Topic: Alpha testers needed - fiat-BTC exchange - Paysty (Read 1804 times)

I copied the above post with my response to a thread where we discuss the technical aspects.
https://bitcointalksearch.org/topic/m.3609507

Hi waxwing and dansmith,

first, thank you for this alpha test. I am currently trying to understand the oracle code and trying to set it up on my own AWS accound for initial testing.
I am not very familiar with Amazon EC2 but I was able to setup the oracle as you described in the INSTALL-readme.
Now I am trying to understand the points in the readme how someone can make sure that the oracle was not maliciously modified.
First, I have maybe a stupid question regarding the public key in the file https://github.com/themighty1/ssllog/blob/alphatest/oracle/authorized_keys. What is the corresponding private key and why do we need this here? Shouldn't we try to block all ssh access to the oracle?

I think it will take some more days until I really understand the other checks what you describe in the INSTALL file...

Just to let anyone interested know, I've set up an alternative escrow node with an EU IP address. You can PM me for a key if you prefer to do that.

Current breakdown of tests by country (only counting successes):
1. UK: 3
2. Germany: 2
3: Latvia: 1
4: Hong Kong: 1

OK, so a little public feedback to expand on grebit's issue, as it may well apply to others:

If you have recently sent a payment to someone, the bank interface will usually store some information about the payment - for example, what I put above in the first post.
However, the info they store may not be complete. Sometimes, they replace an account number with an internal reference number. In other cases, they'll put the name of the recipient, but not the account number. The latter is enough, for proof purposes.

In some cases it may seem that they don't give anything more than an entry in your statement with the amount sent. This, obviously, is not good enough for proof since no third party can be sure where that payment went.

If you're in that latter situation, that's the primary reason we're doing this test. At its face, the deduction would be that for this bank, Paysty won't work.

Edit: forgot to add the other very important issue about bank compatibility: many banks support the ability to pay an arbitrary counterparty, not defined in advance. Often this is supported with 2FA. If your bank doesn't support this, i.e. you have to fill out a form or go to a branch of your bank to enable payment to a new payee, then clearly it will be much more awkward for you to try to use a system like this.

I happily gave Paytsy a whirl, knowing that I never ever gave anyone the SSL keys to any part of my banking session.

Sadly my bank does not seem to be compatible.

OK you've had you say ... big red warnings, etc ... now let them get on it with for people who understand what they doing maybe?

You stay safe you hear?

All that is true, but to be fair to us, there is no way a subtle bug can introduce the sending of a file across a complex network connection. It would be even less likely than that our software accidentally sent the file ~/dummy.txt or C:/dummy.txt to a third party by accident.
It's actually a pretty critical point that I addressed in another thread, in response to Mike Hearn's comments on our project. Whatever other bugs might exist in our software, if you can satisfy yourself just that it doesn't send ssl keys, then the worst that can happen is that it just fails to work. It can't create a security/privacy problem.

And there are even more safeguards based on the way the oracle machine is instantiated in the cloud, but no need to get into that here.
Your feedback is welcome in any case.

You cannot really answer (1) definitely, you can only say that the software is written with no intention to do something unsafe... unless you really have analyzed the whole stack of software and libraries you use. Bugs and weaknesses are not always obvious and larger, more public projects *coughdebiancough* also had their problems despite the code being open. I don't want to pay an auditor to check your code and am not good enough in security to do this myself, so I rather stay on the safe side.

Your concerns are understood.

You seem to have misunderstood something here. The ssl keys stay on your machine in this test. It's only in the fully working form (which hasn't been made yet) that ssl keys will be transferred to someone else, and then it's ONLY ssl keys for one html page (which you can verify), and ONLY in cases of dispute with your counterparty.

The only reason I'm arguing with you is to make very clear there are two different considerations here: (1) does the software do anything unsafe and (2)do you know, or can you trust, that it doesn't do anything unsafe.

I'm stating that the answer to (1) is no; but I totally get that without better information, you can't answer 'yes' to (2). It requires that a user, or some independent party that the user trusts, can review the source code and verify that nothing dangerous is being done.

I consider ISPs to have a lot more ressources than the typical guy on the internet...

Also I know that it is encrypted, still you don't just want the dump - you also want the key(s) to decrypt that. I am definitely not going to install software that is designed to intercept and/or extract SSL keys from my communications, even Open Source one. It just takes one bug and your users are very much in danger.

Not someone with access to lots of resources, necessarily; your ISP, for example, or any other node on the network through which the traffic passes. That wasn't my point; my point was that it's utterly pointless because the data cannot be read by those people. That's the whole point of ssl.

I just accessed my bank page, please post the dump here.

Anybody with access to a lot of ressources can do this, yes. You can't and I won't enable you to do that.

Thank you for the report, greBit.
Fixed that, Paysty now sets the permissions automatically, no need for Linux users to do anything manually.

Anybody can take such a dump of your communication any time. It's useless because it's encrypted.

There is NO WAY that I will let any third party get a dump of communication between me and my bank.

Comment:


My response:
Good call. Yes openssh insists on, if I recall correctly, 600 permissions for private key files (or at least 0,0 for group,world).

