Well this has been an interesting project.
It all started with a need to get better password storage at work. We wound up looking heavily at a GPG-based solution. This prompted the question: how can we make it even more secure?
Well, perhaps, smartcards. The theory is this: a smartcard holds your private keys in a highly-secure piece of hardware. The PC can never actually access the private keys. Signing and decrypting operations are done directly on the card to prevent the need to export the private key material to the PC. There are lots of “standards” to choose from (PKCS#11, PKCS#15, and OpenPGP card specs) that are relevant here. And there are ways to use SSH and OpenVPN with some of these keys too. Access to the card is protected by a passphrase (called a “PIN” in smartcard lingo, even though it need not be numeric). These smartcards might be USB sticks, or cards you pop into a reader. In any case, you can pop them out when not needed, pop them in to use them, and… well, pretty nice, eh?
So that’s the theory. Let’s talk a bit of reality.
First of all, it is hard for a person like me to evaluate how secure my data is in hardware. There was a high-profile bug in the OpenPGP JavaCard applet used by Yubico that caused the potential to use keys without a PIN, for instance. And how well protected is the key in the physical hardware? Granted, in most of these cards you’re talking serious hardware skill to compromise them, but still, this is unknown in absolute terms.
Here’s the bigger problem: compatibility. There are all sorts of card readers, but compatibility with pcsc-tools and pcscd on Linux seems pretty good. But the cards themselves — oh my. PKCS#11 defines an interface API, but each vendor would provide their own .so or .dll file to interface. Some cards (for instance, the ACOS5-64 mentioned on the Debian wiki!) are made by vendors that charge $50 for the privilege of getting the drivers needed to make them work… and they’re closed-source proprietary drivers at that.
Some attempts
I ordered several cards to evaluate: the OpenPGP card, specifically designed to support GPG; the ACOS5-64 card, the JavaCOS A22, the Yubikey Neo, and a simple reader listed on the GPG smartcard howto.
The OpenPGP card and ACOS5-64 are the only ones in the list that support 4096-bit RSA keys due to the computational demands of them. The others all support 2048-bit RSA keys.
The JavaCOS requires the user to install a JavaCard applet to the card to make it useable. The Yubico OpenPGP applet works here, along with GlobalPlatform to install it. I am not sure just how solid it is. The Yubikey Neo has yet to arrive; it integrates some interesting OAUTH and TOTP capabilities as well.
I found that Debian’s wiki page for smartcards lists a bunch of them that are not really useable using the tools in main. The ACOS5-64 was such a dud. But I got the JavaCOS A22 working quite nicely. It’s also NFC-enabled and works perfectly with OpenKeyChain on Android (looking like a “Yubikey Neo” to it, once the OpenPGP applet is installed). I’m impressed! Here’s a way to be secure with my smartphone without revealing everything all the time.
Really the large amount of time is put into figuring out how all this stuff fits together. I’m getting there, but I’ve got a ways to go yet.
Update: Corrected to read “signing and decrypting” rather than “signing and encrypting” operations are being done on the card. Thanks to Benoît Allard for catching this error.
I am currently going through the same journey. Your blog really helped a lot. I live on an island so I have to be cautious what I order. Returning it is generally not an option.
I had my mind set to buy a couple of ACOS5-64 and a card reader to test. But you said: “The ACOS5-64 was such a dud”. Can you expand on that some more please?
Sure. The ACOS5-64 isn’t supported by OpenSC or any other drivers on Linux. It comes with no drivers at all, in fact, and AFAICT the only way to make it work is to pay $50 for their client software kit.
It’s not worth that kind of hassle.
News,
There is a new project to support ACOS5-64 for Linux. You can find it here : https://github.com/carblue
I confirm referring to ACOS5-64, except, currently ACS charges for e.g. CryptoMate Nano Client Kit $59 + ?? non-negligible shipping cost and 1 Nano USB Token is included. For cards, there is another “Client Kit with some cards included”.
Don’t ask me, if I ever would buy a “client kit” again.
At the time of buying the precursor CryptoMate64 + client kit for my Windows-oriented employer, the situation regarding Linux was this: The client kit was (same as today) for Windows only! Asking the ACS support for a PKCS#11 Linux library revealed:
“I am afraid you have to undergo development such that it can work for Linux …”. That’s exactly what I’m doing now; it’s very interesting/challenging but not easy. More than 50% of OpenSC support is done already. The next big step close to finalization is ‘card-initialization’, as my vendor’s client kit does this absolutely wrong. Thus, depending on what’s on a user’s card/token, if it’s PKCS#15 conforming or not, my driver for OpenSC may be usefull right now already for some tasks or after step ‘card-initialization’.
IMHO the problem with ACOS5-64 (at least for Linux) is the middleware/driver/tools software (only). The hardware and card OS is not that bad, (maybe under the pressure of the FIPS 140-2 Level 3 certification process, they went through) the current ACOS5-64 v3.00 got better than the v2.00 of CryptoMate64, though still they didn’t muck out stuff that’s close to being/or already discharged like DES, SHA1 and TDES. But there are alternatives.
And a remark referring to the article’s reality-section opposed to theory:
My concern is, that an attacker might not need to crack into and steel secrets from a smart card, but much simpler just use them, when the ‘door’ is open: An application using a smart card, that You have to trust (like Thunderbird and others) quickly asks for the PIN/authorization and OpenSC even might cache the pin credential for X future uses, but the user doesn’t get informed about the actions going on with credentials revealed. And who knows, which malware comes pickaback with the trusted ones and goes right through an open door. Worse, e.g. Thunderbird keeps this door open as long as it is executing, same with ssh-add as long as it is connected with a module, maybe others behave the same.
CryptoMate64 has an LED that indicates, if some software keeps it busy with commands or not. Sometimes, some false alarm may come from the PC/SC layer, but I learned how to turn this off: Just start e.g. gscriptor without connecting and quit again, and You know, if there is real traffic.
My resume: I’m a fan of an additional user confirmation to actually allow key usage (at least for signature purpose, i.e. where harmful actions might occur) and not to base any smart card security aspect on a pin only.
Also, I personally won’t trust any security related software that isn’t open source.
carblue
Hey I know this is an old post, but I really need some help. I purchased the JavaCOS A22 based on this post and I cannot get it working no matter what I try. Do you remember still how you did it?
Using globalplatform pro with a cap file downloaded straight from yubico, it loads the cap file, but then prints “INSTALL [for install and make selectable] failed: 0x6985 (Conditions of use not satisfied)” and it doesn’t work with gpg or openkeychain after this.
I have noticed you don’t monetize complete.org, don’t waste your
traffic, you can earn additional bucks every month with new monetization method.
This is the best adsense alternative for any type of website (they approve all sites), for more info simply search in gooogle: murgrabia’s
tools