Repository navigation
Ephemeral TLS keys lifecycle and destruction in BCJSSE/BCTLS #2167
Description
Activity
- changed the title
[-]EphemeralTLS private keys destruction[/-][+]Ephemeral TLS keys lifecycle and destruction in BCJSSE/BCTLS[/+]on Sep 24, 2025 Ephemeral (EC)DHE private keys are simply released for garbage collection. In a TLS 1.3 handshake the reference is dropped a) at the server during ServerHello generation, or b) at the client during ServerHello processing. For pre-1.3 I see that they are held until handshake completion; they could in theory be released a little earlier (ClientKeyExchange send/recv), which may be worth changing.
If by ephemeral key material you are referring to the same (EC)DHE ephemeral private keys, then no, TlsSecret is separate from that. Otherwise please clarify what you are asking there.
For the derived secrets that TlsSecret is used with in most cases: if you are interested in the story for a particular secret please specify, but in general we overwrite them in a best effort way (the GC may have made copies) at least by the end of the handshake, sooner in some cases e.g. the PreMasterSecret.
Note that master secrets may be retained by the session cache.
Hello,
We are using BCJSSE/BCTLS 1.80 in a Common Criteria evaluation context (FDP_RIP.1 / FCS_CKM_EXT.4).
During an ephemeral (EC)DHE handshake, private keys are generated internally by the provider to perform key exchange.
Could you please clarify:
Are these ephemeral private keys explicitly zeroized/cleared from memory once the handshake completes?
Or are they simply released for garbage collection when the handshake context is cleared?
Additionally, we see that TlsSecret.destroy() can wipe derived secrets — does this apply only to session secrets, or also to the ephemeral key material itself?
We would like to confirm what destruction guarantees Bouncy Castle provides for ephemeral TLS keys and derived secrets.
Thank you for your support.