Bitcoin Forum

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!

interesting idea!

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)

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

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.

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

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.

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.

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

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)

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.

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


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)

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:


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.

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.

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

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.

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

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

Ah okay that makes more sense, and I'm glad you realise there are some kinks to work out and looks like your on top of it, Good luck mate!

This!

@greBit


I realize that I am actually proposing two solutions:
#1. Escrow controls the SSL key
#2. User controls the SSL key, but all user's communication with the bank goes through escrow's proxy.

#2 is easy for bank to shutdown. The bank will simply block the escrow proxy's IP address. Hence I concentrate on #1 as a more resilient solution. So, to answer your question in #1 context:

Every packet that the user sends/receives to/from the bank is first submitted to the escrow for decryption/encryption with SSL key.
After the SSL session is completed, escrow releases the SSL key to the user. This is needed so that the user can check out his bank session and confirm that escrow wasn't spoofing any packets.

You see, there is no room in this set up for the user to impersonate the bank. The SSL masterkey is unique to the SSL session. Even though the user knows the SSL key after the fact, he can do nothing with it apart from decrypting his own logs.  He cannot use this masterkey for a future SSL session, because there will be a new SSL key for every new session.

Does it explain it?

P.S. I guess I should stop calling it SSL master key - it conveys a feeling as if it was a super-key used for every connection. In the SSL RFC it is called "master secret"

Are you still working on this dansmith?

It's taken me a while, but I'm getting a clearer picture of this now, slowly. First, I'd like to know why you think the proxy model (option #2 in the previous post) is vulnerable to banks shutting them down? The escrow agent could be chosen at random from a group of P2P clients. Surely the bank has no way of knowing anything about it. Just as they would accept my connection from another state or country.

And in that version (#2) how exactly would a user spoof the bank's side of the connection? I get that they have the master key to encrypt data, but if the escrow is sending requests to the bank IP, surely the response has to come from there too?

Not development-wise. I simply put out the idea. After I discovered that "colored coins" will get us faster to a decentralized exchange, as opposed to SSL dumps which is a temporary crutch, I am totally immersed with colored coins.

waxwing, I applaud your grasping the technicalities of this matter so quickly.
I know it is hard to wrap one's mind around initially.


(First let me define the terms. The person who will be selected from a P2P group should not be called "escrow agent", but rather should be called "the gateway user". The gateway user works on behalf of the escrow agent. The gateway user will submit SSL logs to the escrow agent when the banking session is finished.)

Yes, if it is randomly chosen from a p2p group, then it will fly.
The caveat is that eventually the same member of the p2p group will be chosen multiple times. The bank may flag such a member as a potential participant in a p2p exchange.
Another caveat is that altruistic bitcoiners will not subscribe to be added to a pool of potential proxies unless they have an incentive. The incentive will be that those who add themselves to the pool are themselves participants in a p2p exchange. But again, there may not be a significant amount of participants and so the participants will be proxying bank sessions many times a day which will get them flagged by the bank.

Correct me if I misunderstood what you are asking.

with #2 spoofing of the bank-side traffic by the payer is impossible indeed. The escrow receives the traffic from the bank.
With your p2p pool idea though, if the payer and the gateway user are in cahoots, then the user can give the gateway user the encryption key. Then the gateway user can spoof the SSL dumps as if they were coming from the bank and submit those spoofed dumps to the escrow agent.

Feel free to ask for further clarification.

Can colored coins address this fiat transfer problem in any way? My rudimentary understanding is that it's a way of using coins to represent property. I can't see how it would help with the problem being discussed in this thread?


OK, that's another model. I can see why it might be preferable. Not sure, but it's not a critical issue either way.

Yes, but to me that's the essential ingenuity of the P2P aspect; as the network grows it becomes more and more impossible for the bank to find anything to attack (no CPOF etc etc). I don't see a negative here, only a positive.

Quite, incentive is key. The software can help us provide the appropriate incentive.
EDIT: to answer your point more fully, your "gateway user" could be anyone on the network, and your "escrow agent" could be a special class of user (that little bit of quasi-centralization might be safer if thus abstracted from the direct bank connection).

This doesn't look like a problem realistically.
If the gateway user (in your terminology) is not chosen by each counterparty in the transaction, but by the P2P software, there is no realistic chance of collusion. (Any escrow model is of course broken if the escrow is colluding with one side of the transaction.)

I'm feeling more and more positive about the feasibility of this, *except* that from a technical standpoint it's really pretty complex.

Another thought:
since the only "attack vector" is the BTC seller fraudulently denying receipt of the USD into his bank account (and his account number was specified on user creation, or in any case in advance of the tx), we don't have to enable the SSL "snooping" procedure by default.
The BTC buyer/USD seller never needs to be involved in this, which is good because the process of actually *sending* a wire is particularly sensitive.

What we could do is to only initiate this process when there is a dispute that needs to be arbitrated, and only apply it to the BTC seller:
If BTC seller denies receipt of funds, escrow agent (who currently has the BTC locked in a 2 of 3 scheme) requests initiation of bank account verification process. This involves using the browser plugin as you described, and *after* login, the SSL session is "snooped"/dumped. The key would be that you would demand the BTC seller to display his *statement* for the period in question, and by doing so you would be able verify whether or not he received the contracted amount from the BTC buyer during the specified date/time period.
If the statement clearly shows that the amount WAS received, then you have one embarrassed liar of a BTC seller. Escrow releases BTC to buyer and BTC seller is possibly banned or black-marked; they could rejoin the network under a different BTC address, but they'd need a new bank account for what that's worth.

It's a technically difficult process but the key point is that it only needs to happen when there's a dispute. And if it works, it would remove a lot of the incentive for anyone to try to con the system, so it would be even less likely to occur.

Colored coins (CC) facilitate decentralized real-time exchange. This is mainly aimed at full-time traders.
For casual purchases the SSL dump scheme seems better fitted.


You can use CC to represent property, like 1 USD. There must be an emitter of . The emitter accepts USD and issues CC in return. With CC, full time traders don't need to make a money wire into the exchange and risk the exchange being shut down and all their USDs frozen. Full time traders can now trade BTC for CC (on the blockchain) in a high-frequency trading fashion. Later the trader can take his CC back to the emitter and redeem the USD.
Needless to say, the emitter charges a small fee for the service of issuing CC.

As far as the rest of your post, I concur with everything.
Now, let me process your "Another thought"...

What you proposed simplifies the scheme by orders of magnitude but defeats the initial idea of near-real-time trading.

The weak point is that the buyer will simply waste the sellers time by putting in an order and then refusing to send funds because the BTC market price shifted unfavourably to the buyer. This was already observed on bitcoin.de which is a p2p exchange. This has the effect of discouraging the seller to participate on such exchanges.

By using the SSL scheme, as soon as the buyer presses the "Buy BTC" button, the browser plugin immediately transfers the funds and informs the seller that money's been sent. Such an exchange would attract way more sellers than bitcoin.de's model.

Colored coin is a great idea, but I don't think anything like an emitter is very P2P. To be strongly resistant to crackdown, the bank transfer must be carried out between buyers and sellers, rather than sellers and a service provider.

I should first say thanks for the detailed responses, it's been very useful for me.
OK, that's clear - I was never looking for a real time fiat-BTC system, but only a way of transferring fiat into BTC that wasn't vulnerable to an attack on a central point of failure. I realise that a lot of people are focusing on the real time aspect.

That's a very interesting point you raise.

First, the terms of the contract should be clear to the user at the moment of accepting it, i.e. the price they promise to pay.
I don't think a small delay (in my non-real time system) is either here or there. There will be some indicative time requirement per user depending on their circumstances. If they delay too long, the other side will pull out and they might lose some reputation.

But if we imagine a high-volatility scenario where Bitcoin price is collapsing, I can see that this model is going to be ineffective. The buyers of BTC will just pull out whenever they don't think the price looks good any more (over a period of hours). That's inevitable in a non-real time system. The same is of course true with localbitcoins - if there is huge price volatility there will be a lot of time wasting going on with people backing out of deals. But backing out is a second order problem, the system can still function in terms of not being amenable to fraud.

(I'm sure colored-coins, smart property type ideas can be a solution to the real time problem by having an intermediate step without exchange rate risk. I'm sure you and others are looking into that :) )

It just sounds a bit technically infeasible to me. I often wire money, and quite aside from the difficult of parsing my bank's data automatically, you'll have to deal with all kinds of edge cases like, you press "send wire" and it sends back a kind of warning page saying it's after banking hours or something, and then you press another button and... I understand we can build parsers for each bank individually, but I can't see it working like that. On the other hand, using the SSL session dump for *auditing* seems very workable, even if that is still pretty hard!

+1

Interesting.

Provided the data from the bank has the right characteristics, why couldn't an oracle be used as the escrow "agent"?

I think the data from the bank can always be faked, however for SSL connection, they will somehow be signed by the bank, and thus can be potentially used as proof of transfer.

I think this is an important idea and you should continue working on it.

@waxwing
Yes, the real-time scheme involves maintaining parsers for each bank taking into account corner cases.
Your auditing scheme is way easier to implement, because no parsers are needed. The escrow agent can examine SSL logs manually in rare cases of dispute.

So I'm left wondering about next steps. I'm thinking about avoiding wheel reinvention. This SSL thing could latch itself onto another system, like the opentransactions/bitmessage thing that fellowtraveller is working on. In my thread ( https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078 ) I was trying to build an architecture from the ground up, but I'm not sure how much of that proposal is really adding value.

For actually building the SSL dump / proxy etc. part - I'm far from the ideal candidate to kick it off, having only a few years experience as a software engineer, and that some time ago. If I wanted to do that myself, I'd need to spend a lot of time reading and experimenting with the basics. Someone who already has experience working with SSL and networking software generally might get a prototype up and running far quicker.

In any case, I will make a start of my own on it. Does anyone have any suggestions? Will OpenSSL help me?

As was pointed out earlier in the thread, the bank only signs at the beginning, after that the bank and the user share the master secret that's used for encryption of the data during the session. This means that the user can imitate the bank, but if the proxy stands between them, that's not a problem.

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.

I only have a vague understanding of what is meant by oracle here (I read https://en.bitcoin.it/wiki/Contracts) but certainly such a mechanism could help for normal operation (kind of automated escrow?), but I think to try to automate the "audit" process I'm suggesting above would not be wise.

waxwing, if you were to implement it, take the simplest path.
Put aside random selection of a gateway user from a p2p pool. Also put aside the proxying of SSL traffic through the escrow agents server. The simpler scheme is when the e.agent is in possession of the symmetric key for the SSL session.

The user (of online banking) first submits all the traffic (he wants to send to the bank) to the e.agent.
The e.agent encrypts the traffic with the key and sends the encrypted data back to user.
The user then forward that encrypted data to the bank.

I haven't done any research. What you need is:
Browser plugin needs to intercept the traffic coming to/from the bank and redirect it to the e.agent for encryption/decryption.
The plugin then receives from the e.agent the encrypted/decrypted traffic and displays to the user.

I bet OpenSSL has user-friendly tools to construct, deconstruct a packet. Or at the very worst, you can borrow their source code.

Yes, that might be simpler as a first iteration.
Putting aside the user impersonates bank attack for now.

Right now I'm looking at http://www.rtfm.com/ssldump/Ssldump.html. Could be what the doctor ordered.

A bit more digging led me to Mozilla's NSS:
https://developer.mozilla.org/en-US/docs/Overview_of_NSS
In particular:
https://developer.mozilla.org/en-US/docs/NSS_Key_Log_Format
and ssltap at https://developer.mozilla.org/en-US/docs/NSS/Tools

This stuff is open source and recent. Maybe Firefox specific.

Possibly Wireshark may be another element: http://www.wireshark.org/.

This quote of yours prompted me to re-emphasize, that:
the user cannot impersonate the bank in the case when only the e.agent knows the encryption key.
If the user was to impersonate the bank, the user had to submit to the e.agent SSL packets from the bank encrypted with the key. But the user does not know the key, and so he cannot impersonate the bank.

After asking Firefox folks on IRC, I realized that FF doesn't expose raw SSL packets.
The other solution from within FF is to write an add-on which would be a handler for https:// protocol - a task that probably only FF devs could pull off.

The remaining solution is from outside of FF. Assign an SSL proxy in FF settings. mitmproxy can be that proxy.
Some small changes to mitmproxy's code need to be made, so that mitmproxy channel the traffic first to e.agent (who has the key) and after that to/from user/bank.

Yes, if only the e.agent knows the key. I hadn't realised you were planning to make it work like that. Will it still be possible to prevent the e.agent from seeing the user's login details in this case?

Sorry for not reading the entire topic, I'm just answering the OP. If what I'm saying has already been said, just ignore me. ;)

It's a powerful idea, but there's only one thing that bothers me:


All traffic? As soon as I log into my internet banking my balance is displayed, together with latest transactions. Why should my escrow see that?

Can't the plugin have a sort of "print-screen" button, and only send the content of the current page when this button is pressed (together with the SSL session information, of course)? The user could then send only the receipt page for the transfer, which should be enough.

Don't worry, this stuff is kind of overwhelming for all of us!


We're working on that. Of course, we absolutely understand that the user cannot be expected to show their login details at any stage. For the limited version we are currently considering, it would be, we hope, more like what you describe: if the transaction goes through normally, you never have to expose any part of your bank account. If there is a challenge and an audit is needed, then your banking session is recorded, and yes that would mean exposing your bank account number (which you already had to do to join the network), possibly also your name (not ideal, I understand - there might be a way to avoid it, and your bank balance (also not ideal, I understand), but definitely not your login details. Giving the user, as you say, a button to press to start the recording would be the ideal situation.

It's tricky by any interpretation; verification means seeing two things: the bank account number (for the given bank) and statement covering the specified dates. It has to involve human intervention to look at this and parse it intelligently imo.

To answer the question "why should my escrow see that" - the difficulty here is we are trying to prove whether the BTC seller has received the promised USD in his account or not. That can only be resolved by seeing a list of transactions for the given date.


To dan_smith - mitmproxy looks like a very good tool. I also found Fiddler (fiddler2.com), which was very easy for me to install and use on my own Windows 7 box. Pretty much immediately, I was able to record and decrypt the SSL traffic coming from my own internet banking session. It claims to work with all browsers, I tried it in Chrome.

This page explains how to set it up as a proxy:
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/MonitorRemoteMachine
(Obviously the user will need to trust the certificate).

At first glance, it doesn't seem to be open source which could obviously be a deal breaker in terms of using it in a serious way.

One funny thing is that my bank (in Hong Kong) will only display statements in pdf form! But the pdf was dumped out just like everything else.

@waxwing

I wasn't actually planning for it to work like that. But after you suggested the post-session audit, this scheme kind of became the natural path.
The scheme itself will discourage any would-be fraudsters. And the actual audit will be a very seldom occurence. So there is no big risk for the seller to expose his login credentials. At the end of the day, the seller can change his banking password after the audit.

@caveden
Sorry, we are all over the place here with the proposed schemes.
The latest solution as proposed by waxwing is to expose your online bank's balances only in rare cases a dispute arises.
This is in contrast to the initial proposal, where I suggested that all banking session is exposed from the get-to even before there is an actual dispute.

You could show only the details of the relevant transaction. At least every internet banking I've used so far do display a "confirmation page" after a transaction is finished, and this confirmation page contains all relevant data for the escrow (source and target accounts, amount, date, description).
The only "inconvenience" is that the plugin wouldn't be able to automatically recognize the confirmation page - well, it could learn if it's a really fancy software with AI and all, but let's keep it simple please ;) -, meaning that the user should manually indicate that "this is the good page to save". That's why I mentioned a printscreen-like button. And as long as the internet banking displays the details of past transactions, the escrow could always instruct his clients on how to obtain proof of transfer in case of a dispute, meaning that in 'everything goes well' use cases, people wouldn't even need to bother with installing the plugin.

Yes I think you understand the basic situation. The problems are technical, and I see two:
1. If we want a "proof of sending", we have to record all sessions, whether there's a dispute or not. Then we have to know how to parse the output in every case. Ideally this would be automatic, and we would have to build parsers for every possible bank, which would be an unfeasible amount of work imo.
By only running the "recording" process for audit cases (cases of dispute), we can fall back on "manual parsing" (i.e. the escrow agent or other expert just reading the decrypted output and interpreting it). This is not as bad as it sounds, because tools like Fiddler which I've been using today will allow you to view the decrypted output in text, hex or html (obviously easiest!). In theory you get to see the web pages exactly as the user saw them.
Now the reason this is a problem is that the auditing version means looking at the *output* of the wire transfer, not the input, which means looking at a record of the BTC seller (and USD buyer's) transactions. I guess we could (and perhaps should) look at the USD seller/BTC buyer's transaction record too. But anyway in this model (audit only) just looking at the "wire transfer sent confirmation page" can't happen.

2. The other problem is the technical problem of "recording" only *part* of the SSL session, so as not to expose the most sensitive data. I don't think the user could first login to internet banking, and then switch on a proxy to start rerouting traffic via the escrow's machine (who would then dump all decrypted SSL output). That's what we want, but it sounds somewhere between tricky and impossible. There needs to be a solution to this.
Dan's fallback of changing your password after the audit is a great idea for a last resort (or for the sensibly paranoid), but it can't be the main idea there.

Just moving up a level for a minute:
I think users of such a system have to accept that part of the deal is that they make their banking transaction record available to at least one third party. Note that when we use bitcoin we are doing something similar with the blockchain.
This is, to some extent, the payoff for abandoning a centralized counterparty (bank, stock exchange etc.). Trust from openness if you will.

Still I totally agree that the ideal is to only expose THIS transaction - not to expose your name, your bank balance, your other transactions .. and all the other stuff.
But let's be clear - this exposure is only to one other party, who may be living on the other side of the country, and has never met you, and more importantly: this will in most cases never happen - it will only happen if one side is lying about their transaction, and they will be STRONGLY disincentivized to do this exactly because there is a strong audit process in place.

There is an un-practical solution to recording only part of SSL session.
It can be done only if the bank supports SSL re-negotitation.
The user navigates his banking website to a certain page and then re-negotiates the SSL connection so that the e.agent is now in charge of the SSL key and sees only that particular page and not any previous pages, which includes not seeing the login page.
I examined SSL certificates of the largest western-world banks and the tally is that only 50% of banks support SSL re-negotiation. But what kind of user under normal circumstances does SSL re-negotiation? And so it will be very easy for banks to flag users who use this scheme.

Enters the scheme where the user doesn't have to expose his bank credentials and doesn't have to use SSL re-negotiation.
(But what I'm proposing below adds an extra level of complexity).

A randomly selected gateway user comes into play. The payer who has possesion of the SSL key does his banking session by channeling traffic to the bank through/from the gateway user. When the payer in finished, what happens is:
1. The gateway user submits to the e.agent only those packets which the payer has designated. (Packets which don't contain sensitive info)
2. The payer submits to the e.agent his SSL key, so that the e.agent could decrypt packets which gateway user gave him

Weaknesses:
1. the bank may frown upon the payer logging into his bank from random IPs. But we discussed this earlier and it seems not to be a serious weakness. 
2. The payer can flood the p2p pool from which the gateway users get selected by his accomplices. If the payer and gateway user are in cahoots, they can spoof the whole SSL session.
3. To mitigate #2, the gateway user should be the beneficiary of the payment. (The beneficiary has no interest to defraud himself), which leads to ...
4. If the beneficiary is the gateway user and over time has a lot of those who pay him, the bank will flag the beneficiary's IP because there will be many users of that bank logging into their accounts from the same IP.

Very interesting, are you describing what happens during the initial payment there? I think you probably have the right idea with that extra level of indirection. Let me cogitate a bit more :)

Side note: I had a wackier idea. How about another layer of cryptography? What we need is that the pages delivered to the user are (a) not tampered with = need to be digitally signed and (b) secret and not readable by the escrow agent UNLESS the user specifically allows it = need to be encrypted, (EDIT: delete reference to 2 of 3,makes no sense!)

Not even sure if it makes sense, let alone feasible, but if it were it might serve the same function: the user gets to say to the e. agent "only read the last delivered page" and passes the key for that , and that allows him to read the statement of transactions but not the login page or whatever.

On a slight tangent, I personally don't mind if others see my name and account number. As far as I'm concerned, that's semi-public knowledge.
Note that a) such a network can't work unless people give their bank account numbers, but these numbers are NOT centrally stored anyway (and can be passed over the P2P network encrypted)

b)People have to give this info. currently to exchanges, so at the very least we're not worse off (actually much better off).

c)Giving account number is the same as name+account number - from the point of view of a government agency it's trivial to get the former if you know the latter (they strong arm banks all the time over this)

so really the worst that happens from giving someone your statement is that they see your bank balance.

Hum, I thought the recording was being done on localhost, but only now I realized that if the escrow doesn't perform the SSL-handshake himself record everything himself on real-time, he can't really be sure the recorded data wasn't forged. That's correct, right? Only the handshake is properly signed? Each single message is not signed by the server?

Tough.


Of course, it's not the name+account nb that's sensitive (at least not IMO), it's the balance and transaction history.

Yes. *Someone* (not necessarily the escrow agent themselves, see the last few posts) will have to record the data (in encrypted or decrypted form) in real time, otherwise the user could be faking it.
Exactly. That's the only bit of signing the bank server does.
The rest of the data is encrypted with the symmetric key which the two counterparties have agreed on for the session, after the SSL handshake protocol is carried out at the beginning.

Hmm. For me, I don't think that's a deal breaker, if I only have to release it to a certain party, and only in a rare case. But I can certainly understand reluctance on that.
But if most users take that position, that showing balance and transactions at any point is unacceptable, I am finding it more and more difficult to know what we can do. I get your point that the confirmation page *might* be enough; it would usually contain the details of the transaction. But sometimes it just says, effectively "sent", and it's the page before (which might contain other info.) that actually has the amount and the receiving account details (which we of course do need). Perhaps the last two pages would be OK (the page with the "send" button and the "sent" message).

For the "audit only" model, the solution might be to use a confirmation of wire transfer record. I know that when I send wires I get an automated message in the messaging system *inside* my internet banking application. That single page, I believe, shows *only* the details of the wire (date, receiving account, amount) and doesn't expose my other info. That might be the way.

Just did a little experiment. Looked at a wire transfer that I made some time ago, last August, on my statement, and saw that it only shows some kind of transaction ID, not the actual information (the receiving account number or name or bank), so that would actually be quite useless. I would have to rely on the internal messaging thing as I mentioned above, but this message is deleted by the bank after 30 days.

There will be lots and lots of little quirks like this.

POLi (http://www.polipayments.com/) does something similar. It uses a java applet that drives your internet banking interface for you (you just get to type your password and click Confirm), so they could steal your password (but promise not to).

Thanks Tim, interesting example.

Meanwhile comment: today's news on OKPay is yet another example of the urgent need for decentralizing the fiat-in part of cryptocurrencies..

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.

The proxy acts purely as a forwarding mechanism.
I am basing this on the description:
here: http://stackoverflow.com/questions/3118602/convert-http-proxy-to-https-proxy-in-twisted/3186044#3186044
(the first answer)
I would *really* appreciate input from someone with good technical knowledge of SSLs and proxys to comment on feasibility of this.

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.

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.


Maybe we all need to get on localbitcoins. It is a lot easier to shut down an exchange or processor taking $1M a month than to shut down a 1000 randoms doing a $1000 a month.

Hmmm, maybe we can form a Tor-like network with multiple non-colluding escrowers participated, each of them only keeps some of the packages transmitted, so none of them can recover your password and identity information, yet when required, can put all pieces together to verify if the proof of transfer from the buyer is real?

Not sure I understand you there.
That's the purpose of what I'm doing in this thread - if this piece of the puzzle can be worked out, we can build an online and completely decentralized version of localbitcoins. See https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078 for details.

Tor had crossed my mind too, but I rejected it as (a) users will be put off by it and (b) it will make the networking side even more difficult to figure out. Certainly, the anonymity is important, and we should use as much encryption as possible, but there will still be occasions (not often) when someone else on the network sees your bank account number.

As for splitting the banking session records amongst many users, it seems very complicated.
First, to emphasise, we don't need to expose login details at all. (e.g. in the last version of the design I posted a few posts back).
But more importantly, I actually think we do need human intervention for the escrow action, in order to correctly parse the banking session record. So that would need one person to make the decision. The trick is that the USD seller would only show those pages he wanted to show.

My thought was always that the escrow would be chosen randomly from a large network thus making collusion between escrow and bitcoin seller either impractical or impossible.

Following up on the proxy architecture, I found this re: HTTP CONNECT at http://muffin.doit.org/docs/rfc/tunneling_ssl.html


If that's right, the only caveat is that I'm not sure whether the proxy can easily record all the encrypted traffic going back and forth. Presumably we can just sniff the network traffic, although that would be a bit ugly. Much easier if the proxy server just logs it to file.

Or maybe I'm totally misinterpreting it.
For someone who actually knows networking this is probably all child's play :)
 

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

Really good point. Thanks.

First I would say that buyer information will only be exposed at the level of account number, bank and possibly name (all this info is already semi-public as we've discussed). This will only arise in the case of dispute. And for a lot of people (I can't say most, I just don't know), even in that rare dispute case, they will not even have to display their account balance, let alone other sensitive info.

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.(EDIT: Ignore that last sentence, doesn't make sense (see below)).

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

Indeed reputation should be in the system too. something like the OTC rating system. this would help to minimize disputes.
Why not link the p2p accounts (and the corresponding reputations) to the supplied real-world bank accounts? It would further minimize the number of disputes because nobody wants to risk that he can never use his bank account anymore in the p2p exchange. Is it possible to link p2p-account-reputations to real-world-bank-accounts without disclosing the bank-account-number to everyone? Maybe one could create a hash of the account-number, which then serves as the user-id in the p2p exchange?

Could you elaborate why this wouldn't help? I think if a user always trades using his paypal account, then he could build a good reputation by always using this exact paypal account. Consider he has a good reputation after some time, then he wouldn't want to fraud with this account? If you go further, a user might be able to link his paypal and bank-account and p2p-account all together to even get a higher reputation. And when he once linked them, then it's not possible to delink them anymore because everyone knows that these accounts belong to the same real-world person...

Something else that can be done is to require anyone who wants to be an escrower putting a specific amount of bitcoins in custody within an address that's multisigned by a number of randomly chosen escrowers(which rational people would be inclined to do for escrowing fees income), so as long as the majority of the escrowers are not informants, each government action against a bitcoin buyer will cost them a fortune. This should be combined with some rating system to use.

False reporting of government crackdown from buyers/sellers can also be suppressed by requirng them to work with randomly chosen escrowers.

Whilst I'm not denying that reputation is a useful idea, I think it's dangerous to rely on it, because it can easily lead to quasi-centralization, e.g. everyone uses the Bitcoin seller with rating 1000. I know that can be offset with a price mechanism, but still. Better to have the system so that you don't really need to trust the counterparty. Centralization is death for this system.
At a higher level, it's something like: democratise decisions that need to be made (reputation is a kind of democracy), but even better is not to make a decision (i.e. instead of letting trusted parties do X, redesign X so that whoever does it, it's not really dangerous).

Yes I originally wrote in my project description that the user is defined by a bitcoin address AND a bank account number. I agree.

No, I can't elaborate. It seems to be nonsense. I think I just got confused about something :)

This is a specific example of the rule that says if other people have tried hard to solve a problem and failed, then it probably isn't easy to solve. People (Polipay) with real money to spend on programmers etc have already attacked one of the OP's sub-problems (proving that a bank transfer has been made) and the solution they came up with (letting their java app control your internet banking) sucks.

However, they want to do it in real time, whereas your proposal (if I understand correctly), doesn't. The escrow still waits for Betty to confirm that the bank transfer has been received before releasing the BTC. That would typically take a day or more. In this use case POLi sort of forcibly does the transfer for Adam, then sends a message to Betty (presumably via Polipay's servers) that the transfer has been initiated, and Betty is expected to trust that and supply the goods immediately. It is assumed that Betty is trustworthy because she is a business (and pays Polipay's fees).

Good luck with your idea, but I don't think it solves a problem that is holding Bitcoin back much.

OK, so now I understand what you mean - but it's an apples and oranges comparison.

We are only trying to create a way to "record" the internet banking session, but we are trying to do it in a technically transparent way so that the bank doesn't even know about it. (To my mind there is nothing morally wrong with it because the SSL session remains intact - nobody can eavesdrop on Adam's banking activities. Only when Adam *voluntarily* gives the session key to the escrow in case of a dispute would anybody see any part of his internet banking, and only the parts that he specifically chooses them to see.)

Poli on the other hand are actually doing your internet banking for you underneath their app (I won't comment on the technicals because I don't know what they're doing under the hood - could be calling bank APIs in the same style as OFX or could be actually generating normal internet banking sessions - the latter more likely but also a lot more work for them in terms of coding). That's a much harder thing to do than just passive recording of encrypted data. And of course no surprise, they are only doing it for a specific set of banks.

As to your last point, thanks for the good wishes and I'll politely disagree but that would definitely be better for another thread :)

A problem with the approach to always have the proxy on the machine of the BTC-seller is that they might not be online at the same time. How could they agree to a specific online time? Should they specify this in their trade? In principle the BTC-buyer could just say that he couldn't do the transfer because the BTC-seller was always offline when he wanted to do it.

I would add SSL-renegotiation (as optional for the payer) to increase security. How could you really be 100% sure that the gateway and the escrow do not exchange more of your session-dump or your session-key? This doesn't look 100% secure, maybe just 99% secure without SSL-renegotiation.  So it's better for the payer to use SSL-renegotiation if his bank supports it. And many important websites seem to support renegotiation (e.g. paypal and large banks).

Probably the only reason why renegotiation is disabled on some websites is the security vulnerability (CVE-2009-3555). That many banks have it disabled is overkill, because there is a patch for OpenSSL to close this vulnerability. Maybe over time many websites will anyway update to the newer openSSL version and will enable SSL-renegotiation again.


The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

Although it's clearly not ideal to have this synchronization, this seems to be a less important issue. Counterparties displayed would be restricted to those who are active on the network at the time you are looking to trade. Both sides have to agree to a price as well as certain other settings possibly, and then the proxy-ed session to the bank can take place. Importantly, the BTC seller (acting as proxy) doesn't actually have to DO anything during the proxy session (doesn't have to sit at their computer), just has to be online. I think realistically they would want to stay around though and get a confirmation message that the encrypted data from the session was stored correctly.

If the BTC seller fails to store that encrypted data, they have forfeited the right to their (escrowed) BTC in case of a dispute. That works both ways; if the BTC buyer (the one who used internet banking to make a transfer) loses the SSL session key which decrypts the data, they also would forfeit their right to the BTC in case of a dispute.

I agree that the 4th party is an extra level of architectural complexity that is worth avoiding if it doesn't really bring a benefit.

The only risk left once we move to the model I describe in post 61 is the collusion between the escrow and either the buyer or the seller. This is mitigated by (a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.
Would you not agree that this has all been covered in posts 65 and 67-71?

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
if you find 100% secure way to do this, then maybe I will trust this. Otherwise, I would prefer to trade without recording my SSL-session.

So in summary:
if we use option #1 the BTC seller is the gateway
--> BTC-seller and BTC-buyer have to be online at the same time
--> Only instant trades are possible (not possible to first wait for the clearing of the money-wire before a dispute)
--> Every trade has to use recording of SSL-sessions.
--> Much higher risks

in contrast, with option #2 where a fourth party is the gateway
--> asynchronous trades are possible
--> recording of SSL-session only in case of disputes
--> reduced risks

So why not allow p2p-trades with a lot of different contracts, depending on what risks someone is willing to take? I think the worst option is to only implement the solution with the highest risks, isn't it?


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.

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:
<date> <internal transaction id> CREDIT:<amount> USD <new balance>

rather than
<date> <type: wire> <sending account number> <sending bank> CREDIT: <amount> USD <new balance>

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:
<receiving account number> <receiving bank> <amount>

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.

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

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.

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.

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.

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.

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.

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.

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 (https://bitcointalk.org/index.php?topic=173220.msg1826685#msg1826685) 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 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.

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?

Yes.

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.

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.

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 (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?

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

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.

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.

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".  :D

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

Yeah, I know it's only a proof-of-concept implementation. And it's a very good idea to provide this as a tool to other p2p exchanges. I just wanted to raise the issue so that some people might start thinking about solutions esspecially to the AML problem. Because, if this problem is not solved, everybody who would use the system would have high risks to be involved in criminal activities. Still, I think, it is possible to solve it in a p2p way.


Thank you for the instructions! I will try it when I am back at home.

Wow cool. It's funny because I was just brainstorming this idea with Stefan in Amsterdam and we came up with the same idea of relaying the connections through a proxy. Actually I suggested two different ideas:

 - Implement a TLS extension that lets you ask the server to sign a running hash of a connection (no proxies required)

 - Proxy traffic through an intermediary that just signs hashes of the contents of each session. At the end you can grab the signed hashes and present them along with a recording to a mediator who then decrypts them and can see there was no tampering.

For the AML case, I think using NFC passports can help a lot. There's an app on the Android market that shows how smartphones can read passport data. It's all digitally signed so it should be unforgeable (unless you can convince a government to officially issue a bogus passport). I'd do the following combination:

• Request the buyer to install (a variant of) the NFC passport app and send the passport data to the seller. Seller of course has to be careful to destroy the important parts after verifying the signatures so if they get hacked, the data cannot be stolen!
• Request the buyer to do a Skype/G+ Hangouts session so you can match their face to their passport.
• Now check the wire details against the passport data.

This should prevent phishers from cashing out hacked bank accounts through you.

This is what the oracle will be doing, it first dumps all the passing traffic into a file using wireshark or a tcp forwarder, then produces a hash.

Great idea, thanks!

How about this for an anti-phishers idea:
Seller requests the potential buyer to post a certain unique reference string on their facebook public page. The name/surname of the person who posted the message on their facebook page should match the name of the buyer of BTC.

That might be OK sometimes, but Facebook/Google/consumer accounts are fairly easy to hack especially if you are already capable of hacking the users online bank. The advantage of the NFC passport approach is even if an attacker has utterly owned someones laptop or desktop computer, they can't access the passport data as people typically don't have it on their computers.

The big problem of course is, they can access passport data if they hack the seller and steal whatever was stored. Some of the recent breakthroughs in crypto (SCIP/TinyRAM) can potentially help address that by allowing the buyer to send only a proof of a valid passport rather than the actual passport data itself, but failing that, making sure the default tools sellers use delete the data ASAP would be a workable approach.

Unfortunately, in many countries this approach just wouldn't work, because they don't offer a compatible electronic passport.
For example, I live in Germany, and have an eID. But the German eID system does not allow everyone to validate the passport of another person. As far as I know only service providers (like banks etc.) are allowed to apply at authorities to be able to run an eID-server to allow customers to authenticate.
So it seems that our eID does not allow the authentication of citizens to other citizens. It only allows authentication of citizens to some registered service providers.

I am not sure, but isn't the eID system in other European countries compatible to the German eID and wouldn't work either? (see http://en.wikipedia.org/wiki/Electronic_identity_card)
Would be nice, if someone with a good understanding of these eIDs could clarify.

This point is not 100% resolved (I mean whether the login can be kept out of the exposed data); most banking sessions will involve more than one SSL session, as dansmith points out in another post. But there is no guarantee that the relevant data will be in a separate session from the login. We will make our best effort to do that when the ssl data stream makes it possible. We have also considered stripping POSTs from the exposed data, but we haven't done it and it has its own issues.

However I would make this point, having tried out this system with two banks already:
Modern internet banking almost always involved some additional security feature: usually 2FA, or at the very least, some hiding mechanism such that the entire password is not exposed even over an encrypted connection.
Thus, I have shared my unencrypted banking sessions with dansmith :) Now, I trust him, but even if I didn't, he does not have my passwords let alone my 2FA device! If I was more paranoid, I could also change my password..

You may say, but he has my bank account number and maybe my balances and so on. True, but with regard to account number: you're going to have to expose that to use this system, specifically to your counterparty, who you're not going to know (if you did - why would you be using this system?). Admittedly one doesn't want to share one's balance with anyone, but it is very rare in this system that anyone will see it.

The "TLDR" is, I guess: FULL dispute resolution should only be caused by fraud by your counterparty (or yourself :)  ), and it MAY expose personal details, but it SHOULD NOT endanger your banking security; worst case it will expose some personal information to the escrow (not to the counterparty of course).



A couple of comments:
If banks just implemented digital signatures, I would forget about this ssl stuff; it would be unnecessary. Think about why they don't do it. It's because they gain no advantage from signing their statements. It means you can sue them if they make a mistake.
Now think about a world in which they did sign their statements digitally. We could do exactly the same thing as in this thread, simply send fiat to random people on the internet, based on having the BTC in a 2 of 3 escrow. There would be no possibility of fraud, as long as you trusted bank signatures.
Now think about this: if banks did this, wouldn't your legality questions still apply?
Are we really asking whether we have the right to send the money in our CURRENT (AmE: checking) accounts (which is supposed to be like cash) to other people as we choose?
Yes, I know your questions are real and neither I nor dansmith are naive about this. I'm just pointing out how ridiculous it is.
For what it's worth, I am sure that this system will implement a reasonable upper limit on transactions to avoid triggering AML. Don't even get me started about "structuring".

This is a long way down the road (if ever). In our initial implementation users will simply agree on a price (like they do on localbitcoins). dansmith may be working on something that involves an order book, but I'll let him speak for himself on that.

I have a general idea about this, for the future: imagine escrows in a P2P network, with nodes incentivised by getting a proportional percentage of all network transaction fees, and (crucially) we have MORE than one escrow (i.e. buyer-escrow1-escrow2-seller). Thus the auditing function cannot be corrupted by a single agent. The beauty of it is it's incredibly simple to hook up another link in the network chain. Moreover the network could use a concensus mechanism to randomly assign who does this particular transaction, and they wouldn't be incented to muck it up if they were all getting a fixed percentage of all fees.
Just ideas. For now we have a 1 escrow model.

I believe we had originally conceived that identity = hash(BTC address, bank account number), but thinking about it again, you are right - we should use bank account info only, as it's more costly to set up a new one (although hardly objectively costly). Not perfect, but it's something.

See my comment above about large transactions.

Earlier in the thread we discussed stuff like this a bit; Sybil attack mitigation. dansmith is thinking in terms of collateral by buyer and seller; I am still concerned that it would be much better if non-bitcoin holders could buy using the system. I'm open to be convinced though.

Yes, it should work like that. Clearly escrows can and would blacklist identities who were proven to be fraudulent (albeit new identities can be created).
I'll only add that I'm not a big fan of overestimating reputation. If you think carefully about the system you'll realise that what really matters is the reputation of the escrow, rather than the counterparties. The whole system is designed for you not to have to trust your counterparty at all. But that doesn't mean I dismiss these ideas you mention at all.
We're putting a lot of work into finding ways for the escrow to need as little trust as possible (see dansmith's other posts).

Great to have some input from you on all this Mike.
Can I ask for some expansion on this TLS extension idea? Are you talking about the bank server? (if no proxy I'm not sure what else you would mean). Clearly we can't expect banks' cooperation, and in fact if they were prepared to cooperate they could just sign their statements and ssl logging would be unnecessary.

As for the stuff about AML and passport data .. still thinking about it. Interesting points.

You don't have a passport? All new passports have to be e-Passports now as far as I'm aware, it's a part of a global upgrade. And those contain plain data readable by anyone.

Yes, the TLS extension means something that the banks server supports. I suspect most banks just use OpenSSL or the Microsoft equivalent out of the box. If the extension were to be active by default then banks would likely not disable it unless they had some good reason to. But yeah, I was thinking more of the use case of things like exchanges easily signing data, etc.

Sorry, if I was unclear about it. Of course I have an e-Password. But the German e-Passport does not allow me/individuals/citizens to download any personal information from the passports. The only direct access that a citizen can do is to change the PIN. You can use the electronic ID at home with card readers to digitally authenticate yourself to the government/police/banks/organisations, who previously have to apply at the government to have this ability.
Therefore, I said the German eID is not compatible with what you propose, because we cannot even download our own digital ID information from our own passports. We can only use it to authenticate to specific service providers, but not to random citizens.
And I assume that many other European countries have the same data privacy concerns and therefore restrict the access in a similar way.

I'm 99% sure you can download data from your e-Passport. They are standardised by the ICAO. Germany isn't allowed to have some random custom thing, otherwise it wouldn't be readable by e-Passport readers in other countries. In particular I never heard of passports having PIN numbers, so I wonder if you're mixing it up with something else?

If you have an Android phone you could try using the NFC Passport app from the Play Store and see what happens. Unfortunately Nexus devices have a bug in them which means sometimes reading fails, but that's an issue with the OS that will be fixed in KitKat and not to do with the passports themselves.

yes, you are right, I mixed it up with the German identity card, which has a PIN. Somehow I didn't thought about the passport having a different mechanism.

My significant other has had a passport issued to her within the last month, and it's still like all the older spanish ones.

It doesn't have the little chip symbol on the front? Well that's disappointing. Wikipedia has a list of countries and their rollout statuses:

http://en.wikipedia.org/wiki/Biometric_passport

Germany is on the list as implementing the scheme since 2005, so I'm not sure how your SO managed to get a non-RFID passport. The countries that lag behind the most are places like Azerbaijan and Armenia.

Note that we're talking just about the chip here. It doesn't have to be biometric. I have an e-Passport but it's not (as far as I know) biometric.

i have some concerns about using passport data for AML:

1) I would not like to share this data with anyone, where I cannot be sure if they will delete it. So is it maybe possible to just send this data to a server running on the amazon cloud, and knowing by the hash of the virtual machine that it will delete your data after checking the validity?

2) An attacker might have got your passport data just by wirelessly reading it out from your passport from in front of your house. So would it be enough as an identification?

A side question: Wouldn't it be nice if all countries would issue passports which would allow you to digitally sign documents? Similar to the German eID, which uses cryptography to allow active authentication to service providers.

I still think the idea of linking your p2p-exchange-identity to hash(bank-account-number) would be more usable for AML. The only downside would be that everyone who knows yours bank-account-number would be able to see your trading-history.

I didn't know about that symbol. I just asked her and the symbol is there indeed. I expected the new passport to be radically different, as it happened with our ID card here.

No, they look exactly the same except for the symbol (and the embedded chip which you can't see). So you do indeed have one, as I suspected.


There are several ways to do this. Using trusted computing is one way yes. Using AWS is a neat hack to achieve that cheaply (if it works), but you could also use Intel TXT or SGX when it comes out.

Alternatively, the approach I'm more interested in, is using the new SCIP/TinyRAM stuff to generate a proof that you have a valid passport, which is not itself passport data. That proof can be quickly checked using any old hardware and can be generated without sending the data anywhere at all.

Right now the Amazon approach is probably the easiest to achieve, but I'd prefer the SCIP approach longer term.


That isn't possible. Firstly, we're talking NFC here, it's not that easy. Yes I know about people who use giant parabolic aerials and such to read NFC chips from further away than you might imagine, but there are mitigations against such things in e-Passports:

1) The data is encrypted under a key that is derived from data printed inside the booklet. To read an NFC passport is actually a two step process. Firstly you scan the MRZ (the part with <<< symbols) or type in the details by hand (passport number, expiry date, issue date). Secondly you read the chip and decrypt what you find there with the key derived from the first part.

2) American passports actually have EM shielding in the outer part of the booklet so you can't read the chips even with amazing aerials when the booklet is closed.

And I guess of course most people don't carry their passport around with them all the time.


It would be nice. Some e-Passports actually can do that. It's intended for anti-cloning of the chip. The chip contains a private key that is used to sign challenges. I thought originally that could be used to sign another key that would then act as a time-limited extension of your passport. Unfortunately it's an optional feature and many countries don't bother implementing it, presumably for cost reasons.

Most countries don't have a real citizen PKI beyond the ICAO international one, which is unfortunate. To nobody's surprise Germany and Estonia are ahead of the rest of the world there.

Of course, nothing stops you implementing support for a country-specific PKI scheme like eID. It looks like the Bundesdruckerei has a thing called "sign me". That might be useful, but I couldn't find any technical detail about the protocols.

http://www.bundesdruckerei.de/de/node/798


I must have missed that one. How does it help? Remember the threat you're facing is not just regulatory, but people cashing out hacked bank accounts. In that case you have to verify the identity of the person actually initiating the payment to you.

Thank you for the explanations.


The idea is the following:

1) A new user of the p2p-trading system would create his identity=[ generated_public_key, hash(bank-account-number) ]. Thereby you link your bank account to your trading idenity given by your generated private key.
2) Initially other users will give you just a minimum trust, because they cannot be 100% sure the bank-account is really yours. With this minimum trust other users will allow you to just buy 0.01 BTC for 1 EUR/USD for example, because this is just a very small amount.
...One month later...
3) The same user has now gained much more trust, because the old trading partner has not yet received any complains that the bank account was hacked. Therefore the user can now buy 0.1 BTC for 10 EUR/USD, because other p2p users can be more sure that the identity=[ generated_public_key, hash(bank-account-number) ] does not belong to some hacker who wants to cash out hacked bank accounts...
...One month later...
4) The user has gained much more trust, because his idenity is already two month old and so far none of his trading-partners received any complains.
This goes on and on until you have build a lot of trust and you can actually trade amounts like 10.000 EUR/USD

The nice part about this is that you need two access-keys to use your p2p-account: your bank login AND your generated private key for using the p2p-system.
If some criminal gains access to some bank-account he cannot immediately cash out much money. He could only cash out 1 EUR/USD. He would have to wait 1 or 2 months to really cash out a lot of money, but at that time the victim will already have regained access to his bank-account.

So you automatically gain trust just by waiting a few months. You wouldn't even need to trade for two months. Just by waiting you will upgrade your p2p-idenity to very much trust.

I think that approach makes a lot of sense, nomailing. The exact details like times, amounts could be changed of course.

It's worth keeping in mind: how is our proposed system different from others? If you make a transfer via localbitcoins using wire transfer (pretty popular from looking at the site), you are in the same situation as you are with our system. What is different is (a) having ACTUAL verification of transfer so escrow can work properly (not some stupid photoshopped bank statement), and even automatically most of the time, and (b) we CAN move to a really decentralized model (and I hope we will).

If you read the localbitcoins advice to users, they basically leave it up to the seller to verify identify if it seems to be necessary, as well as take a number of other precautions (see "Risk assessment and migitation" on the page https://localbitcoins.com/guides/how-to-sell-bitcoins-online). And when it comes to resolving dispute they say "Localbitcoins staff will resolve dispute". Yes, exactly...

Try not to get side-tracked with the AML stuff, it is an unnecessary complication ... it's p2p not "Big Brother says"

I think you underestimate the implications if you are doing money transfers in the normal banking system without AML in place. This would be criminal activity and is not comparable to some kind of p2p downloading of copyrighted files or mining p2p-coins or whatever.
If you would setup the system without AML, then:
1) smart people will just not use it, because they are aware of the risks
2) dumb people will use it and will be victims. Sooner or later they will get letters from law enforcement that they were doing criminal buisness.
3) hackers will use it to cash out hacked bank accounts

I don't think that is what you want. Also think about the implications that would have on the bitcoin system itself. So better think about AML if you are trying to interface a p2p-trading system with the legacy banking system.

The problem of cashing out hacked bank accounts is reason enough that people have to do this. Even with no government in place at all banks own your money so they can blacklist wire destinations at any time, and they do. They don't care that it was their fault (or their customers fault), they just see repeated reports of "Someone wired my money to IBAN 1234 and it was fraudulent" and decide there's a simple fix.

Are you talking about big traders operating under such system, or the system itself?
Because saying the latter is like saying e-bay is legally responsible for, say, regulatory compliance in the selling of every electronics (or whatever) that goes through them. I know some jurisdictions are that authoritarian (Brazil comes immediately to my mind), but there must be some others where you could place your business and just be fine...


I've used localbitcoins sometimes, and I doubt they have any AML compliance on their side. I obviously don't have on my side, I'm just an individual trading a few bucks, not a professional. So... are you calling me dumb?  >:(

AML laws typically have thresholds on them so people can't get whacked just for using cash in reasonable, day to day amounts.

The thresholds fall constantly either because they don't get adjusted for inflation, or are deliberately lowered. Overall the trend is for governments to try "boiling the frog" when it comes to cash transactions (yes I know frogs don't really boil alive).

Whether you are in compliance or not is difficult to say because the laws are so hopelessly vague. In most jurisdictions it won't be an issue. If you start doing a lot of local trading and it is some significant income for you, you may or may not attract attention, and if it turns out that some SR dealers are cashing out through you and the police catch wind of that, then you might be in trouble regardless of the thresholds.

Really, it's a mess. But as I said. AML is just one aspect of that. Stopping hacked bank accounts wiring money to you is an equally important aspect that killed off a few of the early more amateurish exchanges.

I am talking about the big traders (>100€) and not about the p2p system itself. Of course, small traders might be lucky and not be a victim.
So, I just wanted to stress out, that these considerations are on a completely different level in comparison to considerations if p2p filesharing is legal or if bitcoin is legal. Because you are using the banking system to do money transfers from users whom you might not know. Therefore, if you want to have a usable system, then you have to deal with these issues.

No, I haven't said it is dumb to trade on localbitcoins. They have some mechanisms which prevent users to massively cash out hacked bank accounts. If you read my posts, you will see, that what I actually proposed is similar to the rating system on localbitcoins, but it would work in the p2p system.
Let me give you a counter question: Do you think, that localbitcoins would work without any rating system?
So my whole point is that the p2p system needs some mechanism to prevent hacked bank accounts wiring money. Actually, this is some minimal AML compliance, because if someone wants to cash out hacked bank accounts it is basically money laundering. This is not just important to comply with the law, but it is a fundamental part of the exchange to work.

OK.


