First Impressions of ISO/IEC 24727

** 6 Jan 2010 Update:  The official presentations are now available from NIST.

Today, googling for ISO/IEC 24727 returns ~5000 results.  The first four are links to purchase the standard specifications from either the ISO or IEC webstore.  The fifth, ISO/IEC 24727 – A Future Standard for Smart Card Middleware, looked like a simple description of the standard, maybe distilled for a broader audience…  But, it’s actually a paper about the standard on sale for $25! Perhaps this lack of free information was part of the reason NIST decided to hold a workshop all about the standard this past week.

I attended NIST’s Tutorial Workshop on ISO/IEC 24727 (Identification Cards – Integrated Circuit Card Programming Interfaces).  It lasted a few days and it covered a ton of information about this 6-part standard.  The workshop speakers included several editors of the standard, including Tim Jurgensen, Mike Neumann and Alex Gagel, as well as representatives from NIST who have also been working with 24727 in various capacities: Terry Schwarzhoff, Bill MacGregor, and Sal Francomacaro.  Ketan Mehta & Hung Dang from Booz Allen Hamilton and Alexander Winnen from Giesecke & Devrient gave technical demonstrations of the standard in-action.  Alex Gagel also detailed the first substantial use of the standard for the Queensland, AUS Driver license.

Outside of NIST, it seems that there has been little involvement from United States companies in developing 24727.  Perhaps that is part of the reason why there is not a ton of information available online.  This post explores 24727 from a U.S. smart card standards perspective.  If you’re familiar with CAC and PIV, but are just hearing about 24727, I hope this helps.

Some Background – HSPD-12 & PIV

