tlsnotary - cryptographic proof of fiat transfer for p2p exchanges

[fghj]

If the bank actually did cryptographically sign its outputs and send that in a decrypted form on request (e.g. a bank statement), we wouldn't need any of these shenanigans, but .. they don't.

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.

[1714041918]

1714041918

[1714041918]

1714041918

[waxwing]

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.

[greBit]

I have a new suggestion, melding together several of the ideas already mentioned:

Adam is going to pay Betty USD in return for Bitcoins.

1. Betty puts Bitcoins into escrow
2. The software starts a proxy server on Betty's machine for Adam
3. Adam connects to his internet banking via the proxy.
...
4. Betty's proxy server logs the entire banking session in ENCRYPTED form. Also, Adam's software logs the whole session too, in unencrypted form.
5. If the wire transfer is successful, everyone is happy, no need to do more. If Betty disputes that the wire is received, then:
6. Escrow agent is called in. Escrow agent requests Adam to identify from his logs which pages he would like to provide to agent as proof that he did carry out the wire transfer.
7. Escrow agent requests those specific pages (which remember are still encrypted) from Betty.
8. Escrow agent requests master secret key from Adam
9. Escrow agent can decrypt the specific intended pages and verify that the wire was sent.

Plus points about this approach:
*As long as both sides have the necessary software installed, then if the transaction goes through normally, no one has to do actually *do* anything to ensure trust.
*Adam (the USD sender) has control over which HTML pages he sends to escrow in case of an audit. Normally it will be the last one or two pages of the banking session, and it may well be possible that he doesn't have to reveal any other transaction, or his balance.
*By using the counterparty as the "gateway", we remove the incentive for collusion. This is a brilliant idea and full credit to dansmith for it.

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?

[dansmith]

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?

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.

[greBit]

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.

[caveden]

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

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.

[greBit]

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.

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

[oakpacific]

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.

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

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.

[phillipsjk]

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.

[dansmith]

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 quote myself in post #84:

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

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.

[greBit]

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

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

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?

[dansmith]

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?

Yes.

[phillipsjk]

Apparently some banks let you download signed pdf's since 2006.

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.

[fellowtraveler]

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.

[dansmith]

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://bitcointalk.org/index.php?topic=301538.0
Some of escrow's functions discussed here will be delegated to an oracle.

[nomailing]

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://bitcointalk.org/index.php?topic=301538.0
Some of escrow's functions discussed here will be delegated to an oracle.

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?

[dansmith]

@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.

[nomailing]

What I really like in this concept is that the gateway is only needed in the case of a dispute . In my view, that is a key point to be practically usable without too much complexity, because as you said a dispute will almost never happen.

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).

Are you sure about this point? I always thought that a banking session consists of only one single SSL connection... And I thought some banking websites do not even allow SSL-renegotiation. Did you try this out on several websites?


Anyway, this system should be able to allow decentralized fiat/bitcoin exchange. But when I think about the big picture to use this for a p2p exchange I still think there are some challenges and I am wondering how you plan to tackle them:
1. Did you thought about the legal aspects as well? I am wondering if AML laws would forbid to use such a system, because you might not know the person from whom you would accept the fiat transfer. Therefore criminals could use this system to transfer money from hacked bank accounts into Bitcoin and disappear. Therefore it would involve high risks to use this system and accept these anonymous fiat transfers!
2. The system needs a decentralised orderbook with spam prevention
3. How do you make sure that the escrow is chosen randomly

Maybe you could solve all three problems together if you have a very simple semi-anonymous identity system where each identity is associated with a hash of the bank-account-number? This could solve all three issues together:
1. The AML problem would be mitigated, because you would only accept high volume fiat transfers from users having a history of trades. Thereby you can be much more sure that the account really belongs to that user. In this scenario new users would initially have to build trust by trading only a small amount like 1 USD or 1 EUR and thereby validate that they are really the owners of the bank accounts. This would be similar to how some centralised exchanges validate the bank-accounts of users due to AML laws.
2. You could prevent spam because massive orders using the same bank-account could be discarded by the p2p clients.
3. The p2p system could randomly choose escrow users from the public list of user-ids.

The system would still be quite anonymous, because it stores only the hash of the bank-account-number. Therefore only your direct trading parters would see your real identity because you anyway would have to reveal your bank account details to them. But they could use this decentralized hash store to check for your trading history to make sure that you are not a scammer.

[marcus_of_augustus]

I gotta say guys this is one mean hack onto the legacy banking system that warms the cockles of my heart almost as much as crypto-currencies themselves do ....  the nous, moxy and genius makes for a delicious combination if you can pull it off ... it really says, "you are playing on our turf now". 

[dansmith]

@nomailing

The questions you raise wrt AML, orderbook spam and randomly chosen escrow are all valid and warrant consideration. They will however be not implemented for the proof-or-concept launch. Really what I'm concerned about at this juncture is providing free tools which existing crypto-only exchanges can plug into their infrastructure.

wrt SSL:
a banking session consists of one SSL session. However a single SSL session contains dozens on SSL connections. Each of those connections uses a unique encryption/decryption key.
You are right in that banks don't allow renegotiation, but we don't use it anyway. Renegotiation implies starting a new SSL session, not a new SSL connection.

You can try it out yourself and ascertain that there are multiple SSL connections withing an SSL session, this way:
1. You must use Firefox and add an environment variable SSLKEYLOGFILE=/home/user/sslkeylog
(on Linux we use export SSLKEYLOGFILE=/home/user/sslkeylog and then launch Firefox from the same terminal)
2. Start Firefox and visit a https website like https://www.mozilla.org
3. Look in you sslkeylog file: it will contain dozens of CLIENT_RANDOM lines.
Each of those lines can usually decrypt only a single GET request and server's response.

Start clicking around and you will see how the entries in sslkeylog grow. For every click you make, a new SSL connection is started.