docs: discuss intra-handshake.fail - #2524
Conversation
Do the documentation changes need to be backported?Changes to
|
|
| The paper analyses several ways of binding attestation evidence to a TLS channel. | ||
| Among these is the binding explained above, where the nonce and the ephemeral public key are hashed into the report data field. | ||
| Next, the authors define a set of TLS session correlation goals, and show that none of the analysed binding schemes meet these goals. | ||
| This result isn't really surprising for the schemes that are using ephemeral keys: the TEE commits itself to a specific key, not to a specific negotiated session. |
There was a problem hiding this comment.
What does this sentence mean "the TEE commits itself to a specific key, not to a specific negotiated session"?
| Among these is the binding explained above, where the nonce and the ephemeral public key are hashed into the report data field. | ||
| Next, the authors define a set of TLS session correlation goals, and show that none of the analysed binding schemes meet these goals. | ||
| This result isn't really surprising for the schemes that are using ephemeral keys: the TEE commits itself to a specific key, not to a specific negotiated session. | ||
| For these schemes, the session could be relayed by anybody possessing the committed private key. |
There was a problem hiding this comment.
Maybe a little bit of extra text explaining how.
| In an ideal world, [Platform Ownership Endorsement] would assure that the expected cloud provider operates a particular TEE and vouches for its security. | ||
| Since the concept is quite new and the mechanism isn't widely deployed yet, we can't rely on it as of today. | ||
| Instead, Contrast users can add a list of expected hardware identifiers to their manifests. | ||
| Reports issued by another, attacker-controlled TEE won't pass validation due to ID mismatch. |
There was a problem hiding this comment.
iiuc the issue is at the protocol level so even if you have a list of "trusted identifiers" that would allow you to discard reports signed by TEEs that are not on the list, the attack could still be possible from a compromised TEE that is on the list. So you end up putting trust on the claims of physical security of the hosts.
Does the paper propose a protocol scheme that defends against this regardless?
There was a problem hiding this comment.
With the current shape of TEE threat models, you can't design a protocol that stays secure if the server is physically compromised.
charludo
left a comment
charludo
left a comment
There was a problem hiding this comment.
I only have a couple of nits about phrasings, but IMO they throw the tone of the doc off a bit.
|
|
||
| The necessary condition for the paper's relay attack is a leak of the private key by any TEE that otherwise passes verification. | ||
| If we rule out implementation errors, the threat model of the CPU vendors suggests that a hardware attack is necessary for that to happen. | ||
| This means that we can remove the attack vector by somehow ensuring physical security of the host systems. |
There was a problem hiding this comment.
nit: The word "somehow" here reads weirdly. Maybe something more along the lines of "If the physical security [...], then we can remove [...]".
|
|
||
| ## Intra-handshake.fail | ||
|
|
||
| You might have heard about the [Intra-handshake.fail] paper by Sardar et.al. |
There was a problem hiding this comment.
| You might have heard about the [Intra-handshake.fail] paper by Sardar et.al. | |
| [Intra-handshake.fail] is a 2026 paper by Sardar et.al. documenting relay attacks in intra-handshake attestation. |
"You might have heard" reads too much like "dang it, we wish you didn't know about this" 😁
| ### Applicability to Contrast | ||
|
|
||
| The necessary condition for the paper's relay attack is a leak of the private key by any TEE that otherwise passes verification. | ||
| If we rule out implementation errors, the threat model of the CPU vendors suggests that a hardware attack is necessary for that to happen. |
There was a problem hiding this comment.
| If we rule out implementation errors, the threat model of the CPU vendors suggests that a hardware attack is necessary for that to happen. | |
| Barring implementation errors, the threat model of the CPU vendors suggests that a hardware attack is necessary for that to happen. |
We can't rule that out.
4 participants
No description provided.