Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices

[someone42]

Edit: Please see https://bitcointalk.org/index.php?topic=78614.msg1327630#msg1327630 for an updated prototype.

Hardware Bitcoin wallet is a project which aims to implement a minimal dedicated Bitcoin wallet. Its main difference with every other Bitcoin client/wallet out there is its low resource requirements: the binary is currently 25 kilobytes large, it uses less than 2 kilobytes of RAM and requires only 160 bytes of non-volatile storage per wallet. With such low requirements, I reckon a production device would be smaller, more robust and cheaper than any other Bitcoin wallet.

The wallet stores private keys (actually, it only stores a seed for the deterministic key generator), parses transactions and signs transactions. It essentially doesn't do anything else. This is by design - simpler means a smaller attack surface. Private keys are generated on the device and never leave the device, except when doing a wallet backup. Even then, the seed is only displayed - it is never sent over the serial port. My intention is that physical access to a device is required in order to obtain private keys or to spend anything. As an additional layer of security, wallets can be encrypted. An encrypted wallet offers pseudo-two-factor authentication: in order to spend BTC, you need to know the wallet passphrase and you need to have the hardware Bitcoin wallet.

Here's a somewhat messy prototype:

The thing on the left is an Arduino clone (though I'm not actually using the Arduino IDE or libraries). The bunch of discretes on the lower part of the breadboard comprise a noise source, which is used to generate random numbers. The input user interface consists of two pushbuttons (bottom-left and bottom-right corners), where the user can approve or disapprove of actions. This gives you an idea of the necessary hardware peripherals required. Of course, a production device would be much more compact than this .


Here's the prototype signing a transaction:

Here's an actual transaction that it signed: http://blockexplorer.com/t/AEhoN6bzjd.

The code is hosted at: https://github.com/someone42/hardware-bitcoin-wallet. Currently, there's only a port for the ATmega328 microcontroller. However, most of the code is platform-independent; porting to another microcontroller "only" involves writing drivers for the microcontroller's peripherals.

I shall commit to being open and transparent, releasing source code and hardware specifications as I produce them. If people are interested, I might even design a production hardware Bitcoin wallet. From simple BOM and assembly cost estimates, such a device would cost 6 to 7 USD per unit to manufacture (for a quantity of 1000). If anyone has questions/suggestions, feel free to ask in this thread.

[1714159718]

1714159718

[1714159718]

1714159718

[1714159718]

1714159718

[1714159718]

1714159718

[1714159718]

1714159718

[John (John K.)]

Seems really nice!  Any way of doing a backup of the private keys as the hardware might be lost/damaged?

[da2ce7]

Seems really nice!  Any way of doing a backup of the private keys as the hardware might be lost/damaged?

yes you can display the seed.  so you could regenerate them on another system

[jim618]

Looks very nice !

What is the format of the data on the serial line for:
1) payment request
2) signed transaction

What data rate/ parity etc are you using on your IO ?

Basically: what does a piece of software have to do to interface with your device ?

[cbeast]

Bitcoin apparatus should all be wearable. Next we need human powered wearable asic running mining shoes made by Asics.

[Red Emerald]

Cool project!

[Xenland]

Nice!

[someone42]

yes you can display the seed.  so you could regenerate them on another system

Yeah, well you can in principle...though in practice wallet backups/restores aren't implemented yet. I shall implement this soon.

What is the format of the data on the serial line for:
1) payment request
2) signed transaction

What data rate/ parity etc are you using on your IO ?

Basically: what does a piece of software have to do to interface with your device ?

Serial parameters are: baud rate 57600, 8 data bits, no parity, 1 stop bit. The host and wallet exchange "packets", which are type-length-value triplets. For all the packet types, see: https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL. It's almost the simplest protocol I could think of that is still somewhat extensible.

[jim618]

Hi someone42,

Looks nice and extensible.

I had a couple of comments on your protocol:
+ You do not specify the character encodings you are using. For the bitcoin addresses and public keys ASCII will be fine but for the wallet names I would use UTF8 to make it internationalisable (depends if you can display it I guess)
+ You have some powerful commands (format, change encryption key) that an attacker can use with no constraints on their use. For instance, a point of sale device that you only want to send sign requests can format your device. Or they can change the encryption password and hold your BTC to ransom.  Perhaps you need a 'hardware protect' physical switch to stop this - maybe you have this already.

Nice to be able to get the addresses out, exactly what is required for a watch only wallet.

[RodeoX]

Ima watch this! Cool idea.

[EhVedadoOAnonimato]

Quite cool, congratulations!

Even then, the seed is only displayed - it is never sent over the serial port.

Isn't this overkill? I mean, writing an encrypted copy of the seed on a USB key doesn't sound dangerous. And it's much easier and less error prone for the user than manually copying it from what's displayed.


I guess that it would increase complexity, but do you think it's feasible to implement "hidden volumes" like Truecrypt does, in order to have plausible deniability against this kind of attack (works as long as the attacker doesn't know for sure how much you've got)?

[EhVedadoOAnonimato]

+ You have some powerful commands (format, change encryption key) that an attacker can use with no constraints on their use. For instance, a point of sale device that you only want to send sign requests can format your device. Or they can change the encryption password and hold your BTC to ransom.  Perhaps you need a 'hardware protect' physical switch to stop this - maybe you have this already.

You're right that these are "powerful commands" and at least some sort of confirmation would be welcome. But I'm not sure this is the kind of device you want to take to a point of sale. There are two different use cases, that do not need to be accomplished by the same thing:

• Safely store your bitcoins.
• Easily spend them.

A dedicated air gapped device like this is a good candidate for the first use case, due to its high security.
For the second use case, easy of use and practical features are probably more important than security. A smartphone app with nice features, that communicates well with point of sales etc, is the perfect candidate for it, even if it's on a generic device which is more vulnerable to malware. You just don't load it with any amount of money you cannot afford to lose, pretty much like you do with cash in your physical wallet - you don't walk around with your entire salary in your pocket, do you?

Not saying that the same device can't potentially accomplish both functions. But it would need a lot of features (air gapped, unaccessible private keys, encrypted backups, plausible deniability, wireless communication, QR-scan, good display etc etc). Maybe it's easier to focus on only one use case at a time...

[jim618]

Good points - better to concentrate on the primary use case : air gapped bitcoin storage.

[anu]

How do you get on to the network?

[ThomasV]

cool! we should work together

[PawShaker]

I am hardware-phobic but very impressed. Do you wantto makethis device tamper proof? Like erase memory when you detect that someone is trying to open the case?

[jim618]

How do you get on to the network?

If I understand his protocol class correctly, somebody42's device talks via serial to another piece of software.

That software can ask it to generate keys, ask for the bitcoin addresses for the keys and give it transactions to sign. The other software would know about the blockchain, transmit the tx to the bitcoin network and monitor balances.

The hardware device is primarily a key store and can sign tx it is given if the owner presses the button to agree.

[EhVedadoOAnonimato]

That software can ask it to generate keys, ask for the bitcoin addresses for the keys and give it transactions to sign. The other software would know about the blockchain, transmit the tx to the bitcoin network and monitor balances.

The hardware device is primarily a key store and can sign tx it is given if the owner presses the button to agree.

That just makes me realize that an advanced malware could still steal from you by replacing every bitcoin address or QR-code your browser tries to display by an address in control of the attacker.

Damn. I just can't think of a way to protect against that.

The only partial defense against such a thing is to never use potentially compromised devices to make large amount transfers (like buying a car or moving your whole savings around). If you're transferring big amounts, make sure both ends - that which sings the transaction and that which provides the output addresses - are safe. Preferably air gapped safe.
But you're still vulnerable on daily purchases.

[jim618]

@EhVedadoOAnonimato - it is a bit off-topic but ThomasV has been thinking about how bitcoin URIs can be signed to prevent atackers replacing the addresses and come up with a couple of proposals.  I don't think it is trivial to solve though.

[EhVedadoOAnonimato]

That would require the device to recognize the signature. A standard like what's done for HTTPS could be created, with the device trusting a priori a set of CA root certificates, and people signing their URI's with a signed cert. But this set of root certs would need to evolve once in a while. The only way to "safely" update such set of trusted CA is by signing the update with a manufacturer's private key, which the device always trust. That only works as long as the manufacturer doesn't lose control to this key.

Difficult to implement, with some level of danger still, but yeah, a possibility, and certainly much better than nothing.
I don't know whether merchants would like to adhere to this protocol though. It would probably make their life easier if the same certificate they use for HTTPS could be used for this, at least they don't have to pay two different CA's.

[someone42]

Isn't this overkill? I mean, writing an encrypted copy of the seed on a USB key doesn't sound dangerous. And it's much easier and less error prone for the user than manually copying it from what's displayed.

Writing to a USB key would require the wallet be capable of being a USB host, as opposed to merely being a USB device. Being a USB host requires far more processing resources than being a USB device. IMO, it just isn't worth the extra complexity and cost. An easier alternative to manually writing down the seed would be to take pictures of the display.

I guess that it would increase complexity, but do you think it's feasible to implement "hidden volumes" like Truecrypt does, in order to have plausible deniability against this kind of attack (works as long as the attacker doesn't know for sure how much you've got)?

Hidden wallets are a feature I plan to add. I intentionally made the "format storage" command write random data everywhere (instead of all 00s) for this reason.

I had a couple of comments on your protocol:
+ You do not specify the character encodings you are using. For the bitcoin addresses and public keys ASCII will be fine but for the wallet names I would use UTF8 to make it internationalisable (depends if you can display it I guess)

Good point. Currently, the wallet doesn't ever display or parse the wallet name (the wallet name is just there for the convenience of the host), so adding this feature requires no additional code.

+ You have some powerful commands (format, change encryption key) that an attacker can use with no constraints on their use. For instance, a point of sale device that you only want to send sign requests can format your device. Or they can change the encryption password and hold your BTC to ransom.  Perhaps you need a 'hardware protect' physical switch to stop this - maybe you have this already.

Just like with transaction signing, all powerful commands require approval from the user. I haven't done this with the "change encryption key" command yet because I'm still figuring out how to deal with ransom attacks.

One major problem I've identified with the hardware Bitcoin wallet is that since its input user interface consists solely of two pushbuttons, there's no way to get a wallet password into it. Currently, the host is supposed to provide an encryption key derived from a password, and this is bad because:
1. The user must type the password using the host's keyboard and the host may have a keylogger.
2. The host may have an advanced trojan which covertly mixes a "ransom key" into the encryption key, lets you load BTC into a wallet, then holds those BTC for ransom.

How can these flaws be dealt with? Here are the ideas I've come up with:

