Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices

[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")