Smart Cards From Scratch - Page II

Printer Friendly Version

Standards Supported

There are at least 25 standards that a smart card can adhere to. Most of the standards are ISO/IEC standards, but there are also FIPS standards, ANSI standards, USS standards, X.509 certificate standards, and EMV (Europay, Mastercard, and Visa extensions) standards. If you're a government agency, you'll probably want to adhere to FIPS-140, Level 3 standards which is a NIST security requirement for cryptographic modules. The ISO/IEC standards define the physical characteristics of the cards. A summary table of smart card standards is listed in Table 2.

Access Controls

Different cards have different access control capabilities. These capabilities might be a limitation of the card, or of the life-cycle management software. The access control capabilities that you need depend on what applications you plan on using the card for. A summary of access control capabilities is listed in Table 3. The access control capabilities define who can access what areas of storage and under what conditions. Not all smart cards offer every kind of file access type.

Processor & Programming Support

There aren't many processor types available for smart cards as of yet. Most of the processors are either a 32 bit RISC processor, or a math co-processor. Unless you are going to be using encryption on your smart card, you probably don't need a math co-processor.

It's probably a good idea to make sure your smart card comes with an on-board clock, in case you want to use time sensitive applications that require it. A clock can also be useful for monitoring log files, though in most cases, the reader and life-cycle management software will time-stamp the transaction.

There are various programming capabilities available for smart cards. One I recommend, as perhaps the most important of all, is to make sure your cards are Java programmable. Most new smart card applications are written in Java, and if your card is Java programmable, it will allow you to use almost all of the latest smart card applications. ActivCard is a company that writes Java applications for smart cards, and has written most of the Java applications for smart cards currently in use by the Department of Defense. If you need a custom Java smart card application, they take on customer specific Java programming projects as well.

If you are a U.S. Federal agency, you'll want to make sure your Java card is FIPS certified. Currently Schlumberger Java cards are FIPS certified, and Oberthur cards are not (though Oberthur cards are currently in the process of being certified).

Only Java cards meet specifications of GlobalPlatform.org -- a leading smart cards standard forum. GlobalPlatform has defined rules for smart card security domains, and has also defined standards for various card recognition identifiers.

Other programming capabilities you might want to consider include Visual Basic Extensions, MULTOS, and error correction capabilities. If you plan on programming your cards with Visual Basic, you'll need the Visual Basic Extensions. Many smart card applications are written using MULTOS, a smart card optimized language, so if you plan on using MULTOS applications, you need to make sure your card has MULTOS capabilities built-in.

Algorithms Supported

The only real reason you should care about the algorithms supported is if you plan on encrypting any of the data on your smart card. Certainly, if you want to keep your data secure, the smart thing to do is to encrypt it. Any data that is not encrypted, could be read by miscreants, and perhaps manipulated, and used for fraudulent purposes. Since the purpose of most smart cards are to provide some sort of security, whether it is for identity, access, or electronic purchases, it's probably a good thing to make sure that any smart card you purchase supports at least one leading encryption algorithm. If you plan on using digital certificates or PKI, your card must have at least one encryption algorithm. Your smart card life-cycle management vendor ought to be able to answer questions about what algorithms are appropriate for the applications you want to use. Table 4 lists the encryption algorithms that you can typically expect to find supported by smart cards

Smart Card Manufacturing

Smart cards vendors make the cards -- they don't necessarily make any of the applications that the cards are used for. Some smart card vendors design and make their own circuits, and others buy pre-made circuits, embed them in cards, and resell the cards. The vendors who make their own circuits, will say that their cards are better, however, I haven't found any evidence that supports that claim.

When you implement smart cards on your intranet, you need to also implement what is known as smart card life-cycle management software. It is the life-cycle management software that actually makes the card do what you want it to do. Smart cards vendors are typically not smart card life-cycle management vendors. However, most smart card vendors partner with various life-cycle management vendors. In fact, it might even make sense to shop for the smart card life-cycle management software first, and then find the right card to go with it. Just like it might make sense to pick your enterprise operating system, and then shop for the hardware to put it on. However, the smart card life-cycle management software is not an operating system. It is more similar to a directory service combined with a database.

Go to page: 1  2  3