Przechowywanie klucza

0

Chciałbym szyfrować dane przy użyciu szyfrowania symetrycznego.
Tylko gdzie przechowywać klucz użyty do szyfrowania, żeby nie dało się go łatwo zdobyć? Najprościej klucz przechowywać w kodzie źródłowym:

private static final byte[] keyValue = 
        new byte[] { 'T', 'h', 'i', 's', 'I', 's', 'A', 'S', 'e', 'c', 'r', 'e', 't', 'K', 'e', 'y' };

http://lkamal.blogspot.com/2009/10/java-encrypt-decrypt-jce-salt.html

Problem w tym, że w Javie da się podejrzeć kod źródłowy. Czy wobec tego dobrym pomysłem byłoby skompilowanie pliku .jar do kodu natywnego (np. exe na Windowsie)? Jeżeli tak, to jakie darmowe (lub niedrogie) kompilatory kodu natywnego moglibyście polecić? Może GCJ lub JavaNativeCompiler?

Czy oprócz tego jest jeszcze jakiś sposób na ukrycie klucza?

1

Skoro klucz ma być w programie do odszyfrowywania, to właściwie program jest kluczem. Jak udostępnisz program, to tak jakbyś udostępnił klucz. Takie kombinacje jak chcesz zrobić niewiele dadzą. Klucz ma być tajny a to znaczy, że trzeba go znać i podawać po uruchomieniu programu. Co konkretnie chcesz osiągnąć? Może potrzebne ci szyfrowanie asymetryczne, może funkcje skrótu? Tak na marginesie do przechowywania kluczy jest coś takiego jak keystore (JKS).

0

Chodzi o coś takiego - program ma być klientem sieci peer-to-mail i jedną z opcji będzie szyfrowanie/odszyfrowanie hasła do skrzynek pocztowych, czyli zarówno szyfrowanie haseł jak i odszyfrowywanie będzie w tym samym programie.

Coś na wzór jak jest w programie Mail Resender:
http://www.mailresender.com.ar/Encode.html
a przy ściąganiu plików ze skrzynki:
http://www.mailresender.com.ar/Download.html
użytkownik po prostu podane dane do logowania (w tym to zaszyfrowane hasło do skrzynki) pobrane z jakiegoś forum (o tym piszę poniżej).

