BitStash

Bitcoin Hardware wallet requirements

When designing BitStash I created this list to serve as a checklist of the features that are mandatory for a complete & secure bitcoin hardware wallet solution. BitStash has been designed to meet each one of these items.

1. Must provide a secure operating environment, exposing a limited set of secured operations, with no ability for malware to be loaded on device.
2. Must keep private keys and or seed secure within the device. Encrypt keys and or seed, and use pbkdf2 extension to prevent rainbow table attacks. Do this even if persistent storage/memory on the hardware is considered trusted/secure.
3. Must have a secure, truly random source of entropy for key / seed generation.
4. Must be capable of producing secure backups for recovery purposes. This process must not be capable of being comprised by malware infected client computer.
5. Recovery procedure must be entirely secure, and not have weaknesses exposed by malware driven clients.
6. Must be capable of signing transactions of arbitrary size, without restrictions on the number of UTXOs or inputs.
7. Must support P2SH, multi-sig transactions.
8. Must not generate weak signatures. ECDSA signatures have a weakness, wherein repeated R values leaked to the blockchain allow for private key theft. When signing transactions device must generate k, from which R is derived, in such a way that k is always unique. Some RNGs cannot guarantee this. Preferably, use RFC 6979 as an approach to deterministically guarantee unique k.
9. Must prevent malware miner fee attacks by validating, on the device, UTXO source transactions. More complicated than it sounds, since source transaction size is outside the control of the user, so potentially multi-megabyte transactions need to be validated by independently hashing TXs on the hardware device. Solving this problem with a user friendly, simple to use solution.
10. Must prevent malware address attacks, that is be capable of validating addresses that bitcoin is being sent to are the intended addresses the user wants. Preferably this also means also including Bip70 payment protocol support, validating the certificates associated with a payment transaction on the device.
11. Provide two factor authentication or entirely air gapped PIN/Password entry to prevent key logged malware access.
12. All data on the device needs to be secure from physical tampering and electronic side channel attacks. Preferably physically destroying chips to prevent sophisticated recovery attacks. See FIPS 140–2 level 4.
13. Device should remain secure in the event of theft. So PIN entry back-off algorithms, sleep modes and self destruct features required.
14. Device should enforce an authentication proof that it is YOUR device and not some other malware device that has been substituted in an attempt to acquire your credentials. This proof should be a cryptographic signature and not just a name tag displayed on the device.
15. If the device’s firmware is upgradeable, the device needs to protect against malware driven, non authentic firmware updates.
16. Provide for a seamless, easy to use end user experience, capable of being executed by non technical users. Critical for mass adoption of solution.
17. Not require the use of a Third Party service to operate, for both privacy and business continuity reasons.
18. Provide robust client device and user authentication features, such as cryptographic signatures.

In the case that the hardware wallet is to be used in an enterprise environment, then it might also provide allow for smart card authentication & authorization procedures.

https://bitcointalk.org/index.php?action=profile