Smart cards and smart card-based devices are rapidly becoming the secure device of choice for storing digital identities.  The combination of security and portability allows them to carry credentials that can be used to easily validate a person’s identity.

When an individual uses a digital credential held on a smart card-based device to authenticate to something, the level of trust required is dependent upon the risks associated with the damage caused by fraudulent use.  As the risk levels rise, the reliance you place in the validation of the identity increases. 

With smart, secure device-based identities, this means you have to not only trust that the device itself is secure, but that the device has been issued to a person in a secure manner.  (There is no value in an individual carrying a device proving they are J Smith if they are not actually J Smith!)

By Ian Lowe 

ENTERPRISE IDENTITY DEPLOYMENTS

Smart device-based identity programs within the corporate enterprise have had mixed results.  Success has come slowly due to a number of factors including:

Complexity and Lack of Interoperability -- When deploying smart cards in the enterprise there are numerous infrastructure and technology elements that need to work together, including authoritative user data stores (directories, HR systems, etc.), Public Key Infrastructure (PKI), authentication and Single Sign-On systems, physical access control systems, biometrics, etc.  These technologies often exist as discrete silos and often do not naturally interoperate.

Lack of Policy and Process -- In many organizations there are no standard policies for issuing identity devices to users.  Without reliable processes there is a tangible risk that an identity device will be issued incorrectly, or worse, fraudulently to a user.  Establishing reliable processes is complex and requires experience and expertise. 

When combined, the above factors ultimately lead to the return on investment promised by an identity system not being realized.

A DRIVER FOR IDENTITY DEVICE DEPLOYMENT

In 2004 the U.S. President Bush issued Homeland Security Presidential Directive 12 (HSPD-12).  HSPD-12 established a standard for the identification of all Federal Government employees and contractors.  HSPD-12 requires the use of a common identification credential called a Personal Identity Verification (PIV) smart card for both logical and physical access.

HSPD-12 led to the creation of the Federal Identity Processing Standard 201 (FIPS 201), which set out the two key aspects of deploying a secure identity card:

• The technical specifications of the cards, their content and the interoperability of key systems and technologies
• The business processes necessary to ensure a consistent level of assurance between issuing and relying authorities

HSPD-12 has been an accelerator for the adoption of smart card-based identities within US Federal Government and is now providing a further catalyst for the adoption of smart cards within corporate enterprise and other non-US government environments.

DEFINING INTEROPERABILITY

HSPD-12 and FIPS 201 are paving the way towards a future where identity technologies and IT systems and infrastructure work together in harmony.  Any technology vendor wishing to provide identity solutions to the U.S. Federal government must put their products and solutions through a rigorous testing and approval process.  Once the products have been approved and certified interoperable (based on published standards) they are listed on the Approved Products List (APL) (see http://fips201ep.cio.gov/apl.php).

At the center of any identity deployment is an identity management and card/credential issuance system.

The identity management and card/credential issuance system is the central piece that unites all the necessary identity technologies and systems together to create digital identities, its key role is to bind people with devices and credentials -- creating identities.  This process is secured from both a technology and process perspective allowing digital credentials issued by the system to be trusted.

SECURE POLICY AND PROCESSES

FIPS 201 provides a clear and secure set of roles and processes for the enrollment, issuance and management of people, devices and credentials.

The roles:

Applicant  -- An applicant is the person who requires a PIV card (e.g., an employee of a federal agency).  They must first contact their designated PIV sponsor so that they can initiate the application process.  An applicant must ensure that they have accurate personal information including: (name, date of birth, contact details) and their employment status within the U.S. Government Department (agency/ department, status, role, etc.)

Sponsor  -- The sponsor is responsible for creating the initial requests for PIV credentials for those individuals under their authority.  The sponsor determines whether or not an individual is entitled to apply for a PIV card.  A sponsor is typically someone who knows the individual, e.g., their line manager. 

Registrar -- The registrar is responsible for verifying the identity of the applicant and the authenticity of their application documents and once he/she is satisfied that the documents are in order he/she will make the request for the PIV card to be issued to an applicant.  The registrar will also capture biometric data from the applicant, including capturing fingerprints and a photo.

Signatory -- The signatory is responsible for approving PIV card requests that have been processed by a registrar.  Depending on the policies adopted by an agency, this tertiary approval process may or may not be necessary depending on the card types.

Issuer -- The card issuer has the task of actually producing the PIV card and delivering it to the applicant within a face-to-face collection process.  This involves electronically personalizing the card (e.g., fingerprints and certificates) and printing the card surface.