The blog posts on this will be the more interesting hacking/practical stuff related to a project I’m doing, where I’ll experiment with different Smart Card programming tools and hardware.
Under the right conditions, Smart Cards are an almost perfect method of two-factor authentication – authenticating data is stored on the card encrypted, and the cryptographic key is derived from the PIN. In other words, the card and the owner’s PIN is required to complete the authentication.
But what’s to prevent an attacker reading the data off the EEPROM and bruteforcing the encryption? Something else is needed to implement access control. In this case it’s a microprocessor that mediates access to the EEPROM where the data is stored, along with some level of tamper-resistance to prevent that memory being accessed directly. Read/Write operations must therefore be performed through the microprocessor. After a little probing I learned that it’s the microprocessor itself, and not an ATM machine, that manages PIN changes and bricks a bank card after three incorrect PINs are entered.
The non-management aim of my project, which is slightly related to my work on the IPv6 darknet, is simple: To develop an application that uses Smart Cards as a method of storing cryptographic keys for secure Internet-based comms. Ideally the cards themselves would be endpoints in a widely deployed comms network.
The first step is to create software that calls various functions to interact with a card’s microprocessor. Currently I have installed:
* libpam-p11: PAM modules for PKCS#11 Smart Cards.
* libpcsclite: PCSC Lite library.
* OpenSC: Libraries and utilities for interacting with Smart Cards
* OpenSC PKCS#11 APIs.
* pcscd: Middleware.
* pyscard: Smart Card module for Python.
What I ordered from SmartCard Focus was pretty much the cheapest and most generic hardware I could find, so there’s the greatest chance of getting Python modules, OpenSC, OpenPGP and maybe C++ libraries (as a last resort) to interact with the cards:
* 3x ACOS3 ISO 7816 Smart Cards with 32KB EEPROM
* 1x Gemalto IDBridge CT30 card reader
* Drivers and utilities for Microsoft Windows
SmartCard Focus also do cheap RF shielding products for protecting RFID cards.
ACOS3 Microprocessor Card
The cards themselves were designed on the ISO 7816 standard (which isn’t what the banks primarily use), and memory access is mediated by the card’s own microprocessor. Of course, this wasn’t originally what I had in mind when starting the project, preferring to read/write data as encrypted blocks with the card acting simply as a storage medium for an encrypted block of data.
The ACOS3 isn’t suitable for high-security applications such as ‘e-government’ or national ID schemes, partly (perhaps mainly) because their microprocessors handle DES/Triple-DES only, so you’re either getting 64-bit (which is actually 48-bit) or 192-bit encryption depending on the specific Triple-DES method. Interestingly, I’ve learned, through a bit of field research, that some Chip-and-PIN payment systems still work with an ACOS3 card.
The Card Reader
According to Gemalto’s product description, the IDBridge CT30 is a very basic card reader that works with any ISO 7816 Smart Card. In theory it acts simply as a data bus between the USB port and the card contacts, but in practice card readers have a controller chip that might need additional drivers.
Communication and Test
So far I’ve done some initial testing of the hardware with ACOS3 and a range of other cards. The OpenCT and OpenSC tools detected the reader perfectly, but getting Linux-based stuff talking with the microprocessors is really a matter of testing different manufacturers and libraries, even though numerous technical docs say that certain types should work. The pcsc_scan tool reads the chip parameters and correctly identified the card manufacturer, so there’s definitely some communication happening with the processor.
I’ve yet to properly try this with Python modules or C++ libraries (which I’ve also installed).