TLS Notary

AbstractTLSNotary is a browser add-on which allows you (the auditee) to prove to the auditor that a certain HTTPS page is present in a web browser, without compromising your internet connection, passwords or credentials. TLSNotary can be used e.g. to prove to the auditor that you made an online bank transfer. TLSNotary does not do man-in-the-middle snooping, but relies on SSL/TLS cryptography. TLSNotary page captures are non-forgeable.
Year
Link to the paperhttps://tlsnotary.github.io/docs-mdbook/
Relevance scoreVery relevant
Quality score5
LabelsLegacy compatiblePossible tool in larger solutionWeb2 to Web3 data transfer

TL;DR

Assuring the authenticity of the data that is pulled from web2 servers is an important task for the next phases of the Lido project. For the first phase, we check the existing solutions such as DECO, TLSNotary, and TLS-N. We examined the DECO and TLS-N protocol in separate notes.

TLSNotary is a protocol that allows a user (Requester) to prove to a verifier (Notary) that he interacted with a certain Server and that the transcript between them was not altered. It is a modified version of the standard TLS protocol.

The main idea of the TLSNotary protocol is to split the session keys of the client into two parts, and the Requester and the Notary participate in a two-party computation (2PC) with their key shares to jointly communicate with the server. Neither the Requester nor the Notary knows the session keys. They only have shares of them.

The first version of TLSNotary released in 2014 [1] only supports TLS 1.1 and older versions. However, we see that the TLSNotary protocol is updated so that it supports TLS 1.2 and newer versions.

Preliminary

There are three parties in the TLSNotary protocol, i.e. Requester, Notary, and Server.

The Requester

It is the party that interacts with the Server through a TLS session. The Requester can encrypt a request with a session key, and send it to the Server. Upon receiving the encrypted response from the Server, the Requester gets help from the Notary to decrypt it. Only the Requester can see the decrypted data.

The Notary

It is the party that the Requester aims to convince. He holds partial session keys, and he participates in two-party computation (2PC) with the Requester to achieve the TLS session. He doesn’t see the decrypted response of the Server, but he has a commitment to the decrypted data.

The Server

It is a standard party in a TLS session. It can be any server supporting TLS protocol. The protocol is transparent to the Server, i.e. the Server cannot distinguish whether it interacts with a client for a standard TLS or a TLSNotary session.

TLSNotary

First, we see the general workflow in the below figure, then we’ll describe each building block in the next sections.

Source: https://docs.tlsnotary.org/protocol/notarization/index.html Figure.1. This is a simple modification of the main interaction between the server and the client in a TLS 1.2 session. The operations on the client side are performed by the Requester and the Notary by secure 2PCs.

Transcript

The Transcript is a collection of data that includes metadata, handshake data, and the commitments to the requests and the responses. If the Notary is not the verifier, the Notary is required to sign the Transcript to present it to a verifier.

Source: https://docs.tlsnotary.org/protocol/notarization/index.html Figure.2. This figure depicts the structure of a Transcript which is the main output of the TLSNotary protocol. In addition to outputting the Transcript, the Notary is required to sign on the Transcript if he is not the verifier. Then the signed Transcript can be presented to the verifier to show that the data is authentic and it is notarized by the Notary.

Key Exchange

In all versions of the TLS protocol, the session keys are obtained by a key exchange protocol. To that end, the Server, the Requester, and the Notary participate in the below Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol. Assume that G\mathbb{G} is an elliptic curve group with prime order qq and generator GG.

Source: https://docs.tlsnotary.org/protocol/notarization/key_exchange.html Figure.3. This is a modified version of a standard Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol. The operations on the client side are jointly performed by the Requester and the Notary by a secure 2PC.

The 3-party ECDH protocol between the Server, the Requester, and the Notary results in Pre-master Secret (PMS) shares for the Requester and the Notary as follows:

  1. The Server sends its public key QsQ_s to the Requester, and the Requester sends it to the Notary.
  1. The Requester picks a random private key drd_r, and computes his public key Qr=drGQ_r = d_rG
  1. The Notary also picks a random private key dnd_n, and computes his public key Qn=dnGQ_n = d_nG
  1. The Notary sends his public key QnQ_n to the Requester.
  1. The Requester computes the client public key Qc=Qr+QnQ_c = Q_r + Q_n, and sends it to the Server.
  1. The Requester computes the elliptic curve point (xr,yr)=drQs(x_r, y_r)=d_rQ_s
  1. The Notary computes the elliptic curve point (xn,yn)=dnQs(x_n, y_n)=d_nQ_s
  1. Addition of the elliptic curve points (xr,yr)(x_r, y_r) and (xn,yn)(x_n, y_n) results in (xc,yc)(x_c, y_c), where xcx_c is the PMS (note that ycy_c is not used in TLS)

