Jak wiadomo, /dev/random, kryptograficznie odporny generator liczb pseudolosowych (CSPRNG), ma jeden problem — blokady. W tym artykule opisano, jak można go rozwiązać.
W ciągu ostatnich kilku miesięcy mechanizmy generowania liczb losowych w jądrze zostały nieco przetworzony, ale problemy w tym subsystemie były rozwiązane w szerszym Ostatnie zostały wprowadzone, aby zapobiec długotrwałej blokadzie wywołania systemowego getrandom() podczas uruchamiania systemu, ale podstawową przyczyną tego było zachowanie blokującego zbioru losowego. Ostatnia poprawka usunęłaby ten zbiornik, a oczekiwano, że trafi to do głównego jądra.
Andy Lutomirski opublikował trzecią wersję poprawki pod koniec grudnia. Wprowadza ona „dwa zasadnicze zmiany semantyczne w losowych API Linux”. Poprawka dodaje nowy znacznik GRND_INSECURE do wywołania systemowego getrandom() (chociaż Lutomirski odnosi się do niego jako getentropy(), które jest realizowane w glibc za pomocą getrandom() z ustalonymi znacznikami); ten znacznik sprawia, że wywołanie zawsze zwraca żądaną liczbę danych, ale bez gwarancji, że są to dane losowe. Jądro po prostu dołoży wszelkich starań, aby zapewnić najlepsze losowe dane, jakie ma w danym czasie. „Prawdopodobnie najlepiej byłoby nazwać to „INSECURE” (niesecure), aby zapobiec wykorzystaniu tego API do rzeczy, które wymagają bezpieczeństwa”.
Poprawki również usuwają blokujący zbiornik. Aktualnie jądro obsługuje dwa zbiory danych losowych, z których jeden odpowiada /dev/random, a drugi — /dev/urandom, jak opisano w tym z 2015 roku. Blokujący zbiór to zbiornik dla /dev/random; odczyt dla tego urządzenia będzie blokowany (ma na myśli swoją nazwę), aż system zbierze „wystarczającą” entropię, aby zaspokoić żądanie. Dalsze odczyty z tego pliku są również blokowane, jeśli w zbiorze brakuje entropii.
Usunięcie puli blokad oznacza, że odczyt z /dev/random działa jak getrandom() z flagą równą zeru (i zmienia flagę GRND_RANDOM w noop). Po zainicjowaniu kryptograficznego generatora liczb losowych (CRNG), odczyt z /dev/random oraz wywołania getrandom(…,0) nie spowodują blokady i zwrócą żądaną liczbę losowych danych.
Lutomirski mówi: „Uważam, że blokująca pula Linuxa straciła sens. CRNG Linuxa generuje dane wyjściowe, które są wystarczająco dobre, aby używać ich nawet do generacji kluczy. Blokująca pula nie jest już silniejsza w żadnym wymiernym sensie, a do jej utrzymania wymagane jest wiele infrastruktury wątpliwej wartości.”
Zmiany zostały wprowadzone z myślą o tym, aby istniejące programy rzeczywiście nie ucierpiały, a problemy z długim oczekiwaniem na takie rzeczy, jak generacja kluczy GnuPG, staną się mniejsze.
„Te zmiany nie powinny naruszać żadnych istniejących programów. /dev/urandom pozostaje nietknięte. /dev/random nadal blokuje się zaraz po uruchomieniu, ale blokuje się mniej niż wcześniej. getentropy() z istniejącymi flagami zwróci wynik, który będzie równie odpowiedni do celów praktycznych, jak wcześniej.”
Lutomirski zauważył, że wciąż pozostaje otwarta kwestia tego, czy jądro powinno dostarczać tak zwane „prawdziwe liczby losowe”, co w pewnym sensie miało robić blokujące jądro. Zauważa tylko jeden powód, dla którego to miałoby sens: „spełnianie standardów rządowych”. Lutomirski zasugerował, że jeśli jądro ma to zapewnić, to powinno to być zrealizowane za pomocą całkowicie innego interfejsu lub przeniesione do przestrzeni użytkownika, dając mu możliwość wydobywania surowych próbek zdarzeń, które mogłyby być wykorzystane do stworzenia takiej puli blokady.
Stephan Müller zasugerował, że jego zestaw Generator liczb losowych Linux (LRNG) (obecnie wydana wersja 26) może być sposobem na dostarczenie prawdziwych liczb losowych dla aplikacji, które tego potrzebują. LRNG "w pełni odpowiada wymaganiom 'Zalecenia dotyczące źródeł entropii stosowanych do generowania bitów losowych' SP800-90B", co czyni go rozwiązaniem problemu standardów państwowych.
Matthew Garrett sprzeciwiał się terminowi "prawdziwe dane losowe", zauważając, że wybrane urządzenia w zasadzie mogą być modelowane na tyle dokładnie, aby stały się przewidywalne: "nie wybieramy tutaj zdarzeń kwantowych".
Müller odpowiedział, że termin ten pochodzi z niemieckiego standardu AIS 31 do opisu generatora liczb losowych, który wydaje wynik „z taką samą prędkością, z jaką podstawowe źródło szumów produkuje entropię”.
Oprócz różnic w terminologii, posiadanie puli blokowania, jak to sugerują łatki LRNG, po prostu doprowadzi do różnych problemów, przynajmniej jeśli będzie dostępne bez przywilejów.
Jak powiedział Lutomski: „To nie rozwiązuje problemu. Jeśli dwóch różnych użytkowników uruchamia głupie programy, takie jak gnupg, po prostu będą się nawzajem wyczerpywać. Widzę, że obecnie istnieją dwa główne problemy z /dev/random: jest podatny na DoS (tzn. na wyczerpanie zasobów, złośliwy wpływ lub coś w tym stylu), i ponieważ nie wymaga żadnych przywilejów do użycia, jest również narażony na nadużycia. Gnupg jest błędne, to całkowity upadek. Jeśli dodamy nowy nieuprzywilejowany interfejs, z którego będą korzystać gnupg i podobne programy, znów przegramy”.
Müller zauważył, że dodanie getrandom() umożliwi teraz GnuPG korzystanie z tego interfejsu, ponieważ zapewni niezbędną gwarancję, że pula została zainicjowana. Na podstawie dyskusji z programistą GnuPG Wernerem Kochem Müller uważa, że gwarancja ta jest jedynym powodem, dla którego GnuPG obecnie czyta bezpośrednio z /dev/random. Ale jeśli istnieje nieuprzywilejowany interfejs, który jest podatny na odmowę usługi (jak dzisiaj /dev/random), to według Lutomirskiego, będzie on niewłaściwie używany przez niektóre aplikacje.
Teodor Tsao (Theodore Yue Tak Ts’o), twórca podsystemu liczb losowych w Linuksie, najwyraźniej zmienił zdanie na temat konieczności blokującej puli. Powiedział, że usunięcie tej puli pozwoli skutecznie pozbyć się idei, że Linux ma prawdziwy generator liczb losowych (TRNG): „to nie jest bezsensowne, ponieważ dokładnie to zawsze robiły *BSD".
Obawia się również, że zapewnienie mechanizmu TRNG będzie tylko wabikiem dla deweloperów aplikacji i uważa, że w rzeczywistości, biorąc pod uwagę różne typy sprzętu wspieranego przez Linux, niemożliwe jest zagwarantowanie TRNG w jądrze. Problem nie zostanie rozwiązany nawet przez możliwość pracy z urządzeniem tylko na podstawie uprawnień roota: „Programiści aplikacji wskazują, by ich aplikacja w celach bezpieczeństwa była zainstalowana jako root, ponieważ tylko w ten sposób można uzyskać dostęp do 'naprawdę dobrych' liczb losowych".
Müller zapytał, czy Cao nie zrezygnował z realizacji blokującej puli, którą sam dawno temu zaproponował. Cao odpowiedział, że planuje wziąć poprawki Lutomirskiego i aktywnie sprzeciwia się dodawaniu blokującego interfejsu z powrotem do jądra.
„Jądro nie może dać żadnych gwarancji co do tego, czy źródło szumów zostało odpowiednio scharakteryzowane. Jedyną rzeczą, którą może uzyskać deweloper GPG lub OpenSSL, jest mgliste poczucie, że TRUERANDOM jest „lepszy”, a ponieważ pragną większego bezpieczeństwa, niewątpliwie spróbują go użyć. W pewnym momencie zostanie zablokowany, a kiedy jakiś inny sprytny użytkownik (możliwe, że ekspert w wydawaniu dystrybucji) wstawi go do skryptu init, systemy przestaną działać, a użytkownicy zostaną pozostawieni z jedyną możliwość skarg na samego Linusa Torvaldsa.”
Cao opowiada się również za umożliwienie kryptografom oraz tym, którzy naprawdę potrzebują TRNG, sposobu zbierania swojej własnej entropii w przestrzeni użytkownika, aby mogli ją wykorzystać według własnego uznania. Mówi, że zbieranie entropii to nie jest proces, który może zostać zrealizowany przez jądro na wszelkiego rodzaju obsługiwanym przez nie sprzęcie, zresztą samo jądro nie może ocenić ilości entropii dostarczanej przez różne źródła.
„Rdzeń nie powinien mieszać różnych źródeł szumów, a z pewnością nie powinien próbować twierdzić, że wie, ile bitów entropii otrzymuje, gdy stara się grać w jakąś „nerwową grę entropii” na prostej do bólu architekturze CPU dla przypadków użytkowania IOT/Embedded, kiedy wszystko jest niesynchronizowane z pojedynczym generatorem master, kiedy nie ma żadnej instrukcji CPU do uporządkowania lub przena- nazwnia rejestrów itd.”
„Można mówić o udostępnieniu narzędzi, które próbują dokonać tych obliczeń, ale rzeczy te powinny odbywać się na sprzęcie każdego użytkownika, co dla większości użytkowników dystrybucji jest po prostu niepraktyczne. Jeśli ma to być przeznaczone tylko dla kryptografów, to niech będzie to zrealizowane w ich przestrzeni użytkownika. I nie róbmy prostszego GPG, OpenSSL itd., aby wszyscy mówili: „chcemy „prawdziwej losowości” i nie zgadzamy się na mniej”. Można mówić o tym, jak udostępniamy interfejsy kryptografom, aby mogli uzyskać potrzebne informacje dzięki dostępowi do podstawowych źródeł szumów, oddzielonych i nazwanych, a być może w jakiś sposób źródło szumów będzie mogło się uwierzytelnić w bibliotece lub aplikacji przestrzeni użytkownika.”
Zorganizowano małą dyskusję na temat tego, jak może wyglądać taki interfejs, ponieważ na przykład dla niektórych wydarzeń mogą istnieć konsekwencje w zakresie bezpieczeństwa. Cao zauważył, że kody skanowania klawiatury (czyli naciśnięcia klawiszy) są mieszane w pulę jako część zbierania entropii: „Przeniesienie tego do przestrzeni użytkownika, nawet przez przywilejowane wywołanie systemowe, byłoby co najmniej nierozsądne”. Całkiem możliwe, że inne czasy zdarzeń mogą stworzyć jakieś wycieki informacji przez kanały boczne.
W ten sposób, odnosimy wrażenie, że stara kwestia podsystemu liczb losowych w systemie Linux zmierza ku rozwiązaniu. Zmiany, jakie podsystem liczb losowych przeszedł w ostatnim czasie, w rzeczywistości prowadziły jedynie do problemów DoS podczas jego użytkowania. Teraz jednak pojawiły się skuteczne sposoby na uzyskanie najlepszych liczb losowych, jakie tylko może dostarczyć jądro. Jeśli jednak TRNG wciąż jest pożądane dla Linuxa, to tę wadę będzie trzeba w przyszłości usunąć, ale najprawdopodobniej nie zostanie to zrealizowane wewnątrz samego jądra.
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
