search

CCC-Attestation / meetings

Meeting materials
Apache License 2.0
15 stars 9 forks source link

Usama's attested TLS presentation #28

Closed thomas-fossati closed 9 months ago

gkostal commented 9 months ago

@thomas-fossati , @muhammad-usama-sardar - for posterity, the question I asked during the 1/30 CCC Attestation SIG was regarding slide 9:

thomas-fossati commented 9 months ago

@thomas-fossati , @muhammad-usama-sardar - for posterity, the question I asked during the 1/30 CCC Attestation SIG was regarding slide 9:

  • What does "post-handshake" do to the programming model? It seems that it moves the problem of establishing an attested encrypted channel to the application layer, thereby requiring modification to all apps. If accurate, this seems to make the "post-handshake" alternative significantly less attractive than the others (where this transparently handled by the TLS library).

Thanks! I've copied it to the minutes.

muhammad-usama-sardar commented 3 weeks ago
  • What does "post-handshake" do to the programming model?

Thank you @gkostal for this question. Now that we are done with formalizing pre-handshake attestation and started exploring post-handshake attestation, I have some initial thoughts to your question.

It seems that it moves the problem of establishing an attested encrypted channel to the application layer,

Yes, that is also my understanding.

thereby requiring modification to all apps.

not necessarily. For example, SCONE has "SCONE Runtime" in the same enclave as the application. SCONE Runtime handles all the attestation part, so that there are no/minimal changes to the application. There are, however, at least two cons of this approach:

  1. SCONE Runtime is closed-source. It cannot be verified that it has no vulnerabilities.
  2. The measurement we get from attestation is of "Application + SCONE Runtime" (since they are both in one enclave) rather than "Application" alone.