< draft-irtf-cfrg-randomness-improvements-05.txt   draft-irtf-cfrg-randomness-improvements-06.txt >
Network Working Group C. Cremers Network Working Group C. Cremers
Internet-Draft L. Garratt Internet-Draft CISPA Helmholtz Center for Information Security
Intended status: Informational University of Oxford Intended status: Informational L. Garratt
Expires: December 3, 2019 S. Smyshlyaev Expires: January 9, 2020 University of Oxford
S. Smyshlyaev
CryptoPro CryptoPro
N. Sullivan N. Sullivan
Cloudflare Cloudflare
C. Wood C. Wood
Apple Inc. Apple Inc.
June 01, 2019 July 08, 2019
Randomness Improvements for Security Protocols Randomness Improvements for Security Protocols
draft-irtf-cfrg-randomness-improvements-05 draft-irtf-cfrg-randomness-improvements-06
Abstract Abstract
Randomness is a crucial ingredient for TLS and related security Randomness is a crucial ingredient for TLS and related security
protocols. Weak or predictable "cryptographically-strong" protocols. Weak or predictable "cryptographically-strong"
pseudorandom number generators (CSPRNGs) can be abused or exploited pseudorandom number generators (CSPRNGs) can be abused or exploited
for malicious purposes. The Dual EC random number backdoor and for malicious purposes. The Dual EC random number backdoor and
Debian bugs are relevant examples of this problem. An initial Debian bugs are relevant examples of this problem. An initial
entropy source that seeds a CSPRNG might be weak or broken as well, entropy source that seeds a CSPRNG might be weak or broken as well,
which can also lead to critical and systemic security problems. This which can also lead to critical and systemic security problems. This
skipping to change at page 1, line 45 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 35 skipping to change at page 3, line 35
CSPRNG and able to observe all outputs of the proposed CSPRNG and able to observe all outputs of the proposed
construction, does not obtain any non-negligible advantage in construction, does not obtain any non-negligible advantage in
leaking the private key, modulo side channel attacks. leaking the private key, modulo side channel attacks.
3. If the CSPRNG is broken or controlled by adversary Adv, the 3. If the CSPRNG is broken or controlled by adversary Adv, the
output of the proposed construction remains indistinguishable output of the proposed construction remains indistinguishable
from random provided the private key remains unknown to Adv. from random provided the private key remains unknown to Adv.
2. Randomness Wrapper 2. Randomness Wrapper
Let x be the output of a CSPRNG. When properly instantiated, x The output of a properly instantiated CSPRNG should be
should be indistinguishable from a random string of x bytes. indistinguishable from a random string of the same length. However,
However, as previously discussed, this is not always true. To as previously discussed, this is not always true. To mitigate this
mitigate this problem, we propose an approach for wrapping the CSPRNG problem, we propose an approach for wrapping the CSPRNG output with a
output with a construction that mixes secret data into a value that construction that mixes secret data into a value that may be lacking
may be lacking randomness. randomness.
Let G(n) be an algorithm that generates n random bytes, i.e., the Let G(n) be an algorithm that generates n random bytes, i.e., the
output of a CSPRNG. Define an augmented CSPRNG G' as follows. Let output of a CSPRNG. Define an augmented CSPRNG G' as follows. Let
Sig(sk, m) be a function that computes a signature of message m given Sig(sk, m) be a function that computes a signature of message m given
private key sk. Let H be a cryptographic hash function that produces private key sk. Let H be a cryptographic hash function that produces
output of length M. Let Extract(salt, IKM) be a randomness output of length M. Let Extract(salt, IKM) be a randomness
extraction function, e.g., HKDF-Extract [RFC5869], which accepts a extraction function, e.g., HKDF-Extract [RFC5869], which accepts a
salt and input keying material (IKM) parameter and produces a salt and input keying material (IKM) parameter and produces a
pseudorandom key of length L suitable for cryptographic use. Let pseudorandom key of length L suitable for cryptographic use. Let
Expand(k, info, n) be a variable-length output PRF, e.g., HKDF-Expand Expand(k, info, n) be a variable-length output PRF, e.g., HKDF-Expand
skipping to change at page 4, line 29 skipping to change at page 4, line 29
construction depends upon the secrecy of H(Sig(sk, tag1)) and G(L). construction depends upon the secrecy of H(Sig(sk, tag1)) and G(L).
If the signature is leaked, then security of G'(n) reduces to the If the signature is leaked, then security of G'(n) reduces to the
scenario wherein randomness is expanded directly from G(L). scenario wherein randomness is expanded directly from G(L).
If a private key sk is stored and used inside an HSM, then the If a private key sk is stored and used inside an HSM, then the
signature calculation is implemented inside it, while all other signature calculation is implemented inside it, while all other
operations (including calculation of a hash function, Extract and operations (including calculation of a hash function, Extract and
Expand functions) can be implemented either inside or outside the Expand functions) can be implemented either inside or outside the
HSM. HSM.
Sig(sk, tag1) should only be computed once for the lifetime of the Sig(sk, tag1) need only be computed once for the lifetime of the
randomness wrapper, and MUST NOT be used or exposed beyond its role randomness wrapper, and MUST NOT be used or exposed beyond its role
in this computation. To achieve this, tag1 may have the format that in this computation. To achieve this, tag1 may have the format that
is not supported (or explicitly forbidden) by other applications is not supported (or explicitly forbidden) by other applications
using sk. using sk.
Sig MUST be a deterministic signature function, e.g., deterministic Sig MUST be a deterministic signature function, e.g., deterministic
ECDSA [RFC6979], or use an independent (and completely reliable) ECDSA [RFC6979], or use an independent (and completely reliable)
entropy source, e.g., if Sig is implemented in an HSM with its own entropy source, e.g., if Sig is implemented in an HSM with its own
internal trusted entropy source for signature generation. internal trusted entropy source for signature generation.
In systems where signature computations are expensive, Sig(sk, tag1) Because Sig(sk, tag1) can be cached, the relative cost of using G'(n)
may be cached. In that case the relative cost of using G'(n) instead instead of G(n) tends to be negligible with respect to cryptographic
of G(n) tends to be negligible with respect to cryptographic
operations in protocols such as TLS. A description of the operations in protocols such as TLS. A description of the
performance experiments and their results can be found in the performance experiments and their results can be found in the
appendix of [SecAnalysis]. appendix of [SecAnalysis].
Moreover, the values of G'(n) may be precomputed and pooled. This is Moreover, the values of G'(n) may be precomputed and pooled. This is
possible since the construction depends solely upon the CSPRNG output possible since the construction depends solely upon the CSPRNG output
and private key. and private key.
3. Tag Generation 3. Tag Generation
skipping to change at page 5, line 21 skipping to change at page 5, line 21
To mitigate collisions, tag strings SHOULD be constructed as follows: To mitigate collisions, tag strings SHOULD be constructed as follows:
o tag1: Constant string bound to a specific device and protocol in o tag1: Constant string bound to a specific device and protocol in
use. This allows caching of Sig(sk, tag1). Device specific use. This allows caching of Sig(sk, tag1). Device specific
information may include, for example, a MAC address. To provide information may include, for example, a MAC address. To provide
security in the cases of usage of CSPRNGs in virtual environments, security in the cases of usage of CSPRNGs in virtual environments,
it is RECOMMENDED to incorporate all available information it is RECOMMENDED to incorporate all available information
specific to the process that would ensure the uniqueness of each specific to the process that would ensure the uniqueness of each
tag1 value among different instances of virtual machines tag1 value among different instances of virtual machines
(including ones that were cloned or recovered from snapshots). It (including ones that were cloned or recovered from snapshots).
is needed to address the problem of CSPRNG state cloning (see This is needed to address the problem of CSPRNG state cloning (see
[RY2010]). See Section 4 for example protocol information that [RY2010]). See Section 4 for example protocol information that
can be used in the context of TLS 1.3. can be used in the context of TLS 1.3.
o tag2: Non-constant string that includes a timestamp or counter. o tag2: Non-constant string that includes a timestamp or counter.
This ensures change over time even if outputs of G(L) were to This ensures change over time even if outputs of G(L) were to
repeat. It MUST be implemented such that its values never repeat. repeat. It MUST be implemented such that its values never repeat.
This means, in particular, that timestamp is guaranteed to change This means, in particular, that timestamp is guaranteed to change
between two requests to CSPRNG (otherwise counters should be between two requests to CSPRNG (otherwise counters should be
used). used).
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Elliptic Curve Digital Signature Algorithm (ECDSA). ANSI Elliptic Curve Digital Signature Algorithm (ECDSA). ANSI
X9.62-2005, November 2005.", n.d.. X9.62-2005, November 2005.", n.d..
[X962] "Public Key Cryptography for the Financial Services [X962] "Public Key Cryptography for the Financial Services
Industry -- The Elliptic Curve Digital Signature Algorithm Industry -- The Elliptic Curve Digital Signature Algorithm
(ECDSA), ANSI X9.62-2005, November 2005.", n.d., <American (ECDSA), ANSI X9.62-2005, November 2005.", n.d., <American
National Standards Institute>. National Standards Institute>.
Authors' Addresses Authors' Addresses
Cas Cremers Cas Cremers
University of Oxford CISPA Helmholtz Center for Information Security
Wolfson Building, Parks Road Saarland Informatics Campus
Oxford Saarbruecken
England Germany
Email: cas.cremers@cs.ox.ac.uk Email: cremers@cispa.saarland
Luke Garratt Luke Garratt
University of Oxford University of Oxford
Wolfson Building, Parks Road Wolfson Building, Parks Road
Oxford Oxford
England England
Email: luke.garratt@cs.ox.ac.uk Email: luke.garratt@cs.ox.ac.uk
Stanislav Smyshlyaev Stanislav Smyshlyaev
 End of changes. 10 change blocks. 
23 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/