Author Archives: Brian Kelly

For Archival Purposes

You probably could’ve guessed that this blog has been retired since VeriSign acquired TrustBearer in April of this year.  We’ve also retired the trustbearer.com domain, but we still get a fair amount of traffic here, so I’m moving this blog back to it’s original WordPress URL, openidtrustbearer.wordpress.com.

Yes, this will break some inbound links, but at least the content will still be searchable. Thanks to everyone who has read and contributed over the years.

First Impressions of ISO/IEC 24727

Results of the Google search for 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

Recap of the August 2009 Government Smart Card IAB Meeting

It’s been awhile. I’ve had a few posts queued up to write, and this was one of the first. I try to attend the IAB meetings when possible, but this past August meeting was the first that I’ve been to since March. As most people in our niche identity+smart card government industry know, these meetings are a good opportunity to catch-up with colleagues and hear updates about progress at various agencies. I think all future IAB meetings should be hosted at the American Institute of Architect’s second floor conference room. The concentric circle seating layout with desks is excellent.

GSC IAB bannerSlides and audio from the afternoon’s presentations are available from FIPS 201.com. (Thanks, Avisian)

This August’s meeting kicked off with a wholehearted update from USDA’s Owen Unangst. Owen started with a historical overview of USDA’s Identity and Access Management Vision. I liked his inverted pyramid diagram that outlined this vision. Everything begins at the base with Identity. Identity has existed long before HSPD-12 was announced. HSPD-12 namely addressed the second layer, Credentials, with the PIV specification. USDA has been busy implementing the Accounts, Authorization, and Access Control layers atop credentials. It’s impressive that they’ve made progress with both logical and physical access systems, and tUSDA IAM Vision Pyrmaidhat these two historically disparate systems appear to be tightly integrated. I also found it interesting that the topmost layer, Application Integration, is only in the earliest planning stages. Implementation is far from complete.

My biggest take-away from Owen’s presentation was the method and time that went into each of their strategic planning cycles. While a lot of this is classic PMP stuff, what was interesting is that Owen said one of these cycles (Business Reqs Analysis, Gap Analysis, Portfolio Selection, and Portfolio Assessment) should never take more than 3 months. The output of a cycle is a biz case, roadmap, architecture and project plan. Three months should be more than enough time to make a decision and layout a plan to execute it. In my mind, this is why USDA will be successful in implementing their Identity and Access Management vision.

Tim Baldridge of NASA followed Owen’s talk. Tim gave a brief presentation about how a single PIV card will eventually be trusted across multiple domains and agencies, not just by the agency that issued the card. Today, some individuals are being issued cards from each domain to which they need access. Tim uses an example of a doctor from HHS who has both an HHS and DoD PIV card. Federal PKI Trust Anchors such as the Common Policy (Federal Root CA) and Federal Bridge CA (FBCA) will provide the technical infrastructure that will enable this to happen. There is still quite a bit of work to be done here, but it’s good to see that it is on the radar of leaders in the HSPD-12 space. By the October IAB meeting, Tim hopes to be able to demonstrate certificate interoperability in person. I’m looking forward to seeing this demonstration.

Bill MacGregor, an IAB regular from NIST, gave status updates on a few projects and publications. The NIST SP 800-73-3 draft is open for public comment (Actually, looks like comments were due on 13 September). This isn’t a huge update to 800-73. Looks like some good things for PIV-Interoperable cards (UUID definition consistent with NFI spec). Also, some card lifecycle stuff, “on-card retention of historical keys”. The important news is that this update should have no impact on already-issued cards.

NIST IR 7611 24727 piv stackNIST also has released an Interagency Report on the Use of ISO/IEC 24727 (NIST IR 7611). ISO/IEC 24727 helps desktop applications discover and talk to the growing number of types of identity smart cards. In the introduction of NIST IR 7611, the Transportation Worker Identity Credential is noted as similar but technically different than a PIV smart card. “The ISO/IEC 24727 framework allows any client-application to communicate with any card-application.” The document describes the structure of the NIST-developed 24727 middleware stack that was developed to communicate with PIV cards. Much of this work was based on the exisiting NIST PIV middleware demo. If possible, the source code will be released. What does “If possible” mean, Bill? Interesting stuff for folks like us.

Bill then offered a reminder in light of some recent press about RFID skimming – “Are they talking about PIV?” Probably not. Not all RFID skimming is the same – not everything can be skimmed. He suggests re-reading SP 800-116, Secton 4, Appedix A to help decided the right authentication assurance level. e.g. If you’re just reading the CHUID from a card, you don’t have a very high assurance that the card was not copied. Verify the CHUID signature, or even better, perform a mutual challenge-response with the card to have a much higher assurance that it was not copied.

Chris Lounden finished the day by giving an update on what GSA’s ICAM group has been up to. He spoke about the ICAM’s goals of making Government more transparent to citizens by making it easier to access government websites and leveraging various Web 2.0 technologies. Chris made it very clear that the ICAM’s current focus is on portable identity for non-PKI, OMB Level of Assurance 3 and below. The concepts introduced are not attempting to redefine or replace what PIV or CAC provide. When implemented correctly, applications can reach a Level of Assurance 4 with PIV or CAC.

ICAM’s approach to allowing portable citizen identities in the federal government is to “Adopt technologies in use by industry (Scheme Adoption)” and “Adopt industry Trust Models (Trust Framework Adoption)”. To assist in Scheme Adoption, ICAM is developing Identity Scheme profiles for OpenID, Information Card, and SAML (WS-Federation is to follow). To assist in Trust Framework Adoption, ICAM has published the “Federal ICAM Trust Framework Provider Adoption Process” on IDManagement.gov. The big deal here is that participation is expected from InCommon, the OpenID Foundation, Information Card Foundation and Liberty Alliance / Kantara.

This is old news now, but ICAM and the participating bodies menitoned above made a big splash about this earlier in the month at the Gov 2.0 conference. I’ll be sharing my thoughts on Open Identity for Open Governement in an upcoming blog post. As mentioned at the beginning of the post, all of the presentations (from which I’ve heavily referenced) and audio recordings (hot) from the IAB meeting are available on FIPS 201.com. I’ll look forward to seeing more familiar faces next month at the in-person IAB meeting at the Smart Card Alliance’s Smart Cards in Government conference (Oct. 27-30).

Emerging Technology Presentation from CTST

Earlier this week I gave a presentation on an Emerging Technology panel at Card Tech Secure Tech (CTST) in New Orleans. Much of the content was taken from the Virginia Security Summit presentation given a week prior, but I elaborated on using smart cards for strong authentication. A couple of the slides got into using digital certificates to prove someone’s “real” identity to a relying party using OpenID extensions and digital certificate path discovery & validation.

Where do we go from here? I would like to see some of the identity verification concepts that I touched on in the presentation be tested in a pilot. There are also opportunities here to evolve the OpenID specs and extensions, such as PAPE. TrustBearer would like to continue this discussion and explore some pilot ideas. Contact me if you are interested.

Presentation on OpenID, SAML and Authentication

This past Monday I gave a presentation as part of the Identity Management track at the first Virginia Security Summit in Richmond, VA. The audience here was a mixture of Virginia state & local technology decision makers (CIO / CTO) and implementers. This included local government, education and transportation representatives.

The session description was rather broad.

A comprehensive security plan has to start with user authentication. It is not an easy task when the range of users is constantly growing and shifting, as are potential threats. Using just one tactic is not enough – it takes a combination of technologies and procedures. This session looks at the latest technologies and approaches as well as their strengths and shortcomings.

So, I decided to give a primer on the Security Assertion Markup Language (SAML) and OpenID single sign on standards. At the beginning of the presentation I took a poll of the crowd and found that about one quarter of those in attendance (~50 people) knew something about each of these standards.

In addition to comparing and contrasting SAML and OpenID, I also talked about several strong authentication options available for each of these SSO standards. I basically wanted to convey that there are better options then making users (citizens) create yet another username & password, and various strong authentication technologies can be used with both OpenID & SAML.

One resource online that really helped me frame some ideas was the Overlap of identity technologies article published on the Google OAuth & Federated Login Research site. This is an excellent summary authored by Eric Sachs, Ashish Jain, Paul Madsen. Thanks, guys.

I’m going to be giving a similar, but more authentication focused talk at CTST in New Orleans next Tuesday, May 5. Track D: Emerging Technology, D14: Smart Cards, Tokens & Digital Identity, 4:00 PM – 5:30 PM. Hope to catch some of you out there.

Calling all device providers: Get your own OpenID & SAML Provider

