About Our Portfolio

Fingerprint Image Enhancement:

A critical step in automatic fingerprint matching is to automatically and reliably extract minutiae from the input fingerprint images. However, the performance of a minutiae extraction algorithm relies heavily on the quality of the input fingerprint images. In order to ensure that the performance of an automatic fingerprint identification/verification system will be robust with respect to the quality of the fingerprint images, it is essential to incorporate a fingerprint enhancement algorithm in the minutiae extraction module. We have developed a fast fingerprint enhancement algorithm, which can adaptively improve the clarity of ridge and furrow structures of input fingerprint images based on the estimated local ridge orientation and frequency. We have evaluated the performance of the image enhancement algorithm using the goodness index of the extracted minutiae and the accuracy of an online fingerprint verification system. Experimental results show that incorporating the enhancement algorithms improves both the goodness index and the verification accuracy.

A Focus on FingerPrints with a Portfolio of Other Biometrics

Biometrics and PKI

 What is PKI?

PKI stands for Public Key Infrastructure and refers to the infrastructure and procedures required to facilitate the management, distribution, storage and revocation of certificates based upon public key cryptography. This in turn seeks to provide secure data exchange over third party networks such as the Internet.

A PKI effectively provides a tool set with which organisations or private individuals can implement a level of data transmission security appropriate to their needs. In some cases this may be signing a message or document with a digital signature in order to verify it's source, whilst in other cases it may mean total encryption of the message as well as digital signing. In addition to the desired privacy of information, a PKI seeks to provide:

Integrity - to verify that a message or document is genuine and has not been manipulated or changed since it's original creation and signing.

Authentication - to verify the identity of the individual or organisation sending the message.

Non repudiation - to ensure that the originator of the message or transaction can not subsequently disown it. 

Why do we need it?

The Internet is a powerful enabler for all manner of communication and electronic transactions. However, the topology of the net is such that it is effectively spread across a huge number of servers, routers and geographic locations and cannot therefore be regarded as a trusted network. A typical electronic message or transaction may be passed between a number of servers and routing devices before reaching it's final destination, each step representing a potential opportunity for interception.

In addition, for many transactions undertaken over the net, the users involved neither see, hear or even know each other, leaving little scope for reaching intelligent conclusions as to the integrity of the received message, or the authenticity of the identity of the originator.

We therefore need a methodology to ensure authenticity and integrity of messages and transactions transported via the Internet, or indeed, any such untrusted network outside the immediate control of the user. PKI offers such a methodology, which can be used in a variety of scenarios, but is especially pertinent to the Internet. 

Cryptography

The concept of cryptography has been around for a very long time, although these days we tend to think of it in terms of a cipher to automatically change the protected information into an unrecognisable format until it reaches the authorised recipient who can decrypt the message using the appropriate deciphering methodology. In simple terms, we can think of the cipher as a means of substituting a block of text with another according to a predefined set of rules. The cipher is used in conjunction with a key to encrypt the message and a key to decrypt the message. Symmetric ciphers use the same key to encrypt and decrypt the message, whilst asymmetric ciphers use different keys for encryption and decryption. Popular symmetric ciphers include DES, RC2 and RC4. Popular asymmetric ciphers include RSA, DSA and Diffie-Hellman. Symmetric ciphers generally perform much faster in typical operation, although asymmetric ciphers have a significant advantage with regard to the distribution and management of keys. 

Public / Private Keys

With an asymmetric cipher model, because we are using separate keys for encryption and decryption, we have the opportunity to make one of the keys public without compromising security. This means that you can send or publish the 'public' key to a broad audience, enabling them to encrypt messages that they wish to send to you. You can then decrypt these messages using your 'private' decryption key. Providing you keep this key safe, you can be assured that only you can read messages that have been encrypted with your public key. Similarly, you can acquire the public key for another individual or organisation and use this to encrypt the messages you send to them, in order that only they may decrypt and read such messages. 

Certificates

A certificate is the digital document published by the Certificate Authority in order to make public keys accessible. The certificate contains the public key itself, information about the public key owner, information about the issuer of the certificate and the issuing authority's digital signature to ensure authenticity.

In order to create a certificate for yourself or your organisation, you need to make a certificate request, usually via a Registration Authority which acts as an intermediary between yourself and the Certificate Authority. There are two primary types of certificate request, known as PKCS#10 and RFC2511, with PKCS#10 perhaps being the most popular. The PKCS#10 certificate request typically consists of a version number, the certificate owners name (as in 'Distinguished Name' or Dname), the certificate owners public key and other attributes that the owner may wish to publish such as e-mail address, telephone number and so on. The Dname is an ordered set of owner attributes which includes the applicable two letter country code, the state or province, the locality or street, the organisation name, the organisation department, and the individual owners name.

When the Certificate Authority receives the request, it will check the authenticity and if satisfied, will sign and publish the certificate accordingly. The owner may wish to generate their own key pair and submit the public key to the Certificate Authority for inclusion in the certificate, thus keeping the private key totally in house. Alternatively, the Certificate Authority may generate the key pair and send the private key back to the certificate owner when the certificate is created and published.

Of course, it is possible for an individual or organisation to generate keys and send the public key directly to trusted parties without formally going through the certification process. However, managing the ongoing situation could become extremely complicated, especially if the private key was compromised in any way. A trusted Certificate Authority thus provides a useful management function for those wishing to utilise a PKI. Part of this management includes maintaining the validity of public keys via regular updates and also maintaining a 'revocation' database for keys which have been revoked for one reason or another. 

Digital Signatures

