User names and passwords are easy to use on laptops, PCs and mobile devices, but higher assurance credentials such as cryptographically secure smart cards can be cumbersome to use across various platforms and devices.

This has brought about the idea of derived credentials, which would basically enable a user to spawn lower assurance credentials onto different platforms to perform other tasks. For example, a government employee could use their secure agency-issued PIV smart card to create another digital credential for their mobile device. This derived credential could then be used to check and potentially even sign email via the handset.

“We’re learning that the PIV is great for many things but you need another form factor,” says Kevin Kozlowski, vice president of Government Initiatives at XTec.

The push for derived credentials is coming out of the federal government and the U.S. Department of Defense, says Ray Wizbowski, formerly of Gemalto and now at Datacard. “The government has been looking at ways for officials to securely use credentials on mobile devices,” he explains.

The last draft of FIPS 201-2, the government smart card specification, introduced the idea of derived credentials. This version of the spec released in the fall of 2012 has the PIV presented to a mobile device manager that then assigns a sub-credential to the device using a parent-and-child model. The derived or child credential would be placed on a secure element within the handset or tablet.

Only a portion of the PIV functionality would be available with the derived credential and it’s possible that different derived credentials could be issued depending on the level of assurance necessary.

Derived credentials were also mentioned in NIST’s Special Publication 800-63-1, which focused on electronic authentication. But this prior mention was in a generic form and not specific to PIV.

It will require additional special publications to flesh out the details of how derived credentials will work. These publications will be needed so that vendors can create new products conforming to the revised spec.

Some vendors are not waiting and are already working on solutions.

XTec has run some pilots using derived credentials on iPads and iPhones but the company can place the credentials on any mobile platform, Kozlowski says. He uses the derived credentials on his iPhone to validate his identity instead of using his PIV-I. With derived credentials, the PIV is essentially serving as a Certificate Authority that signs a certificate that is placed on the mobile device, he explains.

In this early example, the system emails a certificate to the mobile device to be loaded and used from there. Eventually, he says the certificate will need to be directly loaded on the SIM or other Hardware Security Module to prevent possible tampering.

Policies surrounding derived credentials need to be sorted out before they can be used in real deployments. Differentiating the derived credentials and making sure the primary one cannot be duplicated are issues that must be addressed, Wizbowski says. “Is it a truncated part of the certificate that identifies it as coming from a mobile device so it’s not giving full access?” he asks. “The technical pieces are still in the formative stages. A lot is being proposed and there are many ways to address it.”

How long should the derived credentials be valid? A day, a week or a month, Koslowski asks. And what applications can accept the derived credential instead of the primary? “Some apps you might want to mandate the card because of the security,” he adds.

The government market might be the main focus for derived credentials in the short term but as high assurance identities become more commonly available the idea could catch on in the consumer market as well, Wizbowski says. Looking at the commonly used four levels of assurance, each one could be a credential. “You could issue low-level credentials for social networking and higher level ones for email and other uses,” he explains.

New use case: Derived credentials expedite physical access transactions

The main discussion around derived credentials is using them on mobile devices to access email and secure web sites. But HID Global is working on a scheme that would see derived credentials placed on the same smart card to expedite physical access, says Bob Dulude, director of Federal Identity Initiatives at HID.

It can take as long as 2.5 second to verify a PIV certificate for physical access, Dulude says. “The certificates are very large, 2K, and it can take a long time to read that data and validate it, not the best performance at the door,” he explains. “With prox it takes less than half a second.”

HID wants to put a card verification certificate on the PIV to enable quicker processing at the door. “It’s constructed to have the minimal data necessary to open the door,” Dulude says.

The derived certificate would be tied to the cardholder’s PIV certificate so that revocation lists could be checked without any changes to the existing infrastructure. “Using a derived credential reduces the size and improves performance,” Dulude says.

---

Related articles:

The Mobile ID Experiment FIPS 201-2 includes derived credentials, beefed up contactless, post issuance updates What is an identity ecosystem?