IT Shop Requirements for Exploiting Biometrics

In a recent post I noted that the Target breach once again raised the idea of biometric authentication as means of improving the protection of corporate data. Yet for all of its benefits, adoption of biometric authentication within the IT shop has been negligible. I believe that’s due to two primary factors.

1. The misconception that biometric authentication has a negative impact on privacy, covered in a previous post

2. The perceived complexity/lack of technical understanding in the average IT shop, which is today’s topic

FULL DISCLOSURE

This is one of my favorite security topics, although I admittedly have many favorites. But in the interest of full disclosure, I have spent so much time thinking about biometric authentication from the IT shop perspective because I have partial ownership in a company that provides a biometric framework for IT shops. Today, though, I’m wearing my “independent security consultant” hat. My intent is to share what I consider to be the major complexities and best practices for biometric authentication from an IT shop’s point of view.

THE BASICS OF BIOMETRICS

I liken the complexity of biometric authentication to the complexity of authentication using digital certificates. While the basic ideas are fairly straight-forward, the implementation and management of them is complex and have a number of “moving parts.”

Before getting into specific complexities, let’s first discuss the difference between “on device” and “on server” authentication. “On device” means that the user’s enrollment template is captured and stored on a specific sensor(s). “On server” means that the enrollment template is stored in a centralized server either in the employer’s internal network or in the cloud.

Some security experts are wary of “on server” authentication. I want to acknowledge these reservations. However, after spending a considerable amount of time investigating them, I am convinced that centralized management and on-server authentication are necessary for IT shops to be able to effectively deploy and manage biometric authentication. Further, I believe it is possible to do this in a way that provides significant improvement in security beyond that provided by passwords. Unfortunately, laying out the rationale for my belief would require a separate article (or book!), and that is not the focus of this article.

For IT shops to effectively utilize any authentication mechanism for controlling network access to servers (e.g. Telnet signon), server applications (e.g. ERP applications), or Web applications, the authentication mechanism must have the following characteristics:

• Centralized authentication server/repository

• Centralized management of enrollment;

• Invokable during server system signon;

• Invokable during application signon;

• Invokable from within an application;

• Ability to mix and match sensors from different manufacturers;

• Ability to use different types of biometrics (e.g. fingerprint and retinal scans) in different environments or for different applications.

Now let’s look at the potential complexity involved for IT programmers to implement biometric authentication in a way that meets the required characteristics.

Similar to certificates, the first problem is that the end user has to have access to a workstation with a biometric sensor installed. (Note that in this article the term workstation can mean a PC, smartphone, or other mobile device.) Next, the user has to be somehow “enrolled” before the installed sensor can be of any use.  Next, the IT programmer has to be able to cause the end user’s workstation to prompt him or her to place their finger or palm on or near the sensor, or to look into a camera, etc. The programmer then has to be able to cause the device to create a template, and transfer the template to the authentication server to compare it with an enrollment template.

AUTHENTICATION SERVER/REPOSITORY

For on-server authentication, you obviously need a server that manages the comparison of templates captured from a biometric sensor and you need a repository of enrolled templates for authorized users. Sensor manufacturers provide all of the APIs you’ll need to build these. Building a server and repository in a way that enforces the tightest security possible is a task left for the reader.  And the components you need from the manufacturer may or may not be available for the platform you want to use. Not to mention the need to build a communication protocol that effectively utilizes encryption to protect data in transit and to prevent spoofing.

This is a complex task. There are only a couple of biometric infrastructure companies that provide this function.

CENTRALIZED ENROLLMENT

IT needs to control enrollment for obvious reasons.  Biometrics wouldn’t do you much good if an attacker was able to enroll themselves in your biometric repository without any management approval.  This would be like letting anyone create a userID and password on your system.

Centralized enrollment is complex because, unlike passwords, it requires an administrator and the end user to take part in the enrollment. With passwords, the end user only waits for an administrator to create a userID, which can be done remotely. With biometrics, when these two are not in the same physical location, you have to build an enrollment application that provides the level of trust necessary for the administrator to ensure that they are enrolling the person they think they are enrolling.

Again, there are only a handful of biometric infrastructure companies that provide this function and those that do often require enrollees and administrators to be in the same physical location.

