Can derived credentials turn a phone into an ID manager?

Smartphones and tablets give users the ability to extend their workplaces far from their home offices. But concerns about security, especially within government, limit what many are allowed to do with these devices while untethered from their desks.

Civilian and defense policymakers are now advancing the idea of derived credentials as a way to use mobile devices as a common platform for remote authentication. But implementing it is proving to be problematic. 

The concept of derived credentials was unveiled by the Information Security and Privacy Advisory Board several years ago. It was also included in the last draft of FIPS 201-2, which lays out government  smart card specs. 

The basic idea is to swap the normal name and password authentication procedure with a certificate-based system facilitated by a user's mobile phone. In practice, a  credential on an employee’s PIV (personal identification verification) card would be extended to a mobile device.

Here’s a possible use case: 

A public health official with a PIV card will be traveling to a location without any access to dedicated computer with a card reader. However, she will need to access patient records that require Level of Assurance 3 (LoA 3) authentication.

As she has her mobile phone with her, she enrolls her smartphone as a derived credential from her PIV card so that she can authenticate her identity when she needs to access the patient records on the road.

According to NIST's Electronic Authentication Guideline Special Publication 800-63-1, if a user is in possession of a device such as a phone or tablet, and that device has been previously associated with another token holding an approved credential (such as a Common Access Card), the user would not have to repeat an identity proofing process just to access information on a network.

In other words, if a user has verified that he owns a phone and has passed a security token to a network with it, such as swiping a CAC, then using the same phone in the future should be no different than using the card. The phone becomes both an access token and a way to actually access a network.

However, the problem with this quickly becomes apparent. If a verified phone is lost or stolen, it makes it fairly easy for thieves to access government information because they would possess both an access point and the security token. 

To fix that problem, derived credentials can be set to expire fairly quickly after use. But this means that there needs to be an easy way for users to take their main identity token, which for government employees is normally a CAC, and present it to their phones to create the derived credential. 

Adding a CAC reader to a phone could work, but “bolt-on” solutions can double the weight and size of a phone and reduce battery life. Near field communication (NFC) is one possible solution, in which case a card would just need to get close to a phone to have its information read and verified. However, not all phones, notably iPhones, support NFC.

Also, the issuing credential token needs to be separate from the phone with the derived credential. Otherwise, it's not really two-factor authentication. So a user with a microSD card with credentials that are passed to a phone should present a red flag. The  phone could easily be lost or stolen with the microSD card attached, giving full access to anyone who picked it up.

So far, little apparent progress has been made in solving these potential problems. 

The Defense Department has been experimenting with a derived credential program in which phones could gain limited permissions to use derived credentials on secure networks. 

In the military model, a phone with derived credentials would not have the same high level of permitted access that a full CAC would grant. That might solve some of the security worries, but if a phone's access is too limited, it forfeits the benefit of working remotely that derived credentials is supposed to promote.

It’s worth noting that the bring-your-own-identity concept, is sometimes used interchangably with the idea of derived credentials. But BYOI is a separate notion altogether, and it is mostly used by nongovernment organizations to verify users for the sake of convenience. 

Whenever a website or application offers to let a user sign in using a Facebook or Google ID, it is making use of the BYOI interface, which simply involves taking the same basic information from Facebook and Google and using it to populate its own fields before granting access. 

The danger is that it presents a single point of failure, so that if a user's Facebook ID is compromised, it can unlock downstream access points.  However, that should not affect government programs as there are no known agencies looking to implement BYOI-based programs, at least for now.

As for derived credentials, with key technical problems still remaining, it may be a while before we start to see adoption of this unique but promising idea in government.