1. Random Number Generators for Cryptographic Applications (Part 1) Werner Schindler Federal Office for Information Security (BSI), Bonn Bonn, January 17, 2008

2. Schindler17.01.2008Slide 2 Outline (Part 1)  Introduction and motivation  General requirements on random number generators (RNGs)  RNG Classification  Characteristic properties and differences  Deterministic RNGs  Physical RNGs  Non-physical true RNGs

3. Schindler17.01.2008Slide 3 Random numbers are used...  as random session keys  to generate RSA prime factors  in DSA, ECDSA (ephemeral keys)  in zero-knowledge-proofs  in challenge-response-protocols  as IV vectors for block ciphers  by TPMs ...

4. Schindler17.01.2008Slide 4 Protocol information Cryptographic protocols usually demand...  „generate a random session key“  „generate a random prime“  „generate a random 64-bit challenge“ ...... but they do not specify the generation process.

5. Schindler17.01.2008Slide 5 What properties should random numbers possess? Usually, no clear requirements are specified. Unexpressed silent requirement: The random numbers should assume all admissible values with equal probability and should be independent from predecessors and successors. This yet characterizes an ideal random number generator.

6. Schindler17.01.2008Slide 6 Classification (I) RNG deterministicnon-deterministic (true) purehybrid purehybrid purehybrid physical non-physical

7. Schindler17.01.2008Slide 7 Classification (II)  Deterministic random number generators are also known as pseudorandom number generators.  Hybrid DRNGs and hybrid TRNGs contain design elements from both from deterministic and non- deterministic RNGs. Their security yet essentially is based upon on the deterministic, resp. on the non- deterministic part.

8. Schindler17.01.2008Slide 8 Example 1: Challenge-response mechanism smart cardterminal C := Enc(M;k C ) C = Enc(M;k C ) ? M C generates random number U M := U || time yes no STOP

9. Schindler17.01.2008Slide 9 Example 2: IV for a block cipher (CBC mode) T = B 1 || B 2 ||... AES k C 1... C 2 AES k || ||... plaintext IV The (pseudo-)randomly chosen IV is transmitted in clear.

10. Schindler17.01.2008Slide 10 Example 3: Simplified fragment of a key exchange protocol AliceBob generates message T generates random session key k rnd C :=AES(T;k rnd ) computes k rnd with d B decrypts C with k rnd k rnd e B (mod n B )|| C (d B,e B,n B ): Bob‘s RSA key

11. Schindler17.01.2008Slide 11 Requirements (I) Example 1: To prevent replay attacks random numbers U 1,U 2,... should be mutually distinct with overwhelming probability. (Depending on the full protocol and the application additional requirements may be necessary.) Example 2: The IVs should have similar statistical properties as output values from ideal RNGs (to prevent replay and correlation attacks).

12. Schindler17.01.2008Slide 12 Requirements (II) Is condition R1 sufficient for Example 3? R1: The random numbers should not show statistical weaknesses. Note: Condition R1 can be checked by statistical tests.

13. Schindler17.01.2008Slide 13 Example 3 (II) BobCharlesDick Eve Alice k rnd,4 e D (mod n D ) || C 4 k rnd,3 e C (mod n C ) || C 3 k rnd,2 e C (mod n C ) || C 2 k rnd,1 e B (mod n B ) || C 1

14. Schindler17.01.2008Slide 14 General Requirements (III) R2: The knowledge of subsequences of random numbers shall not allow to practically compute predecessors or successors or to guess them with non-negligibly larger probability than without knowledge of these subsequences (  privileged attacker Charles!).

15. Schindler17.01.2008Slide 15 Observation Requirement R2 is indispensable for sensitive applications (e.g. for the generation of session keys). The minimum requirements on the random numbers depend on the intended application !

16. Schindler17.01.2008Slide 16 Deterministic Random Number Generators (DRNGs)

17. Schindler17.01.2008Slide 17 Pure DRNG (schematic design) s 0 (seed) internal state snsn f : output function h : state transition function s n+1 :=h(s n ) h r n :=f(s n ) random number f

18. Schindler17.01.2008Slide 18 DRNGs: Advantages  no dedicated hardware required  software implementation  (required e.g. for stream ciphers): identical seeds yield identical random numbers  low costs

19. Schindler17.01.2008Slide 19 DRNGs: Disadvantages  For pure DRNGs the random numbers are completely determined by the seed.   Output sequences of DRNGs (pseudorandom numbers) cannot be truly independent. They can at most behave as output sequences of an ideal random number generator with regard to particular aspects.  The internal state has to be protected even if the device is not active.

20. Schindler17.01.2008Slide 20 DRNG: Design Note: In order to meet R2 (unpredictability of predecessors and successors)  the state transition function and / or the output function must be sufficiently complex.  it must be practically infeasible to guess the seed  Hence DRNGs are typically composed of cryptographic primitives (block ciphers, hash functions etc.).