Sure. I just wouldn't call that "AML". The idea of hashing one's IBAN for example, could be enough.


No, that would be theft. Money laundering would be when/if the thief makes the stolen money a fake part of some official, declared income. That normally only needs to happen for large amounts of money, as for anything small, the thief could just spend it under the radar, without having to launder anything.

I'm being pedantic because "money laundering" is increasingly becoming a magic word, like "terrorism", used to justify all sorts of things.

Exactly that is what I suggested just a few posts ago (https://bitcointalk.org/index.php?topic=173220.msg3279085#msg3279085).


I would definitely call this AML. As you said it is theft of fiat money, but at the same time you would be converting this into bitcoins. And if the criminal can transfer it to bitcoin, then he already has done the most difficult part of money laundering. Then he could just setup a site and anonymously donate bitcoins to himself and it is legal money.

Look at the example of bitcoin24. It was seized 4 months ago, because money was transferred from stolen bank accounts to the exchange and converted to bitcoins. This was called AML. So I do not see your point, why you wouldn't call this money laundering? Of course, AML compliance would be even more, but to prevent exchange of stolen fiat to bitcoin is a major part of AML.


*EDIT* But, probably, it's not very useful to further discuss about definitions of AML. So, I can agree to your definition of AML, if you want. It was not my intention to focus on this term. I just wanted to point out, that the p2p-exchange should use an identity=[pub_key,hash(IBAN)]. The drawback is that this will reveal all your historic trades to everyone who knows your IBAN. I thought that someone would have a better solution at hand. Actually, the idea of Mike Hearn using the passport data might be another better technical solution...

You're tying yourself up in knots trying to program for some insane regulatory hurdles that your users will most likely never encounter ... a simple cost/benefit will show you are wasting your time if AML of specific country's (of which there are hundreds)  is your driving s/ware design concerns.

E.g. leave a space where others can add-in a module or etc if they want it ... wash your hands of it and concentrate on the core. (charge them later for the extra)

A couple of small updates for those following the thread.
We have found a way to ensure that the login and other private information is not exposed. Experiments have verified that it's possible to send ONLY one html page when there is a dispute. I can't say that it will ALWAYS work, but I think it probably will always work - it has done so far.

If the audit is performed concurrent with the transaction, this means sending only an acknowledgement of sending page - which (for my bank at least) means just sending the receiving and sending account details and the amount (and not exposing account balances).

If the audit is performed after the transaction,as currently implemented by dansmith, (in case of dispute only), and as I know most people will prefer, this would mean exposing some kind of statement page - the details will depend on the user's bank, which he or she should verify before using the system.

dansmith is making very rapid progress with the lightweight, oracle-style code based on AMI instances that he described briefly earlier, but I'll let him give you his update on that.

As for me I have been writing a much "bigger" style of app, synchronising buyer, seller and escrow; this model will almost certainly not be used, at least initially, but it has given me plenty of opportunities to test the core architecture and I've been able to verify through hundreds of tests that the ssl logging is working as we want. I even managed to handle dropped connections, although that won't actually impact the initial version that ds is releasing.

On identities: here is my current opinion.
The whole aspect of reputation and collateral is not completely clear to me yet, but I much prefer models based on limiting amounts until a user has transactions under their belt, such as that proposed by nomailing in post 117 in this thread (although probably not as restrictive as that).

I believe that users should approach the system with two things in mind: (a)direct counterparty risk through fraud is eliminated by this system and (b)indirect counterparty risk (mainly, receipt of stolen funds) is their responsibility as a user, and we HELP them to make an informed decision by providing background information, but they should follow good practice. I.e. follow the advice to sellers given on the localbitcoins website, including identity checks but FAR more importantly, limiting transaction size with untrusted buyers.
I much prefer this to a collateral method of disincentive.

In particular I would like to preserve the property that the system would allow at least SOME kind of bitcoin buying by bitcoin non-owners (imagine that you could tell people they can just "buy some bitcoins" direct from their bank account with no security concerns; they would only be able to buy a small amount, maybe max $100, but think how powerful that is in terms of spreading the word).


Would really welcome further thoughts on this, I think it's pretty crucial.

Thank's for the update. how are you implementing the synchronization of buyer, seller and escrow? Hopefully it is completely decentralized in a p2p system.
Do you already have some specific system in mind?

+1 That all sounds great.

I'm not sure exactly what you mean by "completely decentralized" but basically I think you need me to give an overview of the current setup. This is the setup that dansmith is planning to release for testing soon:

There are four parties involved, although one is not human.
The buyer, the seller, the "oracle" and the escrow. The oracle is set up on an Amazon aws instance in such a way that anyone can verify that it is running the correct code. That code exists to audit an internet banking session. More on that in a minute.
The buyer would need to test his internet banking (or just know) in advance to make sure that it shows clear proof of a previously sent wire transfer. If it does, he can use the system like this: choose an escrow and his/her corresponding oracle machine. Then, find a seller similar to how currently done on localbitcoins, i.e. on a website or similar public board like a bitmessage channel for example, with compatible bank account. Discuss and come to agreement on price etc. <Some of the details here need fleshing out> Then bitcoins are placed in 2 of 3 multisig with escrow by seller. When that's confirmed, buyer does internet banking without any auditing, just directly.

Lastly (the important bit, that usually will not happen), if there's a dispute from the seller after the appropriate waiting time, the escrow asks the buyer to log in to oracle machine with previously agreed credentials and run internet banking using the firefox plugin which enables (a) the internet banking to be proxied through the oracle machine and (b)some ssl stuff, in particular a button to press to clear the ssl cache so that the buyer controls which html pages will get exposed.
Finally, the buyer will send the specific ssl session key that allows the escrow to read that specific html page showing proof of his wire transfer (in particular, of course, the bank account number sent to and the amount). This will enable the escrow to resolve the dispute.

Hope that helps.

Edit: you may be wondering, as I did initially, what extra value the oracle brings if we still have to trust the escrow to interpret the html records. The point is that the oracle represents a uniquely trustable agent, so the network audit record that it stores has a privileged position. If a buyer decided that the escrow was lying in his interpretation of the html result, he could call for a second opinion from another escrow, who could also see the html (if the buyer gave him the keys). Thus outright lying by an escrow would not hold.

I am still confused how you want to make sure that the escrow is not in cahoots with the buyer. If the buyer can arbitrarily choose an escrow, as you said, then he could also just setup his own escrow service and thereby completely scam the seller. Maybe I just don't get your idea, how you want that the buyer can choose the escrow...?

I think this decentralized exchange needs two important things:
1) The escrow has to be chosen pseudo-randomly such that neither the buyer nor the seller have influence on this decision.
2) The p2p-system must prevent sybil attacks, where an attacker could flood the system with his own escrow services and use them to scam other traders.

Here are my thoughts on this problem (if it is a problem at all?), and how it might be possible to solve both points:
The idea is to use the block hashes of the bitcoin blockchain as a pseudo random stream to select an escrow.
For example:
All exchange users (buyers,sellers,escrows) have an identity=[ public_key, hash(bank-account-number) ]. If buyer and seller agree to a trade (i.e. through a bitmessage order book as you said), then this trade will be broadcasted to all users. Therefore both trading partners and their identities and the amount will be available for the public. Similar to bitcoin transactions you can compute a hash of this trade. Now based on the hash of the trade and the hash of the next bitcoin block, another user is pseudo-randomly selected. The selection might work like this:
each exchange userXY can calculate his individual score to be the escrow in the broadcasted trade:
score_userXY = hash(identity_userXY XOR hash(trade) XOR hash(next_bitcoin_block))
Everyone can claim to be the escrow service, but only the user with the lowest score will win and be the escrow for this particular trade. By this procedure, the p2p-exchange has pseudo randomly selected the escrow...

Hope my explanation somehow makes sense and could be helpful in any way...

Thanks for your efforts in understanding and critiquing.

I have always thought that, indeed, it's better if the escrow is chosen at random. I think I proposed something similar among these pages. The alpha test will not include this feature.

But I think maybe you haven't understood fully the power that the oracle brings: if the seller suspects that the escrow is in cahoots with the buyer after a dispute, there is nothing stopping him from asking for independent verification: he requests an access key to the system and the ssl session key so that he can also verify by accessing the oracle, what the html page says (remember: the buyer has provided a key for ONE html page which provides proof of his transfer without exposing his login credentials).
If the escrow refuses to hand over those keys he has proved he is a fraud. If he hands over the wrong session key it will decrypt nothing - again proving fraud.
It works only because you can prove exactly what program is running on the oracle, and it cannot be tampered with, including by the escrow.

It's true though that a given escrow could commit exactly one fraud via this method, since he's in control of a 2 of 3 multisig address. Until we are able to construct an oracle which interprets all html bank statements correctly, this will always be true.

This problem *could* be mitigated by the escrow posting collateral to another multisig, such that his bitcoins are lost if he commits this transparent fraud. Then we have to be careful not to create a centralised system - with one or more "super-escrows" acting as police over other escrows. This might be too much centralisation, although I am not completely against a system like that. And if you try to distribute a LOT you might get another problem - 13 of 13 multisig is all very well, but what if 1 of the 13 dies?

So this comes back to your (and my) point that the system works much better if escrows are chosen randomly - but don't ignore the HUGE step forward that an oracle represents.


Yes, at first glance, this looks like one viable approach for random choice. I guess there would be a few ways to do it.

However I want to ask about identity: earlier in the thread you suggested it was better to make identities stick to bank accounts rather than hash(BTC add, bank account), and I realised that this was a good point, because anyone can create a BTC address any time, and so could create identities too easily.
I think this is an important issue and I'm not sure about it.

The identity has to have two properties: there should be at least some cost to creating one, but also it should be impossible to impersonate. Public bank account details satisfy the first but not the second. So maybe the best is indeed to combine a bitcoin address with a bank account but not in such a simple way as hash(BTC+BA). It could be requiring a signed message with the bitcoin address used at account creation time, as well as provision of hash of bank details. That way an attempt to create a second account with the same bank account but different bitcoin address would not be allowed, because the hash of the bank account would be a collision.

yes, I completely agree. That is what I wanted to say by identity=[ public_key, hash(bank-account-number) ].
So you would associate your public_key with a hash of your bank-account-number. Of course, to submit your identity to the other peers, you would have to sign it with your corresponding private_key and thereby linking your public_key to your bank-account.

And any sensible buyer would say: "Hell, no, I'm not going to do that."
This has to be against the TOS of any online banking service, and would leave the buyer open to fraud with no protection from their bank, if it is found out that they have shared their session like this.

I know that many people are sharing their bank account credentials with another company (i.e. http://de.wikipedia.org/wiki/Sofort%C3%BCberweisung (http://de.wikipedia.org/wiki/Sofort%C3%BCberweisung)). This is maybe against the TOS of the banks, but they do it anyway.
Furthermore antitrust agencies have said that these TOS are invalid, because they would exclude some companies from the market (c.f. http://www.bvdw.org/mybvdw/media/view/prozess-giropay-vs-sofortueberweisungde-bundeskartellamt-nimmt-stellung-agb-der-banken-kartellrechtswidrig?media=2775).
So in practice you see that people do share even their login credentials. And you can see that it is allowed to do that.
Now, the system described here would not even share your login-credentials. I don't think that banks could deny someone to use a proxy server. In the end every internet traffic is routed via some other servers. So how should they have some TOS to prevent that?
In the end you don't even have to share your session key with someone. It might be enough to submit it to the Amazon AWS server which will then just provide the proof-of-payment. And the Amazon AWS server is not really a person, it is just a software which is running in between and no real person has access to your keys.

You aren't just 'using a proxy', you are deliberately another person access to your supposedly secure bank connection.
This is a bad idea.
If you bank finds out that you have done it, they may well cancel your account, and would certainly refuse to compensate you for any fraud that happened on your account.

I know that many people drive drunk.
This may be against the law (and really f*cking stupid), but they do it anyway.

People do stupid things all the time, and most parents teach their children that just because other people are doing stupid things, that doesn't mean they should do them too.

I just say, that it cannot be against the law. If you connect to your banking website, then your connection is routed via many different software components. And in the end the Amazon AWS instance will also just be another software which is routing your traffic to the bank. So how should they prohibit this?
I would not even share my login-credentials with any other person, because it is just a software.

Do you think it is against the law to enter your bank-account password into Internet Explorer, because this will effectively share your login information with Microsoft? Because there you even cannot be sure, because it is closed source. With the Amazon AWS instance it would be open source and therefore you can be sure that you don't share your password.

So why do you think, it is more stupid to trust some open-source software running on Amazon AWS in comparison to trusting some closed-source software like Internet-Explorer or any other router software which is between you and your bank?

I've never said that sharing your credentials is against the law.
I have said that:
a) It is against your bank's TOS, and
b) It is stupid

And there is a difference between using software and, unknown to you, there being an exploit which leaks your information, and you voluntarily sharing your information.

My first response to the concept was also suspicion. However this is not what it seems at first sight.
First consideration: it is common practice for people to give copies of their bank statements to various agencies as proof of income (this is even required in some cases to get visas). This is not really different in terms of privacy, the difference is that what we're doing represents actual proof, something that cannot be forged.

Secondly, make sure you understand exactly what is being exposed. The proxy only holds encrypted records, exactly as, say, your ISP does when they forward your internet traffic to your bank. When a buyer CHOOSES to expose ONE html page, by sharing ONE specific ssl session key, they are not exposing anything else to any other party, trusted or otherwise.

Lastly, as to it being against TOS. I investigated this a bit. I found clauses in some internet banking service conditions that suggested this is not allowed, while in others there was no suggestion that sharing the data is not allowed. The former are unrealistic and frankly nonsense, since as I already pointed it out any person sharing their bank statement in any way would be violating such a TOS agreement.

I have to repeat again, as emphatically as possible: you will NOT share your internet banking credentials with this system. 100% not your password. ONLY one html page containing your statement or, even better, the acknowledgement page showing the record of a wire transfer sent.

a) Is it against your bank's TOS to print out a webpage showing a proof-of-payment and handing it over to another party? If not, then why should this be different? You are not sharing your login-credentials.
b) Is it stupid to print out a proof-of-payment from your bank and use it as a proof-of-payment?

Maybe you don't understand that you can audit the software running on Amazon AWS?

It is different, because you are deliberately sharing your online banking session with someone else.
You are potentially opening yourself up to fraud.


Do you think your bank will do that? Or that they will care.
a) Have you shared your session with someone else: Yes
b) Is that against our TOS: Yes
c) Will we refuse to compensate you if you lose money due to fraud: Yes

It doesn't matter here whether technically there is or isn't risk of your credentials being stolen.
Your bank has not agreed that you can extend their security umbrella to some Amazon AWS instance they've never even heard of.

There are two distinct issues:
a) Is this actually a security risk, can you 100% guarantee the security of the setup, and that there can't be a rogue operator or man in the middle?
b) Is it against your banks TOS anyway?

The answer to b) doesn't depend on the answer to a).

murraypaul, did you see my post at the end of page 7? (you may have missed it because there were several posts at once). I made some points about TOS there.

As to a): it's exactly the same risk as passing your traffic through an ISP, a proxy, a VPS or basically normal internet traffic. Namely: passive observers can record your encrypted data. MITM is as big (or small) a risk here as it is with a normal internet connection: do you trust the certificate being presented as from bankofamerica?
Issuing to an escrow, in a dispute case, ONE ssl key that will expose ONE html page (a relationship which you can verify on your local host) is EXACTLY the same issue as whether you want to give your bank statement to that person on paper.
(Again, I responded to (b) in the last post of page 7 - or maybe that depends how your config is on this forum, it was 5 posts back).

Well no, it isn't exactly the same risk, is it?
A standard secured connection is a very well known and understood setup, which large companies do all the time.
You are talking about a brand new, untested, bespoke, security setup.
The risk of security failure in the latter is much higher than the former.


If your security setup was perfect, then in practice it might be as secure in practice.
It isn't exactly the same from the bank's point of view, because showing someone the statement doesn't involve any possiblity of compromising the security of your account, because it is a static bit of data. Accessing your account through someone else's system, where the bank cannot be confident that that system is secured, is not the same thing.
Showing them your bank statement would be the equivalent of emailing someone a screenshot of your online banking.


It would depend on the working of your particular bank's TOS.
I wouldn't be confident that there isn't some clause they could find that would cover this situation.

This is exactly the same setup, using a proxy in dispute (and for normal transactions you will not even do that, just your normal internet banking).

We really aren't; but it's OK, until we actually release a full alpha test with source that people can look at, you have no basis to know either way, so it's right to be cautious. I guess all I'm saying is please don't assume we haven't thought about it :)

It really is the same, but no need to argue further about that without code for you to look at. Either way, your point that the bank would never explicitly accept this system, is I'm sure true. They will never accept anything the customer proposes, generally..

I agree that they will choose to interpret TOS as they wish, unless you have expensive lawyers perhaps. What you might not appreciate though is that this process is completely invisible to them. From the bank's POV you have simply connected via the proxy's IP address. Banks do not restrict which IP you can connect from (assuming it's not in like Iran or something) since that would break one of the main advantages of internet banking, namely mobility.
Of course if ALL our connections came from one IP, that would be different :) And don't forget that this proxying (as of now) only occurs in dispute, also.

murraypaul's arguments all boil down to reputation-based security, but he then surrounds them in lots of other gumpf.

Reputation-based security is last decade.

If anyone would like to help me test the multisig (escrow of bitcoins) part of the application, please PM me.
Details:
you don't need to spend any bitcoins :) we'll just escrow and then redeem 1mbtc from me.
git clone or download the zip from: https://github.com/AdamISZ/multisig_lspnr
If you have python 2.7, you can run it immediately to see the instructions: python multisig.py (no arguments)
(or just read the readme on github).
This test needs two people at least acting at once, so I'm available from around 12GMT to around 9PM GMT tomorrow and most days.

Thanks if you can help, and please be ready for an announcement from dansmith coming v. soon as far as I know :)

Edit: just in case it needs to be said, do not attempt to use this application independently yet; it needs more testing.

I would like to invite those who follow this thread to take part in alpha testing.
Code-named "Paysty", is a set of tools which allow you to connect to your bank via an Amazon EC2 oracle and then select a statement page which you would like a third party to see.
With this alpha version of Paysty you don't give anything to any third party - the oracle sends your encrypted banking data back to you.  Paysty then acts as if it was the escrow and analyzes the encrypted data and lets you know whether it can find your HTML page in it.

Those who wish to participate, please PM me and I will give a key which serves as a passwords to get access to oracle. Otherwise you won't be able to use Paysty.

https://github.com/themighty1/ssllog/tree/alphatest (https://github.com/themighty1/ssllog/tree/alphatest)
You can choose "Download ZIP" if you don't want to use git

Make sure that Firefox is installed on your system.

Windows users don't need any extra software - Paysty is bundled with Python, plink(console putty), stcppipe and wireshark tools.
Just run startPaysty.bat

Linux users will have to install Python (v2 variety), ssh, tshark, gcc.
On Ubuntu we just run Then just run "python buyer-oracle.py"

OSX: nothing yet, sorry.
------------------------------------

Copy the private key which will you receive from me into the file alphatest.txt in the root of the Paysty's installation.


Usage:

On the bottom panel of Paysty there are two input fields: Account number and Sum.
After you navigate to a specific transaction in your banking statement history, enter the Account number and sum exactly as they appear on the page.
After that Paysty will tell you whether your bank is compatible.


Once again let me re-emphasize all security related points:
1. The oracle is open source and serves as a proxy when you connect to your bank.
2. Even though the oracle is launched from my Amazon account, it is set up in such a way that I have no access to it. I can only terminate it at most. I can't see which IP address is connecting to which site via the oracle.
3. In this Alpha version, you don't share any page of your banking session with anyone, all your data is sent back to you for examination.

Whether successful, or otherwise, please let me know your testing results (PM or here), viz. your operating system, your bank's name/site.

Just wanted to give this thread a little bump and add some lamentation.
It's been a week and NO-ONE has contacted me to with the intention to become a beta-tester.

It's a bit sad that we are working here to bring to the community a decentralized open-source FIAT to BTC exchange and yet we have to spend our precious time recruiting beta-testers and even offering the money instead of pressing on with the development.

Nonetheless, we managed to successfully test Paysty with our and our friends' bank accounts. 5 banks in total.
Please feel free to PM me if you want to contribute to this project by becoming a beta-tester.

Sorry Dan. I don't think the issue is lack of interest in the outcome. I did take a look at doing some testing for myself, but:

1) I've been out of time lately (that is, the time I have for Bitcoin is soaked up by other things)
2) I would be about to route an online banking session via a third party proxy, using a large pile of code not written by me

(2) implies before I'd be willing to take part in this, I'd want to verify everything for myself. The fact that this is possible is why your approach is powerful. However, that doesn't mean it's something I can squeeze into my lunch break.

What you might want to do is start a new thread, perhaps in this section or perhaps in the dev/tech section, outlining what is required. It will take a while until someone is able to fully verify that your setup does what you say it does. Once that is complete, it'll be easier to recruit beta testers. All I can suggest for now is raising the visibility of your important work, combined with patience ...

Good points Mike.
In terms of people verifying the code's security, I'd suggest anyone who's interested take a look at the management of ssl keys and what data is transferred.
Since you can see that in the current prototype version, ssl keys are stored locally and not transferred, to my mind that's a 100% guarantee of safety. (not a 100% guarantee of successful operation of course, that's an entirely different matter!)

Of course we are talking about only a prototype here for initial data gathering. The fuller version will include multisig transactions and a messaging feature, and there will be contexts in which ssl keys are transferred (only those for specific html though).

I just tested it for 2 banks.

For netbank.de it works just fine.
For sparkasse.de it doesn´t...

this is the last part of the log:


the amount I entered was 29,44, so.. not sure why it´s garbled in the log while the account no is fine

Edit: Ok, my fault (kinda)... I didn´t enter 29,44 but -29,44, as that was the way it was stated. Imho this should be processed either way.
So, entering 29,44 works for sparkasse.de, too.

Now maybe a stupid question... what exactly does this prove?
Is it a problem that, e.g. I can send a transaction to one of my own bank accounts and put the actual target account number (whom I´m supposed to pay) just in the comments field of the transaction? Paysty does find the actual target account number in the html but does it recognize that this is not the account number money is send to?

Indeed it looks like you entered a minus sign; the garbled part is an encoded form of the minus character.
Did you copy/paste the minus sign or enter it manually? I guess the latter and that's why it's failed.
However you're definitely right that we have to be careful how we deal with the user input, and we're looking into it. Your input is much appreciated.

Paysty is only verifying that what you enter into the 'accno' and 'sum' boxes actually appears somewhere in the html of the page. So of course you're right you could enter anything that appears somewhere on the page, not necessarily the true account number for example. This is just a first stage verification - the real point is as follows: if there's a dispute between buyer and seller, the escrow can (if you choose to give it) take the ssl key(s) specifically associated with that html page, and decrypt that one page and read it.
The protection of your privacy is based on doing a kind of "reset" of the ssl connection and then reloading the page. This means the escrow will never be able to see anything except that one page.
Does it make sense? Obviously a more detailed explanation will be given in the future.

Yeah thanks, makes sense. I guess in the end there will always be some kind of trust required, even for technical people, unless they are willing and able to inspect the whole source code but in essence that´s equally applicable to using bitcoin itself. Making explicit what kind of information at which step is stored where and visible to whom and at which point in time is going to be crucial though.

@PeFro
Just wanted to send you a big THANK YOU for volunteering to test.

@Mike Hearn
Thank you for the words of encouragement. The mere fact of your participation in this thread helps inspire confidence in beta-testers IMO.

There are only 2 files which need to be looked at:
buyer-oracle.py (1000 lines) which I tried to comment as amply as I could
and oracle/oracle.py (700 lines) which stands by for a command from the user and only performs 3 things :
setup tunnel using stcppipe,
send encrypted trace to escrow,
send a copy of oracle's internal database.

Yes, I did take a quick look and the code seemed quite readable. It's just a matter of carving out a few hours to really get to grips with the code, and then trying it.

First, I wanted to commend you guys for this work, which is important, and to congratulate you on your progress.

Second, I wanted to point out my latest progress report on the "Holy Grail" project, which mentions your own project: https://bitcointalk.org/index.php?topic=225954.msg3440808#msg3440808

Third, I wanted to point out that there is a 12 BTC bounty on integrating your project into the Holy Grail, which is currently worth about $3,000. It's too bad your stuff was written in Python instead of C++, but integration may still be possible through some sort of inter-process communication.

Fourth, I wanted to say that while I don't have time to play around with your code personally (right now at least) that I view it as very very important nonetheless, and I am keeping a close eye on your work here.

Well done!

Hello I am keen to do some testing if you like.  I have downloaded and run the python script on my linux box, but I think I need a key from you?

PM or BM dansmith for the key. Thanks for giving it a try.

Just a note for linux testers.  The alphatest.txt file should be created with the most minimal permissions, if the permissions are too 'open' SSH will fail

Good call. Yes openssh insists on, if I recall correctly, 600 permissions for private key files (or at least 0,0 for group,world).
We're going to try to move all alphatesting technical discussion to this (https://bitcointalk.org/index.php?topic=326233.0) thread.
I will copy your comment there grebit.

We'll keep this thread reserved for discussions, questions and ideas on the software/architecture.

Moved from a different thread. This thread is more appropriate for discussion of the architecture.


@nomailing, thank you for trying it out.
The authorized key you're pointing out is the default key which allows the escrow to logon to the oracle for the very first time. Then the escrow is expected to change that key using oracle's register_escrow command.
The corresponding private key is called escrow_key.

Yes, we should and we are. We explicitely tell sshd not to spawn a new shell and to run our custom command with the line "no-pty,no-agent-forwarding,no-user-rc,no-X11-forwarding,no-port-forwarding,command=/usr/bin/python /home/ubuntu/stub.py..." in authorized_keys

There are a number of reason why we use sshd instead of our own code:
1. sshd code is definitely more trusted than any other code we would write
2. sshd provides a simple authentication mechanism to enable only those with correct keys to use the oracle
3. If it was not for sshd, the user would have to connect directly to stcppipe's outward facing port (we need stcppipe to log ssl session on oracle, remember?). So if it wasn't for sshd, we would have to juggle with iptables rules in order to protect stcppipe's outward facing port from DOS.

Ahh ok, that makes sense. Now I get the overall architecture a bit more. Thank you for the explanation.

I am now trying to figure out how exactly I have to setup the escrow after I first started the snapshot using the ec2-api-tools and running the command "ec2-run-instances ami-a73264ce ...".

I tried to get some rough overview about the code: It seems I have to first register my new escrow_key with the register_escrow command and then I have to add users using the add_pubkey command. These commands will be sent via ssh to stub.py on the ec2-instance. From there the commands transmitted via ssh are forwarded via a socket to oracle.py. In oracle.py the command is handled by the escrow_thread or 

I am not quite sure if I am supposed to use test_oracle.py to do this initialization of the oracle. It seems that test_oracle will initialize the ssh session to localhost and not to the EC2-instance? It would be very nice, if you could explain the steps I have to take to initialize the oracle after the first start. Or did I overlook some file where it is explained maybe?
Thank's a lot.

Hi nomailing.

If you've already done register_escrow and add_pubkey for a test user, you should be able to start paysty up directly, as long as you've put that test user's pubkey in alphatest.txt.
Let us know if it doesn't work and we can figure it out together.

Oh and edit: have you constructed the query strings yet with aws_query.py?

I couldn't do register_escrow so far, because somehow the ssh login to the oracle is not working.

Are you sure that the public key in
https://github.com/themighty1/ssllog/blob/alphatest/oracle/authorized_keys (https://github.com/themighty1/ssllog/blob/alphatest/oracle/authorized_keys)
matches the private key in
https://github.com/themighty1/ssllog/blob/alphatest/oracle/escrow_key (https://github.com/themighty1/ssllog/blob/alphatest/oracle/escrow_key)?

Yes, it's the same key. You can verify by doing a ssh-keygen -y on the escrow_key.

If you want to communicate more real-time to solve the issue, PM me and we can set up some kind of channel.

There are lots of fiddly details in getting the oracle to work. It took me quite a while the first time too!

My tshark version in ubuntu does not have the parameter "-Y".
It is tshark version 1.6.7.

I tried replacing -Y by -R, but now it complains about wrong time format:

Yes, the latest Wireshark version is 1.10.x, -R was deprecated a few versions back. As for the date, probably the same issue, never seen that.

Is this just for various kinds of manual testing? tshark executable is shipped with Paysty so shouldn't be any issue there, unless I missed something.

I am using ubuntu, so the executable is not really an option.
Anyway, I will try to update to the latest version.

Thank you for your patience nomailing, github updated to support tshark v1.6. Download from the usual location:

I also changed the oracle machine location from US to South America, because I learned the hard way that accessing your non-US financial institution from a US IP address is reason enough to get your account suspended.

Probably the oracle should proxy traffic back through the client machine rather than connect to the bank directly. That way the bank can't see anything different.

We looked at a number of architectures, but we rejected this one because we didn't see it being possible to trust the buyer's network traffic. In this scenario the buyer would have access to the master secret that's been negotiated by the handshake, which means they could fake traffic post-handshake.

On the other hand, dansmith has been looking at the possibility of splitting the master secret in such a way that this kind of arch (buyer-oracle-buyer-bank) might actually work, with the oracle holding the mac key (but not the encryption key). Watch this space for more, I guess.

Edit: I guess I should mention that we also spent a long time looking at (buyer-oracle/escrow-seller-bank) architectures where the idea was that using the seller as a proxy provided an extra safety for the seller (they keep an encrypted record of the traffic) and helped with the peer-peer element since the IP addresses from which traffic originates are distributed (and kept local if buyers and sellers are in same locality). This approach doesn't seem to be the preferred one by most people in the discussion though, since it involves a "synchronization" of the seller being online in some sense, plus many people say as buyers they don't want their traffic going through unknown nodes (to me that concern makes no sense, but OK).

Btw we never went into buyer-seller-bank architectures because of NAT traversal issues. Of course a full P2P network can overcome that too.

Ah, I see.

Then yes, relays in various cities might make sense. I would suggest Tor nodes or other proxies, but those would give banks even more of an allergic reaction.

This seems like a fairly major problem. The master secret is normally an AES or RC4 key, right? I don't see how it's possible to split that. And Amazon definitely won't have datacenters in most geographies. Even if they did, I know from experience that all kinds of dodgy things can come out of AWS so some banks would likely treat that as inherently suspicious.

Hmmmm.

So a couple of things: first, the TLS RFC section 6.3 states that the master secret is partitioned into 4 16 byte blocks: client/server encryption key, client/server mac key.

This is the basis of the idea of "splitting"; if someone other than the buyer holds the server mac key, then the authentication can be done by another party.
About AWS oracles: yes, there isn't enough geographic distribution, and in any case it isn't a good idea to have a lot of (or maybe any) bank traffic flowing from there. But I think we all agree it can flow *through* there.

We are looking at this "splitting" idea right now. It's possible we can do this without the oracle, or with it.

Edit: as of right now I see some issues with this splitting idea. Probably best leave it alone until we have something more definite, or we decide it can't be done.

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

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

Oops, sorry, you're right.

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

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!

Escrow pool .... interesting.

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)

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.

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.

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

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.

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.

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

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

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.

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?

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

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

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.

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.

A short update of the project status: we have managed to tackle the MITM problem by splitting the MS/keyblock generation process between the auditor and the auditee, as it turns out, the RFC 2246 TLS standard effectively allows the splitting in the definition of the MS generation function:

PRF(secret, label, seed) = P_MD5(S2, label + seed) XOR P_SHA-1(S1, label + seed),

where S1 and S2 are the first and second half of the 48 bytes PMS, respectively.



The basic procedure is a modification from that posted by dansmith: https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488.

1. The auditee connects to the bank's server and starts a TLS handshake.
  
2. The auditee gives the auditor the bank's public key, client_random and server_random.

3. Both auditee and auditor independently generate 24 bytes of random data, called S1 and S2 respectively per the definition of the RFC2246 standard.

4. Both parties then cooperate to generate the encrypted PMS with the bank's public key, using the homomorphic property of RSA encryption:


RSA(2^(k_p)*P+2^(k_1)*S1+1)*RSA(2^(k_2)*S2+1) mod n=RSA(2^(k_p+k_2)*P*S2 + 2^(k_p)*P+2^(k_1+k_2)*S1*S2+2^(k_1)*S1+2^(k_2)*S2+1),

where P is a factor used in construction of the PKCS RSA padding. As can be seen from the result of the above equation, the cleartext PMS that is to be used by the bank can be splitted clearly into parts which can be generated separately by an auditor/auditee, as long as k_1 > k_2+k_s, where k_s is the number of digits of S2.

5. The auditee calculates P_SHA-1(S1, label+seed), generating 48 bytes - H_1 = H_11||H_12, where H_11 and H_12 are of equal length of 24 bytes.

6. The auditor calculates P_MD5(S2, label+seed), generating 48 bytes - H_2 = H_21||H_22, where H_21 and H_22 are of equal length of 24 bytes.

7. The auditor gives to the auditee H_21.

8. The auditee gives to the auditor H_12.

9. The auditee constructs M_1 = H_21 XOR H_11 (the first half of the master secret).

10. The auditor constructs M_2 = H_12 XOR H_22 (the second half of the master secret).

11. The auditee now calculates X=P_SHA-1(M_1, label+seed).

12. The auditor now calculates Y=P_MD5(M_2, label+seed).

13.The auditor and auditee share those bytes of each of X,Y which allow the other party (using XOR again) to generate the required secret data: for the auditor, the server mac secret, and for the auditee, the client and server encryption keys. During the whole process, neither the auditor nor the aduitee has access to the full PMS/MS/keyblock, which prevents both the MITM attack from being carried out, and the forgery on auditee's part. The finished handshake message can be generated similarly as it uses the same PRF function.

Known problems:

Padding the secret is a bit tricky, as it needs to meet certain specified format, however we are already able to generate valid PMS at a high probability(about 90% of the time).

The entropies of both S1 and S2 are a bit too small, with that of S2 being as small as 10 bytes, however any brute-force attack can only be conducted in real-time as the PMS will not be reused, so even 2^80 possibilities pose a formidable challenge to any known potential attacker.

The above procedure will only work for TLS 1.0/1.1, as the TLS 1.2 changes the PRF to use a single SHA-256 function, yet given the slow pace of IT infrastructure upgrade it would take many years before the TLS 1.0/1.1 are phased out.

Implementation:

All of the modifications are already implemented, live trials have been conducted successfully as well, right now dansmith is working on polishing the NSS patch.

As always, questions are welcomed, especially attacks against the security.

Amazing work once again. I don't have the time/energy to check the maths unfortunately, but it sounds plausible.

Looking forward to using the actual service.

The latest alpha release of the tlsnotary software has just been updated by dansmith and can be found at https://github.com/themighty1/tlsnotary/releases.

A few points about the current state:
We have been able to build binaries for MacOS, and indeed run tlsnotary, but there are some technical problems. We'll keep you updated on that. (Edit: Mac OS is now available - ignore the 'Tor Browser' branding; it is not a Tor Browser; we just reused parts of their build process).

The binaries are built using gitian and should therefore be reproducible. See the folder data/gitian for details.

For those running typical Ubuntu installs (and possibly other Linux distros), you may find that there are problems if your version of tshark is 1.6.7 (as it is by default in some cases, even if you do sudo apt-get install tshark). You should upgrade to tshark 1.10. Ask here if that proves difficult.

To test the basic functionality, run in 'self-test mode'. This will start both an auditor and an auditee running on your machine. Pay attention to the instructions in the status bar. Press 'Record' to audit a single page (Edit: button is now 'Audit this page'). You can do this multiple times to get multiple pages audited. At the end, press 'Stop', which will complete the audit by sending the evidence to the 'auditor' (in this case, yourself).

For real time support, you will usually find us hanging out on #bitsquare.io (temporary change of name) on freenode.
Or ask here if you prefer.

New update, now supporting custmoized IRC server/channel used for auditing information exchange, download with git clone https://github.com/themighty1/tlsnotary

We are actively looking for testers! Please, if you want to join, and help creating a future where people can trade and use bitcoins without being subjected to the whim of the banks, come to talk to us on #bitsquare.io on freenode, or ask here. :)

hi everyone, oakpacific told me to drop by and talk about distributed oracles.

We just published this whitepaper a few hours ago
http://github.com/orisi/wiki/wiki/Orisi-White-Paper
and we'll have an implementation ready of it tomorrow.

The idea behind Orisi is that there can be a set of independent oracles locking the funds until some external condition occurs. So it's something similar to what you guys need to have done.

Perhaps you can get some cool things out of our whitepaper, or even fork our solution and just attach your verdict module?
Feel free to ask me any questions, although I'll be going to bed any moment now (Europe, midnight, long day) :)

see below

