Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 250. (Read 965789 times)

Yes, right. USB mass storage bootloader with asymmetric crypto check would be the way. But we have to consider very carefully whether is introducing another attack vector for such small benefit worth it.

I think it is possible, but security considerations are currently the most important. I'm not against such feature in the future, but it must be done properly to not introduce any backdoor. Still, the security concern is top priority.

It's possible for all of us to be right - allowing upgrades that come from insecure computers is definitely possible in the general case, but it may not be implementable with the specific hardware stick/slush are using. If there's a way to do it though, it definitely makes sense to do so - it'd significantly increase the value of the device (at least to me) if I knew it was somewhat future proof.

I think with the method Mike described, that's not the case. If a virus on the flashing computer attempted to flash a modified version of the firmware, the bootloader would reject it due to an invalid signature.

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.


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.


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


Not aplicable for deterministic wallets.


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

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

Yes.

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.

We are accepting donations at 1BitkeyP2nDd5oa647AjvBbbwST54W5Zmx

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

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.


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

Do you need some funds ?

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.

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

But the source code is open source right?

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.

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

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.

Discussion about Mike's proposal has been moved by moderators to new thread: https://bitcointalksearch.org/topic/off-topic-part-ann-trezor-bitcoin-hardware-wallet-138174 . Please continue in discussion there.
Alten - You suddenly become an author of that thread. Can you please rename it? :-)

My ideas about possible screens.

* Generate new address
receive "generate new address" command from USB
display "Generate address?" "OK/Cancel"
generate new and

display "Show priv key?" "OK/Skip"
display "Priv key" "" "OK/Cancel"
display "Address" "

" "Store/Cancel"
store and

transmit

to USB

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

* List addresses
receive "list addresses" command from USB
display "List addresses?" "List/Cancel"
loop through

[]
transmit

to USB
display "Address" "

" "Next/Cancel"
end loop

* Delete address
receive "delete address" command and

from USB
display "Delete address?" "OK/Cancel"
display "Address" "

" "Delete/Cancel"
delete

and its 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" "" "Confirm/Cancel"
store

* 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" "" "Confirm/Cancel"
verify
unlock device and continue

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