Introduction
In the last year or so in my current position, I’ve been fortunate enough to have some time to explore and experiment with smart card technology. In particular, I’m talking about smart cards based on the Java Card and Global Platform standards.
I now have a pretty solid understanding the above standards, and at this point, I have even developed some (small) custom Java Card “applets” as well as some changes to the open source “Coolkey” applet that my current organization uses to store its client PKI certificates and (most importantly) secure the associated RSA private keys. Red Hat has even been kind enough to check in some of my (small) changes to their applet.
Anyway, I still STRONGLY believe that smart card technology (or something similar with a secure element) is the only reasonably-secure way to distribute PKI certificates to end-users (and ensure the keys aren’t stolen by the first piece of desktop malware that comes along). Despite this opinion, I must say that the last 1.5 years of work in my job has consisted of MANY moments of horror; I’ve left my office multiple times in a state of semi-shock, after some random discovery where I’ve realized that smart card technology is actually much less secure than it seems to be on the surface.
Largely, my discoveries to this point have been specific flaws in vendors’ implementations of smart card technology and/or the card management systems themselves; however, the standards currently implemented by most card vendors and management systems also leave much to be desired. In particular, the “master keys” of most smart cards today are based on two-key TDES, which is pretty weak. Also, the SCP01 and SCP02 protocols (using the two-key TDES crypto) are also largely “home-grown” and therefore somewhat naive.
Fortunately, it appears that the Global Platform committee has been steadily pressing forward with modernizing the algorithms used in the underlying card management protocols, which should help improve the situation once card vendors and card management systems catch up and actually implement the newer standards. In particular, SCP03, which allows for AES-128 and AES-256 symmetric management secrets (derived from base “master keys” using NIST standard algorithms for key derivation) seems a lot stronger to me.
Existing Open Source Tools
When tinkering with smart cards, in my opinion, there are a few “must have” tools of the open source world that everyone should have:
- libglobalplatform / GPShell (http://sourceforge.net/projects/globalplatform/) – Useful for setting up SCP01 or SCP02 secure channel sessions with Global Platform compliant cards.
- Smartcard Sniffer (https://github.com/ea/smartcard-sniffer) – Useful for capturing raw APDU traffic generated by programs on MS Windows systems. This is helpful for gaining understanding of what all that “middleware” and “card management” software is actually doing to your cards under the hood. (On Linux systems, of course, you don’t need something like this tool because pcscd will do it for you.)
- GlobalPlatformPro (https://github.com/martinpaljak/GlobalPlatformPro) – I haven’t yet had time to tinker with this tool/library, but it looks like a fast-rising competitor to libglobalplatform / GPShell.
My (Minor) Open Source Contributions
I’ve always wanted to become involved with an open source project but never have known how to begin. One large benefit of my digging into smart card technology and some of these open source tools, is that I’ve finally had the opportunity to become a (very minor) open source contributor.
In particular, after emailing Karsten Ohme (the leader of the libglobalplatform / gpshell project) about the possibility of integrating the NSS library to GPShell (to add support for master keys stored on an HSM), Karsten granted me commit rights. While most of my tinkering has been done in a separate branch (as the code is not production-ready), I’ve stumbled upon and fixed multiple minor bugs in the globalplatform library, and I’ve been able to merge those fixes back into trunk.
In addition, in support of my research on smart cards, I created a command tool which I (unimaginatively) named “SCP01Intercept”, and I’ve committed it to SourceForge under the GPL (see http://sourceforge.net/projects/scp01intercept/). This tool is a sort-of “poor-man’s wireshark” for smart cards; you feed it a sequence of APDUs that were sent to a real smart card and also feed it the GP keys for that smart card. The tool then “follows” any GP SCP01 “secure channel” session establishments, independently derives the SCP01 session keys for the session, and decrypts/outputs the encrypted command APDUs (sent within that session) for you. This can be incredibly useful for determining how your smart card management system of choice is working (provided you know the master keys for your smart cards).
Finally, if I’ve held your interest this long, you may also want to take a look at the few (very simple) github repositories that I’ve started. In particular, my coolkey_globalplatform repository is an initial attempt by me to add support for the newer Global Platform 2.1.1 and 2.2.1 Java Card APIs to the Red Hat “Coolkey” Java Card applet.