Authentication Basics 101

First, some three-point lists to re-hash the elements of authentication, mainly for my own memory-jogging purposes.

An individual who wants to gain access to data or facilities goes through a three-stage process:

• Identification (”Hi I’m Bob!  Let me in!”)
• Authentication (”OK, I verify that you are indeed Bob.”)
• Authorization (”Bob, I verify that you are among those permitted to enter.”)

Authentication can be done using any combination of the following three ingredients:

• something you know (e.g. password, PIN code)
• something you have (e.g. key, smart card)
• something you are (e.g. fingerprint)

It’s been a given for a while that two-factor authentication is a good way of massively raising security of information or premises at a comparatively low cost, by reducing the impact from losing or disclosing any part of the authentication process.  If I drop my access badge on the train, big deal, because I also need a secret passcode to enter the office.

Some Problems (PKI / Certificate Example)

As a quick side-track, during every single PKI-related project involving token-based authentication (usually smart cards) that I’ve ever worked on, two major issues inevitably arose:

First, how do we adapt peoples’ credentials to changing circumstances.  For example, the subject marries and changes their name.  Signing keys used in authentication certificates can be expired or revoked, even though this requires maintenance of a functioning certificate revocation list, something a lot of enterprises don’t seem to be capable of, and which can be technically daunting in any case once you start dealing with multiple thousands of revoked certificates.  However, data signed and encrypted before the expiration or revocation date must be accessible or verifiable in perpetuity, no matter if Jane Smith is now called Jane Smith-Jones.

Continuing the certificate example, this is solved by using something like friendly names on certificates (where the user’s name is not part of the certificate’s LDAP distinguished name (DN), or unique numerical identifiers that are mapped to an actual name in a database accessible by other applications that use the certificate.  There are many ways to skin a cat, or a user who changes their name.  However, this falls squarely into the “bad planning” department that seems to be an attribute of many PKI deployments; architects often don’t make allowance for future requirements, such as extended key attributes (thanks for the tip, Arjo), thus raising the need for additional certificate rollouts and system redesigns.

Second, what happens when the user loses his chip card?  No problem, get him a new one.  Even better, prevent him from losing it in the first place, by combining his authentication token with something he is definitely not going to forget, like the bathroom access pass or his lunch card (but whatever you do, please PLEASE don’t put the company logo or address on his access badge.)

What to do, though, when he’s on a service visit to a missile silo at the North Pole, or with a client in Colombia, and can’t access his laptop?  What about one-man branch offices in Timbuktu?  This is where we start facing increasingly complicated problems with issuing emergency credentials via cell phones (a great medium for secondary authentication — they’re tied to a person, they’re at least somewhat secure against casual attackers via GSM encryption and PIN code access, and they’re one of the least likely items to be forgotten at home.)

Moving beyond the scope of digital certificates, biometric authentication offers a tempting solution for both of the above problems..  Passports can be forgotten, passwords extorted, and unless you’re using a system that doesn’t check for heat or blood flow (useful in the case of the Malaysian Mercedes owner several years ago whose fingers were severed by robbers to gain access to his fingerprint-protected car) or which can be fooled by fake biometric credentials, biometric authentication immediately and reasonably reliably identifies and authenticates a user in one go.  Unless he loses his hands or voice or has his eyes gouged out, but that eventuality doesn’t look so nice in the authentication product marketing brochure, so we’ll conveniently ignore it.

Passwords are Annoying

Passwords have their own problems; I agree that people should use pass phrases instead of passwords whenever possible [1],[2].  Furthermore, I believe that excessively strict password complexity and rotation rules lead people to do stupid things like (with all due respect to Bruce Schneier) writing down passwords in obvious places.  Very few individuals have the time, knowledge or intelligence to write down passwords in a way that keeps them safe (plus, the “YOUR PASSWORD WILL EXPIRE IN 5 DAYS” warnings on Windows workstations tend to catch people when they’re most stressed and hurried to log in and get to their meeting.  Furthermore, password vaults tend to be impractical if, like me, you access similar resources from different workstations, laptops, interfaces, etc.

Biometric authentication gets around all this; in the case of a lot of low-end applications, such as unlocking laptops, it is a thoroughly convenient mechanism that allows administrators to get around the expense and complexity of dealing with things like BIOS/startup authentication, or the aforementioned user failings in dealing with password security rules.

So Where’s the Problem?

There are a number of classic arguments against biometric technology — principal among them being that, in case of identity theft, it is not possible for a user to change his credentials, ever.  My major objection to most uses of biometric authentication, however, is the excessive trust placed in it, combined with the absence of non-repudiation.  While most technologies involved are technologically sound and deployed in a well-meaning manner, these related failings bear the probability of inevitable negative, unintended side effects.

By virtue of its perception as an advanced, “futuristic” technology, there is a tendency to ascribe some degree of infallibility to biometric authentication.  Errors are viewed as improbable; since there are no longer external factors (knowledge or objects) involved in authentication transactions, the person logging in with a thumbprint must perforce be the owner of the thumb who was registered as such.

As an analogy, DNA matching by police suffers from a similar weakness; first, we cannot discount concerns about false positives.  Even if there is a one-in-a-billion chance that a DNA sample from a crime scene matches an innocent person as well as the perpetrator, statistically this may be acceptable, but wouldn’t it suck if you were that innocent person?  Is this tolerable?  Furthermore, as the John Schneeberger case demonstrates, even if the technology were flawless, completely circumventing the context within which DNA matching functions, by means of such shenanigans as introducing fake DNA, the entire usefulness of an otherwise good system is thrown out the window.  This is similar to the famous analog hole argument about why media digital rights management is a fundamentally broken concept; even if the hardware and software works just fine, a method completely out of its scope will render its deployment irrelevant.

In the case of biometric authentication, there are a number of conceivable (and, in my case, for lack of greater expertise, purely theoretical) situations where its employment breaks down; this xkcd cartoon demonstrates one such eventuality in a fairly insightful manner.  Given that many people will be subconsciously awed and intimidated by the cool sci-fi retinal scanners at airports, or palm readers in front of offices, this translates into a disregard for the possibility that something will go wrong with the system — dangerous because, even if the security of the system itself were flawless (which no system is) it can probably be circumvented, somehow.  This brings us to the second, and greater danger, that of the lack of non-repudiation in biometric authentication.

By means of overview, digital identifiers are used in two related but different ways to determine the authenticity of data — signing tells the recipient of data, “the information you received is the same that was sent, and it is I who sent it.”  This comes in the form of MD5 checksums, PGP signatures, etc., or in archaic terms, the royal seal on an envelope — in x.509 terminology, signing keys with an authentication bit set in their certificate containers are normally used for certificate authentication (as the key is used to sign a set of credentials transmitted to an application and to guarantee their inviolability.)

Non-repudiation means that a recipient of information can be assured that the originator cannot deny that he provided certain information; the recipient can prove that something not only originated with a given person, but that person is not able to reneg on the information.  Signatures on credit card slips or notarized contracts are the most common real-world examples of this.  There is a subtle difference between the two — signing assures the recipient that information and sender data are correct, non-repudiation guarantees the recipient that the sender will abide by the terms of the information received.

Authentication by biometrics introduces the idea of non-repudiation into a transaction where it usually has no business.  A user is first identified, then authenticated.  Both of these components of the authentication transaction three-step process take place using the same single medium — part of the user’s body.  This is bad.  As the user is identified as who he is, the authentication process suddenly and automatically includes an audit trail — which cannot, by definition, be contested.

When John Smith, average employee, sits down to log into his company workstation, he enters his username and password.  Even though his username may be “smithj”, which is tied his employer’s Active Directory to his username and photo, the disconnect between the person and the authentication framework means that he is not treated as an individual, but rather as an anonymous construct that possesses, hopefully legitimately, John Smith’s authentication credentials.  Can I prove that someone did not steal John Smith’s username and password?  Not really.  Maybe he wrote it down — perhaps that’s a firing offense in itself, but there is at least the reasonable doubt that it was he who logged in.

Not so with biometric ID.  The moment he swipes his palm across the door entry plate, or looks into the airport retina scanner, even if there is some doubt that it is, indeed, John Smith requesting authorization, that doubt enters the realm of the statistically irrelevant.  Fine for criminal prosecution, but decidedly suboptimal if you are John Smith who spent his Sunday in bed with a book rather than breaking into his workplace with a fiendishly clever copy of his thumbprint, or by jury-rigging the actual scanner with a battery and a bunch of wires.  The fact that it was a physical part of John Smith that was used (in the mind of the authentication system) to open the door or unlock the workstation means that the audit trail automatically associates him with his action.

This extends to a person’s movements between countries, his use of a cell phone, his travel in a car, his purchasing habits — all of which can be plausibly denied and repudiated if physical or virtual items, such as passports and PIN codes, are used to authenticate the user.  Identity theft at this point may be unlikely, but fatal for the victim.

How to Fix This

Biometric authentication is not fundamentally bad.  It has its place, if properly planned and implemented, and if the consequences of its use are known.

For example, authentication can be insular and local.  That is, the process does not register a user’s physical characteristics anywhere centrally, but rather uses a locally cached checksum of, say, a thumbprint to unlock a laptop or smart card — similar to what many Windows-based thumbprint login mechanisms already use.  A kerberos exchange is made with a domain controller, as with a username/password or smart card login, but the actual physical characteristic is not associated in its “raw” form with any central user profile.

Second, biometric authentication must absolutely under no circumstances be tied to audit trails; the tracking of a user’s actions and movements is information desired by law enforcement, human resources, marketing wonks, scammers and any other number of other parties, but there is no reason to tie a user himself, through his physical qualities, to his actions.  I want to be able to deny that I used my credit card in Indonesia last Tuesday; the moment this ability falls due to the authority of a retinal verification for a card transaction that was somehow falsified, I have a huge problem.

Next, such authentication must not cause anyone to come to harm.  As with the Mercedes example above — people are (usually) more important than objects or data.  If you evaluate your security needs and believe it’s a good idea to force someone to go through a burly Secret Service guy to get to the nuclear launch codes, that makes sense.  However, endangering someone’s safety for a car or laptop when it’d get stolen anyway, no matter what they do, would be callous and pointless.

Lastly, authentication credentials must not be tied to any other stored instance of a person’s biometric information.  This sounds paranoid, but physical characteristics, since as we see above these are refutable only with difficulty, and credentials can’t be changed.  The instant someone is able to abuse biometric credentials, a user’s entire financial credibility, his workplace history, and any number of other valuable combinations of reputation and resources may suffer.

We were recently asked to put together a requirements paper for a PKI that was being re-engineered from the ground up. It occurred to me that this might actually be a stellar opportunity to help a client get things right from the start. So, why do we always get bogged down in PKI-related organizational or management issues?

Obviously, the PKI’s main purpose is management of digital certificates for persons, organizations and technical entities. Certificate keys fall into three general categories, which I’ll use Entrust nomenclature to describe: encryption (obvious enough), signing (you can be sure that what you got from me is what I intended to give you) and non-repudiation (you can be sure that I cannot disavow what I gave you.) So, let’s look at what you might actually use these for:

• User authentication (such as web sites or to workstations via smart cards)
• Email and file encryption
• Secure key exchange (e.g. for phase II IPSEC negotiation) between devices
• Source code, binary and other data signing (e.g. financial transaction information)

Why is this important? Two reasons: first, your certificate templates, which govern the formats of the certificates and their usage, depend on what you intend to do with certificates. In most certificates, for example, there is a key usage flag (a hex value) that is used for this.

Second, and more importantly, your LDAP structure must reflect you organizational structure, certificate usage and a number of other factors from the outset. This is usually the largest bone of contention in PKI design; the classic example is the Jane Doe who marries Bob Smith and changes her last name. So a distinguished name (DN) like C=Albania,O=Bob’s Widgets Inc,OU=Research,CN=Jane Doe is now kind of messy. This can be dealt with by using a friendly name, but you get the idea. Changes in requirements for LDAP attributes and DN structure affect other areas, like host naming, validity of signing and encryption keys, and and and. It gets even more fun when you start doing things like cross-certification, setting up a metadirectory for multiple directories, or integrating existing directory structures.

The upshot of all this is that a PKI affects all aspects of an enterprise that are in some way involved in authentication, security, encryption, verification of data integrity, etc. — and it has to pretty much be done right from the outset, or you run into problems of application integration, user acceptance and overall cost. We know of several directory projects that had their scope drastically cut down after they were built, when it was discovered that they simply wouldn’t work for some of what they were intended for; someone obviously hadn’t done their homework.

Most tragically, sometimes design decisions are taken or changed late in the development phase. I will recount one infamous experience of a client who, based on a few casual observations our team made, called a stakeholder meeting consisting of a room full of 35 people shouting at each other, and reversed his entire enterprise directory strategy _twice_ in the course of two hours. We’d done the underlying design and recommended a certain set of project technology several months previously, but were ignored due to political reasons. In this meeting, our group just tried to remain rational and calm, and to give information when prompted, but in the end we realized there was just nothing to be done and snuck out. It was telling that nobody noticed.

Probably, everyone who’s affected will want a piece of the discussion, and we all know how well design by committee works. Many managers also seem naturally threatened by (or nervous about) any technology that effects a lot of blanket organizational and procedural change — a perfect categorization of an enterprise PKI. It doesn’t help that such products sometimes carry the stigma of taking away autonomy from other groups; at some level, any infrastructure component using PKI certificate must follow certain standards and procedures, there’s just no way around that. This is often seen as a loss of self-determination, or it may require technical effort, and who’s going to pay for that?

So, how does one deal effectively with this? A lot of good PKI design practice involves some pretty common-sense elements:

• A knowledgeable, strong project manager who can organize management buy-in and support
• A small design team who’ve done this before and have a clue what they’re doing (good luck!)
• Individual discussions with potential stakeholders about what they want and how their concerns can be addressed
• A _lot_ of time spent on research and design — use the “hire a 6-year-old to spot any obvious flaws in your plan” model liberally here
• A clear idea of budget responsibilities in PKI deployment — but not to the end that every affected team will try to pawn off even minor changes on the PKI budget

And last but defnitely not least, a really good LDAP guy, you won’t regret it.

p.s.:  If you’re interested in reading more about non-repudiation, including how it differs from the usual technical usage of “signing”, have a look at Non-Repudiation in the Digital Environment.