idnits 2.17.1 draft-irtf-cfrg-randomness-improvements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '... SHOULD apply this technique when in...' RFC 2119 keyword, line 141: '... Sig(sk, tag1) MUST NOT be used or e...' RFC 2119 keyword, line 142: '.... Moreover, Sig MUST be a determinist...' RFC 2119 keyword, line 147: '... Both tags SHOULD be generated such ...' RFC 2119 keyword, line 152: '...ons, tag strings SHOULD be constructed...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2018) is 2227 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Cremers 3 Internet-Draft L. Garratt 4 Intended status: Informational University of Oxford 5 Expires: September 24, 2018 S. Smyshlyaev 6 CryptoPro 7 N. Sullivan 8 Cloudflare 9 C. Wood 10 Apple Inc. 11 March 23, 2018 13 Randomness Improvements for Security Protocols 14 draft-irtf-cfrg-randomness-improvements-00 16 Abstract 18 Randomness is a crucial ingredient for TLS and related security 19 protocols. Weak or predictable "cryptographically-strong" 20 pseudorandom number generators (CSPRNGs) can be abused or exploited 21 for malicious purposes. The Dual EC random number backdoor and 22 Debian bugs are relevant examples of this problem. This document 23 describes a way for security protocol participants to mix their long- 24 term private key into the entropy pool(s) from which random values 25 are derived. This augments and improves randomness from broken or 26 otherwise subverted CSPRNGs. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 24, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Randomness Wrapper . . . . . . . . . . . . . . . . . . . . . 3 64 3. Tag Generation . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Application to TLS . . . . . . . . . . . . . . . . . . . . . 4 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 Randomness is a crucial ingredient for TLS and related transport 74 security protocols. TLS in particular uses Random Number Generators 75 (RNGs) to generate several values: session IDs, ephemeral key shares, 76 and ClientHello and ServerHello random values. RNG failures such as 77 the Debian bug described in [DebianBug] can lead to insecure TLS 78 connections. RNGs may also be intentionally weakened to cause harm 79 [DualEC]. In such cases where RNGs are poorly implemented or 80 insecure, an adversary may be able to predict its output and recover 81 secret Diffie-Hellman key shares that protect the connection. 83 This document proposes an improvement to randomness generation in 84 security protocols inspired by the "NAXOS trick" [NAXOS]. 85 Specifically, instead of using raw entropy where needed, e.g., in 86 generating ephemeral key shares, a party's long-term private key is 87 mixed into the entropy pool. In the NAXOS key exchange protocol, raw 88 entropy output x is replaced by H(x, sk), where sk is the sender's 89 private key. Unfortunately, as private keys are often isolated in 90 HSMs, direct access to compute H(x, sk) is impossible. An alternate 91 yet functionally equivalent construction is needed. 93 The approach described herein replaces the NAXOS hash with a keyed 94 hash, or pseudorandom function (PRF), where the key is derived from 95 raw entropy output and a private key signature. Implementations 96 SHOULD apply this technique when indirect access to a private key is 97 available and CSPRNG randomness guarantees are dubious, or to provide 98 stronger guarantees about possible future issues with the randomness. 100 2. Randomness Wrapper 102 Let x be the raw entropy output of a CSPRNG. When properly 103 instantiated, x should be indistinguishable from a random string of 104 length |x|. However, as previously discussed, this is not always 105 true. To mitigate this problem, we propose an approach for wrapping 106 the CSPRNG output with a construction that artificially injects 107 randomness into a value that may be lacking entropy. 109 Let PRF(k, m) be a cryptographic pseudorandom function, e.g., HMAC 110 [RFC2104], that takes as input a key k of length L and message m and 111 produces an output of length M. For example, when using HMAC with 112 SHA256, L and M are 256 bits. Let Sig(sk, m) be a function that 113 computes a signature of message m given private key sk. Let G be an 114 algorithm that generates random numbers from raw entropy, i.e., the 115 output of a CSPRNG. Let tag be a fixed, context-dependent string. 116 Let KDF be a key derivation function, e.g., HKDF-Extract [RFC5869] 117 (with first argument set to nil), that extracts a key of length L 118 suitable for cryptographic use. Lastly, let H be a cryptographic 119 hash function that produces output of length M. 121 The construction works as follows: instead of using x when randomness 122 is needed, use: 124 PRF(KDF(G(x) || H(Sig(sk, tag1))), tag2) 126 Functionally, this computes the PRF of a string (tag2) with a key 127 derived from the CSPRNG output and signature over a fixed string 128 (tag1). See Section 3 for details about how "tag1" and "tag2" should 129 be generated. The PRF behaves in a manner that is indistinguishable 130 from a truly random function from {0, 1}^L to {0, 1}^M assuming the 131 key is selected at random. Thus, the security of this construction 132 depends upon the secrecy of H(Sig(sk, tag1)) and G(x). If the 133 signature is leaked, then security reduces to the scenario wherein 134 the PRF provides only a wrapper to G(x). 136 In systems where signature computations are not cheap, these values 137 may be precomputed in anticipation of future randomness requests. 138 This is possible since the construction depends solely upon the 139 CSPRNG output and private key. 141 Sig(sk, tag1) MUST NOT be used or exposed beyond its role in this 142 computation. Moreover, Sig MUST be a deterministic signature 143 function, e.g., deterministic ECDSA [RFC6979]. 145 3. Tag Generation 147 Both tags SHOULD be generated such that they never collide with 148 another accessor or owner of the private key. This can happen if, 149 for example, one HSM with a private key is used from several servers, 150 or if virtual machines are cloned. 152 To mitigate collisions, tag strings SHOULD be constructed as follows: 154 o tag1: Constant string bound to a specific device and protocol in 155 use. This allows caching of Sig(sk, tag1). Device specific 156 information may include, for example, a MAC address. See 157 Section 4 for example protocol information that can be used in the 158 context of TLS 1.3. 160 o tag2: Non-constant string that includes a timestamp or counter. 161 This ensures change over time even if randomness were to repeat. 163 4. Application to TLS 165 The PRF randomness wrapper can be applied to any protocol wherein a 166 party has a long-term private key and also generates randomness. 167 This is true of most TLS servers. Thus, to apply this construction 168 to TLS, one simply replaces the "private" PRNG, i.e., the PRNG that 169 generates private values, such as key shares, with: 171 HMAC(HKDF-Extract(nil, G(x) || Sig(sk, tag1)), tag2) 173 Moreover, we fix tag1 to protocol-specific information such as "TLS 174 1.3 Additional Entropy" for TLS 1.3. Older variants use similarly 175 constructed strings. 177 5. IANA Considerations 179 This document makes no request to IANA. 181 6. Security Considerations 183 A security analysis was performed by two authors of this document. 184 Generally speaking, security depends on keeping the private key 185 secret. If this secret is compromised, the scheme reduces to the 186 scenario wherein the PRF provides only an outer wrapper on usual 187 CSPRNG generation. 189 The main reason one might expect the signature to be exposed is via a 190 side-channel attack. It is therefore prudent when implementing this 191 construction to take into consideration the extra long-term key 192 operation if equipment is used in a hostile environment when such 193 considerations are necessary. 195 The signature in the construction as well as in the protocol itself 196 MUST be deterministic: if the signatures are probabilistic, then with 197 weak entropy, our construction does not help and the signatures are 198 still vulnerable due to repeat randomness attacks. In such an 199 attack, the adversary might be able to recover the long-term key used 200 in the signature. 202 Under these conditions, applying this construction should never yield 203 worse security guarantees than not applying it assuming that applying 204 the PRF does not reduce entropy. We believe there is always merit in 205 analysing protocols specifically. However, this construction is 206 generic so the analyses of many protocols will still hold even if 207 this proposed construction is incorporated. 209 7. Normative References 211 [DebianBug] 212 Yilek, Scott, et al, ., "When private keys are public - 213 Results from the 2008 Debian OpenSSL vulnerability", n.d., 214 . 217 [DualEC] Bernstein, Daniel et al, ., "Dual EC - A standardized back 218 door", n.d., . 221 [NAXOS] LaMacchia, Brian et al, ., "Stronger Security of 222 Authenticated Key Exchange", n.d., 223 . 226 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 227 Hashing for Message Authentication", RFC 2104, 228 DOI 10.17487/RFC2104, February 1997, 229 . 231 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 232 Key Derivation Function (HKDF)", RFC 5869, 233 DOI 10.17487/RFC5869, May 2010, 234 . 236 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 237 Algorithm (DSA) and Elliptic Curve Digital Signature 238 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 239 2013, . 241 [X9.62] American National Standards Institute, ., "Public Key 242 Cryptography for the Financial Services Industry -- The 243 Elliptic Curve Digital Signature Algorithm (ECDSA). ANSI 244 X9.62-2005, November 2005.", n.d.. 246 Authors' Addresses 248 Cas Cremers 249 University of Oxford 250 Wolfson Building, Parks Road 251 Oxford 252 England 254 Email: cas.cremers@cs.ox.ac.uk 256 Luke Garratt 257 University of Oxford 258 Wolfson Building, Parks Road 259 Oxford 260 England 262 Email: luke.garratt@cs.ox.ac.uk 264 Stanislav Smyshlyaev 265 CryptoPro 266 18, Suschevsky val 267 Moscow 268 Russian Federation 270 Email: svs@cryptopro.ru 272 Nick Sullivan 273 Cloudflare 274 101 Townsend St 275 San Francisco 276 United States of America 278 Email: nick@cloudflare.com 279 Christopher A. Wood 280 Apple Inc. 281 One Apple Park Way 282 Cupertino, California 95014 283 United States of America 285 Email: cawood@apple.com