Muscle Flexes Smart Cards into Linux
Smart cards, like ice cream, come in many different flavors, but there are two fundamental types: memory-only and processor-based.
Plain vanilla memory cards are typically used as electronic purses—for example, phone cards, vending machine cards or university campus cards that store cash value. The value can be decremented with each use and recharged at specialized machines; consequently, such cards are sometimes referred to as cash cards.
Processor cards enjoy a more varied deployment. They can contain a cryptographic coprocessor for authentication and file encryption. Some processor cards actually run Java binaries directly on the card using a built-in Java virtual machine (a subset of the one that runs on any full-sized computer) to interpret the commands in the Java binary. These are referred to as Java cards. Most of a Java card's functionality can be exercised through Java classes, allowing the card to be programmed in almost any platform or hardware specification. Java cards also include some limited cryptographic functionality, which can be accessed through Java security classes. Java cards combine the ease of a familiar programming language with the robustness of the smart card.
Both memory and processor smart cards support two types of I/O: actual electrical contacts or radio-frequency induction.
The burgeoning need for secure transactions and e-mail privacy may be answered by the next generation of cryptography cards, such as the Schlumberger CryptoFlex smart card. Such cards are capable of a wide variety of cryptographic functions, including random-number generation, digital signing and encryption. These cards are typically used in an authentication process, where cryptographic keys associated with an X.509 certificate are stored on the card and unlocked for use with a PIN number. Or biometric measurements on the card are compared with those retrieved through a card reader equipped with biometric sensors. After authentication, a user can access the public/private key pair directly on the card and use it to sign or encrypt messages using the card's cryptographic coprocessor. This key pair never leaves the card. The cards can store more than one key pair and are capable of doing multiple cryptographic algorithms such as PGP, RSA and DES.
Unlike the magnetic-stripe card, which uses single-factor authentication (you have the card in your hand, therefore it must be yours), cryptographic smart cards actually run software right on the card. This allows bi-directional authentication between the smart card and the card-reader terminal, and when biometrics are involved, multi-factor authentication. One possible authentication scenario runs like this:
The card reader terminal powers up the card and identifies it through the “Answer to Reset” function.
The reader initiates authentication by transmitting a random number to the card along with a request for encryption.
The card authenticates the user through a PIN or biometric measurement, and if successful, encrypts the random number using the private key stored on the card. The encrypted random number is returned to the reader along with the certificate of identity.
The card-reader terminal obtains the public key (using a directory lookup or other database) and decrypts the random number using the public key.
If the decrypted random number matches the one originally transmitted, the user and card are authenticated.
A similar process can even be used by the card to authenticate the reader terminal.
A card reader or terminal is required to power and communicate with the card. There are a wide variety of smart card readers on the market. They include contactless or RF readers, and the more common electrical-contact reader. These readers can be computers in their own right or can interface with any host computer via serial, parallel, USB and PCMCIA ports. Other reader-to-host interfaces are possible, even through a floppy drive. Some readers incorporate PIN pads or biometric sensors directly in the reader so that the PIN, pass phrase or biometric measurement never leaves the system.
Readers and terminals come in a variety of sizes, shapes, colors and functions. The Schlumberger Reflex 60 smart card reader is designed for PC applications—for example, secure business-to-business transactions between merchants and banks over the Internet. You could also have secure access to Web TV, games and many other applications.
Smart cards communicate with the reader through either the contact plates located on the plastic card or through radio frequency. In each case, the cards communicate through either the T=0 or T=1 protocol. T=0 is a byte-oriented protocol where an instruction byte is sent and an acknowledgment is received. This may be an error message or just an acknowledgment of the instruction. T=1 is a block-oriented protocol which sends a specified unit of data.
Like PCs, smart cards have a file system which contains a root or master file. All files are identified by two bytes. The master file on smart cards is identified by 3F 00. Dedicated files are similar to sub-directories in that they allow files to have specific paths. Information is actually stored in what is called the elementary file. The elementary file can be defined in different ways, depending on how the user wants it subdivided for storage. The following diagram shows a simple smart card file system.
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
|Non-Linux FOSS: Animation Made Easy||Jan 14, 2015|
|Internet of Things Blows Away CES, and it May Be Hunting for YOU Next||Jan 12, 2015|
- Designing with Linux
- Readers' Choice Awards 2014
- Wondershaper—QOS in a Pinch
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Ideal Backups with zbackup
- One Tail Just Isn't Enough
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- New Products
- Slow System? iotop Is Your Friend
- Tech Tip: Really Simple HTTP Server with Python
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane