SP Reviewing The Standard. Stephan Müller atsec information security GmbH

Transcription

1 SP Reviewing The Standard Stephan Müller atsec information security GmbH 13 ICMC 2013, September 24-26, Gaithersburg, MD 13

2 Agenda Practical aspects of implementing SP800-90A Helpful Requirements Challenges Proposed solutions Vendor feedback Implications of mandatory SP800-90B Proposed solutions Example Linux /dev/random device ICMC , September 24-26, Gaithersburg, MD 13 2

3 SP800-90A Helpful Requirements Previous standards (e.g. X9.31 Appendix A2.4) only defined RBG core SP800-90A covers entire life cycle of DRBG including: Seed and seed period requirements Sanity checks Prediction resistance considerations Practical application of DRBG is clearer now ICMC , September 24-26, Gaithersburg, MD 13 3

4 SP800-90A Challenges Complexity of state maintenance DRBG is very high SP800-90A contains 80 pages of specification X9.31 is half a page Complexity implies large implementation Large implementation is not suitable for sensitive environments Operating System Kernel High assurance environments Example: LOCs DRBG core, Hash-DRBG, HMAC-DRBG, CTR-DRBG OpenSSL: 550, 320, 220, 380 Mozilla NSS Hash DRBG: 750 Mine: 470, 240, 90, 320 (compare with microkernel: 5000 LOCs) ICMC , September 24-26, Gaithersburg, MD 13 4

5 SP800-90A HMAC DRBG State State size equals to cryptographic strength of cipher Size of Key, V is blocksize of cipher Key t+1 =HMAC(Key t, V t 1 Seed t ) V t+1 =HMAC(Key t+1, V t ) State is maintained by cipher No complex logic for establishing K and V for next round Inefficiency: HMAC for Key t+1 and V t+1 is calculated twice Complexity is slightly higher than to X9.31 ICMC , September 24-26, Gaithersburg, MD 13 5

6 SP800-90A Hash DRBG State State maintenance (addition of C, details of hash generation skipped): 440/888 V t Hash t + V t = 0 State of Hash DRBG is larger than cipher strength Hash is surjective function where a larger state does not increase cryptographic strength of DRBG State transition is driven by DRBG controlled update Addition of complexity without gain ICMC , September 24-26, Gaithersburg, MD 13 6

7 SP800-90A CTR DRBG State Most complex DRBG state maintenance Due to bijective property of cipher, any size translation of buffers requires effort Seed, additional data, personality string have arbitrary lengths Data used as input to cipher in DF / BCC contains a number of static 0x00 bytes DF / BCC: Reduction and subsequent expansion of input data using interlocking loops DF / BCC seed input Cipher blocksize DRBG seed State maintenance re-implements Counter mode to XOR with seed ICMC , September 24-26, Gaithersburg, MD 13 7

8 SP800-90A Proposed Solutions HMAC DRBG: update of K, V only once per round Hash DRBG: Size of state equal to hash block length Use hash as state transition function can this state transition function be worse than the byte-wise addition? Effort for addition of buffers can be dropped Use HMAC DRBG approach as a template CTR DRBG: Use cipher as state transition function Only reduce input data size, never enlarge an already reduced size complexity of DF / BCC can be reduced Update of key and state is a result generally defined cipher operation (e.g. SP800-38A Counter mode) complexity of state management can be reduced ICMC , September 24-26, Gaithersburg, MD 13 8

9 Vendor Feedback Applicable to DRBG in detail and FIPS in general Giving the user a greater choice and preventing monocultures by certifying multiple ciphers per cipher class: Symmetric ciphers Hashes ECC curves especially consider suggestions by Braintrust to have users generate their own curves based on known algorithm and random seed and publish the seed for verification (a la PQG generation) ICMC , September 24-26, Gaithersburg, MD 13 9

10 Implications of mandating SP800-90B Mandating of quasi-inclusion of seed source into validation Modules implementing certifiable cipher mechanisms but have no leverage over seed-source vendors cannot be certified Validation of module is prevented Reduction of choice of validated mechanisms Solution: NIST specifies pre-approved seed mechanism implementations and their potential usage requirements Constant re-assessments of commonly used seed sources is inefficient ICMC 2013, September 24-26, Gaithersburg, MD

11 Example: Usage Requirements for Linux /dev/random Ensure proper seed maintenance on target system /dev/random must not be used on a number of hardware architectures (lack of get_cycles function) see NIST must specify whether /dev/urandom can be used Ensuring that sufficient entropy is present in /dev/random at the first time the module technically could read seed, e.g.: By mandating that /dev/random seed is generated during initial installation, By requiring user interaction on console Ensure that module reads data from /dev/random appropriately e.g. a simple read() system call is not sufficient due to EINTR ICMC 2013, September 24-26, Gaithersburg, MD