tlsnotary - cryptographic proof of fiat transfer for p2p exchanges

[dansmith]

EDIT: 3 September 2014
THe software now is near feature-complete, but in order to test its compatibility with the large number of banks out there, we need testers! Please, if you want to help freeing Bitcoin from the harassment of the banks, come and talk to us.

E-mail: tlsnotarygroup-at-gmail.com

Freenode IRC: #tlsnotary-chat

Code: https://github.com/tlsnotary/tlsnotary


EDIT: 29 July 2014
The goal of tlsnotary is to allow the buyer of BTC to prove to a 3rd party arbitrator that a money transfer to the seller has been made.
While logged into their bank account, the buyer requests a TLS-secured (HTTPS) statement page and presents it as proof to the arbitrator.
We use a scheme which leverages the TLS crypto in order to prevent the buyer from forging the proof. The novelty of this scheme is that it doesn't MITM the auditee's connection.

We have released software which implements the goal of this project. Now we are looking for people to test the software.
The final idea on which the ultimate release is based started with this post:
https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488
Then it was enhanced by oakpacific in this post:
https://bitcointalk.org/index.php?topic=173220.msg6160307#msg6160307
The announcement of a software release was made here:
https://bitcointalk.org/index.php?topic=173220.msg7143321#msg7143321

P.S. For real-time support, find us on #tlsnotary-chat on irc.freenode.net

----------------------------------------------------------------
THE INFORMATION BELOW IS OUTDATED. I LEFT IT HERE ONLY FOR HISTORICAL PURPOSES. WE HAVE TRIED VARIOUS SCHEMES UNTIL WE ARRIVED AT THE ONE WHICH DOES WORK.
----------------------------------------------------------------


EDIT2: 14 June 2013
There are many ways of going about implementing SSL logging, but I particularly like the one proposed in post#61
https://bitcointalk.org/index.php?topic=173220.msg2304618#msg2304618
Feel free to jump to #61 as the rest of the discussion basically springs from there.


EDIT:
Ever since starting this thread I realised that proxying SSL through escrow means that the bank can ban escrow's IP. While rather unlikely, I have come up with a more resilient method (post #10 in this thread) where all traffic goes through the user's IP while the escrow controls the SSL key.

https://bitcointalk.org/index.php?topic=173220.msg2266868#msg2266868


Goal: a payer needs to prove that he made a money transfer into the account of the seller (of BTC). This proof is only needed to be presented to an escrow agent in case a dispute arises. This proof aka SSL dump should not disclose payer's online bank login credentials.

Here is the workflow:

1. The user starts up his Firefox with an open-source plugin provided by the escrow agent
2. The user initiates an SSL connection to his online banking site
3. The user enters his username/password and logges in
4. After that all further traffic between user<<-->>bank gets redirected by the plugin through the escrow agent's proxy
5. The proxy collects all encrypted communication dumps.
6. The Firefox plugin knows the symmetric key which was used for SSL communication and which is needed to decrypt the dumps.
7. In case a dispute arises, the payer can provide the symetric key to the escrow agents.

8. The escrow agent decrypts the SSL dumps and verifies that the user has indeed initiated the funds transfer.

Cool?
Can I please get some criticism/peer reviews on this model.
Because I'm burning now to start coding right away!

[greBit]

interesting idea!

[Xenland]

Could work with the P2PCrypt system scince SSL (and assuming HTTPs) probably won't work out of the box.

I'm getting the p2pcrypt.com website back up should be up soon (transferring servers)

[dansmith]

since SSL (and assuming HTTPs) probably won't work out of the box.

I'm not sure I understand what you mean by that. Please explain.

[alberthendriks]

Many p2p exchange ideas are popping up on this forum. I did research on them yesterday. You'll find my conclusion in most of those topics.

[dansmith]

@alberthendriks

Great to see you joining forces! By all means go ahead and create a cool open-source turn-key p2p platform that can be deployed with one click.

I need to make one thing clear though.

What I'm proposing here is just a method of enabling more robust p2p exchanges with minimal escrow involvement.
This model/plugin that uses SSL dumps will be open-source and can be used on any p2p exchange.

[alberthendriks]

Hi Dansmith,

Some brainstorming here:

Thanks for taking up my "hijacking-attempt" positively. Sorry for not reading your project details better before.

Is your project related to bitcoins? I can imagine it is if it is used to buy bitcoins. That could indeed also be exchange-related.

So what I'm now trying to figure out is if your project would be suitable as a plugin for bitcoinx. The issue with p2p exchanges is that you CAN safely exchange bitcoins, but not other entities such as dollars (as you need a third party: a bank, or be georgraphically close to the counterparty). a bank is ok but it is open to fraud, as the bank is not part of your protocol.

- You provide a solution to this by having an escrow.
- The way bitcoinx works is that it uses "colored" satoshi as a proxy for dollars.

Both solutions have an advantage and a disadvantage.

Your solution:
adv: You get the real dollars on your bank account and are not dependant on some entity that will in the end provide dollars for your colored satoshi.
disadv: It's not entirely decentralized. If all banks collapse, p2p bitcoin exchange would not work anymore.

Bitcoinx:
adv: it's more p2p.
disadv: In the end it comes down to that you need trust that you can change your colored satoshi for dollars.(or other fiat)

... and the synthesis is ........:
Bitcoinx should use your service. In case someone wants to sell his bitcoins for dollars, but does not have a bank account, your escrow service would buy colored satoshi at an issuer that at least the receiving party trusts and send them to the receiver. as far as I know the colored satoshi vs. dollar rate of a single service should be constant (the negation of which also might be possible but gives me headaches when I'm trying to think about it. defaults etc. let's not think about this right now.)

It might be possible to couple (as in un-decouple) your escrow service and the colored satoshi issuer.

Maybe I'm running to fast, but I do see the value of your project as a potential addon for bitcoinx.

[dansmith]

I couldn't have boiled it down better than you did.

A robust p2p exchange should have multiple ways of payment:
- colored coins
- my SSL dumps method
- safety deposits with an escrow
- pure p2p without escrow using BIP38, where either both parties lose or both parties win
- you name it.

It is up to the parties to negotiate their payment method of choice.
A p2p exchange should have a pluggable architecture with API to connect various payment options.

[Xenland]

How do we prove trust in these SSL dumps? how do we know both the server and the client aren’t lying?

[dansmith]

Thank you for initiating public scrutiny:

SSL uses symmetric encryption, meaning both the server and the user knows the masterkey.
In order to protect dumps from being tampered by the user, we need to not disclose the masterkey to him.

This is achieved in this fashion:
1. The user starts his Firefox plugin indicating he is ready to login onto the banking website
2. The plugin tells the escrows server that it needs the masterkey
3. The escrow server generates the master key. Encrypts it with the bank's public key. And sends it to the plugin, which forwards it to the bank.
4. All the following traffic from/to the bank, the plugin first redirects to/from the escrow's server, who decrypts/encrypts the traffic and gives it back to the plugin.

This way the user does his banking while not knowing the master key.
The only downside is that the escrow can examine the dumps and see user's login/pasword.
I'm working on some smart crypto now to mitigate that.

P.S.
Yes, this is different from what I proposed in the first post, I should probably fix it.
Because in the first post I suggested that the plugin keep the symmetric key.
(I since learned that it is not safe)

[dansmith]

How do we prove trust in these SSL dumps? how do we know both the server and the client aren’t lying?

Actually the initial model (in my 1st post) stands. What I just proposed is an alternative model.
So, to answer your question:

Because all traffic user<--->bank goes through escrow's proxy, we can rest assured that these dumps are legit.

If the user fakes a request to the bank, say he immitates entering a sum of money and pressing send. In this case, the bank will respond "request denied" or "invalid request" and the proxy will log it. This way the user can't cheat.

But the bank can cheat indeed, no doubt about that. That's why the escrow will only accept transfers through reputable banks.
On a side note: imagine The Bank of America colluding with a bitcoin p2p exchange trader to scam users out of their bitcoins? Hey, why not If they do, it only requires the bank to cheat once to be blacklisted.

[dansmith]

Here's a cross post from another thread, we can continue discussion here:

But you cant really have non-disputable real-time trades happening in this way. It does not prevent the buyer from deciding, "well in fact no, i'd rather not make the bank transfer since the price has just shot down!"

NB: Please understand that my involvement in this thread is not because I'm sceptical about colored coins. By no means. The more ways to enable p2p, the better. I just saw this comment and wanted to respond.

This is how SSL dumps enable real-time trading (with a caveat). Both the buyer the and seller agree to transact a real-time trade. The buyer automatically logs into his website (or his OFX API terminal) and performs the money transfer. The escrows server analyzes SSL dumps in real time and signals to the seller that money's been sent. The seller releases BTC.
The only caveat is that the buyer can revoke the transfer by contacting his bank. But the revocation is not hassle-free (I'd hope) and the buyer's real name and bank credentials are known to the escrow. So why would he revoke the payment.

[greBit]

Here's a cross post from another thread, we can continue discussion here:

But you cant really have non-disputable real-time trades happening in this way. It does not prevent the buyer from deciding, "well in fact no, i'd rather not make the bank transfer since the price has just shot down!"

NB: Please understand that my involvement in this thread is not because I'm sceptical about colored coins. By no means. The more ways to enable p2p, the better. I just saw this comment and wanted to respond.

This is how SSL dumps enable real-time trading (with a caveat). Both the buyer the and seller agree to transact a real-time trade. The buyer automatically logs into his website (or his OFX API terminal) and performs the money transfer. The escrows server analyzes SSL dumps in real time and signals to the seller that money's been sent. The seller releases BTC.
The only caveat is that the buyer can revoke the transfer by contacting his bank. But the revocation is not hassle-free (I'd hope) and the buyer's real name and bank credentials are known to the escrow. So why would he revoke the payment.

Normal behaviour:

1) Buyer and seller agree a contract
2) Seller puts Bitcoin into escrow
3) Buyer pays seller and proves to the escrow people that this occurred with the SSL logs
4) Seller releases Bitcoin to buyer

