An Overview of Biometrics Support in NetWare Through NMAS

Articles and Tips: article

David Heath
Sales & Technical Manager
Triton Secure Ltd.
dheath@tritonsecure.com

01 Jul 2001

This AppNote provides an overview of biometrics and how this branch of security/authentication technology is supported in the NetWare environment through Novell Modular Authentication Service (NMAS). It outlines the functionality of a typical NMAS solution, and presents several NMAS implementation scenarios. Since this AppNote was written in Australia, it retains the British spelling used by the author.

Introduction
Overview of Biometrics
Structure and Operation of NMAS
NMAS Implementation Scenarios
Conclusion

Introduction

One of the biggest ironies about today's computer-enabled, network-connected business environments is that security-conscious administrators feel reasonably safe with even the most basic password protection schemes. One night after everyone has gone home from the office, try taking a walk past all the PCs in a division of your company and look for evidence of passwords being written down. Look on monitors, under keyboards, in desk drawers, and so on. I expect what you find will cause you some level of dismay! My own experience is that, in any organization serious about using effective passwords and enforcing password selection rules, between one-third and one-half of the users will have recorded their passwords in some fashion.

Worse, it turns out that the principal governing factor is your own password security policy. Typically, the more rigorous you make your password selection and construction rules, the more difficulty users will have in remembering their passwords. Unfortunately, strict password rules are necessary to stop simple hacker attacks on the network; there are too many publicly-available programs that perform "brute force" dictionary-based attacks.

There is also the issue of shared passwords. You might sit down at Bob's desk while he is at lunch and shout to the others in the room, "Hey, does anyone know Bob's password?" Too often you'll get the correct (but wrong!) answer.

The Problem with Passwords

The fundamental problem with passwords is two-fold. First, they are transferable: they can be written down on paper; they can be transferred to someone else's head; and they can be transferred to someone who shouldn't have them. Second, and just as important, they can be forgotten. Recent research suggests that a forgotten password can cost as much as US$340 per event! This isn't too surprising when you consider the lost productivity of the user and the flow-on effect to other workers, and also the share of help-desk resources (and on-costs) consumed by the event. Of course, some incidents will cost much less, while others can cost much more. (I was given an anecdotal example where a single forgotten password-by the CEO-cost a company in excess of $10,000.) Stop for a moment and imagine the cost of forgetting the admin password for your Novell eDirectory tree!

Conversations with two large governmental organizations suggest that out of a user population of 2500-3000, approximately 30 users call the help desk on a Monday morning for a password reset, while 10-15 more call on other days of the week. Doing the math, you can easily show that the average user forgets his or her password around 1.4 times per year. Relating that back to the research above suggests that forgotten passwords cost around an average of US$450 per user per year.

Clearly, the risks and costs of compromised passwords are a significant factor to consider in developing any secure system. The critical need for additional levels of security has given rise to the field of biometrics.

The Role of Biometrics

Biometrics has been occupying a niche in the computer industry for more than a decade. However, for many of those years, biometric systems were monolithic- generally top-to-bottom solutions provided by single vendors for specific applications. There were no modular solutions, no API interfaces, and no device independence. It has only been in the last 18 months or so that biometric systems have achieved a more mainstream position as a feasible alternative or add-on to password-based systems.

Novell has long recognised the importance of biometrics as a valuable method of personal authentication. They have also recognised that there is a need for a modular, hierarchical authentication structure to augment the existing password- only regimes. The result is Novell Modular Authentication Service (NMAS), a single, cost-effective point of administration for managing, grading, and accessing all biometric and non-biometric authentication methods to your enterprise. Central to all authentication is Novell's eDirectory (formerly known as Novell Directory Services or NDS), which controls the configuration of access methods and the allocation of these methods to users.

This AppNote provides an overview of the major biometric methods and introduces the biometric partners who support the NMAS environment. After a brief look at how NMAS works, the AppNote closes with a number of real-world implementation scenarios where the combination of NMAS and biometrics offers real benefits.

Overview of Biometrics

History of Biometrics

The term "biometrics" is derived from the Greek words bio (life) and metric (to measure). We typically choose to interpret biometrics as methods for determining unique (or relatively unique, if such an expression is allowed) features of a person's body to distinguish them from the rest of humanity. Note that there is also a branch of statistics with the same name. This branch deals with all manner of data pertaining to variability in human form, some of which is of value to the "biometrics" of the computer industry.

The concept of identification based on aspects of the human body is certainly not a new one. As early as the 14th century, the Chinese were reportedly using fingerprints as a form of signature. During the late 1890s, a method of bodily measurement called Bertillonage (after its founder Alphonse Bertillon) was used by police authorities throughout the world. This system quickly faded when a case of two indistinguishable people with almost identical names was discovered. From this point on, fingerprinting (developed by Richard Edward Henry of Scotland Yard) became essentially the only identification tool for police.

Today, a variety of methods and techniques are available to determine unique identity, the most common being fingerprint, voice, face, and iris recognition. Of these, fingerprint and iris offer a very high level of certainty as to a peron's identity, while the others are less exact. A large number of other techniques are currently being examined for suitability as identity determinants. These include (but are not limited to) retina, gait (walking style), typing style, body odour, signature, hand geometry, and DNA. Some wildly esoteric methods are also under development, such as ear structure, thermal imaging of the face and other parts of the body, subcutaneous vein patterns, blood chemistry, anti-body signatures, and heart rhythm, to name a few.

Major Biometric Methods

The four primary methods of biometric authentication in widespread use today are face, voice, fingerprint, and iris recognition. All of these are supported in the NMAS environment, some more abundantly than others. Generally, face and voice are considered to be a lower level of security than fingerprint and iris, but on the other hand, they have a lower cost of entry. See the table at the end of this section for a complete list of biometric methods.

Face Recognition. Facial recognition has advanced considerably in the last 10 to 15 years. Early systems, based entirely on simple geometry of key facial reference points, have given way to more advanced mathematically-based analyses such as Local Feature Analysis and Eigenface evaluation. These have been extended though the addition of "learning" systems, particularly neural networks.

The task of identifying people by face recognition can be easily divided into two sub-tasks. Firstly, there is the task of recognising a face in a scene and extracting it from the surrounding "noise." Secondly, any computer system must then be able to extract unique features from that image and compare them with images already stored, hopefully correctly identifying the subject at hand. Based on the source of the facial image, there may also be a need to perform "liveness" tests such as determining that the head is moving against the background and that a degree of three-dimensionality can be observed. Other systems are intended to work from previously recorded images and don't test for these factors.

Face recognition systems are particularly susceptible to changes in lighting systems. For example, strong illumination from the side will present a vastly different image to a camera than neutral, evenly-positioned fluorescent lighting. Beyond this, however, these systems are relatively immune to changes such as weight gain, spectacles, beards and moustaches, and so on. Most manufacturers of face recognition systems claim false accept and false reject rates of 1% or better.

In a Novell NMAS environment, a typical face-recognition system would rely on a simple Web camera to acquire an image prior to authentication processing, with the user gently moving his or her head while the software captures one or more images. PC resource requirements are no more than for a typical desktop PC. In an environment where moderate security is sufficient and there is no desire to purchase additional hardware (assuming the Web cameras are available), this is a very useful authentication technique.

Voice Recognition. Software systems are rapidly becoming adept at recognising and converting free-flowing speech to its written form. The underlying difficulty in doing this is to flatten out any differences between speakers and understand everyone universally. Alternatively, when the goal is to specifically identify one person in a large group by their voice alone, these very same differences need to be identified and enhanced.

As a means of authentication, voice recognition usually takes the form of speaking a previously-enrolled phrase into a computer microphone and allowing the computer to analyse and compare the two sound samples. Methods of performing this analysis vary widely between vendors. None is willing to offer more than cursory descriptions of their algorithms-principally because, apart from LAN authentication, the largest market for speaker authentication is in verification of persons over the telephone.

A number of issues contrive to weaken the performance of voice recognition as a form of biometric verification of identity. For instance, no two microphones perform identically, so the system must be flexible enough to cope with voiceprints of varying quality from a wide range of microphone performance. Also, the same person will not speak the code-phrase the same from one day to the next, or even from one minute to the next. Most vendors claim false accept and false reject rates of around 1- 2%, although my personal experience suggests this may be excessively confident.

It is safe to assume that every desktop PC in an organization is either already fitted with a microphone or can easily have one added at minimal cost. This is the main attraction of voice-based identification schemes-no other equipment or significant resources are required.

Fingerprint Recognition. The process of authenticating people based on their fingerprints can be divided into three distinct tasks. First, you must collect an image of a fingerprint; second, you must determine the key elements of the fingerprint for confirmation of identity; and third, the set of identified features must be compared with a previously-enrolled set for authentication. The system should never expect to see a complete 1:1 match between these two sets of data. In general, you could expect to couple any collection device with any algorithm, although in practice most vendors offer proprietary, linked solutions.

A number of fingerprint image collection techniques have been developed. The earliest method developed was optical: using a camera-like device to collect a high-resolution image of a fingerprint. Later developments turned to silicon-based sensors to collect an impression by a number of methods, including surface capacitance, thermal imaging, pseudo-optical on silicon, and electronic field imaging.

Unlike with the previous two methods (voice and face), it is unlikely that a typical desktop PC will be equipped with fingerprint-capture hardware. Most fingerprint reader units connect to either the parallel port (and piggy-back on the PS/2 for power) or make a USB connection. In addition to standalone units, there are fingerprint readers mounded in keyboards and in combination with smart-card readers. Recently, several laptop manufacturers have begun providing a capacitance-based fingerprint scanner either mounted next to the keyboard or as a PCMCIA-attachable unit.

The process of confirming identity via fingerprint is quick and simple for the user. Upon activation of the authentication request, most systems will energise the reader and place a viewing window on the screen. The user places a finger on the reader and can observe the quality of the captured image on the viewing window. Most systems will automatically proceed to the analysis phase upon capture of a good-quality fingerprint, but some require the user to press the <Enter> key.

The most processor-intensive portion of the recognition sequence is analysing the scanned image to determine the location of ridges and subsequently the identification of points of termination and joining. For this phase, most manufacturers suggest a PC with a Pentium processor of at least 120MHz. Recent developments in smart card technology have allowed sufficient processing power to perform the actual template match on the card. This means that an enrolled template can be stored on the "hidden" side of a crypto-card and need never be released outside the card-an important step in promoting the privacy of biometric templates. However, a PC is still required to perform the image analysis.

As discussed, a variety of fingerprint detection and analysis methods exist, each with their own strengths and weaknesses. Consequently, vendors vary widely on their claimed (and achieved) false accept and false reject rates. The poorest systems offer a false accept rate of around 1:1,000, while the best are approaching 1:1,000,000. False reject rates for the same vendors are around 1:100 to 1:1000.

It is generally accepted that fingerprint recognition systems offer a moderately- priced solution with very good abilities to accurately confirm user identity. For this reason, this is the most widely-used biometric method in office environments.

Iris Recognition. Iris recognition is based entirely on a concept originated by Drs. Leonard Flom and Aran Safir, and a software process developed by Dr. John Daugman, all of Cambridge University, England. US Patent 5,291,560 issued in the name of Daugman has been assigned to Iridian Corp., one of the world's principal vendors of iris-based systems.

Extensive research has determined that the human iris is essentially unchanged in structure and appearance from the eighth month of gestation until a few minutes after death. Although a neonatal eye can be darkly coloured until a few months after birth, this darkness is not an influence in the infrared wavelengths normally used to collect an iris image.

Following identification and extraction of the iris from a captured image of the eye, a pseudo-polar coordinate system is established over the iris image. This allows a large number of two-dimensional modulation waveforms to be extracted that are invariant of changes due to iris widening (due to light levels) or to external factors such as spectacles or contact lenses.

Iris recognition systems require special iris cameras with very high resolution and infrared illumination abilities. Typically these are attached to PCs via USB connectors. The user is required to look squarely into the camera while the eye is illuminated with a focussed infrared source. Elapsed time from capture to confirmation of identity takes less than a second. Performance requirements are no greater than those already available on the typical desktop PC.

In the history of iris recognition, there has never been a false acceptance. In fact, the equal error rate is 1:1,200,000, with a typical false accept rate of 1:100,000,000 and false reject rate of 1:200,000. Note that these are theoretical values based on strong analysis of limited data (only 5 to 10 million iris scans have ever been performed); they also do not take into account the perceived level of difficulty in using the system.

Overall, iris scanning is the system to use if you are concerned about strongly authenticating users. The devices are considerably more expensive than fingerprint readers, but the gain in authentication confidence more than offsets the increased cost.

For more information about the background and methodology of iris scanning, a paper by Daugman may be obtained at http://www.cl.cam.ac.uk/users/jgd1000/irisrecog.pdf.

Structure and Operation of NMAS

In the area of authentication, several factors are identified as independent methods of testing a user's identity. The three factors normally described are:

Something you know (such as a password or PIN)
Something you have (such as an ATM card, a SecureID tag, or a PKI certificate)
Something you are (such as a fingerprint or iris)

In an authentication session, a user may be asked to provide one or more factors to satisfy a request for credentials. Thus we can refer to one-factor, two-factor, or even three-factor authentication methods. By allowing system administrators to provide localised implementations of these factors, NMAS facilitates the development of strong authentication regimes.

NMAS Support for Authentication Factors

The following sections describe the specific implementations of these factors in NMAS.

Factor 1: Password (Something You Know). With implementations provided by Novell, NMAS supports the following password authentication systems:

Standard eDirectory password authentication
Clear text password authentication
Secure Hash Algorithm (SHA-1) hashing algorithm
Message Digest (MD-5) hashing algorithm

In general, you would be expected to use eDirectory password authentication, which uses a secure challenge-response authentication where possible, or a clear text system for those environments where encrypted passwords are not possible. Be aware that some systems, while appearing to provide secured password exchanges, have weaknesses where passwords are exposed.

SHA-1 and MD-5 are complex algorithms that produce a summary of any source file, such that it is computationally infeasible to find a similar plain-text message that summarizes to the same digest. SHA-1 produces a 160-bit summary and is FIPS compliant, while MD-5 produces a 128-bit summary and is not FIPS compliant. For a full description of SHA-1, refer to http://csrc.nist.gov/publications/fips/ fips180-1/fips180-1.pdf.

Obviously, SHA-1 and MD-5 are more secure than clear text passwords and faster than eDirectory passwords. However, the performance difference would generally not be noticed in a typical LAN environment.

Factor 2: Physical Device (Something You Have). Novell refers to most physical devices as tokens. Tokens may also be implemented as locally-stored private keys. These may take the form of "smart cards" with cryptographic functionality or other handheld devices able to offer one-time passwords either as time- synchronized values or as a response to a challenge message.

Third-party partners provide all token-based methods included in the NMAS framework. They are listed in the following table. Additionally, Novell provides token-based methods, particularly for the bundled version of NMAS.

Vendor	Product Description
ActivCard www.activcard.com	By implementing a full PKI environment onto smart cards, ActivCard provides two-factor authentication, with a PIN number used to access the contents of the smart card. The Novell certificate server acts as the central key repository. Using the ActivCard Gold product, a singe PKI key-pair can be used for both eDirectory authentication and to access protected web sites and secure e-mail.
EnTrust www.entrust.com	In addition to the normal client functionality, Entrust's Entelligence client module can be used to authenticate to eDirectory, using key-pairs already issued. This is based on an existing Entrust certificate server, maintaining a trust relationship with eDirectory and Novell's certificate server.
RSA www.rsasecurity.com	RSA implements their standard RSA ACE/server environment with a modified client. The RSA ACE/Agent for NMAS redirects eDirectory authorization requests to the ACE/Server; confirmation of identity permits completion of the eDirectory authentication process. All RSA authentication techniques are supported, including software tokens, hardware tokens, key fobs, and smart cards.
SmartTrust www.smarttrust.com	SmartTrust allows eDirectory and NMAS users the opportunity to authenticate with their mobile phones. Using PKI and RSA cryptography, the product ensures that existing sources of secure PKI key storage are used fully.
Vasco www.vasco.com	Vasco offers a secure PKI infrastructure supported on both token and smart card platforms. he Vasco Digipass module for NMAS includes, server, client and management modules, allowing both "response-only" and "challenge-response" authentication schemes. PKI keys have advanced PIN protection capabilities along with secured PIN management capabilities.

Note: While not directly part of NMAS, there is strong support connecting NMAS and RADIUS. Both the RADIUS client-side and server-side components are configured to process NMAS-enabled authentication across a dial-up connection.

Factor 3: Biometrics (Something You Are). As for physical device (or token) authentication, biometrics requires additional hardware for the client PC, such as fingerprint readers, eye scanners, and so on.

Novell does not provide biometric methods with NMAS. A list of biometric partners is provided in the table below, along with a summary of each vendor's offering.

