Topic: Split private keys - page 2. (Read 17309 times)

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.

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.


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.

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.


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.

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.

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.


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.

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.

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.

You always need a second factor. Phone calls can work but I don't think they would be very convenient. Glancing at an attached device and pressing a button only takes a few seconds, assuming you have the device with you.

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.

I agree with this. It's not as fun as trying to defend against root-kits, but probably way more significant for the average user. That said, I still don't get why people are saying you can just have a service without a secure device. Mike, your solution included a device with a screen and a button didn't it? Or are you referring to another solution you posted somewhere else? Gavin's plan called for something you'd get in the mail in case the service went out of business. The only way you can pass on the hardware device is either to trust your computer or to completely trust the online service. To me, completely trusting an online service with all your bitcoins kind of goes against what bitcoin is all about.

I also really like the idea of different kinds of bitcoin addresses. We're going to need this stuff for multi-signing and more advanced scripting.

The out index is a neat idea, but if you aren't a full node (and most users won't run such nodes on their computers in future) it requires you to trust the connected node. That's an assumption Bitcoin tries hard to avoid.

There's no point having an overseer service without layering a naming service on top of Bitcoin. Addresses are opaque, and you probably get them via email, a web page, IM .... ie, via the compromised machine. It's not safe to use raw Bitcoin addresses obtained via an untrusted intermediary. For this reason the overseer must be given a human friendly name and the thing you verify (with secure hardware) must present that name to you, in such a way that the friendly name is always linked to the underlying Bitcoin address in an untouchable manner.

I'd suggest we start by re-examining the patch from genjix to support sending to named addresses. I don't think it's worth worrying about the details of how exactly keys are secured until there's a framework in place to handle address switcharoos.

The particular issue I'm submitting for consideration in this post is the implementation of a new future-proof address type.

Terminology
An overseen transaction is one where the user requires the assent of one or more third parties to complete the transfer of bitcoin.
The third party is termed the overseer. The service they provide is oversight.
Bitcoins sent to the user which require an overseen transaction to spend are overseen coins. The address they are sent to is an overseen address. Note that sending coins to an overseen address does not require an overseen transaction.


Oversight Service
The user signs up to an oversight service with a certain policy and mechanism on approving spends. The oversight service might be implemented as a USB dongle with a display or a web page accessible by a browser or by a call centre accessible by phone.


Overseen Addresses
The user needs to distribute a new overseen address to receive bitcoins and/or to send his existing bitcoins to. The scriptPubKey for transactions sending to an overseen address must require the users signature (like a normal transaction) and the overseer signature.
This is a non-standard transaction which potentially needs to contain two hash160s of information - one for the user's key and one for the overseer's key. It's troublesome to type in such a lot of information and to come up with a new address format for every new type of non-standard transaction.


Out numbers - a new address type
We observe however that it's very easy for the standard client to create a new transaction by copying the scriptPubKey of an existing transaction. So instead of sending to an address like 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa  which contains the hash160 of the credited public key we could send to scriptPubkey 0 as seen in the block chain. I'm going to refer to this as "out 0".

Address 1PSSGeFHDnKNxiEyFrD1wcEaHr9hrQDDWc would be out 170 as it's the coinbase transaction for block 170. The coinbase transaction for block 171 would be out 172 as block block 170 contains the first ever transaction,  sending 10BTC to 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 which is then out 171.

The onus for creating the first non-standard transaction and getting it into the block chain can therefore be shifted onto the oversight service.
When the user signs up, the oversight service creates a non-standard transaction crediting a tiny amount of bitcoin to the overseen address and gets it into the block chain. After a suitable number of confirmations the overseer works out the what position that address has in the block chain and passes that "out-number" (typo-protected, see below) to the user. The bitcoins required for the small transaction could have been transferred by the user to the oversight service on subscription as part of the fee for the service.  


Paying to overseen addresses - or to generic out-numbers
We modify the standard client so that when the user types an out number into the "Pay to:" box, the client looks up the relevant scriptPubKey and fills in the fields accordingly. So if a user types "o170" the client finds out that the scriptPubKey is just a simple transaction to address 1PSSGeFHDnKNxiEyFrD1wcEaHr9hrQDDWc and fills it in. If the user types the out number for an overseen transaction then the client looks up the scriptPubKey and recognizes the transaction type. It redraws the Send Coins window to include a box for the overseer address and it populates the "Pay to:" and "Overseen by:" with the destination address and overseer address respectively.

New schemes involving non-standard transactions will be seen to be useful and will be invented and implemented in future. The above solution is completely future-proof as the client software doesn't even need to understand the scriptPubKey in order to create a transaction sending coins to it. If the standard bitcoin client software and UI is altered to allow transactions to out-numbers then users of that software can send money to overseen addresses even if the bitcoin client does not understand overseen transactions. The client should allow the user to send bitcoins to an out-number for which the client does not understand the scriptPubKey after a suitable warning such as "This version of the bitcoin software cannot inform you how coins sent to this address will be disposed".


Preventing bitcoin transfers going astray with out-numbers
There is an issue with preventing the mistyping of an out-number because it's very likely that adjacent numbers will be valid out-numbers and also many transpositions of adjacent characters will also yield valid out-numbers. I suggest that the hash160 of the scriptPubKey base-52 encoded into "a-zA-Z" be appended to the displayed out-number. A typo-protected out-number would therefore look like "o170XcaYfWuomDEsiFqnaXDVxqHHTxMe". The user would not have to distribute, store or remember all the alphabetic part of the out-number as the client would look up the relevant scriptPubKey, hash it and fill it in. So for the above example "o170X" would provide approximately a 98% chance of typo detection, "o170Xc" would provide approximately a 99.9996% chance of typo detection and "o170XcaYfW" would reduce the chance of an undetected typo to about one in about twenty billion. Anyone distributing their out-number to receive payments could decide how long their protected outnumber was going to be up to a max of the number + about 28 characters.

The exact format of protected out-numbers is thrown open for discussion. There must be no confusion between the current address system and protected out-numbers. Out numbers are "numbers" by analogy with bank account numbers and to avoid commerically embarassing issues whereby inappropriate words are spelled out (cf. the issues with rude words in CAPTCHAs). The alphabetical "check" portion can be engineered to be free of inappropriate words.

Sending overseen coins from an untrustworthy computer
Users subscribed to an oversight service are possibly using rootkitted computers and must be running an oversight-enabled version of bitcoin to spend overseen coins. if all the coins in the users wallet are overseen then when the user presses send, the computer can't send a complete transaction as it does not have access to the overseer's key and can't generate the overseer's signature. (Except by using the "disappearing overseer recovery pack" mentioned by Gavin).

One possibility is that incompletely signed transactions be allowed to propagate across the bitcoin p2p network like a normal transaction. The overseers would see all the incomplete transactions which they could sign to complete and after checking with their policies and/or phoning the users etc they sign the transactions and send the complete transactions out across the network to be included in blocks. In this instance, the behaviour of the incompletely signed transaction is similar to a transaction with a nLockTime in the future.

Another possibility is that the bitcoin client has been informed of the IP address of the oversight service that they are using, so the client sends the incompletely signed transaction direct to the overseer who, after suitable checks, signs it and distributes it or sends it back etc..

In the case that the overseer is a USB key, the incompletely signed transaction is sent to the USB device. It checks the transaction and displays the amount and the address to be credited to the user on its own display so that the user can check them. If the user approves then the USB key signs the transaction and sends the completed transaction back to the computer to send to the bitcoin p2p network. It seems likely that some extra USB-key-specific software needs to be installed on the computer to handle the communication between the bitcoin client and the USB key.


General Considerations
I think the system should not prefer any particular oversight service to any other. Anyone should be able to provide oversight service if they follow the protocol and any user should be able to subscribe to any oversight service.