21. Schindler17.01.2008Slide 21 Example 1 internal state: s n = (r n,k) s n+1 = (Enc (r n, k), k) =: (r n+1,k) (typical smart card design) Enc: block cipher (e.g. AES, Triple-DES) k: key (to be kept secret) (r n,k) rnrn (Enc(r n,k), k)

22. Schindler17.01.2008Slide 22 Example 1: Security evaluation (I)  Requirement R1:  A strong block cipher should not exhibit any statistical weaknesses.  Example 1 meets R1  Requirement R2: Assumption: The attacker knows r i,r i+1,…,r i+j  Task: Find r i+j+1 = Enc(r i+j,k):  Note that r i+1 = Enc(r i,k), …, r i+j = Enc(r i+j-1,k)  specific chosen-plaintext attack on Enc

23. Schindler17.01.2008Slide 23 Example 1: Security evaluation (II)  Goal: Find r i-1 = Enc -1 (r i,k):  Note that r i+j-1 = Enc -1 (r i+j,k), …, r i = Enc -1 (r i+1,k)  specific chosen-plaintext attack on Enc -1  If Enc and Enc -1 are secure against chosen- plaintext attacks the DRNG in Example 1 meets Requirement R2.  Example: Enc = AES, Enc = Triple-DES  Counterexample: Enc = DES.  This security proof is typical for DRNGs (= tracing back to recognised properties of well-known cryptographic primitives).

24. Schindler17.01.2008Slide 24 Attack Scenario An attacker learns the current internal state (e.g., by a successful hardware attack on a smart card or because he has access to the PC where the DRNG is implemented).  The attacker can easily compute all following random numbers. What about the preceding random numbers? If this attack scenario is realistic for the intended use of the DRNG it should additionally meet Requirement R3.

25. Schindler17.01.2008Slide 25 Requirements (IV) R3: It shall not be practically feasible to compute preceding random numbers from the internal state or to guess them with non-negligibly larger probability than without knowledge of the internal state. The DRNG from Example 1 does not meet R3 (decryption!) To meet R3 the state transition function h must be one-way (e.g., h = hash function)

26. Schindler17.01.2008Slide 26 Requirements (V) Occasionally, also Requirement R4 is desirable: R4: It shall not be practically feasible to compute future random numbers from the internal state or to guess them with non-negligible larger probability than without knowledge of the internal state.

27. Schindler17.01.2008Slide 27 Remark  Note: Requirement R4 can only be fulfilled by hybrid DRNGs (regular update of the internal state with random data).  R3 and R4 are DRNG-specific requirements. For physical RNGs R3 and R4 (as R1) usually follow “automatically” when R2 is fulfilled.

28. Schindler17.01.2008Slide 28 Remark  L. Dorrendorf, Z. Gutterman, B. Pinkas (2007) and Z. Gutterman, B. Pinkas, T. Reiman (2006) found weaknesses in the random number generators in Windows 2000 and Linux (/dev/urandom function, not /dev/random), respectively.  The source of these attacks was the violation of Requirement R3.

29. Schindler17.01.2008Slide 29 Cryptographically secure DRNGs  Cryptographically secure DRNGs are based upon intractability assumptions (e.g., factoring is hard). On basis of these intractability assumptions certain properties can be proved (e.g., next-bit security).  NOTE: Usually, only asymptotic security properties can be proved (i.e., for a whole family of DRNGs)  Examples: Blum-Blum-Shub-, RSA-, Rabin- pseudorandom bit generator

30. Schindler17.01.2008Slide 30 RSA pseudorandom generator  Setup: Select  distinct primes p,q; n=pq; and 1 < e <  (n)  the seed s 0 and keep p,q,s 0 secret  r n := s n (mod 2 q ) with q = 1 (basic version)  s n+1  s n e (mod n)  Note: Asymptotically, the exponent q can be enlarged to O(log(log n)).

31. Schindler17.01.2008Slide 31 Blum-Blum Shub DRNG  Setup: Select  distinct primes p, q with p,q  3 (mod 4); n=pq  the seed s 0 with gcd (s 0, n)=1 and keep these data secret  r n := s n (mod 2 q ) with q = 1 (basic version)  s n+1  s n 2 (mod n)  Note: Asymptotically, the exponent q can be enlarged to O(log(log n)).

32. Schindler17.01.2008Slide 32 Cryptographically secure DRNGs  Practical Relevance: Cryptographically secure DRNGs play little role in practice due to their low output rate.

33. Schindler17.01.2008Slide 33 Warning Warning Warning  Many pseudorandom number generators and several statistical test suites (Diehard test suite etc.) have been proposed in the literature for stochastic simulations.  This has often confused designers of cryptographic mechanisms who are not familiar with random number generators!  DRNGs which are fully appropriate for stochastic simulations may not even meet Requirement R1.

34. Schindler17.01.2008Slide 34 Physical Random Number Generators (PTRNGs)

35. Schindler17.01.2008Slide 35 PTRNG (schematic design) noise source analog digitised analog signal (das-random numbers) digital internal r.n. algorithmic postprocessing (optional; with or without memory) external r.n. external interface buffer (optional)

