|
|
|
the trouble with biometrics
by Christopher Calabrese
Chris Calabrese works at an unnamed company at an unnamed job. He has a Master's in computer science from NYU's Courant Institute of Mathematics. His research includes practical applications of security technology.
Acknowledgments
In the April 1999 issue of ;login:, Dario Forte presented the case for authenticating computer users with biometrics — "patterns of unique physiological and behavioral traits"[4]. After I read the article, I began an exchange of email with Dario about some of the little-explored issues with this technology. Our probing took the form of both theorizing and prodding vendors for information. We found some things we really didn't like. This article presents some of them. It also presents some solutions. The Trouble with Biometrics Biometrics are nearly infallible at correctly identifying who a person is. But applications don't authenticate people — they authenticate software that sends them some authentication data, like a password. For this to work with biometrics, the application has to ensure that it's talking to a genuine client talking to a genuine biometric device talking to a genuine person. The same problems exist in the password world. In fact, all authentication mechanisms have to deal with the problems of replaying stolen authentication data; stealing authentication data; and trusting the client, the server, and their intermediaries. So what's the trouble with biometrics? When passwords are stolen, you change your passwords. When credit card numbers are stolen, you have a new card issued. When digital signatures are stolen, you generate new keys. When biometrics are stolen, you can get new ones too. If you're willing to have an organ transplant. This article examines how well different biometric authentication models prevent biometric data from being stolen and keep from being fooled by stolen biometric data. The Password Model The simplest way to perform biometric authentication is to gather biometric data from the end user and ship it off to the application just like a traditional password. To use the real-world example of a bank ATM, the end user would present some body part to the ATM, the client software would send the data to an application across the bank's network, and the application would try to match the biometric data against its user database[8]. This is the most popular model for current biometrically authenticated applications. Unfortunately, it's poorly suited to biometrics. This section examines where biometric data could be injected or stolen along the way. The Biometric Devices Themselves The biometrics manufacturers seem to have paid lots of attention to getting high-quality biometric data that comes from a real live person. This is, after all, the area of research from which they sprang. That said, there are two avenues of attack open against these devices. One is device disassembly and modification. This can be dealt with by encasing all the electronics in epoxy, or by using small devices over which the end user has physical control. The other avenue of attack is a Trojan-horse device. Simple device swapping can be dealt with by having the device digitally sign its transmissions with a mechanism like RSA or Digital Signature Standard[10, 11]. This way the device is authenticated to the application along with the user. The device's signature has to be on file along with the user's biometric data, but that's no big deal. I'm not aware of any device that can do this at this time, however. Also, if the manufacturer or supplier supplies the Trojan then all bets are off — a good reason to stick to trusted suppliers with lots of liability insurance. The Biometric Device-to-Computer Link Most current biometric devices are linked to a control computer by a serial cable or by Ethernet. When I asked vendors about keeping this link secure, one answered that the link should be physically secure[14]. That's fine if it's a short serial cable in a bank under armed guard. It's not a very good solution for a PC in a cubicle or a device attached to the building Ethernet. Another possibility is using encryption to protect the link. Reasonably simple encryption mechanisms could be used to protect the link from having data stolen, and at least one vendor is taking this approach[14]. However, protecting the link from replay attacks in the password-like model under examination requires digitally signing the data. The Client Software This is an area where the biometric-device manufacturers have little control and there are few standards. Given how buggy most software is, this seems like an excellent place to steal biometric data. Insecure operating environments compound the problem by allowing an attacker to drop in a Trojan copy of the software with complete control to inject or steal biometric data. Once again, the only solution under this model is end-to-end encryption and signing. The Client/Server Network Link When asked about protecting the client/server network link, manufacturers referred to "industry standards"[14]. I assume they were talking about the protean BioAPI™ standards, which will provide " 'hooks' for secure networking and encryption"[1]. What these hooks are or what kind of encryption is supported is not specified, though my guess is that most applications will use Secure Sockets Layer / Transport Layer Security (SSL/TLS)[3, 6]. If this link is properly encrypted, it may be safe from data injection and stealing. However, the industry standards are not in place yet, so this is still a matter of conjecture. The Server Software and How It Authenticates In the password-like model we're examining, the bits that finally end up at the server will be the actual biometric data (albeit possibly encrypted and signed). This data is then compared against a database of known users. One danger here is that buggy software, an insecure operating environment, or Trojan software will allow an attacker to inject or steal data at this point. As with the client software, the buggy nature of software leads me to believe that at least some implementations will be insecure. Trojaned software can be dealt with somewhat by digitally signing data transmitted by the server. The real danger at this point, however, is with the authentication database. If the database is kept encrypted with a secure hash that is unique to the application, then stealing the database will only allow replay attacks on this application. If the database is kept in the clear, the data can be stolen and replayed to any application. Summary The point of using biometrics is to get away from the shortcomings of the password model, yet the model used by most current biometrically authenticated applications is the password model. Not only do we get all the problems of the password model, but we can't even change our authentication codes if they're stolen! Encryption can help, and the industry seems to be moving in the right direction, but nobody's yet talked about the kind of two-way end-to-end encrypting, hashing, and signing that is necessary. A Challenge/Response Protocol In the password world, a common solution to the shortcomings of the password model is to use a challenge/response protocol. In this model, the actual password (or biometric data) is never transmitted. Instead, the application sends a challenge that can only be answered correctly if the client knows the correct password (biometric data). The best-known example of this is the PPP Challenge Handshake Authentication Protocol (CHAP), which is used to authenticate dial-up network connections[13]. In the biometrics world, the application would send a random challenge and the biometric device would respond, for example, with a secure hash of the biometric data concatenated with the challenge. By keeping the actual biometric data off the wires and away from any components other than the biometric device and the final authentication system, a challenge/response protocol keeps the biometric data from being stolen at intermediate points. This mechanism does not address replay attacks by a Trojan biometric device, so the biometric device still needs to digitally sign its transmissions to authenticate itself. At least one vendor is working on a challenge/response protocol like this for its product. This section examines how this challenge/response model performs at each step of the way, just as we examined the simple password-like model above. The Biometric Devices Themselves The devices still need to be physically secure, and they still need to digitally sign their data to help ensure we don't have a Trojan device. The Biometric Device-to-Computer Link, the Client Software, and the Client/Server Network Link Since there is no actual biometric data flowing through these intermediate components, it can't be stolen. Using a unique challenge for each authentication deals with replay attacks. The Server Software The server software is still a target in this scenario. Since the application doesn't have to sign its transmissions in this model, however, it's easier to separate the authentication component from the rest of the application. This makes it easier to build a secure authentication component. The Authentication Database A challenge/response protocol does nothing to deal with the problem of data being stolen from the authentication database. Summary A challenge/response protocol with digital signing of the responses addresses many of the vulnerabilities of the encryption-protected password-like model. It also makes it easier to build a hardened authentication component that's separate from the rest of the application. It should even be easier to implement than a password-like protocol with the necessary encryption, hashing, and signing. Authenticating Only to a Crypto Card In the password world, the rung on the ladder above challenge/response is not using passwords to authenticate to applications at all. Instead, passwords are replaced with cryptographic authentication. One of the problems with such systems is keeping your private keys from being stolen. One of the best solutions is never allowing them to leave a crypto card dedicated to performing all the necessary cryptographic computations. One of the problems with this approach is authenticating the user to the crypto card. This is a perfect application for biometrics: no complex operating environments, no network transmissions of biometric data, no big database of biometrics. Just a card with a couple of chips epoxied to it that you keep in your pocket. Devices of this type are starting to come to market, and it's also an active research area[2, 5, 7]. This section examines potential problems with this approach. Stealing Biometric Data Stored on the Card This is a fairly easy problem to solve. Store only a secure hash of the biometric data on the card. To perform the authentication, the card hashes the data from the biometric reader and compares it to the stored value. If the values match, you're in. If the card is stolen and the hashed keys are retrieved, they still can't be used for anything. All bets are off if the card is a Trojan, but there are a number of reasons a Trojan card attack would be difficult to pull off. First, any Trojan card has to include the real card's keys or the owner will notice pretty quickly that the card's not working properly. This means a successful Trojan is one where the real card is stolen, modified, and returned, or where the manufacturer/supplier supplies the Trojan. The stolen/modified/returned route is pretty unlikely since physical security of such cards is easy and modifying them is not. The manufacturer/supplier is an issue, so, as I said before, make sure you go with trusted suppliers with lots of liability insurance. Injecting Stolen Data into the Card The card can be unlocked by only one person, who usually carries the card on his or her person, so you have to steal the card and the right person's biometric data. If you do this, you still have to deal with the fact that the devices can check that they're dealing with a real live person. Sounds mostly like a nonissue, assuming the manufacturer didn't install a back door. Stealing the Keys on the Card and other Nonbiometrics Issues Yes, there are known attacks on card devices, though fewer for a device of this type than for a full smartcard[9, 12]. One nagging issue is a rogue client program that gets your card to sign something it shouldn't have. At least the digital signatures remain intact, however, and the biometric data is not compromised at all. Also, if the card is compromised, you can always dispose of it, get a new one, and generate new keys — just as you get a new credit card if your wallet is stolen. Not pleasant, but much better than an organ transplant. Summary This approach addresses all the issues with biometrics being stolen or replayed. It introduces some new issues of digital signature management, but the trade-off is probably worth it for many applications. Why This Is Important
Conclusions Biometric authentication is a great way of authenticating people to computer applications. Most current implementations, however, leave a lot to be desired. What's scary is that some people assume that because biometrics are nearly infallible for identification, applications that use biometrics for authentication are automatically safe and secure. Even scarier is that others don't even care if biometrics are actually safe, since using biometrics is just so cool. There's also the question of whether authenticating a person is appropriate for a particular application (think Swiss banking privacy laws).
This article has identified two alternatives to the current
password-like biometric authentication model: challenge/response and
authenticating to a crypto card. The challenge/response scheme has
issues with the final authentication database/process being subverted,
while the crypto-card scheme has issues with the client software Let's hope the industry and its customers realize the current dangers before someone steals a large database of biometric data and puts part of the industry out of business at great expense to their stockholders, their insurance companies, and their customers. References [1] <http://www.bioapi.org/arch_des.pdf>. [2] Cascade Project, "CASCADE, A Smarter Chip for Smart Cards," May 1998. Available from <http://www.dice.ucl.ac.be/crypto/cascade>. [3] T. Dierks and C. Allen, "RFC 2240: The TLS Protocol Version 1.0," Internet Engineering Task Force (IETF), January 1999. Available from <ftp://ftp.isi.edu/in-notes/rfc2246.txt>. [4] Dario Forte, "Biometrics: Untruths and the Truth," ;login:, April 1999. [5] Dario Forte, private correspondence, April 1999. [6] A.O. Freier, P. Karlton, and P.C. Kocher, "The SSL Protocol, Version 3.0," Netscape Communications, March 1996. Available from <http://home.netscape.com/eng/ssl3/ssl-toc.html>. [7] U.S. General Services Administration, "GSA Office of Smart Card Initiatives — Overview and Concepts," May 1998. Available from <http://policyworks.gov/org/main/me/smartgov/initiatives/scpaper.htm>. [8] Terri Langford, "Texas Bank Uses Eye Scan to Get Cash," Associated Press, May 1999. Available from <http://dailynews.yahoo.com/headlines/ap/technology/story.html?s=v/a p/19990514/t c/atm_eye_scanners_5.html>;. [9] T. Messerges, E. Dabbish, and R. Sloan, "Investigations of Power Analysis Attacks on Smartcards," USENIX Workshop on Smartcard Technology, May 1999. [10] U.S. National Institute of Standards and Technology, "Announcing the Standard for Digital Signature Standard (DSS)," Federal Information Processing Standards Publication 186, May 1994. Available from <http://www.itl.nist.gov/div897/pubs/fip186.htm>. [11] R. L. Rivest, A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, February 1978. [12] B. Schneier and A. Shostack, "Breaking Up Is Hard to Do: Modeling Security Threats for Smart Cards," USENIX Workshop on Smartcard Technology, May 1999. Available from <http://www.counterpane.com/smart-card-threats.html>. [13] W. Simpson, "RFC 1994: PPP Challenge Authentication Protocol (PPP)," Internet Engineering Task Force (IETF), August 1996. Available from <ftp://ftp.isi.edu/in-notes/rfc1994.txt>. [14] Private correspondence with various biometrics vendors, April 1999.
|
 Need help? Use our Contacts page.
Last changed: 18 Nov. 1999 mc |
|
Issue index