P

seudoRandom Number Generator (PRNG) jest wykorzystywany m.in. w narzędziach i programach kryptograficznych takich jak OpenSSL/TLS, czy OpenSSH. Nawet prosty program do symulacji rzutu kostką zależny jest od poziomu entropii, aby zapewnić dobrej jakości losowość wyników rzutów. W systemie Linux dostępne są dwa urządzenia do generowania losowości: /dev/random oraz /dev/urandom.

Najlepsze źródło losowości stanowi /dev/random, ponieważ jest urządzeniem blokującym, które będzie czekać, aż do wystarczająco dostępnego poziomu entropii, aby produkować dane wyjściowe. Zakładając, że poziom entropii jest wystarczający – urządzenie /dev/urandom również powinno dostarczać takiej samej jakości losowość. Jednakże jest to urządzenie nie blokujące i będzie produkować losowe dane nawet, gdy skończy się pula entropii. Może spowodować to obniżenie jakości danych losowych, czy nawet doprowadzić do ich powtórzeń. Wiele niedobrych rzeczy może się zdarzyć, gdy poziom entropii osiąga krytyczny poziom na serwerach produkcyjnych – szczególnie, gdy serwery te wykonują funkcje kryptograficzne.

Na przykład załóżmy, że nasze serwery wirtualne umieszczone w usłudze chmury wykorzystują protokoły https, starttls, ssh/sftp. Jeżeli jakikolwiek daemon obsługujący te protokoły będzie wymagać wygenerowania losowych danych, gdy wszystkie pule entropii zostały wyczerpane mogą powstać opóźnienia. Jeszcze gorszym scenariuszem będzie, gdy aplikacja ucieknie się do wykorzystania swojego losowego ziarnia utworzonego przy inicjalizacji lub do pomocy wykorzysta urządzenie /dev/urandom, aby uniknąć blokowania operacji. Może to realnie wpłynąć na integralność bezpiecznej komunikacji i zwiększyć szanse kryptoanalizy na prywatnych danych.

Dlaczego wspomniałem o maszynach wirtualnych? Linux potrafi generować dobrej jakości dane losowe z różnych źródeł sprzętowych, ale ponieważ wirtualne maszyny zazwyczaj nie posiadają klawiatury, myszy i innych urządzeń peryferyjnych – generują o wiele mniej entropii. Operacje I/O dysku i sieci stanowią większość źródeł dla tego rodzaju maszyn – niestety dostarczają mało “szumu”. Niewiele “bezgłowych” maszyn posiada dedykowane PRNG. Istnieje kilka rozwiązań działających w przestrzeni użytkownika w celu generowania dodatkowej entropii za pomocą przerwań sprzętowych z urządzeń, które są “głośniejsze” od dysków twardych i kart sieciowych – takie jak karty graficzne lub karty dźwiękowe. Niestety kolejnym problemem takich serwerów jest fakt, że w rolach hostingowych nie zawierają ani jednego ani drugiego.

Projekt HAVEGE (HArdware Volatile Entropy Gathering and Expansion) jest próbą zapewnienia prostego do użycia, nieprzewidywalnego generatora na podstawie algorytmu o tej samej nazwie. W skrócie można powiedzieć, że opierając się na czasie wykonywania kodu przez procesor (ponieważ jest to prawie niemożliwe, aby jeden kawałek kodu mógł mieć dokładnie taki sam czas – nawet uruchomiony w tym samym środowisku, na tym samym sprzęcie) używa różnic w rejestrze TSC zasilając /dev/random. Jeśli nie jesteśmy pewni, czy nasze maszyny wirtualne powinny skorzystać z tego rozwiązania powinniśmy odczytać:

cat /proc/sys/kernel/random/entropy_avail

Polecenie to pozwala na określenie ile entropii zebrał nasz serwer. Jeśli odczytana wartość jest mniejsza niż 1000 powinniśmy zainstalować daemona haveged. W przeciwnym razie może to negatywnie wpłynąć na aplikacje korzystające z kryptografii (nawet na działanie sieci Wi-Fi, jeśli stworzyliśmy programowy Access-Point). Przykład działania havegeda:

agresor@darkstar:~$ cat /proc/sys/kernel/random/entropy_avail
268
agresor@darkstar:~$ sudo apt-get install haveged
agresor@darkstar:~$ cat /proc/sys/kernel/random/entropy_avail
2160

Sprawdźmy teraz jak serwer radzi sobie z standardem FIPS-140-2:

root@darkstar:~# cat /dev/random | rngtest -c 1000
rngtest 4
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=470.202; avg=4981.355; max=3906250.000)Kibits/s
rngtest: FIPS tests speed: (min=2.249; avg=18.421; max=22.439)Mibits/s
rngtest: Program run time: 4957781 microseconds

Przy teście może wystąpić parę niepowodzeń, ale liczba udanych prób powinna utrzymywać się na poziomie 998 – 1000. Haveged wypełni z powrotem pulę entropii, gdy ta spadnie poniżej 1024 (parametr -w w /etc/default/haveged). Więc liczba entropy_avail będzie się wahać, ale nie powinna spaść poniżej 1000, chyba że nasz serwer ma naprawdę duże zapotrzebowanie na przypadkowość (cykliczne generowanie kluczy SSH w krótkim przedziale czasu itp.).

Więcej informacji: Ensuring Randomness with Linux’s Random Number Generator, Analysis of the Linux Pseudo-Random Number Generators