I have been developing the firmware. You can get it from: https://github.com/someone42/hardware-bitcoin-wallet. It's in a state of flux, as the surrounding Bitcoin infrastructure changes. At the moment I'm working on implementing an interface based on protocol buffers, so that I can make it "Trezor compatible" (eg. see https://bitcointalk.org/index.php?topic=125383.0).

Here is an entirely fictitious depiction of what is possible:

• You open multibit and plug the BitSafe into your computer. One of your greyed-out wallets becomes highlighted.
• You navigate to bitmit.com, and purchase something for 1.815 BTC. Multibit handles the Bitcoin URI and gives you a payment prompt.
• After approving multibit's payment prompt, a light flashes on the BitSafe and "Send 1.815 BTC to www.bitmit.net?" appears on the OLED display.
• You press the "approve" button on the BitSafe and the relevant Bitcoin transaction propagates to the rest of the Bitcoin network.

During this story, there is no opportunity for malware to intercept your private keys. Private key storage and transaction signing is done entirely on the BitSafe. Malware does not even have the opportunity to redirect funds to another address; using a proposed payment protocol (see https://gist.github.com/gavinandresen/4120476), addresses and amounts are signed by the merchant (in this case www.bitmit.net), authenticated by the BitSafe and displayed on its OLED display.

It gets better than this. You could encrypt your wallet so that if you accidentally lose the BitSafe, any finders will have a harder time accessing your wallet. "Deluxe" versions of the BitSafe might include a USB port which will allow you plug in a USB keyboard. You could then enter passphrases without fear of (software) keyloggers. Maybe you could even use this keyboard to enter a brainwallet passphrase; the Deluxe BitSafe generates, uses, and erases the brainwallet independently of the host computer.

Currently, the firmware implements a deterministic wallet based on the proposed BIP 0032 standard. So you would be able to do a wallet backup by writing a series of letters/numbers on a piece of paper. You would presumably place this paper in a physically secure location (eg. safe). If you lose the BitSafe or it breaks, you can entirely restore the wallet from this piece of paper.

Is there any chance you could open-source some of your contributions? For example, it looks like you did some significant work interfacing bitcoind with your wallet; as far as I know, no-one else has done that.

I understand that there may be licensing issues with some of the microcontroller code/libraries, but I think there's value in seeing your approach.

Here are some of my findings regarding USB HID-based communication. Perhaps they will be useful to anyone else working on interfacing with hardware wallets.

• The maximum throughput I've seen in either direction when using HIDAPI is 31500 bytes/s. This is fast enough to transfer most Bitcoin transactions instantly (from a user's perspective), but it is less than 3% of full-speed USB maximum throughput.
• There needs to be a way to identify hardware wallets. HIDAPI's hid_enumerate() function gives you a list of HID devices, but it includes things like keyboards and mice. USB device properties which HIDAPI can query include: vendor ID, product ID, manufacturer string, product string and serial number. Identification via. vendor/product ID is probably not a good idea because they're constrained by other factors.
• The latest version of HIDAPI available on https://github.com/signal11/hidapi/downloads (v0.7.0) is quite outdated. It has issues on Windows relating to report sizes (see https://github.com/signal11/hidapi/pull/28).
• For the CP2110-based protocol that slush has proposed, a long, repetitive HID report descriptor is required.
• On the device side, things are complicated by the fact that the HID specification allows reports to be sent/received from both the control endpoint and an interrupt endpoint. Both these methods have their own subtleties.

Some Windows XP-specific things:

• Windows will refuse to enumerate your HID device unless it provides a valid report descriptor. Windows will refuse to process reports unless that report is correctly described in the report descriptor. This is why that "long, repetitive HID report descriptor" is not just a good idea - it seems to be required for the interface to work at all.
• Upon success, HIDAPI's hid_read() always returns the size of the largest report, even if a smaller report was received. So its return value should be ignored and the report ID (first byte) should be used to determine the report size.
• Windows will eat up received reports even if hid_read() isn't being called.

Some Linux-specific things:

• HIDAPI provides two backends: one based on the hidraw kernel driver, and one based on libusb-1.0. Certain kernel versions have some hidraw bugs.
• No matter what backend is used, access to a USB HID device requires root permissions. Alternatively, udev rules can be used to whitelist certain devices. Care must be taken to write the whitelist filter so that it includes all hardware wallets.
• By default, when a USB HID device is plugged in, the hidraw driver will use "get report" control requests, presumably to initialise its view of the state of the device. This can end up eating up the first byte sent from the hardware wallet.

