HID Global on PIV and PIV Competition: Part One

| 0 Comments | 0 TrackBacks

Page:   1   2   3   4  Next  »

Are nonfederal entities--especially those not regularly interacting with federal agencies--finding value in following the standards defining FIPS-201 PIV-I and PIV-C credentials? Our latest interview on the topic was with Kevin Graebel (pictured), Graebeljpg.jpgproduct line manager, HID credentials, HID Global, who dug into the query with us.

In this first half of our interview, edited for length and clarity, we talk about how the FIPS 201 standard mirrors best practices enterprises may already be employing and which card "edge" technologies compete with PIV and how those may influence its reach.

*****

Sharon J. Watson, Security Squared: I want to start with that real basic question: are enterprises not under any mandate to comply with FIPS-201 PIV-I or PIV-C credentials choosing to follow any portion of the standards laid out in FIPS-201 and why or why not?

Kevin Graebel, HID Global:
  At its core, FIPS-201 is really just a set of best practices that have been adopted by the federal government. Those best practices have really been around for a long time in the physical access control industry. In fact, HID published a document in 2008, a white paper outlining what access control industry best standards are. There are a lot of good comparisons between the physical access control and logical access control best practices
compared to basically what's been outlined in the FIPS-201 standard. I could walk you through those the parallels if you'd like.

SJW
: Sure. That sounds fine

KG
: The first component of the FIPS-201 standard defines how you can validate what the card is, if the card itself is legitimate. The standard outlines three different levels of validation. The first is identifying that the card is an authentic card, that it hasn't been tampered with. The next is what they called validating the credential, which is checking the information that's actually stored on the card and basing a person's access levels on that information. The final level of validation that's outlined is identifying the card holder, which is essentially assuring the person presenting the card is the person who's supposed to be holding that card.

Going back to the actual validation of the card, the physical token, the first step is ensuring that card is legitimate. The FIPS-201 standard has outlined requirements both for visual inspection of the card, in calling for holography or other visual security elements that could be added to the card. That way, a security guard looking at the badge will be able to tell that the card is legitimate, that it was issued by a federal government entity.

Really that's nothing new to the industry. Enterprises have been able to purchase custom holography for many years. Fargo has been selling custom over-laminates and custom card bodies for the last 10 or 15 years. It's really an easy way for an organization to add something unique to the card that someone can very quickly look at and at the very least know the organization that issued it. The federal government has built in a visual security elements into the card body, and that's a method they happen to use. There are a couple different ways to get the same end.

FIPS-201 also defines the information stored on the card. One of the methods used to verify is the CHUID [cardholder unique identifier] method. Incorporated with that is the FASC-N [Federal Agency Smart Credential number] along with a digital certificate to verify the data has not been tampered with on the card. It's a method for authenticating between the card and a reader to ensure the card is a legitimate PIV credential.

It is actually very similar to a process known as mutual authentication that's done by iClass and MiFare technologies.  It's just the method for implementing; it is slightly different. It's a best practice that's been established for communication between the card and the reader. It's something that many organizations that have been sold on the security of iClass and MiFare have decided to incorporate into their access control systems.

Page:   1   2   3   4  Next  »

Are nonfederal entities--especially those not regularly interacting with federal agencies--finding value in following the standards defining FIPS-201 PIV-I and PIV-C credentials? Our latest interview on the topic was with Kevin Graebel (pictured), Graebeljpg.jpgproduct line manager, HID credentials, HID Global, who dug into the query with us.

In this first half of our interview, edited for length and clarity, we talk about how the FIPS 201 standard mirrors best practices enterprises may already be employing and which card "edge" technologies compete with PIV and how those may influence its reach.

*****

Sharon J. Watson, Security Squared: I want to start with that real basic question: are enterprises not under any mandate to comply with FIPS-201 PIV-I or PIV-C credentials choosing to follow any portion of the standards laid out in FIPS-201 and why or why not?

Kevin Graebel, HID Global:
  At its core, FIPS-201 is really just a set of best practices that have been adopted by the federal government. Those best practices have really been around for a long time in the physical access control industry. In fact, HID published a document in 2008, a white paper outlining what access control industry best standards are. There are a lot of good comparisons between the physical access control and logical access control best practices
compared to basically what's been outlined in the FIPS-201 standard. I could walk you through those the parallels if you'd like.

SJW
: Sure. That sounds fine

KG
: The first component of the FIPS-201 standard defines how you can validate what the card is, if the card itself is legitimate. The standard outlines three different levels of validation. The first is identifying that the card is an authentic card, that it hasn't been tampered with. The next is what they called validating the credential, which is checking the information that's actually stored on the card and basing a person's access levels on that information. The final level of validation that's outlined is identifying the card holder, which is essentially assuring the person presenting the card is the person who's supposed to be holding that card.

Going back to the actual validation of the card, the physical token, the first step is ensuring that card is legitimate. The FIPS-201 standard has outlined requirements both for visual inspection of the card, in calling for holography or other visual security elements that could be added to the card. That way, a security guard looking at the badge will be able to tell that the card is legitimate, that it was issued by a federal government entity.

Really that's nothing new to the industry. Enterprises have been able to purchase custom holography for many years. Fargo has been selling custom over-laminates and custom card bodies for the last 10 or 15 years. It's really an easy way for an organization to add something unique to the card that someone can very quickly look at and at the very least know the organization that issued it. The federal government has built in a visual security elements into the card body, and that's a method they happen to use. There are a couple different ways to get the same end.