Vendor	Product Description
BioID www.bioid.com	This integrated face, lip, and voice authentication method is implemented as an external client-server environment with a separate authentication server. By looking into a Microsoft DirectShow-compatible camera (Web cam), the user's face structure is examined; lip movement is examined while the attached microphone records the voiceprint. The three biometric attributes are communicated to the BioID server for evaluation, which on successful comparison with the enrolled templates will, in conjunction with the client PC, complete the authentication process with eDirectory. Administrator configuration permits a subset of the three methods to be accepted in specific circumstances. The BioID server must be at least a Pentium II/350MHz machine running Windows NT, with 128MB of RAM and at least 50MB of disk space available. Approximately 20MB of storage is required at the client PC with a Web Cam and a microphone capable of 50-15,000Hz pickup. Enrollment takes about 1 minute for five template recordings, while authentication typically takes less than 2 seconds.
Biometric Access Corp. www.bimetricaccess.com	As with most other partner methods, Biometric Access Corporation (BAC) integrates directly into eDirectory to offer a fingerprint method based on their SecureTouch 2000 finger scanner. The scanner is an optical unit with advanced coatings to dramatically improve dry-finger detection. The system uses minutiae feature extraction and can complete the capture and match operation in less than one second. The FAR is typically less than 1% on the (configurable) medium security setting. BAC provides a user tutorial to assist the introduction of their technology "Fingerprint Lab." Currently the hardware is available as a parallel-port device, although the company advises that a USB device will be available sometime during the second quarter of 2001. BAC supply their product either through resellers or directly to end-users.
Identix Inc. www.identix.com	Identix Indicator hardware has been incorporated in equipment from a number of other manufacturers, all of which make use of the software developed and supplied by Identix. Cherry manufactures two keyboards with Identix fingerprint readers: the G81-12100 and the G81-12000 (which also includes a smart card reader). Compaq incorporates the Identicator into their keyboard, along with a rebranded standalone fingerprint reader and a PCMCIA version for notebook PCs. The Identix BioLogon software suite fully implements the biometric interface for NMAS under both NetWare and Windows NT/2000. There are no special requirements at either the server or client, apart from the usual NetWare/NT server and client requirements. In extreme situations, the software is capable of falling back to a password authentication where there are difficulties in reading a valid fingerprint. However, this clearly violates the NMAS security model as a sequence of "Biometric + Password" could in effect be executed as "Password + Password." Identix has a variety of hardware implementations, all optically based, including standalone fingerprint readers, combination finger and smartcard readers, and PCMCIA-based units for laptop PCs.
SAFlink www.saflink.com	SAFlink is purely a software house and has developed a modular platform to support a variety of biometric authentication devices from many of the leading vendors. By developing a Biometric Service Provider (BSP) module, any hardware manufacturer may be incorporated in the NMAS environment through this platform. SAF/NMAS ships with support for face recognition (with the Visionics algorithm), voice recognition (with the Anovea and Lernout & Hauspie algorithms) and fingerprint recognition (with support for the Authentec, Precise, Secugen and Veridicom fingerprint readers). Other hardware partners (including Identix and Iridian for iris recognition) are also supported in the SAF/NMAS module; the BSPs are available separately. The SAFlink platform allows users to be concurrently enrolled in one or more of the supported biometric methods, with the administrator able to select the method as needed. Unlike all other partner offerings, this structure allows great flexibility within a single management console. Note: Since writing this article, SAFlink have changed the name of their product to SAFlogon for NMAS.
SecuGen www.secugen.com	Secugen manufactures an optical fingerprint reader built into the side of a standard optical/wheel mouse. The fingerprint reader operates at 450 dpi-one of the highest resolutions for any optical fingerprint reader. The mouse is available in either USB or PS/2 and parallel connection modes. The company has a BSP developed for the SAF/NMAS platform, but has also recently announced their own partner method. Details were not available at the time of this writing.
Systemneeds www.systemneeds.co.jp	Sony recently launched the FIU-710 fingerprint reader, also known as "The Puppy." This is the only fingerprint reader to incorporate encryption between the standalone fingerprint reader device and the PC. Unlike almost all other authentication methods, most authentication information resides on the fingerprint reader itself. This is an important point when users are concerned about the location and use of their biometric data. Systemneeds, domiciled in Japan, has developed their WinSafe software to control and manage the user administration and the client experience, interacting with the Puppy device. The system also supports direct authentication to a variety of other software environments.
VisionSphere www.visionsphere- tech.com	To increase the accuracy and performance of face recognition, VisionSphere have implemented a custom camera with accompanying software. Enrollments, consisting of around nine distinct images, take approximately 1 minute, while authentication takes around 2 seconds. The face analysis method is based on a wholistic code, similar to eigenface analysis, with the ability to learn from each successful authentication. Analysed (not plain picture) images obtained from each authentication attempt (both successful and unsuccessful) can be stored for audit purposes. The proprietary CMOS camera allows connection via either USB or parallel ports and can also function as a Web Cam. It offers 640 x 480 resolution. VisionSphere's "It's Me" conforms to normal NMAS implementation guidelines, requiring a relatively typical client PC and using ConsoleOne as the primary administration tool. The interaction between the software and hardware allows for compensation due to varying lighting conditions, lens distortion and also head rotation. Additional features include direct support for PKI solutions and encryption of local folders and files.

Login Methods

A login method is a specific implementation of one of the previously-described factors used to authenticate to eDirectory. Most methods are included in the software distribution. The following table lists all methods available from Novell or from third-party developers.

Vendor	Method	Comments	Free?
ActivCard S.A.	Token	Smart Card and PKI	No
Arcot Systems Inc.	Token	Software emulation of Smart Card	No
BioID	Biometric	Face, voice, lip movement	No
Biometric Access Corp.	Biometric	Fingerprint reader	No
EnTrust	Token	Links with EnTrust profile	No
Identix Inc.	Biometric	Fingerprint reader	No
Novell Inc.	Password	eDirectory password	Yes
Novell Inc.	Password	Clear text password	Yes
Novell Inc.	Password	SHA-1 message hash	No
Novell Inc.	Password	MD-5 message digest	No
Novell Inc.	Token	Simple X.509 certificate	Yes
Novell Inc.	Token	SSL certificate mutual	Yes
Novell Inc.	Token	Advanced X.509 certificate	No
RSA Security Inc.	Token	Requires RSA Ace Server	No
SAFlink Corp.	Biometric	Multi-biometric platform	No
SecuGen	Biometric	PC-mouse fingerprint reader	No
SmartTrust	Token	Mobile phone as an authenticator	No
Systemneeds	Biometric	Fingerprint reader	No
Vasco Data Security	Token	DigiPass token	No
VisionSphere	Biometric	Face recognition	No

