[ESHOP launched] Trezor: Bitcoin hardware wallet

[2112]

Have you considered adding support for a generic trusted path protocol so any server can send a message and get back an A/B answer in a secure manner?

Do you have any proposal how this should work? Actually device is able to sign bitcoin transactions (pay to address, pay to script hash) and sign bitcoin messages.

Yes. Consider the case of online voting. The voting server wants to ensure the following

a) The vote is cast by a human, not a virus.
b) The vote is cast by each human only once.

We can satisfy this use case by using Trezor like this:

• Each Trezor has a unique public key (can be RSA) and a certificate signed by the manufacturers, ie, you and stick.
• When you start the voting process, the Trezor sends its certificate to the computer, which then sends it on to the voting server.
• The server checks that this certificate has not been seen before, and then encrypts/signs a protocol buffer that includes a message to display onscreen (any arbitrary text) and the two options available. That signed message gets sent to the Trezor, which shows it on screen.
• The users answer is then signed with the devices private key and uploaded to the voting server which checks it against the public key in the certificate.

In this way, the server can know that no virus interfered with the communication and there is no fake device at work. Of course, it assumes that the devices are somewhat secure against physical tampering.

If you can already sign/verify text messages in the standard way, then I guess you could add it on top of that, though the need to communicate certificates and things makes it not really necessary to re-use something designed only for text.

You don't have to do this now. As the software is open source, somebody could contribute such a protocol and then you incorporate it into your signed builds.

One trezor, one vote!

Slush, if you are going to start a political party, remember that I was always your friend. Hopefully my trezors will have low serial numbers.  

[Mike Hearn]

. . . Mike now goes on to reinvent representative democracy.

Haha, thanks Actually that's an old interest. Here's a paper I wrote about 6 years ago:

https://docs.google.com/document/d/1jidmNJHWAtsPLCUD7EPPm8jOEV93kSXbZOMycqCWOyA/edit?authkey=CN7BnLUG&authkey=CN7BnLUG

It covers how to use secure hardware to build a new kind of democracy where votes can be delegated by topic up a tree of representatives. I think these days people call it "liquid democracy". I never did anything with the idea. The paper talks about smart cards but Trezor style devices are a better fit.

[molecular]

Not content with:
+ redefining the nature of money, see bitcoinj
+ reimagining the meaning of property rights, see video presentation of Bitcoin London 2012

. . . Mike now goes on to reinvent representative democracy.

Please, for the love of God, can someone stop this guy before he redefines the very essence of reality and/ or space-time and we all become - well - the mind boggles.

:-)

yo jim, don't give him ideas!!

[slush]

[BOUNTY] 2 BTC - logo for Trezor: Bitcoin Hardware Wallet ;-)

[stick]

You don't have to do this now. As the software is open source, somebody could contribute such a protocol and then you incorporate it into your signed builds.

Yes, this is very nice concept but currently out of our project's scope. As you write, once the Trezor is released, it is a matter of rather small firmware modification ...

[commonancestor]

My ideas about possible screens.

* Generate new address
receive "generate new address" command from USB
display "Generate address?" "OK/Cancel"
generate new <priv key> and <address>
display "Show priv key?" "OK/Skip"
display "Priv key" "<priv key>" "OK/Cancel"
display "Address" "<address>" "Store/Cancel"
store <priv key> and <address>
transmit <address> to USB

* Sign transaction
receive "sign transaction" command and <unsigned tx> from USB
display "Sign transaction?" "OK/Cancel"
parse <unsigned tx> values <amount>, <fee>, <send-to addr>, <send-from addr>[]
display "Send-to addr" "<send-to addr>" "OK/Cancel"
display "Amount" "<amount>" "OK/Cancel"
display "Fee" "<fee>" "Sign/Cancel"
sign <unsigned tx> using stored private keys for <send-from addr>[] into <signed tx> (what if some send-from addresses are not in the wallet?)
transmit <signed tx> to USB

