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:
1. The smartcard stores a "context key" that is only known by the smartcard.
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;
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.
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?
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?
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).
