All together now

Michael R. Brooks says DOD has committed to using technology built to NIST's Version 2.0 specification.

Henrik G. De Gyor

New spec sets foundation for DOD and civilian smart cards, but there are many details to work out

An interoperability standard approved this month will require smart-card developers to make civilian agency cards compatible with the Defense Department's Common Access Card.

James Dray, principal scientist for the government smart-card program at the National Institute of Standards and Technology, said he believes interoperability is "the issue that will make or break the smart-card market in the United States."

NIST released the Government Smart Card Interoperability Specification Version 2.0 late last month, and the General Services Administration-sponsored Interagency Advisory Board unanimously accepted the specification this month.

The vote "was a blessed end to a whole year of hard work, not only by GSA but by the partner agencies and industry," said Michael R. Brooks, director of GSA's Center for Smart Card Solutions.

The advisory board consists of representatives from DOD's Common Access Card program, NIST and agencies planning to use smart cards.
DOD contractors and vendors of the governmentwide Smart Access Common ID card must now update or rebuild their products to the specification.

"This is going to take a while," Brooks said. "This is not going to happen overnight."

The architecture will "lead to an interoperable smart card across the government as long as those standards are adhered to," said Gordon Hannah, spokesman for the DOD Common Access Card Office.

The missing link

Version 2.0 "provides the first comprehensive, interoperable architectural model for smart-card systems from the card edge to the application layer," Dray said.

"This is the critical element that has been missing" in previous attempts to deploy smart cards on a large scale, he said.
NIST released Version 1.0 last year, and all products on GSA's Smart Access Common ID contract already follow the specification.

"2.0 is basically an interface protocol that deals with middleware," Brooks said.

He said DOD had to move quickly on its implementation, which predated publication of the first specification and GSA's involvement. "There was a gap between what we were doing and what DOD was doing," Brooks said. DOD now has committed to use technology built to work with Version 2.0, he said.

The specification not only will make cards and readers interoperable, it will also improve interoperability of middleware and applications that work with the cards, Dray said.

Version 2.0's Basic Services Interface and Extended Service Interface are application programming interfaces for making client software work with service provider software. The APIs also support encryption, authentication and digital signatures.

The Card Capabilities Container, embedded in each Version 2.0-compliant chip, maps the card's proprietary language to the standard Virtual Card Edge Interface.

"This ability to abstract the differences between vendors' card edge interfaces is a tremendous step forward in terms of interoperability," Dray said.

But the new standard presents complications:

  • If the cards that an application is hard-coded to use become unavailable commercially, the app must be redesigned for different cards.

  • Version 2.0 applies only to contact-based chips, which require physical contact with a card reader to transfer data. "A lot of people are interested in contactless chips," which transmit data via an embedded antenna, Hannah said.

  • The new standard does not include biometric authentication. "That should be moved into the basic services," Hannah said.

Brooks said there is plenty of room for biometric data in a smart card's 32K chip, and there's time to develop contactless cards. The interagency board will likely set standards for those in fiscal 2003, he said.

Card stops here

Nevertheless, communications incompatibilities among smart cards, readers and host computer systems persist. Hannah said responsibility for solving those problems falls to the Personal Computer/Smart Card Version 1.0 framework of the OpenCard Consortium, an industry group.

Smart-card initialization--similar to formatting a floppy disk--is done by each manufacturer, he said.

Another unresolved problem is cryptographic key management, which involves business rules and policy. Each agency is responsible for its own rules and assurance level. DOD has a more stringent requirement for assurance than do other agencies, Hannah said.

Brooks said the Agriculture Department's system might be able to read his card and credentials, but the department still would need a policy to decide whether he had a legitimate reason to enter a USDA building.

"It's going to be up to Agriculture to give me privileges," he said. "I still have to obey their rules."

Meanwhile, DOD "is working closely with NIST to integrate the Common Access Card architecture into the interoperability framework," Dray said. "Many smart-card pilots have fizzled due to interoperability problems. It gets started, and someone has to champion it to move it to the next level."

Paul Kurtz, senior director of the White House Cybersecurity Office, has urged agencies to think about using smart cards to protect systems against cyberterrorism.

The Cold War model won't work this time, Kurtz said. "We can't use those radars in Alaska to find that cyberattack," he said at a symposium last month. "Smart cards obviously will be a part of the solution set."

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above