Just over a year ago we launched the first* OpenID Provider that exclusively supported smart cards and other USB security devices. Last summer we added SAML login support for Google Apps & Salesforce.com. One of the groups of people that has been most interested in our OpenID provider has been device manufacturers: the companies that make and resell smart cards, biometric readers, and various other types of USB security devices.

TrustBearer OpenID gives these device providers a simple way to demonstrate the value of their devices to end users. It lets users login to useful online services with a very secure cryptographic hardware device. The one question that these customers might have is: Who is TrustBearer?

We are answering that question today by making it irrelevant! TrustBearer is now offering a service to create and host custom-branded OpenID & SAML Identity Provider to security device providers and resellers. This service includes,

  • A custom URL (such as https://superCard.mySmartID.com)
  • Custom graphics and theme for the site
  • Custom application settings & links for OpenID & SAML sites that are relevant to their customers

We are charging a one-time set-up fee and a monthly fee to create and host this service. Please contact us if you are interested.

Custom OpenID / SAML Identity Provider

* I believe we were the first to launch an OpenID Provider that exclusively supported smart cards. C’mon, it made Slashdot.

Recap of the March 2009 Government Smart Card IAB Meeting

It’s been a busy year so far. Last week we began our full-time presence in DC. I moved from Fort Wayne to DC and will be working in the city for the foreseeable future. Our company headquarters will stay in Fort Wayne, and will continue to be the primary site of our software engineering team. The DC office will serve as both a business development and client support location. Most of our customers are in the greater-DC area, and it makes a lot of sense for us to have full-time staff here. It is good to be back.

GSC IAB banner

Every month or so, the Government Smart Card Interagency Advisory Board (IAB) holds a public meeting to discuss the HSPD-12 State of the Union. There are several presentations given about notable smart card and related projects, and there’s plenty of time for Q&A as well as networking. The meetings are attended by both government employees & contractors as well as many vendors. Normally, we wouldn’t make a special trip from Fort Wayne to DC for these meetings, but now that I’m local I’ll be attending these meetings more often.

For this March 5th, 2009 meeting located in the GSA Auditorium we got to hear from the following speakers:

  • Tim Baldridge (NASA) gave the opening and closing remarks, as well as an update on the PAIIWG id, which is being built on the PIV GUID.
  • Judy Spencer (GSA) talked about the future of the government’s Identity Management Strategy and the creation of the Federal Identity , Credential, and Access Management (ICAM) sub-committee
  • Jarrod Frahm (Dept. of State) gave an interesting presentation on how the Dept. of State is using a separate smart card with Match-On-Card Biometrics for authentication, and mentioned the department’s plans for merging this MoC smart card with their PIV smart cards.
  • Craig Wilson (FEMA) gave a summary of the impressive Winter Chill exercise that took place earlier this year. First Responders with PIV, CAC and FRAC smart cards performed geo-location-aware, near-real-time electronic validations across the US. This exercise was used to demonstrate the capabilities of validating cardholders in the field who might be relocated during a disaster.
  • Steve Duncan (GSA) was scheduled to give an update on GSA’s Managed Service Office (MSO) Shared Service Providers, but had to cancel at the last-minute.
  • Bill MacGregor (NIST) followed-up on the Dept. of State’s match-on-card biometric project and commented on NIST’s stance of MoC support on PIV cards.

The presentations should eventually make their way up to the GSC IAB web site. FIPS201.com has posted audio from previous IAB meetings. I learned something new from all of the presentations. I’ll comment on a few items that I found especially interesting.

ICAM: The Future of the Government’s IDM strategy

  • The ICAM sub-committee is being co-chaired by Judy Spencer & Paul Grant (DoD). The fundamentals haven’t changed: The IdAM guidance will be built upon the eAuthentication’s M-04-04 and NIST SP 800-63.
  • The eAuth portal will be moving from SAML version 1 to 2. 
  • eAuth will be partnering with Liberty Alliance for levels 1 and 2.
  • Commercial digital certificates that are cross-certified with the Federal Bridge are now available from VeriSign. (See the Press Release)
  • ICAM’s next steps are to publish a PIV Interoperability for non-federal entities guide & publish an ICAM roadmap & implementation guide. Also, they plan to establish a Citizen Outreach Focus Group

BLADE / PKI – Department of State

  • BLADE: “Biometric Logical Access Development & Execution”
  • Before PIV cards were widely available, the Dept. of State started a pilot program that allows users to access applications using a smart card and match-on-card biometric applet in-place-of or in-addition-to a PIN. Due to the size & compatibility requirements of the MoC applet, DoS could not include this functionality on their official PIV cards. Precise Biometrics is providing the MoC applets and readers.
  • DoS is using the BLADE smart cards to provide PKI logon via kerberos. Their long-term goal is to provide logon to all DoS websites.
  • DoS is currently trying to create a hybrid PIV / BLADE-MoC smart card – they need more storage space on the smart card chip. Until this issue is solved, DoS cardholders will use the BLADE card for logical access and their PIV cards for physical access.
  • One of their biggest challenges is hardware and software deployment overseas.
  • The interesting part of this project is that it has re-ignited NIST’s interest in Match-On-Card biometrics support. Bill MacGregor (NIST) commented on this in a later presentation.
  • Jarrod Frahm gave the presentation and he is the BLADE PM. Mark McCloy is the PKI PM. Steven Gregory is the IIB Branch Chief.

NIST’s thoughts on Match-On-Card for PIV

  • Bill MacGregor (NIST) gave a follow-up presentation on how MoC is being considered as a PIN replacement option for PIV cards. 
  • Motivations for MoC support include improved usability and improved security & reliability
  • What’s not changing: Backwards compatibility with existing PIV card standard, the authentication model, FIPS 140-2 Level 2 requirements, metrics for biometrics testing (MINEX)
  • The NIST process for adopting new technology recommendations: 1. R&D (NIST IRs, papers, presentations), 2. Best Practice Guidelines (Special Pubs), 3. Standards (ANSI, ISO and, rarely, FIPS)
  • NIST R&D for MoC includes, so far:
  • Moving forward:
    • FY 2009: Revisit & formalize requirements
    • FY 2009: Recommend an implementation approach
      • consider ISO/IEC 24787 mapping (updated on 3/11/09 – Thanks, Bill)
      • propose modifications to 800-73, 800-76, FIPS 201
    • “Enable a direction based on merits.”

“Winter Chill” – FEMA’s electronic validation exercise

  • Craig Wilson, Senior Consultant for FEMA, gave an exciting presentation on FEMA’s latest in-the-field exercise dubbed “Winter Chill”. 
  • The exercise involved state and local Federal Emergency Response Officials (FEROs) and representatives from DoD and FEMA.
  • The exercise included moving these representatives around from one site to another and validating their identity using electronic validation of PIV, CAC and FRAC smart cards as well as state-issued Drivers Licenses.
  • In addition to the real-time validation of these credentials, the geo-location was tagged and reported in “near real-time”. (I guess they didn’t want to commit to saying “real-time)
  • Duane Stafford, representing the State of Virginia (VDOT?) talked about how VA provided the geospatial awareness technology.
  • The software was demo’d during the meeting. 
  • As we entered the IAB meeting there were two entrances being manned by some of the same representatives that validated credentials during Winter Chill. The high-assurance entrance scanned PIV cards. The low-assurance entrance scanned driver’s licenses. My newly-issued driver’s license passed with flying colors.

Proposal of a new PIV GUID 

  • Tim Baldridge (NASA) gave a summary of the work done to evolve the PIV FASC-N.
  • Problem: Current PIV card ID number (FASC-N) was not designed to support non-federal PIV Card Issuers (PCIs).
  • Proposal: A GUID (128-bit value, i.e. HUGE) shall be assigned to each issued PIV card according to RFC 4122.
  • Dependencies: 
    • The proposal infers a requirement to update the data model for signed objects, including certs, to include the GUID in addition tot he FASC-N.
    • Development of new functionality in the PIV standard and guidance to support “Mutual Registration” by Relying Parties in co-operation with the PCI.

After the PIV GUID presentation and wrap-up there was some more Q&A. There was some more discussion around this Mutual Registration topic and Match-On-Card biometrics. The part that I found particularly interesting was the MoC Philosophy. The idea is simple:

I control access to my card with my fingerprints that I enrolled.

This really helped me grasp a new motivation for MoC. The fingerprint does not belong on the server. If a user is using it in place of a PIN, it should be treated like a PIN. Only the user should be able to enroll their MoC fingerprints. There may be an unblock function that the server provides, but the user should be in control of the enrollment process and know that their fingerprint templates are only  stored on the smart card.

I hope this was helpful to those who couldn’t attend. Now that I’m around DC more often, I’d be happy to meet-up more often in-person. Also, I recently launched the company’s official Twitter feed. Send me an @TrustBearer reply on Twitter to get in-touch.