INVOKING OVER A NETWORK CONNECTION

IT needs to be able to invoke a biometric authentication from IT-controlled servers and applications.  However, by definition, the server is not directly attached to the end user’s workstation. This implies that the server application needs to:

1. Find the workstation at which the current user is located;

2. Send it a request to provide a template for authentication;

3. Cause the workstation to display a prompt of some kind for the user to interact with the biometric sensor;

4. Cause the sensor to produce a biometric template;

5. Securely transfer that template back to the application and/or the biometric authentication server; and,

6. Get the authentication result from the authentication server.

In addition, the IT Shop often doesn’t own the application with which the user is interacting. IT only owns the server application (e.g. Web server applications, Web services, etc.).  IT often won’t have the ability to modify the client side application. This implies that a software agent needs to reside on the web server and that communication between the server application (or perhaps the authentication server) and the workstation needs to be done through the agent rather than the client application.  This gives IT the control it needs over when authentication is performed. This adds lots of additional complexity.

We haven’t even discussed the concepts of “Fers” and “Fars” in biometrics. When comparing biometric templates, there are various parameters that can be tweaked to improve False Rejection Rates (FRR or Fers) and False Acceptance Rates (FAR or Fars.) This takes knowledge and testing.

All of this also implies the need for a set of APIs for IT programmers to use in server applications.  These APIs need to be very simple. For example, AUTHENTICATE(…), where the parameters include only basic information already available in most IT shop applications (e.g. userID, IP address.) These APIs need to be available in a variety of languages including C++, Java, COBOL, and RPG. Anything more complicated and it will require too much knowledge by business programmers and too much time to retrofit to existing applications.

Needless to say, this alone would be a major and costly development project for any IT shop.

MIX AND MATCH MANUFACTURERS

Until the last few years, each sensor manufacturer had proprietary template structures and matching algorithms. This meant that for an IT shop to deploy biometric authentication within their applications they would have to “bet the farm” on a particular manufacturer. Switching to another manufacturer with better and/or cheaper sensors would mean redoing all of the client-side implementation. It wasn’t possible to start with a few sensors from one manufacturer and then purchase a few more from different one, and have them all work with the same IT applications.

A few years ago, the National Institute of Standards and Technology (NIST) defined a standardized fingerprint template. Manufacturers needed to support that standard in order to sell to the federal government. This has made mixing and matching sensor manufacturers a little less complex. Each manufacturer has its own authentication engine for comparing standardized templates, but in theory they should be able to compare any standardized templates regardless of which sensor generated either template.

Having said that, however, each manufacturer has its own device driver APIs for interacting with their sensors. This implies that the software agent running on the workstation has to be modified to support each manufacturer’s biometric device.

MIX AND MATCH TYPES OF BIOMETRICS

Consider a medical clinic that has a day surgery as well as doctors’ offices. When a doctor is seeing patients in the office, a fingerprint sensor is probably acceptable. However, when that doctor is scrubbed for surgery and needs to access a surgical related application, a fingerprint sensor is not acceptable. They would require something like a palm vein sensor that can read through surgical gloves without the wearer having to physically touch the device.  This is an example of the need to not only support different manufacturers, but to also support completely different types of biometrics

The APIs discussed earlier need to hide all of this complexity from the application developer. Employers cannot afford to train business logic programmers to be biometric authentication engineers.

COMPLEXITY CONCERNS ARE REAL

The previous discussion should have proven that the complexity concerns of biometric authentication are real.  Complexity is a major factor as to why biometric authentication has not been widely adopted by IT shops.  Further, it is a much more legitimate concern, in my option, than those related to privacy.

A BIOMETRIC FRAMEWORK FOR IT SHOPS

I will not attempt to discuss in this article how my other company’s product addresses the complexities of biometric authentication described here. Suffice it to say that I believe it does. If you are interested, check out the biometrics page of the www.botzandassociates.com web site and subscribe to my newsletter or blog. From time to time I will have an article about my other company and its product.

Having said all that, I hope you have found the last two newsletters illuminating and worthwhile. Whether you have or haven’t, I’d love to hear from you. Comment on this post, leave a message on the contact us page on the web site or send me an email at botz@botzandassociates.com and let me know!