Eugene Liderman is director of product management, Public Sector, Good Technology.

Just because smart card and smartphone both start with the word "smart" doesn't mean it's a smart idea to integrate the two.

As someone who has been in the mobile security space from the beginning, it's been fascinating to watch end users struggle with getting their government-issued Common Access Cards (CAC) working with their PDAs and now smartphones, even though from a technology perspective it's been possible for many years now. Whether on Blackberry, Windows Mobile, iOS or Android, believe it or not, a technology gap hasn't actually been the biggest issue but rather challenges related to user experience and cost.

Let's start with the user experience:

When a CAC is plugged into a desktop keyboard or directly into your laptop, a user is able to use it to login to his personalized desktop and any back-end service you access through that device – the perfect combination of seamless and efficient. Unfortunately the mobile experience is quite the opposite. Smartphones running iOS and Android do not support CAC logon to the device and it's not a built-in service of the mobile OS. Because of this, users still need a traditional password to logon while also attaching a bulky reader to their smartphone. After this setup, the user inserts his CAC and uses a third party application that has smart card integration. When access to a certain application and/or data set is needed the user must complete the process all over again.

Now let's look at challenges related to cost:

For desktop or laptop use of a CAC, users can order either a laptop or a USB keyboard with a built-in smart card reader. In the mobile world, smartphones do not have built-in smart card readers. External readers that plug in or connect via Bluetooth cost anywhere upward of $150 each, and case-based readers range even higher in price per unit. In the end, smart card readers often cost as much as (or more than) the phone.

Some agencies have skipped smart card integration and instead utilize a soft token approach that stores an alternative set of credentials directly on the smartphone. Unfortunately this does not have broad appeal, as it's essentially a second set of credentials in addition to the ones stored on the user's CAC.

To resolve the issues seen in utilizing traditional smart cards and soft token credentials on smartphones the National Institute of Standards and Technology (NIST) has provided FIPS 201-2 and NIST SP 800-157 guidance, which specifically covers the use of a derived credential as a bridge between the two. The derived credential – true to its name – is derived from the credentials on your smart card and stored in soft token form and should be secured using the hardware protection the smartphone/tablet may offer.

This new method has picked up a lot of momentum, as the Air Force, Navy and Defense Information Systems Agency (DISA) are all conducting their own derived credential initiative programs. The Department of Defense CIO, which began piloting them in September, also issued a memo on expanding the use of derived credentials across the department's agencies and services in 2015.

At the moment, the detailed definition of a derived credential and the actual implementation/approach to deriving and deploying it is still somewhat broad and interpreted differently by various agencies and commands, but it's a step in the right direction. In due time, derived credentials will provide users balance between complying with the security requirements that are set forth while still maintaining an easy, seamless user experience.

Share:
More In The Compass