Czyli np. jeden użytkownik za pomocą programu wrzuci na swoją skrzynkę pocztową pliki (w formie załączników do wiadomości) i zaszyfruje do niej hasło. Później wrzuci na jakieś forum (tak jak np. tutaj: http://p2mpolska.com/topic/107488-kabaret-ani-mru-mru-edycja-specjalna-2006/) te dane do logowanie do skrzynki (czyli login i to zaszyfrowane hasło), tak żeby inni użytkownicy mogli wpisać te dane do programu i zalogować się do skrzynki po to by móc pobrać wrzucone na niej pliki. Program wtedy odszyfruje sobie hasło i zaloguje się do skrzynki.

Założyłem, że można by użyć do tego jednego klucza symetrycznego. Ale być może szyfrowanie symetrycznie się tu nie przyda i będzie właśnie coś innego z tych rzeczy, które wymieniłeś?

chodnik napisał(a)

Tak na marginesie do przechowywania kluczy jest coś takiego jak keystore (JKS).

Czy w tym keystore klucze przechowywane są lokalnie, czy gdzieś zdalnie na serwerze?

1
R_K napisał(a)

Czy w tym keystore klucze przechowywane są lokalnie, czy gdzieś zdalnie na serwerze?

Keystore to plik, więc może być lokalnie a może być dostępny przez URL, jak chcesz.
Z tego co piszesz że chcesz, to hasło musi być w programie, więc wydaje mi się, że nie ma bezpiecznego sposobu osiągnięcia tego. Można jedynie utrudnić odnalezienie. A to można osiągnąć używając złożonego algorytmu szyfrującego, np. kilka różnych algorytmów po sobie z dodanymi jakimiś przesunięciami. Układ wywołań kolejnych kroków będzie stanowił program i wtedy odczytanie samego hasła niewiele da, bo konieczna będzie znajomość sekwencji i rodzaju użytych algorytmów. Dodatkowo kolejne kroki mogą zależeć od samej treści hasła (instrukcje if else w zależności od wartości któregoś bajtu w tablicy).
Ewentualnie jako hasła możesz użyć funkcji skrótu z zapisanej tablicy bitowej, to się wydaje prostsze.

1

Jako, ekhem :D, były pomagier przy Moorhuncie powiem ci jak to w nim wyglądało i wygląda (aplikacja jest napisana w .NET, więc podobny motyw). Moorhunt był tym pierwszym z najbardziej popularnych programów zaraz po oryginalnym kliencie i wśród wszystkich hashy P2M to właśnie te Moorhuntowe są najpopularniejsze (<<a..*>>). Każda kolejna wersja hasha to przede wszystkim inny klucz i IV. Wszystkie one są oczywiście zawarte w kodzie programu. Na przestrzeni kilku lat stosowane były różne metody ich zabezpieczenia (było sporo osób, które tworzyły własny program i chciały, by można w nich było korzystać z hashy Moorhunta i.. z reguły im się to udawało), były stosowane różne protectory i tak na dobrą sprawę żaden z nich nie może zagwarantować, że tych kluczy nie będzie można przechwycić. Ba, nie jest to nawet trudne, ot zadanie na max 20 minut (nawet jeżeli reflector się wysypywał to zawsze można było zrobić ildasm i dojść do odpowiednich nazw funkcji, a potem... po prostu je wywołać przez refleksję). Z pewnością więcej czasu było poświęcone na próbę ich zabezpieczenia. Możesz mieć tylko nadzieję, że umiejętności pozwalające na złamanie takiego zabezpieczenia idą w parze z brakiem chęci niszczenia czyjejś pracy (bo co by stało na przeszkodzie, by napisać program, który przeszukuje takie forum i usuwa wszystkie dane ze skrzynek w hashach?).

0
chodnik napisał(a)

Keystore to plik, więc może być lokalnie a może być dostępny przez URL, jak chcesz.

Z tego co piszesz że chcesz, to hasło musi być w programie, więc wydaje mi się, że nie ma bezpiecznego sposobu osiągnięcia tego.

OK, nie upieram się - klucz nie musi być koniecznie w kodzie programu. Ale nawet jeżeli będzie gdzieś na zewnątrz - np. we wspominanym przez Ciebie Keystore, to pewnie jak ktoś się uprze, to też znajdzie jakiś sposób, żeby wydobyć z tego pliku klucz? Więc to również będzie tylko (a zarazem "aż") utrudnienie?

chodnik napisał(a)

Można jedynie utrudnić odnalezienie. A to można osiągnąć używając złożonego algorytmu szyfrującego, np. kilka różnych algorytmów po sobie z dodanymi jakimiś przesunięciami. Układ wywołań kolejnych kroków będzie stanowił program i wtedy odczytanie samego hasła niewiele da, bo konieczna będzie znajomość sekwencji i rodzaju użytych algorytmów. Dodatkowo kolejne kroki mogą zależeć od samej treści hasła (instrukcje if else w zależności od wartości któregoś bajtu w tablicy).

Czyli jak rozumiem chodzi tu o utrudnienie analizy kodu? Wobec tego - czy jest w ogóle sens kompilowania do kodu natywnego, czy pozostawić kod w plikach .jar? Bo jeżeli zostawię w .jar, to analiza będzie na poziomie kodu wysokopoziomowego (Java), a jak skompiluję do np. .exe, to analizować będzie przy pomocy jakiegoś edytora plików binarnych, lub nawet kod assemblera. Więc gdzie będzie trudniej? Czy warto sobie w ogóle zawracać głowę kompilacją do exe?

chodnik napisał(a)

Ewentualnie jako hasła możesz użyć funkcji skrótu z zapisanej tablicy bitowej, to się wydaje prostsze.

private static final byte[] keyValue = 
        new byte[] { 'T', 'h', 'i', 's', 'I', 's', 'A', 'S', 'e', 'c', 'r', 'e', 't', 'K', 'e', 'y' };

http://lkamal.blogspot.com/2009/10/java-encrypt-decrypt-jce-salt.html

Czy chodzi może o to, żeby na tej zmiennej keyValue użyć jednokierunkowej funkcji hashującej (np. SHA1)?

0
Rev napisał(a)

Jako, ekhem :D, były pomagier przy Moorhuncie powiem ci jak to w nim wyglądało i wygląda (aplikacja jest napisana w .NET, więc podobny motyw).

No to gratulacje, bo z tego co słyszałem to świetny program. Ja wolałem się powzorować na Mail Resenderze, bo wydaje mi się, że prościej będzie taki program napisać. Mój program nie będzie więc korzystał z hashcodów, tylko po prostu z pary: login, hasło (zwykle zaszyfrowane).

Rev napisał(a)

Moorhunt był tym pierwszym z najbardziej popularnych programów zaraz po oryginalnym kliencie i wśród wszystkich hashy P2M to właśnie te Moorhuntowe są najpopularniejsze (<<a..*>>). Każda kolejna wersja hasha to przede wszystkim inny klucz i IV. Wszystkie one są oczywiście zawarte w kodzie programu.

Czyli reasumując w klientach sieci Peer-to-mail klucz musi być w kodzie programu? Po prostu nie ma innego sposobu, żeby użytkownik mógł sobie odszyfrować hasło do skrzynki?
Jak generujecie te hascody? Używacie szyfrowania symetrycznego, asymetrycznego? Do tego używacie hashowania?

Rev napisał(a)

Na przestrzeni kilku lat stosowane były różne metody ich zabezpieczenia (było sporo osób, które tworzyły własny program i chciały, by można w nich było korzystać z hashy Moorhunta i.. z reguły im się to udawało), były stosowane różne protectory i tak na dobrą sprawę żaden z nich nie może zagwarantować, że tych kluczy nie będzie można przechwycić. Ba, nie jest to nawet trudne, ot zadanie na max 20 minut (nawet jeżeli reflector się wysypywał to zawsze można było zrobić ildasm i dojść do odpowiednich nazw funkcji, a potem... po prostu je wywołać przez refleksję). Z pewnością więcej czasu było poświęcone na próbę ich zabezpieczenia. Możesz mieć tylko nadzieję, że umiejętności pozwalające na złamanie takiego zabezpieczenia idą w parze z brakiem chęci niszczenia czyjejś pracy (bo co by stało na przeszkodzie, by napisać program, który przeszukuje takie forum i usuwa wszystkie dane ze skrzynek w hashach?).

Czy w takim razie jest w ogóle sens kompilować do .exe? Bo jeżeli dla crackera to robota na 20 min, to może lepiej pozostawić program w plikach .jar i się nie przejmować? :)

1

Hashe w Moorhuncie to zwykła struktura, która zawiera metadane w postaci nazwy pliku, listy kont z danymi dostępowymi i hasła umożliwiającego edycję. Zserializowana do ciągu bajtów, zaszyfrowana najzwyklejszym AES i potraktowana base64. W kodzie programu są klucze i IV. W gruncie rzeczy to to samo, co chcesz zrobić. Jeżeli masz pod ręką jakiś gotowy, darmowy protector to nic nie zaszkodzi, żeby go użyć, ale.. generalnie tego typu rzeczy dla kogoś obytego z deasemblerem i debuggerem to mała przeszkoda. No cóż, taka już specyfika tego typu programów, że nie da się skutecznie tego zabezpieczyć, bo tak czy inaczej na skrzynki pocztowe logować się będzie komputer użytkownika.

0
Rev napisał(a)

Jeżeli masz pod ręką jakiś gotowy, darmowy protector to nic nie zaszkodzi, żeby go użyć, ale.. generalnie tego typu rzeczy dla kogoś obytego z deasemblerem i debuggerem to mała przeszkoda. No cóż, taka już specyfika tego typu programów, że nie da się skutecznie tego zabezpieczyć, bo tak czy inaczej na skrzynki pocztowe logować się będzie komputer użytkownika.

W programach w których trzeba podawać hasło (czy klucz) przy logowaniu, można podobno to hasło łatwo wydobyć z kodu podając błędne hasło i zastawiając breakpoint. Istnieją specjalne narzędzia umożliwiając to (np. SoftIce). Później pozostaje już tylko analiza kodu assemblerowego.

1 użytkowników online, w tym zalogowanych: 0, gości: 1