What’s the deal with PIV cards? Is it just U.S.?

By Sven Gossel, charismathics

In August 2004, US President George Bush signed a presidential directive that requested a standard for secure identity documents, issued by the US federal government to federal employees and contractors. That standard, called FIPS 201, was issued in February 2005 and specifies all aspects of the Personal Identity Verification processes and credentials, as well as the requirements for the products, such as cards, readers and software that are to be used with such credentials.

Additional guidance from the White House established a timeline for compliance with the standard and process for measuring the progress government agencies were making towards complying. In turn, the US General Services Administration established an evaluation program that allowed vendors with FIPS201 compliant products to list these products on an approved products list. The result of this initiative is that the US government is well on its way to providing all Federal employees and contractors with a standardized identity card with a high validation level.

The physical FIPS201 credential (known as the PIV card) contains both contact and contactless interface. Much of the implementation focus is on adapting systems and processes for identity verification. Another major initiative is the use of the contactless interface for physical access. Agencies are working to integrate the PIV card with their legacy physical access systems so that they can replace their current proximity badges, raising the level of security, and simplify the process of inter-agency employee access. The FIPS201 initiative also directs agencies to use of the PIV card for logical access, including network and computer logon.

PIV and the US market

It is hard to overestimate the impact of the FIPS201 initiative on the US security market. Although the adoption rate of printed ID badges and contactless physical access cards in the USA is quite high, the overall adoption of PKI capable smart cards for user identification and logical access is low compared to Europe, Asia and South America. This is true across all market segments including state and local government, first responder, educational institutions, transport as well as businesses of all sizes. As a result, the first typical exposure a US IT or security professional has with a smart ID card is the PIV card. This is true for both end customers and vendors. As such, the PIV card is effectively seen not just as a government standard, but also as a de-facto smart ID card standard.

Many non-federal organizations and corporations are planning adoption of the PIV card for their own purposes. Some voices in the industry have predicted that PIV will be the tipping point for the adoption of smart ID cards in the US. For US based security software vendors, the PIV card has become the focal point of their strong authentication strategy.  Most have ignored the smart ID card in the rest of the work, but with the PIV card on their doorstep, they are making changes – affecting the worldwide market.

When is a PIV card really a PIV card?

A closer look shows that the PIV Card is not necessarily well suited for non-Federal users. The first barrier is that a PIV card is not actually supposed to be used by non-federal users in the first place. A PIV card is, by definition, a card issued by the federal government according to the FIPS201 standard. It means the user has gone through a stringent process of identity verification, and a federal CA has issued the digital certificate.

This process is specific to the US federal government, and is not accessible to, or even appropriate for, non-government users. The PIV program supports government contractors, and there are several industry initiatives to enable such contractors to get valid, government issued PIV cards. But what about non-federal issuers such as state and local government, schools and corporations?

The US Federal CIO Council, which is responsible for many aspects of the federal PKI infrastructure, has addressed this issue, and determined that there are, in fact, three types of PIV cards;

• The standard PIV Card– which is a technically compliant card issued by a ‘conformant’ federal entity.
• The PIV Interoperable card issued by a trusted, non-federal entity.
• PIV compatible cards, which are technically compliant cards, issued by a non-trusted entity.

PIV interoperable cards

Non-federal organizations can issue PIV Interoperable cards as long as they are issued by a trusted non-federal entity, meaning that the federal government must trust the issuing entity. The US Government is extending its Public Key Infrastructure to bridge with non-government entities, ensuring interoperability and trust. It has established policies and security guidelines. Several non-governmental CA’s are bridged now, and in the future is expected to grow. Several initiatives are already in place built around trusted CAs that could deliver PIV compatible cards. First in line are the defense and aerospace industries, with the transportation sector not far behind. These industries already operate globally, and adoption of the PIV card by these industries will have global implications. The US federal government and any number of organizations would trust such a credential across the globe allowing for the verification of that employees identity.

PIV compatible cards

In principle, any organization or corporation could sign up with a trusted provider and start issuing credentials. However, when we look at the organizations evaluating or planning to issue PIV cards, the ability to verify the identity of a cardholder to a high level is only one of many requirements and objectives, and often not the most important one. The expectation many organizations have is that the PIV card will be a single unified credential that will allow them to manage physical and logical access and enforce identity and access policies. But in fact the PIV card was not designed for this.  It is more like a passport, and less like a driver’s license, train ticket or student ID.

Most organizations have no need for authenticating their employees to outside organizations, and no real need for authenticating employees from other organizations. Where they do need to do so, existing user credentials (such as passports and drivers licenses) meet their needs. Most organizations need to issue organization specific credentials to a well defined user population, with ID management and authorization in a centralized structure; a school to its faculty and students, a city to its staff, a company to its employees. Though digital certificates are an effective way of doing this, such organizations don’t need a complex, decentralized PKI. For such organizations, the most effective model is for the organization to issue credentials itself for its own purposes, primarily managing access to physical and logical resources. Given the cost and complexity of PIV Interoperable card issuance, and the limited utility of such cards, most organizations will end up opting for PIV Compatible cards – typically technically compliant cards issued by the organization itself.

