SESSION ID: PDAC-F03 Random Number Generation Is Getting Harder It s Time to Pay Attention Richard Moulds General Manager Whitewood Richard Hughes Laboratory Fellow (Retired) Los Alamos National Laboratory
All crypto security starts with random numbers Crypto security assumptions rely on keys being random, when patterns emerge (or are engineered) keys get more predictable Anything less than true randomness is a risk
But, there s a problem We need more and more randomness But, we are less and less sure we have enough entropy More and more crypto in use Longer and longer keys Increased key management scrutiny Tougher compliance Quantum threat Abstraction, containers and VMs Hosted and cloud environments Headless systems, no users Snap shots and replication Low power IoT devices
Hidden vulnerabilities and backdoors of choice
Basic requirements for randomness Uniformity: As many 1s as 0s, on average Independence: Each bit uncorrelated with all previous - statistical tests Diehard(er), NIST SP800-22 STS, TestU01 etc. These are necessary, but are not sufficient: π passes these tests 3.141592653589793238462643383279502884197169399375896 For cryptography, we also need - Compromise of one output must not compromise future or previous outputs Different outputs from each use
Unpredictability, irreproducibility requires entropy A hypothetical source of random numbers: Tossing a fair coin N times makes an N-bit random binary sequence (H=0, T=1) Example: 256 coin flips generate a 256-bit binary sequence Probability of a 256-bit output sequence x, is P x Unpredictability is quantified by entropy Min-entropy captures the probability that the output could be guessed in 1 trial But practical coin flips are biased: A bias of 51:49 is typical - i.e. not uniform How unpredictable? P. Diaconis et al., Dynamical Bias in the Coin Toss, SIAM Review 49, no.2, 211 (2007). 256 flips with a bias of 51:49 has H = 249 bits As unpredictable as 249 flips of a fair coin How to find entropy, quantify it, and use it to make a trusted, verifiable source of randomness for crypto?
Finally we have a standard (nearly) Specifying an entropy source is a complicated matter. This is partly due to confusion in the meaning of entropy, and partly due to the fact that, while other parts of an RBG design are strictly algorithmic, entropy sources depend on physical processes that may vary from one instance of a source to another. Recommendation for the Entropy Sources Used for Random Bit Generation (SP800-90B 2 nd draft) NIST January 2016 Constructions specify how entropy sources can be used to supply cryptographic randomness Assured randomness that s easy to use
NIST SP 800-90B entropy assessment A very general methodology Treats noise source as a black box Novel feature: entropy assessment Sequential and restart internal datasets Permutation testing to determine IID or non-iid Numerical entropy assessment tests Beyond statistical randomness tests Provides internal and external entropy scores Measured as bits of entropy per bit of output What entropy scores do present and future randomness sources have?
Why so complicated? Most random numbers come from the Operating System RANDOM NUMBER GENERATO R But software doesn t act randomly
Entropy - a long standing issue Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. (J. von Neumann, 1951)
Pseudo-random numbers an oxymoron? Entropy Source Random Seeds Operating System Pseudorandom number generator Random Numbers Crypto Application Shuffling the deck Dealing the deck
Where does entropy come from? Local Environment Host System Keyboards Mouse Clicks App1 App2 App3 Random Numbers Camera Entropy Pseudo-random number generator Operating System Microphone Entropy Antenna CPU Timing Network Timing Hard Drive Timing Hardware
But in a virtual world Local Environment Host System Keyboards Mouse Clicks App1 App2 App3 Random Numbers Camera Pseudo-random number generator Operating System Microphone Hypervisor Antenna CPU Timing Network Timing Hard Drive Timing Hardware
Random number generators in Linux Delivers random numbers only if sufficient entropy has been captured - otherwise it stops Delivers random numbers irrespective of how much entropy has been captured
Entropy sources in Linux Interrupt Events Timer Events (Disk activity, keyboard clicks and mouse movements etc.) Interrupt Entropy Pool (1024 bits) Main Entropy Pool (4096 bits) /dev/urandom PRNG /dev/random PRNG Check your entropy level with: cat /proc/sys/kernel/random/entropy_avail
Interrupt derived entropy in Linux Kernel IRQ handler adds data from interrupts into the Interrupt Pool Cycle Count & Kernel Timer (4 bytes) IRQ (4 bytes) Instruction Pointer (8 bytes) Cycles Kernel IRQ Instruction Pointer 123975895488 4294893898 14 18446744071578900000 123977123888 4294893898 14 18446744071578900000 123979445304 4294893898 18446744071578900000 123983781984 Entropy 4294893899 Score: 0.108 bits 14of entropy per 18446744071578900000 bit (non-iid) 123985083096 4294893899 14 18446744071578900000 123986825584 4294893899 14 18446744071578900000 123987250920 4294893899 14 18446744071578900000 Thanks to Adam Everspaugh - http://pages.cs.wisc.edu/~ace/
Disk derived entropy in Linux Timing of disk events is added directly to Input Pool Kernel Timer (4 bytes) Cycle Counter (4 bytes) Device ID (8 bytes) Kernel Timer Cycles Device ID 4294893055 114984099168 8388864 4294893055 114984867024 8388864 4294893055 114985479992 8388864 Entropy Score: 0.137 bits of entropy per bit (non-iid) 4294893055 114985942112 8388864 4294893060 115031476128 8388864 4294893060 115031907648 8388864 4294893060 115032263720 8388864 4294893060 115032643792 8388864 Thanks to Adam Everspaugh - http://pages.cs.wisc.edu/~ace/
Enhancing system entropy Goal: Generate true random numbers from a PRNG Good news - entropy is always additive Supplementary entropy source(s) Existing Applications PRNG e.g. /dev/random True random numbers Operating System Existing system entropy
Supplementary sources of entropy Three general approaches to improve entropy beyond the basic kernel: 1. Software daemons to more efficiently extract entropy for existing signals in interrupts State changes - HAVEGED (www.issihosts.com/haveged/) Timing Jitter CPU Jitter RNG (www.chronox.de/jent.html) Microphones and cameras audio-entropyd (www.vanheusden.com/aed/ and www.lavarnd.org/) 2. Local hardware based entropy sources (>0.99 bits of entropy per output bit?) Embedded CPU feature - e.g. Intel RdRand External or plug in devices - USB sticks, HSMs, PCI cards, etc. 3. Network based entropy sources and RNGs Random number services (https://random.org and https://beacon.nist.gov/home) Entropy as a Service (https://getnetrandom.com and https://entropy.ubuntu.com/
Comparing hardware RNGs Entropy or noise source Sample analog noise Digitize Remove sampling distortion (no entropy added) Post Processing Entropy extraction and whitening (no entropy added) Conditioning Random number outputs Noise sources Electrical noise Thermal noise Metastable circuits Ring oscillators Quantum fluctuations Health tests and entropy measurements Assessment criteria Quality of entropy source Verifiability of implementation Access to raw entropy for testing Data output rate Reliability of health tests Pseudo random number Generator Data rate expansion (no entropy added)
Comparison of supplementary entropy sources Jitter Daemons Embedded Hardware Sources Retrofit Hardware Sources Entropy as a Service Goal Low cost improvements Hardware/CPU differentiation Compliance and security Consistency and security Maturity Open source Mature Niche Emerging Advantages Low cost Low cost Speed Assurance Speed Consistency Assurance Barriers Hard to validate Hard to Manage Hard to validate Platform specific Inconvenient Cost Trust Immaturity
Summary Random numbers are critical for security but are often poorly understood and managed Random number generators are a point of attack and vulnerability potentially an invisible one Modern application environments present entropy challenges VMs, cloud and IoT Proving the operation and quality of entropy sources and random number generators goes beyond statistical tests - NIST SP 800-90B will help Supplementary sources of entropy can help and exist in various deployment models Random number generation should be a critical component of your key management strategy and datacenter infrastructure
Apply what you have learned today Next week you should: Identify applications that require true random numbers Think about entropy sources and their availability within your application environments In the first three months following this presentation you should: Consider supplementary entropy sources where risks of entropy starvation might exist Assess tools to test the quality of randomness in your organization Track the evolution (and finalization) of NIST SP 800-90 Within six months you should: Consider entropy management in data center infrastructure planning Consider entropy as part of any IoT strategy Make NIST standards certification a purchase criteria Define internal entropy validation and assurance policies
Thank you Questions? richard.moulds@whitewoodsecurity.com