On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote:
> The other serious problem - and this is a problem with smartcards in > general > anyway - is that without Bitcoin-specific logic you're just signing > blindly; we > recently saw the problems with that with the Bitfinex/BitGo hack. And even > then, without a screen most of the hardware wallets in are still just > signing > blindly, with at best hard-to-use limits on maximum funds moved > per-transaction. Also note how even hardware wallets with a screen, like > Trezor, aren't yet able to authenticate who you are paying. > "Welcome to my threat model." In multisig scenarios, there must be a different "trust root" for each key. For example, storing two private keys next to each other on the same web server is broken because if one key is compromised it is infinitely trivial to compromise the second key. Using multiple web servers is also broken if the two servers are controlled by the same AWS keys or same "help me get my servers back" support email request to whatever single sign-on service is used. In some cases, it can be better to write software such that transaction data is served at a particular location, and another security-critical step is responsible for downloading that data from the first machine, rather than the first computer directly pushing (with authentication credentials in place for the attacker to compromise) the data to the second computer. I recommend using hardware security modules (HSMs). It's important to have a public, reviewed bitcoin standard for hardware wallets, especially HSMs. I expect this is something that the entire industry has a tremendous interest in following and contributing to, which could even lead to additional resources contributed (or at the very least, more detailed requirements) towards libconsensus work. Instead of signing any bitcoin transaction that the hardware wallet is given, the hardware should be responsible for running bitcoin validation rules and business logic, which I recommend for everyone, not only businesses. Without running business logic and bitcoin validation rules, the actual bitcoin history on the blockchain could be a very different reality from what the hardware thinks is happening. Using a different out-of-band communication channel, the hardware could query for information from another database in another trust root, which would be useful for business logic to validate against. As for a screen, I consider that somewhat limited because you only get text output (and I don't know if I can reasonably suggest QR codes here). With a screen, you are limited to text output, which can compromise privacy of the device's operations and info about the wallet owner. An alternative would be to have a dedicated port that is responsibly only for sending out data encrypted to the key of the wallet owner, to report information such as whatever the hardware's transaction planner has decided, or to report about the state of the device, state of the bitcoin validation rules, or any accounting details, etc. Additionally, even a signed transaction should be encrypted to the key of the device owner because a signed transaction can be harmless as long as the owner still has the ability to control whether the signed transaction is broadcasted to the network. It's "separation of concerns" for transaction signing and decrypting a signed transaction should be unrelated and uncoupled. Also I am eager to see what the community proposes regarding signed and authenticated payment requests. ((insert here general promotional statement regarding the value of reusable checklists used during every signing ritual ceremony)) - Bryan http://heybryan.org/ 1 512 203 0507
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
