The Impact of TLS 1.3 and ACVTS on FIPS Certification Testing

by Marcos Portnoi, Stephan Mueller, and Viktoria Meyerhoff

In 2018, the Internet Engineering Task Force (IETF) published RFC 8446, “Transport Layer Security (TLS) Protocol Version 1.3”, a new standard for the latest version of TLS. TLS is the successor of SSL (Secure Sockets Layer), which was developed by Netscape in 1995. In 2020, the Cryptographic Module Validation Program (CMVP) updated the algorithm testing process from the Cryptographic Algorithm Validation System (CAVS) to the Automated Cryptographic Validation Testing System (ACVTS). Companies pursuing certifications may wonder how TLS 1.3 and ACVTS affect the algorithm testing requirements needed for FIPS certification.

Full TLS 1.3 Handshake
 

Transport Layer Security is a protocol utilized in encrypting data transferred over the internet. Information systems use the Hypertext Transfer Protocol (HTTP) to facilitate communication across the internet. HTTPS (Hypertext Transfer Protocol Security) enables encrypted communication by layering HTTP over a TLS channel. In order to utilize HTTPS, a TLS certificate must be installed on the origin server to permit server authentication to the client. The client may also use their own certificate, which allows for bi-directional authentication. The user’s browser and the server can communicate securely after a successful TLS handshake and establishment of the TLS encrypted channel. TLS 1.2 employs the RSA as well as elliptic-curve Diffie-Hellman (ECDH) / Diffie-Hellman (DH) algorithms in its handshake, among other options. The issues with forward secrecy and the several back-and-forth communications by the RSA key exchange posed a security risk in the process. In order to improve security and speed, the IETF decided to abandon use of the RSA key exchange as well as non-ephemeral Diffie-Hellman and only allow use of ephemeral ECDH/DH and RSA for authentication. Hence, TLS 1.3 allows using a pre-shared secret that is not transmitted through the channel or utilizing ECDHE for ephemeral session keys. Pre-shared keys can be used in conjunction with ECDHE to achieve forward secrecy. The updates to TLS 1.3 also include removal of MD5, an algorithm for key exchange that focuses on elliptic curve cryptography, and key exchange simplification using HKDF-based derivation including utilization of a parallel derivation process.

While TLS 1.3 supports (pre-shared key) PSK for establishment of the session, a method without forward secrecy, the forward secrecy process works in the following way: When the TLS 1.3 key exchange with forward secrecy process first starts, both parties do not have a shared key. Hence, the TLS handshake must include a method to create a shared key. For this to take place, six parameters are required. The initiator must send a key, an initialization vector, and a MAC key to the responder and vice versa. To generate the keys, the DH/ECDH process is conducted, so that both parties possess the same pre-master secret. The pre-master secret is then needed to create six keys, which is accomplished with a pseudorandom function (PRF). The PRF uses HMAC key derivation function (HKDF), a hash-based message authentication code (HMAC)-based key derivation function (KDF) as described in RFC 5869. HKDF implements two functions: an extract function and an expand function. During the extract function, a new keying material with a limited length is derived from an initial key. In the expand function, the initial key can be used to create keying material of various lengths from which cryptographic keys can be extracted. The function can be called upon numerous times.

The TLS 1.3 protocol described in RFC 8446, section 7.1, explains that the key schedule utilizes HKDF expand and extract functions. The various expand functions generate several different keys. Utilization of HKDF brings up some concerns when it comes to testing. Per the Implementation Guidance (IG) Section D.8 (Section D.F in the 140-3 IG), HKDF is only approved for use within SP800-56C Rev. 2 key agreement as a two-step KDF and must be tested using the ACVP tool. TLS KDF 1.3 is approved for use within SP800-56C Rev. 2 per IG D.8 and it is also approved as a component algorithm to be used by itself per IG G.20 (Section 2.4B in 140-3 IG). Many Implementations Under Test (IUTs) implement HKDF within their cryptographic module boundary, but the HKDF calling sequence is oftentimes outside of the boundary, such as in a TLS-stack. Furthermore, while KDF TLS 1.3 is based off HKDF, KDF TLS 1.3 and HKDF are different cryptographic algorithms with their distinct certificates. A KDF TLS 1.3 algorithm cannot be claimed using an HKDF certificate, but keys derived by a certified HKDF can be claimed as valid TLS 1.3 keys.

To ensure NIST cryptographic algorithm testing requirements are met for FIPS certification, either of the following scenarios must be tested.

1. If the HKDF calling sequence is within the module boundary, the TLS 1.3 test as defined by ACVTS must be used. This test provides a pre-master secret and demands that all keys in the KDF TLS 1.3 key schedule are returned. The TLS 1.3 test vector provides either a DH shared secret or a pre-shared key along with the server hello random value, the client hello random value, the server finished random value, and the client finished random value. Per the key schedule in RFC 8446 section 7.1, the IUT is now expected to calculate all the following values: the client early traffic secret, the early exporter master secret, the client handshake traffic secret, the server handshake traffic secret, the client application traffic secret, the server application traffic secret, the exporter master secret, and the resumption master secret. This test approach requires the calculation of the different interleaved HKDF extract and expand steps.
   
   
2. If the HKDF calling sequence is outside of the module boundary, the test for HKDF as defined by ACVTS must be utilized. This test provides a key for the extract function and checks the result of the expand function. The HKDF test contains two test approaches: In the first approach, the test vector provides the salt and input key material (IKM), which is equal to the shared secret computed by the DH/ECDH operation during the TLS handshake. Utilizing this, the extract operation is performed, and additional info is provided to perform the expand function, such as the calculation of the output keying material (OKM) as stated in RFC 5869. In the second approach, the test vector utilizes the same input parameters as in the first approach, but it also uses the result of the HKDF expand function. Now the IUT must return a Boolean operation to indicate whether the OKM calculated by the expand function matches the OKM of the test vector.
   

To summarize: If the calling sequence is inside of the module, utilize the TLS 1.3 test. If the calling sequence is outside of the module, utilize the HKDF test. NIST has approved both tests.

The publication of RFC 8446 “Transport Layer Security (TLS) Protocol Version 1.3” and the implementation of the Automated Cryptographic Validation Testing System (ACVTS) are major changes in the world of security and validation. atsec information security is an independent, privately-owned company that focuses on providing laboratory and consulting services for information security. If your company is interested in pursuing FIPS certification for your software, firmware, hybrid, or hardware products, please contact us at info@atsec.com.