Now the goal is to compute xc=(ynyrxnxr)2xrxnx_c = \Big(\frac{y_n - y_r}{x_n - x_r}\Big)^2 - x_r - x_n by a secure two-party computation.

To do that, an M2A (multiplicative-to-additive) and A2M (additive-to-multiplicative) protocols from [7] are used.

Key derivation

The Requester and the Notary must run the PRF -a secure 2PC- with their PMS shares as inputs

The PRF function is computed via an HMACHMAC as follows:

HMAC(k,m)=H((kopad)H((kipad)m)).HMAC(k, m) = H\Big((k \oplus opad) \| H((k \oplus ipad) \| m)\Big).
  1. The Requester and the Notary participate in a 2PC to compute a PRF (see the above equation) that outputs the master secret MSMS.
  1. Using MSMS as the input, they compute their expanded key shares by 2PC.
  1. Upon having expanded key shares, the Requester and the Notary jointly compute the CFCF message and the verify_data that depends on random seeds, MSMS, and the SHA256SHA256 hash of the handshake data up to this point. (see the below code)
    # (handshake_hash) is a sha256 hash of all TLS handshake messages up to this point
    
    seed = str.encode('client finished') + handshake_hash
    a0 = seed
    a1 = hmac.new(ms, a0, hashlib.sha256).digest()
    p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
    verify_data = p1[:12]
  1. Then the Requester proceeds to encrypt and authenticate the verify_data and sends it to the Server.
  1. Once the Requester receives the SFSF from the Server, the Requester and the Notary jointly compute the verify_data for SFSF.
  1. They proceed to decrypt and authenticate the SFSF data in 2PC. Then the Requester checks whether theverify_data that they compute matches the decrypted one.

We skip the details on 2PC. For further information please see here.

Commitment

At the end of the TLSNotary protocol, the Requester has some encrypted data (AES ciphertext). Although this may also be seen as a commitment to a plaintext, this kind of commitment is not flexible enough, especially for cases when a Requester wants to partially reveal the plaintext.

So, how can a Requester transform the ciphertext into a commitment?

It is stated in the documents that proving the decryption in zero-knowledge is not the computationally cheapest way to do that. For the same purpose, two approaches are proposed:

  1. Decrypting the ciphertext with Garbled Circuits and producing a hash commitment to the wire labels. (useful for committing to the data to be made public)
  1. Producing a Poseidon hash over the private data (useful for proving the statements about some private data in zero-knowledge)

We skip the details. For further information please see here.

Implementation

Comparison of DECO and TLSNotary

Both protocols seem to be WIP, they haven’t been released yet. We compare them according to the DECO paper and TLSNotary sources in the references. Note that the TLSNotary documentation and GitHub repositories are not very clear to compare it to the DECO paper.

TLSNotary and DECO protocols have the same functionalities, and they use the same building blocks such as garbled-circuits protocols [13], A2M (Additive-to-multiplicative), M2A (multiplicative-to-additive) share conversion protocols [7][14], etc., for achieving those functionalities.

We give some possible differences below:

References

  1. https://github.com/tlsnotary/tlsnotary/blob/master/src/documentation/TLSNotary.pdf
  1. https://github.com/tlsnotary
  1. https://github.com/tlsnotary/tlsnotary
  1. https://tlsnotary.github.io/docs-mdbook/
  1. https://tlsnotary.org/TLSNotary.pdf
  1. https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman
  1. Efficient Secure Two-Party Exponentiation https://www.cs.umd.edu/~fenghao/paper/modexp.pdf
  1. https://en.wikipedia.org/wiki/Garbled_circuit
  1. POSEIDON: A New Hash Function for Zero-Knowledge Proof Systems https://eprint.iacr.org/2019/458.pdf
  1. https://old.tlsnotary.org/wp/?p=8
  1. https://www.rfc-editor.org/rfc/rfc5246#section-1.2
  1. Hubert Ritzdorf, Karl Wüst, Arthur Gervais, Guillaume Felley, and Srdjan Čapkun. 2018. TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing.. In NDSS https://eprint.iacr.org/2017/578.pdf
  1. Xiao Wang, Samuel Ranellucci, and Jonathan Katz. 2017. Authenticated Garbling and Efficient Maliciously Secure Two-Party Computation. In ACM CCS. https://eprint.iacr.org/2017/030
  1. Rosario Gennaro and Steven Goldfeder. 2018. Fast multiparty threshold ECDSA with fast trustless setup. In ACM CCS. https://eprint.iacr.org/2019/114.pdf
  1. A Pragmatic Introduction to Secure Multi-Party Computation https://securecomputation.org/docs/pragmaticmpc.pdf
  1. Aug 2019. (Bristol Format) Circuits of Basic Functions Suitable For MPC. https://homes.esat.kuleuven.be/~nsmart/MPC/old-circuits.html.