Designing a universal smart card

When the Department of Veterans Affairs began planning for a massive smart

card project that would encompass issuing more than 200,000 cards to veterans,

interoperability among its branches and other agencies, such as the Defense

Department, was a key requirement. That's because the smart cards, which

will include all health registration and enrollment data, will serve as

veterans' identification cards and will be used at multiple health care

facilities.

However, officials couldn't find a mainstream industry standard to draw

upon to ensure that the cards would work with readers at various locations,

said Kent Simonis, director of the Veterans Health Administration's health

administrative services.

That was before the General Services Administration leveraged its procurement

power to design an interoperability standard to enable different smart cards

to work together across government. GSA, along with vendors and agency representatives,

drafted an open interoperable specification to enable smart cards purchased

by one agency off the governmentwide Smart Access Common ID Card contract

to work with applications and smart card readers used by other agencies.

"In the absence of those, we would have had to develop our own requirements

and perhaps would not have been as successful," Simonis said.

No doubt the GSA efforts are an important first step: The work is credited

with spurring many agencies to jump-start projects once delayed by the lack

of standards. But there is concern that the government initiative doesn't

go far enough.

Indeed, some IT planners think that as they add new applications to

their smart cards they will need to either develop their own additional

standards or wait for standards that encompass new applications to gain

acceptance.

GSA Takes Lead

When GSA awarded its estimated $1.5 billion smart card contract in

May to five prime vendors — KPMG Consulting LLC, Litton/PRC Inc., Electronic

Data Systems Corp., 3-G International Inc. and Logicon Inc. — it required

all smart cards to interoperate so that agencies could use cards for multiple

purposes.

Because smart card vendors offer proprietary solutions based on their

own specifications, vendors and GSA had to develop a neutral specification

that all can support. The specification covers five smart card applications:

identification; logical access control, such as access to a computer network;

physical access control, such as access to a building; biometrics, such

as fingerprint scans; and cryptographic services, such as digital signatures.

The National Institute of Standards and Technology is helping GSA test

the specifications in 20 cards with 20 readers — a process expected to last

several months.

"We were in a position to take the lead here...in an attempt to foster

interoperability," said Mike Brooks, director of GSA's Center for Smart

Card Solutions. "GSA is pretty much in the driver's seat because we are

the procurement arm of the federal government. Agencies with limited budgets

need the flexibility to use Brand B reader with Brand 2 cards...instead

of being locked into one solution."

GSA based its specification on the ISO 7816 standard, which is composed

of several parts. The first four parts of the standard, for example, address

the physical attributes of the card, including where the chip is placed,

how it is mounted and the electrical interface of the cards. Industry experts

said this portion of the standard is considered to be fairly stable. As

long as those protocols have been implemented correctly, readers should

work well with cards on the same operating systems.

Still, the vendors, at the request of GSA, will have to develop middleware

to enable different platforms to support different cards; this middleware

will create extra administration overhead for agencies, said Gilles Lisimaque,

senior vice president at Gemplus SA and vice president of the Smart Card

Forum.

"When you want interoperability, you have those multiple layers and

then you have to manage them," he said. "There won't be one middleware that

will be stable forever. Multiple middleware will have to be managed." In

addition, although GSA's specification covers applications that have attracted

agencies' interest, as they move to tap additional smart card applications — such as financial trans-actions — agencies will have to write their own

interfaces or rely on other evolving industry standards. That is because

reader manufacturers have yet to agree upon a common standard interface,

and a variety of different protocols are available.

In the world of smart cards, there is no shortage of standards under

development. Among the many are the PC/SC (Personal Computing/Smart Card)

standard for smart cards operating in the Windows environment; the OpenCard

standard, designed to allow cards to interoperate across multiple hardware

and software platforms; and the JavaCard, which enables Java technology

to run on smart cards.

"The operating systems are very important," said John Moore, chairman

of the Federal Smart Card Users Group and director of smart card studies

in GSA's Office of Electronic Government. "If you have a different operating

system on the card and on the accepting device, that's a problem to start

with. It limits what you can do in reading the cards. It limits...how robustly

you can tie in to all the [application program interfaces]."

The VA's Simonis said his agency might eventually need to deploy standards

that would allow its cards to interoperate with card readers in Europe or

those deployed at private-sector hospitals so a veteran could use a smart

card at any of these facilities.

Although only a small group of veterans are authorized to receive VA-covered

care at private facilities, officials envision some day storing details

of what procedures and treatment are authorized by the VA on smart cards

carried by those veterans.

Another challenge for some agencies is marrying "contact" applications,

where the card is placed or swiped through a reader, with contactless applications,

which use an electromagnetic signal and antenna to send and receive data.

Although work is being done on a standard to support both types of applications

on one card called a Combi card, no such standard has gained widespread

industry acceptance.

Tina Pemberton, financial analyst at the Education Department's Office of

Student Financial Assistance Programs, said officials there are now evaluating

how to use a multipurpose smart card to control physical access, manage

assets, track transit benefits such as mass transit fare and access computers

and networks. Some of these applications, like physical access control,

would be contactless and some, like a computer log on, would be contact

solutions.

The question is, "How could you get these different functions to work

together on a single card?" Pemberton said.

There are other potential pitfalls for the ISO 7816 standard for applications

falling outside the basic set initially identified.

For example, ISO 7816 offers various protocol options that differ by

application, Lisimaque said. For a smart card that would be used with a

cellular phone, developers would want to use a protocol that would require

low voltage to conserve as much of the battery of the phone as possible.

But for a smart card to be used at a banking terminal, security would be

a much more important objective than voltage, so a different protocol would

be used, Lisimaque said.

"They do not have the same constraints," he said. "Depending on the

application, people are going to take one protocol...to save the battery

or want the ability to crunch numbers fast with the highest cryptography

features."

In addition, the GSA specifications do not apply to smart cards until

after they have been "personalized" by vendors, a method that can vary,

said Bill Bialick, technology director at Spyrus Inc.

When a smart card is manufactured at the factory, it is essentially

a raw chip with some storage features. The card vendor then writes the operating

system that will tell the card how to behave and will set it up for the

user, a process that includes loading digital certificates and cryptography

keys on the card.

"How you get it set up is different per vendor," Bialick said. "That's

going to be a problem. There still is uniqueness to each of them in some

part of their life. Vendors try to put that uniqueness in to draw the market

share."

Harreld is a freelance writer based in Cary, N.C.