Monthly Archives: July 2014

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.

Two Factor Authentication with BitGo and Coinbase

Online wallets such as BitGo and Coinbase make Bitcoin much more approachable. That said neither seem to prioritize enabling two-factor authentication. This is surely an artifact of them trying to minimize account setup friction.

The net of this decision is that users have to know setting up two-factor authentication is a good idea and go spelunking for the setting in the account settings.

For technical users this maybe fine but for the less technical often times they either don’t know such an option even exists or don’t have the patience to find where this is done.

It might seem like an unfair criticism to suggest this is a bad approach since most banks and e-commerce sites don’t go make this experience much better but I think Bitcoin companies can and should do more.

If LinkedIn, Facebook and Twitter can remind us to improve our social profiles these high-tech financial institutions can remind us to improve our account safety.

UPDATE 07/28/14: Mike Belshe of BitGo points out that it may not be directly obvious but BitGo does actually require two factor authentication once you add a wallet to the account but since I did not attempt to create a wallet until the account was adequately secured I never observed this enforcement. This approach represents a decent trade-off for reduction of account sign-up friction and account security.

UPDATE 07/29/14: I should also point out that Coinbase does require you to use multi-factor if you use their vault feature. I personally think that they should still be encouraging non-vault users to use multi-factor though.

I would add that while these new wallet services are much easier to use than their predecessors I think there is still plenty of room for improvement and I am looking forward to seeing what they and the newer entrants to this space will bring to the table for users.

If you’re not familiar with the user experiences these two services check out these presentations that show you how to setup accounts with them: