A Painful Birth for an ID Card Standard

March 2, 2005
Initiative moves forward, attempting to create standards where none exist

It was a simple enough goal: create a standard ID card that U.S. government employees and private contractors could use to enter government buildings and for logging on to computer networks.

And, by the way, make sure it supports digital certificates for signing electronic documents and biometrics to verify that the person presenting the card is the legitimate cardholder. And it would be a big help if it were compatible with existing smart card programs, especially that of the Department of Defense, which has issued Common Access Cards to 3.1 million of the 3.5 million military and civilian personnel who will need the smart card IDs.

OK, maybe it wasn't such a simple goal.

It certainly has turned out to be a painful process, but one that may prove useful to others as they seek to introduce identification credentials that can be shared by many entities.

As Card Technology went to press in late February, government officials were increasingly optimistic they could arrive at a reasonable compromise. Some officials, as well as industry vendors were less optimistic after the National Institute of Standards and Technology, the U.S. government's technology arm, released its latest proposal Jan. 31. But sources say negotiations were productive.

The aim is to create a protocol that ensures that a card issued by agency A can be read by agency B, without tying those agencies to specific vendors or smart card formats. The ID card will be used by some 7 million U.S. government employees and private contractors.

It's an aim others are pursuing, as well.

European Initiatives
In Europe, there is similar work underway to create a framework that would allow different agencies within government to accept each other's credentials, says John Elliott of UK-based Consult Hyperion. And he says his firm was recently engaged by the European Commission to study both private and public identification systems in each of the European Union's 25 member states with a view toward encouraging interoperability.

U.S. officials also are spearheading an effort within the International Organization for Standardization to create an ISO standard, known as ISO/IEC 24727, for use with ID cards. Work on the overall architecture has reached the draft stage, and votes on that proposal are due by April, says Teresa Schwarzhoff, the NIST official chairing the ISO task force.

Normally, it takes a year to get a proposal to the ballot stage, and she says the first part of the 24727 proposal managed it in six months. Two more sections are likely to reach the ballot stage this year, she says. Nonetheless, final approval is likely still years away.

Other governments might choose to wait, but Washington is moving forward.

President George Bush signed an executive order in August mandating that the U.S. Commerce Department, the parent agency of NIST, come up with a standard for an ID card that can be used for physical and computer network access by government workers and contractors. The deadline was set for late February. Implementation of that new standard is supposed to begin by October.

Facing that aggressive timetable, NIST set to work last fall on a new standard. There already was a protocol in place and being implemented, the Government Smart Card Interoperability Specification, or GSC-IS, which was largely based on the Defense Department's ID card.

Other agencies also are moving forward. The Department of Homeland Security recently received a $6 million appropriation for the coming fiscal year to issue a smart card ID to its 180,000 employees. The agency will be required to conform to the new ID card spec.

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.

International Standards
"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?"

Middleware Muddles
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.

According to several sources, NIST angered some officials by ignoring proposals made by the Interagency Advisory Board, a group of representatives from agencies with smart card programs. They say the IAB's suggestions were largely left out of NIST's updated spec, released for comment Jan. 31.

Lisimaque says the Jan. 31 proposal did take into account earlier comments about the original spec NIST released in the fall, and now specifies only the minimum required to ensure interoperability. What NIST did not include, was the IAB's proposal for a migration path from current GSC-IS implementations to the new ID standard. NIST's Dray says a migration path will be proposed after officials agree on the spec.

The IAB made its discomfort clear last month by informing NIST that it did not concur with the latest proposal. Although IAB's approval is not required, NIST clearly would prefer the agreement of the agencies that must implement the standard.

The clock was ticking. The policy document setting out the framework for the ID standard, FIPS 201, was due to be approved early this month. The more controversial document that will provide details on the smart card technology, Special Publication 800-73, is expected to come several weeks later. Sources said late last month that a compromise was in the works that appeared satisfactory to the major players.

A Loophole?
The most pressing deadline is the one coming in October, when agencies are supposed to start complying with the new standard. However, the presidential decree says agency heads should comply by that date "to the maximum extent practicable." That may provide an out if the government decides to allow a longer transition to the new technology.

If there is a lesson for other governments, it may be to try to set your ID card standard before agencies are too far along in their deployments to easily modify their systems. Otherwise, expect howls of protest and lengthy negotiations over how to convert and who is going to pay.