/dev/random

256-bajtowy zrzut szesnastkowy /dev/urandom

W systemach operacyjnych typu Unix /dev/random i /dev/urandom to specjalne pliki , które służą jako bezpieczne pod względem kryptograficznym generatory liczb pseudolosowych . Umożliwiają dostęp do szumu środowiskowego zebranego ze sterowników urządzeń i innych źródeł. /dev/random zazwyczaj blokowany , jeśli dostępna jest mniejsza entropia niż żądana; ostatnio (patrz poniżej, różne systemy operacyjne różnią się) zwykle blokuje się podczas uruchamiania, dopóki nie zostanie zebrana wystarczająca entropia, a następnie odblokowuje się na stałe. Urządzenie /dev/urandom zazwyczaj nigdy nie było urządzeniem blokującym, nawet jeśli źródło generatora liczb pseudolosowych nie zostało w pełni zainicjowane z entropią od czasu rozruchu. Nie wszystkie systemy operacyjne implementują te same metody dla /dev/random i /dev/urandom .

Linuks

Rngtest testuje pulę /dev/random

Generowanie liczb losowych w przestrzeni jądra zostało po raz pierwszy zaimplementowane w Linuksie w 1994 roku przez Theodore'a Ts'o . Implementacja używała bezpiecznych skrótów zamiast szyfrów , [ wymagane wyjaśnienie ] , aby uniknąć ograniczeń eksportu kryptografii , które obowiązywały, gdy generator był pierwotnie projektowany. Implementacja została również zaprojektowana z założeniem, że dowolny hash lub szyfr może ostatecznie okazać się słaby, więc projekt jest trwały w obliczu takich słabości. Szybkie odzyskiwanie po włamaniu do puli nie jest uważane za wymaganie, ponieważ wymagania dotyczące włamania do puli są wystarczające do znacznie łatwiejszych i bardziej bezpośrednich ataków na niepowiązane części systemu operacyjnego.

W implementacji Ts'o generator przechowuje oszacowanie liczby bitów szumu w puli entropii . Z tej puli entropii tworzone są liczby losowe. Podczas odczytu /dev/random zwróci tylko losowe bajty w ramach szacowanej liczby bitów szumu w puli entropii. Kiedy pula entropii jest pusta, odczyty z /dev/random będą blokowane , dopóki nie zostanie zebrany dodatkowy szum środowiskowy. Zamiarem jest służyć jako kryptograficznie bezpieczny generator liczb pseudolosowych , dostarczający dane wyjściowe z możliwie największą entropią. Jest to sugerowane przez autorów do wykorzystania w generowaniu kluczy kryptograficznych do ochrony o wysokiej wartości lub długoterminowej.

Odpowiednikiem /dev/random jest /dev/urandom („nieograniczone”/nieblokujące losowe źródło), które ponownie wykorzystuje pulę wewnętrzną do wytwarzania większej liczby pseudolosowych bitów. Oznacza to, że wywołanie nie zostanie zablokowane, ale dane wyjściowe mogą zawierać mniej entropii niż odpowiedni odczyt z /dev/random . Podczas gdy /dev/urandom jest nadal pomyślany jako generator liczb pseudolosowych odpowiedni do większości celów kryptograficznych, autorzy odpowiedniej strony man zauważają, że teoretycznie może istnieć jeszcze niepublikowany atak na algorytm używany przez /dev/urandom , a użytkownicy zaniepokojeni takim atakiem powinni zamiast tego użyć /dev/random . Jednak taki atak jest mało prawdopodobny, ponieważ gdy pula entropii jest nieprzewidywalna, nie powoduje wycieku bezpieczeństwa o zmniejszoną liczbę bitów.