36. Schindler17.01.2008Slide 36 Noise source  The noise source is given by dedicated hardware.  The noise source exploits, for example,  noisy diodes  free-running oscillators  radioactive decay  quantum photon effects ...

37. Schindler17.01.2008Slide 37 Requirements R1 - R4  Requirement R1 can be checked with statistical tests.  If the internal random numbers are unpredictable the PTRNG will also meet R2.  Apart from exceptional designs R3 and R4 then are automatically fulfilled.  Entropy quantifies the „degree of uncertainty“.

38. Schindler17.01.2008Slide 38 Entropy (Shannon Entropy) Definition: Let X denote a random variable that assumes values in a finite set S = {s 1,...,s t }. The (Shannon) entropy of X is given by Remark: (i) 0  H(X)  log 2 | S | (ii) Shannon entropy is (maybe the most) important representative of a family of entropy definitions. H(X) =  Prob(X= s j )* log 2 (Prob(X=s j )) j=1 t _

39. Schindler17.01.2008Slide 39 Renyi Entropy For 0     the term H  (X) = log 2  Prob(X= s j )  j=1 t __ 1-  1 denotes the Renyi entropy of X to parameter . As a function of  the Rényi entropy is monotonously decreasing. The most important parameters are  = 1 (Shannon entropy) and  =  (or more precisely,    ; min- entropy). H  (X) = min {- log 2 (Prob(X=s j )) | j  t}

40. Schindler17.01.2008Slide 40 Remark (II)  For cryptographic applications the success probability for guessing attacks is a relevant figure.  Shannon entropy may differ significantly from the guess work:  Example: S = {0,1} 128, Prob((0,...,0))=2 -1 + 2 -129, Prob(x)=2 -129 for x  (0,...,0); H(X)= 1 + 64.5 = 65.5  The min entropy is the most conservative entropy measure.

41. Schindler17.01.2008Slide 41 Remark (II)  Usually, the computation of the min entropy is much more costly than the computation of the Shannon entropy.  However, for physical RNGs the Shannon entropy is yet appropriate (  Part 2)

42. Schindler17.01.2008Slide 42 Non-Physical True Random Number Generators (NPTRNGs)

43. Schindler17.01.2008Slide 43 NPTRNG (schematic design) entropy source random raw bits internal r.n. algorithmic postprocessing (with or without memory) external r.n. external interface buffer (optional)

44. Schindler17.01.2008Slide 44 Entropy source (I)  The entropy source is the pendant to the noise source of a PTRNG.  The entropy source typically exploits  user‘s interaction (e.g. key strokes, intermediate times between consecutive key strokes, mouse movement etc.)  system data (time, RAM data, thread number, handle, Windows API functions etc.)

45. Schindler17.01.2008Slide 45 Entropy source (II) Differences to noise sources:  - usually: (entropy / raw bit) is low  requires substantial compression of the raw data (  algorithmic postprocessing)  - usually: the entropy source is not under the control of the RNG designer (  prevents precise entropy estimation)  + no dedicated hardware required

46. Schindler17.01.2008Slide 46 Example 2: Non-physical true RNG The entropy source  interprets key strokes as 6 bit strings to generate 1020 random raw bits numbers  algorithmic postprocessing:  SHA-1(raw data)

47. Schindler17.01.2008Slide 47 Example 3: Non-physical true RNG The entropy source uses  the absolute time  time since system start  thread numbers  handles  RAM content to generate a string of 1024 raw bits. algorithmic postprocessing:  SHA-1(raw data)

48. Schindler17.01.2008Slide 48 Attacks The one-way property of SHA-1 suggests a typical attack on NPTRNGs:  guess the raw bit string  apply the postprocessing algorithm (SHA-1)  check the result (e.g. a session key)  The output of non-physical true RNGs may be used ‘directly’ or to seed / reseed DRNGs.

49. Schindler17.01.2008Slide 49 Evaluation of NPTRNGs: General advice  ignore consecutive strokes of the same key  the effective range of a k-bit API return value may contain considerably less than 2 k elements, and the values in the effective range may occur with different probabilities (  entropy defect)  for API functions that return time values consider  the time resolution of the system  the adversary’s knowledge (= preciseness of information)  consider dependencies between data strings (e.g.: absolute time, absolute time at system start, time since system start)  …

50. Schindler17.01.2008Slide 50 Outline (Part 2)  Design and evaluation criteria for physical RNGs  general advice  stochastic model  entropy  online tests, tot test, self test  AIS 31 and ISO 18031  Conclusion

51. Schindler17.01.2008Slide 51 Contact Federal Office for Information Security (BSI) Prof. Dr. Werner Schindler Godesberger Allee 185-189 53175 Bonn Tel: +49 (0)3018-9582-5652 Fax: +49 (0)3018-10-9582-5652 Werner.Schindler@bsi.bund.de www.bsi.bund.de www.bsi-fuer-buerger.de