The Smart Cards in Government conference in November 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 such as the alphabet soup of acronyms: 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. 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 and is another topic for discussion, but onward with PIV-C.

Yes, PIV-C when it was used to mean PIV compatible was bad. It should have been PIV Counterfeit. In this way PIV-C could be used to help to explain why it is different than PIV-I. A credential can be a counterfeit either from the policy and procedures followed in issuing it and/or using un-trusted keys, certificates or other Web tokens. The government should have realized it’s the use case it doesn’t like not the acronym. 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 enables 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.

The goal for credentialing is to issue trusted identities. Trust is the killer app not being, as Frank Zappa said, “strictly commercial.” We are engaging in developing the National Strategy for Trusted Identities in Cyberspace not un-trusted identities. PIV-I meets these goals PIV-C does not.

Ironically, all during the conference it was easy to make this point. I used a counterfeit credential. Yes it was wrong and I didn’t do it with the intent of documenting it. But 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 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. Offer a glass of water not a fire hose. While this may not be simple it can be simply said. And it can start in a way where no acronym need be found.

---

Related articles:

PIV-I, CIV circling the drain Can CIV be trusted? PIV and multi-factor authentication