{"id":3480,"date":"2021-03-02T17:37:00","date_gmt":"2021-03-02T16:37:00","guid":{"rendered":"https:\/\/webdev.atsec.us\/?p=3480"},"modified":"2024-08-19T21:29:47","modified_gmt":"2024-08-19T19:29:47","slug":"the-impact-of-tls-1-3-and-acvts-on-fips-certification-testing","status":"publish","type":"post","link":"https:\/\/webdev.atsec.us\/the-impact-of-tls-1-3-and-acvts-on-fips-certification-testing\/","title":{"rendered":"The Impact of TLS 1.3 and ACVTS on FIPS Certification Testing"},"content":{"rendered":"\n
by Marcos Portnoi, Stephan Mueller, and Viktoria Meyerhoff<\/font><\/p>\n\n\n\n In 2018, the Internet Engineering Task Force (IETF<\/a>) published RFC 8446<\/a>, \u201cTransport Layer Security (TLS) Protocol Version 1.3\u201d, 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<\/a>) updated the algorithm testing process from the Cryptographic Algorithm Validation System (CAVS<\/a>) to the Automated Cryptographic Validation Testing System (ACVTS<\/a>). Companies pursuing certifications may wonder how TLS 1.3 and ACVTS affect the algorithm testing requirements needed for FIPS certification.<\/p>\n\n\n\n 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\u2019s 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. 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. by Marcos Portnoi, Stephan Mueller, and Viktoria Meyerhoff In 2018, the Internet Engineering Task Force (IETF) published RFC 8446, \u201cTransport Layer Security (TLS) Protocol Version 1.3\u201d, 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 […]<\/p>\n","protected":false},"author":9,"featured_media":3481,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[7,8,6],"tags":[],"_links":{"self":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3480"}],"collection":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/comments?post=3480"}],"version-history":[{"count":1,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3480\/revisions"}],"predecessor-version":[{"id":3482,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3480\/revisions\/3482"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media\/3481"}],"wp:attachment":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media?parent=3480"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/categories?post=3480"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/tags?post=3480"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<\/figure>\n\n\n\n
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<\/a>. 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<\/a>, 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<\/a> (IG) Section D.8 (Section D.F in the 140-3 IG<\/a>), HKDF is only approved for use within SP800-56C Rev. 2<\/a> 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<\/a>). 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.<\/p>\n\n\n\n\n
The publication of RFC 8446<\/a> \u201cTransport Layer Security (TLS) Protocol Version 1.3\u201d and the implementation of the Automated Cryptographic Validation Testing System (ACVTS<\/a>) 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<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"