NIST SP 800-90A: DRBG-standarder

Kryptografiske operationer kræver tilfældige tal af høj kvalitet: nøgleoprettelse, nonces, IV'er, salte og sessionstokens. Generatorer af ægte tilfældige tal (TRNG'er) indsamler entropi fra fysiske kilder (hardwarestøj, afbrydelser og termisk støj), men de er langsomme og ikke altid tilgængelige — især i virtuelle maskiner eller under tidlig opstart. Deterministiske generatorer af tilfældige bits (DRBG'er) løser dette: Initialisér en DRBG med en lille mængde ægte entropi, og brug en kryptografisk algoritme til at udvide den til en stor strøm af pseudotilfældige bits, der beregningsmæssigt ikke kan skelnes fra ægte tilfældighed. NIST SP 800-90A definerer tre godkendte DRBG-mekanismer, som bruges i stort set alle moderne kryptografiske implementeringer.

En DRBG fungerer gennem tre grundlæggende operationer. Instantiate: Initialisér DRBG'ens interne tilstand ved hjælp af entropy_input (fra en entropikilde), en nonce (en engangsværdi, der sikrer entydighed) og eventuelt en personalization_string (kontekst, der er specifik for applikationen). Generate: Frembring det ønskede antal pseudotilfældige bits, og opdatér den interne tilstand for at forhindre tilbagesporing. Reseed: Tilfør frisk entropi til DRBG-tilstanden for at give modstand mod forudsigelse — efter en ny forsyning med entropi kan selv en modstander, der kendte den tidligere tilstand, ikke forudsige fremtidig uddata. NIST angiver maksimale intervaller mellem nye forsyninger (reseed_interval): 2^48 anmodninger før en obligatorisk ny forsyning for alle tre DRBG-typer.

NIST SP 800-90A definerer fire niveauer for sikkerhedsstyrke: 112, 128, 192 og 256 bits. Sikkerhedsstyrken bestemmer den minimale entropi, der kræves ved instansiering, og kvaliteten af den genererede uddata. For 128-bit sikkerhed skal entropiinddataene indeholde mindst 128 bits entropi. Sammenhængen er: security_strength bits entropi -> DRBG-uddata, der beregningsmæssigt ikke kan skelnes fra tilfældighed af en modstander med 2^security_strength operationer. Valg af nøglelængde (AES-128 i forhold til AES-256) og hashfunktion (SHA-256 i forhold til SHA-512) skal matche eller overstige den ønskede sikkerhedsstyrke. Overdimensionering (SHA-512 til 128-bit sikkerhed) er sikkert, men spilder ressourcer; underdimensionering ødelægger sikkerheden.

Hash_DRBG vedligeholder to tilstandsværdier: V (en værdi, der genererer uddata) og C (en konstant, der føjes til under generering). Generate: hash_gen frembringer bits ved at gentage H(0x01 || V), H(0x01 || V+1), ... indtil der er tilstrækkelig uddata; derefter opdateres V med V = V + H(0x03 || V) + C + reseed_counter. Reseed: Bruger Hash_df (hashbaseret afledningsfunktion) til at kombinere den aktuelle V med frisk entropi og frembringe en ny V og C. Hash_DRBG er enkel at implementere og har en simpel sikkerhedsanalyse, hvilket gør den velegnet til miljøer med begrænsede ressourcer. NIST anbefaler instansiering med SHA-256 eller SHA-512. Hash_DRBG bruges i Javas SHA1PRNG (ældre) og OpenSSLs ældre DRBG.

HMAC_DRBG vedligeholder tilstanden (nøgle K, værdi V). Generate: Gentager V = HMAC(K, V), indtil der er frembragt tilstrækkelig uddata; derefter sættes K = HMAC(K, V || 0x00) og V = HMAC(K, V). Update: Tager additional_input og genforsyner K og V ved hjælp af HMAC-operationer. HMAC_DRBG har et klart sikkerhedsbevis baseret på HMAC-sikkerhed (PRF-antagelsen for HMAC). Det er den mest anbefalede DRBG: OpenSSL (siden 1.1.1), mbedTLS, wolfSSL og de fleste TLS-stakke bruger HMAC_DRBG. HMAC-konstruktionen sørger for indbygget blanding mellem efterfølgende kald, hvilket gør tilbagesporingsangreb sværere at udføre, selv hvis tilstanden delvist afsløres.

CTR_DRBG bruger et blokchiffer (AES) i tællermodus. Tilstand: nøgle K og tæller V. Generate: Krypterer efterfølgende tællerværdier E(K, V), E(K, V+1), ... og øger V. Update: Bruger Block_Cipher_df til at udlede ny K og V fra additional_input. CTR_DRBG er den hurtigste DRBG — AES-NI-hardwareacceleration gør den mange størrelsesordener hurtigere end hashbaserede DRBG'er på moderne processorer. Den er standard-DRBG'en i Windows CNG (CryptGenRandom bruger CTR_DRBG med AES-256), OpenSSL 3.0 (standard) og Linux-kernens tilfældighedsgenerator (getrandom-systemkaldet). CTR_DRBG's sikkerhed afhænger af, at AES er en pseudotilfældig permutation, hvilket understøttes solidt af årtiers analyse.

Modstand mod forudsigelse er en egenskab, hvor DRBG-uddata er uforudsigelig selv for en modstander, der tidligere har kompromitteret DRBG-tilstanden, forudsat at frisk entropi blandes ind via genforsyning. En DRBG med prediction_resistance_flag=true kalder entropikilden før hvert Generate-kald for at tilføre frisk entropi. Uden modstand mod forudsigelse gør en kompromittering af tilstanden på tidspunkt T det muligt at beregne al fremtidig uddata (den fremadrettede sikkerhed er brudt). Bagudrettet sikkerhed (også kaldet modstand mod tilbagesporing) betyder, at tidligere uddata er uforudsigelig, selv hvis den aktuelle tilstand er kendt — HMAC_DRBG og CTR_DRBG opnår dette via deres opdateringstrin, som udleder en ny nøgle fra den aktuelle tilstand efter hver Generate.

SP 800-90A angiver DRBG-algoritmerne, men ikke entropikilden. SP 800-90B definerer krav til entropikilder: Hardwarebaserede støjkilder skal karakteriseres og valideres, entropiberegninger skal være konservative, og sundhedstjek skal opdage fejl i entropikilder. SP 800-90C angiver, hvordan entropikilder kombineres med DRBG'er til komplette generatorer af tilfældige bits. Typiske entropikilder er CPU'ernes RDRAND/RDSEED (hardwarebaseret tilfældighedsgenerator, tilgængelig på Intel- og AMD-CPU'er siden 2012), operativsystemets entropi (/dev/urandom på Linux, BCryptGenRandom på Windows), hardware-sikkerhedsmoduler, TPM 2.0's tilfældighedsgenerator og omgivelsesstøj (diskadgangstider og variationer i netværksforsinkelse). Forhold med lav entropi (virtuelle maskiner og tidlig opstart) kræver særlig håndtering for at undgå svage initialværdier.

FIPS 140-3 (den aktuelle standard for validering af kryptografiske moduler) kræver NIST SP 800-90A-DRBG'er til al generering af tilfældige tal i certificerede moduler. Modulet skal: bruge en godkendt DRBG (Hash, HMAC eller CTR), initialiseres med entropi fra en godkendt entropikilde, der opfylder kravene i SP 800-90B, udføre selvtest ved opstart (POST) for at kontrollere DRBG-funktionen, implementere løbende RNG-tests (CRNGT), der opdager entropifejl, hvor værdien sidder fast på nul eller et, og understøtte genforsyning, når entropikilden angiver, at entropi er tilgængelig. HSM'er (Thales Luna, AWS CloudHSM og Utimaco), TLS-acceleratorkort og netværkskrypteringsenheder kræver ofte FIPS 140-3-validerede moduler, hvilket fremmer udbredelsen af SP 800-90A.

Moderne operativsystemer vedligeholder en DRBG på kerneniveau, som initialiseres med entropi fra hardwarekilder. Linux bruger en ChaCha20-baseret DRBG (siden kerne 5.17, hvor den erstattede det ældre Fortuna-lignende design), som initialiseres med RDRAND, afbrydelser samt disk- og netværkshændelser. /dev/urandom returnerer uddata fra DRBG'en og blokerer ikke, når den først er initialiseret. /dev/random blokerer, indtil der er tilstrækkelig entropi til rådighed (ældre adfærd, som for det meste er fjernet i nyere kerner). Systemkaldet getrandom(2) er den moderne grænseflade og blokerer kun under den tidlige opstart, før DRBG'en er initialiseret. Windows bruger CTR_DRBG (AES-256) i kernens RNG, som initialiseres fra TPM'en og hardwarehændelser. Programmer bør bruge operativsystemets DRBG via API'er på højt niveau i stedet for at initialisere deres egne DRBG'er ud fra tidsstempler eller PID'er.

Sårbarheder i DRBG'er fra virkeligheden skyldes implementeringsfejl snarere end svagheder ved algoritmen. (1) Utilstrækkelig initialisering: Initialisering udelukkende med det aktuelle tidsstempel eller PID'en giver angribere en startværdi, der kan gættes. (2) Manglende håndtering af forgreninger: Når en proces forgrener sig, deler moder- og underprocessen den samme DRBG-tilstand — de genererer identiske tilfældige tal. Løsning: Geninitialiser efter forgreningen (pthread_atfork eller et eksplicit getrandom-kald). (3) Genbrug af VM-snapshots: Hvis et VM-snapshot gendannes, vender DRBG-tilstanden tilbage til snapshottilstanden, så der genereres uddata, som allerede er set. Løsning: Tilfør unik entropi ved VM-opstart (VIRTIO RNG). (4) Stiltiende fejlslagne sundhedstests: En DRBG, der fortsætter med at generere uddata efter at have registreret en entropifejl, leverer uddata, som angriberen kan forudsige. (5) Genbrug af nonceværdier på tværs af DRBG-instanser.

NIST SP 800-90A definerer tre godkendte DRBG-mekanismer: Hash_DRBG (iterativ hashfunktion, enkel), HMAC_DRBG (HMAC-baseret, med et klart sikkerhedsbevis og bred udbredelse) og CTR_DRBG (AES i tællertilstand, hurtigst via AES-NI og standard i Windows/OpenSSL). De deler alle livscyklussen Instantiate/Generate/Reseed med en grænse for reseed_interval på 2^48. Sikkerhedsstyrken (112-256 bit) bestemmer entropikravene. Forudsigelsesmodstand kræver geninitialisering før hvert Generate-kald. FIPS 140-3 kræver DRBG'er fra SP 800-90A sammen med entropikilder fra SP 800-90B. Manglende håndtering af forgreninger, genbrug af VM-snapshots og utilstrækkelig initialisering er de vigtigste implementeringsfejl i virkelige systemer.