Bad behaviour which would prevent real-time trading:

1) Buyer and seller agree a contract
2) Seller puts Bitcoin into escrow
3) Buyer sees that the price of Bitcoin has crashed and decides not to go through with the deal.
4) Seller is pissed off and loses trust in the marketplace.


That was my point, the level of commitment with your proposal is biased. The seller commits, the buyer does not - as there is no escrow for his fiat.

The whole point of colored coins is that it makes both parties commit to the deal. Neither can back out. Which means the system can be trusted and deals can be performed in near real-time (still need to wait for confirmations)

[dansmith]

Let me reinforce what I said earlier in another thread - yes colored coins are the way to go and they have their niche.

It seems to me you are not taking into account that:

3) Buyer sees that the price of Bitcoin has crashed and decides not to go through with the deal.

It takes literally seconds from the moment the Buyer clicked "I agree to buy" to the moment when his browser plugin logged into his bank account and sent the money and forwarded SSL logs and escrow released BTC.

Unless, the market crashes in the time window of 5 seconds from clicking "Buy", there is no danger.

[dansmith]

Sorry, maybe I'm omitting crucial details from my description which make my point harder to digest.

The firefox plugin is linked to the p2p exchange's account of the buyer. As soon as the buyer presses "Buy", it's all automatic from then on and he can't bail out.

The seller knows in advance that the Buyer has the plugin and the Seller refuses to accept orders from any Buyer who is not using the plugin.

[Xenland]

How do we prove trust in these SSL dumps? how do we know both the server and the client aren’t lying?

Because all traffic user<--->bank goes through escrow's proxy, we can rest assured that these dumps are legit.

Oh nice, so the trust comes from your "favourite" escrow. gotcha! So now you just need an app/browser that will send the SSL keys to the escrow after the client is done, atleast im guessing anyways there are so many alt proposals on here its too much to read'em all

[dansmith]

You are not being sarcastic, right? Sorry, if I misunderstood.

Yes you are right, after the user is finished, he submits his SSL keys to escrow, so that escrow could ascertain that a transaction has been made.
The escrow can set up a server which automatically decrypts SSL logs, parses them and signals to the seller of BTC that all is well. Thus enabling real-time trade.

[Xenland]

You are not being sarcastic, right? Sorry, if I misunderstood.

Yes you are right, after the user is finished, he submits his SSL keys to escrow, so that escrow could ascertain that a transaction has been made.
The escrow can set up a server which automatically decrypts SSL logs, parses them and signals to the seller of BTC that all is well. Thus enabling real-time trade.

If your talking to me I'm slightly sarcastic as I'm just worried about the escrow "controlling the clickes" if they have the ssl keys. but im assuming they send the keys "after" the tx has been made.... okay so what about "approval" the other party will review the SSL dumps and make sure the tx has been made? its hard to process HTML let alone make sure the balance went through that takes some brain power with out a specific outputs.

[dansmith]

@Xenland, yes I was addressing you.

You are worrying that escrow basically is listening in on your banking session.
What are the worst outcomes from that. Grading from worst to less severe.

1. The escrow (or an attacker who compromised the escrow) makes a fraudulent bank transfer from your bank account while the SSL session is active. This probably also means that the attacker will not disclose the SSL key to the plugin after you're finished banking (The attacker doesn't want your plugin to examine your SSL logs an alert you that the wrong amount of money was sent). Your plugin will treat the fact that the attacker didn't send you the SSL keys immediately as a red alert.
Solution: as soon as your plugin alerts you. Pick up your phone and call the bank and cancel the transfer, call the police. The escrow loses business and reputation. You get your money bank.

2. The escrow (or attacker) knows your log-in and password.
Solution: this is the last kink that I need to work out in my model using some smart crypto technique. There is no reason why escrow should know that in the first place. It is hard to rip this bit out of the SSL sessions trafic.

3. The escrow (or attacker) sees your name, bank statements, transaction history.
Yes, you can't hide your name.
Solution: when doing the escrow-controlled SSL session , don't go around clicking all your page. Go straight to the payments section and make a payment and log out.

I guess this covers all threats from allowing an escrow to control the SSL session.
I'm hoping to soon find solution to number 2.

okay so what about "approval" the other party will review the SSL dumps and make sure the tx has been made? its hard to process HTML let alone make sure the balance went through that takes some brain power with out a specific outputs.

It is hard, indeed. We need to create per-bank tools/parsers which simply parse the HTTP request. It's not that hard actually, we don't need to parse the HTML. Because when user enters the sum and clicks send, his browser sends a simple HTTP POST request and bank responds with OK or Error (I'd hope that's the case, this needs checking on a per-bank basis).

[phathash]

The bank only signs the symmetric key, not the content. What stops the user impersonating the bank's server after the fact?