* List addresses
receive "list addresses" command from USB
display "List addresses?" "List/Cancel"
loop through <address>[]
transmit <address> to USB
display "Address" "<address>" "Next/Cancel"
end loop

* Delete address
receive "delete address" command and <address> from USB
display "Delete address?" "OK/Cancel"
display "Address" "<address>" "Delete/Cancel"
delete <address> and its <priv key> from storage

Maybe there could be also a PIN security feature for the device. The PIN would be a hexadecimal number entered in a binary form.
Once the PIN is set, the device auto-locks when disconnected or after some period of inactivity, and then it needs to be unlocked next time.

* Set PIN
receive "set pin" command from USB
display "Set PIN?" "OK/Cancel"
display "1111 0111 10*_ ___" "F 7 8 _" "0/1" (enter 16 binary digits)
display "Setting PIN" "<pin>" "Confirm/Cancel"
store <pin>

* Unlock device
receive any command from USB when the device is locked
display "Unlock device?" "OK/Cancel"
display "1111 0111 10*_ ___" "F 7 8 _" "0/1" (enter 16 binary digits)
display "Unlocking device" "<pin>" "Confirm/Cancel"
verify <pin>
unlock device and continue

[slush]

Discussion about Mike's proposal has been moved by moderators to new thread: https://bitcointalk.org/index.php?topic=138174.0 . Please continue in discussion there.
Alten - You suddenly become an author of that thread. Can you please rename it? :-)

[slush]

Is this going to have a re-writeable firmware? I thought it was going to be fused to allow only a single access to the memory for backup purposes. Maybe I'm thinking of another project.

Yes, devices will have locked firmware for security reasons. We need to freeze feature set for the first release (otherwise we never release any product), but hopefully we will continue in the development, so such extra features will come with next versions.

[novusordo]

Is this going to have a re-writeable firmware? I thought it was going to be fused to allow only a single access to the memory for backup purposes. Maybe I'm thinking of another project.

Yes, devices will have locked firmware for security reasons. We need to freeze feature set for the first release (otherwise we never release any product), but hopefully we will continue in the development, so such extra features will come with next versions.

Just to make sure I'm understanding this right... the firmware will be "locked", but updatable?

[slush]

Just to make sure I'm understanding this right... the firmware will be "locked", but updatable?

Chip is updatable, but once it is locked, firmware cannot be changed anymore. For security reasons chips will be locked before shipping and casings will be sealed with custom hologram. Casings are not designed to be openable (without heavy damage). All this is to prevent malicious modification of device during distribution from the manufacturer to the customer.

[hazek]

Just to make sure I'm understanding this right... the firmware will be "locked", but updatable?

Chip is updatable, but once it is locked, firmware cannot be changed anymore. For security reasons chips will be locked before shipping and casings will be sealed with custom hologram. Casings are not designed to be openable (without heavy damage). All this is to prevent malicious modification of device during distribution from the manufacturer to the customer.

But the source code is open source right?

[World]

Just to make sure I'm understanding this right... the firmware will be "locked", but updatable?

Chip is updatable, but once it is locked, firmware cannot be changed anymore. For security reasons chips will be locked before shipping and casings will be sealed with custom hologram. Casings are not designed to be openable (without heavy damage). All this is to prevent malicious modification of device during distribution from the manufacturer to the customer.

maybe for the first series you can offer special editions along with engraving

[Mike Hearn]

Wait, so the firmware can't even be reflashed to new signed builds? That seems like a pretty important feature for future-proofing. Otherwise you'll have to physically sell new devices whenever you add software features.

The usual way to implement that is have the locked firmware just contain a bootloader that verifies the signature on the next part of the code, and have that code loaded from reflashable memory. Sometimes the firmware has features like rollback prevention so a bad guy/virus cannot downgrade code to a known vulnerable version.

[StarenseN]

Do you need some funds ?

