So, yeah, they'd better test it a lot, and keep it simple.
+1
Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 250. (Read 966173 times)
+1
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?
What if there's a bug in the software that manages the breaks of your car? (many newer cars have electronic breaks, remember that Toyota scandal?)
Even if it was possible to update the firmware of such software, most people wouldn't be capable of. A recall would be necessary.
I'd expect the same for Trezor. If a critical bug is found, they should do a recall. So, yeah, they'd better test it a lot, and keep it simple.
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.
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.
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).
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.
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.
* 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.
Quote
* 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.
Quote
* List addresses
This is unnecessary, because thanks to deterministic algorithms (BIP32, Electrum), computer itself can generate public keys for given seed.
Quote
* Delete address
Not aplicable for deterministic wallets.
Quote
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.
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...
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).
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.
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.
Do you need some funds ?
We are accepting donations at 1BitkeyP2nDd5oa647AjvBbbwST54W5Zmx
And yes, the research and development cost time & money ... :-)
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...
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.
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.
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.
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?
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.
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?
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.
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? :-)
Alten - You suddenly become an author of that thread. Can you please rename it? :-)
Jump to: