Is "the keys stay in the TEE and aren't accessible to parts of the application other than those that are being attested to" a guarantee or a mechanism? It is a guarantee.
It is not, unfortunately. There could be several reasons for this. The code inside the TEE could be buggy and allow exfiltration attacks. The code could be malicious and push the keys out. The code could use an insecure RNG and make the keys predictable. Etc. The only guarantee the TEEs make is that the code running inside the TEE matches that of the quote at the time the quote is generated. ________________________________ From: Muhammad Usama Sardar <[email protected]> Sent: Sunday, July 20, 2025 9:51 AM To: Eric Rescorla <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Thomas Fossati <[email protected]> Subject: [Attested-tls] Re: [TLS] Review of draft-fossati-tls-exported-attestation-02.txt On 20.07.25 03:37, Eric Rescorla wrote: On Sat, Jul 19, 2025 at 5:11 PM Muhammad Usama Sardar <[email protected]<mailto:[email protected]>> wrote: A clarification question: did you mean * the draft should describe such guarantees in the security considerations section? * the draft should describe mechanisms which provide such a guarantee? I'm not sure I understand the distinction you are drawing here. The former is stating those requirements (in the security considerations section) that the TEE must implement and the RP's Verifier need to check. The latter is describing mechanisms provided by TEEs to meet these requirements. From a formal perspective, the former will partly come from the assumptions in the security properties. The latter is irrelevant to the formal proof. Is "the keys stay in the TEE and aren't accessible to parts of the application other than those that are being attested to" a guarantee or a mechanism? It is a guarantee. The bottom line here is: what do I as a relying party need to know in order for the attestation to actually provide meaningful practical security guarantees. There are some baseline requirements that we must state which will be implemented in the appraisal policy checks depending on the peer's architecture. For example, for a given RP, the answer can vary from: * knowing just an authenticated public key of the Verifier and checking the signatures and a single bit (yes/no) from the Verifier to * RP checking every minute detail itself, partly presented in [1]. If the former, sure, we can add this. If the latter, I don't think so. The problem is that we want to focus on protocol design and not eat the lunch of RATS :) No, I don't think so. The basic design concept of many (if not most) attestation systems is that the RP is forming a cryptographically secured channel to the system being attested to. Your design concept is correct. I am not aware of any counterexample to your design concept, i.e., in all such practical systems, RP needs a secure channel to the Attester. In this case, that channel is being provided by TLS, and that means that the implications of the attestation for the security provided by TLS to said system are necessarily in scope. I think the word "implications" answers my clarification question. If yes, I am in total agreement with you. Usama [1] https://ieeexplore.ieee.org/document/10373038
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
