Tag Archives: Smart Cards

Smart cards, PC/SC and Chrome

Smart cards have been around since 1974 and as a technology while they have expanded their capabilities they still work in very much the same way they did back then.

These cards expose a protocol represented in Application Data Units (APDUs), the devices themselves are typically connected to computers via smart card readers (either embedded or external) that communicate via PC/SC.

Shortly after PC/SC was defined a class interface for USB PC/SC devices was defined called CCID with devices that conform to this specification one does not need vendor specific drivers to interact with the PC/SC device.

Since Chrome 26 Google has supported an interface that allows plug-ins to interact with USB devices. While I have not looked at this interface in detail I do know that the Google Gnubby (aka FIDO U2F) uses this interface to interact with their devices. I also understand that the U2F devices are in simple JCOP cards with a Gnubby applet on them.

Based on the above it seems rational to believe a third-party (aka someone other than Google) should also be able to create a Chrome plug-in (which is nothing more than Javascript) that allows a web-page to interact with smart-cards.

This would when paired with a reasonable card-edge that supports secp256k1 enable Multi-signature Bitcoin transactions leveraging smart cards without the need for a “fat” client.

Smart cards, PIV, Bitcoin and secp256k1

I am thrilled to see Multi-sig (P2SH) getting adopted across Bitcoin industry it has the potential to significantly reduce the risks involve with storing Bitcoin online. With that said it is still dependent on software keys, which can be trivially stolen via malware and other attack vectors.

One way to address this risk is to move the keys off of the host and into a isolated computing environment like a smart card.

Hardware devices like the Trezor do this by creating a Bitcoin specific computing environment, which has a many benefits (like being able to enforce policy on the card and get trusted implementations of the whole Bitcoin stack) but they turn into single use devices as a result of this approach also.

An alternate or really complimentary approach would be to have a smart card (or USB token) that supports the same cryptography used in Bitcoin as well as other more commonly used algorithms.

The thing to understand about smart cards is that for the most part every one you see is a proprietary non-interoperable mess. This is a function card industry attempting fend off the race to the bottom by differentiating at the card protocol layer which resulted in devices that are based on “standards” yet are totally non-interoperable.

Where they do “interoperate” it is because middleware has been written to mask these cross-vendor idiosyncrasies. The largest case where this has not happened is in the PIV card-edge, which was defined by the US government as their standard for logical and physical access control.

This card-edge explicitly supports only two ECC curves ansip256r1 and ansip384r1. That said the mechanism the caller has to specify which curve to use is via numbers in IDs specified in SP800-78 that map to the algorithm to be used (see table 6-2 for those algorithms) one could squat on un-used IDs and have a card that could also support secp256k1. This means it is possible to extend a standard PIV applet to support storing and protecting Bitcoin keys also.

PIV has other limitations that make it not ideal for these scenarios, specifically the default ACL set for the cards are such that users can not create keys themselves. GoldKey a smart card vendor who’s product uses the PIV card-edge works around this by adjusting those ACLs and embedding an administrative key within their “driver” that enables key generation to happen when their driver is used.

The net of all of this is that one can reasonably create a smart card that supported all of the rich capabilities that are available to users of a PIV device and also support protecting Bitcoin wallet keys.

Hardware Based Key Management and Bitcoin

Hardware based key management solutions like Smart Cards and Hardware Security Modules provide a lot of value. Probably the most important being that the keys are moved out-of-process into a totally separate computer. This goes a long way towards protecting keys from being stolen via by malware or exposing keys to an attacker via software defects like happened with Heartbleed.

Depending on the device you choose you may also get:

  1. Third-party assurances that their cryptographic implementations and random number generators are sound which is incredibly hard to be sure of when you just pick something up blindly off the Internet.
  2. A verifiable supply chain with third-party assurances and audit trails the devices have not been tampered with.
  3. Hardware that makes it obvious it has been tampered with and is resistant to such attacks.
  4. Protection from side channel attacks such as Differential Power Analysis, Electromagnetic Leakage and Timing Attacks.
  5. Basic policy enforcement mechanisms like preventing keys from being exported, limiting which users can use them and requiring M of N users approve.
  6. Mechanisms to securely clone keys from one device to another to improve survivability of failure and compromise.
  7. Some devices support the concept of “Remote Pin Entry Devices” so that the cryptographic device can be stored in one location but the tokens used to approve an operation to happen with the keys managed by it can be located anywhere on the globe.

Despite how valuable these solutions are they are not without their shortcomings one of which is that for the last twenty years they have not changed much short of getting faster and adding support for newer mandated algorithms.

One of the reasons these devices have not changed is that Common Criteria (CC) and FIPS 140-2 verification, the standards they must conform with to be sold to their largest customers, make it excruciating hard to change and as such the incentive model is set up to discourage innovation and often encourage bad behavior.

These restrictions also have resulted in them not supporting algorithms not mandated by these standards this means in the case of Bitcoin the decision to use secp256k1 in the protocol precludes their use or limits their use to a limited feature set and significantly reduced performance.

Additionally since PKCS#11 (the library one uses to work with these devices) doesn’t specify how to generate a secp256k1 key any code written to use such device ends up being proprietary.

The net-effect of this is if you buy one of these devices your going to be spending $5,000 for a device that gives you some of the above properties that you can write custom software on that would be able to do about 24 secp256k1 operations a second.

This is more than enough for a personal wallet but nowhere near enough for an exchange or payment provider; which means these vendors, are not using these sorts of techniques to keep your keys safe.

There have been a number of solutions that have been started by individuals to bring some of these protections to Bitcoin to-date they are all incomplete, unusable, unmaintained or not available.

The most promising being the Trezor but based on what we know of these systems its seems very unlikely they will provide the kind of protection one gets from a commercial hardware security module or many of the other features these devices often have.

And even if they do since they are for the most part by individuals with limited resources who knows if they will be around or available a year from now? If you have lots of Bitcoin in these devices and the vendor goes down or the device fails what are you to do?

That is not to say this these projects are not good, in-fact I will order a Trezor once they start taking orders again but they should be thought of as a Wallet and not a Safe or Vault as they will not protect from a well healed attacker and without much more work are not appropriate for cold-wallet storage of large amounts of Bitcoin.