MFA Post 8: Smart Cards
“Smart card” is actually a bad term. The proper term for what we mean here is “hardware-backed certificate authentication” but for the obvious reasons, we’ll probably just stick to “smart card”. Smart cards are simply a hardware device with an integrated circuit (IC) on them. In fact, you probably have at least one in your wallet. Virtually all credit cards now include an IC along with a set of metallic contacts on one side. However, you may also find contactless (RFID) based smart cards, smart cards in a form factor indistinguishable from a USB flash drive, and multi-purpose devices that include smart card functionality, such as most Yubico YubiKeys. Today, something like 10 billion chips suitable for smart cards are manufactured each year.
When used in an authentication context smart cards typically would be ones that implement the Personal Identity Verification (PIV) standard defined in Federal Information Processing Standard (FIPS) 201, which was originally published in 2005. However, smart cards were used for authentication in common systems in the 1990s. Smart card authentication was built into Windows Active Directory from the beginning in Windows 2000. Microsoft rolled out smart card login to its employees for use on its Virtual Private Network (VPN) in 2001. Smart cards are ubiquitous in U.S. Federal Government systems and other governments and may, as a result, be the most widely used multi-factor authentication solution in the world.
But, what actually is a smart card? Simply put, it is a hardware chip that can store one or more private keys, associated digital certificate(s), and that can perform cryptographic operations. Usually, but not always, the public-private key pair is generated on the card itself. This is much more secure because it means the private key never needs to live outside of the card. The identity binding between the user and the keys is provided by an external entity and can have varying levels of assurance. Remember, identity is not the same thing as authentication.
Once generated and the identity binding is completed, the public key is usually sent in a certificate services request to get signed by a certificate authority. That certificate will specify the user principal that the certificate belongs to and who may use the smart card that holds the corresponding private key to authenticate. The certificate, or an identifier associated with it, would be stored in the user database at the identity provider (IdP). This IdP must trust the issuer of the certificate, which means that the entire system is based on the existence of a mutually trusted Public Key Infrastructure (PKI) that can verify the identity of the user prior to issuing the certificate.
The specifics on the authentication flow is rather detailed and there are many varieties. In a simplified view, the user tells the IdP which identity they wish to claim. The IdP tells the user, through the system the user is using to authenticate, to use smart card authentication. The system generates some bit of random data, perhaps a time stamp, passes that to the smart card and asks the card to use the private key to sign the data. The card does this and creates a signed parcel of data. The user’s system gets this parcel and passes it to the IdP, which then uses the public key in the digital certificate to verify the signature. If the signature checks out the user must have the private key in their possession. If the key was generated on the smart card and was set to be non-exportable it stands to reason that the user has the smart card in their possession.
Smart cards deployments are well suited to certain kinds of environments. Most organizations that use them have integrated the smart card with the identification badge alongside the outdated photo of what the person looked like after walking through a hail storm on their first day at work, 17 years ago. This type of card, such as the U.S. military’s Common Access Card (CAC) can be used as photo identification, as an access card to a building, and to log into a computer. This type of system means you have automatically solved the problem of a trusted signatory.
Smart cards are widely supported in enterprise systems. You can use them to log into Windows, Linux, and Mac. They are supported over both SSH and RDP. If you use a PIV compliant smart card in a USB A or C form factor it also works with most computers without any additional hardware.
Smart cards are physically rather secure. The FIPS 201 standard specifies that the cards must be tamper resistant as well as tamper evident. The difference between the two is important. My smartphone is tamper evident in the sense that I am clumsy, and if I were to try to open it, it would no longer be functional, providing evidence that I tried to tamper with it. It also uses a really weird pentalobe screw, and the associated screw driver is hard to find, making it somewhat resistant to my tampering with it. Many smart cards are FIPS 140-2 certified at Level 2 (verified tamper evident) or Level 3 (verified tamper resistance).
Smart cards do have a number of disadvantages. First, the system relies on a trusted party that can verify the identities, in essence, a PKI. While there are many trusted certificate authorities, getting a certificate onto a smart card is a little bit involved and not suitable for the general consumer population. In addition, it must be possible to revoke certificates if you use them for user authentication. Revocation support on public CAs is generally not scaled for this. To use smart cards for public services, therefore, the IdP would likely end up having to build its own PKI, which means the user would have to have a different smart card for each service. At last count, I maintain just over 400 accounts in my password vault. 400 smart cards seems like a bit much.
Which leads us to the second disadvantage of smart cards. They require a smart card, and in the case of a card-format device, a reader. Those who were around when Microsoft rolled out smart cards nearly 20 years ago are sometimes fond of telling the story about the readers. Every employee needed to get a smart card reader that they had to carry with them. Two readers were on offer. One was an ugly black thing that took up a lot of space in your bag. The other was a really cool, thin and transparent device that looked a bit like a Klingon bird of prey. Only one of them worked reliably. I’ll let you guess which one.
The fact that smart cards typically need a hardware reader means they do not work on many devices and that they need peripherals on nearly all. This makes them rather inconvenient. A number of years ago a credit card company in the U.S. sent customers a smart card reader along with their cards. It seemed like a really good idea. The cards could have chips on them that, many years later when the U.S. started catching up to the rest of the world, could be used to pay with as well as log into the provider’s website. Unfortunately, that wasn’t the intent. The idea was that rather than typing the card number when buying things online you would plug the reader in and it would read the card number and fill it in on participating shopping sites. While I received the reader, I can’t recall ever finding a single site that worked with it, nor being able to set it up to authenticate against the issuer’s online account. A decade later everything was mobile apps and getting a smart card reader to work on an iPhone was a non-starter, so this idea never took off.
Smart cards are also a bit fragile. As long as you keep a card in your wallet they tend to last for a while, but smart cards, especially ones combined with identity badges, are meant to be used frequently and worn. They are notorious for breaking off in the reader, especially readers built into a computer, and especially if the smart card must be inserted for the duration of the login session, leading users to carry the computer around with a card sticking out of it. One user I recall was notorious for breaking the card on his lanyard by leaning against his desk and trapping the card between it and his body.
There are multiple varieties of authentication flows defined in FIPS 201-2, and there are non-FIPS 201 compliant variations (primarily ones that predated FIPS 201). The phishing resistance of smart card authentication varies depending on the exact implementation. Perhaps the most common method is PIV Asymmetric Cryptography, which can take a couple of forms, depending on whether or not the cardholder must enter a PIN to unlock the card. Neither approach provides strong resistance to a man-in-the-middle (MITM) attack, such as that used in phishing, because this was largely out of scope for current revisions of FIPS 201. Depending on other implementation details, a challenge may be forwarded by the man-in-the-middle and unless the user notices that they are not connected to the legitimate service an attacker could establish a session to that service. FIPS 140-2-3 requires MITM resistance at all assurance levels, which means in practice some form of phishing resistance is likely included in most FIPS-compliant implementations, but may vary in non-FIPS ones. The implementer needs to investigate this.
The protocol is relatively resistant to an offline attack. The attacker must actively be in the middle of the session, otherwise the challenge may expire before it is used. In addition, executing an attack is a complex task. Therefore, phishing resistance in practice is reasonable, but there are more resistant options, which we shall cover next time.