Matching Location

Matching can be done in one of four locations. The location where the templating occurs can be independent of where the matching takes place. The next sections will discuss where templating could take place for use with each of the following matching locations:

1. Trusted device

2. Local host

3. Authentication server

4. MOC (smart card)

Local Host

The local host is the interaction point of the biometric system with the software requesting biometric authentication. If a trusted device is used, then there is a secure link between the device and the local host. Also, as described earlier, it is ideal if both the local host and the trusted device have authenticated each other through the use of certificates. This assures the software running on the local system that the match/no match response from the trusted device is valid.

If the local host is not interacting with a trusted device, then the local host will need to exhibit one of two behaviors. If the local host is not doing the matching, then it must act as a secure conduit for the biometric information to reach an authentication server. If this is the case, then the local host may do the templating of the raw biometric data. This may involve the local host decrypting the raw data from the reader, templating the data, and re-encrypting the data for transmission and eventually comparison at the authentication server. This would mean that while templating is taking place, the raw biometric data and the template itself are exposed to possible interception and attack. To reduce the risk of the raw data or template being compromised, the templating could take place at the authentication server. If the templating does take place at the authentication server, this adds another level of activity for the server. If the server is intended to do high-volume matching, the templating of individual user data will only slow it down. Thus, templating often takes place on the local host. If templating must occur on the local host, then the following precautions should be taken:

• The templating and encrypt/decrypt operation should take place in a secure area of memory.

• All temporary buffers and variables should be cleared after use.

• The data should never be written to disk.

• The local workstation should be up-to-date with the latest operating system service packs and security patches.

• Anti-virus software should be run to prevent malicious code from being introduced on the system.

• The matching software should validate that its components have not been switched, or that its underlying resources have not been tampered with.

• If possible and supported by the host operating system, the matching should be done through statically linked applications. This prevents dependencies on underlying system components that could be compromised.

Even with the above precautions taken, there will always be some risk that the transaction will be compromised. The main reason for this is that most host systems are running untrusted operating systems. The local host is often the primary computing platform for the user, and as such, is constantly being updated with new software. This means that we cannot implicitly trust these platforms.

Matching on the local host is the last choice for matching a biometric template. In order of preference, is most secure, followed by a trusted device, a MOC, a match on the server, and finally, a match on the local host.

Authentication Server

The authentication server is generally a single-purpose server. It is used to verify the reference template to the stored template. In doing so, it provides services with biometrics similar to those network login servers provide for passwords. Thus, the authentication server needs to be protected in the same manner as a network login server. These servers are generally used in a secure room or facility with controlled access to the console. Secure access to the machine and the console is necessary in order to safeguard the integrity of the server. It is well-known that if an attacker can reach the server physically, it can in general be compromised. In addition to keeping the server physically secure, the same precautions that were taken for local host authentication are also applicable .

If the authentication server will also template the raw data, then the authentication device and the server should authenticate to each other with certificates. This way, the device knows that its raw data will arrive at the trusted authentication server, and the authentication server knows that it is talking directly to a device and not to a replay of a previous transaction. In addition, the local host now acts as a conduit for data. As such, the local host should not touch the transmitted data other than to assist in its forwarding to the authentication server.

If the local host will template the data, then the authentication server must secure the transactional link and support encryption of the data. The same methodologies that were outlined in the electronic hardening of a trusted device are also useful in securing the communications between the server and local host, or the device itself.

The authentication server needs to authenticate itself with the local host so that it can transmit the outcome of biometric data matching in a secure manner.

Matching on the server is preferred over local host matching. It is still more preferable to have a trusted device. If a trusted device is cost-prohibitive, then having a properly secured server is a powerful second option.

Match on Card (MOC)

As the name implies, biometric matching can take place on a smart card. While this appears to be an ideal solution, the implementation of the solution is very important. When considering MOC, the following questions need to be answered :

• Where does the template get created?

• What communication methods are used between the biometric device and smart card?

• How is the algorithm implemented on the card?

Where is the template created?

When the templating is done on the local host, this opens the transaction up to attack. If by using a MOC solution the actual templating takes place on the local host, then this is no better a solution than matching on the local host. Once the template is exposed to the PC bus, even with the precautions discussed in local host templating, an element of uncertainty has now been introduced into the transaction. MOC solutions may template on the local machine due to a lack of speed or system resources on the smart card. For an ideal solution, the card itself would do the biometric templating.

What communication methods are used between the biometric device and the smart card?

Regardless of where the template is created from the raw data, either the raw data or an externally created template needs to reach the smart card. This communication path needs to be as secure as possible. If this path involves exposure to the PC bus, then once again, an element of uncertainty is introduced into the transaction. If, on the other hand, the biometric data moves internally in the device, never leaves the device, and travels across secure buses, then this is a strong matching solution from a security standpoint.

How is the algorithm implemented on the card?

Many vendors , when trying to implement a MOC solution, take shortcuts with their algorithm to get acceptable performance from the matching. Any change to the algorithm invalidates the current biometric statistics. Therefore, it is important to have a vendor clearly state what its biometric statistics are for MOC.

Getting the performance increases that MOC providers are looking for can involve templating taking place elsewhere. When templating takes place off the card, the template can be compromised. Thus, a certain degree of uncertainty is introduced into the transaction. Another method of increasing performance is to have some binning and pre-comparison work for the match take place on a faster processor. This normally involves using the local host. As seen before, the same issues with using a matching location can affect this plan.

A vendor may also adjust its measurements of any algorithm's strength. When matching takes place in application software, algorithm strength may be greater. For example, the vendor may have biometric security levels of high, medium, and low for matching in application software. The vendor could say that the MOC has a high, medium, and low level of biometric security. Since the same vendor is claiming the same security levels regardless of where the matching takes place, the user might assume that the security settings are equivalent. As we have seen, this may not be the case, depending on whether the same algorithm is implemented in both locations in the same way.

Final thoughts on matching location

As in every other business decision that needs to be made, risk is a large deciding factor. If the risk of a compromised transaction is sufficiently strong, then the use of a trusted device is warranted. For most transactions and applications, the use of an authentication server will meet the users' needs appropriately. For much lower risk transactions, or if using biometrics purely for convenience, local host matching may be sufficient.