Encryption may provide us with increased confidence that our message will not be seen by unauthorised third parties as it travels the net. However, there are still issues around authenticity, both of the contents of the message and of the sender. If you receive a message with a header which says it is from Charlie Brown, how do you know that Charlie Brown really sent the message? Similarly, how do you know that the contents of the message have not been tampered with in some way? Digital signatures seek to provide an answer by allowing the message originator to digitally 'sign' the message before sending it to the recipient. To do this, the sender uses his private key in association with a hash function in order to create a unique identifier for the message (the text of which may or may not be encrypted). The hash function creates a specific output stream for a given block of text. Such a text block will always hash to the same value, but different text blocks will produce different hash outputs. Thus, if anything changes within the text block between original transmission and final reception, then applying the hash function to the received message will produce a different output which can subsequently be compared with the original. If the two hash outputs do not match, then we know that the message has been corrupted somewhere along the line. 

The originator of the message creates a hash from the document, encrypts the hash with his private key in order to create the digital signature and then sends both the message and the signature to the recipient. The recipient creates a hash from the message, decrypts the signature to recreate the original hash and then compares the two hash values. In practice, good quality available software streamlines this process for the user.

The benefits are twofold. Firstly, the recipient can have confidence that the received message has not been tampered with or altered in any way, because the two hash values match. Secondly, the recipient can have confidence as to the true identity of the sender, because he used the sender's public key to decrypt the digital signature. If we utilise message encryption and digital signatures within a PKI environment, our confidence in data exchange over untrusted networks is increased considerably. 

What are the weaknesses of PKI?

OK, if PKI is so great, why hasn't it quickly become the norm for all data traffic over the Internet and other uses such as data storage on workstations and networks? Well, firstly, we should acknowledge that not everyone needs or desires this increased level of security. Many people are happy enough with the default levels of security provided by ISP's and common web browsers and e-mail clients, although there does seem to be a growing mistrust even in this area. For commercial and legal transactions however, there is a real need for increased confidence around electronic data exchange via untrusted networks. In this context, PKI is particularly interesting.

One of the often repeated concerns lies in the area of key management, and in particular, the likelihood of your private key being misused or perhaps stolen. For example, if the operation of your private key is protected by a PIN, then this may easily be compromised at your workstation by someone who wishes to pretend to be you and makes it his or her business to discover that PIN. Similarly, if the private key is stored on your computer's hard disk, then how easy is it for someone to hack into your computer and copy this file? If someone acquires and is able to use your private key, then your PKI environment is powerless to protect you as this person could intercept messages meant for you and easily decrypt them. Furthermore they could pretend to be you within the context of important transactions, with all the implications that this entails. Key management and key security therefore become paramount within a PKI environment. 

The Relevance of Biometrics

Biometrics offer the potential to considerably enhance the PKI model in the same way that they have brought significant benefits to the more conventional user authentication area. Let's take for example the ability to restrict the use of your private key for encryption and decryption. Using a PIN for this provides a certain level of perceived security, although the actual level is rather low. Using a biometric, such as a fingerprint for example, provides a substantially higher level of confidence. The likelihood of someone else using your workstation or mobile computer and successfully using your biometrically protected private key is reduced to almost infinitesimal proportions. In a similar manner, you might link a biometric to local or network file encryption in order to ensure that only the person who encrypted the file will be able to decrypt and read it. Merging these two related technologies promises some exciting possibilities in the area of secure data exchange and general encryption.

Let's bring in another old friend, the chip card or smart card as it is sometimes known. If we undertake key management functionality right on the card itself and maintain the private key in the secure area of the chip, then we can use the private key straight from here, removing the problems associated with storing the private key on the hard disk. The user now has absolute control over the key and can carry it around with him or keep it secure, just as he would with a physical key. If we now protect access to this private key via a biometric, we have created a considerably higher confidence level as to the true identity of the originator and digital signatory of a specific PKI message. In addition, we have dramatically reduced the possibility that the private key could be fraudulently acquired by a third party as we are physically securing it away from a hard disk or network drive. 

Moving Forward

The integration of biometrics, chip cards and PKI technology offer the potential for high confidence data exchange over non trusted networks in applications where security is paramount. There are of course several variations on exactly how such a model would, or should be implemented and we should consider each application on its merits.

We should also consider the user position in this context. Some people may be wary of having the biometric template on the chip card for fear of identity theft should the chip card be lost or stolen. Others are wary of using biometrics with a PKI because of the enhanced non repudiation that this offers, feeling that their anonymity is compromised and that third parties such as law enforcement agencies might use this against them. For every distinct view on the subject, it is likely that you will find an equally distinct opposing one. Clearly a solution which seems ideal for one group will not necessarily be acceptable to another and we should be cognisant of this reality. Perhaps the answer lies in developing the technological infrastructure that allows for all levels to be accommodated, and then letting the user choose to what degree they wish to use the functionality. For example, a particular solution may integrate biometrics, chip cards and PKI, but allow the user to choose whether they use a biometric or a PIN, how and where the biometric template is stored and other variables. This would then place the choice, and the responsibility for that choice with the user or user organisation. If adopting a higher level of security unlocks enhanced functionality, or otherwise, as the case may be, then why not allow the user to choose accordingly? This is perhaps a thorny question, especially when we move into the territory of public applications, but these are the sort of questions we need to ask as the relevant technology continues to move forward. From a technical solution perspective, the integration of biometric and PKI models offers the potential for substantially enhanced confidence in data exchange over untrusted networks, especially in the areas of digital signing and non repudiation. Historically, the two camps have not always seen eye to eye on the subject, but maybe it is time to move closer together and understand the potential advantages and how these might be offered to user communities. 

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.