“People are focused on one area, but you have to look at all three and the big picture,” Pattinson says. That means being able to use a handset to securely store identity credentials as well as access to public transportation and payment data.

It’s likely the mobile will store multiple sets of each type of data, Pattinson says. There may be one set of identity credentials for work and another for personal information. “We have a platform in our hands that becomes a multifunction device,” he says

It could take two to three years to define the policy issues that will guide the placement of identity credentials on secure elements, Gold predicts. Until then it’s going to be a waiting game as consumers load various identity apps in an application space that may not be fully secure.

BYOD

In a “bring your own device” world, corporations are faced with a major challenge. Consumers expect to be able to load the applications of their choice on to their devices, but leads to serious security issues in enterprise environments.

Deloitte’s take on bring your own device is pretty straightforward, Duque says. “You’re damned if you do and damned if you don’t.”

To make it easier for the corporation it can come up with a list of approved handsets from which an employee can choose. This gives the employee some options, Duque says.

Otherwise it is bring your own device, and this creates issues that can literally change on a daily basis as new handsets hit the market, Duque explains.

A company can achieve some cost savings if they don’t reimburse for the purchase of mobiles devices and employees don’t have to carry multiple devices, which makes it more convenient for them.

But the disadvantages are numerous.

Employees buy devices and try to connect them to corporate resources without approval, circumventing security. There’s an increased cost, as IT staff must support multiple devices types. Trying to keep up with the potential attacks on the different handsets can be time consuming and expensive because each mobile operating system has different attack vectors.

The cons would seem to outnumber the pros but organizations are still wrestling with the issue. Duque also says organizations need to have policies in place for device configuration, devices use monitoring, data ownership and acceptable data use.

These policies issues can get thorny, says Jim Zok, director of Identity and Privacy Assurance at CSC. “If I bring in my device and want to use it for work what happens if I download something? You wipe the phone but will I get reimbursed?” he asks. “If you have a company phone does it have an approved app list?”

The viruses and malware attacks on mobile devices are ever growing. “There’s practically no way to protect these devices and put an app on it,” Zok says.

One solution could be two kernel handsets, says Zok. This would enable the device to have a business function and a personal function with strict segregation between the two sides. If one kernel is infected the other side would be able to function normally, he explains.

Mobile PIV

In the U.S. government space, enabling the mobile will take some significant policy changes. Computer scientists at the National Institute of Standards and Technology (NIST) are working on possible solution for government employees to have secure credentials on mobile devices. NIST released a revised FIPS 201-2 draft last year, and though the draft omitted mobile ID, government smart card officials say adding the capability is imperative.

The agency is exploring three options for enabling the PIV on a smart phone or tablet, says Bill MacGregor, a computer scientist at NIST. One is additional hardware that would connect the smart card to the mobile device, another is an enhanced PIV that would fully enable all functionality of the PIV’s contactless interface and last is use of a mobile device manager and a derived credential.

Contact smart card readers that use Bluetooth, WiFi or a cord to securely connect the PIV credentials to mobile devices already exist, MacGregor says. This option isn’t the most attractive because of the cost of the hardware and the form factor. “From a usability point of view it’s awkward and not realistic,” he adds.

Enhanced PIV

The other two options seem to be more realistic but each requires policy and technology changes. The phone could be used as a credential if the contactless interface of the PIV was fully enabled, MacGregor says. The first FIPS 201 version limited the amount of information that was available from the contactless portion of the card.

If these restrictions were eliminated, near field communication devices could read the PIV and authenticate to networks, sign and read email, and complete other tasks. To do this the process for creating a secure channel between the mobile and the credential would have to be created. “It’s easy to do technically but hard for the key management,” he says.

Since any NFC device would be able to read any PIV there would have to be a secure key placed on the mobile to make sure the credential is only being read by the properly authorized device. It would be a way to authorize the device to the credential.

Secure keys would have to be issued to the mobile devices, MacGregor says. This could be as simple as a pairing PIN that could be entered into the mobile to authorize pairing. “This doesn’t require too much more functionality,” he adds.

Derived credential

The other option is a derived credential and mobile device manager, MacGregor says. This option has the PIV presented to a mobile device manager which then assigns the credential to a device. The credentials would be placed on a secure element within the mobile.