Revamped first post 
old first post content stays after the line below, for historical purposes only as the scope and supported features changed quite a lot - you don't need to read below the line if you're new to the projectBTChip is a bitcoin/altcoin hardware wallet in a USB smartcard - low cost, secure, and available now - buy from
https://buy.hardwarewallet.com (limited promotional offer, 2 cards for 20 €, payable in bitcoins)
See installation and setup instructions on
http://www.hardwarewallet.com - BTChip works out of the box with
GreenAddress (Chrome application & Android wallet) and
Electrum (upcoming release)
For developers :
Updates are always posted on twitter :
https://twitter.com/btchipUser tutorials :User reviews : -------------------------------------------------------------------------------------------------------------------------------------------------------------------
(Word of warning for people who got a sample at 29c3 and plan to attack it - there will be some chip spoilers during this post)Hi
Hardware bitcoin related projects look quite alive & kicking in 2012, which is great
here is my take on the topic of smartcard wallets, with a real world implementation
Smartcard wallet vs hardware walletFirst an hopefully unbiaised comparison between smartcard wallets and hardware wallets :
Pro smartcard wallet- Hardware security : making sure an attacker who got the device will have a very hard time extracting something useful from it. Also protection against side channel attacks, especially during known-to-leak cryptographic operations.
- Cost : not considering an additional reader, an initial target cost per unit between 0.5 and 1 BTC is realistic (not considering large volumes). Shipping costs will be lower too, as sending an hardware wallet in a simple letter envelope seems harder.
- Durability : limited failure options with a single hardware component.
Against smartcard wallet- Not Open Source : smartcard chips and associated toolchains are heavily covered by NDAs, which makes sharing the source a pain. It's of course possible to release an Open Source smartcard wallet application running on an open smartcard platform, but you still need to trust the platform.
- Limited protection against custom malware attacking bitcoin transactions : a hardware wallet will offer a display or buttons to review transactions. It is still possible to offer some protection against this in a smartcard as we will see, but not as extensively.
- Limited code options : modern smartcards f.e. SC000 based look more and more like typical microcontrollers, if you don't consider the RAM size - however that's still not what you get in a typical secure product. Moreover coding on an "open" platform such as Java Card limits you to what the cryptographic API can offer, which can be an issue for the bitcoin protocol (f.e. ECDSA signature is only offered over SHA-1 for one of the most recent Java Card version, considering the card supports ECDSA first)
BTChip project
http://www.btchip.com1.4.4 firmware specificationThis project started as a more or less 2 weeks hack of a generic smartcard OS to offer bitcoin friendly APIs. The initial motivation was to see if it could be done, and also the pleasure of tweaking a project initially dedicated to banking applications to support something outside the system
The chip used is an
ST23YT66 which is your regular smartcard microcontroller with a twist : USB support. Which means it can be directly connected into a USB port with no reader necessary.
It features an implementation
of the basic smartcard wallet described below an advanced smartcard wallet described in the specification, using USB HID as transport protocol - because it's more convenient than CCID for a general public application.
Here's the roadmap for the coming weeks, which will be updated as things get done :
Release the first samples at 29c3 - done- Improve the key generation & signing speed.
Target is less than 2s, maybe less than 1s Now 900 ms to generate the keypair / 900 ms to sign Maybe support the advanced wallet model (discussion below check the specification), but that's unlikely.- Support additional rich clients - so far there's a prototype for bitcoinj and integration into the official client is in progress. If you're a client developer and want a sample to play with, don't be shy and drop me a PM
- Support web clients -
even if Java security has been a bit controversial in the past months (and Java browser support turned into a sick joke on OS X) I've had good success with javahidapi running in an applet container and Java should still be available on public computers, so it can be a starting point. since I wrote this Java security got even worse (hats off to Oracle, that's quite an achievement), so browser plug-ins here we come 
Exposing hidapi through FireBreath is quite easy, so that's the preferred approach so far.
A few words about GlobalPlatformThe GlobalPlatform Card Specifications are a set of specifications implemented by most recent multi application smartcards - they define how the card applications and cryptographic materials are isolated, as well as how to establish a secure transport channel (Secure Channel - think TLS with authentication and optional confidentiality using only symmetric keys) between the card and an external entity.
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
Smartcard wallet architectureWe assume the user store a lot of keys, not necessarily related to each other (i.e. not necessarily generated by a deterministic wallet)
To support this model, no ECDSA key will be stored on the smartcard and the smartcard will only manipulate the private component of an ECDSA key (S, 32 bytes) in an encrypted form.
A key used to encrypt private component of an ECDSA key is called a
Context Key. Context Keys are stored on the smartcard itself and never revealed. The suggested encryption algorithm is Triple DES in CBC mode (because Triple DES capable cryptoprocessors are still way more common than AES capable cryptoprocessors nowadays on smartcard chips).
A bitcoin client stores the private key in an encrypted form along with the reference of the Context Key used to access it. It then sends SHA-256 hashes to sign to the smartcard for a non transaction aware smartcard wallet, or each component of the transaction to sign for a transaction aware smartcard wallet, along with the encrypted private key to sign with.
A Context Key can be associated to a specific GlobalPlatform Secure Channel. In this case, the user should be authenticated to the Secure Channel before being able to sign a transaction.
Basic smartcard wallet (non transaction aware)The basic smartcard wallet just knows how to generate a keypair over the bitcoin ECDSA curve, and sign something. It is not aware of anything else bitcoin specific, and does not need to support SHA-256 either.
The following APIs are defined :
Generate Keypair : takes a Context Key reference, generates a keypair over secp256k1, returns the public component of the key (W) and the encrypted private component of the key (S') using the Context Key.
Import Private Key : takes a Context Key reference and a cleartext private key component (S), returns the encrypted private component of the key (S') using the Context Key.
Sign : takes an encrypted private key component (S'), the SHA-256 hash to sign, and returns the ASN-1 encoded signature components.
Verify (optional) : takes a public key component (W), the SHA-256 hash to verify, the signature and returns ok or not ok.
Advanced smartcard wallet (transaction aware) (old version, check the posts below for the updated version)The following description is mostly outdated and kept only for reference - check the firmware specification insteadThe advanced smartcard wallet proposal uses a simple concept to defeat useful malware : all output addresses must be authenticated by the card when included in a transaction.
In this model, before starting a transaction you'd take the output addresses, provide them to the card to be encrypted on a trusted computer or a different platform, then go on with the transaction signing.
Two new type of keys are defined, the Address Key, which is used to encrypt an address, and the Secure Hash key, which is used to encrypt a SHA-256 context.
In this implementation the smartcard needs to support SHA-256 and optionally RIPEMD-160 if automated keys generation for change is desired
The following APIs are defined :
Generate Keypair For Change : takes a Context Key reference, an Address Key reference, generates a keypair over secp256k1, returns the public component of the key (W), the encrypted private component of the key (S') using the Context Key, and the associated encrypt address.
Encode Address : takes an output address, an Address Key reference and returns an encrypted address that the smartcard will authenticate later.
Secure Hash Generic : takes a generic part of the transaction which is not an Output script, a Secure Hash context (or nothing if creating a new hash), a Secure Hash key reference and returns an updated (or new) Secure Hash context. The Secure Hash context holds the context of the SHA-256 hash, encrypted by the smartcard. It is sent back to the host instead of being kept in RAM in case people are interested to have a distributed implementation. This function must validate the provided data i.e. make sure that no Output script can be hashed by this function (f.e. by fragmenting it into meaningless parts).
Secure Hash Output Script : takes an Output script, a Secure Hash context, a Secure Hash key reference, a list of encrypted addresses and associated Address Key references and returns an updated Secure Hash context. The Output script structure is parsed and only accepted if the given address matches one of the encrypted addresses passed.
Sign Secure Hash : takes an encrypted private key component (S'), a Secure Hash context, a Secure Hash key reference and returns the ASN-1 encoded signature components.
Protecting against custom malwareCreating multiple Context Keys can be effective protected by a Secure Channel can help fragmenting the risks for large wallets - supposing an all powerful malware grabbed the authentication key of the Secure Channel and can play transactions, the risks are limited to the private keys linked to this Context Key.
Another simple method to protect against custom malware using an USB implementation can be to rely on an annoying fact : powering off a USB device by software is painful. Using this model, we can choose to accept one signature per session and force the user to unplug/plug again the device for each signed output - a cheap way to check that no additional outputs were added, but requires free fingers to count and doesn't prevent a malware that'd just replace a legitimate transaction by a fake one rather than adding outputs to a legitimate one.
Feel free to comment and improve on this
Show Posts
