Split private keys

[ben-abuya]

Note that unlike smart cards, these devices would not be customized per user. If yours is at home, you could just as easily use your friends.

How do you sign in to the online service? If you use a pass phrase there could be a keylogger. This doesn't sound like 2-factor authentication, because your device doesn't authenticate you. So it solves the trust problem (you know the transaction is legit), but a hacker could steal your identity and pretend he's you.

[1714206574]

1714206574

[1714206574]

1714206574

[Mike Hearn]

You can just leverage Google or Facebook authentication if you want 2-factor on signin. That's a 2 hour job for any BitBank.

You're right that it doesn't solve the case of an attacker who just wants to observe your bank statements and doesn't care about stealing your coins. I don't think anyone has ever solved that one, without assuming the web access device is trusted.

[ben-abuya]

You can just leverage Google or Facebook authentication if you want 2-factor on signin. That's a 2 hour job for any BitBank.

Ok, that's the missing piece. I think that's a pretty good option for Gavin's challenge. I'm not that familiar with Google or Facebook 2-factor authentication, but if people become comfortable using it via a mobile phone or smartphone and these cheap little devices become easily available, that would be a really nice system.

I still like the idea of a secure usb device that obviates the need for the online service. It's a tradeoff of trust of a 3rd party service against the responsibility of securing your physical keys.

You're right that it doesn't solve the case of an attacker who just wants to observe your bank statements and doesn't care about stealing your coins. I don't think anyone has ever solved that one, without assuming the web access device is trusted.

I never really expected that of the scheme. Most people don't have incredibly sophisticated keylogging, memory-reading root-kits on their computers and teams of hackers standing by to analyze the data collected from them. As long as your money is safe I think that's pretty reasonable for the average joe.

[kjj]

While I was driving today, I had some thoughts on what exactly was needed to get my hardware wallet project talking to the client.  Might work for other types of smartcards projects too.

I also had the bright idea of letting the client act as a stand in for a hardware wallet.

Step 1.  Add some new methods to the JSON RPC API.  I think I can get by with just 4, but I may have missed something.  acceptPublicKey tells a node to add a new public key and include it in balance calculations.  getPublicKeyTransactions tells a node to return all transactions involving a given public key.  getPaymentRequest tells the node to give it any pending payment requests.  returnPaymentRequest returns the signed transaction to the node.

Step 2.  Add UI/config file support for these calls.  A set of options to specify a remote JSON server to connect to as a client.  An option to tell the client NOT to generate keys.  A checkbox on the payment page to tell the node to queue up the amount/address pair for delivery to an external device in response to a getPaymentRequest RPC call.  A button to tell the client to ask the other server for transaction requests.  A dialog to display and request confirmation/deletion of queued requests.

At this point, you could have two computers running bitcoin.  One on your main box that has no keys and is unable to send any coins by itself, and a second box that does not connect to the network ever, but only talks RPC to the first box.  All keys are on the second box, so all payments must be relayed through the JSON RPC service from the first box to the second.