Commentary/update (refer to (EDIT: paper is now at https://github.com/tlsnotary/tlsnotary/blob/master/data/documentation/TLSNotary.pdf?raw=true) for technical details):

So the last few weeks have been focused on patching what was, although practically very implausible, a theoretically important weakness in the design that we had been working on. That's why I killed the earlier doc and video links.

You can see a reference to it in the discussion on the thread back in February - does the fact that the client doesn't check the server mac during the (very brief) audit connection matter? Basically, yes it does - TLS provides authentication, and that mac check is the cornerstone of the authentication. It might be crazily difficult, but in principle someone might be able to alter the traffic in a malicious way.

So this hole has been patched (credit to dansmith for the main idea to solve it), and as described in the abstract of the document in the previous post, we have now fully reinstated the TLS security model, modulo a reduction in the entropy of the secret.

How is it done? The client (the auditee) makes a request to the server using the tlsnotary special sauce negotiated premaster secret, but at that point doesn't know the server mac secret/key. When the server sends the response back, the client effectively hits 'pause' and doesn't decrypt this traffic. The client/auditee sends a hash of the traffic (i.e. a commitment) to the auditor, who only then sends to the client/auditee the required secret data to reconstruct the server mac secret. At this point the client has the entire master secret for the session and can safely decrypt. They could even render it in the browser safely, although for other reasons we set it up so the client only looks at the raw html of what's being audited (just that one page).

All this shenanigans does not impact the user experience really (or at least, not more than it did before) - the user just sees a page reload taking a few seconds extra (and there are info messages in the status bar telling them what's going on in the mean time).

Some extra modifications have been done, importantly RSA encryption of the peer to peer messaging has been implemented.

As it stands, everything is badly in need of more eyes on it. I am much happier (see underlined above) and I have tested all this stuff to death, but the usefulness of that is limited beyond a certain point.

If anyone has questions about where to find stuff, please ask me.

Introductory video for tlsnotary: https://www.youtube.com/watch?v=kKdEhuiXYz4&list=PLnSCooZY6_w9j5tQ8jAeZtrl9l4NnL48G&index=3 (EDIT: updated link, new Intro video - also algorithm video in the same playlist)

(re-shared after some updates and checks).

The newest location for downloading https://github.com/tlsnotary/tlsnotary.

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: #bitsquare.io

I've just read this entire thread. It looks great.

Is this project still going?

Hi yakov,
Yeah, it's still going :)

We'd like people to try it out, as it's basically a finished product now (famous last words :) )

Ideally if we could get a good group of people (we don't need hundreds or thousands, just 'some' is fine) that could give it a try, then we could iron out any bugs and also get good feedback on what proportion of websites it works OK with (from extensive automated testing, it works with the vast majority of https pages, but certain dynamic features in some websites might stop it working in the way you want).

Installing it is very easy nowadays compared to what it was. Just have Firefox, have Python, and it should run out of the box.

I've tried to put tons of explanatory information in the README on the main page: https://github.com/tlsnotary/tlsnotary . So anybody new to the project, start reading there.

Thanks.

I hope I'll be forgiven if this is a question that has already been answered:

What if the "auditor" is an undercover cop and you're in a jurisdiction where this is illegal (surely everywhere once they find out about it)? Since the auditor can see your bank statement then he can see your account name and number and thus identify you. Is there provision for obfuscating that information?

Why would this be so? Surely they could not make it illegal to secure your own end of a data connection in which ever way you see fit?

It doesn't penetrate the corresponding party's system and it abides by the established secure connection protocol offered.

Because they make the rules and they will change them to prohibit whatever they don't like. Witness the fact that we have statutes prohibiting "money laundering" and "structuring" - legal concepts that were invented in the last twenty years.

Even if they didn't act immediately, the banks would amend their TOS to disallow it, until the government caught up (but they're almost the same thing).

It's absolutely certain.

The only way to avoid such an outcome for the individual client is to prevent his real-world identification by the auditor. The client has to remain pseudonymous. If you have to trust the auditor then what have you accomplished with all the rest of the trustless technology?

Hello hgt, at this moment, what you have to rely on, is the good-old rep/rating system, much like, you know, how they did in online black markets to counter Sybil attack.

We do expand serious effort to come up with something that can allow an auditee to have only the part of his statement that is strictly necessary (i.e., the amount and the destination account) to be verified by the auditor to be authenticated(which we call the "dark mode" in a tongue-in-cheek way), in the end we prove it's somehow theoretically not impossible, but is rather tricky would require quite a lot of developmental effort. Also note that the 'dark mode' still can't protect the identity of the seller, which is inevitable as the auditor has to make sure the money goes to the right account.

The good news is that I believe we are definitely not on the radar of the agencies, if we ever become so popular to draw their attention :P, we will certainly invest much more effort into the anonymity protection.

Thank you for your question!

Hi Oakpacific! Thanks very much for your thoughtul response.

Ratings will mitigate the problem of bad actors in the same way that ratings mitigate centralized monetary exchanges and markets.

Consider the late Sheep market as a perfect example of the latter.

An evil operator will patiently build reputation while fulfilling his role faithfully, all the while getting bigger and bigger, and then one day take everything and wipe his clients out.

In the case of an evil auditor (whether private or state) and auditees that are de-anonymized to him, he will patiently collect real-life identities until a huge database is amassed. Then one day there are sudden and co-ordinated mass arrests.

"Under the radar" is a silly idea. You think LE isn't already monitoring a big site such as this?

Another thing to reflect on: I (like millions of people around the world) have had occasion in the past to *print* my bank statement - including the account name and number and the balance, and monthly transactions, and present it to a local bureaucratic office to "prove" my savings/income. This was done without my bank's permission.

Is tlsnotary really so different to that, in terms of privacy and permission? It *is* different in one very important sense - it's *actual* proof, not pretend proof!

Hi Waxwing! Yes, your comparison is very reasonable.

But we're not discussing a reasonable adversary, but one who uses armed force to gain economic advantage and who adjusts the rules to suit its goals.

tlsnotary will be construed as something like wire-tapping and conspiracy to commit fraud (after all, the bank, who is one party to the communication, has not consented to the use of tlsnotary). I'm not calling it that; I'm saying that they'll apply some such label. And if the statutes as they stand are not sufficient then they'll change them to make their case stick.

But if they can't identify the participants because they remain pseudonymous then the statutes are moot.

hgt,
Yes I fully understand what you're saying. I did want to start from the most important basis though - that it's not different from existing audit mechanisms in terms of privacy and permission.

I share the same perspective as you that, given the Bank Secrecy Act, 'structuring' and so on, we live in a world where if those in power decide that they don't want something, it can be declared illegal at any time  - because terrorism, because child porn, whatever, and logic be damned.

But I'm not sure the risk that you highlighted is the most important one to focus on. It's true that having an auditor not know any transaction details is preferable, but we are talking about manual audits here because we cannot automate the interpretation of bank transaction pages for all banks, which means that at the very minimum the auditor *must* know the account number and bank, IF an audit takes place. So currently the situation is : your counterparty *always* knows your bank identity (account number), your auditor knows it only if there is an audit, which will of course be all the rarer because it's impossible to fake the result.

It is very likely that an auditor will need to have significant community reputation to operate. There's nothing intrinsic in this software deciding how auditors get setup - there could be thousands, there could be just one. I personally like the design of having a large pool which gets chosen from in an unpredictable way to minimise collusion/bad actor risk, but this is a matter of considerable debate in groups like TLSNotary, bitsquare, openbazaar etc.

An automated auditor - running on an 'oracle' - is a nice concept, which we've already played around with. But (a) not sure the technology is really ready for it and (b) it would need perfectly predictable parsing of transaction records. Could work with one fixed fiat payment method perhaps (assuming you can set up an oracle!)

Thanks for the clarification.

This is jaw-dropping!

I successfully self-tested myself on a few websites and I'm especially amazed, because the whole process (or the part that I saw until now) was straight forward and without unexpected behavior or any other obstacles.

Good to hear.

As you can see, this thread hasn't been very active recently. You're welcome to post any thoughts/queries etc. here, or you can join us on IRC (freenode) at #tlsnotary-chat, or your can post an issue on github (https://github.com/tlsnotary/tlsnotary), or you can even take a look at the nascent discussion forum https://tlsnotary.org/smf (we're trying to put together a proper website, but it's not done). So I guess that's enough options. Now we just need a few more people like you to test it out :)

Thanks a lot, still, worth it to remind again to log out before you send anything to a real human! ;)

We are happy to report that https://bitbargain.co.uk (a fiat<->btc marketplace) told us that they successfully used TLSNotary in an unusual case where bank lost the buyer's payment.

Even though https://bitbargain.co.uk processes ~300 trades per day, twice a year they'll have a situation where there is no way to resolve a disagreement between reputable parties.

Using TLSNotary the seller showed to the BitBargain staff their online bank's statement page (with a cryptographic proof) without revealing their bank's login/password. Good times.

So the buyer proved they had actually made the bank transfer using TLSnotary also?

And seller was able to prove he hadn't received (yet) because bank had lost the payment.

Interesting that a bitcoin-centric system for removing trust has been used to prove legacy banking error ... good work.

AFAIK, the seller provided a proof, then the buyer was advised to press his bank more, who is later found to be the party at fault.

Feel free to read the latest blog post and try out the new version (only proof of concept, but functional):

https://tlsnotary.org/wp/?p=27

Simple explanation: audit a page and get a .audit file. You can give it an auditor later - where 'auditor' means anyone :). It's transferrable (it's as if the server had signed the page with a digital signature).
You perform the audit with a remote 'notary server', which knows basically nothing: there is no login, no credentials, you don't give the notary server either your html or the encrypted version of your html. It sees nothing except the server pubkey. It just provides you with some preliminary random secrets and then signs that you received the completed version of the secrets after you committed to a hash of your encrypted data.

Well, a little more detail in the blog post above.

Note that although there isn't much going on at the main repo https://github.com/tlsnotary/tlsnotary at the moment, there is a lot of work being done in other places.

In a little while I might throw up a couple of .audit files so others can look at them (you can just run the auditor script locally to verify a .audit file's validity).

You can try verifying an example audit, see the notes here: https://tlsnotary.org/audits.html

The example given is a file proving a PM I received on reddit from dansmith. You can verify it's authentic in about 10 seconds by running the `python tlsnotary-auditor.py <audit filename>` in the src/auditee directory of the repo https://github.com/AdamISZ/taas-poc-1-auditee.

Hopefully others will add a few similar .audit files there for experimentation.

A reminder, it needs openssl for the signatures; for Linux/MacOS it'll be there by default, but if you're on Windows you may not have that (this will change at some point, it's just for proof of concept).

https://www.tlsnotary.org/pagesigner.html

PageSigner is a drastic simplification of the user experience of TLSNotary. You can get a file which proves you visited a webpage with one click in Firefox. No need for Python, key management, or delays (it takes a few seconds). You can pass the file to an auditor at any later date and they can verify it. Watch the walkthrough video on the above page and let us know what you think.

There's a lot more to say, but feel free to give it a try and get back to us with any questions.

Sounds like a major milestone. I'll test it out.

Chrome is now supported (same link as before, short walkthrough for installation provided there; Firefox is a one (ish) click install, but Chrome requires pushing a few buttons in the correct sequence :) )

From a discussion about a particular use case on IRC (API access), I feel like it's worth laying out the tradeoffs between three technologies:
(Edit: this table was not well designed: a 'yes' means 'using this feature/technology'. So if there are two 'yes'es on one row, it means combining those technologies together).

tlsnotary	website's digital signature	(amazon aws) oracle	Provides...
no	yes	no	Non-repudiable data (the webserver signs the webpage). The webserver chooses what to sign. Rarely used, controlled by webserver.
no	no	yes	Proof that the oracle ran the code that's claimed
yes	no	no	Proof to *one* party that the webpage is genuine
yes	no	yes	Non-repudiable proof if the oracle signs the hash of the page (i.e. like digital signature)

Consider the application: API access. Oracle only looks like a good choice: write the oracle to retrieve the webpage (just ping it with a url, it sends back the result) - note that the oracle could then append its *own* digital signature, to provide the non-repudiability you're looking for. This does, however, require giving the oracle control of the API credentials (which conceivably *could* be OK, but at the very least it means passing it outside your machine). Using the last row of the table (which is what pagesigner uses) is more complex but has the advantage of putting a wall between the credentials needed for access and the oracle. Also having the oracle be the source IP address of https requests could have disadvantages.

Browserless pagesigner: https://github.com/tlsnotary/pagesigner-browserless

This allows you to notarize a page from the command line, enabling automation. This version was created in response to someone who's creating an oracle for real world data; with this, they can use pagesigner to query an API (with their credentials) and generate a proof of data recorded by an authoritative website.

See the README for usage notes.

Neat how this project is branching out naturally based on the original concept.

https://github.com/tlsnotary/pagesigner/issues/12

Hi,

Could tlsnotary be applied to wallets and prove a payment was made? Saw implimantation to SSL, but I think for crypto payment it should be done differently.

Tnx

@Sylz, I'll need much more context for what you are asking, but the short answer is
you can use tlsnotary-based PageSigner to create a transferable proof of e.g. blockchain.info's webpage showing the payment/transaction.

It isn't working currently.
Is there anyone that can run an alternative?