On Sun, Jul 20, 2025, 3:52 PM Thomas Fossati <thomas.foss...@linaro.org> wrote: > > On Mon, 21 Jul 2025 at 00:12, Eric Rescorla <e...@rtfm.com> wrote: > > On Sun, Jul 20, 2025 at 1:45 AM Mark Novak <mr.mark.no...@gmail.com> wrote: > >> > >> Regarding this statement: > >> > >> I'm not sure I understand the distinction you are drawing here. > >> 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? > >> > >> On one level your observation is correct: the key must remain in the TEE > >> and be safe from exfiltration. It is also 100% correct that the mere > >> presence of a TEE does not guarantee that the key cannot (or would not > >> deliberately) be exfiltrated from the TEE. > >> However, what comes to the rescue in this case is a critical property of > >> TEEs: they cannot lie about the code they are running. If the evidence > >> provided by the TEE (inside the CPU-signed "quote") matches the reference > >> value that is deemed correct by the Verifier, that's the only and best > >> guarantee of the code being implemented correctly you can get. Of course > >> if the reference values treat buggy code as correct, then all bets are > >> off, but that's unavoidable. > > > > > > The point I am trying to make is that whoever is examining the code needs > > to know that this is a property they are looking for, along with some other > > properties, and it is the job of this spec to tell them that. > > This specification must define certain security properties that the > execution environment may reasonably provide, e.g. the > non-exportability of key material, the localisation of the TLS > endpoint within the isolated environment, and the inability to act as > an oracle, among others.
This has some nonobvious implications for structuring of the software environment of the enclave. For one thing the TLS stack can't be part of the user provided application and has to have some standalone evidence applied. These might be "RATS territory" but I think there's a bunch of interplay with how the requirements feed back to TLS implementations this WG is better suited to explore, just out of familiarity. Sincerely, Watson > cheers, t > > _______________________________________________ > RATS mailing list -- r...@ietf.org > To unsubscribe send an email to rats-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