PIV technology: Ready for the real world?

One of the peculiarities of the FIPS201 initiative, from a Non-US perspective, is that it does not dictate specific application level protocols. The low level interface to the PIV credential has been defined, and a large number of access products have been certified and listed on the approved products list.  But on a higher level, there is no uniform interoperability. There are multiple compliance levels and different, often vendor specific, implementations.

For logical access the issue is even more acute. FIPS201 specifies a card interface and a low level application-programming interface (PIV Middleware Specification).  The card interface is limited and doesn’t meet the needs of typical corporate applications. If you need multiple user certificates, manage multiple encryption certificates over time, or store additional data or keys, then the standard PIV card interface is too limited. Several industry attempts have been made to define an interoperable card edge standard, and all have their weaknesses. It is not clear that a standardized card edge should be a real objective for Smart ID Cards. An argument can be made that all that is needed is an application level interface, and that the card edge serves to optimize the performance and functionality at the API level. This is the approach that Microsoft has taken with their smart card ‘mini driver’ specification. Alternatively, PKCS15 (ISO/IEC 7816-15) is a widely used card edge standard that is often used as an example of a card edge that is too complex and limits performance. But the PIV card edge goes the other way and provides a very limited interface. In principle a lean card edge interface makes sense, if it is coupled with a higher-level application interface and a way of mapping the application data (related to users, credentials, keys and application data) to the card data. The PIV card edge is not that.

One industry attempt to overcome the card edge limitations of PIV is the Generic ID-Card Command Set (GICS). This is an extension of the PIV card interface support by several large card manufacturers, and developed through the INCITS/B10 standards committee. It is promising, but needless to say it is not FIPS 201 approved.

Integrating PIV and applications

PIV also defines a PIV Middleware layer that is intended to allow an application to access the card and its credentials using a certified and approved application library. In principle this allows any application to interface to the card. In practice things are more complicated. Applications on a personal computer typically work within a security framework that provides the applications access to resources, and manages the user credentials that facilitate that access. The processes for authenticating users and validating credentials is typically done using specialized functions in the operating system, and card and credential typically requires specialized applications and components. However, the PIV specified middleware does not integrate into the PC security environment; as such, the PIV ‘Middleware’ is a misnomer. How then to bridge the gap between PIV and application?

One ambitious attempt is a standard called ISO/IEC 24727. This provides an integrated way to abstract and make available smart card based data, credentials and services to applications, and the Identity and Access application environment. It is complementary to PIV and GICS, and provides data abstraction and a language syntax that allows applications to coherently interact with and make use of smart ID cards on a high level. Unfortunately it is unclear how this solution will end up being integrated with the existing PC client security context, and provides no clear incremental path to adoption.

For now, the most common way that PIV cards are integrated into the application is through the Windows environment, and PKCS11. Microsoft Windows CAPI/CNG provides a rich API for its security and cryptographic services, and manages credentials and user authentication almost transparently. The PKCS11 token interface also has seen wide adoption, and is a de-facto standard on UNIX and Linux machines. Both Windows and PKCS11 allow applications to interact with digital certificates and keys without having to worry about the underlying mechanics of the smart card, the smart card reader, and such things as certificate compression. Because the specified PIV Middleware does not integrate at this level, a Smart Card Middleware package is required to handle the integration of the PIV card specification into the Microsoft Cryptographic system, as well as PKCS11, and deal with the vendors’ specific variations of the cards and data.

Migrating to PIV Cards through Single Sign On

In the US, beyond government, the market for smart card and digital certificates is still in its infancy. For companies and organizations that look to adopt these technologies, the challenge is the migration path to a complete solution. Deployment typically starts with a single application (such as remote access) but the ov­erall business case needs to build on a much wider application base.

One way is through the integration of smart ID cards with Enterprise Single Sign On (E-SSO). E-SSO systems store user credentials (typically passwords) in a secure vault, and enable users to access the vault using a single credential. The better E-SSO systems provide convenience to the user, and a higher level of security then straight password usage.  E-SSO adoption is quite high in the USA, and the main vendors, including IBM, Oracle and Imprivata, support a wide variety of systems and applications already. We should expect to see a lot of US organizations adopt the PIV card as a strong authentication factor for their E-SSO system. This will allow them to get to scale quickly, and provides a straightforward migration path to a full PKI system in the long run.

Conclusion

The PIV card standard is probably not taking over the world just yet. It is too limited in its user functionality and technical capabilities. But the PIV card as a force of change in the US security market is a fact. With the US industry commitment to integrate the card in security applications and solutions, and with the build out of a large scale cross industry PKI infrastructure, it is clear that the impact goes way beyond just the US federal government.

PIV ALFABET SOUP

HSPD12 – the directive to implement the PIV card
FIPS 201 the PIV standard
NIST SP 800-73 The PIV interfaces specifications
FPKIPA Federal Public Key Infrastructure (FPKI) Policy Authority
IAB –Government Smart Card Interagency Advisory Board (IAB)  www.idmanagement.gov/iab/