ISO/IEC 24272 is a bold attempt to make identity credentials (such as smart cards) and the applications that consume those credentials much more interoperable than they are today.  Wait, isn’t that what PIV was supposed to do? Sort of, but 24727 goes much further in its interoperability goals.  On the technical interoperability side, PIV defined a smart card edge (API), data model (to store the cardholder’s name, ID#, photograph, etc.), and required cryptographic capabilities.  FIPS 201 (Titled Personal Identity Verification of Federal Employees and Contractors or “PIV” for short) tackled much more than just the technical specifications of the smart card.  It also defined the physical card look and feel of the card, standardized the identity vetting procedures, and provided use cases for physical and logical access.

The goals of 24727 are slightly different than the U.S. Government’s goals with PIV.  FIPS 201 / PIV was created in response to HSPD-12 – a request from former President G.W. Bush to create an identity standard for all federal employees and contractors.  NIST answered the call and developed the FIPS 201 specification in 6 months – a very short amount of time for a standard encompassing many identity concepts.  PIV defined a single smart card standard that enabled many different hardware and software manufacturers to create compatible products.  This has had an enormously positive impact for the adoption of identity smart cards and related products in the U.S. Government.  PIV was also a huge boost TrustBearer’s industry.  Now, state & local governments and private companies are starting to take advantage of this federal government investment.  See the CIO Council’s PIV-Interoperable document.

The scope of the PIV specification was deliberately limited to address the requests in HSPD-12.  PIV defined a smart card application for usage, but not for card personalization.  PIV also defined a very specific card data model intended to store information that would be helpful to identify federal employees and contractors.  Organizations outside the federal government are now trying to adopt PIV, but are finding that these deliberate limitations make PIV a less flexible identity standard.  Consider healthcare: PIV does not define nor provide a way to extend the data model to record clinical information like allergies or medications on the card.

A More Flexible Identity Credential Standard

As Mike Neumann mentions in his presentation from earlier this year,

ISO/IEC 24727 is a framework for interoperable IAS [Identification, Authentication, Signature] systems.

It provides abstraction at every level of an IAS system, including the card data model & associated security model, card administration, communication protocols, and authentication protocols.  Even the testing section was developed to be completely extensible.  When these concepts and this image were first presented, I was a bit overwhelmed.

This was such a leap beyond what PIV and CAC tried to accomplish that I really needed those few days to digest the breadth of the 24727 standard.  I like to think about it this way – 24727 gives

• Card operating system / applet providers, and
• Card Management System (CMS) providers

a standard way to describe the card/applet’s

• technical capabilities (e.g. crypto)
• data model
• data security model
• administrative capabilities (for personalization / lifecycle management)
• communication protocol capabilities (e.g. APDU, TLS)

for use by

• Card middleware providers (e.g. TrustBearer), and ultimately
• Client applications (e.g. Windows, Custom smart card viewer, Web services)

Before this standard, there were always some functionality limitations in layers between these components.  By functionality limitations I mean that layer x (e.g. application) could not access (or didn’t know how to access) a feature in layer y (e.g. specific data container on card).  To pick on one at a relatively high level, consider PKCS#11, commonly used in non-Microsoft browsers and Email clients.  PKCS#11 allows client applications to use digital certificates and keys stored in a variety of locations – usually in software or hardware (smart cards).  Smart card middleware vendors provide PKCS#11 modules to communicate with the smart cards that they support.  PKCS#11 allows for a single PIN or passphrase to be entered, typically to gain access to use a private key located on a smart card.  But what if different PINs are used for different keys or different operations on those keys (e.g. signing v. authentication)?  PKCS#11 doesn’t support it.

To borrow another description from Mike’s presentation, he describes two approaches to previous standards / specs:

“client-down”, e.g.

• PKCS#11 – general, but uncoordinated across API
• CSP – Single function of a single application view

“card-up”, e.g.

• All of ISO/IEC 7816 series
• (Nearly?) all middleware based on ISO/IEC 7816

ISO/IEC 24727 is the first series of standards to be designed with both in mind.

This is a helpful way to start to get a feeling for the scope of 24727.

6 Parts

24727 is divided into six parts (and ISO & IEC will be happy to take your money to download each one).

• Part 1: Architecture – The diagram you saw above, plus some more detail;  The shortest of all parts
• Part 2: Generic Card Interface (GCI) – Provides a well-defined syntax to describe any card’s data model, security model (Access Control Lists), and capabilities;  Allows middleware to talk to a card without knowing the specific card edge commands
• Part 3: Application Programming Interface (API) – Provides a well-defined syntax for client applications to communicate with the GCI;  Apps can discover data on cards they’ve never seen previously
• Part 4: API Administration – Used for secure communication to the card and lifecycle management;  This was added as  a new work item while developing the spec;  It addresses end-to-end security, connectivity, secure messaging, stack configuration & use, and interface devices (IFD)
• Part 5: Testing – Baked in from the beginning, there’s a model and test script to help prove compliance with the parts that your product claims to implement
• Part 6: Register Authentication Protocols (AP) – A maintained list of commonly used authentication protocols, such as internal authenticate and external authenticate;  Industries will need their own domain-specific APs, and this allows them to register specific APs to share with others. (See PIV for PACS or MR-PIV and PLAID for examples of a newly proposed APs that could be brought into this part of 24727 someday)

I am just scratching the surface here.  Each of these parts could be another post on its own.  There are some really interesting concepts introduced in the details.  Such as the Part 2 translation scripts – this is where the conversion from a card protocol, like APDUs and the Part 3 API is made.  In some cases, a card could actually store ISO 20060 bytecode that describes its data model and supported functions.  Middleware could then download and run this bytecode to make these translations in real-time.  This is, of course, for new cards that adopt the standard at the card level.

Transition from Existing Applications and Cards

While it would be great if every opportunity out there was a greenfield, like the Queensland Driver’s License project, there are many well-established identity programs with cards already in use, such as CAC and PIV.  24727 can be adopted at various parts.  NIST gave a demo at the workshop of a 24727 Reference Implementation for PIV smart cards.  Ketan Mehta and Hung Dang implemented parts 2 and 3 and hooked this up to a Cryptographic Service Provider (CSP) on Windows to demonstrate smart card logon.  They also connected a PKCS#11 module on both Windows and Linux to their 24727 ref imp to demonstrate email signing on both operating systems and smart card logon using PAM on Linux.  All of this was accomplished without modifying the actual PIV card at all.

During the wrap-up on the last day, Bill MacGregor said this ability to work with existing, deployed tokens was one of his two top benefits of 24727.  The other was the identity abstraction layer in part 3, which provides a tool to think about digital identities and tokens that we have not had in the past.  There are no promises that the next revision of FIPS 201 / PIV will utilize 24727, but I believe it is being considered as a possibility to extend the current PIV standard while remaining backwards compatible with existing PIV & CAC cards.

Generic Identity Command Set (GICS)

We had a Q&A session on the last day of the workshop, and I asked about GICS, which is yet another smart card technical specification that primarily came from industry (INCITS B10.12).  This presentation from Oberthur at CTST this year gives a helpful background and details about the in-progress spec.  The motivations behind developing GICS are interesting.  The presentation starts out by listing all the government endorsed standards released over the years: GSC-IS 2.0, 2.1, PIV’s SP 800-73, 800-73-1, then 24727.  Then it follows with the statement that this costs industry a lot of money to make products that comply with these changing standards, but there’s not much ROI from deploying these changes in the market.

Summer 2006: Using experiences from the development of PIV products, a group of smart card technical experts from the industry decided to work together to define a stable generic card command set that would piggyback on the PIV End Point card edge developed by NIST, but extend its reach outside of the Government area, to extend the market.

GICS is a proposal from the smart card industry to preserve the existing investments of PIV, TWIC, etc. and address the needs for greater interoperability for new card applications other than PIV (or maybe those that have derived from PIV).  GICS introduces a standard card command set, not a new card application command set.

You can see the full list of expected benefits in the presentation, but essentially GICS is trying to standardize an extensible smart card command set for identity cards so that when a card or applet vendor makes an investment to develop products that comply with this command set, the market for these products is much larger than it would be for a specific command set (e.g. PIV).  Certification (like FIPS 140) could be performed on a single GICS card / applet one time rather than an a card/applet for each different identity specification.

The technical characteristics in GICS cover a wide range of capabilities found in modern smart cards: Data objects, parser, templates, tag lists, and even On-Card fingerprint verification.  It also includes a set of common Authentication Protocols and allows that list to be extended.

Sounds a lot like 24727, right?

While it does have some similar goals in extensibility and interoperability, GICS does not go nearly as far as 24727.  It sticks to smart cards and APDUs.  It builds atop PIV to allow for PIV Interoperable and PIV compatible specs to be invented and implemented without requiring yet another applet that needs to be certified.  It stays within the smart card middleware world that we know today.  At the conference Mike Neumann said that 24727 and GICS work together.  From his presentation that I referenced earlier, “ISO/IEC 24727 defines the system interfaces; GICS defines the card commands.”

Opinion

My goal in attending the workshop last week was to learn about ISO/IEC 24727 and understand how it affects TrustBearer’s business.  Among other things, we provide middleware software that allows all kinds of applications and devices take advantage of high assurance identity credentials like smart cards.  Technical identity standards like PIV and ISO 24727 often indicate that there will be a market for the types of products that we build.

24727 is the first attempt I’ve seen at taking a brand-new look at how identity credentials and systems could be made much more interoperable.  This is an extremely extensible specification.  Data and security models can be discovered.  The communication protocols can evolve – imagine not needing to know what an APDU even is! From a technical perspective, these concepts and the proposed architecture are very impressive.  But the level of abstractions introduced in this specification couldn’t help but remind me of Spolsky’s posts on architecture astronauts.

Does 24727 have too much abstraction?  Is there really a market demand for the concepts introduced in this standard?  That is the top question in my mind.  It was helpful to hear from Alex Gagel, one of the lead architects on the Australian Queensland Smart Driver’s License project.  That smart card project is clearly the largest and most thorough implementation of 24727 to date.  Alex and his team are such early adopters of the standard that they are the editors for parts 5 (Testing) and 6 (AP Register) of the standard.  This FAQ states that the European Union Citizens Card, German Smart ID Card and German Electronic Health Card will also be adopting 24727, but to what degree I am not sure.

Is GICS a more practical step in the right direction?  I can say that from a middleware and card application provider perspective, GICS has a more well-defined scope and short-term value proposition for the U.S. ID credential market.  GICS has the luxury of building on top of an existing standard (PIV) and it’s scope us much more narrow than 24727.  Is GICS itself sufficient for the next 5 years?

<ISO/IEC $$$ rant> I do not have all the information on why ISO and IEC charge money to download their specifications, but coming from the technology / Web 2.0 industry, where companies are dying to give away their API documentation in order to drive adoption… I don’t get it.  How does charging anywhere from $95 USD to $245 USD for each part of the 24727 specification encourage the world to adopt this interoperability specification?  It just doesn’t make any sense to me. </rant>

**COUPON: On that topic, we were informed at the workshop that ANSI has an agreement with ISO/IEC to sell each part of the 24727 spec for $30 USD.  Access the ANSI eStandards Store and search for 24727 to see each part – the discounted ones are at the bottom.

TrustBearer will be keeping an eye on the adoption of 24727.  Until we see a significant demand coming from our existing customers and focus markets, we will probably not begin to adopt these concepts in our software.  That said, I would like to hear the opinions of others who stumbled across this article.  Is 24727 affecting development of your products today?  And for those in charge of identity programs, will 24727 be a cornerstone of your next ID credential?  Please email me or leave a comment.

Presentation References

NIST said that all the presentations from the workshop should be eventually published online.  For now, I’ll embed the two that I found very helpful when writing this article.

Mike Neumann’s 24727 & GICS Presentation

Oberthur’s GICS Presentation