Topic: Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices (Read 44615 times)

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

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://bitcointalksearch.org/user/someone42-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.

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

Resistance is futile.

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.

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://bitcointalksearch.org/topic/ann-bitsafe-hardware-wallet-now-shipping-152517.

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://bitcointalksearch.org/topic/m.880376) and elsewhere, but Gavin Andresen's proposal looks likely to become "the standard". So I would like to implement it.

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

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

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.

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

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.

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

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.

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

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.

Ping

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.

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.

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.

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?