Specifying Biometrics

For several years now, industry observers have been predicting an explosion of biometric applications which will forever banish the card and PIN. The reality has been subtly different, with a steady but relatively small stream of applications being configured and implemented, often in high security situations. In addition, many of these applications have utilised biometric verification technology in association with a token such as a magnetic stripe or chip card. The result of this steady trickle of background activity is that biometric technology may now be considered as mature and capable of providing real benefits when intelligently applied to a given situation. There are many potential applications for biometric technology. In short, any situation where we would like to verify an individuals identity in respect to a transaction may be a candidate for biometrics. Such applications may range from physical or logical access control to retail point of sale or banking transactions, to automated border control for example. It should be remembered however that biometrics are not a panacea for every personal ID related situation. There may be perfectly valid reasons why the adoption of biometrics is not the answer in some cases.

As in all good application designs, it is the business process requirements which should drive the design - not the other way around. Similarly the specific type of biometric chosen, i.e., fingerprints, iris codes, hand geometry etc. should reflect the application requirements - the application should not be a slave to an individual biometric methodology.

A successful application development and deployment scenario may follow a path something like the following;

Identify the business and operational requirements clearly, together with any current problems and the effect they are having on the situation.

Develop and agree a suitable business process which has the potential to significantly improve on the current situation, given the current state of technology.

Quantify the operational logistics such as (in an access control context) number of people, time profile / distribution of transactions, type of entry point, target transaction time, environmental considerations, availability and profile of system operators and so on.

Analyse existing situation and processes in order to identify legacy requirements and system interaction - it may be necessary to retain or assure compatibility with certain existing processes.

Design a system architecture which accounts for all of the above whilst remaining open for future development and enhancement.

Design an operating methodology and user interface which satisfies the above requirements in an intuitive and attractive manner.

Choose the appropriate front end technology accordingly (i.e., biometric / biometric and chip card etc.) ensuring that the biometric methodology is the most suitable for this application.

Interface the biometric / token technology with your system.

Thoroughly test and document the system in house before demonstrating the system to the client and agreeing and documenting any design changes.

Develop and schedule an operator training programme together with the provision of system manuals as necessary.

Install and commission the system having surveyed the site and noted relevant conditions and with due consideration to existing systems.

Hand over the system after ensuring that operators have a comprehensive understanding of the functionality and that all operating data is present and correct.

In the above example, you will notice that the final choice of a biometric came relatively far down the list. We should only be considering this parameter once we have fully understood the business requirement and the potential benefit that adopting a biometric system might bring.

In defining the specification required, we should concern ourselves with perceived ease of use, acceptable transaction time, contingency measures for errors, where the biometric template should be stored, enrolment procedures and logistics and general compatibility and connectivity issues.

We should also understand the distinction between verification and identification. In short, verification is a straightforward one to one check whereby we are comparing a live biometric sample with a single stored template with a simple match or no match result. Identification is a different kettle of fish entirely as we may be seeking to compare a live biometric sample with hundreds, thousands or conceivably even millions of stored templates. The probability of errors multiplies with the number of templates in the database. Currently, there is really only one commercially available product which offers the promise of practical identification from a large database of templates. For the majority of applications we are probably going to be concerned with biometric verification..

We must also consider where the biometric template (the individual reference derived from taking a biometric sample or series of samples) will be stored. It may be that the template is stored on a token such as a chip card and input into the system by the user prior to verification. This would certainly allow for a large user base as well as a degree of portability between systems and would provide for automatic updating of templates if appropriate. Alternatively, we may decide to keep the templates on a central database and call them from either a card swipe or PIN input for comparison. This decision will naturally have an impact on system hardware and configuration - if we are maintaining a central database we had better be sure about our system host and it's communication with the biometric readers, not to mention the usual database maintenance and backup requirements.

Whilst we are on the subject of hardware, it is worth stressing the importance of understanding the cabling and line termination requirements of different communication protocols. Lack of attention to detail in this area can often result in temperamental performance and perceived intermittent faults which can be difficult to trace subsequently. Whilst this may seem like stating the obvious, it is surprising how often otherwise well designed systems are tripped over by poor installation practice.

You will have noticed that we have got a long way into this paper without trundling out the usual marketing promises about biometrics or contemplating the old chestnuts of false accepts / false rejects etc. This is deliberate - one can concentrate too much on the theoretical individual device performance issues. The performance we should concern ourselves with is that of the entire system, not individual components. In the real world, theoretical performance may be influenced greatly by other less quantitative parameters. For example, a badly sited reader which is difficult for individuals to use comfortably will almost certainly result in increased false rejects, even though the system may be functioning properly. Similarly, a lack of training or understanding among both system administrators and regular users will play havoc with your anticipated performance. The operational processes coupled to the perception and attitude of the user are as much of a performance criterion as biometric hardware specifications. These elements, coupled with overall system design and component performance combine to produce the Total System Performance (TSP). It is the TSP that we should have uppermost in our minds throughout the development and implementation of the entire project.

To put this into perspective, it would seem rather pointless to have lengthy discussions about the inclined valve angle on a one litre petrol engine which we are fitting into a three ton vehicle - we should be asking about power to weight ratios and what sort of engine we need to propel this vehicle at the required speed. The same is true of our biometric system. We must consider the system as a whole, together with our business related objectives for implementing such a system.

So far, we have discussed some of the issues inherent in a typical systems supplier / client situation. In certain cases, the end user (or retained systems house) may wish to buy in the component technology on an OEM basis and develop their own custom application according to precise requirements. In the early days of biometrics this would have been quite difficult with many of the proprietary products available. These days life is a lot easier for the application development team as several of the leading device manufacturers have taken the trouble to make available a Software Development Kit (SDK) for use with their product. This usually takes the form of a set of DLL's which the developer may call from his application in order to access various functions of the device. This allows the developer to concentrate on the user interface and program logic without having to get too involved with the low level coding detail.

This is certainly a step forward and is to be welcomed. However, it is a little device specific in the sense that if you decided later on to use a different front end biometric device, then you would need to rewrite your application accordingly. This may be acceptable in some instances, but what if you wish to use more than one type of biometric device on your system? This is not unreasonable. You may wish to use a dual biometric for high security reasons, or to use different biometrics in different areas for environmental reasons. This can complicate matters somewhat. It would be nice perhaps if there were a universally accepted biometric Application Programming Interface (API) which developers could use in order to mix biometric methodologies within a single system. In fact, there has been much work undertaken in this context and by the time you read this paper at least one such API should be freely available. The question is, will the biometric manufacturers be happy to comply with and support such an initiative? I hope that they will, but suspect that this may take a while to become embedded in biometric culture.

What of the future? The is no doubt that biometric technology is mature and eminently useable across a wide variety of advanced personal ID related applications. Both the systems integrator and the end user have a wider choice than ever of front end biometric components and it is easier than it has ever been to integrate these components into bespoke systems. Individual unit cost is still relatively high for biometric products, but this too is changing and several manufacturers are introducing lower cost OEM modules to the market place.

In short, if you have an operational problem that biometrics might solve there is no reason to sit on the fence any longer - biometrics are alive and well and available off the shelf at a location near you!

 Julian Ashbourn