Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges - page 3. (Read 42867 times)

I noticed today that my bank (UBS) can be told to generate digitally signed PDFs for wire transfers. No SSL tricks necessary, just load it into Adobe Reader and you get a document signed by the bank attesting to _only_ that transfer. This is pretty sweet: exactly what we need.

It makes me wonder how many other banks have a similar feature. Seems like this project can really be split into several pieces: ability to meet counterparties like on localbitcoins, ability to make a dispute mediated trade, and ability to extract a proof from lame banks that don't provide any kind of crypto proof of transfer.

An update - it seems it this proposal might be a bit easier to understand if explained in a bit more detail, so I wrote a semi-detailed description here:
https://github.com/AdamISZ/stegabank/blob/master/protocol.md

It's a fairly big wall of text of course, but maybe it's helpful.

As you can see I've made a new repo with the name 'stegabank', you can see the rest of the code in there if it's of interest.

Ah, got it. I didn't realise the PMS was random. Great.

@Mike Hearn
The auditor generates a 48-byte random Pre-master secret
The auditor then encrypts the PMS with the bank's key and gives the encrypted PMS to the auditee.
Thus, the auditee never knows the PMS.

One thing that wasn't clear to me - the auditor doesn't seem to create local randomness at any point. If the auditee has both client and server random, then what stops it repeating the exact same process?

Further concerns/questions about the tlsnotary model. All of this is obviously modulated by how difficult the attack is, but all the same.

1. Since the purpose of the ssl logging is to provide objective proof to some other party that the payment was made, the possible attacks are not restricted to redirecting a payment to a new bank account. Any tampering with the data that invalidates the record allows the btc seller to give "objective evidence" that the wire transfer did not take place, when actually it did, and thus defraud the buyer.


2. The nightmare scenario might still allow direct stealing, even with 2FA:
The black hat auditor has inserted himself as MITM between you and the bank. You request a wire transfer to account X (00001234), the MITM modifies it to send a request to transfer to account Y(00005678) to the bank. The bank sends back the challenge for the 2FA device, expecting the user to enter the last four digits of account Y to get the correct response. The MITM modifies this web page so it says "enter the digits 5678" instead of "enter the last four digits of the account number". Thus, the MITM receives the correct response from the client and forwards that to the bank, enabling the fraudulent transfer.

You may very reasonably say that most users are not so stupid to follow such instructions, but there are plenty of limitations on that: systems can't rely on users not being stupid, users tend very strongly to trust (and even obey!) their bank if they are convinced that they're actually talking to their bank (principally through the "padlock thingy" in their browser, combined with their own passwords), and last but not least, the MITM's ability to modify the html contents allows them to exercise their creativity in phrasing the instructions to make users trust it. Here's an example of such creativity: "enter the account number here - ... - now the system will now generate a one-time code to be entered into your 2FA device ... hourglass ... here it is: 5678". It is not that difficult to bamboozle people, at least the less intelligent 50% of people.

3. As I opined before to dansmith, security experts will not sign off on this kind of thing, I'm pretty sure. It violates the essential principle of ssl. Banks, moreover, will be within their rights to attack us as we would genuinely be weakening their security model. Users are already very distrustful of even logging the encrypted ssl session (even though any node on the internet could do that). How much more so here.

Yes, use of 2FA for wire transfers is standard these days at least for European banks.

It doesn't remove all the risk, and it will be very bank dependent, but - you make a good point.

This looks promising.


I think it is anyway standard to have 2 factor authentication enabled. At least all banks in Germany that I know ask for a unique TAN before every new action or money wire.

