TLS and NIST'S Policy on Hash Functions

NIST'S Policy on Hash Functions


March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.

TLS specifics of hash functions


  1. MAC constructionsA number of operations in the TLS record and handshake layer require a keyed Message Authentication Code (MAC) to protect message integrity or to construct key derivation functions.
    For TLS 1.0 and 1.1, the construction used is known as HMAC; TLS 1.2 still use HMAC, but it also decalares that "Other cipher suites MAY define their own MAC constructions, if needed."

  2. HMAC at handshakingHMAC can be used with a variety of different hash algorithms. However, TLS 1.0 and TLS 1.1 use it in the handshaking with two different algorithms, MD5(HMAC_MD5) and SHA-1(HMAC-SHA). Additionla hash algorithm can be defined by cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for TLS 1.0 and TLS 1.1.
    TLS 1.2 move away from the hard coded MD5 and SHA-1, SHA-256 is the default hash function for all cipher suites defined in TLS 1.2, TLS 1.1, TLS 1.0 when TLS 1.2 is negotiated. TLS 1.2 also declares that "New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function", which means that the hash functions used at handshakeing should be SHA-256 at least.

  3. HMAC at protecting recordFor the HMAC operations used to protect record data, the hash funtion is defined by cipher suites. For example, the HMAC's hash function of cipher suite TLS_RSA_WITH_NULL_MD5 is MD5.
    TLS 1.0 and TLS 1.1 define three hash functions for HMAC, they are:
    • null
    • MD5
    • SHA1
    From TLS 1.2, new cipher suites may define their own MAC constructions except the default HMAC. TLS 1.2 defines five MAC algorithms, from the literal, it is straight forward to know the hash function used.
    • null
    • hmac_md5
    • hmac_sha1
    • hmac_sha256
    • hmac_sha384
    • hmac_sha512

  4. Pseudo-Random FunctionPseudo-random function takes a key rule in TLS handshaking, it is used to calculate the master secret, calculate session keys, and verify the just negotiated algorithms via Finished message. TLS specifications define PRF based on HMAC.
    For TLS 1.0 and TLS 1.1, the PRF is created by splitting the secret into two halves and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1, then exclusive-ORing the outputs of these two expansion functions together.
    PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);
    TLS 1.2 defines a PRF based on HMAC as TLS 1.0/1.1, except that the hash algorithm used if SHA-256, "This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function."
    Unlike TLS 1.0/1.1, the PRF of TLS 1.2 does not require to split the secret any more, only one hash function used:
    PRF(secret, label, seed) = P_<hash>(secret, label + seed)

  5. Hash function at ServerKeyExchangeIn the handshakeing message, ServerKeyExchage, for some exchande method, such as RSA, diffie_hellman, ec_diffie_hellman, ecdsa, etc., needs a so-called "signature" to protect the exchanged parameters.
    TLS 1.0 and TLS 1.1 use SHA-1 ( or with MD5 at the same time) to generate the digest for the "signature". While for TLS 1.2, the hash function may be other than SHA-1, it is varied with the ServerKeyExchange message context, such as "signature algorithm" extension, the server end-entity certificate.

  6. Server CertificatesIn TLS 1.0/1.1, there is no way for client to indicate the server what kind of server certificates it would accept. TLS 1.2 defines a extension, signature_algorithms, to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. The hash algorithm could be one of:
    • none
    • md5
    • sha1
    • sha224
    • sha256
    • sha384
    • sha512

  7. Client CertificatesIn TLS 1.0/1.1, a TLS server could request a serial of types of client certificate, but the "type" here refer to the "signature" algorithm, which does not include the hash algorithm the certificate should be signed with. So a certificate signed with a stonger signature algorithm, such as RSA2048, but with a weak hash funtion, such as MD5, would meet the requirements. That's not enough.
    TLS 1.2 extends the CertificateRequest handshaking message with a addtional field, "supported_signature_algorithms", to indicate to the client which signature/hash algorithm pairs may be used in digital signatures. The hash algorithm could be one of:
    • none
    • md5
    • sha1
    • sha224
    • sha256
    • sha384
    • sha512

What the FIPS 140-2 Concern

In the last update of "Implementation Guidance for FIPSPUB 140-2", "The KDF in TLS is allowed only for the purpose of establishing keying material (in particular, the master secret) for a TLS session with the following restrictions, even though the use of the SHA-1 and MD5 hash functions are not consistent with in Table 1 or Table 2 of SP 800-56A: "
  1. The use of MD5 is allowed in the TLS protocol only; MD5 shall not be used as a general hash function.
  2. The maximum number of blocks of secret keying material that can be produced by repeated use of the pseudorandom function during a single call to the TLS key derivation function shall be 2^32-1.

NIST's Policy Compliant profile for TLS

The NIST's policy on hash functions could be split into four principle. We discuss the profile according to the principles.
  • Principle 1: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms.MD5 is not a FIPS approved hash functions, so first of all, the profile needs to disable all cipher suites with the MACAlgorith of MD5.
    • TLS_RSA_WITH_NULL_MD5
    • TLS_RSA_EXPORT_WITH_RC4_40_MD5
    • TLS_RSA_WITH_RC4_128_MD5
    • TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
    • TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
    • TLS_DH_anon_WITH_RC4_128_MD5
    • TLS_KRB5_WITH_DES_CBC_MD5
    • TLS_KRB5_WITH_3DES_EDE_CBC_MD5
    • TLS_KRB5_WITH_RC4_128_MD5
    • TLS_KRB5_WITH_IDEA_CBC_MD5
    • TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
    • TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
    • TLS_KRB5_EXPORT_WITH_RC4_40_MD5
    SHA-2 family of hash functions are completely compliant to the policy. The profile is safe to enabled the those cipher suites based on SHA-2
    • TLS_RSA_WITH_NULL_SHA256
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA256
    • TLS_DH_DSS_WITH_AES_128_CBC_SHA256
    • TLS_DH_RSA_WITH_AES_128_CBC_SHA256
    • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_DH_DSS_WITH_AES_256_CBC_SHA256
    • TLS_DH_RSA_WITH_AES_256_CBC_SHA256
    • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    • TLS_DH_anon_WITH_AES_128_CBC_SHA256
    • TLS_DH_anon_WITH_AES_256_CBC_SHA256
    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_DH_RSA_WITH_AES_128_GCM_SHA256
    • TLS_DH_RSA_WITH_AES_256_GCM_SHA384
    • TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
    • TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
    • TLS_DH_DSS_WITH_AES_128_GCM_SHA256
    • TLS_DH_DSS_WITH_AES_256_GCM_SHA384
    • TLS_DH_anon_WITH_AES_128_GCM_SHA256
    • TLS_DH_anon_WITH_AES_256_GCM_SHA384
    • TLS_PSK_WITH_AES_128_GCM_SHA256
    • TLS_PSK_WITH_AES_256_GCM_SHA384
    • TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
    • TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
    • TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
    • TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
    • TLS_PSK_WITH_AES_128_CBC_SHA256
    • TLS_PSK_WITH_AES_256_CBC_SHA384
    • TLS_PSK_WITH_NULL_SHA256
    • TLS_PSK_WITH_NULL_SHA384
    • TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
    • TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
    • TLS_DHE_PSK_WITH_NULL_SHA256
    • TLS_DHE_PSK_WITH_NULL_SHA384
    • TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
    • TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
    • TLS_RSA_PSK_WITH_NULL_SHA256
    • TLS_RSA_PSK_WITH_NULL_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_PSK_WITH_NULL_SHA256
    • TLS_ECDHE_PSK_WITH_NULL_SHA384
    Those cipher suites with MAC algorithm of SHA-1 are addressed at the follow principles.
  • Principle 2: Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010.
    Profile ServerKeyExchange Message
    ServerKeyExchange depends on digital signature, the profile should stop using SHA-1 hash function for ServerKeyExchange handshaking message.
    TLS 1.0 and TLS 1.1 use SHA-1 ( or with MD5 at the same time) to generate the digest for the "signature". There is no way to disable SHA-1 in ServerKeyExchange handshaking message. ServerKeyExchange is a optional handshaking message," it is sent by the server only when the server certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods:"
    • RSA_EXPORT (if the public key in the server certificate is longer than 512 bits)
    • DHE_DSS
    • DHE_DSS_EXPORT
    • DHE_RSA
    • DHE_RSA_EXPORT
    • DH_anon
    For TLS 1.0 and TLS 1.1, the profile needs to disable the above key exchange methods, for the purpose of preventing the ServerKeyExchange handshaking message occurred, by disabling the following cipher suites:
    • TLS_RSA_EXPORT_WITH_RC4_40_MD5
    • TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
    • TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
    • TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
    • TLS_DHE_DSS_WITH_DES_CBC_SHA
    • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    • TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
    • TLS_DHE_RSA_WITH_DES_CBC_SHA
    • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
    • TLS_DH_anon_WITH_RC4_128_MD5
    • TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
    • TLS_DH_anon_WITH_DES_CBC_SHA
    • TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
    • TLS_DHE_DSS_WITH_AES_128_CBC_SHA
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    • TLS_DH_anon_WITH_AES_128_CBC_SHA
    • TLS_DHE_DSS_WITH_AES_256_CBC_SHA
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    • TLS_DH_anon_WITH_AES_256_CBC_SHA
    In TLS 1.2, the hash function used with ServerKeyExchange may be other than SHA-1, the following rules defined:
    • Signature Algorithm Extension: If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm used in ServerKeyExchange message MUST be a pair listed in that extension.Per this rule, the profile requires that the "signature_algorithms" extension sent by client should include only SHA-2 hash algorithms or stronger, and must not include the hash algorithms: "none", "md5", and "sha1".
    • Compatible with the Key in Server's EE Certificate: the hash and signature algorithms used in ServerKeyExchange message MUST be compatible with the key in the server's end-entity certificate.Per this rule, the profile requires that the server end-entity certificate must be signed with SHA-2 or stronger hash functions.
      Note that, at present, the DSA(DSS) may only be used with SHA-1, the profile will not allow server end-entity certificate signed with DSA(DSS).
    Profile Server Certificate
    In TLS 1.0/1.1, there is no way for client to indicate the server what kind of server certificates it would accept. What we can do here is from the point of programming and managerment, the profile requires all server certificates must be signed with SHA-2 or stronger hash functions, and carefully checking that there is no certificate in the chain signed with none SHA-2-or-stronger hash functions.
    In TLS 1.2, there is a protocol specified behavior, "signature_algorithms" extension. "If the client provided a 'signature_algorithms' extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension." Per the specific, the profile requires that the "signature_algorithms" extension sent by client should include only SHA-2 hash algorithms or stronger, and must not include the hash algorithms: "none", "md5", and "sha1"
    However, "signature_algorithms" extension is not a mandatory extension in TLS 1.2, while server does not receive the "signature_algorithms" extension, it also needs to ship the NIST principle. So the profile still requires all server certificates must be signed with SHA-2 or stronger hash functions from the point of programming and management.
    Profile Client Certificate
    In TLS 1.0/1.1, there is no way for server to indicate the client it would accept what kind of hash algorithm used to signed the client certificates. What we can do here is from the point of programming and managerment, the profile requires all client certificates must be signed with SHA-2 or stronger hash functions.
    TLS 1.2 extends the CertificateRequest handshaking message with a addtional field, "supported_signature_algorithms", to indicate to the client which signature/hash algorithm pairs may be used in digital signatures. The profile requires that the "supported_signature_algorithms" field must include only SHA-2 hash algorithms or stronger, and must not include the hash algorithms: "none", "md5", and "sha1".
  • Principle 3: After 2010, Federal agencies may use SHA-1 only for the following applications:
    • hash-based message authentication codes (HMACs);
    • key derivation functions (KDFs);
    • random number generators (RNGs).
    Except the ServerKeyExchange, server Certificate and client Certificate messages, the hash function used in TLS protocols is for HMAC, KDF or RNG, which is allowed by the policy. Need no addtional profile for this principle.
  • Principle 4: Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.
    • TLS 1.0 and TLS 1.1 is totally depends on SHA-1 and MD5, there is no way to obey this principle. In order to fully remove the dependency on SHA-1/MD5, one have to upgrade to TLS 1.2 or later revisions.

