ekaggata at gmail.com
Sat Sep 13 08:20:26 EDT 2014
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
* 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,
*** 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
More information about the cryptography