/dev/random, bezpieczny kryptograficznie generator liczb pseudolosowych (CSPRNG), ma jeden irytujący problem: blokowanie. W tym artykule wyjaśniono, jak rozwiązać ten problem.
W ciągu ostatnich kilku miesięcy funkcje generowania liczb losowych w jądrze zostały nieco przerobione, ale problemy w tym podsystemie zostały rozwiązane w trakcie szerszego . Najbardziej zostały wprowadzone, aby zapobiec blokowaniu wywołania systemowego getrandom() przez długi czas podczas uruchamiania systemu, ale podstawową przyczyną tego było blokujące zachowanie puli losowej. Niedawna łatka usunęłaby tę pulę i można było oczekiwać, że skieruje się w stronę głównego rdzenia.
Pod koniec grudnia Andy Lutomirski opublikował trzecią wersję łatki. On przyczynia się „dwie główne zmiany semantyczne w losowych interfejsach API systemu Linux”. Łatka dodaje nową flagę GRND_INSECURE do wywołania systemowego getrandom() (chociaż Lutomirsky nazywa to getentropy(), które jest zaimplementowane w glibc przy użyciu getrandom() ze stałymi flagami); ta flaga powoduje, że wywołanie zawsze zwraca żądaną ilość danych, ale bez gwarancji, że dane są losowe. Jądro po prostu zrobi wszystko, co w jego mocy, aby wygenerować najlepsze losowe dane, jakie posiada w danym momencie. „Prawdopodobnie najlepiej będzie nazwać to «NIEBEZPIECZNYM» (niebezpieczne), aby zapobiec używaniu tego interfejsu API do celów wymagających bezpieczeństwa. ”
Łatki usuwają również pulę blokującą. Jądro utrzymuje obecnie dwie losowe pule danych, jedną odpowiadającą /dev/random i drugą /dev/urandom, jak opisano w tym 2015. Pula blokująca to pula dla /dev/random; odczyty dla tego urządzenia zostaną zablokowane (co oznacza jego nazwę), dopóki z systemu nie zostanie zebrana „wystarczająca” entropia, aby spełnić żądanie. Dalsze odczyty z tego pliku są również blokowane, jeśli w puli nie ma wystarczającej entropii.
Usunięcie puli blokad oznacza, że odczyt z /dev/random zachowuje się jak getrandom() z flagami ustawionymi na zero (i zamienia flagę GRND_RANDOM w noop). Po zainicjowaniu kryptograficznego generatora liczb losowych (CRNG) odczyt z /dev/random i wywołania getrandom(...,0) nie będą blokowane i zwrócą żądaną ilość losowych danych.
Lutomirski mówi: „Uważam, że pula blokująca Linuksa stała się przestarzała. CRNG Linux generuje dane wyjściowe, które są wystarczająco dobre, aby można je było wykorzystać nawet do generowania kluczy. Pula blokująca nie jest silniejsza w żadnym sensie materialnym i do jej wsparcia wymaga dużej infrastruktury o wątpliwej wartości.”
Zmiany wprowadzono w celu zapewnienia, że nie będzie to miało rzeczywistego wpływu na istniejące programy i że w rzeczywistości będzie mniej problemów związanych z długim oczekiwaniem na takie rzeczy, jak wygenerowanie klucza GnuPG.
„Te odcinki nie mogą zakłócać istniejących programów. /dev/urandom pozostaje niezmieniony. /dev/random nadal blokuje natychmiast po uruchomieniu, ale blokuje mniej niż wcześniej. getentropy() z istniejącymi flagami zwróci wynik, który jest tak samo odpowiedni do celów praktycznych, jak poprzednio.
Lutomirsky zauważył, że wciąż otwartym pytaniem jest, czy jądro powinno dostarczać tzw. „prawdziwe liczby losowe”, co w pewnym stopniu miało robić jądro blokujące. Widzi ku temu tylko jeden powód: „przestrzeganie standardów rządowych”. Lutomirsky zasugerował, że gdyby jądro miało to zapewniać, powinno to odbywać się poprzez zupełnie inny interfejs lub zostać przeniesione do przestrzeni użytkownika, umożliwiając użytkownikowi pobranie surowych próbek zdarzeń, które można wykorzystać do stworzenia takiej puli blokad.
Stephan Müller zasugerował, że jego zestaw dla Linux Random Number Generator (LRNG) (obecnie wydana wersja 26) może być sposobem na zapewnienie prawdziwych liczb losowych dla aplikacji, które tego potrzebują. LRNG jest „w pełni zgodny z wytycznymi SP800-90B dotyczącymi źródeł entropii używanych do generowania losowych bitów”, co czyni go rozwiązaniem problemu standardów rządowych.
Matthew Garrett sprzeciwił się określeniu „prawdziwie dane losowe”, zauważając, że pobrane urządzenia można w zasadzie modelować na tyle precyzyjnie, aby były przewidywalne: „nie próbkujemy tutaj zdarzeń kwantowych”.
Müller odpowiedział, że termin ten pochodzi z niemieckiej normy AIS 31 i opisuje generator liczb losowych, który generuje wynik jedynie „w takim samym tempie, w jakim podstawowe źródło szumu wytwarza entropię”.
Pomijając różnice terminologiczne, posiadanie puli blokad sugerowanej w łatkach LRNG będzie po prostu prowadzić do różnych problemów, przynajmniej jeśli dostęp do niej będzie możliwy bez uprawnień.
Jak powiedział Lutomirski: „To nie rozwiązuje problemu. Jeśli dwóch różnych użytkowników uruchomi głupie programy, takie jak gnupg, po prostu wyczerpią się nawzajem. Widzę, że obecnie istnieją dwa główne problemy z /dev/random: jest on podatny na DoS (tj. wyczerpywanie zasobów, złośliwy wpływ lub coś podobnego), a ponieważ do korzystania z niego nie są wymagane żadne uprawnienia, jest również podatny na nadużycia. Gnupg się myli, to kompletna porażka. Jeśli dodamy nowy, nieuprzywilejowany interfejs, z którego będzie korzystał gnupg i podobne programy, ponownie przegramy.”
Mueller zauważył, że dodanie funkcji getrandom() umożliwi teraz GnuPG korzystanie z tego interfejsu, ponieważ zapewni niezbędną gwarancję, że pula została zainicjowana. Na podstawie rozmów z programistą GnuPG Wernerem Kochem Mueller uważa, że gwarancja jest jedynym powodem, dla którego GnuPG obecnie czyta bezpośrednio z /dev/random. Jeśli jednak istnieje nieuprzywilejowany interfejs, który jest podatny na odmowę usługi (jak ma to miejsce obecnie w /dev/random), Lutomirsky argumentuje, że niektóre aplikacje będą go niewłaściwie wykorzystywać.
Wygląda na to, że Theodore Yue Tak Ts'o, twórca podsystemu liczb losowych w Linuksie, zmienił zdanie na temat potrzeby stworzenia puli blokującej. Powiedział, że usunięcie tej puli skutecznie pozbyłoby się poglądu, że Linux ma prawdziwy generator liczb losowych (TRNG): „To nie jest nonsens, ponieważ dokładnie to zawsze robiło *BSD”.
Obawia się również, że udostępnienie mechanizmu TRNG będzie po prostu przynętą dla twórców aplikacji i uważa, że tak naprawdę, biorąc pod uwagę różne typy sprzętu obsługiwanego przez Linuksa, nie da się zagwarantować TRNG w jądrze. Nawet możliwość pracy ze sprzętem tylko z uprawnieniami roota nie rozwiąże problemu: „Twórcy aplikacji określają, że ze względów bezpieczeństwa ich aplikacja powinna być instalowana jako root, więc tylko w ten sposób można uzyskać dostęp do„ naprawdę dobrych ” liczb losowych”.
Mueller zapytał, czy Cao zrezygnował z zaproponowanego przez siebie od dawna wdrożenia puli blokującej. Cao odpowiedział, że planuje pobrać łatki Lutomirsky'ego i aktywnie sprzeciwia się dodaniu z powrotem interfejsu blokującego do jądra.
„Jądro nie może zagwarantować, że źródło hałasu zostało prawidłowo scharakteryzowane. Jedyne, co może uzyskać programista GPG lub OpenSSL, to niejasne poczucie, że TRUERANDOM jest „lepszy”, a ponieważ chce większego bezpieczeństwa, niewątpliwie będzie próbował z niego skorzystać. W pewnym momencie zostanie zablokowany, a gdy jakiś inny mądry użytkownik (być może specjalista ds. dystrybucji) wstawi go do skryptu inicjującego i systemy przestaną działać, użytkownicy będą musieli jedynie złożyć skargę do samego Linusa Torvaldsa.
Cao opowiada się również za umożliwieniem kryptografom i tym, którzy faktycznie potrzebują TRNG, gromadzenia własnej entropii w przestrzeni użytkownika do wykorzystania według własnego uznania. Mówi, że zbieranie entropii nie jest procesem, który może wykonać jądro na każdym obsługiwanym przez siebie sprzęcie, ani samo jądro nie jest w stanie oszacować wielkości entropii dostarczanej przez różne źródła.
„Jądro nie powinno mieszać ze sobą różnych źródeł szumu, a już na pewno nie powinno próbować twierdzić, że wie, ile bitów entropii otrzymuje, próbując zagrać w jakąś „grę o drgającej entropii” na skandalicznie prostym procesorze architektura dla użytkowników konsumenckich. Przypadki IOT/embedded, w których wszystko nie jest zsynchronizowane z pojedynczym oscylatorem głównym, gdzie nie ma instrukcji procesora umożliwiającej zmianę kolejności lub zmianę nazwy rejestru itp.
„Można mówić o udostępnieniu narzędzi, które będą próbowały wykonywać takie obliczenia, ale takie rzeczy trzeba robić na sprzęcie każdego użytkownika, co jest po prostu niepraktyczne dla większości użytkowników dystrybucji. Jeśli jest to przeznaczone wyłącznie dla kryptografów, pozwól, aby zostało to zrobione w ich przestrzeni użytkownika. I nie upraszczajmy GPG, OpenSSL itp., aby wszyscy mówili: „chcemy „prawdziwej losowości” i nie zadowalamy się mniej. Możemy porozmawiać o tym, w jaki sposób zapewniamy interfejsy kryptografom, aby mogli uzyskać potrzebne informacje poprzez dostęp do głównych źródeł szumu, oddzielonych i nazwanych, a być może w jakiś sposób źródło szumu może uwierzytelnić się w bibliotece lub aplikacji przestrzeni użytkownika.
Odbyła się dyskusja na temat tego, jak mógłby wyglądać taki interfejs, ponieważ na przykład niektóre zdarzenia mogą mieć wpływ na bezpieczeństwo. Cao zauważył, że kody skanowania klawiatury (tj. naciśnięcia klawiszy) są mieszane w puli w ramach gromadzenia entropii: „Wprowadzenie tego do przestrzeni użytkownika, nawet poprzez uprzywilejowane wywołanie systemowe, byłoby co najmniej nierozsądne”. Jest całkiem możliwe, że inny harmonogram wydarzeń może spowodować pewnego rodzaju wyciek informacji kanałami bocznymi.
Wygląda więc na to, że długotrwały problem z podsystemem liczb losowych w Linuksie jest na dobrej drodze do rozwiązania. Zmiany, jakie ostatnio przeszedł podsystem liczb losowych, w rzeczywistości spowodowały jedynie problemy DoS podczas jego używania. Obecnie istnieją skuteczne sposoby uzyskania najlepszych liczb losowych, jakie może zapewnić jądro. Jeśli TRNG jest nadal pożądane w systemie Linux, wówczas tę wadę trzeba będzie naprawić w przyszłości, ale najprawdopodobniej nie zostanie to zrobione w samym jądrze.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com