Bitcoin Forum
December 03, 2016, 04:43:38 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: [PAPER] 3-factor Authentication for Exchanges  (Read 1767 times)
Hach-Que
Newbie
*
Offline Offline

Activity: 19



View Profile WWW
June 21, 2011, 12:47:27 PM
 #1

A few people and I just finished writing up a short paper on how 3-factor authentication can be used to secure exchanges such that an attacker can't place trades on a user's behalf without compromising the user's computer and the exchange (if the user is using physical verification).

http://www.redpointsoftware.com.au/papers/3FactorAuthenticationForExchanges.pdf

Feedback is appreciated (especially anything related to flaws in the proposed system)!
1480740218
Hero Member
*
Offline Offline

Posts: 1480740218

View Profile Personal Message (Offline)

Ignore
1480740218
Reply with quote  #2

1480740218
Report to moderator
1480740218
Hero Member
*
Offline Offline

Posts: 1480740218

View Profile Personal Message (Offline)

Ignore
1480740218
Reply with quote  #2

1480740218
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 21, 2011, 01:50:12 PM
 #2

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

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
June 21, 2011, 01:54:08 PM
 #3

Reviewing this, will give feedback when done.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Martin P. Hellwig
Jr. Member
*
Offline Offline

Activity: 33


View Profile
June 21, 2011, 02:26:50 PM
 #4

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

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
June 21, 2011, 02:45:14 PM
 #5

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


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

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
je_bailey
Newbie
*
Offline Offline

Activity: 18


View Profile WWW
June 21, 2011, 02:53:42 PM
 #6

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.

Jason Bailey
Developer/Designer
SomeoneWeird
Hero Member
*****
Offline Offline

Activity: 700


View Profile
June 21, 2011, 03:00:23 PM
 #7

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.

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.
Hach-Que
Newbie
*
Offline Offline

Activity: 19



View Profile WWW
June 21, 2011, 11:59:45 PM
 #8

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.

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.

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

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.

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

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.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 22, 2011, 11:10:48 AM
 #9

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.

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.


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.
Hach-Que
Newbie
*
Offline Offline

Activity: 19



View Profile WWW
June 22, 2011, 11:29:00 AM
 #10

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.

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.

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.

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

Activity: 700


View Profile
June 22, 2011, 11:30:14 AM
 #11

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.

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.

Quote

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.

Yeah, and the paper is written from the perspective that the exchange hasn't been hacked.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 22, 2011, 01:15:31 PM
 #12


Yeah, and the paper is written from the perspective that the exchange hasn't been hacked.

No, see Explicit Requirements:

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

Activity: 700


View Profile
June 22, 2011, 01:40:56 PM
 #13


Yeah, and the paper is written from the perspective that the exchange hasn't been hacked.

No, see Explicit Requirements:

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

Quote
In the event that both the exchange and the user's computer is breached,
the user has not previously placed trades while under surveillance and
the user has set up SMS authentication, the attacker should not be
able to withdraw funds or place trades on the user's behalf.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 22, 2011, 02:15:00 PM
 #14

Quote
In the event that both the exchange and the user's computer is breached,
the user has not previously placed trades while under surveillance and
the user has set up SMS authentication, the attacker should not be
able to withdraw funds or place trades on the user's behalf.

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.
Hach-Que
Newbie
*
Offline Offline

Activity: 19



View Profile WWW
June 22, 2011, 10:41:38 PM
 #15

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.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 23, 2011, 04:07:24 PM
 #16

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.
Hach-Que
Newbie
*
Offline Offline

Activity: 19



View Profile WWW
June 24, 2011, 12:33:42 AM
 #17

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:

Quote
In the event that both the exchange and the user's computer is breached, the user has not previously placed trades while under surveillance and the user has set up SMS authentication, the attacker should not be able to withdraw funds or place trades on the user's behalf.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 24, 2011, 11:09:11 AM
 #18

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.

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

In the event that both the exchange and the user's computer is breached, the user has not previously placed trades while under surveillance and the user has set up SMS authentication, the attacker should not be able to withdraw funds or place trades on the user's behalf.
[/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.
Hach-Que
Newbie
*
Offline Offline

Activity: 19



View Profile WWW
June 24, 2011, 11:37:24 AM
 #19

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.
tubro
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 24, 2011, 01:16:06 PM
 #20

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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!