Powodem, dla którego nie chcesz samodzielnie implementować algorytmów kryptograficznych, są ataki typu side-channel.

Co to jest kanał boczny?

Kiedy komunikujesz się z serwerem, treść wiadomości jest „głównym” kanałem komunikacji. Jest jednak kilka innych sposobów na uzyskanie informacji od partnera komunikacyjnego, które bezpośrednio nie wiążą się z tym, że coś ci powie.

Są to między innymi:

• Czas potrzebny na udzielenie odpowiedzi
• Energia, którą serwer zużywa na przetworzenie żądania
• Jak często serwer uzyskuje dostęp do pamięci podręcznej, aby odpowiedzieć.

Co to jest atak kanału bocznego?

Mówiąc najprościej, atak kanału bocznego to każdy atak na system, w którym występuje jeden z tych kanałów bocznych. Weź następujący kod jako przykład:

  public bool IsCorrectPasswordForUser (string currentPassword, string inputPassword) {// Jeśli oba ciągi nie mają takiej samej długości, nie są równe. if (currentPassword.length! = inputPassword.length) return false; // Jeśli zawartość łańcuchów różni się w dowolnym momencie, zatrzymaj i zwróć, nie są one równe. for (int i = 0; i < currentPassword.length; i ++) {if (currentPassword [i]! = inputPassword [i]) return false; } // Jeśli łańcuchy miały jednakową długość i nigdy nie miały żadnych różnic, muszą być równe. return true;}  

Ten kod wydaje się funkcjonalnie poprawny, a jeśli nie popełniłem żadnych literówek, prawdopodobnie robi to, co powinien. Czy nadal potrafisz dostrzec wektor ataku kanału bocznego? Oto przykład, aby to zademonstrować:

Załóżmy, że bieżące hasło użytkownika to Bdd3hHzj (8 znaków) i osoba atakująca próbuje je złamać. Jeśli atakujący wprowadzi hasło o tej samej długości, zostanie wykonana zarówno kontrola if , jak i co najmniej jedna iteracja pętli for ; ale jeśli hasło wejściowe będzie krótsze lub dłuższe niż 8 znaków, zostanie wykonane tylko polecenie if . Pierwsza sprawa wymaga więcej pracy, dlatego jej zakończenie zajmie więcej czasu niż druga; łatwo jest porównać czasy potrzebne do sprawdzenia hasła 1-znakowego, 2-znakowego, 3-znakowego itp. i zauważyć, że 8 znaków to jedyne, które jest znacząco różne, a zatem prawdopodobnie będzie to poprawna długość hasła hasło.

Mając tę ​​wiedzę, atakujący może udoskonalić swoje dane wejściowe. Najpierw próbują aaaaaaa poprzez aaaaaaaZ , z których każdy wykonuje tylko jedną iterację pętli for . Ale kiedy dochodzą do Baaaaaaa , następują dwie iteracje pętli, których wykonanie ponownie zajmuje więcej czasu niż wejście zaczynające się jakimkolwiek innym znakiem. To informuje atakującego, że pierwszym znakiem hasła użytkownika jest litera B , i może teraz powtórzyć ten krok, aby określić pozostałe znaki.

Jak to się ma do mojego Kod kryptograficzny?

Kod kryptograficzny bardzo różni się od „zwykłego” kodu. Patrząc na powyższy przykład, nie wydaje się błędny w żaden istotny sposób. W związku z tym podczas samodzielnego wdrażania może nie być oczywiste, że kod, który robi to, co powinien, właśnie wprowadził poważną lukę.

Innym problemem, o którym przychodzi mi do głowy, jest to, że programiści nie są kryptografami. Zwykle postrzegają świat inaczej i często przyjmują założenia, które mogą być niebezpieczne. Na przykład spójrz na następujący test jednostkowy:

  public void TestEncryptDecryptSuccess () {string message = "To jest test"; KeyPair keys = MyNeatCryptoClass.GenerateKeyPair ();
byte [] cipher = MyNeatCryptoClass.Encrypt (wiadomość, klucze.Public); string decryptedMessage = MyNeatCryptoClass.Decrypt (szyfr, klucze.Private); Assert.Equals (message, decryptedMessage);}  

Czy wiesz, co jest nie tak? Muszę przyznać, że to nie było uczciwe pytanie. MyNeatCryptoClass implementuje RSA i jest wewnętrznie ustawiony na używanie domyślnego wykładnika 1, jeśli nie podano jawnie wykładnika.

I tak, RSA będzie działać dobrze, jeśli użyjesz publicznego wykładnika potęgi 1. Po prostu niczego nie „zaszyfruje”, ponieważ „x ¹ ” nadal jest „x”.

Możesz zadać sobie pytanie, kto przy zdrowych zmysłach by to zrobił , ale zdarzają się takie przypadki.

Błędy implementacji

Innym powodem, dla którego implementacja własnego kodu może się nie udać, są błędy implementacji. Jak zauważa użytkownik Bakuridu w komentarzu, błędy w kodzie Crypto są śmiertelne w porównaniu z innymi błędami. Oto kilka przykładów:

Heartbleed

Heartbleed to prawdopodobnie jeden z najbardziej znanych błędów implementacyjnych, jeśli chodzi o kryptografię. Chociaż nie wiąże się to bezpośrednio z implementacją kodu kryptograficznego, to jednak ilustruje, jak potwornie złe rzeczy mogą się potoczyć w przypadku stosunkowo „małego” błędu.

Podczas gdy linkowany artykuł w Wikipedii zawiera dużo bardziej szczegółowe informacje na ten temat, ja chciałbym, aby Randall Munroe wyjaśnił sprawę znacznie bardziej zwięźle niż kiedykolwiek:

^{https://xkcd.com/1354/ - Obraz na licencji CC 2.5 BY-NC}

Debian Słaby błąd PRNG

W 2008 roku pojawił się błąd w Debianie co wpłynęło na losowość wszystkich dalszych użytych kluczowych materiałów. Bruce Schneier wyjaśnia zmianę, którą wprowadził zespół Debiana i dlaczego była ona problematyczna.

Podstawowym założeniem jest to, że narzędzia sprawdzające możliwe problemy w kodzie C narzekały na użycie niezainicjowanych zmiennych. Chociaż zwykle jest to problem, umieszczenie w PRNG zasadniczo losowych danych nie jest złe. Ponieważ jednak nikt nie lubi wpatrywać się w ostrzeżenia, a uczenie się, jak ignorować ostrzeżenia, może prowadzić do własnych problemów, w pewnym momencie „obraźliwy” kod został usunięty, co prowadzi do mniejszej entropii dla OpenSSL.

Podsumowanie

Podsumowując, nie wdrażaj własnego Crypto, chyba że zostało zaprojektowane do nauki! Używaj sprawdzonej biblioteki kryptograficznej zaprojektowanej tak, aby łatwo było zrobić to dobrze, a trudno było źle. Ponieważ Crypto jest bardzo łatwe do zrobienia źle.

Wspomniane ataki kanałem bocznym to wielka rzecz. Uogólniłbym to trochę bardziej. Twoja biblioteka kryptograficzna to kod o bardzo wysokim ryzyku / wysokim poziomie trudności. Często jest to biblioteka , której można ufać, że chroni resztę miękkiego systemu. Błędy tutaj mogą z łatwością sięgać milionów dolarów.

Co gorsza, często musisz walczyć z własnym kompilatorem. Zaufane implementacje tych algorytmów są intensywnie badane przez wiele różnych kompilatorów i zawierają drobne poprawki, aby zapewnić, że kompilatory nie robią złych rzeczy. Jak zły? Cóż, zastanów się nad tymi bocznymi atakami kanałowymi, o których wszyscy wspominają. Ostrożnie piszesz kod, aby uniknąć wszystkich tych ataków, robiąc wszystko dobrze. Następnie uruchamiasz na nim kompilator. Kompilator nie ma pojęcia, co robiłeś. Może łatwo zobaczyć niektóre z tych rzeczy, które zrobiłeś, aby uniknąć ataków kanału bocznego, zobaczyć szybszy sposób na zrobienie tego i zoptymalizować kod, który starannie dodałeś! Pojawiło się to nawet w kodzie jądra, gdzie przypisanie w niewielkiej kolejności daje kompilatorowi uprawnienia do optymalizacji sprawdzania błędów!

Wykrywanie takich rzeczy można to zrobić tylko za pomocą dezasemblera i dużo cierpliwości.

Och, i nigdy nie zapominaj o błędach kompilatora. W zeszłym miesiącu spędziłem większą część tygodnia na szukaniu błędu w moim kodzie, który w rzeczywistości był w porządku - był to znany błąd w moim kompilatorze, który był przyczyną problemu. Teraz miałem szczęście, ponieważ błąd spowodował awarię mojego programu, więc wszyscy wiedzieli, że trzeba coś zrobić. Niektóre błędy kompilatora są bardziej subtelne.

Argumentem przeciwko toczeniu własnej kryptowaluty jest to, że błędy mogą ukrywać się w oprogramowaniu kryptograficznym bez żadnych objawów, nawet w obliczu obszernych testów.

Wszystko wydaje się działać idealnie. Na przykład w aplikacji podpisującej / weryfikującej weryfikator będzie działał prawidłowo. ważne podpisy i odrzucaj nieważne. Same sygnatury będą wyglądać jak bełkot dla oka, ale błąd nadal będzie tam, czekając na rzeczywisty atak.

Czy kiedykolwiek wpisałeś znak w swoim kodzie i nie zauważyłeś, co spowodowało, że edytor wyróżnienie lub szybki błąd kompilacji lub wykonania, a następnie szybko go naprawiłeś? Gdyby nie miał podświetlenia, skompilowany i działał bez widocznych objawów, czy kiedykolwiek złapałeś tę literówkę? To jest poziom trudności w rozwijaniu własnego krypto.

Nawet w sytuacjach, gdy ataki typu side-channel nie są możliwe, algorytmy kryptograficzne często zawierają szczegóły implementacji, które są krytyczne dla bezpieczeństwa, ale nie są oczywiste. Dwa przykłady:

• Algorytm podpisu ECDSA wymaga użycia losowej liczby całkowitej podczas generowania podpisu. Ta liczba całkowita musi być inna dla każdego podpisu generowanego za pomocą danego klucza prywatnego. Jeśli zostanie ponownie użyty, każdy, kto uzyska dwa podpisy, może odzyskać klucz prywatny za pomocą podstawowej arytmetyki modularnej. (Sony popełniło ten błąd przy zabezpieczeniu przed kopiowaniem PlayStation 3, używając tego samego numeru dla każdego podpisu).

• Generowanie pary kluczy dla algorytmu RSA wymaga wygenerowania dwóch losowych dużych liczb pierwszych. W normalnych warunkach odzyskanie klucza prywatnego wymaga faktoryzacji na czynniki całkowite lub rozwiązania problemu RSA, co jest bardzo powolnymi operacjami matematycznymi. Jeśli jednak para kluczy dzieli jedną ze swoich liczb pierwszych z inną parą kluczy, wówczas klucze prywatne obu par można łatwo odzyskać, po prostu obliczając największy wspólny dzielnik dwóch kluczy publicznych. (Wiele routerów generuje certyfikaty SSL przy pierwszym uruchomieniu, gdy nie ma dużej liczby losowości. Czasami zdarza się, że dwa routery generują certyfikaty z nakładającymi się parami kluczy).

Wydaje mi się, że napisane drobnym drukiem:

Zaimplementowanie algorytmu kryptograficznego jest w porządku, o ile kod jest wolny od błędów i pozwala uniknąć wszelkich pułapek na każdej platformie (system operacyjny i architektura), na której kod będzie działać.

Na przykład niektóre implementacje prawdopodobnie mają dodatkowy kod zapobiegający atakom z kanału bocznego. Nie jest to nieodłączne od algorytmu, ale jest wymagane, aby implementacja była bezpieczna. To prawdopodobnie jeden z wielu punktów.

Niezwykle łatwo jest popełnić błąd kryptograficzny, jeśli zastosujesz go samodzielnie i nie masz bardzo solidnego zrozumienia tego zagadnienia. Z domowych wdrożeń, które widziałem w mojej karierze, nie przychodzi mi do głowy ani jedna, która nie miałaby katastrofalnych słabości, które można było łatwo wykorzystać, prowadząc w większości przypadków do całkowitego zerwania lub przynajmniej poważnego osłabienia

Poza tym, nawet jeśli masz umiejętności i wiedzę potrzebne do wykonania własnej implementacji, prawdopodobieństwo wystąpienia innych słabych punktów w stosunku do samej implementacji jest wysokie w przypadku takich rzeczy, jak ataki czasowe lub rzeczywiste błędy w implementacji, które mogą wyciek informacji bezpośrednio, nawet jeśli w idealnym przypadku wszystko działa poprawnie. W takich przypadkach nie jest tak, że osoby wdrażające muszą koniecznie lepiej je zrozumieć, ponieważ znacznie więcej osób użyło i przetestowało implementację, a znacznie więcej osób chce się upewnić, że jest bezpieczna.

Jeśli wdrożysz się sam, masz bardzo małą liczbę białych kapeluszy, które patrzą na to i potencjalnie dużą liczbę czarnych kapeluszy, więc masz przewagę liczebną wśród atakujących. Korzystając z dużej, często używanej implementacji, równoważy liczbę atakujących ją hakerów białych i czarnych kapeluszy, aby uzyskać bardziej wyrównaną mieszankę.

Chciałbym przedstawić nieco inną perspektywę ...

Nie jest tak, że nikt nie powinien nigdy wdrażać kryptografii. W końcu ktoś musi to zrobić. To po prostu niezwykle trudne zadanie i powinieneś zapytać, czy masz do dyspozycji niezbędne doświadczenie i zasoby.

Jeśli masz duże doświadczenie w odpowiednich dziedzinach matematyki i informatyki, silny zespół recenzentów, metodyczne i staranne testowanie we wszystkich środowiskach, jesteś na bieżąco z odpowiednią literaturą, rozumiesz pułapki projektowania i wdrażania, które są specyficzne dla kryptowalut ... to jasne, idź dalej i zaimplementuj kryptowaluty.

Cóż, to szybko się rozwinęło. Zdaję sobie sprawę, że nie będzie to popularne, ale jeśli myślisz, że wiesz, co robisz i dobrze rozumiesz język, którego używasz, i sposób, w jaki go używasz, być może bądź całkowicie bezpieczny, pisząc własną implementację niektórych prymitywów kryptograficznych.

Na przykład, jeśli sprawdzasz, czy hashe pasują do oczekiwanej wartości przed uruchomieniem jakiegoś oprogramowania układowego, implementacja algorytmu haszującego prawdopodobnie będzie w porządku. Osoba atakująca otrzymuje bardzo mało informacji zwrotnych, jeśli powiedzą, że niepoprawna wartość nie otrzymuje żadnej odpowiedzi.

Jednak rzadko zdarza się to w środowisku naturalnym, ponieważ istnieje już implementacja SHA256 w każdym języku, o którym myślisz: dlaczego skopiowałbyś to z kilkoma różnymi nazwami zmiennych. Dzieje się tak, gdy ktoś zdecyduje się być sprytny lub chce innego zachowania, albo nie rozumie niuansów (jak kanały boczne itp.).

Wydaje się, że społeczność myśli: mniej kowbojów jest lepszych, więc odstraszyć wszystkich. Może to być słuszne, ale myślę, że rady są łatwiejsze do zastosowania bez robienia uwag (takich jak nigdy nie wprowadzaj własnych), które wydają się zbyt gorliwe.

To powiedziawszy, łatwo o tym zapomnieć, chociaż wiesz dokładnie, kiedy nie rozumiesz większości rzeczy związanych z programowaniem, ponieważ nie działają one zgodnie z oczekiwaniami. Crypto zawsze działa zgodnie z oczekiwaniami w sensie „udzielił poprawnej odpowiedzi”. Jednak wiedza o tym, czego nie wiesz, że inni mogą o kryptowalutach, jest nietrywialnym zadaniem. To jest sposób myślenia, z którym ludzie mają trudności. Dlatego ludzie pytają „dlaczego nie mogę”, a nie „co jest nie tak z moim dowodem, że potrafię”.

Ogólnie rzecz biorąc, mam zamiar przyjąć postawę „jeśli musisz zapytać: nie” jest prawdopodobnie dla najlepszych. Ale to nie znaczy, że twój proces myślowy jest zły. Tylko tyle, że ci, którzy udzielają porad, nie mogą być naprawdę pewni, że tak nie jest.

Mówiąc prosto, starsze, szerzej używane oprogramowanie szyfrujące zostało poddane większej liczbie testów (przyjaznych i nieprzyjaznych) i większej analizie.

Ponadto historia szyfrowania jest zaśmiecona zepsutym oprogramowaniem, z których część został opracowany przez wybitnych ekspertów kryptografów.

Tak więc kody, do których możesz mieć największe zaufanie, to bardzo często kody, które istnieją od jakiegoś czasu.

Nie, i wydaje się, że jest to skierowane do laików jako ostrzeżenie, aby zostawić to lepszym.

Jeśli implementacja nie istnieje dla twojego języka, ktoś będzie musiał to zrobić. To nie jest tak, że nie będzie wystarczającej liczby przypadków testowych, a jeśli jesteś profesjonalistą, odbędzie się wzajemna ocena i dalsze testy.

Tak, musi być poprawna, ale jeśli jest to opublikowana (i wcześniej zaimplementowane w innych językach) to powinno być prawie standardowe.

Więc może nie powinieneś tego robić, ale oczywiście ktoś musi. Jeśli tego nie zrobisz, będziesz musiał wezwać coś innego, aby wypełnić swoją lukę, co nigdy nie jest pożądane.

Powinien być oczywiście napisany tak, aby specjalista ds. bezpieczeństwa mógł go rozpoznać po wizualnym „odcisku palca”.

Kolejny powód, który idzie w parze z wieloma innymi odpowiedziami, to fakt, że szyfrowanie jest dobre, jest trudne

Szyfrowanie dobrze jest drogie.

Problem z użyciem dobrze znanych, profesjonalnie zaimplementowanych algorytmów polega na tym, że do ochrony wiadomości wystarczy tylko klucz. Jeśli Evelyn może znaleźć (lub odgadnąć) klucz, wiadomość może zostać odszyfrowana.

Przed drugą wojną światową istniały dwa rodzaje maszyn kryptograficznych Enigmy - jedna do celów biznesowych, a druga do wojska. Wersja militarna, bardziej skomplikowana i solidna niż druga, była oczywiście nieosiągalna, ale każdy mógł się pojawić i kupić wersję biznesową. Kryptolodzy znaleźli jeden, zdemontowali go i przeanalizowali, a ostatecznie wymyślili, jak zbudować własną wersję wojskową. (To była główna przyczyna przegranej Niemiec.)

Aby zapewnić najlepszą ochronę, algorytm MUSI być utrzymywany w tajemnicy. Nie ma tam żadnych dobrze znanych tajnych algorytmów.

Teoretycznie można by budować maszyny, które są algorytmami i nie mają klucza. Po prostu uruchom go przez maszynę bez klucza i upewnij się, że Evelyn nigdy nie otrzyma kopii algorytmu. (Prawdopodobnie nie chciałbym tego robić sam).

Dla najlepszego bezpieczeństwa przepuściłbym tekst jawny przez mój własny niepublikowany algorytm , a następnie przez profesjonalnie zrealizowany. Jest to oczywiście możliwe tylko w przypadku niewielkiej liczby użytkowników „tylko na zaproszenie”; nie można go umieścić na GitHubie.

Musiałbyś uniknąć sytuacji, w której drugi (profesjonalnie zaimplementowany) proces zrobiłby coś niezabezpieczonego, jeśli jego dane wejściowe są już zaszyfrowane. Z drugiej strony, wiele prób złamania kodu działa na zasadzie wypróbowania każdego możliwego klucza i zatrzymania się, gdy pojawi się coś, co wygląda jak zwykły tekst. Ponieważ wynik tego procesu wymaga kolejnego kroku, zanim stanie się czytelny po ludzku, proces łamania kodu nie będzie wiedział, kiedy się zatrzymać.

IANAC, ale nigdy nie pozwoliłem, aby coś takiego mnie powstrzymało.