FIPS-201 also defines the information stored on the card. One of the methods used to verify is the CHUID [cardholder unique identifier] method. Incorporated with that is the FASC-N [Federal Agency Smart Credential number] along with a digital certificate to verify the data has not been tampered with on the card. It's a method for authenticating between the card and a reader to ensure the card is a legitimate PIV credential.

It is actually very similar to a process known as mutual authentication that's done by iClass and MiFare technologies.  It's just the method for implementing; it is slightly different. It's a best practice that's been established for communication between the card and the reader. It's something that many organizations that have been sold on the security of iClass and MiFare have decided to incorporate into their access control systems.

<!--nextpage-->

The next level of validation best practice outlined in FIPS-201 is how you verify that the credential is authentic. In this case, the credential is the information stored on the card. It's really the heart of identifying that individual. With the FIPS credential, they use a digital certificate that's placed on the card that contains all of the users' information and their access levels.

A process known as PKI verifies the certificate is legitimate, based on the Federal Bridge that links up to the Federal Certificate Authority to make sure that user's information has not been tampered with or revoked.

This is a very advanced technique, and it's not widely used in physical access control today but that technique has been widely adopted in the logical access control system for logging into computers. Many different companies in the market sell PKI-based cards and logical access control systems for managing them. It's a very similar process they go through to validate their identities.

Even with physical access control, it is similar to how iClass or MiFare or even a proximity card contains a unique card number stored on the card. With physical access control systems today, once the card has been validated, it sends its unique card number to an access control panel that's on the backend of the system, and it checks that card number against a database stored there to see if that user has the right to enter into the area or gain access to whatever that card panel is protecting. It's not as advanced a security method as PKI but fundamentally you're checking to see if the information stored on the card is legitimate so it's a similar process.

The final component of the FIPS-201 best practice is the process of identifying the card holder and ensuring the person presenting the card is the person who is supposed to have that card. Historically the way that has been done is visual inspection, looking at the photograph printed on the card and matching it to the person holding it.

FIPS identifies the size and location of the picture on the card to make it easy for a security guard or whoever to have that first pass at making sure that person is who they say they are. That's nothing new, that's been done for many years.

For electronic verification, the FIPS standard outlines two methods for identifying a person is who they say they are. That includes a PIN. The person has to enter in a PIN when they present their card to ensure they at least know that password before they are allowed access. It also includes a biometric factor, which is typically a fingerprint.

In the access control industry, this is known as multifactor authentication, it's typically up to those three factors: it's something you have, which could be the card; something you know, which could be the PIN usually, and then something that you are, usually a fingerprint in this case.

The FIPS standard outlines different levels of what it calls exclusionary areas based on how many different factors you have to provide to gain access to that area.

<!--nextpage-->

SJW: If enterprises use variations of the best practices spelled out in the FIPS-201 standard, the credential they come up with might not necessarily be considered a PIV I or PIV C credential.

KG: That's correct. There are many different variations on the same best practices that an organization could choose to adopt. To get a PIV I credential, the card has to be issued by a government certified entity, they need to have access to the Federal Bridge which allows them to link up to the Federal Certificate Authority to be able to validate any certificates that are accessed during the authorization process. So it's a very complex system for organizations that don't necessarily need to work with the federal government.

Now many of them might choose to adopt a PIV C, which would essentially be that same credential but it has not been issued by a federal authority so it couldn't be used to identify themselves with the federal government. But they would still be following to the "T" all of the requirements outlined in the FIPS-201 standard.

Organizations would sort of pick and choose which of those different items they would like to adopt out of the FIPS-201 standard. As far as the visual layout of the card, most organizations wouldn't follow that exactly because they would like to incorporate some aspect of their branding into the credential. They might have some minor differences in how they rank people or how they prefer to control the different levels of credentials in their organization so they are likely to make slight tweaks to how the information is printed on the card.

When it gets to the actual card technology itself, most of the card suppliers that sell a PIV credential allow you to purchase the same base technology with modifications to it. This leads into how FIPS-201 has influenced technology and processes.

<!--nextpage-->

Competing Edges

Several different suppliers on the market today provide logical access systems and contact chip smart cards that allow you to work with different functions of that card. Microsoft has a smart card interface, Base CSP, that specifies the communication between the computer and the contact chip smart card for purposes of different encryption processes.

In addition, there's something known as PKCS#11, which is a different standard. Several different third party developers, such as ActivIdentity, create middleware card interfaces for that. PIV is essentially a competing standard to those.

PIV defines the interface between the card and the computer. For the communication between the card and the reader to have any value, the card management system needs to be able to configure it with that communications protocol and any other applications you want to be using [with] your card need to be set up to work with it as well.

For example, if you want to use Microsoft Outlook to encrypt an e-mail and you want to use your contact chip smartcard to do that, right now I don't think Microsoft Outlook supports PIV as an encryption standard. But it might support Microsoft's Base CSP, so that would define which card standard an organization would want to purchase simply based on which of the different applications they would like to be using their card with.

But even with the PIV standard, it seems to be gaining some ground in nonfederal space. With Windows 7, Microsoft has released essentially PIV middleware. It's included in the operating system itself so a customer that purchases a card based on the FIPS-201 standard doesn't need to install anything on their PC to make it work. It's just basically a plug-and-play operation for them. As more companies are recognizing this, and they continue to develop their applications that utilize smart cards, it's likely they'll want to take the path of least resistance and look at a PIV card edge.

***
In part 2 of this interview, posting May 25, 2010, Graebel talks more about the factors influencing PIV adoption for nonfederal enterprise use, PIV use in physical access control, and its international reach.


No TrackBacks

TrackBack URL: http://www.securitysquared.com/cgi-bin/mt/mt-tb.cgi/218

Leave a comment