Choices to make before deploying smart cards
I’ve got a good email thread going with a colleague regarding the deployment of smart cards, and specifically regarding the choice of reliable card middleware. Wanted to broadcast some of it for wider benefit:
Regarding vendor selection for a smart card deployment, there are a couple of things you’ll have to evaluate and choose: who provides the chip, who puts the chip on the card, who provides the software mask that runs on the chip, who provides the middleware for the host, and who provides the readers. There are packages wherein some or all of those choices are made for you.
Middleware refers to the application-layer software that runs on the PC. The Cryptographic Service Provider (CSP) plug-in in Windows is an example of one component of the middleware. The CSP allows Windows apps to use a given card for crypto operations via Crypto API (CAPI), such as those required for logon or for signing an email.
Due to the complexity of application interfaces such as CAPI, it’s easy for vendors to make mistakes in the middleware that can cause client apps to fail and/or cause the card to exhibit poor performance. For that reason, assuming you’re targeting Windows, I recommend looking for cards that support the “card mini-driver” or “card module” (two names for the same thing) interface (more info). In that case, Microsoft has provided a CSP called the Base Smart Card Crypto Provider (or BaseCSP), and the vendor has written a much smaller card-specific plug-in that sits under that. That way, there’s less application surface area exposed to vendor code.
Some applications require PKCS#11 middleware instead of a CSP. Thus, in an ideal world, you’d have a card with supported P11 and CAPI middleware.
Another piece of the interoperability puzzle is to ensure that your choice of card works well with your choice of card reader (also called the interface device, or IFD). Ensure the reader has drivers available for all of the OS versions you want to support and that the driver is reliable. Finally, test the card with the reader to ensure you don’t see spurious communications failures and that card operations are speedy: once the card has been provisioned, signing an email with it shouldn’t take more than 1/2 second, for example.
It’s a good idea to run a pilot deployment, gradually scaling up to 5 – 10% of the user base, to work all of these things out.
“Ensure the reader has drivers available for all of the OS versions you want to support and that the driver is reliable.”
In line with the minidriver recommendation, it helps if the reader is compliant with the USB CCID device class standard. This enables the deployment to have a) independence from reader vendors and b) not require proprietary drivers. Moreover, the USB CCID driver is built into Windows Vista, Mac OSX, and available via WU for Windows XP, and Linux distribution (ex. Ubuntu, Red Hat) package managers. From an end-user/sysadmin perspective this means, plug in the reader and it is ready for use.
If a reader is already built into deployment target hardware this is a moot point.