Jak niebezpieczne jest szyfrowanie danych za pomocą formatu AES-128-CTR przy użyciu formatu pliku kluczy Ethereum?
On 18 listopada, 2020 by adminUżywam formatu pliku kluczy Ethereum do szyfrowania wszelkich innych danych, takich jak zwykły tekst lub JSON.
Oto przykład pseudokod implementacji:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Za pomocą tego kodu mogę wygenerować plik kluczy, który wygląda następująco:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
To jest standardowy plik, który przechowuje miliony dolarów ludzi w Ethers.
Pytania:
- Czy to jest bezpieczne?
- Jeśli nie, dlaczego?
- Jeśli tak, czy szyfrowanie zwykłego tekstu lub JSON jest również bezpieczne (bez formatu szesnastkowego)?
- Czy bezpieczne jest ustawienie mniejszego
kdfparams.n
?
Edytuj: Aby wyjaśnić, dlaczego pytam, to dlatego, że inna osoba powiedziała to:
To wcale nie jest bezpieczne. Ta implementacja zawiera wiele podstawowych błędów. Jednym z przykładów jest użycie niezabezpieczonego generatora liczb losowych, który całkowicie niszczy bezpieczeństwo szyfrowania. Innym jest użycie AES- 128-CTR bez uwierzytelniania.
Komentarze
- Najpierw zdefiniuj ” secure ” . Ale według jakiejkolwiek rozsądnej definicji, z hasłem z tej samej ligi co ' 1234 ' i tak duży i nadmiarowy tekst jawny, że nic użytecznego nie jest bezpieczne.
- Bezpieczne pod względem bardzo trudnym do złamania, nawet jeśli jest dobry kryptograf i edytuj, aby wyjaśnić, że byłoby to bardzo silne hasło.
- Teraz zdefiniuj ” break ” . Czy to znalezienie oryginalnego hasła? Zgadujesz tekst jawny z jednego zaszyfrowanego tekstu? Zgadujesz fragment tekstu jawnego z wielu tekstów zaszyfrowanych, które udostępniają te niektóre? Zgadujesz jeden tekst jawny z wielu tekstów zaszyfrowanych i wszystkich innych tekstów jawnych? Czy możemy uzyskać pomoc od pliku wykonywalnego działającego na tej samej maszynie (a jeśli tak, to jaki dokładnie procesor z jaką poprawką mikrokodu? Jest używany AES-NI?). Czy możemy używać EMI jako kanału bocznego? Keylogger, hardware czy sotfare? Rzeczywiście, czym ' jest implementacja randomBytes, która ma wpływ?
- Nie możesz odpowiedzieć na to pytanie, patrząc na psuedocode. Rzeczywista implementacja może zawierać wszelkiego rodzaju luki i kanały boczne . Bezpieczeństwo też nie jest binarne, ' zależy od tego, jak daleko ' chcesz zabezpieczyć się przed coraz większą egzotyczne ataki .
- @ fgrieu przepraszam, jedyne pytanie, na które mogę odpowiedzieć, to: nodejs.org / api / … @EllaRose Zakładam, że biblioteki, których używam, nie mają luk w zabezpieczeniach. Więc mój pseudokod powyżej jest po prostu implementacją tych funkcji bibliotek, takich losowych bajtów.
Odpowiedź
Najgorsze czysto kryptograficzną słabością jest hasło (1). Najgorsze (i znacznie gorsze) praktyczne słabości mogą znajdować się w implementacji (6) (7) i tych (4) (5), które kryptolodzy odrzucają jako poza zakresem szyfrowania (jedyny określony cel pytania).
Kandydaci na słabości, od kryptografii (ale wciąż do rozważenia) do implementacji:
- Hasło: trudno zapamiętać hasło z ponad 48 bitami entropii ( to mniej więcej odpowiednik 16-cyfrowej liczby, np. 3141592653589793 lub 2718281828459045, i więcej niż przewiduje to obowiązkowy XKCD ). Używając N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , kupujesz co najmniej 18 + 3 + 1 = 22 bity (patrz to ) w porównaniu z prostym hashem SHA-256, po którym następuje AES-128, myślę, że około 32 bity mocniejsze, więc klucz może być dobry około 80 bitów, co jest nie do końca niezniszczalny brutalną siłą, ale nadal całkiem bezpieczny.
- AES-128: ma 128-bitowy klucz, nieznany czysto kryptoanalityczny atak lepszy niż brutalna siła, a zatem jest znacznie lepszy niż hasło.
- Tryb CTR: z 128-bitowym blokiem AES jedynym sposobem ponownego użycia strumienia klucza byłaby zła liczba losowa generator dla IV (patrz 6)
- Rozmiar tekstu jawnego można łatwo wywnioskować z rozmiaru tekstu zaszyfrowanego. Jest to wyraźnie nie teoretyczna słabość szyfrowania, ponieważ długość jest wykluczone z tego, co szyfr ma ukrywać w tekście jawnym. Jednak może to być praktyczną słabością. Analiza tekstu zaszyfrowanego stwierdza, że jest to 17267095423 oktety; i istnieje gdzieś w prokuraturze eksponuje teczkę o dokładnie takiej wielkości, ewidentnie poprzedzającą przeszukanie i zajęcie zaszyfrowanego tekstu, a której samo zatrzymanie jest nielegalne.
- Brak wykrywania (umyślnych lub przypadkowych) zmian w zaszyfrowanym tekście, odpowiadających przewidywalnej zmianie w tekście jawnym: znowu jest to wyraźnie nie teoretyczna słabość szyfrowania, ale może pozwolić na niektóre ataki jeśli przeciwnik może zmienić zaszyfrowany tekst (na przykład: jeśli tekst jawny jest plikiem wykonywalnym lub PDF ze znanym ułamkiem, może to pozwolić na zmianę tego, co robi plik wykonywalny, na cokolwiek lub sprawić, że plik PDF będzie wyświetlany jako cokolwiek). Uwierzytelnione szyfrowanie ( AES-GCM ..) rozwiązuje ten problem.
- Generator liczb losowych: jeśli jest źle lub gorzej, blokuje się mniej lub bardziej (obowiązkowo XKCD i Dilbert , które zbyt często stają się rzeczywistością), co umożliwiłoby odzyskanie zwykłego tekstu w wielu scenariuszach, w tym wielokrotne szyfrowanie różnych tekstów w języku angielskim lub adresów e-mail za pomocą tego samego hasła.
- Kanał boczny, czyli ogólnie mówienie o nieprzewidzianym lub pełnym wycieku informacji w kontekście wdrożenia lub użytkowania. Jest ich tak wiele:
- Odzyskiwanie hasła od właściciela hasła przez wykorzystanie błędu proceduralnego (hasło w notatce postit, lista haseł głównych), kryptoanaliza węża gumowego (obowiązkowa XKCD ), warianty prawne (obejmujące użycie wyrażeń na temat obraza sądu ), łapówkarstwo, impregnacja chemiczna ..
- Odzyskiwanie hasła przez surfowanie po ramionach , key logger (oprogramowanie lub sprzęt), kamera, mikrofon (dobre nagranie dźwięku dźwięk klawiszy podczas wprowadzania hasła powoduje wyciek wielu informacji o haśle, zwłaszcza gdy jest skorelowany ze znanym wpisem na klawiaturze przez tego samego operatora w tych samych warunkach).
- Proste kompromitacja tekstu jawnego, jak pokazano na ekranie (z TEMPEST ), drukowane podczas przesyłania do drukarki lub zdalnego dostępu przez sieć lub po prostu przechowywane „tymczasowo”.
- Prosty kompromis z systemem operacyjnym maszyny zajmujemy się szyfrowaniem lub deszyfrowaniem (wystarczy uzyskać tymczasowy dostęp do roota, co oznacza, że w wersji 7.7 gra jest dla atakującego).
- Kryptanalityczny kanał boczny na odległość, w tym DPA i wariant elektromagnetyczny DEMA oraz hipotetycznie synchronizacja , jeśli maszyna wykonująca szyfrowanie / deszyfrowanie jest dostępna przez sieć i nie używa instrukcje AES .
- Kryptanalityczny kanał boczny z procesu działającego na tym samym sprzęcie (w tym na innej maszynie wirtualnej), w tym oparte na pamięci podręcznej kierowanie na AES, gdy nie używa AES instrukcje lub bardziej ogólne (Meltdown, Spectre), które są obecnie popularne.
- Wykorzystywanie różnych błędów oprogramowania; to jest ogromne.
Komentarze
- Byłoby bardziej przydatne, gdybym zaszyfrował hasło przed szyfrowaniem? Podobnie jak użycie sha lub md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Hashowanie hasła przed wpisaniem w scrypt nie zmienia zbytnio trudności ataku na hasło ( punkt 1) .Aby to poprawić, potrzebne jest lepsze hasło, lepsza parametryzacja dla skryptu lub lepszy schemat wyprowadzania klucza na podstawie hasła (Argon? Balon?)
Odpowiedź
Głównym elementem bezpieczeństwa, który można zaatakować w powyższym schemacie, jest – oczywiście – hasło. Teraz sól jest ważna, aby uniknąć ataków tęczowych tablic, ale poza tym nie dodaje aż tyle bezpieczeństwa. Jeśli sól i hasło są w miarę unikalne, klucz również jest unikalny. W takim przypadku IV nie jest taka ważna.
Więc chociaż używanie niezabezpieczonego generatora liczb losowych jest złe, prawdopodobnie nie będzie miało tak dużego wpływu na praktyczne bezpieczeństwo. wskazuje, że rzeczywiście zastosowano złe praktyki. Co by się stało, gdyby hasło zostało wygenerowane przy użyciu tego samego niezabezpieczonego generatora losowego? Co się stanie, jeśli pojawią się inne błędy implementacji?
Używanie nieuwierzytelnionego tekstu zaszyfrowanego jest większym problemem, ponieważ Pozwoliłoby to przeciwnikowi zmienić tekst jawny dla każdego bitu. Przeciwnik może po prostu odwrócić dowolny bit tekstu zaszyfrowanego, a bit tekstu jawnego w tej samej pozycji również się odwróci. Oznaczałoby to, że wystąpiłby błąd lub problem podczas korzystania z portfela. Poufność zawartości portfela prawdopodobnie nie zostanie utracona, ale używanie uwierzytelnionego szyfrowania jest z pewnością najlepszą praktyką.
Komentarze
- Dziękuję! Czy mógłbyś wyjaśnić ledwo jak uzyskać uwierzytelniony tekst zaszyfrowany w tym trybie? Powyższe przykłady, ponieważ myślę, że są związane z oryginalną właściwością mac, którą usunąłem z oryginalnego pliku kluczy.
- Tryb CTR jest podstawowym trybem CCM, GCM, EAX, SIV i całej masy innych uwierzytelnionych szyfry. Jednak połączenie trybu CTR z (H) MAC może z pewnością być również bezpieczne.Oba tworzą znacznik uwierzytelniający o mniej więcej tym samym rozmiarze / zabezpieczeniu. CCM i EAX to niewiele więcej niż konkretne kombinacje CTR i MAC, w których ten sam klucz może być użyty do szyfrowania i MAC.
- Zwróć uwagę, że ' ve odpowiedziałem na to pytanie najlepiej jak potrafiłem, wykorzystując ogólną wiedzę o szyfrach (nie tyle Ethereum). Ella Rose ma rację, że nie możemy wywnioskować o bezpieczeństwie systemu na podstawie informacji podanych w pytaniu. Dlatego ' skupiłem się wyłącznie na wykorzystaniu CTR.
- Cóż, losowość wydaje się polegać – w końcu – na systemie losowym. Często losowe źródła systemowe są stosunkowo bezpieczne, a termin CSPRNG jest rzeczywiście używany w źródle. Więc twierdzenie, że nie jest losowe, jest błędne, chyba że system losowy nie jest dobrze zaimplementowany lub rozstawiony.
- Tworzenie MAC bezpośrednio z SHA-3 nie jest zalecane, zamiast tego powinno się użyć KMAC (prawdopodobnie po prostu nie został jeszcze wtedy określony '). Ale nie przychodzi mi do głowy żadna sytuacja, w której użycie zamiast konkatenacji klucza i zaszyfrowanego tekstu mogłoby kiedykolwiek stanowić problem.
Dodaj komentarz