Last month the Department of Defense Chief Information Officer Terry Halvorsen made a bold call for the replacement of Common Access Cards within the next two years. Common Access Cards, or CACs, are credit-card-sized smartcards used to provide Two-Factor Authentication (2FA) to DoD networks. This method of access requires two out of three of the following items:
- Something the user knows
- Something the user has
- Something the user is
A CAC – “something a user has” – in conjunction with a PIN – “something a user knows” – provides the required 2FA. The issue Mr. Halvorsen has with CACs is that they do not work well in a tactical environment. As he said, “It’s really hard to issue CAC cards … when people are dropping mortar shells on you and you need to get in your systems.”
So what will we use instead of CACs? Mr. Halvorsen mentions Biometrics as part of the solution. Biometrics, or “something the user is”, includes physical characteristics like fingerprints or behavioral characteristics like how many times a user misspells Halvorsen in a blog post (purely hypothetical). I discussed some of the security concerns surrounding Biometrics in a previous post but the biggest issue seems to be with public key cryptography. In public key cryptography the user maintains a secured private key and shares a public key with the world. The private key is stored on the CAC and is unlocked with a PIN as part of the DoD Public Key Infrastructure (PKI).
Click to Subscribe
If there is no more CAC, does that mean there is no more private key? We can derive passwords from Biometrics, for instance fingerprints have enough entropy for the equivalent strength of a 13 character password, but it is not public key cryptography. If there is no more public key cryptography how can the DoD maintain its PKI?
I believe this highlights a very interesting debate on the difference between authentication and encryption. If we look back at the earliest days of authentication, passwords were often sent in the clear (e.g., Password Authentication Protocol (PAP)). It was assumed that the channel would be encrypted and all information, including passwords, would be encrypted by the channel. Authentication was merely used for authorization and accounting. It was not until we moved from point-to-point networks to the Internet that we combined authentication and encryption in PKI. Is Mr. Halvorsen telling us that we no longer need PKI?
I do not believe this is the case because at a luncheon following the CAC elimination comment Mr. Halvorsen made a point of recognizing the need for PKI. As he said, “I want to make it clear, when we replace the CAC card, it will be public-key infrastructure.” Mr. Halvorsen suggested using Derived Credentials in conjunction with Biometrics to simplify authentication and maintain PKI. Derived Credentials is a software-based version of the CAC contained in an electronic device such as a smartphone. In that architecture Biometrics would unlock the electronic device while a user’s certificate and associated private key would be stored in the Derived Credentials.
Derived Credentials is intriguing because it heralds the ability to Bring Your Own Device (BYOD). The only issue is current policy (i.e., NIST 800-157) which requires that credentials issued at Level of Assurance (LOA) 4 be kept in a hardware cryptographic module that has been validated to FIP 140-2 Level 2. This means you may need a special hardware solution which is an issue for BYOD.
The moral of the story is that the DoD is now committed to changing how users authenticate themselves and that we should expect to see big changes in the next few years. This will make it difficult for the Government to purchase devices or applications that have a fixed authentication mechanism. Perhaps this is the reason we are seeing so much interest in applications that allow a flexible authentication mechanism, like TELEGRID’s SMRTe.
Eric Sharret is Vice President of Business Development at TELEGRID.
Click to Subscribe
Disclaimer: The opinions expressed here do not represent those of TELEGRID Technologies, Inc. TELEGRID Technologies, Inc. will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.