Here's my current understanding. It's subject to change, since analog circuits can work differently in the "real world" vs. theory.

Atmel CryptoAuthentication chip
Good: Tiny, integrated solution. This means board layout is easy (no touchy analog sections to worry about) and device size is a bit smaller. It is very likely to Just Work.
Bad: As slush has pointed out, Atmel don't say how it works. They say it's "high-quality" but don't justify it. There's no access to the raw samples, meaning that it could fail to produce enough real entropy, though it still outputs seemingly random bits.

Thermal noise source
Good: the existence of thermal noise is guaranteed by fundamental physics. The amplitude can be reasonably well estimated a priori. The particular design used (a differential amplifier) rejects common-mode noise somewhat. Noise characteristics are simple (white, Gaussian).
Bad: requires a lot of gain, which can provoke oscillation. High-valued resistors mean that it's sensitive to parasitic capacitance; this can cause bandwidth, unwanted feedback or (external) noise feedthrough problems. Requires board space for 3 op amps.

Zener noise source from zener diode
Good: components widely available. Requires less op amps than thermal noise source. Noise characteristics are probably distinctive, which makes it easier to distinguish zener noise from everything else.
Bad: noise amplitude is tiny, requiring even more gain than thermal noise source. Noise amplitude probably varies between components, complicating mass production. While zener noise is generally unavoidable, most manufacturers strive to reduce it.

Zener noise source from voltage reference
Good: Louder than zener diode. Probably more consistent than zener diode.
Bad: Once again, noise is usually unwanted by circuit designers, so chip designers try to minimise it. We had to look around for a chip which was noisy enough (the LM385 is used, which is an old chip). Voltage references aren't designed to be used as noise sources: they're designed to be used as voltage references. Slightly more expensive and bigger than zener diode.

Oh, I forgot this one: most microcontrollers have multiple independent oscillators (eg. crystal oscillator and internal RC oscillator). If both oscillators are run simultaneously, they will drift apart randomly. This drift can be measured using a suitable interrupt handler.

Drifting simultaneous oscillators
Good: you get it for "free": no external components required.
Bad: uncertain quality of random bits. Throughput is quite slow - last time I tried, I was only able to get a few hundred bits of (unknown quality) entropy per second.

Some resources:
The zener noise source circuit we borrowed from: https://mywebspace.wisc.edu/lnmaurer/web/minirng/RandomBit.jpg
Comparison of noise sources: http://ciphersbyritter.com/RADELECT/MEASNOIS/NOISMEA1.HTM

Fourtunately, X.509 verification is feasible, even with low-end microcontrollers. The overwhelming majority of X.509 certificates use RSA. RSA signing is indeed difficult, but verification is much, much easier. I estimate that verification of a 2048 bit RSA certificate is no more difficult than ECDSA (using secp256k1) signing.

As a very rough estimate, a modern but low-end 32 bit microcontroller should be able to generate a ECDSA signature in < 0.5 s.

It is possible to avoid using a PicKit 3. If the dev board is loaded with an appropriate bootloader (eg. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en554836), it should be possible to program the device using the on-board USB port.

What the PicKit3 is useful for, is if:

• You want to develop or modify the bootloader itself (if you mess up the bootloader, you could brick the PIC32, in which case you need a PicKit3 to recover).
• You want good integration with MPLAB.
• You want to use debugging features like breakpoints, watches etc.

The story is: we had a few ideas for hardware random number generators (the Atmel chip, thermal noise, zener noise from zener, zener noise from voltage reference). Instead of choosing one, all of them were included. There are a bunch of 0 ohm resistors to facilitate switching between circuits. The different generators have their own advantages and disadvantages.

It might be worth supporting (or perhaps even demanding) an OCSP stapling-like mechanism for certificate revocation checks. This would place the burden of OCSP querying on the merchant, who is typically better equipped to perform such queries. It also scales better, is potentially more reliable and does not leak information to a 3rd party.

How will signed invoices work with offline wallets? I ask this in the context of dedicated hardware wallets, but this issue also applies to cold-storage wallets on computers intentionally disconnected from the Internet.

Theoretically, basic verification of a signature is feasible. As long as an offline device is seeded with a sufficient set of root certificates, it can verify a valid chain of certificates. However, there are problems with certificate revocation. Ideally, certificate verification should be accompanied by revocation checks. For an offline device, checks are very difficult.

I am aware that even with no revocation checking, the security of offline devices is significantly enhanced by signed invoices. But is it possible to do better than this?

