Part 3 – Exported Session Key Passive Decrypt

This blog is the third in a series that looks at a NIST project “Addressing Visibility Challenges with TLS 1.3 within the Enterprise.” The home page for the project is here: https://www.nccoe.nist.gov/addressing-visibility-challenges-tls-13. The NIST site includes details of the project and organizations involved in the project as well as drafts of the project documents which will be updated as the project progresses.

As detailed in Part 1, the NIST project is looking at two passive decryption mechanisms that can be used within an enterprise data center to gain visibility into TLS 1.3 traffic. In this post, we look at the second of these techniques: ephemeral key export.

As detailed in the previous blog, the TLS handshake results in a unique ephemeral session key for that TLS session. During a TLS 1.3 handshake, the server generates ephemeral keys that are used to derive the ephemeral session key. From observing the TLS handshake on the wire, it is impossible to determine what the resultant ephemeral session key is, which prevents passive decryption of the flow.

However, if the ephemeral session key resulting from the handshake is exported and made available to a decryption device, then it will be able to perform passive decryption. This is what the ephemeral key export mechanism does; an agent (typically on the TLS server) captures the ephemeral session key generated by the TLS handshake and exports it so it can be used by a decryption device. The decryption device can use the session key to decrypt a copy of the flow in real time or to decrypt a captured copy of the flow at a later point in time.

A number of things need to be possible in order for ephemeral session key export to be achievable:

• An agent on the server needs to be able to capture the session key;
• There needs to be a unique identifier that associates the captured session key with the flow it belongs to; and
• The decryption device needs to receive the session key before it receives TLS records encrypted with the key if it is to be able to carry out real-time decryption

Associating a session key with the associated TLS flow relies on a feature of the TLS handshake called the Client Random. This field is part of the Client Hello message sent by the client to initiate a TLS handshake and is, essentially, unique. If the agent exporting the session key also exports the client random for the session, then the decryption device can use the client random as the way to determine which exported session key to use for a flow. It is theoretically possible that more than one flow in a network is using the same client random, but very unlikely. While this is unlikely to be an issue, it can be mitigated by either including the source IP address of the client as part of the information used to determine which key to use, or by simply trying the session key against each of the flows with the same Client Random to see if it works.

In addition to sending the exported session keys to a decryption device, the agent (or the decryption device) can send them to a key management system. The key management system allows capture and storage of session keys in a secure environment so that they can be retrieved at a later time and used to decrypt a packet capture of the flow, typically a PCAP file. If the captured session key is deleted from the key store, then any PCAPs of encrypted flows become useless, as it is then no longer possible to decrypt them.

As noted earlier, TLS 1.3 PFS prevents post-facto decryption of a captured flow that occurred before the TLS server was compromised. This is no longer the case if exported session keys are being captured and stored as described above. While compromising the server will not provide access to past ephemeral session keys, compromising the key management system will. However, as noted, as soon as the captured session keys are destroyed, the ability to decrypt a captured flow is lost. Clearly, key management systems need to enforce strong security on who can access keys and for how long.

The diagram below shows the elements involved in implementing an ephemeral key export mechanism. Mira’s Encrypted Traffic Orchestrator (ETO) can receive exported ephemeral session keys from an agent and use them to carry out passive real-time decryption of TLS 1.3 flows.

Exported Session Key Passive Decrypt

In the post-facto decryption case, the key management system needs to retain the exported session keys and other associated data, such as the Client Random, and be able to provide them to a decryption device when requested at some time in the future. The decryption device will need to know the Client Random value for the flow it wishes to decrypt in order to request the appropriate session key from the key management system. Clearly, the key management system needs to provide secure storage for the session keys and associated information as well as strong access controls over who can retrieve session keys.