• Keep things the way they are. Rely on the assumption that even if an attacker has your wallet password, they probably won't have physical access to your hardware Bitcoin wallet, so they still can't do anything nasty. Rely on wallet backups to mitigate ransom attacks.
• Change the protocol so that the wallet password is sent in cleartext over the serial port. Then, the wallet has the opportunity (when setting or changing the wallet password) to display the password, allowing the user to detect if a "ransom key" has been inserted.
• Add a USB port to the hardware Bitcoin wallet and allow the user to plug a USB keyboard into the wallet and directly enter the wallet password.

I like the last option the most, but it does involve additional cost (+0.20 to 0.40 USD for quantity = 1000) and complexity*. Also, since the key derivation function is evaluated on the hardware Bitcoin wallet, it can't be as strong, since the microcontroller on the device will be orders of magnitude less powerful than a modern CPU or GPU.

Can anyone think of a better way to deal with ransom attacks?

I am hardware-phobic but very impressed. Do you wantto makethis device tamper proof? Like erase memory when you detect that someone is trying to open the case?

It would be nice to have tamper proof features and there are microcontrollers out there which have such features. But the semiconductor manufacturers all seem to require the signing of an NDA (that goes against my goal of openness) and probably won't bother talking to me unless I commit to an order of at least 10,000 units. I figure it's not such a big deal: Bitcoins are transferrable. If your wallet is compromised or stolen, you create a new one and use a wallet backup to transfer everything to the new wallet.

That would require the device to recognize the signature. A standard like what's done for HTTPS could be created, with the device trusting a priori a set of CA root certificates, and people signing their URI's with a signed cert. But this set of root certs would need to evolve once in a while. The only way to "safely" update such set of trusted CA is by signing the update with a manufacturer's private key, which the device always trust. That only works as long as the manufacturer doesn't lose control to this key.

Difficult to implement, with some level of danger still, but yeah, a possibility, and certainly much better than nothing.
I don't know whether merchants would like to adhere to this protocol though. It would probably make their life easier if the same certificate they use for HTTPS could be used for this, at least they don't have to pay two different CA's.

It may be possible to verify signed Bitcoin addresses on a hardware Bitcoin wallet, as long as the signatures are generated using ECDSA (and preferably using the curve secp256k1). Most of the code needed to verify a signature is already implemented, because signature verification is similar to signature generation. Also, ECDSA public keys are only 64 bytes each, so there will probably be enough spare space to fit a couple in a firmware binary. Nevertheless, I don't think I'll implement this feature in the near future.

*There's a bit of a cheat I can use here. As I mentioned above, being a USB host is difficult. But most (maybe all?) USB keyboards are also PS/2 keyboards: those USB-to-PS/2 dongles they come with simply re-route the USB pins to PS/2 pins. The keyboard uses some electrical checks to determine whether it is plugged into an actual USB port or a USB-to-PS/2 dongle. Thus it's possible to trick a USB keyboard into using the PS/2 interface, and the PS/2 interface is much easier to work with than the USB interface.

[marcus_of_augustus]

Interesting.

How small are you thinking a final version maybe? As small as a USB stick with 2-line display?

I think for btc savings (large amounts) having just a small, network-isolated, piece of hardware that does nothing else but store keys and sign transactions is a very promising concept.

[Xenland]

Interesting.

How small are you thinking a final version maybe? As small as a USB stick with 2-line display?

I think for btc savings (large amounts) having just a small, network-isolated, piece of hardware that does nothing else but store keys and sign transactions is a very promising concept.

Sounds like iron key needs to be Contacted

[EhVedadoOAnonimato]

How can these flaws be dealt with? Here are the ideas I've come up with:

• Keep things the way they are. Rely on the assumption that even if an attacker has your wallet password, they probably won't have physical access to your hardware Bitcoin wallet, so they still can't do anything nasty. Rely on wallet backups to mitigate ransom attacks.
• Change the protocol so that the wallet password is sent in cleartext over the serial port. Then, the wallet has the opportunity (when setting or changing the wallet password) to display the password, allowing the user to detect if a "ransom key" has been inserted.
• Add a USB port to the hardware Bitcoin wallet and allow the user to plug a USB keyboard into the wallet and directly enter the wallet password.

I like the last option the most, but it does involve additional cost (+0.20 to 0.40 USD for quantity = 1000) and complexity*. Also, since the key derivation function is evaluated on the hardware Bitcoin wallet, it can't be as strong, since the microcontroller on the device will be orders of magnitude less powerful than a modern CPU or GPU.

Can anyone think of a better way to deal with ransom attacks?

*There's a bit of a cheat I can use here. As I mentioned above, being a USB host is difficult. But most (maybe all?) USB keyboards are also PS/2 keyboards: those USB-to-PS/2 dongles they come with simply re-route the USB pins to PS/2 pins. The keyboard uses some electrical checks to determine whether it is plugged into an actual USB port or a USB-to-PS/2 dongle. Thus it's possible to trick a USB keyboard into using the PS/2 interface, and the PS/2 interface is much easier to work with than the USB interface.

Seriously, 0,40USD is nothing. Even if it ads more than 1USD per unit, it's still nothing. Just use USB, it's the current standard, people wouldn't need adapters, you could use the same USB port to connect to the device that will provide the transactions to be signed, and maybe one day you could make it capable of writing the encrypted seed out for backup purposes.

I agree that keeping low cost is important to boost adoption, but don't get too radical on that. Usability is also an important criterion. This device would mostly be used by those which have a sensible amount of BTCs to protect anyway, so I believe they can afford a few dollars more for a decent thing. Those who don't have much coins, don't have much too lose in using desktop wallets anyway.

[jim618]

@someone42
You should give your device and protocol a name.

That way client software can advertise itself as supporting 'YourName' devices.
Also people can then clone your hardware and advertise their devices as 'YourName' compatible.

[jim618]

These combined USB drives with LCD make for an interesting form factor:


No buttons though.

Edit: link http://www.usbflash.co.uk/usb-flash-drives/plastic-usb-drives/flash-drive-lcd.html

One of the things on our 'possible' things to do with MultiBit is to make a MultiBitPortable where the wallet and software are all on a USB device. With a combination hardware wallet + USB drive you could :

+ plug in your USB drive / hardware wallet combo and start up your client software, the executable for which is on the USB drive.
+ when it needs to do a spend, it talks via serial/USB to the hardware device to get you to approve it with a button press on the device and the hardware device signs it.
+ client software then transmits the tx.

Both Electrum and MultiBit can run from small USB drives quite happily.

Just exploring the possibilities.

[EhVedadoOAnonimato]

It seems you forgot to add a link, jim...

[MatthewLM]

I'm looking through the code. I guess the ECDSA and bignum algorithms were implemented more or less from scratch? I might use some of you algorithms for the C library I'm making. I was looking at other libraries including OpenSSL which is what the C++ client uses but none easily allow me to include only the specific parts I need into my library.

I found this:

Code:

  * All computation functions have been written in a way so that their
  * execution time is independent of the data they are processing. However,
  * the compiler may use optimisations which destroy this property; inspection
  * of the generated assembly code is the only way to check. The advantage of
  * data-independent timing is that implementations of cryptography based on
  * this code should be more timing attack resistant. The main disadvantage is
  * that the code is relatively inefficient.

Does this matter for the purposes of this device? And what about using bitcoin on a PC?

For a time-based attack an attacker would need to determine the start and end times of an operation. For signing transactions on a PC I don't see how time information could leak out to an attacker. From what I can tell the attacker would need some sort of access to the computer itself, in which case wallets are vulnerable anyway. So would the algorithms need to be secured against this type of attack when using bitcoin?

Perhaps using a random sleep period when signing transactions would protect against the attack and may allow for better optimisation. I found this but it isn't too keen on the random time delays: http://www.cryptography.com/public/pdf/TimingAttacks.pdf The blind signature technique wouldn't be applicable (unless I don't know something). Does anyone have any thoughts on this?

[whiskers75]

Nice idea!
To solve the password dilemma,
Why not use the LCD as the password display and
Ask the user to type the password BACKWARDS...

[pc]

Definitely an interesting concept.

But before using any sort of embedded device to generate keys, I'd want some confidence in its random number generator. (I haven't looked at the hardware or code, and I don't have the expertise to evaluate its randomness even if I did.) But the research using EFF SSL data that indicates a lot of SSL certificates in the wild use bad random number generators, probably generated on embedded devices, makes me really hesitant to use an embedded device to generate my bitcoin keys without a lot of scrutiny.

[Peter Todd]

For a time-based attack an attacker would need to determine the start and end times of an operation. For signing transactions on a PC I don't see how time information could leak out to an attacker. From what I can tell the attacker would need some sort of access to the computer itself, in which case wallets are vulnerable anyway. So would the algorithms need to be secured against this type of attack when using bitcoin?

Perhaps using a random sleep period when signing transactions would protect against the attack and may allow for better optimisation. I found this but it isn't too keen on the random time delays: http://www.cryptography.com/public/pdf/TimingAttacks.pdf The blind signature technique wouldn't be applicable (unless I don't know something). Does anyone have any thoughts on this?

The problem with random sleep periods is that you can still determine the underlying time taken through simple statistical averaging in many circumstances. Possible a better solution would be to start a timer at the beginning of any cryptographic operation, and then once the operation finishes wait until a fixed maximum-time has elapsed. That way every operation takes the same amount of time. Adding a further random delay on top of this fixed delay wouldn't be a bad idea either, to help mask any residual leakage. (for instance, suppose that the time measurement turns out to be flawed, and there is still a remainder which it does not detect)

If the attacker can also determine what the power consumption of your hardware wallet you have to hide that as well. Unfortunately in the case of a USB-powered wallet this is actually a realistic attack as some motherboards can measure how much power a USB device is actually consuming. To protect against this, the "makeup" time period should do something cpu-intensive as well, perhaps an additional, randomly chosen, cryptographic operation. (don't pick the same operation, with the same keys, in case there turns out to be a key-dependent power consumption)

Finally, at the hardware level you can choose a power supply with a fixed current consumption on the input. A zener diode and resistor voltage regulator, operated correctly, has a nearly zero change in input current for a change in output current and you can do even better with something more sophisticated.

For the OP: I'm an electronics designer and I'd be interested in working further on the hardware design.

[MatthewLM]

Thanks retep. I was thinking the same thing: Instead of a random delay, you could profile the algorithms to estimate the longest time and add a delay up until this time each time the algorithms are run. An additional random delay would be good also. As for the power problem, wouldn't it be best to focus on the hardware to mask this? With the algorithms there may be detectable power variations for the actual different operations computed right?

[EhVedadoOAnonimato]

But before using any sort of embedded device to generate keys, I'd want some confidence in its random number generator.

Good point to remember.
As suggested here, the device could have an embedded AM antenna and use the background noise as entropy source.

[Peter Todd]

Thanks retep. I was thinking the same thing: Instead of a random delay, you could profile the algorithms to estimate the longest time and add a delay up until this time each time the algorithms are run. An additional random delay would be good also. As for the power problem, wouldn't it be best to focus on the hardware to mask this? With the algorithms there may be detectable power variations for the actual different operations computed right?

It depends on who the attacker is. If you assume they have access to your computer, as is the case with a virus, you're job is a lot easier and hardware or software solutions to keep the power draw constant are fine. However, if you are trying to defeat an attacker who has the actual device, then a hardware solution is trivial to attack by just taking the device apart. At that point though, there are a *lot* of possible attacks which this design can't prevent anyway.

I'd argue for fixing the problem in software first, and then once you've done that, determine if a cheap hardware fix is possible too. Having said that, a USB powered device with this fix is pretty easy to make as USB provides +5V and most uC's will run on 3.3V. If one of the easy-to-use FTDI FT-X chips is used for the uC<->USB communication we have no issue as well, as those chips have 3.3V-tolerant IO. The only issue left is the LCD screen, most of them run off of 5V. Still, simple level translation isn't hard and won't add much cost.

BTW, for the non-electrical engineers out there, this is how the zener-regulator works, and why it makes the current constant:



Vs represents the 5V supplied by the computer over USB, and R2 representing your uC. DZ is the zener. In operation, the effective value of R2 changes as the uC draws different amounts of current. At what extreme, R2 might be nearly infinite if the uC is in sleep mode, at the other extreme, the most current the uC can draw will look like an R2 of a few dozen ohms. What we want is for the current being drawn out of Vs to be fixed, regardless of the value of R2.

The zener diode has a property called breakdown where if the voltage applied to it in the reverse direction increases over a certain threshhold, it starts conducting current exponentially. Suppose we pick a 3.3V zener, and R2 is an open circuit. (the uC is off) If the zener is not conducting any current, the voltage across it will rise, and as the voltage reaches 3.3V, it will start conducting current again. This means we can pick the value of R1 assuming a given amount of current flows through it. Lets assume 30mA: R1=(Vs-Vz)/I=(5V-3.3V)/30mA=73Ohms. Now the zener is happily allowing 30mA of current to flow through it, which causes 30mA of current to flow through R1, and there is a voltage drop across R1 of 2.2V, just enough that 3.3V is across the zener.

Now lets suppose the uC starts doing a cryptographic operation. It's now consuming 20mA of current computing a bitcoin transaction. If the zener continues to draw 30mA of current, the total would be 50mA, and the voltage drop across R1 would be (20mA+50mA)*73Ohms=3.65V. However, 5V-3.65V=1.35Volts, way less than the 3.3V breakdown of the zener. Instead what happens is as the uC draws more current, the zener draws less, so the total current between the two stays the same. Now we have the zener drawing 10mA and the uC drawing 20mA.

An external observer, such as a wallet-stealing virus that can ask the computer for how much power the USB port is drawing, now has no idea how much power the uC is drawing no matter what it's doing. The disadvantage of course being that the power consumed is constant, even when the wallet isn't doing anything. Still, 150mW isn't a lot of power.


Of course, the above example is a bit hand-wavey, what actually happens is more subtle. A zener's current-to-voltage relationship is actually an exponential relationship, in the form I=k(V-Vth)^n with k and n being device-specific coefficients. Effectively, the total current drawn is *not* actually constant, it's just that the change in current draw is small.

Lets assume that the computer we're using has the ability to measure the current draw on an individual USB port with a precision (not accuracy!) of 0.1%, and the range of that measurement is one standard USB load, 100mA. 100mA * 0.1%=0.1mA, so if we keep our *change* in current draw to less than half of that, we can guarantee that there will be no detectable change in the current measured. We'll assume that uC draws 25mA fully on, or a change in uC current from off to on of 25mA. In the small signal model a zener looks like a resistor, so our circuit is now:



R1 is the 73Ohms we calculated earlier, and Rz is the impedance of the zener. (also known as the zener differential resistance) Our load now looks like a current source, and the input voltage disappears. What we want is for IR1 to be less than 0.05mA for I=25mA. So, I=IR1+IRz -> I=IR1+V/Rz Now what's V? Simply I*(R1*Rz)/(R1+Rz), so I=IR1+I(R1*Rz)/((R1+Rz)Rz) -> Rz=I*R1/(I-IR1) - R1=0.146Ohms

See, that's the catch, seemingly OK zeners can't meet this spec. For instance all of the BZX84 series zeners have maximum impedance of greater than 10Ohms, even if they look OK otherwise. Unfortunately, it looks like zeners that meet our requirements don't actually exist; the minimum zener impedance on digikey for a 3.3V zener is 3Ohms, and that spec only applies if you are drawing 380mA.

So lets go back to a software/hardware solution. Suppose we can get the change in current down to 0.25mA by clever software that carefully uses the same amount of power no matter what the cryptographic engine is doing. The above equation now gives us 18Ohms at the maximum, and as it turns out the $0.20 225mW MMBZ5226BLT1G is almost suitable at 28Ohms. (measured at 20mA) Solving for IR1 we get 0.18mA maximum, IE, this is the maximum change in current allowed before the host could detect it. So go work on the software some more!

Now what happens if the zener fails? Specifically, suppose the zener's impedance rises, such that the change in current through R1 increases. The only way we would know is if the voltage across R1 increases, so basically the uC now has to monitor the change in it's own voltage supply as it begins a cryptographic operation. That change would be equal to V=I(R1*Rz)/(R1+Rz)=3.4mV, tiny! Fortunately 10bit ADC's are quite common, so 3.3V/1024=3.22mV - we probably can't detect a subtle failure, but anything major is detectable. Such a design doesn't even have to be all that expensive if you use the other side of the R1 resistor as your Vref, which is OK because we only care about the difference between the too. Total implementation would be 4 0.1% resistors, $0.20 in volume.


Ugly 'eh? What looked so simple, just isn't. I gotta admit, I wasn't expecting a combined hardware/software implementation to be mandatory myself.

[Peter Todd]

Good point to remember.
As suggested here, the device could have an embedded AM antenna and use the background noise as entropy source.

Regardless of how you collect your random data you should be also saving the state of the random number generator so you can restore it on the next power up. Currently the getRandom256() function collects new random bytes from the hardware generator, hashes them with sha256, and then returns that result. It really needs to operate with a persistent entropy pool to protect against a HWRNG failure. FWIW I just created an un-tested patch that implements this. See https://github.com/retep/hardware-bitcoin-wallet/compare/persistent-pool-prng

[EhVedadoOAnonimato]

Wow, sorry but you're talking Greek to me, retep.
What's the point in storing previously used random numbers? What's a HWRNG failure? I suppose the acronym means HardWare Random Number Generator, but still don't understand what you mean.

[someone42]

How small are you thinking a final version maybe? As small as a USB stick with 2-line display?

I won't really know until I choose a display and layout a PCB, but I estimate a final version will have a size of about 1.5x the length/width/height of a typical USB stick.

I'm looking through the code. I guess the ECDSA and bignum algorithms were implemented more or less from scratch? I might use some of you algorithms for the C library I'm making. I was looking at other libraries including OpenSSL which is what the C++ client uses but none easily allow me to include only the specific parts I need into my library.

If you do choose to use the code, keep in mind that:

• bigMultiplyVariableSizeNoModulo() is horribly slow. If you are going to hand-optimise or reimplement one function, choose this.
• The "constant execution time" property of the algorithms may not carry over to a contemporary CPU because of caches and branch prediction. I don't have to worry about caching/branch prediction because none of the microcontrollers I'm looking at have these features.

The problem with random sleep periods is that you can still determine the underlying time taken through simple statistical averaging in many circumstances. Possible a better solution would be to start a timer at the beginning of any cryptographic operation, and then once the operation finishes wait until a fixed maximum-time has elapsed. That way every operation takes the same amount of time. Adding a further random delay on top of this fixed delay wouldn't be a bad idea either, to help mask any residual leakage. (for instance, suppose that the time measurement turns out to be flawed, and there is still a remainder which it does not detect)

If the attacker can also determine what the power consumption of your hardware wallet you have to hide that as well. Unfortunately in the case of a USB-powered wallet this is actually a realistic attack as some motherboards can measure how much power a USB device is actually consuming. To protect against this, the "makeup" time period should do something cpu-intensive as well, perhaps an additional, randomly chosen, cryptographic operation. (don't pick the same operation, with the same keys, in case there turns out to be a key-dependent power consumption)

Finally, at the hardware level you can choose a power supply with a fixed current consumption on the input. A zener diode and resistor voltage regulator, operated correctly, has a nearly zero change in input current for a change in output current and you can do even better with something more sophisticated.

For the OP: I'm an electronics designer and I'd be interested in working further on the hardware design.

The way my current implementation achieves constant time operation is to insert dummy operations instead of using branches. I believe this is like the "wait until maximum-time, while doing something cpu-intensive" approach, except that the waiting is interleaved instead of happening all at the end. However, it has the advantage that program flow is independent of secret data, so it also hides most (but not all) of the power consumption signature.

I had previously assumed that power analysis using a computer motherboard wouldn't be feasible for a hardware Bitcoin wallet. I assumed this because usually fast ADCs (at least the clock rate of the microcontroller) are required to do power analysis, and I doubt motherboards have 48 Msps ADCs in them. However, your comments have prompted me to question this. A point multiplication operation involves 256 point addition and point doubling operations which take place over some time (0.5 s to 4 s depending on the speed/power of the microcontroller). Sampling over each point addition/doubling would only require a < 1 ksps ADC and could possibly reveal information about secret data. Although I still think a power analysis virus is a bit exotic, it would be prudent to design some power analysis countermeasures into a hardware Bitcoin wallet.

About the hardware design: yes, I'd really appreciate help. Software mistakes can be fixed with a commit; hardware mistakes can require expensive redesign or rework.

See, that's the catch, seemingly OK zeners can't meet this spec. For instance all of the BZX84 series zeners have maximum impedance of greater than 10Ohms, even if they look OK otherwise. Unfortunately, it looks like zeners that meet our requirements don't actually exist; the minimum zener impedance on digikey for a 3.3V zener is 3Ohms, and that spec only applies if you are drawing 380mA.

So lets go back to a software/hardware solution. Suppose we can get the change in current down to 0.25mA by clever software that carefully uses the same amount of power no matter what the cryptographic engine is doing. The above equation now gives us 18Ohms at the maximum, and as it turns out the $0.20 225mW MMBZ5226BLT1G is almost suitable at 28Ohms. (measured at 20mA) Solving for IR1 we get 0.18mA maximum, IE, this is the maximum change in current allowed before the host could detect it. So go work on the software some more!

Now what happens if the zener fails? Specifically, suppose the zener's impedance rises, such that the change in current through R1 increases. The only way we would know is if the voltage across R1 increases, so basically the uC now has to monitor the change in it's own voltage supply as it begins a cryptographic operation. That change would be equal to V=I(R1*Rz)/(R1+Rz)=3.4mV, tiny! Fortunately 10bit ADC's are quite common, so 3.3V/1024=3.22mV - we probably can't detect a subtle failure, but anything major is detectable. Such a design doesn't even have to be all that expensive if you use the other side of the R1 resistor as your Vref, which is OK because we only care about the difference between the too. Total implementation would be 4 0.1% resistors, $0.20 in volume.


Ugly 'eh? What looked so simple, just isn't. I gotta admit, I wasn't expecting a combined hardware/software implementation to be mandatory myself.

Yeah, using simulation of a simple zener regulator circuit, I couldn't get better than a factor of ~3 reduction in power consumption signature.

I think a mostly software solution is possible. A relatively large (compared to what's possible on a smartcard) amount of passive filtering can be used to mask high-frequency power consumption signatures (with a cutoff in the 10s of kHz).

Say, for example, an addition: x + y requires i + d_i milliamp of current over one clock cycle, but the addition of ~x + ~y requires i - d_i milliamp of current over one clock cycle. As long as every necessary addition x + y is paired with a dummy addition ~x + ~y, total current consumption is always i milliamp of current over two clock cycles. Since the core clock of microcontrollers is in the Mhz range, the cycle-to-cycle variations in power consumption are not visible to an attacker; thanks to the filtering, only power consumption over hundreds of cycles is visible. The challenge is then to "pair" every necessary operation with a dummy operation that quickly compensates for the power comsumption of the necessary operation.

Seriously, 0,40USD is nothing. Even if it ads more than 1USD per unit, it's still nothing. Just use USB, it's the current standard, people wouldn't need adapters, you could use the same USB port to connect to the device that will provide the transactions to be signed, and maybe one day you could make it capable of writing the encrypted seed out for backup purposes.

After seeing this: https://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html, I believe it is possible to bit-bang a USB host interface. So I will probably include a USB port on the wallet, for you to plug a USB keyboard into.

[someone42]

Regardless of how you collect your random data you should be also saving the state of the random number generator so you can restore it on the next power up. Currently the getRandom256() function collects new random bytes from the hardware generator, hashes them with sha256, and then returns that result. It really needs to operate with a persistent entropy pool to protect against a HWRNG failure. FWIW I just created an un-tested patch that implements this. See https://github.com/retep/hardware-bitcoin-wallet/compare/persistent-pool-prng

If I understand your patch correctly, you are adding a persistent (across power cycles) entropy pool so that in the event of an undetected HWRNG failure, getRandom256() will degrade gracefully instead of immediately giving crappy random numbers.

This is a good idea, but you're using the encrypted read/write functions to do save/restore the pool state. I understand this is to ensure that the pool state is secret. But it is a problem because the encryption key the encrypted read/write functions use depends on which wallet is loaded. In some cases (eg. formatting non-volatile storage), random numbers are required when a wallet isn't even loaded (i.e. no encryption key is set).

The most general and secure fix I could think of for this is to define a "global" wallet encryption key, which exists solely to encrypt the pool state and its checksum. Actually, now that I think about it, the global wallet encryption key can also be used to encrypt the wallet names/versions. But this will require some significant changes elsewhere in the codebase. I will fully incorporate your suggestions, but only after I add support for multiple wallets.

[Peter Todd]

If I understand your patch correctly, you are adding a persistent (across power cycles) entropy pool so that in the event of an undetected HWRNG failure, getRandom256() will degrade gracefully instead of immediately giving crappy random numbers.

Exactly.

This is a good idea, but you're using the encrypted read/write functions to do save/restore the pool state. I understand this is to ensure that the pool state is secret. But it is a problem because the encryption key the encrypted read/write functions use depends on which wallet is loaded. In some cases (eg. formatting non-volatile storage), random numbers are required when a wallet isn't even loaded (i.e. no encryption key is set).

The most general and secure fix I could think of for this is to define a "global" wallet encryption key, which exists solely to encrypt the pool state and its checksum. Actually, now that I think about it, the global wallet encryption key can also be used to encrypt the wallet names/versions. But this will require some significant changes elsewhere in the codebase. I will fully incorporate your suggestions, but only after I add support for multiple wallets.

Ah, I see what you mean. That said, in the interm it's probably acceptable to simply store the random seed unencrypted. An attacker who gets hardware access to read it can only use that knowledge to find out what the random values will be in the future; past values are protected by the one-way property of SHA256. Any attacker who gains such access can do far worse things.

That said I should add some documentation to my patch making this clear, as well as think through this issue carefully.

Also, in general we should write a clear statement as to what types of attacks we're trying to prevent in the first place.

[Peter Todd]

The way my current implementation achieves constant time operation is to insert dummy operations instead of using branches. I believe this is like the "wait until maximum-time, while doing something cpu-intensive" approach, except that the waiting is interleaved instead of happening all at the end. However, it has the advantage that program flow is independent of secret data, so it also hides most (but not all) of the power consumption signature.

That's a good technique. Have you tried to measure the actual current consumption vs. time yet?

I had previously assumed that power analysis using a computer motherboard wouldn't be feasible for a hardware Bitcoin wallet. I assumed this because usually fast ADCs (at least the clock rate of the microcontroller) are required to do power analysis, and I doubt motherboards have 48 Msps ADCs in them. However, your comments have prompted me to question this. A point multiplication operation involves 256 point addition and point doubling operations which take place over some time (0.5 s to 4 s depending on the speed/power of the microcontroller). Sampling over each point addition/doubling would only require a < 1 ksps ADC and could possibly reveal information about secret data. Although I still think a power analysis virus is a bit exotic, it would be prudent to design some power analysis countermeasures into a hardware Bitcoin wallet.

It also occurred to me that another possible avenue of attack would be for the virus to record audio from the computer's line-in port. On most computers a lot of power-supply noise gets into the audio subsystem, and yet at the same time the ADCs connected to it are fast and precise.

About the hardware design: yes, I'd really appreciate help. Software mistakes can be fixed with a commit; hardware mistakes can require expensive redesign or rework.

Sure thing. What hardware experience do you currently have? I would be interested in starting a set of specs and then schematics.

For licensing the TAPR Open Hardware License looks reasonable: http://www.tapr.org/ohl.html - out of respect for my employer, I do want to make it clear I'm not trying to make any money out of this project. At the same time, my employer is also quite clear that I own the IP to things I develop unrelated to my job.

Yeah, using simulation of a simple zener regulator circuit, I couldn't get better than a factor of ~3 reduction in power consumption signature.

I think a mostly software solution is possible. A relatively large (compared to what's possible on a smartcard) amount of passive filtering can be used to mask high-frequency power consumption signatures (with a cutoff in the 10s of kHz).

Yeah, fix thing where it's easy, software, first, and then fix it where it's hard.

Using the system sound card as our threat model, we really have to filter out, well, practically everything. Even the high frequency stuff needs to be filtered as we can't predict what non-linearities exist in the system that would downconvert, say, 1MHz to 5KHz. That said, ferrites are cheap, and as you say, we've got a lot more room for stuff like that than on a smartcard. We'll have to come up with a plausible attack in detail to figure out just how many dB of reduction is required; unlike the projects I normally work on cost is a factor.

Of course, if cost is a problem, this can be a differentiation thing as well. Sell one version with "pretty-damn-good" security that leaves out the filtering and another "god-damn-bankvault" version that puts in back in.

The bankvault version can have all sorts of fun paranoia. For instance, if you have a sealed box, the best way to protect against it being opened is to put a light sensor and a light, in the box and trigger the alarm if the light level changes.

Say, for example, an addition: x + y requires i + d_i milliamp of current over one clock cycle, but the addition of ~x + ~y requires i - d_i milliamp of current over one clock cycle. As long as every necessary addition x + y is paired with a dummy addition ~x + ~y, total current consumption is always i milliamp of current over two clock cycles. Since the core clock of microcontrollers is in the Mhz range, the cycle-to-cycle variations in power consumption are not visible to an attacker; thanks to the filtering, only power consumption over hundreds of cycles is visible. The challenge is then to "pair" every necessary operation with a dummy operation that quickly compensates for the power comsumption of the necessary operation.

Yup. Pretty standard techniques, although we'll have to be careful to actually verify that the techniques really do work.

After seeing this: https://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html, I believe it is possible to bit-bang a USB host interface. So I will probably include a USB port on the wallet, for you to plug a USB keyboard into.

Nice! A keyboard is going to be a very slick interface, although do consider leaving a backup option for laptop users.

Incidentally, a keyboard makes possible a mode of operation that I think some users might like: brainwallet. The idea here is that you don't store the private key on the device at all. Rather each time you want to make a transaction, you connect the device up to a secure computer, type in your passphrase, have the device turn that into the wallet seed privkey, and then it tells the computer the public key portion of the seed. When you're done, the device forgets the privkey.

Now if the device falls into wrong hands, it can't even be used to show that you made transactions at all with that wallet, let alone steal coins from the wallet.

[Peter Todd]

Wow, sorry but you're talking Greek to me, retep.
What's the point in storing previously used random numbers? What's a HWRNG failure? I suppose the acronym means HardWare Random Number Generator, but still don't understand what you mean.

Electronics designers do like their greek letters.

So basically, HWRNG stands for HardWare Random Number Generator. There are a lot of ways to get hardware to generate random numbers, but the one thing in common with all of them is they can all fail, and you'll never know it if they do. So by storing a "seed" you have some pre-existing source of randomness. Every time a random number is generated you take the seed, and combine it with the allegedly random bits the hardware gives you to create a new random number. Specifically you do this with a cryptographic hash function like SHA256.

Now, lets suppose the seed turns out to not be random. This will happen the first time the device is powered up. No worries, the hardware will produce some randomness.

Now, lets suppose you've been using the device for a few years, and one day the hardware random number generator fails. Again, no worries! So long as the attacker doesn't know what your random seed is, you can use it to derive unpredictable, if not strictly speaking random, numbers for as long as you want. All you actually care about is that the attacker can't guess what number you used, that the entropy of the number is actually lower than specified isn't a problem.

Of course, there are nuances like how do you take the current seed, and generate a random number from it in such a way that the attacker can't guess the seed, but you get the idea.

For further explanation, look up the Yarrow algorithm: http://www.schneier.com/yarrow.html

[someone42]

Regardless of how you collect your random data you should be also saving the state of the random number generator so you can restore it on the next power up. Currently the getRandom256() function collects new random bytes from the hardware generator, hashes them with sha256, and then returns that result. It really needs to operate with a persistent entropy pool to protect against a HWRNG failure. FWIW I just created an un-tested patch that implements this. See https://github.com/retep/hardware-bitcoin-wallet/compare/persistent-pool-prng

I've finally implemented the persistent entropy pool. It was more work than I thought because the persistent entropy pool doesn't play nice when trying to format non-volatile storage - if the entropy pool is stored in non-volatile storage, it gets mangled in the process, so I've added a way to temporarily store it in RAM.

Have you tried to measure the actual current consumption vs. time yet?

Nope. It's something which is dependent on which microcontroller we choose, so measurements should probably be done after a choice is made.

Sure thing. What hardware experience do you currently have? I would be interested in starting a set of specs and then schematics.

For licensing the TAPR Open Hardware License looks reasonable: http://www.tapr.org/ohl.html - out of respect for my employer, I do want to make it clear I'm not trying to make any money out of this project. At the same time, my employer is also quite clear that I own the IP to things I develop unrelated to my job.

With hardware, I consider myself merely a hobbyist. I have designed and built many circuits in the past, but I've never designed anything which was "mass-produced". That's another reason why I wanted to keep things simple; I don't think I could design something with exotic features like self-destruct on tamper detection. It was always my intent to open-source everything, so TAPR looks good.

I have thought a lot about the requirements and it's quite clear that the ATmega328 isn't going to cut it. Even now, I'm close to running out of program flash. Having a look around, I reckon the LPC11Uxx series from NXP (see http://www.nxp.com/products/microcontrollers/cortex_m0/lpc11u00/) is appropriate: low power, low cost, integrated USB, integrated EEPROM and good development tools. What do you think?

Using the system sound card as our threat model, we really have to filter out, well, practically everything. Even the high frequency stuff needs to be filtered as we can't predict what non-linearities exist in the system that would downconvert, say, 1MHz to 5KHz. That said, ferrites are cheap, and as you say, we've got a lot more room for stuff like that than on a smartcard. We'll have to come up with a plausible attack in detail to figure out just how many dB of reduction is required; unlike the projects I normally work on cost is a factor.

I thought of another way to mask power signatures. With some transistors and a large-ish (> 100 uF) capacitor, a device can temporarily disconnect its own USB power line. It can then operate in two phases:

• A discharging phase, where the device does cryptographic operations while USB power is disconnected, using the capacitor as a temporary power supply
• and a charging phase, where the device sleeps while USB power charges the capacitor.

For example, if the microcontroller/regulator can tolerate a 1 volt drop and current consumption is 15 milliamp, then a 100 uF capacitor allows the discharging phase to be about ~7 ms. If the capacitor can tolerate a current of 100 milliamp, then the charging phase is only 1 ms. This results in a small (13%) reduction in overall performance, but I don't think anyone will care if a signing operation takes 1.1 second instead of 1.0 second.

This method can be applied to any cryptographic algorithm. An attacker can still measure power consumption, but they can only measure the average power consumption over each discharging phase. For a 7 ms discharging phase, this equates to 100,000s of clock cycles. There's probably not a lot of useful information in that. If more masking is required, the microcontroller can dissipate some power in a resistor, either to compensate for the power consumption of its ALU, or to inject some noise into an attacker's measurements.

@someone42
You should give your device and protocol a name.

That way client software can advertise itself as supporting 'YourName' devices.
Also people can then clone your hardware and advertise their devices as 'YourName' compatible.

I'm bad at naming things. I chose "hardware Bitcoin wallet" as a working title because it's direct. At one time I thought "Solidcoin" (solid: it's a solid device you can physically hold in your hand, coin: from Bitcoin) would be a good name, but that name's already taken. If you or anyone else can come up with a good name, I'll adopt it.

[molecular]

Definitely an interesting concept.

But before using any sort of embedded device to generate keys, I'd want some confidence in its random number generator. (I haven't looked at the hardware or code, and I don't have the expertise to evaluate its randomness even if I did.) But the research using EFF SSL data that indicates a lot of SSL certificates in the wild use bad random number generators, probably generated on embedded devices, makes me really hesitant to use an embedded device to generate my bitcoin keys without a lot of scrutiny.

well, if the device has capability to restore a seed, you could also generate the seed somewhere else.

[molecular]

I'm bad at naming things. I chose "hardware Bitcoin wallet" as a working title because it's direct. At one time I thought "Solidcoin" (solid: it's a solid device you can physically hold in your hand, coin: from Bitcoin) would be a good name, but that name's already taken. If you or anyone else can come up with a good name, I'll adopt it.

Solidcoin would indeed be a very poor choice.

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name for a micro-btc)

[Xenland]

I'm bad at naming things. I chose "hardware Bitcoin wallet" as a working title because it's direct. At one time I thought "Solidcoin" (solid: it's a solid device you can physically hold in your hand, coin: from Bitcoin) would be a good name, but that name's already taken. If you or anyone else can come up with a good name, I'll adopt it.

Solidcoin would indeed be a very poor choice.

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name Drug dealing code word for a micro-btc)

fixed that for ya

[Peter Todd]

I've finally implemented the persistent entropy pool. It was more work than I thought because the persistent entropy pool doesn't play nice when trying to format non-volatile storage - if the entropy pool is stored in non-volatile storage, it gets mangled in the process, so I've added a way to temporarily store it in RAM.

Cool! I'm actually kinda surprised how directly my code actually translated over.

Nope. It's something which is dependent on which microcontroller we choose, so measurements should probably be done after a choice is made.

Fair enough. Probably quite uC dependent. It'd be nice if we could compare different uC's, but that'd likely be a fair amount of effort better devoted elsewhere.

With hardware, I consider myself merely a hobbyist. I have designed and built many circuits in the past, but I've never designed anything which was "mass-produced". That's another reason why I wanted to keep things simple; I don't think I could design something with exotic features like self-destruct on tamper detection. It was always my intent to open-source everything, so TAPR looks good.

Sounds good. I'd also suggest you use the GPL-2 or -3 for the firmware license. In a project like this the bulk of the work is really the firmware, so reasonably strong protections are probably a good thing, especially the patent clauses in the GPL-3. You're current license is both permissive, yet by being non-standard can still cause problems for other projects trying to re-use the code.

I have thought a lot about the requirements and it's quite clear that the ATmega328 isn't going to cut it. Even now, I'm close to running out of program flash. Having a look around, I reckon the LPC11Uxx series from NXP (see http://www.nxp.com/products/microcontrollers/cortex_m0/lpc11u00/) is appropriate: low power, low cost, integrated USB, integrated EEPROM and good development tools. What do you think?

I like the idea of 32-bit ARM for futureproofing and making it easier to re-use code.

However, those LPC11U's are really hard to get; everything better than 32KB of program memory seems to involve long lead times. It's a new product and they're probably having  a hard time ramping up production. They've probably also pre-sold most of their initial production as well.

Picking something with a dev kit available at sparkfun is probably a good idea. That said price is an issue. How much *ram* do you think you can live with?

I looked around on digikey for stuff meeting the criteria of ARM, 128KB flash, 48-LQFP package, and 3.3V power requirements and there actually are only about a dozen different chips available, and not all have USB and ADC's. That said, you can probably use a bit-bang USB implementation if you can find one, and for the ADC as long as your random error source has a decent voltage swing you can use a capture and compare module instead.

I thought of another way to mask power signatures. With some transistors and a large-ish (> 100 uF) capacitor, a device can temporarily disconnect its own USB power line. It can then operate in two phases:

• A discharging phase, where the device does cryptographic operations while USB power is disconnected, using the capacitor as a temporary power supply
• and a charging phase, where the device sleeps while USB power charges the capacitor.

For example, if the microcontroller/regulator can tolerate a 1 volt drop and current consumption is 15 milliamp, then a 100 uF capacitor allows the discharging phase to be about ~7 ms. If the capacitor can tolerate a current of 100 milliamp, then the charging phase is only 1 ms. This results in a small (13%) reduction in overall performance, but I don't think anyone will care if a signing operation takes 1.1 second instead of 1.0 second.

This method can be applied to any cryptographic algorithm. An attacker can still measure power consumption, but they can only measure the average power consumption over each discharging phase. For a 7 ms discharging phase, this equates to 100,000s of clock cycles. There's probably not a lot of useful information in that. If more masking is required, the microcontroller can dissipate some power in a resistor, either to compensate for the power consumption of its ALU, or to inject some noise into an attacker's measurements.

Well, the simple thing isn't to discharge power into a resistor, but rather measure your own power supply voltage and at the end of the crypto-cycle use a variable amount of power to reach a specified voltage at a specified time.

Note that any switch to disconnect the uC from the USB power will have capacitance from drain to source in the off state. That said, that capacitance is usually in the order of dozens to hundreds of pF and can easily be shunted to ground by a few capacitors.


Going back to the zener idea, I forgot about synthetic active zeners. Chips like the LT1431 have as little as 0.1ohms dynamic resistance, which would be plenty good enough. Reasonably cheap too, $3.76 to $1.91 in bulk and it'd replace the 3.3V regulator you'd need anyway. Disconnecting the power supply would be more like $0.5 though.
 

@someone42
You should give your device and protocol a name.

That way client software can advertise itself as supporting 'YourName' devices.
Also people can then clone your hardware and advertise their devices as 'YourName' compatible.

I'm bad at naming things. I chose "hardware Bitcoin wallet" as a working title because it's direct. At one time I thought "Solidcoin" (solid: it's a solid device you can physically hold in your hand, coin: from Bitcoin) would be a good name, but that name's already taken. If you or anyone else can come up with a good name, I'll adopt it.

mikey's actually kinda clever. "mikey" isn't googlable of course, but mikey bitcoin, or mikey bitcoin wallet doesn't have any hits.

[someone42]

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name for a micro-btc)

Unfourtunately, it's too similar to "myki" (http://www.myki.com.au/), a public transport smartcard used in Australia.

Sounds good. I'd also suggest you use the GPL-2 or -3 for the firmware license. In a project like this the bulk of the work is really the firmware, so reasonably strong protections are probably a good thing, especially the patent clauses in the GPL-3. You're current license is both permissive, yet by being non-standard can still cause problems for other projects trying to re-use the code.

I chose the BSD "2-clause" licence because it was one of the most permissive licences accepted by the Open Source Initiative. I believe it exactly the same in spirit to the MIT/expat licence (maybe I should use that?). If software patents are a problem, why not use the Apache License v2.0? It's compatible with GPL-3 (http://www.gnu.org/licenses/license-list.html#apache2), so there would be less re-use problems.

However, those LPC11U's are really hard to get; everything better than 32KB of program memory seems to involve long lead times. It's a new product and they're probably having  a hard time ramping up production. They've probably also pre-sold most of their initial production as well.

Picking something with a dev kit available at sparkfun is probably a good idea. That said price is an issue. How much *ram* do you think you can live with?

I was looking at the LPC11U24, which seems quite widely available (there are also easy-to-use dev kits out there eg. http://www.sparkfun.com/products/11045). Though it only has 32KB of program memory, I've found that Cortex-M0 code is much smaller than AVR 8-bit. For example, the platform-independent portion of hardware Bitcoin wallet compiles to 22.8KB on AVR 8-bit, but compiles to only 11.5 KB on Cortex-M0 (using the yagarto toolchain).

As for RAM requirements, anything greater than 2 KB is probably enough. Currently, I've calculated maximum RAM usage to be ~1.5 KB.

Going back to the zener idea, I forgot about synthetic active zeners. Chips like the LT1431 have as little as 0.1ohms dynamic resistance, which would be plenty good enough. Reasonably cheap too, $3.76 to $1.91 in bulk and it'd replace the 3.3V regulator you'd need anyway. Disconnecting the power supply would be more like $0.5 though.

Is there any reason why the dirt-cheap TL431 couldn't be used? Looking at datasheets, the TL431s from various manufacturers have a typical output impedance of between 100 and 300 mohm. And they're cheaper than a 3.3V LDO which I was going to have to use anyway.

[cbeast]

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name for a micro-btc)

˙ɐıןɐɹʇsnɐ uı pǝsn pɹɐɔʇɹɐɯs ʇɹodsuɐɹʇ ɔıןqnd ɐ '(/nɐ˙ɯoɔ˙ıʞʎɯ˙ʍʍʍ//:dʇʇɥ) "ıʞʎɯ" oʇ ɹɐןıɯıs ooʇ s,ʇı 'ʎןǝʇɐunʇɹnoɟun

FTFY
To the rest of the world "mikey" would be a good name. 

[Peter Todd]

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name for a micro-btc)

Unfourtunately, it's too similar to "myki" (http://www.myki.com.au/), a public transport smartcard used in Australia.

Spelled differently though, that's enough for google. I know what you mean about names though... I've got a project of my own and the best I've come up with is STEGanographic BAKups...

Sounds good. I'd also suggest you use the GPL-2 or -3 for the firmware license. In a project like this the bulk of the work is really the firmware, so reasonably strong protections are probably a good thing, especially the patent clauses in the GPL-3. You're current license is both permissive, yet by being non-standard can still cause problems for other projects trying to re-use the code.

I chose the BSD "2-clause" licence because it was one of the most permissive licences accepted by the Open Source Initiative. I believe it exactly the same in spirit to the MIT/expat licence (maybe I should use that?). If software patents are a problem, why not use the Apache License v2.0? It's compatible with GPL-3 (http://www.gnu.org/licenses/license-list.html#apache2), so there would be less re-use problems.

That's a good idea I think. However you still have the problem that someone can take the firmware, put it in their own product, and then distribute it under their own license *not* subject to the patent provisions; it only protects you against patents that contributors assert.

If you decide to use TAPR for a hardware license you're making the hardware design more restrictive than the software design. Hardware is expensive to develop, and not always all that reusable. You also have the issue where the copyrightable parts of hardware, the board layout and schematic, are actually no-where near as important as the design calculations that went into them. So licensing for hardware doesn't buy you much. For firmware though by putting your code under the GPL, and especially the GPL-3 with the patent provisions, you make sure that someone who decides to develop the "hardware bitcoin wallet 2" will contribute back to the community in a way that permissive licenses don't.

However, those LPC11U's are really hard to get; everything better than 32KB of program memory seems to involve long lead times. It's a new product and they're probably having  a hard time ramping up production. They've probably also pre-sold most of their initial production as well.

Picking something with a dev kit available at sparkfun is probably a good idea. That said price is an issue. How much *ram* do you think you can live with?

I was looking at the LPC11U24, which seems quite widely available (there are also easy-to-use dev kits out there eg. http://www.sparkfun.com/products/11045). Though it only has 32KB of program memory, I've found that Cortex-M0 code is much smaller than AVR 8-bit. For example, the platform-independent portion of hardware Bitcoin wallet compiles to 22.8KB on AVR 8-bit, but compiles to only 11.5 KB on Cortex-M0 (using the yagarto toolchain).

As for RAM requirements, anything greater than 2 KB is probably enough. Currently, I've calculated maximum RAM usage to be ~1.5 KB.

Ah, that's much more reasonable then, still maybe a bit tight, but if you can live with it for a few months I'm sure the better LPC's will be available then.

Going back to the zener idea, I forgot about synthetic active zeners. Chips like the LT1431 have as little as 0.1ohms dynamic resistance, which would be plenty good enough. Reasonably cheap too, $3.76 to $1.91 in bulk and it'd replace the 3.3V regulator you'd need anyway. Disconnecting the power supply would be more like $0.5 though.

Is there any reason why the dirt-cheap TL431 couldn't be used? Looking at datasheets, the TL431s from various manufacturers have a typical output impedance of between 100 and 300 mohm. And they're cheaper than a 3.3V LDO which I was going to have to use anyway.

Good idea. The Texas Instruments TL431CPK, the SOT-89 package, is only $0.43 in singles and $0.16 in bulk, and the SOT-89 package has a very good 52degC/W thermal resistance to ambient.

One thing to keep in mind is that the output impedance of the whole circuit is different than the zener itself. If you look at the footnote on page 19 of the TL431 datasheet it points out that the dynamic impedance of the circuit in two-resistor mode is actually Z=|Zka|(1-R1/R2), essentially because the reference resistors to set the output voltage are influenced by a change in the voltage they are supposed to set. That equation is also a ratio - it's totally determined by the required output voltage. Vref=Vout*R2/(R1+R2) -> R1/R2=Vout/Vref-1 -> Z=|Zka|(2-Vout/Vref) -> Z=|0.5ohms max|(2-3.3V/2.5V)=0.34ohms and 0.136ohms typical (0.2ohm Zka)

So basically in our case we can go for an even worse-performing active zener than expected.

Your other issue will be the reference voltage temperature coefficient. A change in output voltage implies a change in input current of course so what we really want is what is the change in reference voltage due to change in temperature due to change in current, three chained derivatives. You'd also need to work out the thermal intertia of the chip+board. However a quick glance at page 22 of that TL431 datasheet pretty quickly shows this really shouldn't be an issue. With the SOT-89 package your change in temperature from 0mA to 100mA is only a few degrees, which at worst seems to imply a change in voltage of only a few mV. Also, the change in temperature due to the crypto isn't terribly predictable measured against equally big changes in ambient temperature from the room, as well as conducted into the device from the computer. I don't see any reason to worry about it. Just make sure the load resistor used in conjunction with the zener has similarly good properties, which is easy as resistors with downright magical specs are cheap and available.

[2112]

I have one comment related to your choice of CPUs.

It seems like you have a wide power margin in your power budget, in fact so wide that you are thinking of plainly burning this power to increase the resistance to DPA & DFA (Differential Power Analysis & Differential Fault Analysis).

I propose that you could burn that power in a more usefull way. If you choose a CPU that supports SIMD instructions you can greatly increase the resistance to those side-channel attacks. I'm aware of AVR32 controllers with SIMD extensions (apparently mature/obsoleted) as well as versions of ARM processors with NEON extensions.

The basic attack defense mode is to use a 4-way SIMD streams to simultaneously compute:

1) two copies of the desired cryptographic result
2) two copies of a benchmark cryptographic problem with a known result

The benchmark problem is randomly selected from a library of known solutions, and the allocation of the problems to the vector registers is also made randomly.

The papers I remember seeing about the above techniques were concerned with symmetric crypto as well as RSA assymetric crypto. I would presume that the results carry over to the elliptic assymetric crypto.

If the ARMs with NEON are too expensive or otherwise unsuitable the techniques are still valid when used in a plain CPU. In that case care must be taken to prevent the compilers from optimizing and reordering the instruction streams bythe  use of the appropriate "__builtin" functions (in GCC).

[molecular]

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name for a micro-btc)

Unfourtunately, it's too similar to "myki" (http://www.myki.com.au/), a public transport smartcard used in Australia.

or the "makey makey": https://www.youtube.com/watch?feature=player_embedded&v=rfQqh7iCcOU#!

I couldn't care less, screw trademarks, before you find a name that way you're old as Stallman with a white beard.

[cbeast]

or the "makey makey": https://www.youtube.com/watch?feature=player_embedded&v=rfQqh7iCcOU#!

Wow! I was just thinking about something like that the other day. Thanks for the link! BTW, the OP is a great idea too

[someone42]

An update on features: I've added support for multiple wallets and hidden (plausibly deniable) wallets. 2 KB of EEPROM should be able to store 10 wallets; 4 KB of EEPROM should be able to store 23 wallets. The LPC11U24 comes in 2 KB and 4 KB variants.

If you decide to use TAPR for a hardware license you're making the hardware design more restrictive than the software design. Hardware is expensive to develop, and not always all that reusable. You also have the issue where the copyrightable parts of hardware, the board layout and schematic, are actually no-where near as important as the design calculations that went into them. So licensing for hardware doesn't buy you much. For firmware though by putting your code under the GPL, and especially the GPL-3 with the patent provisions, you make sure that someone who decides to develop the "hardware bitcoin wallet 2" will contribute back to the community in a way that permissive licenses don't.

I did intentionally choose a permissive licence because I wanted other people to be able to reuse portions of my code with few restrictions. I don't think someone else will release a closed-source wallet since the Bitcoin community isn't going to accept the whole "trust me, there isn't a backdoor in this binary" thing. Maybe the hardware should be licensed under a more permissive licence (than TAPR) to match the firmware?

One thing to keep in mind is that the output impedance of the whole circuit is different than the zener itself. If you look at the footnote on page 19 of the TL431 datasheet it points out that the dynamic impedance of the circuit in two-resistor mode is actually Z=|Zka|(1-R1/R2), essentially because the reference resistors to set the output voltage are influenced by a change in the voltage they are supposed to set. That equation is also a ratio - it's totally determined by the required output voltage. Vref=Vout*R2/(R1+R2) -> R1/R2=Vout/Vref-1 -> Z=|Zka|(2-Vout/Vref) -> Z=|0.5ohms max|(2-3.3V/2.5V)=0.34ohms and 0.136ohms typical (0.2ohm Zka)

So basically in our case we can go for an even worse-performing active zener than expected.

Your other issue will be the reference voltage temperature coefficient. A change in output voltage implies a change in input current of course so what we really want is what is the change in reference voltage due to change in temperature due to change in current, three chained derivatives. You'd also need to work out the thermal intertia of the chip+board. However a quick glance at page 22 of that TL431 datasheet pretty quickly shows this really shouldn't be an issue. With the SOT-89 package your change in temperature from 0mA to 100mA is only a few degrees, which at worst seems to imply a change in voltage of only a few mV. Also, the change in temperature due to the crypto isn't terribly predictable measured against equally big changes in ambient temperature from the room, as well as conducted into the device from the computer. I don't see any reason to worry about it. Just make sure the load resistor used in conjunction with the zener has similarly good properties, which is easy as resistors with downright magical specs are cheap and available.

Looking at TI's datasheet (http://www.ti.com/lit/ds/symlink/tl431a.pdf), I see a "+" instead of a "-" on page 19. Am I missing something? But if dynamic impedance is a problem, what if we used an extra PNP transistor (like on Figure 21 of the datasheet) as the shunt? If I understand the circuit correctly, the transistor amplifies current changes from the TL431, theoretically decreasing dynamic impedance by the current gain h_FE of the transistor. That would result in an insanely low dynamic impedance, though there are probably stability problems involved with putting an amplifier in the TL431's control loop. As an additional bonus, it would further decrease the thermal effects you mention.

I suggest "mikey", following connotations:

 * usb key form factor
 * stores "my key" to my money
 * holds mikes (street name for a micro-btc)

˙ɐıןɐɹʇsnɐ uı pǝsn pɹɐɔʇɹɐɯs ʇɹodsuɐɹʇ ɔıןqnd ɐ '(/nɐ˙ɯoɔ˙ıʞʎɯ˙ʍʍʍ//:dʇʇɥ) "ıʞʎɯ" oʇ ɹɐןıɯıs ooʇ s,ʇı 'ʎןǝʇɐunʇɹnoɟun

FTFY
To the rest of the world "mikey" would be a good name. 

How about "CoinKey" or "BitKey"? Both are google-able, and both have .org domain names available. "CoinKey" also suggests that the wallet can be used with an alternative cryptocurrency such as Namecoin, since it (presumably) also uses ECDSA for coin transfer.

I have one comment related to your choice of CPUs.

It seems like you have a wide power margin in your power budget, in fact so wide that you are thinking of plainly burning this power to increase the resistance to DPA & DFA (Differential Power Analysis & Differential Fault Analysis).

I propose that you could burn that power in a more usefull way. If you choose a CPU that supports SIMD instructions you can greatly increase the resistance to those side-channel attacks. I'm aware of AVR32 controllers with SIMD extensions (apparently mature/obsoleted) as well as versions of ARM processors with NEON extensions.

The basic attack defense mode is to use a 4-way SIMD streams to simultaneously compute:

1) two copies of the desired cryptographic result
2) two copies of a benchmark cryptographic problem with a known result

The benchmark problem is randomly selected from a library of known solutions, and the allocation of the problems to the vector registers is also made randomly.

The papers I remember seeing about the above techniques were concerned with symmetric crypto as well as RSA assymetric crypto. I would presume that the results carry over to the elliptic assymetric crypto.

If the ARMs with NEON are too expensive or otherwise unsuitable the techniques are still valid when used in a plain CPU. In that case care must be taken to prevent the compilers from optimizing and reordering the instruction streams bythe  use of the appropriate "__builtin" functions (in GCC).

Those ARM processors with NEON are in a much more powerful (and much more expensive) class than the Cortex-M0 microcontrollers I'm looking at using. I think what you're suggesting is to use SIMD to detect fault analysis, since any injected faults will affect the benchmark problem. But I'm not that worried about fault analysis, because the attack model I have in my head is that of a remotely compromised host computer. This means that timing attacks and power analysis attacks are an issue, because a typical computer has the ability to measure time and power consumption. But I can't think of any way a typical computer could inject faults into a USB device, especially if that device has its own clock and filters its power supply.

or the "makey makey": https://www.youtube.com/watch?feature=player_embedded&v=rfQqh7iCcOU#!

Wow! I was just thinking about something like that the other day. Thanks for the link! BTW, the OP is a great idea too

I should probably say this now: the idea for a hardware Bitcoin wallet isn't mine, nor are the core ideas (like the use of a deterministic wallet). This sort of thing has been suggested multiple times on this forum. I was expecting someone to beat me to an actual implementation, and was surprised when it didn't happen.

[ripper234]

Would this support m-of-n signatures?

Please read this short thread, I'm glad to see someone has started working on this already.

What is the state of this project?
Have you thought about integration with existing wallets?

[someone42]

Would this support m-of-n signatures?

Please read this short thread, I'm glad to see someone has started working on this already.

What is the state of this project?
Have you thought about integration with existing wallets?

I do intend to add support for m-of-n signatures some time in the future. Currently, I'm working on porting the code to better hardware. I'm also writing code to do online testing of the hardware noise source, so that its failure can be detected. The project's github page (https://github.com/someone42/hardware-bitcoin-wallet) should have the latest development status.

As for integration with existing wallets, I like BIP 0032 (see https://en.bitcoin.it/wiki/BIP_0032) and will probably implement a BIP 0032-compatible deterministic wallet. IIRC, the authors of various Bitcoin clients have expressed interest in BIP 0032, so in the future you may be able to import and export wallets between this device and those clients.

Since the device doesn't do any blockchain management, it needs another client to act as a "host" and give it transactions to sign. I haven't contacted any developers of other clients about adding support for this wallet device yet, since its host communication interface is not mature - I haven't even decided which USB device class the wallet will implement.

[jim618]

Good idea to implement an BIP 32 / HD wallet.

I know for sure the Satoshi/ Armory/ MultiBit clients plan an implementation so to talk to your device there would just be the serial IO to integrate.

[ripper234]

Good idea to implement an BIP 32 / HD wallet.

I know for sure the Satoshi/ Armory/ MultiBit clients plan an implementation so to talk to your device there would just be the serial IO to integrate.

Have you thought about raising money for this project, Kickstarter style?

I would pay for such a device, if it was professionally made.

I approached the makers of CryptoStick about the possible cost of such a device, and their rough answer was "100,000 euro + 50 euro per device". That's a bit stiff...

I'm not a hardware guy ... how much do you think it will cost to mass manufacture these, with these requirements:

1. Key is only stored on the device, only ECDES signatures are sent out.
2. No internal power source needed, draw power via USB
3. Support for m-of-n signatures are a must.

My dream use-case: you carry this around (1st signature), input a password into a computer to access your blockchain.info wallet (2nd signature), and can thus can move your bitcoins. To generate a signature, you get the bitcoin address and BTC amount from the USB interface, display them on the device to avoid any chance of trojan faking these, and click a button on the device (like Yubikey).

If you lose the device, you still have a 3rd signature lying someplace safe (bank vault). Compromising any single one of the 3 secrets doesn't cause you any harm.

4. Everything (code + hardware plans) should be open source.
5. This should be a real, production-quality project, and not just a POC.
6. The product should have long shelf life.

someone42, what are your plans with this? If you got funding, would you dedicate the necessary time & resources to make this production-grade? Do you have the necessary experience in making production-grade devices, or would you need to team up with someone to take it to the next level?

I want to help make this device a reality. I can donate funds and help organize a fund raiser, and perhaps help with other stuff (e.g. building a website, marketing).

Please pm if you want to discuss further.

[ripper234]

Ping

[someone42]

Have you thought about raising money for this project, Kickstarter style?

I would pay for such a device, if it was professionally made.

I approached the makers of CryptoStick about the possible cost of such a device, and their rough answer was "100,000 euro + 50 euro per device". That's a bit stiff...

I'm not a hardware guy ... how much do you think it will cost to mass manufacture these, with these requirements:

1. Key is only stored on the device, only ECDES signatures are sent out.
2. No internal power source needed, draw power via USB
3. Support for m-of-n signatures are a must.

My dream use-case: you carry this around (1st signature), input a password into a computer to access your blockchain.info wallet (2nd signature), and can thus can move your bitcoins. To generate a signature, you get the bitcoin address and BTC amount from the USB interface, display them on the device to avoid any chance of trojan faking these, and click a button on the device (like Yubikey).

If you lose the device, you still have a 3rd signature lying someplace safe (bank vault). Compromising any single one of the 3 secrets doesn't cause you any harm.

4. Everything (code + hardware plans) should be open source.
5. This should be a real, production-quality project, and not just a POC.
6. The product should have long shelf life.

someone42, what are your plans with this? If you got funding, would you dedicate the necessary time & resources to make this production-grade? Do you have the necessary experience in making production-grade devices, or would you need to team up with someone to take it to the next level?

I want to help make this device a reality. I can donate funds and help organize a fund raiser, and perhaps help with other stuff (e.g. building a website, marketing).

Please pm if you want to discuss further.

The requirements and use case you listed are basically what I had in mind for this project. However, I have no experience with production-grade hardware, only "once-off" hardware. I would also like to see this project become a real product, but I have no experience with marketing, distribution, compliance testing, supply chain management etc. By myself, I can probably get this project to a stage where I have a working, fully-assembled prototype in my hands, but to actually make a product, I would need to team up with someone/some people.

As for costs, the wallet is simple hardware-wise, so it's quite cheap. I originally estimated the parts + assembly cost at 6 to 7 USD per device (for quantity = 1000), but after some revisions, I think "somewhere in the vicinity of 10 USD" is more accurate. I haven't thought about fundraising, because so far I haven't had any need for funds specific to this project (all the stuff I've bought can be used for future projects).

Anyway, I'm glad to see that people are interested in this project. I do hope to get to a working, assembled prototype by the end of this year.

[Dabs]

I'd like a hardware wallet where you can import your own keys, like vanity keys, or your own generated private keys. It should be a one way write only function. It can never be read from, so there would be no way to extract the private keys.

That way, you generate the keys on a secure air gapped computer and send them to the hardware wallet when plugged via USB.

Something like a yubikey.

Maybe future versions could even be connected by bluetooth or wifi. (but then they probably won't be considered "airgapped")

[allten]

So many great minds on here. I started working on the same project for the last few weeks knowing there had to be someone already doing the same thing.
Well, tonight I discovered this thread.

I'm not about making a profit or anything; I would just like to see this product available.

I've been coding for a MICROCHIP PIC 32 bit MCU.

[irritant]

alten maybe you can help    i also want to see this project become a real product, but i dont have those skills ..

However, I have no experience with production-grade hardware, only "once-off" hardware. I would also like to see this project become a real product, but I have no experience with marketing, distribution, compliance testing, supply chain management etc.

[someone42]

I have just completed an improved prototype.

Here is a picture of that prototype. An Australian 20 cent coin (comparable in size to the US half dollar) is shown for scale. It is signing the same transaction as in the OP.


The firmware has received substantial improvements. Here is a summary of current features:

• Wallet encryption. Wallets are encrypted using AES-128 in XTS mode. Encryption is optional.
• All potentially dangerous operations (eg. formatting storage) require user confirmation.
• When signing a transaction, all output addresses and amounts are displayed, as well as the transaction fee.
  
• The transaction parser supports P2SH addresses.
• Deterministic wallets. All addresses are generated from a random seed, so that once a backup is done, no further backups are necessary.
• Wallet backup/restore. A wallet's deterministic seed can be displayed on-screen, giving the user the opportunity to write it down. Wallet backups can be (but don't have to be) encrypted.
• Multiple wallets. A single device can hold many wallets. Each of these wallets are independent - they can have different addresses and different encryption keys.
• Hidden (plausibly deniable) wallets. Erased wallets consist of random data. Since encrypted data is statistically indistinguishable from random data, (theoretically) the existence of a hidden wallet cannot be confirmed without the correct encryption key.
• Secure formatting. Formatting a device does a multipass, low-level (i.e. bypasses any wear levelling) overwrite with random data.
• Dedicated hardware entropy source. A thermal noise source is sampled to collect entropy. The source is continually tested for signs of failure and interference. A persistent entropy pool mitigates the impact of more subtle failures

Here is the current prototype doing a wallet backup:

Note that the entire seed is displayed over three such screens; only the first one is shown.

These are some features that I would like to implement for the future:

• BIP0032-compatible deterministic wallets.
• Resilience to sudden power-off events. In other words, data corruption should be avoided if power is suddenly removed at any time. This is necessary because the wallet is USB powered.
• P2SH address generation. This will enable some secure multisig use cases, such as the secure reception of funds.
• Software ("bit banged") low-speed USB host for USB keyboard input. This will enable the input of wallet encryption keys in a way which bypasses software keyloggers.
• Firmware updating. I intend to allow this only simultaneous with the erasure of all wallets. That way, firmware updates cannot be used to extract the contents of a wallet, and the firmware update feature cannot be used to install a backdoor without the user noticing (provided the user creates their wallets on a clean device).

Some additional statistics:

• Firmware binary size: 22.9 kilobytes.
• Required RAM: 8 kilobytes.
• Required non-volatile memory per wallet: 160 bytes. The included 4 kilobyte EEPROM fits about 23 wallets.
• Microcontroller: NXP LPC11U24, a 32-bit ARM Cortex-M0 microcontroller running at 48 Mhz.
• Display: SSD1306-based OLED display, with a resolution of 128x64. That's enough to display 4 lines of 16 characters.

Firmware source is available from https://github.com/someone42/hardware-bitcoin-wallet. A schematic of the circuit in the top picture is available from https://github.com/someone42/hardware-bitcoin-wallet/blob/master/lpc11uxx/hardware/hwrng.jpg.

I have teamed up with someone else (allten on this forum) who is doing hardware development. This means that the next prototype will probably be much cleaner and more robust.

[jim618]

Hello someone42,

It looks like you are making great progress on your hardware wallet.

Have you considered if/ how your users can hook up to their desktop wallets ?
I ask as I am sure you are aware of the Slush/ Stick wallet and I wonder if you could consolidate your 'wire protocol' so that desktop clients only have one API to work against.

By 'wire protocol' I mean the message format and the method calls between the hardware device and a host computer that gives it the transactions to sign.

I ask as, to be honest, there is quite a lot of software effort in supporting hardware devices so having a common interface would really help their rollout.

Of course it is not always easy to get something that works both across devices and across desktop clients but it would be a great result if we could do it.

Jim

[2112]

Some additional statistics:

• Firmware binary size: 22.9 kilobytes.
• Required RAM: 8 kilobytes.
• Required non-volatile memory per wallet: 160 bytes. The included 4 kilobyte EEPROM fits about 23 wallets.
• Microcontroller: NXP LPC11U24, a 32-bit ARM Cortex-M0 microcontroller running at 48 Mhz.

Thank you very much for the additional information you gave.

I clicked around on the NXP's web site to see how thin is the ice you are skating on. It is very thin: 32kB is the maximum firmware size in the chips you selected.

LPC11U2x family is 24-32/1-2-4/6-8 Flash/EEPROM/SRAM

LPC11U3x family is 40-48-64-96-128/4/8-10-12 Flash/EEPROM/SRAM

I didn't to a thorough price research but the random price comparison gave me $2.26 for 11U24 and $3.14 for 11U37.

The very important additional information is that the free version of LPCXpresso platform will allow the user to build an executable of any size, but there is a restriction in terms of code download which is 128kB.

The target market here is open-source tinkerers. They are not going to be much affected by a price difference of about $5.

So I suggest switch to the top-of-the-line LPC11U37 with the compatible package if possible. People will buy it just for the opportunity to tinker with it.

Edit: Thanks again for posting the address space utilization numbers. I wasn't really aware how thinly shaved some of the ARM-licensed designs are. I was talking about NEON and SIMD-like coding and these devices have a software integer division in ROM! Sorry. The oldest and smallest embedded design I ever worked on used full 8-bit address space of 64kB divided between DRAM and EPROM.

[someone42]

Thank you very much for the additional information you gave.

I clicked around on the NXP's web site to see how thin is the ice you are skating on. It is very thin: 32kB is the maximum firmware size in the chips you selected.

LPC11U2x family is 24-32/1-2-4/6-8 Flash/EEPROM/SRAM

LPC11U3x family is 40-48-64-96-128/4/8-10-12 Flash/EEPROM/SRAM

I didn't to a thorough price research but the random price comparison gave me $2.26 for 11U24 and $3.14 for 11U37.

There's a reason for this: back when I was looking at dev kits to purchase, the LPC11U3x series hadn't been released yet, though I was aware of their impending release. Fourtunately, the LPC11U3x series are all fully binary and pin-compatible with the LPC11U24. Future prototypes will definitely use a microcontroller with more program memory.

I'd like a hardware wallet where you can import your own keys, like vanity keys, or your own generated private keys. It should be a one way write only function. It can never be read from, so there would be no way to extract the private keys.

I do see the merit of this, in that it increases interoperability with the existing Bitcoin infrastructure. I've considered allowing a few (maybe 4?) imported private keys per wallet. However, I see this feature to be slightly beyond the scope I had in mind for this project, so it's quite low on my feature priority list.

[Ente]

Where is this!
Give me that Hardware Wallet!
Shut up and take my money!

Seriously, what's the current status? Is this here the most recent thread?

Ente

[someone42]

Here's an update:

In October 2012, allten contacted me. He had designed some hardware but needed some firmware, while I had some firmware but only a hardware prototype. So we combined our efforts. He sent me a special development version of the BitSafe:




I spent some time porting the firmware to the BitSafe. I think the BitSafe will be the "home" of the hardware-bitcoin-wallet firmware, though much of that codebase is and will remain platform-independent. If you want to get your hands on some actual hardware, see https://bitcointalk.org/index.php?topic=152517.0.

The images above make the BitSafe look misleadingly large. This one gives a better sense of scale:


My immediate goals for the firmware have concentrated on integration with other parts of the Bitcoin infrastructure.

• The deterministic wallet implementation now uses the (proposed) BIP 0032 specification. This should allow wallets to be imported/exported across other BIP 0032-compatible Bitcoin clients.
• The wire protocol is being changed to make it more similar to that of slush/stick's Trezor. This should make it easier for Bitcoin clients to support hardware wallets in general.
• I began working on a P2SH (multisignature) address generator, to facilitate secure multisignature reception of funds. However, I've put that on hold to focus on more basic use cases.

Finally, since the last update, a difficult but significant goal has appeared. Gavin Andresen proposed a secure payment protocol (see https://gist.github.com/gavinandresen/4120476) which makes address rewrite attacks much more difficult. The problem with asking "Send 0.0461 BTC to 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr?" is that an attacker could covertly rewrite this address and it is difficult for a user to determine whether a given address is genuine or not. With the proposed payment protocol, the prompt would be something like "Send 0.0461 BTC to mtgox.com?", where the name is validated using some sort of certificate chain.

Such a solution has been alluded to in this thread (see https://bitcointalk.org/index.php?topic=78614.msg880376#msg880376) and elsewhere, but Gavin Andresen's proposal looks likely to become "the standard". So I would like to implement it.

[XcelR]

We have been looking through your project and your github. We are going to take on the task of Building our Own Hardware wallet for our Coin XcelR.

[Ente]

We have been looking through your project and your github. We are going to take on the task of Building our Own Hardware wallet for our Coin XcelR.

Resistance is futile.

[potificate]

Here's an update:

In October 2012, allten contacted me. He had designed some hardware but needed some firmware, while I had some firmware but only a hardware prototype. So we combined our efforts. He sent me a special development version of the BitSafe:

https://i.imgur.com/ylEx0PE.jpg
https://i.imgur.com/D1ERR5c.jpg

It's been ages since this has been posted.... what have you been up to? (Tried DMing you, but BCT still thinks I'm a noob and blocks me from such things.. I've been on for a while but mostly lurk.)

This was so amazing that you started this before anyone else... just curious what's been going on over the past 5 years. :-)

Potificate

[Pmalek]

It's been ages since this has been posted.... what have you been up to? (Tried DMing you, but BCT still thinks I'm a noob and blocks me from such things..

I doubt you would have gotten far by PMing the user. If you check his profile he has not been online since November 2017 - https://bitcointalk.org/index.php?action=profile;u=38146
Took a quick look at this posting history in search for an email or other way to contact him but couldn't find anything except for a few github repositories and dropbox links.

[potificate]

It's been ages since this has been posted.... what have you been up to? (Tried DMing you, but BCT still thinks I'm a noob and blocks me from such things..

I doubt you would have gotten far by PMing the user. If you check his profile he has not been online since November 2017 - https://bitcointalk.org/index.php?action=profile;u=38146
Took a quick look at this posting history in search for an email or other way to contact him but couldn't find anything except for a few github repositories and dropbox links.

Oh man.. that's such a shame considering such important work. Thanks for looking!