(This won't apply to Windows users).

This thread follows on from this post.

But before you read the details, some background.

You're welcome not to read ALL of this Just get a flavour. Then click the link above for instructions on how to get involved.

Motivation The biggest problem with Bitcoin is getting hold of some. Conduits allowing fiat money to flow into Bitcoin have proven themselves unstable, and so many are searching for a decentralized way to allow this to happen.

The problem The problem with most attempts to solve this is the fundamentally different nature of fiat money, controlled by banks, governments and financial institutions is so different from the fundamental nature of Bitcoin. Bitcoin is irreversible, most other forms of money in everyday use are not. Take a look at the scale of money hardness. If you try to trade directly with a counterparty (i.e. not via an exchange), say, credit card money for bitcoins you have an insurmountable problem: the bitcoin buyer can reverse his payment in the future.

Solution 1: the localbitcoins model The site localbitcoins.com has been a tremendous success in allowing people to transfer cash and other 'hard' money for bitcoins. Physical transfers are awkward in various ways, and impractical for those in remote locations. Online payments with mechanisms like bank wires and OK Pay seem like a better solution, although they incur fees; they're faster, location-independent, and in some ways safer. Escrow helps keep the process even safer, but there's a problem: what if the bitcoin seller denies having received the funds? Here's what the localbitcoins site says about disputes:"LocalBitcoins.com support handles disputes based on evidence and reputation supplied by trade participants." What evidence might that be?
We shouldn't forget also how centralized localbitcoins is as a business and as a trusted third party, albeit the model can be replicated.

Solution 2: the Paysty approach With Paysty we are proposing a significant improvement to the above model: a way to prove that you sent a bank transfer. You still have the escrow mechanism, but it's relegated to a trivial checking mechanism: the escrow requests proof of transfer.

So how does it work?
Payments of 'hard' money (see above) made via bank transfer and via OK Pay (and some others) are done over ssl (https) connections on the internet. This network traffic is encrypted, for obvious reasons. There is nothing stopping you recording encrypted traffic; it's just that without the secret key which both you and your bank have, it's not possible to read it.
So here's the trick: pass your internet banking session through a proxy, which records the encrypted traffic. The bank won't know this has happened: they just see the traffic coming from a particular IP address.
But let's go one better: let's host the proxy on a virtual machine in the cloud, and let's set that machine up in a special way so that anyone can verify what software it's running, and no one (including the account owner!) can modify what it does. Let me be clear: any person accessing this machine can only run one program by accessing the machine, and the only extra thing the owner can do is shut it down.
So? You can record the traffic. Big deal, it's encrypted. We can do more. The person making the bank transfer can, if asked, and they agree, provide ONE (or a few) of the ssl encryption keys to a third party. This will allow that third party to decrypt ONE html page. That html page might have this kind of info:


Subject   Acknowledgement - Ref No. BA123
20 Oct 2013

Status: transfer completed
TT Reference No: XXXXXXXXXXXXXXX
Processing Date: 20 OCT 2013

From Account: my-usd-account-number
Payment Amount: USDX,XXX.XX
To Name: recipient-account-name

To Account: beneficiary-acct-number
To Bank: XXXXXXXXXXXXXXXXXX
Bank Address
Amount Debited from Source Account: USDX,XXX.XX
Charges: USDXX.XX
Charge Account: my-usd-acct-number


Notice that you will never, of course, have to display your username, password. That will remain fully encrypted and as safe as it was in just doing a normal banking session.

So, how will it usually work?
Usually, you will
(0) Choose in advance an escrow agent to act as third party for bitcoin payment, and to adjudicate dispute.
(1) agree on a transaction with a counterparty (we are looking at options for how to set up private messaging for that now)
(2) place bitcoins in escrow (if you're the seller)
(3) do your normal internet banking without running Paysty (if you're the buyer)

Note for those aware of such things: there is a possibility that this whole system will be integrated into Open Transactions as a legacy banking interface; this will mean that OT will handle (0),(1) and(2).

And how will it work if there's a dispute?
The most plausible type of dispute is where the seller of bitcoins says "no, I didn't receive those fiat funds".
The buyer of bitcoins (=the sender of fiat funds) will be asked to run Paysty. Inside Firefox, she will browse to her banking website and to the page which shows proof of the transfer, including the account number of the recipient and the amount. Paysty will record this whole banking session in encrypted form on the 'oracle' machine (the one in the cloud, remember?) which is doing the proxying. Then the escrow will request the buyer to send that set of ssl encryption keys that decrypts that one html page, which the buyer has marked as being proof. This is the objective basis on which the escrow can judge.

The best thing is - the more watertight the proof, the less likely anyone will dare to try to defraud you...

So this isn't finished? Why does it need testing? The part of the software that's new (the verification/proof of bank sessions) is basically finished. The other elements are bits of software that already exists so we're not very worried about getting them working.
What it needs right now is a good set of example data of how well it works with bank websites. We already have evidence from about 5 banking websites that it works fine, but we'd like many more.
What does the test actually do?
If you follow all the instructions in the link at the top of this post (here it is again), you should see either a "congratulations" or an error message. Report these findings back to dansmith or I.

For best results, please use a page on the website with a record of an actual transfer of funds, so you can select an account number and sum/amount. If you choose to use some other data on the page, such as a statement balance, or anything else, it will still work, but this will not serve the purpose of the test - we want to know whether it's possible to use this system with your bank.

How can I know this software is safe?
The software is open source and, in this simple testing version, does not transfer your ssl keys off your local machine under any circumstances. Therefore you're in the same situation as with a normal internet banking session - the only thing the 'oracle' machine sees is encrypted data. If you feel like reviewing the code, go to https://github.com/themighty1/ssllog, and in particular review buyeroracle.py to see how ssl keys are handled locally. If you need help understanding something about the code, give us a shout.