Since the second box is on the network too (or it wouldn't be able to talk to the first box), won't it get infested too?  Yup, and that brings up...

Step 3.  Implement JSON over serial.  Could be actual serial, could be serial over bluetooth, could be serial over USB, could be a terminal program on each box with the super paranoid user relaying commands back and forth by retyping them.  I think we would need to extend the JSON spec, since it doesn't seem to contain any provisions for in-band authentication, and we won't have access to the HTTP layer doing it for us.  I propose that each string be followed by a hash of the command + password.

Step 4.  Implement a security system that allows the developers (or the use, I suppose) to allow/disallow certain RPC to come in from or go out to certain interfaces.

Step 5.  Build hardware that talks this protocol over various forms of serial.

I think that this approach has a bunch of advantages.  First, it allows everyone with a junk box sitting around the ability to set up a secure offline wallet without needing any special hardware.  Second, it allows debugging to take place on computers which have excellent debugging tools, at least initially.  And when we get to the step where we are working with hardware, we will have a protocol to target that is known to work.

[ben-abuya]

Step 1.  Add some new methods to the JSON RPC API.  I think I can get by with just 4, but I may have missed something.  acceptPublicKey tells a node to add a new public key and include it in balance calculations.  getPublicKeyTransactions tells a node to return all transactions involving a given public key.  getPaymentRequest tells the node to give it any pending payment requests.  returnPaymentRequest returns the signed transaction to the node.

acceptPublicKey, balance calculations -- I like that!

getPublicKeyTransactions -- why do we need that?

getPaymentRequest, returnPaymentRequest -- yep these are exactly what's needed to enable use with secure devices. browsing through the code shows that the relevant code that has to be split out is all in a critical block. the signed transaction will have to be checked for viability once it's imported back into the client.

Another thing you'd want to be able to do is test the private key signing without actually doing a transaction.

Step 3.  Implement JSON over serial.  Could be actual serial, could be serial over bluetooth, could be serial over USB, could be a terminal program on each box with the super paranoid user relaying commands back and forth by retyping them.  I think we would need to extend the JSON spec, since it doesn't seem to contain any provisions for in-band authentication, and we won't have access to the HTTP layer doing it for us.  I propose that each string be followed by a hash of the command + password.

Why do we need in-band authentication? Why not just encrypt the JSON with the secure device's public key? I think it's best to use established secure protocols like TLS if at all possible.

[kjj]

getPublicKeyTransactions -- why do we need that?

The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later.  It would use this request to ask for them.  As an aside, the secure device should only make this request upon a command from the user.  That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data.

Step 3.  Implement JSON over serial.  Could be actual serial, could be serial over bluetooth, could be serial over USB, could be a terminal program on each box with the super paranoid user relaying commands back and forth by retyping them.  I think we would need to extend the JSON spec, since it doesn't seem to contain any provisions for in-band authentication, and we won't have access to the HTTP layer doing it for us.  I propose that each string be followed by a hash of the command + password.

Why do we need in-band authentication? Why not just encrypt the JSON with the secure device's public key? I think it's best to use established secure protocols like TLS if at all possible.

Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below.  Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.

My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.

[ben-abuya]

getPublicKeyTransactions -- why do we need that?

The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later.  It would use this request to ask for them.  As an aside, the secure device should only make this request upon a command from the user.  That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data.

But if you're getting the unsigned transaction, that will include the proper inputs. I'm not sure why you'd need all the previous transactions. The idea is that we don't assume anybody is honest. The secure device makes sure we're never doing anything except sending the displayed amount to the displayed address. It's impossible to do anything else with that signed transaction no matter what you feed the secure device.

Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below.  Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.

My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.

I'm probably missing something here. If we know the secure computer or device's public key and encrypt the whole JSON response with that key, what else do we have to worry about? In any case, all information being sent here is in the public block chain anyway so I'm not sure if there's a point encrypting it.

[kjj]

getPublicKeyTransactions -- why do we need that?

The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later.  It would use this request to ask for them.  As an aside, the secure device should only make this request upon a command from the user.  That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data.

But if you're getting the unsigned transaction, that will include the proper inputs. I'm not sure why you'd need all the previous transactions. The idea is that we don't assume anybody is honest. The secure device makes sure we're never doing anything except sending the displayed amount to the displayed address. It's impossible to do anything else with that signed transaction no matter what you feed the secure device.

Your real wallet is in the device.  The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it.  When you want to pay, it sends the destination address and the amount, only.  The device then creates the transaction all by itself, using transaction records it already knows.

Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below.  Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.

My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.

I'm probably missing something here. If we know the secure computer or device's public key and encrypt the whole JSON response with that key, what else do we have to worry about? In any case, all information being sent here is in the public block chain anyway so I'm not sure if there's a point encrypting it.

Encrypting the whole thing would certainly work, but it is probably overkill.  You can't just encrypt the data using the keys themselves, or you provide the attacker with a whole lot of known plaintext to degrade your key with.  Most encrypted streams exchange session keys and do a whole lot of crap behind the scenes, and we would have to do all of that ourselves, all to protect stuff that doesn't really need to be protected.

Simple hashing seems sufficient.  At least for now.  Eventually, sure, we'll probably want the serial communication to be encrypted.  But for the first step, I'd like to be able to debug the thing with a 'scope.

[ben-abuya]

Your real wallet is in the device.  The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it.  When you want to pay, it sends the destination address and the amount, only.  The device then creates the transaction all by itself, using transaction records it already knows.

Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.

[kjj]

Your real wallet is in the device.  The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it.  When you want to pay, it sends the destination address and the amount, only.  The device then creates the transaction all by itself, using transaction records it already knows.

Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.

If the device does all of the wallet stuff itself, you can take it on the road.

I want this thing to be my wallet.  Not a glorified dongle that allows me access to the wallet stored on my PC.

[bfever]

I've been reading this topic with great interest, as I already proposed something similar a few months ago (a smartcard-like device to use as payment in stores instead of a full bitcoin client on some fancy smartphone).

I've been working on this idea and this is what I have in mind:

• a lightweight client (A);
• a smartcard device (B) with display and button(s);
• a GUI software (C).

It can support a variety of configurations like the secure storage of wallet keys (like the discussion in this topic) or paying at your favourite store, just to name two.
Still need to develop a lot (only part A partially done), but because of this discussion, I'll release the "lightweight" client very soon (still working out some final details, then it's ready for first release/test), so that perhaps other people can build on top of that.