Note: NMAS also support post-login methods, such as screen savers.

Login Sequence

There are eight predefined Security Clearance Labels that are used to implement access restrictions at the network volume level. Specific login sequences are constructed by the administrator and composed of a representative from each of one or more factors. The following are the Security Clearance Labels, listed in order of increasing perceived strength:

Logged In
Password
Token
Biometric
Password + Token
Password + Biometric
Token + Biometric
Password + Token + Biometric

The "Logged In" method is the lowest level of security and refers to any authentication session that does not make use of the specific NMAS infra- structure. This may refer to a client PC where the NMAS software is not installed.

Sequences are typically named to represent the resultant authentication level (for example, "Web Writers" or "Microsoft Takeover Bid Team") and contain specific instances of ordered login methods. For instance, both of the previously-named sequences might be composed of Password + Biometric; both may even use eDirectory passwords; but the Web Writers biometric method might be confined to fingerprint recognition, while the Takeover Bid Team method could use iris scanning for stronger authentication.

Note: NMAS does not support the use of more than one method in any factor. For example, you cannot have two biometrics comprising a single authentication event.

Graded Authentication

Two implementations of NMAS are available: a basic version for bundling in other product offerings (such as eDirectory) and an Enterprise Edition that offers all the features of the basic version plus all methods Graded Authentication and multi-method login sequences. The bundled version of NMAS permits only one login method per sequence. Additionally, those methods may only be the Novell supplied "simple password" and "X.509 certificate."

Any user may access any sequence. However, if the sequence contains methods for which users haven't been enrolled, or for which they don't have an appropriate token, it is of little use to them. Similarly, if the necessary hardware (such as a fingerprint reader) is not installed on their PC, again the sequence cannot be used. In the two-method examples listed above, a user's PC would probably not have both a fingerprint reader and an iris scanner installed. However, since both teams have security clearance labels of "Password + Biometric," users in each team would be able to authenticate to the same disk volumes (subject, of course, to user rights restrictions).

NMAS Functionality

From the user's perspective, the minimum NMAS installation is virtually indistinguishable from the standard NetWare client, particularly if they are configured to use one of the password methods.

Clicking on the "Advanced" button on the Novell Login screen reveals a new NMAS tab which gives access to methods defined and installed by the administrator. The user simply clicks on OK and each method will be launched in the order determined by the administrator. If the only method used is Password (see Figure 1), then the user will probably be unaware that NMAS is installed.

The Novell Client login screen with only the password method.

This AppNote does not propose to give a detailed look at each of the auth- entication methods available; a single biometric authentication will be briefly illustrated. For this purpose, I have chosen the Veridicom fingerprint hardware and the SAFlink software.

NMAS Installation and Operation Example

Assuming a standard installation of NMAS at the server and client, with ConsoleOne extensions in place, there are five steps to follow to install, configure, and make use of the Veridicom fingerprint reader:

Install the hardware and the method software.
Create a login sequence.
Assign clearances to resources and users.
Enroll the users.
Use the method.

Install the Hardware and the Method Software. Apart from the simplistic Novell-supplied password methods, all methods require specific software installation and, in some cases, hardware as well. All vendors provide detailed configuration information relevant to their products. In this example, I am using a parallel port-attached Veridicom fingerprint reader.

A number of components are involved for any method under NMAS:

Login Server Module (LSM). This NetWare Loadable Module (NLM), installed on the server, handles the comparison of enrolled and authentication biometrics, interacting with eDirectory to handle storage of the template.
Login Client Module (LCM). This is a DLL file that interacts with the login screen to activate collection of the biometric sample.
ConsoleOne Snap-In. This is the module used to manage the Method Login Secrets for users. In the case of biometrics, the secrets are the biometric identification record and other configuration information.

Individual methods also have customised modules that are applicable to them. In the case of the SAFlink/Veridicom combination, the SAF/NMAS administration suite is installed as a ConsoleOne snap-in, followed by the Veridicom LSM and LCM packages. Finally, the SAFlink Licence Manager is installed to bind the purchased licences to the system. (Note that the NMAS distribution pack includes five free licences to set up an evaluation environment.)

In all cases, the documentation clearly describes the correct installation tasks. The screen capture shown in Figure 2 demonstrates the state of the security container following completion of the Veridicom method.

The Security container after the installation of the Veridicom software.

Create a Login Sequence. Sequences can contain one, two, or three methods- with at most one from each of the three factors. In this example, I will create a dual-method sequence. However, the screen shots clearly show how to add more (or fewer) methods and also how to control the order in which they will be presented to the user.

Most method installation scripts offer you the choice of creating a login sequence containing just that method. It is useful to accept this, if for no other reason than to have an easy way to test the method without other methods interfering.

Figures 3 through 6 illustrate the creation of a login sequence. In Figure 3, I have given the sequence a name ("Veridicom Demo") and have a list of available login methods I can choose from to include in the sequence.

Selecting the login sequence.

There is an option to allow the choice of "one of the methods" to users when they select this sequence; I do not recommend this option. I selected "AND" in the Sequence Type box.

In Figure 4, I have added the NDS method to my sequence. Note that the Sequence Grade is shown as "Password." This is updated automatically.

Selecting the method.

In Figure 5, I have now added the Veridicom method and the grade is shown as "Biometric & Password." Note also that the arrows on the right-hand side are now illuminated.

Selecting the Sequence Grade.

In Figure 6, I have changed the order in which the methods are presented to the user by clicking the down arrow to demote NDS. If the user selects to use this login sequence, he or she will be presented with a request for fingerprint identification, followed by a request for a password.

Selecting the Login Sequence.

Assign Clearances to Resources and Users. Finally, I am ready to apply the authentication structure to actual network resources and also to Directory objects. Be aware that clearances can only be assigned to a NetWare volume in its entirety, not at any subdirectory level. This suggests that you should be very aware of your intended authentication structure when developing the volume layout.

