IDmachines

The Differences Among PIV, PIV-I and CIV Credentials

2012-01-20T08:52:00.000-08:00

IDmachines put together the following for the Smart Card Alliance newly renamed Access Control Council in support of one of its first deliverables.

HomelandSecurity Presidential Directive 12 (HSPD-12) mandates a standard for a secureand reliable form of identification to be used by all Federal employees andcontractors. Signed by President GeorgeW. Bush in August 2004, HSPD-12 initiated the development of a set of technicalstandards and issuance policies (FIPS 201) that create the Federalinfrastructure required to deploy and support an identity credential that canbe used and trusted across all Federal agencies.

The policy, processesand technology in FIPS 201 support multiple other special publications (SPs)specifically written for FIPS 201 and build on other National Institute ofStandards and Technology (NIST) standards and SPs that support best practiceacross information technology and security domains. Importantly these standards also build oninternational and national standards such as the Internet Engineering TaskForce (IETF), the International Telecommunications Union (ITU), the Institute ofElectrical and Electronics Engineers (IEEE), the Security Industry Association (SIA), the International StandardsOrganization (ISO), the for the Advancement of Structured Information Standards(OASIS) and others.

		PIV		PIV-I	CIV
Policy
Breeder documents	Follows FIPS 201		Follows FIPS 201			Follows the organization’s policies
Background checks	National Agency Check with Investigation		None required, directly impacts level of suitability for access			None required, directly impacts level of suitability for access
Process
Application Adjudication Enrollment Issuance Activation	Follows FIPS 201, including separation of roles, strong biometric binding		Follows FIPS 201, including separation of roles, strong biometric binding			Follows the organization’s policies
Technology
Card data model	Must follow SP 800-73		Must follow SP 800-73			“Follows” SP 800-73
Current Primary Credential number	FASC-N		UUID			UUID (expected)
Object Identifiers	Federal Bridge		Federal Bridge			Organization Internet Assigned Number Auhority (IANA) (if exists)
Level of Assurance
Trust	High		Trusted identity and credential but not suitability of individual for access			None

The policy, processand technology applied to each of these credentials results in a level ofassurance and interoperability and ultimately the extent to which you can trustand use it externally. As shown in thechart the policy and process around PIV and PIV-I ultimately provide theinteroperability and trust of the credential. Identity and credential infrastructure requires an additional investmentin order to adhere to and maintain these policies and processes. In return users and organization can accessubiquitous identity and credential services with the benefit of high assurance intheir federated transactions.