Why a lightweight client ?
Everybody talks about "in the future people won't be using a full bitcoin client", and I agree with that: the full client is only useful for people actively supporting the p2p network (mining, big bitcoin user, ...). "Normal" people only need a (very) small part of the blockchain to be able to use bitcoins.
So the client I'm developping will connect to the bitcoin network (at the moment only to one node) to do only 1 thing: download the blockchain, inspect it and store only relevant data. In "private" or "extra-light" mode, it will only store open transactions of a (small) list of bitcoin addresses (=the few user's bitcoin addresses). In "store" or "light" mode, it will story all open transactions (to be used by a store/website that will accept payments in bitcoin, or some power-users wanting to have all relevant data of the blockchain).
It stores this data in a database (I choose MySql) so that any other program/script/web page can easily access this data. In extra-light mode, as only a few transactions need to be stored, a much easier storage (like plain text or CSV format) can be used (so it could be compiled for smartphone platforms more easily).

The GUI software (C) will act as the interface between the smartcard and the client (A): it will manage the smartcard and will send unsigned transactions to the smartcard and signed transaction to the client. (C) could be a small program running on a PC/checkout desk at the local store where a customer can insert his smartcard into a reader to pay for some goods. But it could also be a webpage of an online store.

In a bigger store, the actual implementation could be: 1 server hosts the lightweight client (A) + database and at each checkout software (C) is installed and used to process payments (which will query the database on the server, and send transactions to (A)).