Clearances can be the default set (Biometric + Token, Password, and so on) or they can be created to match the intended usage (such as with the "Takeover Bid Team" example above).

Figure 7 shows the assignment of a clearance to a disk volume.

Assigning a clearance to a disk volume.

Figure 8 demonstrates that users can be assigned a number of different clearances, allowing them to choose the appropriate clearance for their intended activity.

Assigning multiple clearances to users.

Enroll the Users. To use a biometric method, users must first be enrolled. The following screen captures demonstrate the Veridicom enrollment procedure.

Figure 9 shows the main SAF/NMAS management screen. All installed biometrics will be shown here. Note that the first tick-box (HAAPI BSP installed) refers to the presence of the drivers (and, by implication, the biometric device) on the local PC. If this box is not ticked, it indicates that the method is installed in the tree, but not on the PC at which you are sitting.

Enrolling a user for the Veridicom fingerprint device.

Clicking on the Enroll button commences a dialog that leads to the screen shown in Figure 10.

Completing the enrolling procedure.

At this point you can place your finger on the reader and visually determine the quality of the image. When the image looks clear, click Capture. The system will ask for a second finger impression (to allow for the "band-aid effect"), and then complete the enrollment. Once this is done, the "Enrolled" tick-box will be checked on the screen in Figure 9. Typically, you can enroll a user in 30 seconds or less.

Use the Method. I have already shown you the NMAS login screen in its default form, showing the standard NDS password sequence. With other methods installed, a drop-down list provides a choice in the level (grade) of authentication. There is also the option to select the session clearance, although the screen shown in Figure 11 demonstrates the use of login sequence only. In most cases this is sufficient.

Novell Client login screen with Veridicom solution.

This has been a very cursory description of the installation, configuration, and use of one specific implementation of fingerprint recognition under NMAS. There are many more features in NMAS that were not included in this section. I strongly urge you to consult with all Novell and third-party documentation relevant to your proposed implementation.

NMAS Implementation Scenarios

A number of specific industries have a clear need to use NMAS to complete their security architecture. In other situations, the use of NMAS adds a level of convenience to the user experience. This section introduces a few usage scenarios. Hopefully you will see your own circumstances represented here.

Conforming to HIPPA

In 1996, United States federal legislators passed the Health Insurance Portability and Accountability Act (HIPPA) as a means of safeguarding patient privacy and improving the delivery of health services. To quote from the online summary of the act, the three major purposes are:

To protect and enhance the rights of consumers by providing them access to their health information and controlling the inappropriate use of that information;
To improve the quality of health care in the U.S. by restoring trust in the health care system among consumers, health care professionals, and the multitude of organizations and individuals committed to the delivery of care;
To improve the efficiency and effectiveness of health care delivery by creating a national framework for health privacy protection that builds on efforts by states, health systems, and individual organizations and individuals.

