Topic: [PAPER] 3-factor Authentication for Exchanges (Read 2179 times)

The exchange has to operate in real-time, waiting for users to release funds is not an acceptable solution (and introduces problems such as "Oh the price went up... yeah about those funds...").

There is actually a lot you can do. It just depends on the exact problem you are trying to solve. For example, why does the exchange need access to the wallet at all? It might be enough to prove (e.g. by signing something with your private key), that you have access to the funds in some account (public key), and then once the deal is brokered you just release the funds all by yourself. The exchange checks this public fact and credits you some dollars. The dollar side of the transaction might be the more problematic one, but as I said, you would have to specify what exactly should be done.

As I said previously, if an attacker is monitoring all the communications between the user's computer and the exchange, and has access to the files on the exchange, there isn't really much you can do in the way of allowing the exchange to safely create transactions on the user's behalf without the situation being compromised.  It's fundamentally flawed.  If the exchange has to create a transaction for the user, and the attacker has that level of control, then the attacker can withdraw coins at will.  They only need the decrypted private key to do so.

That's the point of this; it isn't to prevent an attacker withdrawing coins when the user is being observed making trades; it doesn't protect against that and quite frankly, I don't really see how anything could.  What the design does do is prevent an attacker from withdrawing coins from accounts that he hasn't observed.

This is in contrast to existing systems where an attacker can manipulate the system and withdraw any coins he likes, when he wants to, without having to observe anyone.  There are no restrictions on what an attacker can do to existing system.  That's what this paper set out to solve and that's what the design does.

As I said previously, until you can show me a solution in which the exchange can use a private key to create a transaction and an attacker still can't manipulate the transaction as it's being created, then there's no point in continuing the discussion further.

That is kind of right. This is because it is a non-trivial task to do it right, and if I were to start thinking about it properly, I would not start with your paper. See below for one reason:

[/quote]

This is one example of the carelessness/imprecision that IMHO does not make the paper worth repairing. The attack I pointed out does NOT require both the exchange and the user's computer being breached. Only the exchange needs to be breached. And your requirements claim that you want to defend against this case. But your design does not.

Unfortunately you haven't actually detailed any solutions yet other than stating the current system is unsatisfactory.  If you want to outline exactly how this can be done, then I'm all ears, but until then, I don't think this conversation is going to go anywhere.

For future reference, the requirement of the paper which you quoted explicitly details that the situation that we've been arguing about is noted as (practically the only) attack vector on the system:

Please be careful with assertions such as "there is no other way ...". That's a classic fallacy. Just because you do not see the way doesn't mean there is none. Actually, in this case there are numerous ways to go about this, as hinted in my first post. Unfortunately, I believe it would be much easier to start a whole new design than try to save the one pointed out in the paper. Sorry.

No, it does protect against that.  If an attacker breaches the exchange, they can not place trades on behalf of a user unless that user makes a trade after the exchange is breached.  That's the key point here.

You can't protected afterwards given that the exchange must be able to easily move coins around and must be able to transfer coins when an exchange match is made.  The alternative to this system would be for the exchange to wait until the user transfers coins from their BitCoin wallet and then wait one hour before the trade actually takes place, which is not an acceptable system for an exchange.

There isn't another way that the exchange can have the private key as needed, the information to use the private key for signing (such as decryption information), and still not have an attacker be able to observe those variables.

For this attack it is not necessary to breach the user's computer. Owning the exchange is enough. And this is one of the scenarios that the paper purports to protect against. Yet it doesn't.

No, see Explicit Requirements:

1. In the event the exchange is breached, the attacker should not be able
to withdraw funds or place trades.

Nothing stops you from recording the master keys and differencing codes if you had that level of control over the server, the intention is that you wouldn't be able to automatically access the BitCoins used by the accounts in the past (meaning you can't steal all of the BitCoins from the exchange).  It's about minimizing damage.

Unfortunately, since the exchange must have easy access to BitCoins for trading (i.e. they must have a wallet of some kind with the user's BitCoins in it; currently I expect this is done with one giant wallet, here it is one wallet per user) there is no way to have both the exchange accessing the coins without you providing the details required to open the wallet.  Please note that you can't simply send BitCoins to the exchange when you want to do a trade, as it takes up to an hour for a transaction to be processed and confirmed (which is no good for trading).

What makes you believe that the master key is never stored at the exchange? When I own/pwn the exchange, what keeps me from storing it?

There are crypto techniques (such as zero-knowledge proofs) that make it unnecessary to give the exchange (which you do explicitly not trust) any part of your secrets.

Transmission of the master key on trade requests is exactly what keeps it secure; an attacker can not break into the exchange and steal coins without also knowing the master key, which is never stored at the exchange.


It's not about trusting the exchange, since you must originally trust the exchange when you make trades (because for that short time, the exchange knows the master key and differencing code); rather it is to prevent attackers from gaining access to your wallet after-the-act.

In the case of MtGox, this system would have prevent the type of attack that was seen; an attacker would not have been able to place large trades on accounts unless they observed the user actually making previous trades.


Unfortunately if it's firewalled off and inaccessible, then you're implying that the web server also has no automatic way of transferring coins from the user's exchange wallet into the "Active Transactions" pool, which is not an effective situation for an exchange.

1) It's not PGP/GPG persay, it's just a 'key' that's used in conjunction with the SMS verification to decrypt the users information in the database.

2) We're not sure about that at the moment, but I think it's probably only going to be on purchases >$100 (or something like that) - don't quote me on that though.

3) We're not going to be using a wallet, the private keys for the coins are kept encrypted in the database, and can only be decrypted with the masterkey and the sms verification togethor.

Couple of thoughts

If you're talking two way verification through public-private keys, you'll need some form of client for your customers to interact with, you'll also need a fairly robust key management system and a way to validate and manage when a key has been stolen.

SMS is an interesting idea for large exchanges, however if I'm going to have to jump through hurdles for each trade I might decide to go somewhere else where it's easier.

Not sure what the point is of establish a wallet for each user, the wallet should be buffered and fire walled off and not even accessible from the web server.

Still haven't read paper, but exchanges must be trusted, you're giving them your bitcoin so they must be worthy of trust.

Hi,

The problem is an organizational one, if you don't trust the exchange in holding the money, the only logical alternative is that a user must make a manual effort to verify the transaction before it is processed. This more or less defeats the purpose of an exchange service that gets its added value because it can act on behalf of the user and large amount of transactions are automatically processed. Otherwise you end up with an ebay for bitcoins.

But perhaps I misunderstood your paper or exchanges in general.

Cheers,

Martin

Reviewing this, will give feedback when done.

Well, thanks for trying. Unfortunately, I find your paper largely confusing and unclear. First of all, what problem do you intend to solve that has not been solved by standard techniques already? Second, I get the impression that you have a poor understanding of the state of the art in applied cryptography. For example, it should not be necessary to transmit the "master key" to the server. If you are trying to build this for your own exchange I suggest hiring someone who has read a book or two about theoretical computer science/cryptography.