Bitcoin Forum
December 03, 2024, 03:43:33 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 »  All
  Print  
Author Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges  (Read 42856 times)
fghj
Member
**
Offline Offline

Activity: 65
Merit: 10


View Profile
June 08, 2013, 08:55:12 AM
 #81

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.
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 253


View Profile
June 08, 2013, 11:33:09 AM
 #82

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.

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
June 11, 2013, 09:15:53 AM
 #83

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 (OP)
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
June 11, 2013, 01:21:14 PM
 #84

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

https://tlsnotary.org
Transferable webpage content notarization.
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
June 11, 2013, 03:04:57 PM
 #85

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
Legendary
*
Offline Offline

Activity: 1106
Merit: 1004



View Profile
June 12, 2013, 06:10:50 AM
 #86

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
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
June 12, 2013, 10:17:16 AM
 #87

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
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
June 13, 2013, 05:33:12 AM
 #88

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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
phillipsjk
Legendary
*
Offline Offline

Activity: 1008
Merit: 1001

Let the chips fall where they may.


View Profile WWW
June 14, 2013, 06:29:19 PM
Last edit: June 14, 2013, 07:50:20 PM by phillipsjk
 #89

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.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
dansmith (OP)
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
June 14, 2013, 07:58:12 PM
 #90

Quote
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:
Quote
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.

https://tlsnotary.org
Transferable webpage content notarization.
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
June 15, 2013, 08:34:48 AM
 #91

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 (OP)
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
June 15, 2013, 12:52:36 PM
 #92

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

https://tlsnotary.org
Transferable webpage content notarization.
phillipsjk
Legendary
*
Offline Offline

Activity: 1008
Merit: 1001

Let the chips fall where they may.


View Profile WWW
June 15, 2013, 05:33:24 PM
 #93

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.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440
Merit: 251


View Profile
June 15, 2013, 11:13:16 PM
 #94

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.

co-founder, Monetas
creator, Open-Transactions
dansmith (OP)
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
September 27, 2013, 06:41:16 PM
 #95

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.

https://tlsnotary.org
Transferable webpage content notarization.
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
September 27, 2013, 07:49:03 PM
 #96

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?

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
dansmith (OP)
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
September 27, 2013, 09:01:42 PM
 #97

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


https://tlsnotary.org
Transferable webpage content notarization.
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
September 27, 2013, 11:38:56 PM
 #98

What I really like in this concept is that the gateway is only needed in the case of a dispute Smiley. 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.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3920
Merit: 2349


Eadem mutata resurgo


View Profile
September 27, 2013, 11:50:11 PM
 #99

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".  Cheesy

dansmith (OP)
Full Member
***
Offline Offline

Activity: 202
Merit: 100


View Profile
September 28, 2013, 09:00:31 AM
 #100

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

https://tlsnotary.org
Transferable webpage content notarization.
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!