Możliwe jest również pisanie do /dev/random . Pozwala to każdemu użytkownikowi mieszać losowe dane w puli. Dane nielosowe są nieszkodliwe, ponieważ tylko uprzywilejowany użytkownik może wydać ioctl potrzebny do zwiększenia oszacowania entropii. [ wątpliwe – dyskusja ] Bieżąca wielkość entropii i wielkość puli entropii jądra Linuksa, obie mierzone w bitach, są dostępne w /proc/sys/kernel/random/ i można je wyświetlić za pomocą polecenia cat /proc/sys/ odpowiednio kernel/random/entropy_avail i cat /proc/sys/kernel/random/poolsize .

Gutterman, Pinkas i Reinman w marcu 2006 roku opublikowali szczegółową analizę kryptograficzną generatora liczb losowych Linuksa, w której opisali kilka słabości. Być może najpoważniejszy problem, jaki zgłaszają, dotyczy wbudowanych lub Live CD , takich jak routery i klienci bezdyskowi , dla których stan rozruchu jest przewidywalny, a dostępna podaż entropii ze środowiska może być ograniczona. W przypadku systemu z pamięcią nieulotną zaleca się zapisanie pewnego stanu z RNG podczas zamykania, aby można go było włączyć do stanu RNG przy następnym uruchomieniu. W przypadku routera, dla którego ruch sieciowy stanowi główne dostępne źródło entropii, zauważają, że zapisywanie stanu po ponownym uruchomieniu „wymagałoby od potencjalnych atakujących podsłuchiwania całego ruchu sieciowego” od pierwszego uruchomienia routera lub uzyskania bezpośredni dostęp do stanu wewnętrznego routera. Zauważają, że ten problem jest szczególnie krytyczny w przypadku routera bezprzewodowego, którego ruch sieciowy można przechwytywać na odległość i który może wykorzystywać RNG do generowania kluczy do szyfrowania danych.

Jądro Linuksa zapewnia obsługę kilku sprzętowych generatorów liczb losowych , jeśli zostaną one zainstalowane. Surowe dane wyjściowe takiego urządzenia można uzyskać z /dev/hwrng .

W jądrze Linuksa 3.16 i nowszych jądro samo miesza dane ze sprzętowych generatorów liczb losowych w /dev/random na ruchomej skali w oparciu o definiowalną jakość oszacowania entropii HWRNG. Oznacza to, że do wykonania tego zadania nie jest potrzebny żaden demon przestrzeni użytkownika, taki jak rngd z rng-tools . W jądrze Linuksa 3.17+, VirtIO RNG został zmodyfikowany tak, aby miał domyślną jakość zdefiniowaną powyżej 0 i jako taki jest obecnie jedynym HWRNG domyślnie dodanym do / dev/random .

Pulę entropii można ulepszyć za pomocą programów takich jak timer_entropyd , haveged , randomsound itp. Dzięki rng-tools sprzętowe generatory liczb losowych , takie jak Entropy Key itp., mogą zapisywać do /dev/random . Zagorzałe programy testowe dieharder , diehard i ent mogą przetestować te generatory liczb losowych.

W styczniu 2014 roku Daniel J. Bernstein opublikował krytykę tego, jak Linux miesza różne źródła entropii. Przedstawia atak, w którym jedno źródło entropii zdolne do monitorowania innych źródeł entropii może zmodyfikować swoje wyjście, aby unieważnić losowość innych źródeł entropii. Rozważmy funkcję , w której jest funkcją mieszającą, a x , y z są źródłami entropii, przy czym wynikiem złośliwego działania opartego na procesorze H. ( y HRNG Z:

  1. Z generuje losową wartość r .
  2. Z oblicza .
  3. wynik żądanej r z _ _
  4. W przeciwnym razie powtórz, zaczynając od 1.

musiałby powtórzyć 16 razy Jest to możliwe, ponieważ Linux aktualizuje H na bieżąco, zamiast używać pojedynczego materiału siewnego wysokiej jakości.

W październiku 2016 r., Wraz z wydaniem jądra Linuksa w wersji 4.8, /dev/urandom jądra zostało przełączone na implementację kryptograficznego generatora liczb pseudolosowych (CPRNG) opartego na ChaCha20 autorstwa Theodore Ts'o , opartego na uznanym strumieniu Bernsteina szyfr ChaCha20 .

W 2020 r. jądro Linuksa w wersji 5.6 /dev/random blokuje się tylko wtedy, gdy CPRNG nie zostało zainicjowane. Po zainicjowaniu /dev/random i /dev/urandom zachowują się tak samo.

systemy BSD

System operacyjny FreeBSD udostępnia łącze /dev/urandom do / dev/random . Oba blokują tylko do momentu prawidłowego rozstawienia. Fortuna ) FreeBSD aktualizuje się regularnie i nie próbuje oszacować entropii. W systemie z niewielką aktywnością sieciową i dyskową ponowne umieszczanie odbywa się po ułamku sekundy.

Od OpenBSD 5.1 (1 maja 2012) /dev/random i /dev/arandom używały algorytmu opartego na RC4 , ale zmieniono ich nazwę na ARC4 ze względu na prawa własności intelektualnej. Podczas gdy generowanie liczb losowych wykorzystuje tutaj entropię systemową zebraną na kilka sposobów, algorytm ARC4 zapewnia odporność na awarie, zapewniając szybki i wysokiej jakości strumień liczb pseudolosowych, nawet gdy pula jest w stanie niskiej entropii. System automatycznie używa sprzętowych generatorów liczb losowych (takich jak te dostępne w niektórych koncentratorach Intel PCI), jeśli są one dostępne, poprzez OpenBSD Cryptographic Framework . Począwszy od OpenBSD 5.5 (1 maja 2014), arc4random() używane dla losowych urządzeń OpenBSD nie używa już ARC4, ale ChaCha20 ( nazwa arc4random może zostać ponownie rozważona jako A Replacement Call for Random ). /dev/arandom został usunięty w OpenBSD 6.3 (15 kwietnia 2018).

Implementacja starszego API arc4random() w NetBSD została również przeniesiona do ChaCha20.

macOS, iOS i inne systemy operacyjne Apple

Wszystkie systemy operacyjne Apple zostały przeniesione do Fortuny co najmniej od grudnia 2019 r., być może wcześniej. Opiera się na SHA-256 . Wykorzystywanych jest wiele źródeł entropii, takich jak bezpieczna enklawa RNG, jitter taktowania fazy rozruchu, przerwanie sprzętowe (zakładane taktowanie). RDSEED/RDRAND jest używany na komputerach Mac z procesorami Intel, które go obsługują. Dane początkowe (entropia) są również przechowywane do kolejnych ponownych uruchomień.

Przed zmianą macOS i iOS używały 160-bitowego Yarrowa opartego na SHA-1 .

Nie ma różnicy między /dev/random a /dev/urandom ; oba zachowują się identycznie.

Inne systemy operacyjne

/dev/random i /dev/urandom są również dostępne w systemach Solaris, NetBSD, Tru64 UNIX 5.1B, AIX 5.2 i HP-UX 11i v2. Podobnie jak w przypadku FreeBSD, AIX implementuje własny projekt oparty na Yarrow, jednak AIX wykorzystuje znacznie mniej źródeł entropii niż standardowa /dev/random i przestaje uzupełniać pulę, gdy uzna, że ​​zawiera wystarczającą ilość entropii.

W systemie Windows NT podobną funkcjonalność zapewnia ksecdd.sys , ale odczyt specjalnego pliku \Device\KsecDD nie działa tak, jak w systemie UNIX. Udokumentowane metody generowania kryptograficznie losowych bajtów to CryptGenRandom i RtlGenRandom . Program Windows PowerShell zapewnia dostęp do kryptograficznie bezpiecznego generatora liczb pseudolosowych za pośrednictwem polecenia cmdlet Get-Random .

Cygwin w systemie Windows zapewnia implementacje zarówno /dev/random, jak i /dev/urandom , których można używać w skryptach i programach.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=/dev/random&oldid=1133315917 ”