For TLS-PSK (pre-shared key), should non-ephemeral key exchange be preferred over ephemeral one?

Du Huynh

6/28/24, 6:46 PM

TLS 1.3 specify two pre-shared key exchange modes, which are psk_ke and psk_dhe_ke. The former is a non-ephemeral key exchange where the master secret is basically derived from the pre-shared key, the client random and the server random; whereas the latter is ephemeral and derives master secret from those same data plus the (EC)DH result. Ephemeral key exchange gives forward secrecy, so it's unarguably the better choice, only if the pre-shared key is a long-term secret.

According to RFC8446 Section 7.1:

PSK (a pre-shared key established externally or derived from the resumption_master_secret value from a previous connection)

If I understand correctly, for session resumption, after the PSK of the current connection has done its job (deriving all needed secrets/keys), the TLS implementation must automatically erase (ideally zeroize) it for us, right? Therefore it is definitely not a long-term secret.

For external PSK, the TLS implementation cannot automatically erase it because the implementation doesn't know whether the PSK is/will be used for any other purpose or not. So one can tweak at the application layer with a simple key update mechanism like derive $PSK_{n+1} = KDF(PSK_n)$ then erase $PSK_n$ at both sides after the handshake. Therefore we can make the PSK no longer a long-term secret while keeping communication capability. (Side note: IMO, one PSK should be used solely for the purpose of communicating between one pair of parties, so this key update mechanism could be integrated into the TLS implementation.)

In both cases, session resumption and external PSK, we get forward secrecy without using a ephemeral key exchange like Diffie-Hellman. The advantage is performance gain by not using public key cryptography. And I couldn't think of any disadvantage. So my question is:

In TLS, should the non-ephemeral psk_ke mode always be preferred over the ephemeral psk_dhe_ke mode for session resumption? And also the same for external pre-shared key if proper key update is applied?

Please correct me if I had any misunderstanding. Thanks in advance and have a nice day!

1 + 0

key-exchange

Score:1

Crypto

Richard Thiessen

6/28/24, 11:38 PM

The advantage of ephemeral key exchange is that secrecy is preserved even if the PSK is leaked. Contrast with a purely symmetric solution where an attacker that gets the PSK can decrypt all prior sessions.

Using a ratchet at the application layer as you describe solves this for compromising the application's stored keying material but this requires secure erasure of long term secrets Secrets stored in nonvolatile memory may be difficult to erase securely and changes in the underlying storage implementation (EG:switch from hard disk to SSD) may break security assumptions with no way to tell this at the application layer.

Secure nonvolatile storage erasure is hard or impossible

In the old days of hard disks and simple filesystems, overwriting a file in place to erase data worked pretty well. These days with copy on write filesystems and SSDs with opaque flash translation layers, secure erasure is difficult if not impossible.

Securely erasing long term secrets is best delegated to the OS(EG:effaceable storage on IOS) or handled carefully if you are designing the full implementation (EG:using microcontroller EEPROM). Unfortunately I don't know of any OS that exposes this to applications(EG:IOS effaceable storage is only used to delete entire keybags during device data wipes). SSDs similarly don't expose this functionality to users except for device wiping (and this is often not secure either).

Given that that ratchet like schemes might not work, asymmetric crypto is a relatively cheap way to prevent save-now-decrypt-later PSK compromise attacks since deleting an ephemeral key in RAM is easy to do correctly.

Detecting MITM attacks

Something like the noise protocol incorporating the channel binding value (derived partly from ephemeral asymetric keys) in the ratchet is better still since MITM attacks desynchronise the two parties. If Mallory performs a MITM attack on an Alice<-->Bob connection, the channel binding value for the Alice<-->Mallory and Mallory<-->Bob connections will be different and they will each ratchet to a different state. If they later try to connect directly, this fails and a long term fallback non-ratcheting Alice<-->Bob PSK can be used to prove this and signal to the application layer something fishy is going on. Either a MITM attack, logic error, or cloning of Alice or Bob machines (EG:VM snapshot and rollback) has occured.

+ 5

Du Huynh

6/29/24, 3:01 PM

Even with a ephemeral key exchange, secure erasure is still needed to delete session secrets like the DH result, session keys. So is this requirement really a disadvantage of non-ephemeral key exchange? Or is that secure erasure _for the PSK_ is possibly harder to achieve because it may be stored on disk? Also, what problem could desynchronization possibly cause?

Richard Thiessen

6/29/24, 6:41 PM

Essentially yes. The simplest way to securely erase long term secrets is to know how the storage medium works (EG:knowing the filesystem and underlying storage medium is modify on write vs copy on write. This is not true of SSDs or many modern filesystems.) Alternatively you do some sort of wrapping thing where a secure enclave stores a wrapping key in a tree-like data structure and modifies the tree and root key to do secure deletion. Alternatively not secure deletion but secure tracking of "this data is not accessible". TL:DR:securely erasing data in RAM is easy, nonvolatile storage less so.

Richard Thiessen

6/29/24, 6:46 PM

Desynchronising means direct connections not through an attacker MITM fail because both parties ratchet to different keys. In the context of a messaging protocol, after Mallory mounts a MITM attack, Alice and Bob can no longer send messages to one another without manually resynchronising which is indication a MITM attack has happened(or a logic error on one of the computers). Having a fallback key that doesn't ratchet allows Alice or Bob to prove to the other that this has happened and send a warning to the application layer.

Du Huynh

6/30/24, 12:42 AM

Great answer. I'm convinced that using an external PSK with a non-ephemeral key exchange comes with many pitfalls one need to take care of like secure erasure (or PSK delivery without touching the disk) and ratchet design. And with an ephemeral key exchange developers will have an easy life. But how about the TLS session resumption case? The resumption secret should never touch the disk, right? And TLS key schedule does have channel binding property. So could one mindlessly use non-ephemeral key exchange in this case?

Richard Thiessen

6/30/24, 12:53 AM

[In chrome at least session resumption tickets don't hit disk(2015).](https://groups.google.com/a/chromium.org/g/net-dev/c/zL6aUh8RG88?pli=1) The next resumption ticket would be sent over a channel protected by the previous key so there is forward security. The only issue is if an attacker dumps the browser memory at some time `t` then loses access to the device. They can use the session resumption ticket to decrypt later connections unless ephemeral keys are used. In a browser use case a single Curve25519 exchange is ludicrously cheap and code will be present anyways so little reason not to.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: For TLS-PSK (pre-shared key), should non-ephemeral key exchange be preferred over ephemeral one?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.