Thank you for good comments.
Yes, this is THE weakness of tlsnotary for which there is no mitigation. If the attacker is the auditor (or the attacker has compromised the auditor's machine) AND the attacker is controlling the auditee's home router, then It's a full-on MITM attack. The attacker can channel modified or unmodified traffic to-from the bank and on top of that he can inject any kind of HTML. Even after the auditee stops the "recording" and logs out, the attacker can spoof the logout page and  still have a functioning connection to the auditee's bank and can do whatever he wants.



Ideally of course, the auditor and the auditee should exchange their public keys via some alternative channel and only then meet on IRC. Each message between them must be digitally signed. Then the possibility of an attack is mitigated.
STUN is possible, but someone must be running the STUN server and get paid for that. That's why IRC was my first choice. Besides, I also thought that having an independent third-party logging the IRC channel may serve as an extra safeguard if one of the counterparties breaks the protocol. This way even if the auditor and the auditee don't trust each other to even follow the protocol, they still can meet on IRC and invite an arbiter to monitor the channel.

So Dansmith and I discussed this in December. I have yet to be convinced that this idea is safe. My issue is not so much the stripping of the server mac (I agree that needs to be assessed, maybe it already has), but that the auditor possesses the master secret. Whilst attacks may be practically difficult, it seems to me that this isn't safe. I would love to be convinced otherwise, as it's a powerful idea and full credit to dan for managing to modify NSS to allow it to work.

Edit: to clarify, the issue is that in this architecture the auditor possesses the master secret in real time, ie. the MS of the live connection, whereas in previous architectures the master secret was only passed to the auditor after the connection was torn down (long after).

That's beautiful! Congratulations! I wondered throughout this entire thread if there was a way to do some creative hack or abuse of the protocol to get the needed effect, but I never knew enough about TLS to come up with one.

The only issue I see, which I'm sure you already thought about, is that by stripping the server MAC it may become possible to do some kind of content injection MITM attack on the live connection. However, as you can snapshot just a single page and the user already knows what content to expect anyway, I suspect that's not a big deal in practice especially if the HTML is not rendered (as otherwise various kinds of cookie stealing attack might be possible). I mean, I suspect it's rather hard to usefully inject data into the middle of a TLS stream even without the server MAC, but it's obviously there for a reason.

Is there a risk of k-lining or attacks if using IRC for rendezvous? IRC is typically unauthenticated. I wonder if direct ip to ip with STUN would be feasible.

edit: By the way, I'd suggest running your scheme past Adam Langley and see what he thinks. He is a TLS expert who works for Google and has designed a bunch of recent TLS extensions.

I'd like to bring you up to speed on what I've been doing over the last 2 months or so.
I came up with a much more efficient method of proving the ownership of HTTPS pages which I dubbed "tlsnotary".

Here's why tlsnotary is better that the current working solution a.k.a paysty:

- tlsnotary does not require the use of Amazon EC2 oracle instances
- in tlsnotary the traffic from the auditee flows directly to the bank, as opposed to via the oracle instance in paysty.
- it does not require the escrow agent at all, i.e. can be used p2p between the buyer and the seller of the BTC.

Here's the simplified explanation:

During a TLS connection, the bank's server uses a symmetric encryption key to encrypt the HTML page and also uses a MAC key to "sign" the HTML. It is sufficient for the auditee to only know the server's encryption key in order to decrypt the HTML, the MAC signature check only ensures that the TLS data from the bank was not modified in transit.
Thus we can delegate it to the auditor to calculate the encryption key and the MAC key. The auditor then hands the encryption key to the auditee but keeps the MAC key. Having the server encryption key, the auditee can now decrypt data from the bank. Because all messages are "signed" by the bank using the MAC key and only the bank and the auditor know the MAC key, a correct MAC signature can serve as proof that certain messages came from the bank and were not spoofed by the auditee.

Here's the in-depth explanation of the TLS workflow: with references to RFC2246

   The auditee connects to the bank's server and starts a TLS handshake.
   The auditee gives the auditor the bank's public key, client_random and server_random.
   The auditor generates pre-master secret(PMS) and encrypts it with the bank's public key, calls it A) encrypted PMS. (see 7.4.7.1. RSA encrypted premaster secret message)
   Using PMS, client_random, and server_random, the auditor derives master secret (MS) - an intermediate step. (see 8.1. Computing the master secret & 5. HMAC and the pseudorandom function)
   Then using MS, client_random, and server_random, the auditor derives B) server encryption key, C) client encryption key, D) server MAC and E) client MAC. (6.3. Key calculation & 5. HMAC and the pseudorandom function)
   The auditor forwards A), B), C), E) to the auditee. Keeps the server MAC.
   TLS requires that the handshake be verified. For that the auditee submits to the auditor md5 and sha hashes of all the handshake messages. The auditor then uses MS, md5 hash and sha hash to calculate the verify_data which gets sent back to the auditee. (see 7.4.9. Finished & 5. HMAC and the pseudorandom function)
   The auditee finishes the TLS hahdshake and continues with the data exchange OMITTING the MAC check. (because the auditee must not know the server MAC key for the scheme to work.)
   When finished, the auditee presents the auditor with a network trace file containing the encrypted HTML in question. The auditor checks the TLS record against the server MAC key to ascertain that it originated from the server.

How this will be implemented:
   I already implemented this and know that it works for TLS 1.0&1.1 with RSA-AES128&256 ciphers, I just need to package the tools in an end-user-consumable way.
   I made a small patch to the NSS library, the one which Firefox relies on for TLS crypto.
   I need to setup a gitian environment to build the NSS library. This way multiple people can replicate the build process and confirm the hashes of the builds. This will allow me to distribute the patched NSS libs in binary form.
   The Auditee will be requires to use Firefox with a patched NSS library.
   Auditee-to-auditor communication will be happening on an IRC channel.


Questions are welcomed.

Here's an updated version with the following change: sharing numbers to create a random number is not a good idea on the CNE (I will spare the details for those who want to discuss it); instead we use only publically verifiable information, initial suggestion the last few bytes of the next blockchain hash after the funding of deposits.

Additionally, a "proxy service agreement" for the seller will be necessary since costless abort is no longer possible when on the RE.

More to the point, I added two slides at the end to show the map of transaction states through the protocol.
 
https://docs.google.com/file/d/0B-fjs8k25mNAcEltbzNtWjJXdEU/edit

As before, criticisms welcome, especially attacks.

(Edit: here is an interesting public source of randomness: https://beacon.nist.gov/home)

Escrow pool .... interesting.

Here is a much more detailed suggested architecture, not dependent on oracles and not dependent on buyer/seller reputation or identity persistence (intra-transaction) (formats pdf and libre office):
https://drive.google.com/folderview?id=0B-fjs8k25mNAemdxWkpmRFJmNm8&usp=sharing

The trust is in a pool of escrows, which must have some recognizable identity. The slightly complicated set up of a transaction, and escrow choice is all designed to make it both costly and infeasible to achieve collusion between escrow and one party, to cheat the other.

Criticisms more than welcome!

Here are a few slides I put together last week. Rough notes actually, intended to be combined with verbal descriptions. Not sure if it's useful as if you've been following the project you'll already know most of it, otherwise you probably won't understand it. However, there is a diagram in there which might be helpful.

https://github.com/AdamISZ/multisig_lspnr/raw/master/Paysty.pdf

Oops, sorry, you're right.

Yes, see the third paragraph of post 175 just above, this was the first model we looked at seriously.

What if it was relayed via the seller instead? In many cases, buyer and seller will be in the same country.