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 project

BTChip 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 :

• Latest firmware documentation always available on https://btchip.github.io/btchip-doc/bitcoin-technical.html or https://github.com/btchip/btchip-doc
• C APIs : https://github.com/btchip/btchip-c-api
• Java APIs : https://github.com/btchip/btchip-java-api
• Web APIs (Chrome / Chromium only) : https://github.com/btchip/btchip-js-api - sample : KryptoKit integration https://github.com/btchip/btchip-kryptokit
• Python APIs : https://github.com/btchip/btchip-python

Updates are always posted on twitter : https://twitter.com/btchip

User tutorials :

• gdassori : https://bitcointalk.org/index.php?topic=787418

User reviews :

• Coding In My Sleep : http://codinginmysleep.com/hands-on-with-btchips-hw-1/
• Bitvoid : http://bitvoid.net/btchip/
• BitcoinInformation : https://bitcointalk.org/index.php?topic=134999.msg8819383#msg8819383
• Gabridome : https://bitcointalk.org/index.php?topic=782875.0

-------------------------------------------------------------------------------------------------------------------------------------------------------------------


(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 wallet

First 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.com

1.4.4 firmware specification

This 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 GlobalPlatform

The 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 architecture

We 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 instead

The 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 malware

Creating 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  

Kick ass! Read half of your post and had to comment 

(goes back reading...)

Hi, sure. First you cut the shape in the center



Then you fold it



Then you can insert it




The basic use case is indeed very similar to an encrypted wallet, but offers some additional security in my opinion.

One thing is that once a malware obtains the passphrase to an encrypted wallet, it can grab the private keys and use them later without requiring any interaction from the user. Using a smartcard wallet, the malware can request the smartcard to sign something using those keys, as long as the smartcard is connected and agrees to sign (you could set a session based limit according to the number of outputs you plan to sign, for example, and after this the card would have been to be removed / inserted again to be operational, or other creative countermeasures).

The biggest difference is that the private key is never manipulated in a usable form by the host.

You could also make the malware attack less successful by using different encryption keys for the private keys, each one using a different PIN.


You can back it up, and it's very important to do so the idea is to generate the context keys (encrypting the private keys) on a trusted computer when you first use the card (or decide to create a new context key), and keep the Triple DES key value in a safe place (printed / gpg encrypted ...). Thus you can exchange keys between another client implementation and the smartcard if you wish.


I can see it fitting some space between the pure software approach and the hardware wallet for people wanting some additional security, as it's cheaper to produce and distribute. And rebrand, if you consider the BTChip form factor (f.e. a web based wallet providing this to its users). Also as a side note more secure if physically attacked.

Now if the consensus is that basic mode is not secure enough, then I'll see how this can be improved and we can discuss it.


yes it could do that, although it has a very limited storage capacity (on this version, 16 kb). Can you elaborate more on this ?

16 kilobytes. There are 66 Kbytes indeed, which are mostly used by the bitcoin patch in this implementation

so yeah, you'd be able to store a few private keys, too. It's just less convenient when the card is lost, and less interoperable with other clients.

another idea for a (stupid) countermeasure against malware : generate a one time pad, and when signing, ask the user for a random value.

ok I see, just for synchronization purposes. Yes, no problem doing that, creating extra files is already supported in the current version (and security restrictions can apply for read / update / delete access). I just need to map it in the client API.

Some news ...

Key pair generation and signature are both at 900 ms each now.

Rather than adding a new giant wall of text to this forum the specification for the upcoming new firmware release has been published on github :

btchip 1.4.1 firmware specification (do not use the table of contents on this link, clone it locally if you want to do that)

Description of the challenge mechanism used to authenticate addresses - I've tried my best to be confusing for an automated malware, and hopefully not too confusing for the user, but let me know  

Now development of the firmware goes on and the first integration of the new features (including some absolutely non nice UI to play the challenge game) will be done for bitcoinj.

OK, lets assume that I have no reservations against signing NDAs and developing wholy closed source. Could you please answer the following questions:

1) What is the cost of one complete development seat for the target platform?
2) Would the toolchain vendor even be willing to consider NDA from an one or two person shop (and no personal assets pledged) as valid?

Thank you very much. I was mostly courious if the situation had changed since the last time I researched it. Only costs went somewhat down, other than that things haven't changed much.

Is it possible to use two different keys in such a way that either of those keys could sign?
Just for the single key failover case / redundancy.
Hope it would act like duplicate door keys..

Contact Kim Dotcom. He has a job for you.