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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Parsing an RSS News Feed with a Bash Script
- Tips for Optimizing Linux Memory Usage
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide