[Cryptography] TLSNotary

Adam Gibson ekaggata at gmail.com
Thu Oct 16 18:02:36 EDT 2014


If anyone would be kind enough to take a look at this (it was posted
here last month), and let us know if you see any problems, we'd be grateful.

(Note to moderator: if this kind of bump, which I don't intend to do
again, is not appropriate, no worries :) )

Regards,
Adam Gibson

On 09/13/2014 03:20 PM, Adam Gibson wrote:
> Paper:
> https://github.com/tlsnotary/tlsnotary/blob/master/data/documentation/TLSNotary.pdf?raw=true
> 
> TLSNotary is intended to allow an auditor to audit the contents of an
> https server response (e.g. html page), without the auditor having
> control of or access to the live TLS session between client and server.
> It is restricted to TLS 1.0/1.1, at least for now.
> 
> To boil it down to the simplest terms:
> 
> * Have the auditor and client separately generate two 'halves' of the
> premaster secret.
> * Use the TLS 1.0/1 PRF** to have the auditor hold the server mac write
> secret, while the client (called 'auditee' in the paper) holds the other
> secrets in the expanded keys.
> * Client Key exchange message can still work without the client having
> the full premaster secret, using the RSA homomorphism*** (hence -
> restricted to RSA cipher suites).
> * Client sends an initial request on the new connection as normal,
> receives response, but is not able to authenticate as doesn't have the
> server mac secret.
> * Client makes commitment of server response to auditor. Auditor "hands
> over" server mac secret, client can now safely authenticate.
> * Finally, if the client is happy with the material to be audited (i.e.
> html page usually), he can pass this over to the auditor as a 'reveal'
> of the earlier commitment.
> 
> ** This part is the main innovation and is described in the paper,
> Section 2.1.
> *** This is described in detail in Section 2.2. It (at the moment)
> necessitates a considerable reduction in the entropy of the premaster
> secret; crudely, one could say that the entropy protecting from an
> external attacker is reduced from 46 bytes to about 21 bytes, and the
> protection the auditee has from the auditor is only 12 bytes (but such
> an attack would have to be carried out in an unfeasibly short time).
> 
> Motivation: we were motivated by the problem of the difficulty of doing
> decentralised exchange of bitcoin for things like bank wires - the
> question being, is there any way to cryptographically prove a bank wire
> has taken place (rather than relying on less sound proof methods).
> Obviously, using such a system for something as sensitive as bank
> statements raises the stakes considerably. However, our main motivation
> in describing the algorithm here is to ask if anyone can see holes in it
> either cryptographically or in more general computer security terms.
> 
> An example of the non-cryptographic concern would be: what happens if
> the html page sent to the auditor contains a session cookie? We believe
> that it would be sufficient to log out of the session in advance.
> We don't see exposure of login credentials as a concern, because the
> client/auditee chooses a page within the logged-in site to audit (the
> audit, notice, only covers one single server response), and the auditee
> can sanity check before sending any material to the auditor anyway.
> Perhaps these arguments aren't convincing - opinions welcome.
> 
> There is a working implementation at
> https://github.com/tlsnotary/tlsnotary - needs Firefox and Python 2.
> There is a specific 'self-test' mode to allow the curious to try it out
> on their own - here you act as both auditor and auditee at the same time
> on your own machine.
> 
> Many thanks for any feedback,
> Adam Gibson (see contacts for me and the other two developers on the
> README).
> 


More information about the cryptography mailing list