Smart Cards: PIV-C or Not to PIV-C?

When deciding on applicable standards to utilize in the deployment of smart cards in an enterprise organization, what are the considerations of PIV, PIV-C, or CIV? Are there any reasons not to approach a project with PIV-C or are all serious vendors offering PIV cards?

A precursory answer to this question is not the answer you seek but is relevant and will save you from the #1 reason for why smart card projects fail – do not start your investigation by focusing on the card.  In the overall scheme of things, the core IT infrastructure, integration, resources, and dependencies are by far 90% of it all. Hence, the card is really a commodity and the best practice would be to start from back-end and work your way to the front end. This would mean that the actual card you purchase is the last vendor commit to make. The impact otherwise is ending up with thousands of expensive cards that can’t do anything more than open doors. This happens all too often and is easily avoidable.

Having said all of this, once the stakeholders can agree on the business goals of the project, transitioning to technical focus, HOW you get there is where standards come into play. The first fork in the road is obvious:

Standards vs. Proprietary

Proprietary:

For years, if one wanted to deploy smartcards, it generally had to be servers, clients, drivers and so on from one vendor. Their adherence to support applications, cards, and hardware was somewhat draconian and if you were fortunate enough to successfully roll out to populations in mass, you were dependent on their specific roadmap for additional feature support. If you wanted to get away from that vendor, it was an entire rip, replace, and reissue. And when you run out of the initial batch of cards you purchased, it was likely that you had to go back and buy newer cards from them and upgrade the CMS and client to support it. The vendor had you locked on supply, cost, roadmap, and so on. Standards change this

Standards:

Standards have changed much of this by driving participating vendors to build their components (including but not limited to cards) to an open (not vendor owned) specification. In doing so, compatibility between one vendor’s cards, clients, servers and other components may work with one another giving Enterprises best-of-breed choices to suit their needs. It also has a mass community of millions of users driving features verses a lone enterprise requesting this of their vendor that they heavily rely on. There is also less dependency on end of life cards, supply, and price-setting because there are competitive options readily available. So overall, it is an excellent evolution.

Types of Standards:

There is only one recognized standard that pertains to smartcard components and deployment – PIV. One would think that since there is only one standard, deciding on how to proceed on this path would be simple, but it is not. Unfortunately, the world of standards pertaining to smart cards is quite complex. The reason for this is that the standard, PIV, was created by government to suit government requirements. It did not take into any consideration the enterprise, their use cases, pre-existing infrastructure, etc. To be fair, was not the objective and rightfully so, but leveraging it within an enterprise requires careful thought on what parts to leverage, execution, and ultimately striking a balance of specifications and an organization’s unique business requirements that set it apart from being a government entity.

PIV: Broken down

To be clear, there is officially only one standard – PIV. There are other variants, some which from a real world perspective have merit but categorically are fiercely debated to be unsanctioned by those around the government community. This in itself creates even more confusion since the message, source info, and opinions on the matter are fragmented.

PIV:

This is the specification of smartcard deployments for government agency employees only. This is the basis for all things PIV. It specifies who can be issued a card, how, , what gets issued to the card, assurance processes of who they are prior to issuance (background and vetting), policy, and assurance level attainment, etc. It also references FIPS201 in terms of the components that have to be used (they must be certified). All of these things combined – technology, process and certification – are defined in this collective bucket.

PIV-I:

The “I” standard for “Interoperable”.  By interoperable, this means that this credential will be recognized and trusted by the federal government identity infrastructure when presented. By doing so, it conforms to many (but not all) of the specifications of PIV. This is a sanctioned variant for non-federal employees of enterprise companies to obtain a credential that can be trusted when accessing federal facilities or computer systems. Typically, this applies to contractors. There are audit and assurance levels to comply with so it is very stringent.

PIV-C:

The “C” stands for “”Compatible”.  This is entirely unsanctioned by NIST and the definition of it is not governed by any specific entity. Typically it refers to using technology components that embrace the PIV model by specification, and everything in terms of policy, process, and certification are optional. There is no assurance level audit or compliance. It is important to note that I mentioned “specification” rather than components meeting “certification”. The certification would refer to these components being certified and on the approved product list to meet FIPS201. It is possible to have components to work with one another, following the PIV specification, but not necessarily going through all of the expense of getting on to the APL. More on this below.

CIV:

This is a specification (not a standard) sponsored by the Smart Card Alliance written by its contributors. Its charter was to satisfy the government camp that was dissatisfied with the usage of the term “PIV-C” (or anything PIV that was not approved by NIST). In its effort to do so, it provides guidance as to how an Enterprise can leverage PIV without such assurance levels and certifications and benefit from the standard.

The challenge with all of these is that with the exception of PIV-C, they are all very prescriptive. For example, with PIV, there are no deviations and only the government can do this. With PIV-I, you are either 100% compliant of not, there is no 99%. Therefore, if an organization doesn’t think that some of the processes, feature behaviors, demands on infrastructure are suitable to their organization, you are faced with a choice – either be compliant or be CIV or PIV-C.

Argument against PIV-C

There are many arguments that PIV provides best practice and without it any card issued cannot be trusted and is not secure. While PIV does have some credibility here, because it does layout some procedures that inarguably are good and transparent for all to know that a relying party has done so, it is not perfect. Mainly this stems from the premise of two areas.

Premise #1: Trust:

The PIV and PIV-I models mandate that trust is achieved where certain requirements are met prior to finalizing the infrastructure build and issue an identity to a person. If achieved, which is rigorous, other parties that subscribe to this model can reasonably trust that you have also met the same requirements and such people can be reasonably trusted to be who they say they are, regardless of which organization they belong. The thought in the government arena is that without this, there is no guidance and therefore an identity cannot be trusted and is of little value.

Counter Perspective: From a PIV standard standpoint, there is a level of achievement here.

However, to say that if not performed the way that the government does so and therefore has little value is not accurate either. The truth is somewhere in between in that since this is in ungoverned territory, the Enterprise may or may not do many or most of PIV. It may actually do more. Ultimately however, Enterprises that need not integrate or be trusted by the government only need to adhere to their own trust model that they create. Their being trusted by the government for additional expenses and cumbrances has little value to them. To take on additional assurance levels while not foreseeably required has an unwarranted gain in complexity, cost, and deployment time.

Premise #2: Security:

From the same community, it is assumed that if these rigid policies and processes are being followed, and assurance levels are obtained, then this automatically means high security. Conversely, it is assumed that if not, then implementations are not secure.

Counter Perspective: Standards and assurance levels are great, and they do enforce participating entities to perform many things that are good practice. However, there are many things that are not covered which leave holes from a security standpoint and therefore are not absolute. Also, just because an enterprise does not conform to an assurance level, does not mean they are doing less, but rather what they are doing is not transparent. It could be that they are doing more. I have seen many instances of an enterprise that due to the nature of their business, risk, and competitive market skill sets are far more secure than any specification, even PIV. Due to both of those points, therefore, one should conclude that PIV can set a baseline for transparency in some areas but security is not necessarily commensurate with assurance levels.

One additional item is that the premise that a certification authority employed by an enterprise cannot be trusted if it is not cross certified by the federal government. This is not true either as the “public root” and webtrust certifications have long been established years earlier than the Federal Bridge, and they do have to comply, disclose, and enforce policies (“CPS”) to maintain their status. This enables a certificate from one certification authority to be trusted by a certificate holder that was issued by another. It comes down to the level of trust you need and what you need it for.

Considerations for Enterprises

Below are some questions to ask when considering to implement PIV-I or not. In most cases, if the answer is that your enterprise needs to have control in the definition any of these items, PIV-I is going to be tough to achieve or benefit from.

Assurance Level: Obtaining assurance levels is rigorous and expensive. It also locks down process and policy.

• Is there a mandate for a segment of your population to be PIV-I compliant with the government?
• Do they need direct access to Federal Government information systems or facilities and being directed to do so by an agency?
• If so, how many employees of the overall population are required?
• Do the imposing processes required by PIV-I enhance current and desired processes or stifle them?

Process:

• How cards are issued, to whom, what occurs before hand.
• How to verify remote users, activate, provide them with emergency access, help desk functions.
• Definition of certificate expiration, process for renewal.
• Definition of handling keys, key history.

Usability:  Overall, is user experience and acceptance important? Is your organization the type that can dictate to users or must balance with what is acceptable? If you are like most emprises, there is a balance to a point, before there is user mutiny and erosion if stakeholder support. PIV-C enables organizations to define the following in a way that fits them best. .

