US Government Smartcards; CAC, PIV and PIV-I
Recently, I had the pleasure of trying to get some government certified smart cards for some of the technical people at Quest, and I can't believe how much of a headache and hassle it was. I actually don't work for Quest Software, but a subsidiary (Quest Software Public Sector) which is focused on the public sector space. And while most Quest employees don't have a need for government-issued or government approved smart cards, our company does. And while I knew that non-government employees can get a relatively new (a little over a year old) flavor of the PIV card called PIV-I, I was amazed at how difficult the process was to navigate. Thankfully, we have some pretty good and persistent purchasing folks, but the process is still pretty arduous for an organization that has been working with the government for years.
I won't get into all the details, but if you're interested, feel free to contact me offline.
In any case, I find myself constantly having to explain what the different is between a smart card, a CAC, a PIV card, and now a PIV-I card. A smart card is pretty straight forward - it's a generic term, and all the other cards fall into this category. You can find a lot more details on them here at Wikipedia. In any case, the thing that makes a smart card a CAC (which means Common Access Card, so please don't say, "CAC Card" as it is redundant) is that it is used by the US DoD (Department of Defense). If you want to do any work on government systems in the military, you will most likely need one of these.
Like their military counterparts, employees within civilian agencies also need smart cards. Of course, they opted for a similar, but not the same, standard. That standard is a PIV card (Personal Identification Verification). The cards are slightly different from CACs, and have varying information printed on them, depending on the issuing agency. Plus, they use a different set of CA (Certificate Authority) servers than the ones that CACs use, as the DoD have their own servers.
Finally, and this is the confusing thing, there are PIV-I cards. PIV-I stands for PIV-Interoperable. There are some great docs about PIV and PIV-I at www.idmanagment.gov which is a site run by GSA but I'll save you the trouble of wadding through a lot of documentation. The PIV-I FAQ here states:
2.2 What is the difference between a PIV-I Card and a PIV Card?
The term “PIV Card” may only be used to describe an identity card that is fully conformant with Federal PIV standards (i.e., FIPS 201 and related documentation). Only a Federal entity is capable of fully meeting these standards and issuing a PIV Card. A PIV-I Card meets the PIV technical specifications of NIST SP 800-73 and is issued in a manner that may be trusted by Federal Government Relying Parties, but does not meet all of the requirements of FIPS 201.
What does this mean? A Federal entity (aka employee) uses a PIV card, and a trusted, non-government entity has to use a PIV-I card.
So there you go. In summary:
- CAC is for Department of Defense users
- PIV is for civilian users working for the Federal government
- PIV-I is for non-Federal entities that need to access government systems
Wait! I thought the Feds only cared about smartcards . . .
Monday, I posted how Quest's tokens allow for users to program their own seeds. Which then prompted questions (internally) of, "Why do you even care? I thought you focused on the Federal space, and the Feds only cared about PAP, or CIV cards?"
Well, yes. For the most part, the US Federal government does focus on CAC (Common Access Card - used by the DOD), and PIV (Personal Identification Verification - mostly used by the civilian agencies) cards. And you'll also hear about PIV-I (PIV Interoperable) being involved. In the case of CAC and PIV, a user has to file an application, and some Federal agency would need to sponsor the individual to obtain such a card. This usually includes a background check, or some sort of formal review, before the card is issued. PIV-I tried to lower this barrier, by allowing non-Federal organizations (think government contractors, state governments, first responders, etc) to issue interoperable smartcards that are trusted by Federal systems.
However, PIV-I has a lower "assurance level," and often involves the same (or similar) sort of background check, just by a different organization. Assurance Levels are set by NIST and can be found detailed in their Special Publication (SP) 800-63. You'll see there are 4 assurance levels, and PIV-I only gets to level 2 (really, it gets to level 3, but with a less stringent background check, it can only be considered level 2.5 at best). CAC & PIV strive for level 4, if not level 3.
Ok. So we've established that smartcards are the main vehicle for 2-factor authentication in the Federal government, but I still haven't explained why tokens (RSA and other ones) crop up. And this is because a token is also an acceptable form of 2-factor authentication (read SP 800-63. and you'll see them mentioned as 'one-time passwords'). The "identity proofing" is still required, but tokens are actually a lot more flexible for several reasons.
1. Tokens can be assigned to any user (part 1). In the case of smartcards, they are usually assigned to people, while tokens can be shared. In fact, with our tokens, users can share tokens, but continue to use their distinct credentials (username and password) with the token. Which means that multiple admins can share a token to access a common system, but you can determine which admin logged in to do something with the particular token. This lets you continue to have 2 factor authentication, but also a "check-in/check-out" system for the particular token, allow more controls over the physical token (perhaps locked away in a safe or vault).
1a. Tokens can be assigned to any user (part 2). This is really a corrollary to 1, which is that the token can be assigned to service, or privileged accounts. Putting in the same sharing (check-in/check-out) model for a token, plus tie the password to a password vault product, and you have some pretty solid security around your privileged accounts such as oracle, root, Administrator, and other 'non-named' accounts.
2. Tokens are independent of environment. With smartcards, you have to have a reader attached to the user's console. No reader, or a malfunctioning reader, makes authentication a bit more difficult (read not possible). There are also situations where PKI simply isn't used. Older applications or platforms that do not make use of certificates cannot be changed quickly or easily. With a token, along with a username and password/PIN, you can continue to get 2FA, even in a scenario where a reader isn't available or not practical, or the app is expecting only a username and password. There is still some amount of work to be done, but it's often easier than tying an app into an entire PKI infrastructure.
2a. Tokens are independent of environment. There are some cases where the app or platform is capable of using PKI, but it is sitting in a location/area/network that simply cannot reach the PKI infrastructure to which the certificate on the smartcard is tied to. Not every system is actually on the internet (unbelievable, I know), which means tokens can provide access without requiring a centrally managed CA (certificate authority) to be present.
3. Tokens can be assigned much quicker and easier. And this is really the crux of why tokens come into play in the Federal space. Smartcards require a centrally issued certificate to be put onto the card. In some cases, there is no time for the requests to make their way through the system to get a certificate, publish it to a CA (certificate authority) and card, and get the card to the user. In other cases, the user simply will not get through a background check (or unwilling to get one), but has to be given access to certain systems. Yes, there are times when the Federal government has to deal with "questionable people" but they might as well make sure it's the right person, so 2-factor is still needed.
3a. Tokens can be revoked much quicker and easier. Because the token is usually some bit of plastic, it's easier to revoke and know that it won't be used in other ways. Most smartcards take a while to issue because they are also printed as a security badge. Meaning that even if the certificate on the card is revoked, the card may still be usable to get physical access to a building or location. However, it's unlikely that an agency will let you in because you have a black piece of plastic on your keychain.
So, with those all those reasons, tokens are not going away. Smartcards will continue to dominate, but there will continue to be a need for 2-factor authentication (2FA) using one-time passwords (OTP) in the Federal space.
The RSA Breach saga continues . . .
I've discussed the RSA breach before, but had a very interesting conversation last week with a customer that was in a dilemma as to what to do. RSA have said they would replace some of the tokens, depending on the situation (protecting Intellectual Property, Consumer-Oriented products, etc) and this customer was pretty certain they were to get new tokens from RSA, but didn't know if they wanted them. Nor do they want any other "standard" token that other vendors could provide, because that new vendor could be breached as well.
What this client really wanted was a token where he could program his own seed into it. I mentioned that our software tokens actually allow for this out of the box, and when you "program" a new soft token, the seed is automatically generated. Which means that Quest never knows what the seed record is for any software token that we provide. For an example of this, you can actually see a recording of it here where the seed is generated, and then here where the seed is put into our Desktop token (there is no audio on either recording).
However, this wasn't as interesting to him as programmable hardware tokens. He had concerns about keys getting compromised while being transferred to the end user, and wanted to send a pre-programmed hardware device. At first, I didn't think we had anything like that in our arsenal, however, it turns out that one of our latest token models (The Yubikey token) as well as some of other ones already allow for user programmability! In fact, if you look at the link for the Yubikey token, and then scroll down, you'll see that some are programmable. It took our Defender Product Manager (Stu Harrison, who blogs on and off here) to point this out to me, even though I should have remembered this from earlier on.
Obviously, each token does come with a default seed that Quest will know about, but if there was concern about a vendor having the "keys to the kingdom," a programmable token puts the onus back on the organization, and keeps Quest out of the limelight. I don't want to discount the fact that this will take more manpower, but if you don't want your vendors to have your seed records, reprogramming the tokens is the only secure way of doing it. It only makes sense, and as a security professional, you should never rely on RSA, Quest or any organization if you can minimize the number of people that have access to the token seed records.