Entities

• User: Runs the whole TLS session with the Website
• TEE_K: Trusted Execution Environment (hosted at a cloud provider) that holds TLS keys and performs encryption/decryption tasks.
• TEE_T: Trusted Execution Environment (hosted INDEPENDENTLY from a previous one at a cloud provider) that assists in tag computation without access to TLS keys.
• Website: The real Website with which the User communicates.
• Verifier: Validates the authenticity of the TLS transcript (hosted by a 3rd party, independent from Reclaim). This entity is a separate party that does not participate in the main protocol flow, though appears after the main protocol is done.

NOTE: due to the need to divide AEAD into two processes (encryption and MAC computation), further when we say “ciphertext” it means that it does not include tag (the latter is mentioned separately).

Protocol Goals

• Ensure that a specific TLS transcript reflects communication between the User and the real Website, mediated by TEE_K and TEE_T.
• Maintain the transcript's authenticity and integrity while protecting the privacy of sensitive data.

Assumptions

• Secure channels between TEE_K, TEE_T and User. Additionally, secure channel between the User and the Verifier
• Impossibility of collusion between any entities (assuming that this means collusion with cloud providers)
• TEEs’ integrity (i.e. they run their code)
• An adversary (in practice) cannot steal data from both TEEs during the TLS session lifetime
• Single request-response TLS session with the help of TEEs
• Standard crypto assumptions

Security Considerations

• The MPC protocol is provably 1-private, meaning that any “honest but curious” adversary cannot learn anything about others’ inputs.
• We are not interested about being 1-secure or 2-secure because we run code in TEEs, and so they cannot be malicious