The system should be able to be extensible to facilitate coins overseen by multiple overseers in which case the system should be able to facilitate situations in which both overseers are required to sign, and situations in which only one is required to sign.

If the overseer is a USB key, care has to be taken so that the bitcoin client does not have to concern itself with the details of transacting with the USB device.

In order to facilitate oversight services, bitcoind should be changed to enable the sending of transactions with explicit custom scriptPubKeys, possibly specified as a hexadecimal string encoding of the scriptPubKey contents.

ByteCoin

RE: cryptocards instead of an online service:

Seems like we aught to be able to come up with a protocol that works over the web or that can talk to http://localhost:SOMEPORT to interact with an attached smart-card device (there'd be helper software running on localhost:SOMEPORT that spoke the protocol and relayed to the smart card).

I wanted to start this discussion to make sure we don't re-invent the wheel, and to think in advance about what changes to core bitcoin (if any) are needed to support this kinds of functionality.

On a related note I found a commercially available smart card that supports the ECC curve bit coin uses and I have ordered samples, it provides a PKCS11 implementation which should be hook able into OpenSSL via it's engine interface. Its not the cards I though I would go with originally but they will work

1st step will be to get crypto to happen on the token, then the idea of getting a on device display for transaction or some other similar solution

http://www.athena-scs.com/product.asp?pid=33

I don't have a great solution for this but maybe just some food for thought:

Key protection is a hard subject that people have been trying to solve for a long time.
There are a ton of solutions that someone might choose based on their comfort and circumstance.
If you guys get hung up on key protection schemes you could make a full time job of implementing them and the core development might suffer. There are a couple of projects out there right now that would be more easily adaptable to cranking out a multitude of different key protection schemes. Bitcoinj comes to mind.

Encryption of the wallet was a huge advance. Solving the key logger issue, etc, seems to be beyond the scope of what you need to solve. Let the OS developers take care of that.

Perhaps instead just add the ability to more easily import transactions generated by other programs.
If you added the option to monitor a folder for txt files and relay transactions contained in it I think you would see a plethora of key protection software develop without having to worry about it becoming the bulk of the bitcoin developers' time.

As an added benefit the relaying installation could have no knowledge of what keys you possessed period, thus having the ability to completely remove key management responsibility from the core client. I can't think of a more secure mode to operate under... assuming the client validated transactions before relaying them.

The point of the BitBank is to hold your keys. Obviously - the whole point is that your computer is actively working against you. So the most it can be trusted to do is relay messages, but you have to assume they might get modified in transit.

Smartcards or ECDSA in hardware aren't necessary in the design I proposed (which would have to be implemented by a BitBank of course). You could use any signing/encryption algorithm.

Hmm.  Think I found my hardware.

Sansa Fuze - $50 on Amazon
ARM9 based system on a chip (similar to the hammer I linked earlier) - up to 250 MHz, with 320K RAM on chip.
8 MB SD RAM
Couple gigs of flash, and microSD socket for backups.
Has a method for unbricking.

I was going to derail the thread by leaping to java's defense until I realized that my previous suggestion is completely impossible to implement in it.

But they don't need the hardware device if they use an online service.  These are competing options, not a decision that must be made once for all users at all times.

Thanks for the link.  I'll check those out.  Hopefully one will be suitable.

I may get stuck with a Java device just for price reasons, but I personally despise Java, so I'm looking for other choices.  This would totally work, but is a bit expensive, and probably FAR more capable than we need.

This is a design discussion, we're trying to evaluate what would work best for the average user, it's not about what I want to use. My question is why would people find this useful if they can get the same functionality from a device they'd need anyway?


Sure: http://forum.bitcoin.org/index.php?topic=17919.msg227691#msg227691


What about the cryptocards like this?

http://www.gemalto.com/products/top_javacard/download/TOP_DL_v2_Sept10.pdf

Not sure it has the exact curve bitcoin uses, but it's getting pretty close.