Additionally, the SmartCard Interagency Advisory Board has indicated that to comply with FIPS 201 PIV II, U.S. government agencies should use smart card technology. This means that to support the complex cryptographic operation of FIPS 201, a smart card is essential.
The NIST proposals target the fact that the federal government does not have a central authority for identity management. With more than 15 million civilian employees, it is the largest employer of personnel. Centralized control does not and cannot exist because it is not a single, homogeneous organization.
In the past, the many thousands of military and government facilities used whatever PACS system was approved (and funded) using many hundreds of contract initiatives. The state of the nation, when it comes to PACS, was that there are just as many vendors selling into the government as there are vendors. Cards issued by one facility did not necessarily work in another — even if they came from the same vendor. The same had been true of logical access control systems (LACS) for computer and network access, and perhaps more importantly, systems for national security. This was the sorry state the government found itself in after 9/11 when it decided to issue the directive that led to the NIST PIV proposals.
PIV is a clever, though complicated, way of verifying identity. It relies on the issuance of a cryptographic certificate (your credential), from a trusted authority that cannot be forged. It is based on cryptographic key pairs — one is the private key (yours) and the other is the public key (the government’s). This enables a user to verify his or her identity by authenticating the private key to a publically signed access point. This is how PKI (Public Key Infrastructure) asymmetry works: the key-pair is not identical, and it allows a many-to-one relationship between the host and its users. It is the way the Internet operates.
For the PACS (and LACS) security designer, FIPS 201-compliant smart cards require both a contact and a contactless interface. For ease of issuance, so-called dual-interface cards have been the de facto standard, but the two interfaces technically do not have to share a common microprocessor, and in fact, in most cases, do not. In effect, we have two cards in one body, and commensurate cost. There is also the overhead of upgrading the reader infrastructure to support PKI access.
It is precisely this problem of knowing who works for you that the government has sought to issue PIV credentials to all federal employees and their contractors. If you add state employees, their contractors and the uniformed military, then the market size for PIV is considerable. The opportunities are immense, but so is the cost and complication.
Anyone who has seen the cost of PIV cards and the PKI system to support them will ask two questions:
1. Will this become a de facto standard that enterprises and small businesses will have to adopt?
2. Is there an alternative that offers the same level of security?
A Perfect Symmetry: An Alternative Approach?
In organizations where there are large card user populations and no central authority, the veracity of the card is questionable. This is a consequence of unbounded systems where the verifying agency does not know the constituent. The Internet works this way also, and represents the ultimate many-to-one relationship system. For example, Amazon.com relies on HTTPS protocol in the browser to issue and manage certificates to you.
We are somewhat fortunate being PACS people. Why? Because by definition, PACS is a “bounded system.” Every security designer, working with security policies and risk assessment, knows the entry and exit point of the facility. The system is known; thus it is bounded. PACS card users are also known; cards are only issued to known and vetted individuals (per the security policies); therefore, the card users are also bounded.
Bounded systems have a special property which unbounded systems do not possess. Because we know the population of users and we know the trust boundary — and there is an implicit self-authentication in a bounded system — the system by design is trusted.
However, one difficulty remains: We also have to trust all the components that service the system. And not surprisingly, this can also be solved.