NIST's objection to GSC-IS that it was not specific enough to ensure that anyone holding a GSC-IS-compliant card could, for instance, use it to log on to any U.S. government computer network set up for smart card authentication, says Gilles Lisimaque of the Washington-area consulting firm Identification Technology Partners and a former executive at France-based smart card manufacturer Gemplus International SA. Lisimaque worked with NIST on the new spec.
One Blueprint, Two Buildings
He says GSC-IS was designed to allow agencies to buy standard technology, but it did not describe in enough detail how it was to be used. He compares it to two builders going to Home Depot, a major U.S. chain of home improvement stores, and buying the same materials. "They can build two different houses, although they have the same supplier," he says.
In fact, he says, agencies did implement GSC-IS differently. For instance, some require cardholders to enter a personal identification number immediately when inserting their smart card into a reader attached to a PC; others may require the PIN only when using the chip card to sign an e-mail, and still others may require a biometric identifier to create a digital signature.
"Although they are using the same tools, the same application does not interoperate, because in some cases the client (the PC) is going to expect behavior in one sequence, and another is going to expect it in another sequence," Lisimaque says.
What NIST has done in the smart card draft, known as Special Publication 800-73, is to create an application, called Personal Identity Verification, that must work the same in all implementations. That should mean, for instance, that an Agriculture Department employee would be able to use his or her card to log on at a Department of Treasury computer.
One issue is that the PIV spec means new or added software for cards and the computers or readers that interact with the cards.
"The PIV application can be implemented as a wrapper layer on top of existing applications," including GSC-IS applications, James Dray, NIST's chief smart card scientist, says in an e-mail response to Card Technology.
He says that NIST's draft spec complies with international standards for card commands and labels for such data as the cardholder number and digital certificates. In the NIST spec, Dray says, it does not matter in what internal format the card uses to store the data elements "thereby future-proofing the PIV architecture against changes in card technology."
Lisimaque agrees, but notes that agencies may face significant hurdles in moving from their current GSC-IS implementations to the NIST technology.
Adding new software on the card means recertifying the security of the smart card. That can take nine months to a year, Lisimaque says.
Vendors, which already have spent considerable sums to develop and certify products that conform to GSC-IS, were furious at the thought of starting over, says one source who asked not to be named. "Industry says, we've worked with you up to this point and you've changed it again. How many times are you going to do this?"
For agencies that have deployed smart cards, one of the big issues could be updating the middleware that allows the smart card chip to interact with PC applications, such as network log-on.
Agencies refresh their software on a regular basis. But if they have to do it all at once to conform to the new spec it will mean added expense and disruption. Says one Defense Department official, "All the old stuff must work, the new stuff must work, and then later on the old stuff has to be flushed from the system. The phasing of this is hard."
That is an especially big problem for Defense, which has equipped 2.2 million computers to communicate with its smart cards. Defense Department officials say they continue to discuss the issue with NIST.