I'm not so sure that displaying the change address deals with the "malicious send to /dev/null" attack described above. For example, say the device displays "change of 0.05581992 BTC was sent to 1HoYQQeA3BxWisDK3VtGFNbvnNPcoZTE5n". How do you even know whether that's a "genuine" change address?

Perhaps a better solution is to display the change address index instead. There is an immediately apparent difference between "change was sent to address 18" and "change was sent to address 1156397331". But will users understand this?

Another option is to require change addresses to be explicitly and sequentially generated by the wallet. However, this does require an internal counter that is incremented every time a change address is generated. The malicious change address attack is prevented because the wallet is presumably unable to generate millions of change addresses in any reasonable time.

You can do this if you re-order the fields* in the protocol buffer messages to match the order of the Bitcoin protocol (inputs before outputs, previous output reference before input script etc.). Then, you send the entire transaction through once per required signature. Each time an output is encountered, you prompt the user about it. This is merely an extension of your "streaming" idea, but applied to the whole transaction.

You can probably see the problem with this: the user will be prompted repeatedly, for each required signature. This makes for an unnecessarily bad user experience. This is how I intend to deal with the problem in my implementation:
1. While processing the transaction, a hash for signing needs to be calculated. In addition to this "signing hash", calculate an "input invariant hash" which is just like the signing hash, except it ignores all input scripts.
2. The input invariant hash will be the same regardless of which input is being signed (that's why it's called the "input invariant hash").
3. If the user fully approves a transaction, save that transaction's input invariant hash.
4. Include a field in the SignTx message which specifies whether the required signature is for a repeat of the previous transaction.
5. If the host specifies that the transaction is repeated, do not prompt the user.
6. In order to stop the host from lying about the status of the repeated transaction, compare the input invariant hash of the current repeated transaction with the saved input invariant hash, returning a Failure message if there is a mismatch.

The host signs a series of inputs like this:

*This brings me to something which will probably be a non-issue, but we should be aware of: (according to https://developers.google.com/protocol-buffers/docs/encoding) field ordering in a protocol buffer message is not guaranteed. Every serialiser will write out fields in field number order, but certain operations may not preserve this ordering.

After having a closer look at nanopb's API, I withdraw any request for limited sizes of messages or fields. It is indeed possible to decode smaller chunks of messages. There is even a mechanism to decode smaller chunks of individual fields.

I'm not aware of any standard saying that protobuf parsers must skip unrecognised fields. In fact, modifying a parser to fail on unrecognised fields would make things more secure: it would protect against client software accidentally using an unsupported feature and then misleadingly reporting success to a user.

I agree that supporting OTP and PIN is a yes or no thing. But sometimes it is not so clear, and we can't anticipate what advanced features might be added to wallets in the future.

The ignore-on-0 convention would not encourage "unexpected state", as long as 0/false/"" is always defined to mean that a feature is disabled. For example, say an "is_hidden" field is added to the LoadDevice message. Wallets which do not support hidden volumes can safely ignore is_hidden = false. If such a wallet ever gets a message with is_hidden = true, it fails with a "feature unsupported" failure message.

Such a convention is safely used in microcontrollers, where reserved bits in peripheral hardware registers are often supposed to be set to 0. Then, if features are added to those registers, the designers will take 0 to mean disabled and 1 to mean enabled.

Edit: Here's a compromise: if a wallet sees an unrecognised field, it always fails with "feature unsupported", no matter what the value of the field. All new fields must be optional. If client software doesn't want to use a new feature, it must not include the corresponding fields.

I would like to propose the convention that if the wallet sees a field in a protocol buffer that it does not recognise, if that field is 0, false or "" (depending on the type of the field), the wallet can safely ignore the field. On the other hand, if an unrecognised field contains something other than 0, false or "", a wallet must not ignore the field and must return a "feature not supported" failure message. This convention makes it easier to add additional fields in the future.

As it stands, nanopb currently doesn't allow this (it skips all fields it doesn't recognise). But I'm sure it's possible to modify the runtime decoder to follow this convention.

I see the approach slush has taken is to include a "Features" message which enumerates a wallet's features. I think a features list is somewhat open to interpretation. For example, what happens if a wallet only supports a subset of feature X? Does it report that it supports feature X or not? Another advantage of the ignore-on-zero convention is that client software doesn't have to put as many ifs all over the place - "feature not supported" is handled like any other wallet error.

USB does have some error checking (one CRC16 per packet), so there's probably no need for us to implement it anywhere.

As for how to determine the packet boundaries, protocol buffers appear to lack a terminator. So length information must be out of band:
1. One option is to include the length of the packet somewhere. For example, the length (eg. as a packed, little-endian 32 bit integer) can be prepended to the protocol buffer.
2. Another option is to rely on the chunk lengths. When you see a chunk with less than 63 bytes of payload, you know it's the end. Note that if the packet length is a multiple of 63, to avoid confusion, an extra 0-payload packet needs to be sent as well.

Lastly, a bit of detail: how is the message type sent? A single byte prepended to the protocol buffer will do; but does anyone have a better solution?

I was mistaken about FTDI drivers on Windows.

Looks like it is USB HID then.

I was going to come here and whinge about your choice of protocol buffers, but after a bit more research, I'm liking them more. Their encoding is quite lean; I was worried that it would be like XML. Also, there are tiny parser libraries (eg. nanopb) written in C out there.

So now I think it's a good idea to use protocol buffers. My only request is that, for all the non-signing messages, there is a maximum message size specified. A reasonable value would be something like 256 bytes. This allows buffers to be statically allocated (i.e. without the use of malloc). The limit cannot apply to signing messages, because transactions can be very large.

I'm don't mind which USB class device is used. I think the primary criteria is how easy it is to work with the most common combinations of programming languages and operating systems (which unfourtunately is a lot of combinations). The only other appropriate USB classes I can think of are HID and CDC (i.e. a serial port).

There are problems (you appear to be aware of them as well) with USB serial ports in Windows, notably the need to supply a .inf, and the bugginess of usbser.sys. I was going to work around these problems by instead emulating a FTDI USB-to-serial chip. Every major operating system has reliable drivers for the FTDI chips included, and the protocol seems quite simple (from looking at the Linux driver sources).

The advantages of implementing a serial port are:

• Easy to work with; often OSes allow you to treat them as a non-seekable file.
• It's possible to use common terminal programs to do debugging or firmware updating.

There's one major disadvantage: device discovery is hard. There's no easy, portable way to "know" what a serial port is connected to without sending something and waiting for the correct response.

I think USB HID is a good choice. Advantages:

• Allows you to choose a VID/PID (the FTDI emulation solution above requires you to use an FTDI VID/PID).
• Easy device discovery; just query the product descriptor string.

The only disadvantage I've come across in my research: apparently, in Linux, you need to detach a kernel driver in order to properly communicate with a HID class device. This can be done on most systems, but I worry that it will break on some Linux configurations. Please correct me if the situation is different now.

As lile has pointed out, the size of signatures can vary.

In particular, for uncompressed public keys, there is:

• a 25% chance each input is 179 bytes or smaller,
• a 50% chance each input is 180 bytes,
• a 25% chance each input is 181 bytes.

However, what makes a bigger difference is that if compressed public keys are used, each input is 32 bytes smaller.

If you want to set a conservative limit, 181 bytes per input + 34 bytes per output + 10 bytes seems like a good bet. This limit only applies to reasonably-sized (< 253 inputs and outputs) and standard (one signature required) transactions.

I wasn't very clear on the description of my method, but every hash can be calculated without having any transaction entirely in RAM.

You can go even further than this. If you send the entire serialised spending transaction once for each TxInput, you don't even need to store outputs. You can then have essentially unlimited inputs and outputs.

FWIW, here's approximately the method I use:
1. Supporting transactions (i.e. transactions whose outputs are being spent) precede the spending transaction in the data stream.
2. Supporting transactions are serialised as they would be in the blockchain.
3. The spending transaction is serialised as it would be in OP_CHECKSIG (with all inputs removed except for the signing input, which has its script replaced).
4. Before each supporting transaction, the output number of the output being spent is explicitly specified.

This allows the bunch of supporting and spending transactions to be parsed by a streaming parser. Each output in the spending transaction can be displayed and approved as it is parsed.

The supporting transactions are there to calculate the transaction fee. The parser does this to calculate the transaction fee:
1. For each supporting transaction, the hash of the transaction, tx_hash, is calculated.
2. For each supporting transaction, the nominated output (from (4) above) has its amount added to the transaction fee.
3. The list of tx_hash and output numbers is itself hashed into ref_hash_compare.
4. When the parser sees the spending transaction, it takes the list of input reference transaction hashes and input reference numbers and hashes them into ref_hash. ref_hash should == ref_hash_compare. This step is necessary to confirm that the correct supporting transactions are being included.
5. For each output in the spending transaction, the output amount is subtracted from the transaction fee.

BIP 0010 is relevant to this discussion. What do you think of BIP 0010? It might be a good idea to talk to etotheipi about it, if you haven't already.