There was a recent Economist piece on Estonia's lead over the rest of the world on a national identity solution. Although not directly related to the following, the article got me curious about smartcards (again).
I find the existing crude practice of passwords very unsettling. We, as users, can mitigate the risk somewhat by choosing strong passwords and using unique ones for every account. However, the local PC/smartphone environment is far from secure and yet we are largely forced to enter and store these passwords within this insecure environment. Once the password is leaked, it becomes 'carte blanche' for any unscrupulous individual
What is desirable is to: 1) have physically separate hardware storing the credentials and 2) employ some sort of challenge authentication handshake where the secret itself is never revealed.
Aside: #2 is particularly problematic, since for web-based applications it requires the cooperation and implementation effort of each of the web sites. I don't even attempt to address that problem in this write up, although it is critically important.
There are products that might at least partially fit the bill, but there is a dearth of good information. The following is based on my interpretation of information that I've found online. Depending on costs, I may purchase some devices for personal evaluation, but I have not yet done so. So, do not blindly regard the following as canon.
There is an ISO standard (ISO 7816) for smartcards that has been around for eons. It describes both a physical form factor and an electrical interface.
Caveat: "smartcard" does NOT necessarily mean a solution for the problem described above. It is a superset category that covers an extremely broad range of applications.
Given the age of the ISO standard, it should be no surprise that there are a plethora of incompatible "reader" adapters to connect an ISO 7816 smartcard to a PC. More recently, there appears to be a push to adopt readers that conform to the USB CCID specification. (What is maddening is that vendors of PC readers don't always seem to document that they follow the USB CCID specification, even when they do.)
First published in 1995, PKCS#11 (aka "Cryptoki") was intended as a "one size fits all" software API for talking to security modules/tokens/smartcards.
Through the API, a list of cryptographic mechanisms is enumerated. The API caller (such as Firefox, Thunderbird, etc.) can then ostensibly invoke one or more of these mechanisms.
Aside: what I find immensely frustrating is that it is not overtly apparent which mechanisms are used by a particular piece of software. PKCS#11 lists a variety of mechanisms, including block ciphers, message digests, PKI ciphers, etc. Say a user employed PKCS#11 and a security device with an email client. Would PKCS#11 get invoked just to perform the PKI cipher to obtain the session key and then perform the session decryption on the PC? Would everything go through the security device? Would perhaps the PC software use the security device if the capabilities were compatible with the desired operation, but then fall back to a PC implementation if not? If so, would the user ever be informed or be given a choice? There is so much that is unknown or covered by the veil of "just trust us".
The open-source "OpenSC" seems to consist of the software glue logic to provide a PKCS#11 API on one side and to talk to security modules/tokens/smartcards on the other side.
OpenSC seems to be more a gathering point rather than a monolithic solution. There are so many different (incompatible) readers; for each of these readers, there are many different smartcards that can be inserted into each of them. It is a complete crapshoot as to whether or not particular combinations of products will even work with OpenSC. (Then, a further problem discussed later is whether the security device actually provides the cryptographic capability that the user actually needs.)
For some security devices, manufacturers provide binary-only drivers (often just for Windows). This doesn't encourage much trust. In a day and age where most PCs are connected to the Internet, this affords a mechanism for any secret data to be collected and uploaded without the user's knowledge.
Even with open source drivers for the security device, security is far from ensured. There may be gaping holes or backdoors in the security device itself. However, if one doesn't blindly execute someone else's binary code, at least one is hopefully preventing a malicious entity from obtaining direct access to your security device.
Aside: Speaking of unnecessary security risks, it seems foolhardy that most card readers do not have integrated keypads. The de facto method of invoking the smartcard is to enter a PIN number. It seems unwise to provide this information to a possibly compromised PC or smartphone.
the smartcard itself
Here is where things get particularly maddening.
As mentioned earlier, ISO 7816 is an umbrella standard. As such, there is added protocol complexity to distinguish between the application you might be using the smartcard for versus the thousands of other applications ISO 7816 is also used for.
Let's say the intended application is PKI. In this case, there appear to be at most three architectural approaches (and all of these may likely be the same underlying hardware):
1) custom code running natively on a purpose-built smartcard IC (example: NXP "SmartMX" P5Cx012/02x/40/73/80/144 family, which is a classic 8051 combined with hardware acceleration for the crypto)
2) custom code running on a "Javacard" (which appears to be a continually moving target specification for a lightweight Java interpreter running on a smartcard platform). The "Javacard" is likely just #1 but with middleware between the underlying hardware and the Java interpreter environment.
3) custom code running on a "Basiccard" (which is a ZeitControl product consisting of a BASIC language IDE for development and an interpreter on the smartcard running "P-Code"). Like #2, the "Basiccard" is likely just #1 but with middleware between the underlying hardware and the "P-code" interpreter environment.
All three seem to fall into the "trust us" category in varying degrees.
"Gemalto" seems to be a heavyweight USA player (used by the US government?), but the only information seems to be marketing hype. Unless one is a major corporation (or government), it doesn't (to me) seem to be a viable solution for an individual.
The "ACOS5-64" from the Chinese company "ACS" looks promising and at a fair price, but its binary PKCS#11 drivers are closed and the card's origins are unknown. UPDATE: Linux drivers don't exist despite manufacturer web site claiming them; requests to the manufacturer for drivers go ignored. Windows drivers tell the user to turn off security!!!! Avoid, avoid, avoid.
There appear to be two quasi-open-source solutions. "Musclecard" was a Javacard (see #2 above) open source project, but the effort seems to have imploded.
"OpenPGP card" is a closed-source Basiccard (see #3 above). It is Europe-centric (specifically Germany) and also seems to be made of unobtainium,
Although it is frustrating that "OpenPGP card" is closed-source, I can see some justification for this approach:
a) To start any open-source project seems to be akin to volunteering to become a lightning rod. All sorts of crazies come out of the worldwide Internet woodwork and expect you to work tirelessly and for free to execute their whim-fuelled, half-baked ideas. Moreover, lots of unscrupulous individuals will take your hard work and sell it for profit... but leave you to provide all support to the end users. I've come to the conclusion that anyone who starts an open-source project needs his or her head examined (unless they can somehow ensure legions of supporters will field the end user support).
b) Authenticity is suspect when multiple vendors exist. How does an end user know that a card sold to them is actually an "OpenPGP card" and not a flawed or backdoor-ed device? (Then again, would one be confident that any device (even one from the original authors) shipped internationally has not be tampered with or replaced?)
Most, if not all the "USB" solutions appear to just be a miniaturization of the smart card and smart card reader into a single device (without a keypad... see "foolhardy" aside above).
back to main page contact