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

@nomailing
Thank you for your enthusiasm!

The proof-of-concept version will work this way:


1. Only buyers from those banks will be able to partcipate, which show on their statement at least the date, the recepient account and the sum.
Many banks do show this bare minimum of info, but notably HSBC, however, does not show the account number of the recepient.
We will create some incentives for users to submit screenshots of their bank's statement pages (edited of course), so we could build a database of approved banks. Potentially, of course, any bank in the world can participate in the exchange as long as proper data is shown in the statement.

2. The BTC part of exchange will be 2-of-3 multisig (buyer,seller,escrow) addresses only. So, no running away with customer's BTC for escrow. Both buyer and seller will be expected to put collateral (10% of the purchase) into a multisig address. The seller puts his BTC into a multisig address as well. If no dispute is raised, the seller releases the funds to buyer and the collateral is returned. Of course all the GUI tools will be provided to both buyer and seller, so they don't need to know the mechanics of multisig.

3. If a dispute is raised, the buyer performs an audit by routing his Firefox's traffic through the oracle while opening his banking statement page.
The oracle then forwards the ENcrypted SSL log to the human escrow.

A banking session usually consists of multiple SSL connection, each havng a unique decryption key. So the buyer will forward to escrow only that key which is required to decrypt that particular HTML statement. This is enough to prevent the escrow from learning the login credentials (as those credentials reside in a different SSL connection and hence require a different decryption key).


If the oracle concept proves successfull, we can have the buyer set up his own oracle on Amazon Cloud and perform audits on himself if necessary.
But since any would-be scammer knows in advance what the outcome of his fraud will be, I expect next to 0 disputes, which means it will be inconvenient for a user to pay the costs of running an oracle that is used so rarely, and thus there will be a market for escrow's oracles.

That sounds great! Can't wait to see the proof-of-concept!

How did you finally ended up implementing it? Did you change anything from your initial proposals?

What functions of the escrow do you plan to implement on the Amazon Cloud? Seems like an excellent idea. Do you plan to have the proxy, which records the banking session, in the cloud? And then the fiat-sender can submit what pages would have to be decrypted as proof-of-payment?

Wow, can't believe it's been now 3,5 months we've been sucked into development of this project.
A lot of R&D has been done by me and waxwing, code has been written.
Stay tuned for a proof-of-concept launch.

In the meantime, I posted a thread soliciting peer review on setting up an Oracle on Amazon Cloud.
https://bitcointalksearch.org/topic/setting-up-an-oracle-machine-on-amazons-aws-301538
Some of escrow's functions discussed here will be delegated to an oracle.

For the "holy grail" bounty we have a piece for legacy banking integration.

Basically build what you are discussing into our QT C++ application for 12 BTC bounty:
http://ciyam.org/open/?cmd=view&data=20130608221956480000&ident=M100V131&chksum=e257f8e6

You will have full access to the OT API and the Bitmessage API, and I will make any necessary changes inside OT itself in support of you.

When I was auditing the finances of a non-profit last year, the PDF statements from a Canadian bank were not properly signed. I decided to give the executive director the benefit of the doubt that he was not tampering with them; even though he probably had the technical know-how to do so.

Bank-statements don't actually list specific account numbers of the recipient anyway. My bank statements say something like BR-to-BR when I buy a money order or send money to another person.

Yes.

The problem is that there is no mechanism to enforce this. Once you proxy the SSL session through Betty, the data is out of your hands. It is up to Betty to decide what to do with it. She may decide to publish it on the web, or she gets hacked etc. You can enact no further control over it.

When you give the SSL crypto key to someone you kind of have to assume that this person will have the whole SSL session including the credentials, no?

To quote myself in post #84:

Adam WILL NOT share his password with either Betty or Escrow. Adam will only explicitly mark those pages that he wants Escrow to see.

phillipsjk, the link you gave described the scheme in its germinal form. It began evolving around the time when waxwing joined the discussion. I should probably go ahead and re-edit the initial post.

Doesn't the bank usually use SSL to encrypt authentication mechanisms like passwords? would that not be included in the dump?

Edit: If the escrow has the encryption key, what prevents then from editing the logs? Are people expected to use the escrow's credentials to ask the bank directly?

Edit: found the actual post explaining the scheme. Still don't like it.

If my bank requires me to use an anti-virus, they probably require me to not share may password with random people on the Internet.

To minimize the risk of a Sybil attack, there should be a web of escrow agents, and they will be randomly forwarded dispute settlement requests based on their performance rating as an escrower and in addition, the amount of bitcoins they deposited which is a prerequisite by the network to be an agent, so as to further limit the ability of say, governments to disrupt the network.

Its not a big problem I was just trying to clarify things.

In the event of a dispute I guess the buyer should just assume that the escrow could gain access to his credentials. So before sending the escrow the SSL session key, he would change his banking password

Yeah, but the whole idea of using escrows also depend on trust. You must trust your escrow won't collude with the other party.
And btw, it seems in the example above Betty was both the person holding the encrypted data and the BTC-seller. It doesn't need to be the same person, there can be a second intermediary.

It's hard to completely eliminate the need of trust, but you can make it much safer nevertheless. And eventually you could even have automated p2p exchanges (if your bank provide you an API to handle your fiat), what could be quite cool. Payment processors, for instance, could shift part or even all of their exchanges to this p2p system.

I understand there would be various ways of indicating to Betty what constitutes the subset of encrypted data to send on to the Escrow.

But it still requires a level of trust ... we ask Betty kindly to only forward on our marked pages and not the whole session.

Adam, while browsing his banking website, explicitly  marks those pages that he wants Betty to hand over to Escrow.

There is room for possibilities of how Betty could recognize which encrypted traffic to hand over. One of them is Betty remembering the timestamp at the time when Adam does the marking. Subsequently, Betty could hand over only packets that were transmitted at that time. Another solution could be Adam hashing the encrypted packet as it leaves his wire and then requesting that Betty hands over only packets which match Adam's hashes.

EDIT: mixed up Adam's and Betty's roles.

So Betty has Adam's online banking session in encrypted form. In case of a dispute, Betty is required to hand over a subset of this encrypted data to the Escrow.

How is this part enforced? How does Betty know which parts of the data to send? What if she just sends the whole thing? Could she not decide to expose Adam's credentials to the Escrow by sending the whole SSL session?

Thanks for that fghj. It seems clear even though google translate is failing me there.
I did some searching a couple of weeks back but could only find one example: ICICI bank in India. And it wasn't even obvious that they were still doing it.
I'm not aware of any major bank in the developed world doing it; and my bank, one of the biggest in the world, doesn't do it.

To reiterate, if this were done then this thread would be redundant imo.

This might be of some importance:
http://www.multibank.pl/dla_ciebie/multikonta/wyciagi/jak_zweryfikowac_pdf
http://www.dobreprogramy.pl/Podpis-elektroniczny-na-wyciagach-z-MultiBanku,Aktualnosc,3121.html
Apparently some banks let you download signed pdf's since 2006.

Good work. This is the coal-face of the interface with legacy banking and they must use internet technologies ....

First, an update.

We have successfully tested the model:
client -> proxy(transparent) -> bank.
That is to say, we can decrypt the session on the client side, have the proxy store/log the session in ONLY encrypted form, and then later pass across the session key and decrypt the log on the proxy (or any other machine).

To emphasise, we are NOT using mitm on the proxy. The proxy never sees decrypted data unless someone gives him the session key.

This was a proof of concept of the basic architecture. It's not a surprise that it basically works, there was no fundamental reason for it not to.
All based on open source: firefox, wireshark/tshark,squid.

Where we go from here is up for debate.

But let me address some of nomailing's questions from earlier (sorry for the delay in getting back to you..)
------------------------------------------------------------------------------



First, renegotiation is actually disabled by a large proportion of banks anyway, so we don't rely on it in our architecture. Second, the disadvantage of seeing the whole session without renegotiation has already been addressed in #61: if an audit takes place, the BTC buyer reviews the html pages from the recorded session (on his machine it's all unencrypted of course) and CHOOSES the pages he wants to expose to the escrow. The system then passes the ENCRYPTED SSL application data FOR THOSE SPECIFIC PAGES from the BTC seller to the escrow, so that the escrow only ever sees those html pages that the BTC buyer wants him to see. No one will ever see the entire internet banking session if you don't want them to (and you don't). You will allow them only to see the "send wire" page and the "confirmation" page, in most cases.
Of course collusion between the escrow and the BTC seller breaks this. But anything with escrow is broken by collusion. We can discuss this more later, but I want to get on to something else:


I think I need to explain better why I switched from proposing recording the banking session only in case of audit to always recording the fiat-sender's banking session.

It's a result of the way banks operate. They do not consider it essential to display all relevant information to the user. For example, an online bank statement might have a record like this:
CREDIT: USD

rather than
CREDIT: USD

See the difference?
From the user's point of view, since the amount is the same in both cases, the first version is "good enough" to confirm the receipt of a wire. If that user needs more details they might have to use the phone or an email to get that information.

Now perhaps in YOUR internet banking software, these details are exposed, but they aren't in mine (and I checked very carefully).

So I thought about this and I realised that at the moment of actually SENDING the wire, these details HAVE TO BE DISPLAYED.
Because if they weren't displayed, the user could have no confidence that they were actually sending the right amount of money to the right recipient. Every internet banking that has wires enabled at all will have to display:


So basically: the process of sending has to transparent to the user at the time of sending. The process of receiving is going to be recorded in various opaque ways. And even for the sender, if reviewing the transaction later, it may not be displayed in detail.

That's why I reverted back to the model "record the sending, but keep it encrypted and unreadable unless there's an audit."

I know that it's a huge advantage to not record the sessions by default, but you would have to tell me how to deal with the case of my own bank, where I can clearly see that the account numbers of wires I've received (or sent, believe it or not) are not being displayed.

OK there's a lot more to answer and to say but that's enough for now.

I am just comparing the two possibilities which you presented:
#1 The BTC seller is the gateway
#2 A fourth party is the gateway

I see only negative points with #1 and only positive points with #2. Let me elaborate:

I think many users would like to trade without recording their online-banking session if there is no dispute. You already proposed earlier that the method could be used after a dispute only. I personally would like that much more. But then you would have to wait maybe 1-3 days until the wire-transfer cleared and only then you would have to eventually enter the dispute process and use the proxy. It's not quite clear that the BTC seller is online at that time.

I, personally, would try to minimize the use of the proxy, because proxying an online-banking connection increases the risks (i.e. man-in-the-middle attacks as described in CVE-2009-3555). Your risks increase even more if you cannot use SSL-renegotiation during this banking session (i.e. your full recorded SSL-session is exposed to one party and could be decrypted using your master key, which you have to expose at least to another party). I personally would like to minimize both these risks and I also don't like to change my online-banking password so often.

Maybe you could persuade me to always expose my online-banking-session and the corresponding session-master-key if you could elaborate more on your proposal to use

I don't see the extra level of complexity, because you have to implement some form of randomly choosing the escrow anyway. So you can also use the exact same algorithm to select an independent gateway.


I think your proposed solutions are really very good and I hope this will work. I am just comparing the options which you (and dansmith) already suggested earlier and at the moment I would conclude that it is much better to only record my banking session in the case of a dispute. And I see this only if the gateway is another user, because then nobody has to be online at the same time. Otherwise it would get really hard for some parties to proof that the gateway was online or was offline and if the connection was possible or was not possible because of some network failure or whatever. If the gateway is a party which is involved in the trade, it could get very hard to proof anything. If the gateway is choosen randomly at the time when it is needed, then you can proof something at all times independent from the other party.