algorytmy bezpiecznej komunikacji oprogramowania z

www.pwt.et.put.poznan.pl
Krzysztof Dyki
Krzysztof Małecki
Politechnikka Szczecińska
Wydział Informatyki
ul. Żołnierska 49
71-210 Szczecin
e-mail: [email protected], [email protected]
2005
Poznańskie Warsztaty Telekomunikacyjne
Poznań 8 - 9 grudnia 2005
ALGORYTMY BEZPIECZNEJ KOMUNIKACJI
OPROGRAMOWANIA Z ZABEZPIECZONYMI DANYMI
Streszczenie: W referacie poruszono problematykę
bezpieczeństwa danych krytycznych z punktu widzenia
autora danego oprogramowania. Przedstawiono aktualne
problemy komunikacji niskopoziomowej wraz z aspektami
bezpieczeństwa oprogramowania na etapie projektowania.
Zaproponowano również efektywne metody doboru
poszczególnych algorytmów wraz z metodami ich
implementacji oraz przykładowym rozwiązaniem opartym
o architekturę klient-serwer.
1. WSTĘP
W procesie projektowania oprogramowania
operującego na danych krytycznych (których
bezpieczeństwo musi zostać zapewnione) z punktu
widzenia autora każdorazowo wymagane jest podjęcie
decyzji o wyborze odpowiedniego algorytmu
spełniającego
określone
wymagania
względem
oprogramowania [6],[7]. Analizując aktualnie stosowane
rozwiązania można dojść do wniosku, że producenci nie
przykładają zbytniej wagi do ochrony danych, na
których operuje ich oprogramowanie lub też nie zdają
sobie sprawy ze słabej ochrony wynikającej
prawdopodobnie z błędów popełnianych już na etapie
projektowania oprogramowania i wyboru algorytmów
kryptograficznych przeznaczonych do implementacji.
Niejednokrotnie też producent nie zdaje sobie sprawy z
wartości danych dołączanych do oprogramowania a
szczególnie nie jest świadom możliwości dokonania ich
ekstrakcji i konwersji w celu wykorzystania
(implementacji) w obcym oprogramowaniu bez wiedzy i
zgody autora. Przykładowe typy oprogramowania
narażonego na ataki to:
–
–
oprogramowanie prawnicze (zawartość aktów
prawnych oraz ustawowych dokumentów jest
jednolita, w związku z czym stanowi bardzo cenną
wartość dla firm produkujących lub chcących
wyprodukować konkurencyjne oprogramowanie o
tożsamym przeznaczeniu),
oprogramowanie bazodanowe (przykładem mogą
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
być słowniki oraz programy do kosztorysów
zawierające indeks towarów i usług formatowanych
według ściśle określonych urzędowych kategorii, a
także ogólnodostępne bazy zawierające informacje o
ludności, np. książki telefoniczne wydawane w
formie cyfrowej),
–
oprogramowanie urzędowe (dane oraz informacje
o charakterze niejawnym stanowić mogą cenne
źródło informacji dla szerokiego grona osób
zainteresowanych
ich
rozpowszechnieniem,
odsprzedaniem lub po prostu wykorzystaniem na
własny użytek).
Jak łatwo zauważyć podane przykłady zawierają
bardzo cenne źródła danych, a niejednokrotnie źródła
informacji mogących stanowić tajemnicę handlową o
strategicznym znaczeniu i wymiernej wartości
finansowej. W związku z wysokim stopniem narażenia
na ataki wyżej wymienione typy danych były, i zapewne
w dalszym ciągu będą, obiektami udanych prób
ekstrakcji i konwersji ich danych z przeznaczeniem do
dalszego wykorzystania. Prawidłowa implementacja
komunikacji z algorytmami kryptograficznymi stanowi
dla większości programistów trudne zadanie. Sytuacja
komplikuje się jeszcze bardziej w przypadku potrzeby
skorzystania z ogólnie przyjętych standardów i
zastosowania np. kryptografii asymetrycznej opartej na
wykorzystaniu klucza prywatnego. W takim przypadku
autorzy oprogramowania sięgają najczęściej po gotowe
biblioteki kryptograficzne narażając komunikację
swojego
oprogramowania
z
algorytmem
kryptograficznym na łatwą dekompilację, a w
konsekwencji czytelną analizę funkcjonalną [3].
Głównym problemem jest nie tylko wybór
odpowiedniego algorytmu kryptograficznego, lecz
również, co bardziej istotne od samego algorytmu,
sposób jego implementacji i realizacji komunikacji
oprogramowania z zabezpieczonymi danymi [2].
2. AKTUALNE ROZWIĄZANIA
Na podstawie wyników przeprowadzonych badań
1/4
www.pwt.et.put.poznan.pl
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
deszyfrowania krytycznych danych oprogramowania.
Badając aktualne formy zabezpieczeń danych w
oprogramowaniu komputerowym można stwierdzić, że
standardem stała się implementacja algorytmu RSA w
przypadku korzystania z kryptografii asymetrycznej,
RC4 i DES w przypadku kryptografii symetrycznej oraz
MD5 i SHA dla funkcji haszujących. Powszechnie też
jedyną formą zabezpieczenia zewnętrznych danych
oprogramowania jest użycie jednej operacji XOR. Co
więcej, przeważnie stosowana jest tylko jedna wartość
tego operatora w stosunku do całej objętości
zabezpieczonych danych [5].
Jednak zastosowanie nawet najsilniejszego
asymetrycznego algorytmu kryptograficznego niewiele
ma wspólnego z bezpieczeństwem danych nim
zabezpieczonych jeśli klucz deszyfrujący jest
przechowywany
i
wykorzystywany
przez
oprogramowanie bez zastosowania dodatkowych technik
zwiększających bezpieczeństwo komunikacji wewnątrz
oprogramowania (rysunek 1). Przykładowymi funkcjami
narażonymi na ataki wewnątrz oprogramowania są
komunikacje:
a) oprogramowania z kluczem deszyfrującym,
b) deszyfrowania danych,
c) odczytu danych odszyfrowanych.
APLIKACJA
OPERACJE I/O
PRZEKAZANIE DANYCH
DLA
OPROGRAMOWANIA
DANE
(B1)
ALGORYTM
DESZYFRUJACY
,
BLOK
KOMUNIKACJA
należy przyjąć, że aktualnie stosowane formy
zabezpieczania krytycznych danych oprogramowania,
poza
nielicznymi
wyjątkami,
nie
spełniają
podstawowych wymogów bezpieczeństwa dotyczących
komunikacji oprogramowania z zabezpieczonymi
danymi. Jak wcześniej wspomniano stan taki może być
spowodowany różnymi czynnikami, począwszy od
nieodpowiedniego stopnia uwagi podczas projektowania
oprogramowania i doboru jego algorytmów, poprzez
niewłaściwe metody implementacji samych algorytmów,
a skończywszy na braku świadomości zagrożenia lub
świadomości możliwości stosowania technik odwrotnej
inżynierii (ang. reverse engineering) w stosunku do
każdej
programowej
implementacji
algorytmu
kryptograficznego. Ostatnim najbardziej spektakularnym
przykładem
błędnej
komunikacji
algorytmu
kryptograficznego oraz niewłaściwej ochrony danych
oprogramowania było złamanie 113-bitowego klucza
kryptograficznego algorytmu ECDSA (ang. Elliptic
Curve DSA) w najpopularniejszym oprogramowaniu do
zabezpieczania aplikacji i bibliotek systemowych
Armadillo (www.siliconrealms.com). Do złamania
klucza wykorzystano niezabezpieczoną komunikację
oprogramowania z prywatnym kluczem ECC oraz
ewidentny błąd w generatorze (silniku) liczb pierwszych.
Pomimo
starannego
zabezpieczenia
struktury
oprogramowania
wykorzystano
otwartą
formę
komunikacji, co umożliwiło stworzenie generatora
kluczy dla teoretycznie odpornego na ataki algorytmu
ECDSA. Skupienie się na ochronie komunikacji
wewnątrz oprogramowania zamiast implementowania
wyrafinowanych algorytmów kryptograficznych mogło
w tym przypadku zapobiec złamaniu oprogramowania,
ale przede wszystkim zapobiec utracie wizerunku firmy
Digital River będącej jednym ze światowych liderów w
dziedzinie
ochrony
oprogramowania,
jego
licencjonowania i zabezpieczania transakcji finansowych
dokonywanych online.
W
przypadku
prawidłowej
implementacji
algorytmu kryptograficznego szyfrującego dane,
zakładając dobór właściwego algorytmu o odpowiedniej
długości klucza, nie ma możliwości dokonania dekrypcji
danych zaszyfrowanych za jego pomocą bez znajomości
klucza deszyfrującego będącego przeważnie kluczem
prywatnym w kryptografii asymetrycznej [11]. Wynika
to z właściwości matematycznych danego algorytmu
(najczęściej właściwości te spełniają algorytmy
kryptograficzne w standardzie AES) oraz braku dostępu
do klucza deszyfrującego, w jakiejkolwiek postaci.
Inaczej
jest
w
przypadku
oprogramowania.
Oprogramowanie działające w ramach jednostki
centralnej, bez względu na formę zaimplementowanej
ochrony kryptograficznej (klucz prywatny w kryptografii
asymetrycznej lub klucz deszyfrujący w kryptografii
symetrycznej), musi operować na krytycznym
strumieniu danych stanowiącym klucz deszyfrujący [8].
Najczęstszym błędem popełnianym w trakcie
zabezpieczania
danych
przez
producentów
oprogramowania jest wybór jednego, ewentualnie dwóch
powszechnie znanych algorytmów kryptograficznych, za
pomocą których wykonuje się operacje szyfrowania i
Rys. 1 Aktualne formy komunikacji oprogramowania z
zabezpieczonymi danymi
Brak ochrony komunikacji występującej na
poziomie oprogramowania, algorytmu kryptograficznego
oraz samego klucza deszyfrującego pozwala na użycie
wyżej wymienionych technik analitycznych w celu
odszyfrowania danych bądź uzyskania hasła do ich
dostępu (bez potrzeby wykonywania dodatkowych
operacji). Co więcej, taką formę badania można
sklasyfikować
jako
wysokopoziomową
analizę
funkcjonalną oprogramowania [4] ponieważ w takim
przypadku zbędne jest stosowanie skomplikowanych i
zaawansowanych technik niskopoziomowego badania
kodu w celu próby określenia funkcjonalności badanego
fragmentu oprogramowania. Taki stan nie tylko znacznie
ułatwia pracę osoby analizującej zabezpieczenie danych,
2/4
www.pwt.et.put.poznan.pl
3. PROPONOWANE ROZWIĄZANIE
Najistotniejszym czynnikiem mającym największy
wpływ na bezpieczeństwo danych w kontekście ich
odczytu przez oprogramowanie jest maksymalna
komplikacja algorytmów komunikacji zachodzących
wewnątrz
oprogramowania.
Przez
algorytmy
komunikacji należy rozumieć każdy fragment kodu
odpowiedzialny za odczyt, modyfikację i zapis danych
pobieranych przez oprogramowanie. Przedstawione w
rozdziale drugim aktualnie implementowane formy
komunikacji charakteryzują się dużą otwartością i
czytelnością. Poza tym operują na powszechnie znanych
algorytmach
kryptograficznych,
niejednokrotnie
implementowanych w formie komercyjnych bibliotek
bądź kontrolek systemowych umożliwiając łatwą i
bardzo czytelną analizę funkcjonalną algorytmu, za
pomocą którego zabezpieczono dane.
Proponowane rozwiązanie nie tylko pozbawione
jest tych wad, ale zawiera również propozycję nowej idei
zabezpieczeń zewnętrznych danych oprogramowania.
Główny
nacisk
położono
na
maksymalne
skomplikowanie
czytelności
komunikacji
oprogramowania z zabezpieczonymi danymi oraz
implementację trzech istotnych czynników w dużym
stopniu zwiększających bezpieczeństwo komunikacji, a
tym samym zabezpieczonych danych. Czynnikami tymi
są:
–
–
–
kompresja danych oparta na własnym algorytmie,
zastosowanie podwójnej deszyfracji danych,
pobieranie klucza deszyfrującego z serwera.
Schemat ideowy proponowanego rozwiązania
przedstawiony został na rysunku 2. Na początku
procedur odpowiedzialnych za odczyt bazy danych
uruchamiany jest silnik mutujący dane wejściowe w taki
sposób, że każdorazowe wykonanie danego fragmentu
kodu poprzedzone jest mutacją (przemieszaniem)
danych wejściowych. Celem tego typu operacji jest
mutacja (zmniejszenie czytelności) algorytmów i funkcji
realizowanych wewnątrz oprogramowania [1]. W
przypadku proponowanego rozwiązania odczyt klucza
B(n)1 (pierwszego z dwóch kluczy niezbędnych do
dokonania pełnej dekrypcji, gdzie B oznacza blok
danych, (n) jego numer) poprzedzony jest mutacją jego
danych wejściowych tak, aby w każdym przypadku ich
binarna reprezentacja była inna ale interpretacja taka
sama dla oprogramowania. Następnymi krokami w
kolejności występowania są:
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
–
–
–
–
–
–
–
–
–
–
–
mutacja danych wejściowych i wyjściowych dla
operacji odczytu i ewentualnego zapisu na dysku,
pobranie bloku danych B(n)1,
mutacja bloku danych B(n)1,
mutacja zdekompresowanego bloku B(n)1,
deszyfrowanie bloku B(n)1,
obliczenie indeksu klucza dekrypcji dla bloku
B(n)2,
połączenie z serwerem (LAN, WWW) w celu
pobrania klucza dekrypcji B(n)2,
mutacja klucza B(n)2,
deszyfrowanie bloku B(n)2,
mutacja bloku B(n)2,
odszyfrowanych danych dla oprogramowania.
APLIKACJA
SILNIK
MUTUJACY
,
DANE
(B1)
SERWER
(B2)
ODCZYT KLUCZA
DLA BLOKU B(n)1
DEKOMPRESJA
SILNIK
MUTUJACY
,
SILNIK
MUTUJACY
,
SILNIK
MUTUJACY
,
ALGORYTM
DESZYFRUJACY
BLOK B(n)2
ALGORYTM
DESZYFRUJACY
BLOK B(n)1
SILNIK
MUTUJACY
,
OBLICZENIE
INDEKSU KLUCZA
DLA BLOKU B(n)2
PRZEKAZANIE
DANYCH DLA
OPROGRAMOWANIA
OPERACJE
I/O
SILNIK
MUTUJACY
,
KOMUNIKACJA
ale również poszerza potencjalny krąg osób zdolnych do
odbezpieczenia danego zbioru danych. W przypadku
wysokopoziomowej analizy wystarczy umiejętność
posługiwania się standardowymi funkcjami interfejsu
programowania aplikacji wewnątrz danego systemu
operacyjnego [1]. Umiejętności takie posiada średnio
zaawansowany programista umiejący posłużyć się
dowolnym debuggerem i tworzący oprogramowanie, lub
jego fragmenty, z użyciem funkcji API (ang. Application
Programming Interface) systemu operacyjnego.
Rys. 2 Schemat ideowy proponowanego algorytmu
ochrony komunikacji
Proponowany algorytm, poza charakterystycznymi
punktami
zmniejszającymi
czytelność
danych
wejściowych, powinien wykorzystywać własny algorytm
dekompresji uniemożliwiający skorzystanie z aktualnie
dostępnych bibliotek kompresji i dekompresji danych w
celu ręcznej dekompresji danych. Zastosowanie
kompresji gwarantuje nie tylko dodatkowy element
zabezpieczenia, ale umożliwia również dokonywanie
weryfikacji
integralności
(nienaruszalności)
zabezpieczonych danych w celu np. ochrony przed
modyfikacją lub sygnalizowania uszkodzeń. Jako
algorytmy szyfrujące i deszyfrujące powinny zostać
dobrane również własne rozwiązania, nawet teoretycznie
słabsze (z matematycznego punktu widzenia) od
standardowych algorytmów. Zabieg taki uniemożliwia
automatyczne wykrycie sygnatur znanych algorytmów i
ich tablic, co ma miejsce w przypadku tradycyjnych
rozwiązań
dzięki
możliwości
zastosowania
heurystycznych skanerów binarnych (zasadą działania
zbliżonych do skanerów antywirusowych). Tym samym
analiza i dekompilacja zaimplementowanego algorytmu
3/4
www.pwt.et.put.poznan.pl
szyfrującego
będzie
niewykonalna
dla
osób
nieposiadających
poważnego
doświadczenia
w
posługiwaniu się technikami odwrotnej inżynierii.
Zamiast implementacji własnego algorytmu można
wykorzystać również ogólnodostępne algorytmy wraz z
ich kodami źródłowymi w celu modyfikacji ich stałych
punktów podatnych na skanowanie heurystyczne oraz
skanowanie sygnatur. W tym celu wystarczy
modyfikacja kodu źródłowego bez zmiany jego
funkcjonalności oraz modyfikacja ziarna (ang. seed)
algorytmu. Taki zabieg jest stosunkowo mniej odporny
na analizę niż własny algorytm, jednak w dalszym ciągu
trudniejszy do odnalezienia i analizy niż powszechnie
dostępne biblioteki [10].
Oprócz
typowo
indywidualnych
realizacji
implementowanych
algorytmów
kompresji
i
kryptografii,
w
celu
dodatkowej
ochrony,
zaproponowano podwójne szyfrowanie danych oparte na
wykorzystaniu dwóch tablic kluczy. Tablica kluczy
B(n)1 pobierana byłaby z oprogramowania, natomiast
tablica kluczy B(n)2, niezbędna do dokonania pełnej
dekrypcji danych, powinna być pobierana zdalnie, aby
uniemożliwić jej lokalną ekstrakcję. Zastosowanie
serwera z kluczami deszyfrującymi oraz indywidualnego
algorytmu indeksującego pozycję kluczy B(n)2 jest
nowatorską formą ochrony zaszyfrowanych danych,
niespotykaną dotychczas w oprogramowaniu.
sporego nakładu pracy. Biorąc pod uwagę fakt, że każde
zabezpieczenie ze swojej natury jest możliwe do
odbezpieczenia, a jedynym czynnikiem mogącym
powstrzymać osoby je analizujące jest wymiar czasowy
niezbędny na przeprowadzenie badań należałoby przyjąć
tezę, iż proponowane rozwiązanie spełnia ten wymóg.
Czas niezbędny na odbezpieczenie omawianego
algorytmu powinien przekroczyć wartość danych nim
zabezpieczonych [9].
Proponowane rozwiązanie, w porównaniu do
aktualnie stosowanych algorytmów, charakteryzuje się
znacznie
wyższym
stopniem
bezpieczeństwa
komunikacji oraz skomplikowaniem własnej struktury.
Tym samym zabezpieczone dane są dużo trudniejsze do
odbezpieczenia. Dzięki zastosowaniu kompresji możliwa
jest nie tylko optymalizacja wielkości baz danych, ale
również weryfikacja ich integralności oraz ochrona
antywirusowa. Nieskomplikowane wymogi względem
implementacji (czas implementacji, zasoby systemowe
oraz umiejętności programistyczne) umożliwiają
zastosowanie omawianego algorytmu w każdym typie
oprogramowania, począwszy od oprogramowania typu
shareware, poprzez oprogramowanie komercyjne
jednostanowiskowe, a skończywszy na rozbudowanych
aplikacjach pracujących w środowiskach sieciowych.
4. WNIOSKI
[1] K. Kaspersky, Hacker Disassembling Uncovered, AList Publishing, 2003.
[2] P. Tonella, A. Potrich, Reverse Engineering of
Object Oriented Code (Monographs in Computer
Science), Springer 1st edition, 2005.
[3] D. Aucsmith, Tamper-Resistance Software: An
Implementation, Information Hiding, Proceedings of the
First International Workshop, volume 1174 of LNCS,
1996.
[4] C. Collberg, C. Thomborson, D. Low, Breaking
Abstractions and Unstructuring Data Structures, IEEE
International Conference on Computer Languages, 1998.
[5] C. Wang, J. Hill, J. Knight, J. Davidson, Software
Tamper Resistance: Obstructing Static Analysis of
Programs, Technical Report CS-2000-12, 2000.
[6] A. Lenstra, E. Verheul, Selecting Cryptographic Key
Sizes, Selecting Cryptographic Key Sizes, 1999.
[7] C. Adams, Symmetric Cryptographic System for
Data Encryption, U.S. Patent #5,511,123, 1996.
[8] S. Akl, On the Security of Compressed Encodings,
Advances in Cryptology–Proceedings of Crypto, 1984.
[9] D. Branstad, Encryption Protection in Computer Data
Communications, Proceedings of the 4th Data
Communications Symposium IEEE, 1975.
[10] D. Denning, Cryptography and Data Security,
Addison-Wesley, Reading, 1983.
[11] P. Geffe, How to Protect Data with Ciphers That
Are Really Hard to Break, Electronics 46, 1973.
W prezentowanym referacie ukazano algorytmy i
techniki bezpośrednio zwiększające bezpieczeństwo
krytycznych danych oprogramowania. Zwrócono także
uwagę na najczęściej popełniane błędy podczas
implementacji zabezpieczeń zewnętrznych danych.
Coraz większa wartość danych zamieszczanych wraz z
oprogramowaniem oraz rosnąca skala piractwa i
kradzieży intelektualnej powinna skłonić deweloperów
do stosowania zaawansowanych technik ich ochrony.
Zakładając poprawną implementację proponowanego
rozwiązania w celu dokonania pełnej dekrypcji tylko
jednego bloku danych niezbędne byłoby wykonanie
następujących czynności:
–
–
–
–
ręczna ekstrakcja tablicy kluczy B(n)1,
zdekompilowanie
i
odwrócenie
algorytmu
indeksującego klucze B(n)2,
pobranie z serwera tablicy kluczy B(n)2 (na
podstawie obliczonego indeksu),
zdekompilowanie i ponowna assemblacja algorytmu
dekompresji danych.
Wysoki stopień ochrony oraz skomplikowanie
funkcjonalne od początku eliminuje szerokie grono
potencjalnych osób zdolnych do złamania takiej formy
zabezpieczenia danych. W przypadku pozostałych osób,
które ewentualnie posiadają zaawansowaną wiedzę z
zakresu technik odwrotnej inżynierii oraz kryptografii
przeprowadzenie analizy takiego zabezpieczenia i
odbezpieczenie danych w dalszym ciągu wymagałoby
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
5. LITERATURA
4/4