A stric mode profile

  1. Disable all cipher suites which mac algorithm is MD5;
  2. Disable all cipher suites which may trigger ServerKeyExchange message;
  3. Accept only those certificates that signed with SHA-1 or stronger hash functions;
  4. Upgrade to TLS 1.2 for purpose of fully remove the dependence on weak hash functions.

Put it into practice

Currently, Java SDK does not support TLS 1.1 or later. The proposals talked here are for TLS 1.0, which is implemented by the default SunJSSE provider.
  1. Disable cipher suiteJSSE has no APIs to disable a particular cipher suite, but there are APIs to set which cipher suites could be used at handshaking. Refer to SSLSocket.setEnabledCipherSuites(String[] suites), SSLServerSocket.setEnabledCipherSuites(String[] suites), SSLEngine.setEnabledCipherSuites(String[] suites) for detailed usage.
    By default, SunJSSE enables both MD5 and SHA-1 based cipher suites, and those cipher suites that trigger ServerKeyExchange massage. In FIPS mode, SunJSSE enable SHA-1 based cipher suites only, however some of those cipher suites that trigger ServerKeyExchange also enabled. So, considering the above strict mode profile, the coder must explicit call SSLX.setEnabledCipherSuites(String[] suites), and the parameter "suites" must not include MD5 based cipher suites, and those cipher suites triggering handshaking message, ServerKeyExchange.
  2. Constrain certificate signature algorithm
    3. The strict profile suggest all certificates should be signed with SHA-2 or stronger hash functions. In JSSE, the processes to choose a certificate for the remote peer and validate the certificate received from remote peer are controlled by KeyManager/X509KeyManager and TrustManager/X509TrustManager. By default, the SunJSSE provider does not set any limit on the certificate's hash functions. Considerint the above strict profile, the coder should customize the KeyManager and TrustManager, and limit that only those certificate signed with SHA-2 or stronger hash functions are available or trusted.
    Please refer to the section of X509TrustManager Interface in JSSE Reference Guide for details about how to customize trust manager by create your own X509TrustManager; and refer to the section of X509KeyManager Interface in JSSE Reference Guide for details about how to customize key manager by create your own X509KeyManager

Note that the above profile and suggestions are my personal understanding of the NIST's policy and TLS, they are my very peronal suggestions, instead of official proposals from official orgnization.

Popular posts from this blog

TLS Server Name Indication Extension and Unrecognized_name

Image
Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem , the ADT handshake alert , and the jarsigner issue with timestamp.geotrust.com , etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension. Background "Unrecognized_name" is an error alert, define by RFC4366 .  In section 4 of RFC4366 : - "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366 : If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). From above sections, we see that "unrecognized...
Read more

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider. The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989 , and was published in 1992 as an Informational RFC (RFC 1319) .; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown." Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation. You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in ...
Read more

JEP 115: AES-GCM CipherSuites in JDK 8

Image
Chengdu, China RFC 5288 describes the use of AES in Galois Counter Mode ( GCM ) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 ) providing both confidentiality and data origin authentication. Java SE had already defined the AES-GCM interfaces in Java SE 7 .  In the coming Java SE 8, as an implementation of JEP 115 , AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider. The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_...
Read more