[caveden]

Wait, so the firmware can't even be reflashed to new signed builds? That seems like a pretty important feature for future-proofing. Otherwise you'll have to physically sell new devices whenever you add software features.

I was expecting it to be this way. It's like a hardware, if you want an upgrade, buy a new one. It can't be more secure than that.

The usual way to implement that is have the locked firmware just contain a bootloader that verifies the signature on the next part of the code, and have that code loaded from reflashable memory. Sometimes the firmware has features like rollback prevention so a bad guy/virus cannot downgrade code to a known vulnerable version.

Although that's already more secured than any solution we currently have available, you'd have the risk of someone silently stealing the signing key and using it to infect some devices. Once you discover you'd need to make a callback of the product, what's already awful. And until then the hacker may be able to steal quite some money.

I know that security experts like slush and his partner probably know how to secure a signing key very well, but why running the risk? This device is supposed to be so cheap that buying a new one every year or so would be perfectly feasible. Plus, once tens of thousands of bitcoins are being secured by Trezor wallets, and thus by its firmware signing key, attacking those who control such signing key in meatspace becomes quite profitable...

[stick]

Do you need some funds ?

We are accepting donations at 1BitkeyP2nDd5oa647AjvBbbwST54W5Zmx

And yes, the research and development cost time & money ... :-)

[Mike Hearn]

And what if a security vulnerability is found in the software? Am I supposed to buy a new one? Shouldn't the sellers bear that cost? Software upgrades are important. And yes, the signing key becomes more sensitive the more that are sold but there are definitely ways to mitigate that risk.

The DNSSEC root signing keys, for example, were split using Shamirs secret sharing technique and the pieces placed onto smart cards that were then held by various entities around the world. They are held in safes with all the usual techniques and each card is stored in a different way.

[slush]

But the source code is open source right?

Yes.

[stick]

And what if a security vulnerability is found in the software? Am I supposed to buy a new one? Shouldn't the sellers bear that cost? Software upgrades are important. And yes, the signing key becomes more sensitive the more that are sold but there are definitely ways to mitigate that risk.

To enable flashing feature you have to ultimately trust the computer you are performing flashing on. If there was such computer you would not need Trezor at all (speaking of average users not technical savvy people).

[slush]

* Generate new address

Trezor is based on deterministic wallets, so device itself don't need to have private key management. Device stores just initial seed and send master public key to the computer, so computer itself can generate new bitcoin addresses for receiving money.

* Sign transaction

The workflow is bit more complicated than this. Firstly, it's not wise to allow signing of custom transaction provided by the computer, because making 100% bulletproof script parser is pretty hard. Trezor has native support for "pay to address" and "pay to script hash" scripts, which are currently the only scripts used in bitcoin world. So computer ask Trezor to build transaction with given inputs and outputs and Trezor make tx template itself.

Second problem is memory limits of such devices. We'd like to support teoretically unlimited amount of inputs and outputs per transaction, so sending everything in one message is non feasible. We've proposed "streaming API", method how to pass necessary information to Trezor and still keep memory footprint very low. Please read https://github.com/slush0/bitkey-python/blob/master/docs/signtx_workflow.png and https://github.com/slush0/bitkey-python/blob/master/protobuf/bitkey.proto for technical details.

* List addresses

This is unnecessary, because thanks to deterministic algorithms (BIP32, Electrum), computer itself can generate public keys for given seed.

* Delete address

Not aplicable for deterministic wallets.

Maybe there could be also a PIN security feature for the device. The PIN would be a hexadecimal number entered in a binary form.
Once the PIN is set, the device auto-locks when disconnected or after some period of inactivity, and then it needs to be unlocked next time.

PIN is there already. When user put invalid PIN, device will sleep for few seconds. Device also asks for OTP (one time password) *before* asking for PIN, so brute force won't be possible at all, because for every PIN attempt, user will need to rewrite OTP from the display to test new PIN...