Transparent Humanity Attestation on the Web

--- title: Transparent Humanity Attestation on the Web tags: crypto, tls, antifraud, papers --- **Context**: Our goal is to investigate how to allow users to accumulate “*breadcrumbs*” or tokens from their online behavior such that: - The tokens prove online behaviour (e.g. visiting a webpage, loging in to a service); - Tokens cannot be forged; - The user can prove arbitrary statements about the tokens (e.g. they are included in your whitelist), in ZK - A double spending mechanism at the verifier level that detects when the same tokens have been used more than once. ## ATLAS **Idea**: Leverage TLS (1.2/1.3) handshakes to prove connection to a website out of a list of whitelisted websites - Is a "TLS connection" enough for attestation? ## OAuth ## 3rd party Privacy Pass tokens as web attestation ⭐ ❌ Can we use signed privacy pass tokens from 3rd parties as an humanity attestation? Not without interacting with the issuer. The current Privacy Pass protocol does not allow 3rd parties to check whether a token has been signed by a well-known provider. Only the provider (signer) can do that. ## DECO - Liberating Web Data Using Decentralized Oracles for TLS https://arxiv.org/pdf/1909.00938.pdf **Goals**: DECO allows a prover to proof generate statements of data "encapsulated" in a TLS session; The protocol does not require any server-side changes or TEE. ### How - Three-party handshake (3PH) between *prover*, *verifier* and *server*, instead of the normal 2 party TLS handshake between initiator and server. The 3PH provides authenticity to the proofs generated by the prover (i.e. verifier can validate the proof; not possible for the prover to forge proofs). - The verifier commits to a TLS data session. Once committed, the verifier can proof arbitrary and selective statements about the data in the commitment (i.e. TLS data session contains a substring); - Selective disclosure of the committed data session give the prover fine granular control about what statements to disclose about the session data; - DECO also provides *context-integrity*, i.e. it allows the verifier to verify that the proofs from the selective disclosure are generated within an expect context, without revealing the context itself. e.g. the prover can generate a proofs that a substring exists in the data session of the TLS within a JSON/HTML blob of an online shopping cart without revealing the shopping cart code itself. ### Tradeoffs in the context of Brave: - Privacy: Brave knows when user performs an action (and which action); - Time; Website; Action - Implementation and deployment needs to be fast in order to prevent time outs; - How to implement the intersection at the browser side? - PR/Optics of such a protocol? ### Protocol details and questions - ❓ Brave participating in the TLS handshake is cumbersome and it may lead to privacy leaks. Brave will *know* which actions the user is making and when, e.g. Brave knows that User/wallet purchases an item on Amazon, since it has to participate in the TLS handshake with the user. Could we remove the need for a 3PH, even if that means more expensive proof generation and less flexibility wrt the selective disclosure of session data? - ❓ Generating zkps about the TLS session records is expensive; DECO uses a MAC-then-encrypt where the number of operations required to generate the proof reduces substancially (from 1024 AES operations to 3 AES operations); In the context of using DECO for fraud prevention, the prover needs to generate the proofs only a few times only -- could we trade proof generation complexity/performance to drop the need for Brave to participate in the TLS handshake? - ❓ In the context of antifraud where the verifier keeps a list of selected websites that are trusted for verification, we may not need the context-integrity feature of DECO. - ⭐ ❌ Why can't the prover generate a zkp over a TLS record of a normal TLS session (i.e. no need for the 3PH)? - TLS data does not "encode" provenance, since it is encrypted using symmetric keys generated by the server and the client during the Handshake process; - However, the data records received from the server contain a MAC, generated by the server -- this could be used to verify *integrity* and sender *authentication*, and thus provenance -- false, because of MAC (not signature); - The paper claims that since the prover knows the session keys, the messages received can be forged and thus the verifier cannot trust the proofs generated based on that data. MACs are generated and verified by the holders of a common symmetric key. Thus, any party can generate MACs over arbitrary data. - Why, then, are MACs used in TLS instead of signatures? [Performance and the TLS thread model](https://security.stackexchange.com/questions/168106/why-would-i-use-mac-over-digital-signature). The TLS threat model does not consider the need for server and client to prove the provenance of data to third parties (i.e. parties outside of the TLS connection) - ⭐ Why doesn't TLS offer a feature for users to request record data (batches) to be signed by the server, so that the user can prove the data provenance to 3rd parties? This feature could be disabled by default. ### Implementation status There is no implementation of the 3PH and the query stage (proof generation and verification) available on github or elsewhere.