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

The Smart Cards in Government conference last month brought together a very good group of users, solution providers and trade associations’ members to engage on the state of the practice on trusted identities and the use of secure elements.  IDmachines contributed to a pre-conference workshop on PIV-I physical access control and an e-Gov overview for the Kantara Identity Summit.    And despite budget challenges there remains work 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 conference were 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 begat PIV-C.  When PIV-C became known as PIV compatible it was bad.  Compatibility was too close to interoperability in some minds so a new acronym was requested.  That this lead to the Commercial Identity Verification Credential and CIV, which has nothing to do with identity verification, is another topic for discussion, but onward with PIV-C.

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

Standards for identity proofing and agreement on the authoritative sources of attributes and privileges are one of the current gaps in the identity ecosystem.  PIV-C basically allows ad hoc enrollment and self assertion.  Technically you have a number keys, certificates, interfaces, and at present one or a small number of applets.  Easy to implement as physical access enterprise credential where there is no federation, but a web credential needs to be interoperable.  Is the National Strategy for Trusted Identities in Cyberspace developing un-trusted identities?  I am sure not.  Other part(s) of government’s paranoia over counterfeit credentials has wagged the dog and resulted in a classification that really didn’t need to exist.  There are already, albeit limited, enterprise multipurpose PKI credentials.  Really we should keep people focused on PIV-I and we should keep to a minimum PIV-C and CIV-C, etc.

Ironically, all during the conference it was easy to make this point.  I used a counterfeit credential.  Yes it was wrong and says so on the back, I didn’t do it with the intent of documenting it, and it was an immediate way to demonstrate to the members of the steering committees for the United States Federal government physical security and ICAM initiatives going in with me.  It helps to document security theatre.  I used my demo FRAC credential to get into the Reagan building. (My Federal colleague took a photo).  Test credentials are useful and very real looking.  Mine had a nice shiny chip, security lamination and 4 certificates of course all issued by a rouge certificate authority.  These hardly mattered 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 but rather electronic verification including trust of the issuer.  

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

And it’s about more than authentication.  

1. Make sure you have established identities to the assurance level needed for individuals’ roles.
2. Make sure there is a separation of roles among the people enforcing the process
3. Make sure the identity is bound properly to the credential
4. Perform cryptographic challenge of the credential and validation of issuer along with checks against other access control (black and/or white) lists.
5. Don’t truncate the identifier (which is different than hashing them and yes, you will need to upgrade infrastructure to accomplish this).
6. Match the level of authentication to the assets being protected.
7. Protect secrets, personally identifiable information and the cryptographic processing.
8. Use standards based technology and policy.
9. Only procure systems that can do this.
10. Only procure systems from vendors and integrators that have demonstrated they can do this at a system level.  (The weakest link is the strength of the chain).
11. Implement and automate the controls that audit and alert to the above.

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