The smartcard (B) is the key part making everything secure: it has a fixed software on it (you can't hack into it and install some other software to read out the RAM containing the private keys) that can generate/load keypairs and sign a transaction sent to it (so it never needs to reveal the private keys when inserted into a unknown PC/terminal).
As said elsewhere, we cannot trust that what we actually see on the display of the checkout terminal/PC is that what is asked to sign, so it will have to have a display and one or more buttons to confirm/cancel the transaction (or loading of new keypairs, ...). This will also prevent abuse of the smartcard when the PC of a local user is infected.

I'll release the link to my website as soon as the lightweight client is ready for testing.

[ben-abuya]

Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.

If the device does all of the wallet stuff itself, you can take it on the road.

I want this thing to be my wallet.  Not a glorified dongle that allows me access to the wallet stored on my PC.

The only reason I can think of that you wouldn't want an untrusted client preparing the unsigned transaction for you is that you don't want to divulge any of your public keys that are holding money. But that means that if you receive money away from your trusted machine, you won't be able to spend that money. I think a combination makes sense. You can download a cache of your current transactions at home. When on the road, if these transactions can cover the bill, you don't need to divulge any public keys. Otherwise you have the choice of divulging public keys to the client to check for new incoming transactions until you can cover the bill.

I'll release the link to my website as soon as the lightweight client is ready for testing.

Looking forward to it

[bfever]

The only reason I can think of that you wouldn't want an untrusted client preparing the unsigned transaction for you is that you don't want to divulge any of your public keys that are holding money. But that means that if you receive money away from your trusted machine, you won't be able to spend that money. I think a combination makes sense. You can download a cache of your current transactions at home. When on the road, if these transactions can cover the bill, you don't need to divulge any public keys. Otherwise you have the choice of divulging public keys to the client to check for new incoming transactions until you can cover the bill.

I don't think this is correct.

• You have the following 4 items: the private key (A), the public key (B), its associated hash (C) and finally the associated bitcoin address (D), which is base58encode( hash (C) + checksum). (D) is only invented so that the hash (C) is human friendly.
• If you know (C), you can calculate (D) and vice-versa. But is it not possible to calculate the public key (B) from (C) or (D).
• Initially to receive coins, you reveal your bitcoin address (D).
• If you send coins to it, a standard transaction is made to (C) (Humans do not really need to read the raw blockchain). Output from it can be claimed if you can sign the transaction.

So up to the point where you only receive coins, you never have to reveal your public key (B).

But if you want to spend any of them, you will have to reveal your public key to everybody. Otherwise is it not possible for anyone to check to see if your signature is correct.
That is why 2 checks are made when you claim a transaction: first the supplied public key is checked that it hashes to (C) (so that you cannot claim the coins using another public key), and afterwards the signature is checked using the supplied public key.

In fact, revealing your public key shouldn't make things more insecure. But it was probably added as an extra security layer: once you have to reveal the public key (=to spend some coins), you can spend all coins of that bitcoin address and send the change to a new bitcoin address with unrevealed public key. To get to your bitcoins, one must first find a public key that hashes to your bitcoin address (quite impossible already) and then use that to find the associated private key (again at the moment quite impossible).

[ben-abuya]

I don't think this is correct.

• You have the following 4 items: the private key (A), the public key (B), its associated hash (C) and finally the associated bitcoin address (D), which is base58encode( hash (C) + checksum). (D) is only invented so that the hash (C) is human friendly.
• If you know (C), you can calculate (D) and vice-versa. But is it not possible to calculate the public key (B) from (C) or (D).
• Initially to receive coins, you reveal your bitcoin address (D).
• If you send coins to it, a standard transaction is made to (C) (Humans do not really need to read the raw blockchain). Output from it can be claimed if you can sign the transaction.

Yeah, those are very good points. The compromised computer can already know that the bitcoin addresses you're sending from belong to the same account and that they belong to you (if the computer has any additional information about you). This could be an issue, and should probably be addressed by any scheme that purports to be secure. The only added amount of data it could glean from you requesting previous transactions for bitcoin addresses is that it could infer that you own bitcoin addresses that you may not end up using in the send transactions.

[marcus_of_augustus]

listening.

[Mike Hearn]

OK. For a lightweight client, check out BitCoinJ which implements this mode already. There's no need to duplicate work.

I've investigated smartcards before. Finding cards that can do ECDSA is difficult. Also, readers that have a display and pinpad can be quite expensive (reusing the ones banks issue isn't as easy as I'd hoped).

Ideally the smartcard reader device is smart enough to do internet connectivity (perhaps tunnelled through the host), because - again - Bitcoin addresses/pubkeys are opaque. You need assurance that the address you see is  owned by the counterparty you think it's owned by. We covered this before. Having a display isn't enough. The display needs to display something human readable. In my proposal, the BitBank provided another service beyond hosting keys: verifying that the public key in question was really owned by some human readable string like a business name or email address. In a pure card based design there's no such external trusted observer. Instead I suppose you could try to re-use the existing SSL PKI and have the reader understand how to verify a signature over a new pubkey using the organizational pubkey embedded into a SSL cert.

I think the right tradeoff is not to have the card sign the transactions (this requires a powerful and expensive card) but rather, have the card hold the keys and release them in the clear to a device that can provide the correct PIN. The device itself then takes an unsigned transaction created by the host, fills out the scriptSigs and hands the signed transaction back.

So there'd be three levels of trust: the untrusted host device knows your balance and can build transactions. The dedicated device signs them. The card holds the keys.

There would need to also be an ability to export an encrypted backup because people probably won't want to store all their value in a card that can easily break, be lost, be stolen, etc.

[ben-abuya]

OK. For a lightweight client, check out BitCoinJ which implements this mode already. There's no need to duplicate work.

Is this regarding the discussion about saving previous relevant transactions on the secure device? If so, it's a good point

As for the hardware design, I'm starting to think this is the wrong place to get into it. People can hack their own MP3 players and do cool DIY projects, but if we're talking about something that's intended for mainstream use I think you'd need to form a real company to get this moving.

Imagine starting a company that implements Gavin's idea. The company doesn't have ownership over your bitcoins, but helps regular people transact securely on a day-to-day basis. This company would bring in hardware engineers, talk to smart card manufacturers, and negotiate bulk pricing for them. To open an account, you'd ask for a couple of devices or smart cards to be sent to you in the mail. Eventually, you'd be able to buy them at Walmart and 7-eleven. Once you have your devices, you put one away in a safe deposit box and forget about it, and use the other one to do secure payments. The company could make a lot of money on a monthly or annual storage fee. Since the company has to know the bitcoin addresses it's securing, it could just look in the block chain to see how much you've got in them, and take a small cut.

It's cool because it's like opening a bank but without the regulatory bs, and you're not really responsible for everybody's money. Advanced users probably won't need the service at all, and the company can sell them the hardware to secure their coins themselves.

[Mike Hearn]

That's a BitBank more or less, and unfortunately I doubt you could avoid being regulated as a money services business because you'd still be a "money transmitter". You probably could avoid being regulated as a fully blown bank though.

Being regulates as a money transmitter means following AML regulations, basically, doing KYC in order to open an account and trying to report "suspicious transactions". There are some other rules in there as well.

[ben-abuya]

That's a BitBank more or less, and unfortunately I doubt you could avoid being regulated as a money services business because you'd still be a "money transmitter". You probably could avoid being regulated as a fully blown bank though.

Being regulates as a money transmitter means following AML regulations, basically, doing KYC in order to open an account and trying to report "suspicious transactions". There are some other rules in there as well.

This is definitely a topic for lawyers, but you don't really have to transmit anything. Customer wants to pay $100 electric bill. His client generates an unsigned transaction and sends to vault service. Vault service partially signs transaction and sends back to client. Client has secure device complete the signature and client broadcasts fully signed transaction to the network. I guess the only thing the regulators could say here is that the service has the ability to block transactions, so it should be required to do so under AML regulations.

Another thing is there's no need to open this kind of service in the US. There's a much smaller degree of trust required than a regular bank, and it might be a lot harder for the US to strong-arm other countries into regulating this. I definitely wouldn't call it anything with the word "Bank" in it. In some countries it's even illegal to call a company a bank if it's not regulated as a bank.

Just as an example, some definitions in the Michigan Money Transmission Services Act:

(b) "Money" means a medium of exchange authorized or adopted by the United States or a foreign government as a part of its currency that is customarily used and accepted as a medium of exchange in the country of issuance. The term includes a monetary unit of account established by an intergovernmental organization or by agreement between 2 or more governments.

Seems not to include bitcoin.

(c) "Money transmission services" means selling or issuing payment instruments or stored value devices or receiving money or monetary value for transmission. The term does not include the provision solely of delivery, online, or telecommunications services or network access.

No selling or issuing of any payment instruments is done by the security service. It's possible you could mangle the meaning of "issuing payment instruments", but see below.

(e) "Payment instrument" means any electronic or written check, draft, money order, travelers check, or other wire, electronic, or written instrument or order for the transmission or payment of money, sold or issued to 1 or more persons, whether or not the instrument is negotiable. The term includes any stored value device or facsimile. The term does not include any credit card voucher, letter of credit, or tangible object redeemable by the issuer in goods or services.

"transmission or payment of money" -- according to (b), bitcoin may not be defined as money, and therefore no payment instruments could ensue.

[BitterTea]

If the device does all of the wallet stuff itself, you can take it on the road.

I want this thing to be my wallet.  Not a glorified dongle that allows me access to the wallet stored on my PC.

If I remember correctly, ArtForz is already working on a secure key storage and signing device. I'll see if I can find a chat log.

Found it: http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/05/05/20#l485685