Digging into Nubeva SKI: Details Around Key Discovery and Updates
SKI is a complete TLS 1.3, TLS 1.2 PFS and legacy protocols decryption solution. SKI sensors extract session secrets from clients or servers without modifying client or server software or data. SKI is intentionally implemented for visibility by a security or devops team and integrates with existing security or APM technologies. The customer (OEM) has full control of implementation, allowing secrets to be extracted if the user has control of the clients (outbound), or control of the servers (inbound) or both. The user may decrypt in real time or store traffic and keys for decryption after the fact. The user has full control of what, when and where to decrypt. More details on SKI are available in our documentation and feel free to Contact Us to schedule a discussion.
As recently covered in the the POMCOR blog there are 2 main points mentioned in that are specific to the operations of Nubeva SKI Sensors. We realized that there was some information missing from the presentation at the NIST workshop. Our TLS 1.3 key extraction capabilities are listed in part 1 below. In part 2, we address the issue of key updates.
Part 1: Key Extraction Capabilities
Nubeva SKI Sensors discover TLS 1.3 session secrets (keys) including client and server handshake and application data encryption keys. The secrets and identifiers are listed below. More information is available in our documentation.
- CETS: client early traffic secret
- CHTS: client handshake traffic secret
- SHTS: server handshake traffic secret
- CTS0: client traffic secret 0
- STS0: server traffic secret 0
- XS: exporter secret
The following highlights these secrets in the context of RFC 8446 section 7.1:
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(., "ext binder" | "res binder", "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic", ClientHello)
| = client_early_traffic_secret ←------- CETS
|
+-----> Derive-Secret(., "e exp master", ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
v
(EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret ←------- CHTS
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret ←--------- SHTS
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0 ←-------- CTS0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0 ←------ STS0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_master_secret ←------ XS
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_master_secret
There is a final [HKDF] step to derive keys (page 72 of 8446). We provide all the material required for this calculation in each context. More detailed explanations are provided in https://tls13.ulfheim.net/ in the sections:
- Server Handshake Keys Calc
- Client Handshake Keys Calc
- Server Application Keys Calc
- Client Application Keys Calc
Part 2: Key Updates
As for key updates, it is true that there can be numerous such messages per session. However, the number of key update messages in a session is not an issue, since each key update builds on the existing key material.
Looking deeper, the ‘key update’ message does not contain key information. Rather, the message receiver updates the existing keys for that TLS session based on the requirements defined in RFC 8446 section 7.2 and RFC 5869. Nubeva’s SKI Decryptor and SKI Decrypt libraries implement this standard key recalculation/update function to compute new keys from the existing key material.
The initial key material, which is provided by Nubeva SKI sensors, from the first session handshake is available to Nubeva’s decryptors, decrypt library or any TLS 1.3 decryption solution. Therefore any of these TLS 1.3 decryption solutions can calculate the new keys based on the first key update message. As well, these resulting keys are the inputs to the next key update calculation, and so on.
In conclusion, Nubeva’s SKI technology provides an evolved option for TLS visibility across protocols and extends to the future, including TLS traffic using pinned certificates, or environments that use client certificate solutions that render traditional MITM solutions unworkable.
Who is Nubeva? : Nubeva Technologies Ltd. develops and licenses software for the decryption of TLS network traffic to enable deep packet inspection for security and application monitoring systems. The need to inspect data in motion is fundamental to network security and application monitoring and assurance. Nubeva solves the growing capability, performance, and complexity gaps introduced by modern TLS encryption and today’s network and computing architectures. The shift to SaaS, the cloud, 5G, and stronger encryption practices like perfect forward secrecy and TLS 1.3 create new and unique challenges for in-line and out-of-band decryption and visibility solutions. Nubeva has evolved the TLS visibility option for the modern era of strong encryption in dynamic and distributed compute environments.
The benefits of our SKI solution include:
- Capability - With the ability to capture the session secrets, decryption is simple and straightforward. Unlock any encrypted session regardless of protocol, pinning, certs, CA, or other variants.
- Extensible - SKI works by finding keys in memory. It is extensible to any protocol that uses the same base constructs, including QUIC, DTLS, DoT/DoH, SSH, IPsec, and more.
- Performance - Extract and land on a system in under 200 to line-rate deep-packet inspection with commodity hardware and eliminate latency.
- Simplicity - TLS inspection becomes an instant-on, easy option with no certs and server keys to manage, no CA issues, and no bypass and exception around unsupported applications and protocols.
- Universal - Works the same for any application, inbound and outbound, east-west, inline or passive, real-time, or historical, making it easier to plan and build more into architectures and environments.
- Security - SKI presents a far lower risk profile than any other method.
- Session integrity is maintained and not modified in any way end-to-end promoting the highest levels of security, privacy, and compliance of any TLS inspection method.
- Keys are session keys that are kept long enough to be used and are then discarded. Unlike master server keys, which last forever and can unlock all sessions, or by resigning certificates that violate the core security of TLS in the first place.
- Finally, by separating a “key-plane” from the data or traffic plane, security is delivered through segregation and abstraction of the two dimensions needed to decrypt
