Topic: Split private keys (Read 17136 times)

This is the part I'm fixating on right now.  I assume this is done by Device 2 in order to obfuscate it's private key from Device 1.  Can someone provide an example of an equation that would do this?

EDIT: Gavin, I also assume you made a typo at the end of your sentence and meant Device 1's private key instead of public key.

You're obviously already beyond my skill level. I'm sorry, but I can't help more.  But I don't believe that this particular idea ever got much traction.

Yes, but my intent is different, so I just wanted to verify this specific part of the equation.  Can Computer A and Computer B generate a shared public key with their respective private keys, without compromising the shared private key?  Is the main security problem only when the shared private key actually needs to be used?

Um, no not quite.  What Gavin was talking about here is a form of two factor authentication, as applied to how the bitcoin system works.  Roughly what is being suggested is that one device is creating the transaction according to what it knows about the spender's wallet.dat file, less the private keys that go with the addresses that contain value; and the second device's job is simply to securely hold the private keys, and sign the transaction with the correct keys when presented with a verifiable transaction and proper authorizasion from a human being.  But the second device does not have access to the transaction inputs in the wallet.dat file, and therefore couldn't create a valid transaction on it's own.

Actually, that's not quite right.  What I've described above is a split wallet.dat system, which can be done now; but what Gavin is suggesting is the development of a new kind of address that, even if the second device is compromised and the private keys stolen, the funds cannot be moved without access to the first device.  Currently, a split wallet.dat system is employed by a couple of light android clients (such as Mycelium) to permit a server to hold the wallet.dat while the actual private keys are kept on the android phone.  When the user, from the android phone, initiates a transaction; the server creates the transaction and then sends it to the device for signing by the user's phone.  This protects the user's funds both from a hacker tricking the server into thinking that they are the user's phone and from similar server ended theft/fraud, but the user's funds are still at risk if the phone is stolen.  'Split addresses' would permit two factor transaction signing, requiring both access to the user's phone, and another of the user's devices; so that the attacker would require both devices to agree.  This may not be useful for most people, since if someone is mugged of their phone they are likely mugged of any devices that they possess at the time.  But the second device could be as simple as a bluetooth only device that must be within range of the cell phone, with a keypad to enter a code upon POS.  Or it could be the user's home pc, that can be set to remain open (within limits, say a max BTC per day rule) for a full day or week, so that if the user's phone is stolen, the amount at risk is limited to what can be taken before the home PC client can be stopped.  Either device could be backed up as well.

Bringing this back from the dead for something slightly related I am brain-storming.  If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key.  The security problem arises when one needs to actually utilize the private key, correct?

Sounds like he and I came to the same conclusions, he just beat me by a month or two.

I really need to start hanging out on IRC.

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

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:


Seems not to include bitcoin.


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.


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

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.

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.

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.

listening.

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.

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

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.


Looking forward to it

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.

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.

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.

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.


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.

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.


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.