(For more information about HIPPA and its requirements, see http://aspe.hhs.gov/admnsimp/final/PvcPre01.htm.)

Around the world, many governments and health authorities are becoming mindful of the general HIPPA framework and are endeavouring to replicate the general thrust of the legislation either via legislation or through the internal practices of health organizations.

Of itself, HIPPA does not mandate biometrics. However, many implementers are rapidly coming to the conclusion that biometrics are the simplest and most elegant method of implementing the levels of authentication and security required by this legislation.

Capital Coast Health (CCH), a major health authority in Wellington, New Zealand, are evaluating NMAS and biometrics to implement NMAS with Single Sign-On (SSO) and DirXML. They have completed phase one of a three-stage trial which, when finally implemented, will see fingerprint readers as the sole authentication method throughout the entire hospital-with one important exception. They propose using iris scanners inside operating theatres, as there is no other workable method of authentication in this environment. This is how importantly they view the need to authenticate all access to patient data.

Over a one-month period, CCH surveyed all users who requested a password change from the help desk to determine the level of password misuse. They found that users admitted to a moderate level of password sharing, to some difficulty in thinking of new passwords and, in some cases, to an amazing inability to recall passwords. About 5% of users reported in excess of six password resets in the previous six months. As the on-site Security Analyst commented, "Doctors can remember the name of every single nerve in the human body, but simply cannot recall a simple password!"

A local software house is developing a data tracking and control system for hospitals where every event is biometrically authenticated. Consider the following scenario: The pathology lab completes an analysis and logs the results in the online patient database. A fingerprint confirms the data entry. At the relevant nurse's station, an alert arrives; the only person able to read the data is the authorized doctor or nurse. This person must use a fingerprint to open the patient's file. An appropriate response (perhaps a course of treatment) is then entered and authorized biometrically. Finally, a nurse or doctor, at the bedside, actions the treatment and logs the completion (again biometrically).

While this example is perhaps a little more rigourous than what would happen in reality, in general it makes some sense. The system will offer three important advantages. First is a high level of patient confidentiality; no one can browse data without a good reason. Second is a strong level of auditability; one can see exactly what was done and when, right down to knowing exactly when and by whom data was seen. Finally, it provies strong non-repudiation. A person cannot easily deny an action when it was authenticated with a biometric and recorded in the audit log.

Graded Authentication Scenario

NMAS offers one key advantage that is unique in the range of available authentication structures for PC and LAN-based environments: the concept of graded authentication. Graded authentication is the ability to offer multiple levels (or grades) of authentication to individual users. It is of value when users have, from a security and authentication perspective, a number of distinctly different roles within an organization. While I am not able to discuss specific sites, here is a fictitious but representative scenario to consider.

The Novell Insurance Company (NIC) has a small, flexible workforce in which people often share roles and positions as the demands on the company vary. They are a very aspirational company and are frequently involved in highly sensitive corporate negotiations on a number of fronts. Users can be found at one moment working back-office tasks, and in another accepting payments at the front office. Other users (perhaps senior management) may be embroiled in planning another corporate raid today, and tomorrow be working on more mundane internal reporting.

In these situations (and many more), there is a perceived demand to match the level of authentication with the importance or confidentiality of the task. Some sites choose to have a variety of usernames to match the specific task being performed by the user: for example, DavidSecure and DavidStd. However, this always leads to the usual problem-forgotten passwords. And I'll guarantee that users will forget the secure ones more often!

Accordingly, NIC implements NMAS on their Netware 5.1 LAN. Being generally conscious of security, they implement strong password authentication for all users. Additionally, most users are configured to use token authentication with an NMAS sequence (Token + Password) defined for the purpose. Those users with the greatest need for secure authentication are provided with fingerprint readers, and two login sequences are developed: Fingerprint + Password and Fingerprint + Token. Optionally, a three-factor sequence could also be used. By setting up the appropriate permissions and NMAS labels on the data volumes, tight access to specific applications and data resources can be defined.

From the users' perspective, they will be presented with the standard NMAS login screen. At this point, they must decide what task they need to perform and choose a login sequence that matches the required security for that task. The necessary credentials (password, fingerprint, token, or some combination) will be collected and evaluated before access is permitted.

At this point, the user has read-write access to those parts of the file system that match the access permissions, and read-only access to those parts which require a subset of the authentication offered. Any volumes that require one or more factors not offered by the user will not be accessible. Note that all these access rights restrictions are in addition to file and folder permissions enacted for the file system. In other words, users need to be granted access rights before those rights can be modified (possibly reduced) by the NMAS security system. As long as the sequence labels are properly defined to match the intended security, NIC will have a seamless graded authentication infrastructure.

Improving Productivity in an Education Setting

The City of Stockholm is responsible for all primary and secondary education in the region, using NetWare as its primary LAN environment. All students from ages 5 to 17 are expected to authenticate to the LAN whenever using computer- based education systems.

To ensure proper identification of students and, in the case of older children, to prevent plagiarism, all accounts are guarded by a password. But therein lies the problem. Students are typically able to remember their user name (a combination of their class name and their own name), but the younger students (ages 5 - 8) generally cannot recall their passwords. This can lead to the loss of 10 to 30% of the lesson time while the teacher identifies which students are unable to login and resets their passwords. Additionally, students are frequently seen sharing usernames and passwords, making clear identification of the perpetrators of Internet abuse difficult.

Biometrics and NMAS have been introduced to attempt to alleviate this problem. Currently, the system is in trial at a school in Kvarnbyskolan, Rinkeby, where 450 students and teachers have been using it since February 2001. This trial is intended to evaluate both a reduction in administrative costs and a concomitant increase in perceived security. As part of the trial, a variety of biometric devices were evaluated. A decision to focus on fingerprint readers was quickly made, finding that face and voice methods were impractical in the intended usage.

Currently, the trial is evaluating five different fingerprint devices, finding that some are not well adapted to detecting the small fingers of the younger students, generally indicating that they are not reading sufficient finger surface to make a suitable enrollment. By the time this AppNote goes to press, a decision will have been made to standardise on a single fingerprint reader, with the trial moving into a second, wider phase using just that device.

The education division of the City of Stockholm have a clear need to replace passwords when a teacher may lose the first 15 minutes of a lesson in network administration. Also, where abuse of Internet privileges is discovered, punishment of the guilty parties is difficult as password sharing is rife. The implementation of NMAS with biometrics clearly addresses both of these concerns.

This education application is also being used as a trial to evaluate the use of biometrics throughout the City of Stockholm's network environment. One department particularly interested is involved with older citizens, who also have difficulty recalling passwords. The primary stakeholders from the education trial intend assisting other City of Stockholm departments who want to take up this technology.

The Big Picture: NMAS + SSO + DirXML

One of the greatest nirvanas in a multi-application and multi-platform environment is Single Sign-On (SSO). The ability to authenticate just once and be properly recognized wherever one navigates in the corporate computer environment dramatically simplifies the authentication support environment.

Too often, users are required to remember a large variety of passwords, generated under differing sets of construction rules, with differing aging criteria. This leads to just one thing: more work for the help desk! With SSO, users don't have to remember separate passwords for the corporate mainframe, the accounting system, and a whole slew of authentication-protected environments. SSO dramatically simplifies the user experience.

A typical SSO environment (Novell's is no exception) permits users to maintain a secure repository of usernames and passwords for a variety of applications, all accessed automatically and triggered by the PC presenting the user with the individual login screen for a particular application. The SSO resident manager completes the fields and the authentication is completed without user intervention. All the user needs to do is log in to the network; eDirectory takes care of the rest.

For all its advantages, there is one serious flaw in the SSO scenario. What you do, by enabling SSO in this manner, is seriously weaken your security model. Whereas originally a user needed to annunciate a separate (and hopefully different) password for every distinct point of authentication, now only one is required. The first point of authentication is now the only point of authentication, and you haven't improved that first point at all. You always used a password to access eDirectory-that hasn't changed. However, you used to need a separate username and password pair for all the other corporate systems you accessed- that has changed. So if an unauthorized person had your eDirectory password, originally he could only access files and such. But with the SSO implementation, he can access everything you know how to access!

In this scenario, NMAS permits much stronger authentication at the "front door," particularly when you have, in effect, removed the locks from every other door in the building. Additionally, with support for multiple and graded authentication, differing sets of SSO authentication pairs can be assigned to a single user, effectively matching the foreign environments to the level of authentication offered to eDirectory, via NMAS. Now if an intruder wants to access your environment, he must complete the full NMAS-enabled authentication sequence. Better still, it enables the administrator to create "horrible" usernames and passwords for all the access-points that are to be included in the SSO profile without the overhead of supporting them.

At this point, you have a well-protected front door, you have automatic access to all your applications and environments at the user level, and you have strongly hidden account and password sets for all accesses. The final step is to incorporate DirXML. Why DirXML? Because you have no desire whatsoever to separately administer all these systems, especially since you no longer need to maintain the access infrastructure for them. There's no sense in creating the opportunity for mismatches in the information stored in each location.

DirXML is a smart framework of information publishers, information users, and the means to connect the two. It can be configured to translate data from widely disparate systems both in terms of data storage methods and data formatting. For example, an employee's date of birth in the Human Resources system (running on Oracle, for example) might be referred to as DOB and be stored in the format YYYY/MM/DD. However, in the payroll system (perhaps developed in Microsoft Access), it is referred to as BirthDate and recorded in the form Day-Month-Year. Additionally, rules can be created that this value can only be updated in the HR system. In this simplistic scenario, HR is an information publisher with respect to the date of birth, and Payroll is a reader. If a change is made to the BirthDate in payroll, it is "reversed" during the next synchronization with correct data sourced from the HR system.

By combining these three key technologies, you can construct a robust framework for strongly and securely supporting users across multiple authentication environments. This simplifies the experience for users, strengthens the overall security regime, and simplifies support requirements.

Conclusion

Novell's NMAS is the first configurable, hierarchical, and (optionally) non- password authentication system available for Directory authentication. It permits graded authentication based on a set of administrator-defined access rules. Fitting within the NMAS structure, biometrics is a new and highly accurate method of authenticating people, overcoming many of the weaknesses of maintaining a password-only infrastructure.

In conjunction with the NMAS infrastructure and with the non-password methods provided by Novell, a number of third-party organizations have developed biometric authentication systems based on a rich variety of hardware and software solutions. These can offer a "mix and match" opportunity to implement appropriate solutions for various sub-groups of the user population.

The problems with password-only regimes are well known. The more rigorous the construction rules you apply, the more likely passwords are to be written down. The more demanding you make workflow, the more likely it is that everyone knows the passwords of the key players. In conjunction with biometrics, NMAS solves these problems. You don't need to use passwords to ensure all the users are properly authenticated. And you'll almost never have to reset a password again.

With reference to your help desk reporting system, you can easily calculate the cost of passwords in your organization. Most who implement biometrics report a return on investment period of 12 to 18 months. The next move is up to you.

Biometric Performance Terms

There are a number of terms used to describe the measurements of biometric system performance.

Authentication: When we want to login to our system we present an identity (for example a username) and then authenticate that identity by offering the appropriate "secret." This might be a password, a token of some sort or a biometric. Authentication can be described operationally as "I am David, here's my proof." The use of PKI is an implied Authentication, with the public key as an identity and the private key as the "secret." Contrast Authentication with Identification. Authentication is often described as "one to one matching."

Identification: In the case of identification, NO identity is offered in advance. The "secret" is offered on its own, the assumption being that secrets are unique. The operational question is "Here's my secret, who am I?" Identification is often described as "one to many matching."

False Acceptance Rate (FAR): The proportion of times a non-matching biometric is offered and a "match" is announced. This is bad! Compare it with you knowing my password.

False Rejection Rate (FRR): The proportion of times a matching biometric is offered and "no match" is announced. This is annoying, but not ‘bad.' Compare it with me miss-typing or forgetting my password.

Equal Error Rate (EER): In general, biometric systems can be tuned to reduce the FAR, but this is typically at the expense of increasing the FRR. Typically, the two values are loosely in inverse proportion to each other. One can graph the relationship between the two and find that at some point, they are equal -hence the Equal Error Rate. Note that systems are almost never tuned to set FAR = FRR = EER - this would set the FAR way too high! You are generally much more concerned about reducing FAR (stopping the wrong people getting in) than about reducing FRR (protecting people from themselves).

The EER is, however, very useful as a coarse estimate of the relative performance of unrelated biometric systems, e.g. comparing fingerprint with voice recognition, or even comparing Brand ‘X' fingerprint recognition with Brand ‘Y.'

Receiver Operating Curve (ROC): A graph showing how the false rejection rate and false acceptance rate vary according to the threshold. This is the graphical representation of the EER.

Failure to Acquire Rate: This is a reflection on the general robustness of the biometric system. The higher the Failure to Acquire Rate, the less willing users will be to use the system.

Failure to acquire a biometric sample can be caused by a number of factors. There are people who for whatever reason cannot submit a sample (possibly amputation) and others for whom the sample is too immature for valid use (weakly-defined fingerprint for example).

Biometric Taxonomy: A method of classifying biometrics. For example, San Jose State University's (SJSU) biometric taxonomy uses partitions to classify the role of biometrics within a given biometric application. Thus an application may be classified as:

Cooperative vs. Non-Cooperative User (also known as ‘willing' authenticators)
Overt vs. Covert Biometric System
Habituated vs. Non-Habituated User
Supervised vs. Unsupervised User

Factors: Factors are independent methods of authenticating user identity. The three normally described factors are:

Something you know (e.g. a password or PIN)
Something you have (for example an ATM cad, a SecureID tag, a PKI certificate etc)
Something you are (fingerprint, iris etc).

In an authentication session, a user may be requested to provide one or more factors to satisfy a request for credentials. Thus we can refer to one-factor, two-factor or even three-factor authentication methods.

Enrollment: The process of collecting biometric samples from a person and the subsequent preparation and storage of biometric reference templates representing that person's identity.

SHA-1: Secure Hash Algorithm (SHA-1) is a message digest algorithm that produces a 160-bit summary of any source file of up to 264 bytes in length. It is computationally infeasible to find a similar plain-text message that summarizes to the same SHA-1 digest. Refer to http://csrc.nist.gov/publications/fips/fips180-1/fips180-1.pdf for a full description.

MD-5: In the same manner as SHA-1, MD-5 (message digest 5) produces a 128-bit summary of the input file. Note that MD-5 is NOT FIPS compliant and does not appear in the recently released FIPS140-2 standard.

Smart Card: A smart card is a small plastic card (approximately the size of a typical credit card) containing an embedded processor and memory. These cards are capable of performing cryptographic functionality and typically (in the security usage domain) offer a protected memory zone, which is not addressable by external applications where PKI and other secrets may be stored.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.