(Fry really wants to buy something)
I plan to keep talking
while taking your money, how cool is that ?
Cool project!
I am new to this thread, so please excuse me if I'm slow
but I want to make sure I understand the basic idea behind BTChip:
No problem, welcome ! Also the whole thread is quite outdated and the technical description got stuck 2 years in the past, but let's see
The best up to date references are the API
https://btchip.github.io/btchip-doc/bitcoin-technical.html and C API
https://github.com/btchip/btchip-c-api1. The smartcard stores a "context key" that is only known by the smartcard.
This was the old architecture when I couldn't generate BIP 32 keys. Now the "context key" only applies to "trusted input" - only a way to bind an amount to a prevout by having the card sign a specific output of a transaction.
2. The smartcard can:
a. read a cleartext private key, and return the cleartext public key and the "context key"-encrypted private key;
b. generate a new keypair internally, and return the cleartext public key and the "context key"-encrypted private key;
yup. Still, for the old version.
3. The smartcard can also:
a. decrypt a "context key"-encrypted private key (from the user) and use that to sign a hash (also from the user)
b. verify an ECDSA signature.
Still correct (also still for the old version). The new version fully parses the transaction.
I know there is a lot of advanced functionality, but did I get that right? This has applications (like you point out) such as signing bitcoin transactions on a local machine in such a way that the private key decryption and hash signing is done "offline." Another application is to produce signatures at brick-and-mortar stores to authorize certain transactions (assuming the merchant could determine a valid cyphertext private key).
I have a few questions:
You mentioned using the ST23YT66 secure smartcard microcontroller. Was this chosen instead of a regular microcontroller so that you could take advantage of the security provisions, cryptographic primitives and user identification methods without having to write your own?
yes, especially because it is hardened by design. also because we write operating systems for smartcards during the bitcoinless parts of our professional lives
You mentioned that "the smartcard wallet implementations will rely on GlobalPlatform concepts to define how keys are inserted into the card, authenticate the user to validate access rights to access specific keys, optionally authenticate the card responses." Is this basically ISO/IEC 7816? I can understand adhering up to ISO/IEC 7816-4 (ADPUs) and in your case ISO/IEC 7816-12 (USB), but since a custom reader application will always be required, is there a need to adhere to any other sections?
this was done because parts of an old version of the operating system was reused for a quick prototype - it's no longer the case now.
Basically, I am wondering if it would be possible to start with something like an ARMCore MCU, write firmware to support up to ISO/IEC 7816-4 (APDUs), add whatever cryptographic operations you need to Trezor-Crypto, and then define your own spec for "how keys are inserted into the card, authenticate the user to validate access rights to access specific keys, etc." This would allow everything to be open-sourced too, if that was your desire. At the same time, I think you'd still be compatible with the majority of smart-card readers currently deployed in the field (as they'd need an update to their application software anyways to interface with BTChip).
yes, and that's definitely the approach we're taking with one part of
http://www.prismicide.com/ - the other part being a 95.8% (insert another random % here) open Operating System working on a regular smartcard, which still has some benefits considering getting a sane crypto stack that's not trivially vulnerable to SPA/DPA is a hard problem, both on the IP and technical side, and preventing trivial information recovery from a generic purpose microcontroller that you can touch is also a hard problem