PIV, PIV-I, PIV-C, CIV-C, IDm (It Don't matta)

2011-12-01T06:46:00.001-08:00

The Smart Cards in Government conference last month broughttogether a very good group of users, solution providers and trade associations’members to engage on the state of the practice on trusted identities and theuse of secure elements. IDmachinescontributed to a pre-conference workshop on PIV-I physical access control andan e-Gov overview for the Kantara Identity Summit. And despite budget challenges there remainswork to be done with standards and programs (acronyms) such as NSTIC, ICAM,OpenID, OAuth, PIV and PIV-I.

One set of acronyms that were described at the conferencewere PIV-I, PIV-C and CIV. So to(quickly) go through how we got here... First there was PIV (FIPS 201) that begat PIV-I that due to cost begatPIV-C. When PIV-C became known as PIVcompatible it was bad. Compatibility wastoo close to interoperability in some minds so a new acronym wasrequested. That this lead to theCommercial Identity Verification Credential and CIV, which has nothing to dowith identity verification, is another topic for discussion, but onward withPIV-C.

Yes PIV-C as PIV compatible was bad, but PIV Counterfeit isexactly what it is and for this reason PIV-C is a useful way to look atit. Further the reason it’s acounterfeit can be from the policy and procedures followed in issuing it aswell as using un-trusted keys, certificates or other web tokens. The government should have realized it’s theuse case that it doesn’t like not the acronym, ergo PIV-C PIV counterfeit. CIV should have never come to pass and it’sreally not that good an idea to be out there.

Standards for identity proofing and agreement on theauthoritative sources of attributes and privileges are one of the current gapsin the identity ecosystem. PIV-C basicallyallows ad hoc enrollment and self assertion. Technically you have a number keys, certificates, interfaces, and atpresent one or a small number of applets. Easy to implement as physical access enterprise credential where thereis no federation, but a web credential needs to be interoperable. Is the National Strategy for TrustedIdentities in Cyberspace developing un-trusted identities? I am sure not. Other part(s) of government’s paranoia overcounterfeit credentials has wagged the dog and resulted in a classificationthat really didn’t need to exist. Thereare already, albeit limited, enterprise multipurpose PKI credentials. Really we should keep people focused on PIV-Iand we should keep to a minimum PIV-C and CIV-C, etc.

Ironically, all during the conference it was easy to makethis point. I used a counterfeitcredential. Yes it was wrong and says soon the back, I didn’t do it with the intent of documenting it, and it was animmediate way to demonstrate to the members of the steering committees for theUnited States Federal government physical security and ICAM initiatives goingin with me. It helps to documentsecurity theatre. I used my demo FRACcredential to get into the Reagan building. (My Federal colleague took aphoto). Test credentials are useful andvery real looking. Mine had a nice shinychip, security lamination and 4 certificates of course all issued by a rougecertificate authority. These hardlymattered since it was as a flash pass that I put it to work. It doesn’t matter what acronym you give it,it’s a counterfeit flash pass.

This gets to the real point. Rather than focus on acronyms focus on strong authentication. This does not mean vague requirements butrather electronic verification including trust of the issuer.

Counterfeits exist; ask any teenager, the way to beat themis not to rename them it’s to make sure you do a real job of checkingthem. The security theatre of the flashpass at government buildings and for that matter at airports (ultravioletpens?) has to cease.

And it’s about more than authentication.

Make sure you have established identities to theassurance level needed for individuals’ roles.
Make sure there is a separation of roles among thepeople enforcing the process
Make sure the identity is bound properly to thecredential
Perform cryptographic challenge of the credential andvalidation of issuer along with checks against other access control (blackand/or white) lists.
Don’t truncate the identifier (which is different thanhashing them and yes, you will need to upgrade infrastructure to accomplishthis).
Match the level of authentication to the assets beingprotected.
Protect secrets, personally identifiable informationand the cryptographic processing.
Use standards based technology and policy.
Only procure systems that can do this.
Onlyprocure systems from vendors and integrators that have demonstrated they can dothis at a system level. (The weakestlink is the strength of the chain).
Implementand automate the controls that audit and alert to the above.

Guidance can and will need to provide more details includingcurriculum, security controls, specific approvals (products and certifications)that support the above. This takes times(it’s been going on for decades). Offera glass of water (or age and situation appropriate beverage) not a firehose. While this may not be simple itcan be simply said. And it can start ina way that not an acronym need be found.

The Registration Authority : Why an Authoritative Identity Store Needs to be the First Investment in the Enterprise Identity Infrastructure

2011-05-24T12:51:00.000-07:00

Best Practice Lessons from FIPS 201

Federal Information Processing Standard 201 titled Personal Identity Verification (PIV) (and the Draft FIPS 201-2) often gets thought of a standard defining the technology associated with strong authentication, digital signing and encryption using digital certificates and public key infrastructure (PKI). While the standard and the underlying special publications do define the credential technology components an equally important part of the specification addresses best practices for establishing and identity and employment (enrollment) suitability.

The first phase in the FIPS 201 process of establishing an identity that can provide high assurance and interoperability is a crucial aspect of the standard where PIV and PIV-I Interoperability (PIV-I) establish best practice and warrant focus by identity professionals. This identity creation process needs to be a template for any trusted identity. Much of what is written about PIV and PIV-I gets caught up in why PKI, when just as much, if not more, attention needs to be paid to why you need to create an enterprise identity service and the architecture to support this. And fundamentally why there needs to be a single authoritative source for identity data also known as a registration authority. This needs to be the case even if organizations have opted for identity as a service and outsourced their PKI.

One of the best results from the Federal Identity, Credential and Access Management (ICAM) initiative is the separation of the lifecycle management of each of the ICAM components. In order to progress in the ICAM maturity model organizations must start with an enterprise service to support the identity creation function and as a result support the creation of a registration authority. A registration authority can serve as a powerful focal point to implement policy for the creation of a range of credentials. This can range anywhere from high assurance multi-step, multi-role, multi-person registration to doing self assertion via a simple web registration portal.

One of the important things that come from starting with the creation of a registration authority is the ability to create an identity vault that properly safeguards data. The other significant benefit is that it invokes an architecture that properly restricts the frequency of access to data that by its very nature is long lived and does not need to be updated. In fact the ICAM process has an underlying logic that comes from the inverse relationship to the frequency with which data needs to be accessed and its life-cycle. Identity data is long lived and seldom needs to be accessed (but still needs to have a chain of trust maintained) while certification related attributes have shorter life-cycles and are more frequently accessed. The following inverted triangle can be used to represent these relationships.

The enterprise registration authority and the associated identity vault sits at the bottom of the triangle. It is the building block on top of which enterprises will implement ICAM. It provides the foundation for enterprise governance, risk management and compliance by providing a common identity footing across these regimes and activity. ICAM needs to be done in order; identity then credentials, then access, then management of other attributes and certifications. In order to take the first step in getting the “I” in place a registration authority needs to be put in place and organizations need to look to PIV and PIV-I and the process they define. When doing this organizations need to make sure they put in place a process that meets the highest level of assurance they will need to meet. Supporting lower levels of identities is easy to do from a high assurance identity infrastructure. Supporting higher levels of identity is extremely difficult if not impossible with a low level of assurance identity infrastructure. The need to get things right at the start and to support the full range of use cases is all the more reason to adopt PIV and PIV-I as enterprise policy for identity creation and to establish this as policy and a requirement for the enterprise registration authority.

There is a long standing lesson from manufacturing that building quality in to a process is much more cost effective than trying to add it on after the fact. In building 21^st century identities quality (high assurance) needs to be built in at the beginning. Getting identity (as opposed to simple identifiers) right necessarily needs to have a registration authority and the associated roles and policy that can meet the requirements as laid out in FIPS 201 and supported by the PIV and PIV-I frameworks. In doing so organizations not only maximize the use cases they can support but also maximize the return on their identity infrastructure investment.

Draft FIPS 201-2 Workshop Personal Identity Verification; Annotated Top Ten List and Other Observations

2011-04-25T11:55:00.000-07:00

IDmachines and other colleagues attended a workshop last week at the Department of Commerce National Institute of Standards and Technology in Gaithersburg, MD on the draft FIPS 201-2. The workshop allowed NIST, other government agencies and industry to discuss the initial changes and to propose other changes to Federal Information Processing Standard 201 (FIPS 201) titled Personal Identity Verification (PIV). FIPS 201-1 has over 5 years of experience and the issuance of millions of credentials to consider as the new draft goes forward. The comment period for FIPS 201-2 closes 6 June.

FIPS 201 is one part of a number of initiatives on the part of the Federal government around identity and cybersecurity. The Federal Chief Information Officer (CIO) Council has released the draft of the Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, Part B that goes into the use of PIV credentials for both logical and physical security. The FICAM effort also includes the Trust Framework Provider Adoption Process (TFPAP) for lower assurance levels across a range of identity tokens. Companions to FIPS 201and the FICAM include the National Strategy for Trusted Identities in Cyberspace (NSTIC) that was recently released by the White House and which is managed by a a program office at NIST. Besides NSTIC the CIO Council and the General Services Administration in Coordination and the Federal PKI Management Authority have promoted the expansion of PIV to organizations outside of Federal employees and contractors with PIV- Interoperability or PIV-I. Understanding the activity around identity on the part of the United States Government is helped by looking across these things (and other related activity) as a whole.

As part of the overview to the workshop NIST presented its "top ten" list of the changes to FIPS 201. While not exactly ready for Letterman it provides an excellent overview of what is changing in the document.

Asymmetric Card Authentication Key (CAK) is mandatory

The Asymmetric CAK provides interoperability over the contactless interface. Previously optional, the CAK now provides a mandatory contactless Public Key Infrastructure (PKI) component. A symmetric CAK is also available as an option in addition to and in combination with the asymmetric key. This allows a practical approach to key management in a federated environment while providing options for speed and enterprise specific keys.

Introduction of enrollment record or chain of trust as maintained by the issuer. The document puts an emphasis on chain of trust with good reason particularly given the interoperability goals of FIPS 201. There are a number of reasons where the chain of trust helps to improve the economics and reduce the effort when you take lifecycle considerations into account. Some of these benefits of this include

Eliminates complete re-enrollment
Eliminates recapturing biometrics
Background Investigation (BI) may not need to be repeated

Iris recognition as an additional biometric modality is introduced. The draft proposes using a standard image (which then requires (non-standard) template/model creation and matching). Further testing and recognition rates were discussed and will likely be forthcoming and build on existing Iris Exchange (IREX) work at NIST. Iris biometrics bring benefits that include:

Iris provides alternative in the case where fingerprints cannot be obtained as a basis of biometric binding of the individual to the credential.
Iris can be used as an authentication method. There are an increasing number of vendors and applications use cases around iris matching and the draft now allows these to be part of an organizations identity toolkit.

Standards based technology advancement is really about Optional On Card Biometric Comparison (OCC) coincidentally called match on card. (Question here is should optional should be mandatory?)

OCC use cases include enrollment, authentication, and PIN reset. Is there a degrading the number of authentication factors if you combine PIN and BIO in the reset transaction? Unrelated buy also introduced is how many expiration dates do we need in the specification was notable among many good points made by the audience and industry presenters.

ISO 24727 as a means of providing interoperability for smart card identification, authentication and digital signatures. It is a 6 part standard with the 6^th part including a registration authority procedure.

NIST discussed registering a PIV authentication profile.
Also provides secure channel features

NIST also discussed a forthcoming Special Publication 800-xx on secure contactless communications.

Optional feature for card authentication to address issues related to the Rehabilitation Act and Section 508 and access to electronic and information technology procured by Federal agencies.
Maximum length of printed name was extended and provides flexibility with dealing with printed names. Good to have a name people want on the front and this helps in that regard { though it is still the case you can’t put the apostrophe in D’Agostino on a PIV card (;-}. Instead the electronic naming issue should go to UUID as baseline identifier, UUID should be top 10 and mandatory (will be in DoD) as is the case with PIV-I.
Replace indicator for National Agency Check with Investigations (NAC-I) with a background investigation (BI) indicator. This addresses PIV-I where certain populations of cardholders are not applicable for a NAC-I. Indicates that a national BI indicator service would be put in place.
Allow post issuance updates to PIV card. This aligns with the desire to have the card live through two 3 year certificate cycles and have a 6 year life. This also ties to #2 chain of trust to enable the update.
Put employment eligibility verification background documents (I-9) into the FIPS 201 specification. This helped clarify some of the background document requirements as it represents the specific items accepted. Interesting not to have included a TWIC. As a close and an aside one of the interesting things about PIV-I and PIV-I is the ability to use it as an identity credential to get other access credentials (e.g. SAML, JSON Web Tokens, OpenID, etc.) and while this document only refers to credentials acceptable as background for a PIV card its interesting to think about the ability to register with PIV and PIV-I and their related authentication factors and attributes.