• PIN definitions and policies, attempts, recovery
• 4 certificate model, or combining some of them for crypto uses
• s/mime for email signing and encryption on mobile devices
• When a PIN must be entered. For each email or only for defined periods of time (cached mode)?
• Mobile devices: Is there a plan for contactless usage of mobile phones as credentials or to accept those from cards already issued?

Cost:

• Does the additional expense of cross certification and carrying out prescribed processes for the segment of the population that is required provide adequate ROI for the overall population and mandate?
• If not going through Assurance level certification, are APL certified cards really required or just compatible ones that are essentially very similar for a lower cost meet internal requirements?
• Are ongoing annual costs of having your Certification Authority cross certified acceptable or justifiable?

Time to Deployment:

• Will deployment time line mandates accommodate the additional cross certification and assurance requirements?
• Are the resources available to partner on initial and annual compliance procedures?

If not PIV-I, then what about CIV and PIV-C?

If it is determined that PIV-I is not the path for your organization, then CIV and PIV-C are to be considered. CIV is an effort to try and make use of a common data model to simplify an enterprise’s effort in deploying smartcards in the enterprise absent of assurance levels required for PIV-I. It utilizes the same data model that is on a government card but without the assurance levels. There are still many usage restrictions and assumptions placed on the enterprise that make it unrealistic or desirable for many consider when entering the deep levels of their requirements gathering.

Also, CIV focuses on the card data model, not the actual building of your infrastructure, project plans, sequencing, dependency mitigation, and this is really where most enterprise deployments take a turn down a risky road. So, in a sense, it goes back to the first point in this post – don’t focus on the card first.

To be fair, PIV-C (not PIV or PIV-I), does not provide detailed or useful guidance in these areas either, but PIV-C again, is non-denominational and doesn’t attempt to. Like PIV, CIV does not address physical access integration that is specific for the enterprise. It assumes that you will leverage a government data model (usage of certificates at the door or eventually will). While this would be ideal, it is very costly, many issues, and needs time to play out. Until then backward compatibility with heterogeneous systems (as opposed to replacing them) and forward capability of higher security encoding that the PIV card can support is ideal.

All in all, PIV-C is bare bones for enterprise that have already for years do not buy into anything proprietary anymore and is the equivalent of them buying a web server that is J2EE compliant – what you do with it, integrate with it, and purpose it is up to you. Going PIV-C can save a lot of headaches but doesn’t mean to do whatever without thought.

I have yet to be inside one F1000 Enterprise that after initial interest, can implement a government data model to meet their requirements after digging down a few layers in how their organization functions, needs to function, their objectives, and culture. The exception here has been large government contractors implementing PIV-I, that are by nature an enterprise, but their customer base is so largely federal government focused that the value of demonstrating to their customer that they approach identity the same way they do far outweighs TCO, ROI, user experience, and actual realization of the original feature objectives. The average enterprise that has a consumer or B2B focus will be quite the opposite and ultimately accountable for P&L, resource utilization, ability to work with existing investments, risk mitigation goal attainment, and adoption via experience adoption.

Perhaps, if there was a better term it would not be a debate for many but without referencing PIV in some of it, it is just on equal ground with an entirely draconian proprietary model that is absent of leveraging anything PIV. This is the dilemma that has created the use of PIV-C – SOMETHING to reference the difference. Not to say they are equal by any means, but CIV doesn’t address this because it doesn’t solve what it was attempting to replace for most enterprises. Enterprises are still left with a gap on usage of this data model.

Summary

The industry, in sponsorship by the Smart Card Alliance, has done an excellent job in coming together to provide guidance for the enterprise where it does not exist in mass. My personal vote is for enterprises to try and take the CIV path if it can work for them, but if not it should be entirely their choice, free from any criticism from those that are not intimately familiar with the specific goals, after careful consideration and planning to go PIV-C. After all, enterprises know their businesses, how they need to operate much better than either myself or the government would. I am an advocate for educating and supplying them with options for success by THEIR measure – even if I don’t agree or need to point them to another vendor that is a better fit.

The real focus in the discussion should be the positive in that there are now options for enterprises, government agencies, contractors, and quasi-government organizations to leverage where years ago there weren’t. We can mainly credit this to the excellent work that NIST has done but until they work in the interest of the average enterprise, they are left to their own devices to decide.

 

Both comments and trackbacks are closed.