applications
Biometric Client Framework
Biometrically enabled applications made easy
Business Need
Business applications increasingly make use of biometric verification to authenticate users or clients. Although today access control might be the most widespread use of biometric technologies, this secure and convenient method of authentication is rapidly making its way into your client-facing front-desk operations as well as onto back-office workstations, handling day-to-day business transactions.
Non-repudiation has become a common business need.
In general terms, non-repudiation is the assurance that someone cannot deny something. Typically, non-repudiation refers to the ability to ensure that a party to an agreement or transaction cannot deny the authenticity of their signature or cannot deny having been party to this agreement.
Non-repudiation requires a number of elements to be in place, one of them being a secure and undeniable method of authenticating a person, or in other words, proving beyond a reasonable doubt that a person was present at a transaction and has agreed to it.
Biometric verification can provide for this need, sometimes as the only form of authentication, sometimes combined with other means.
The CIO of a large corporation will be faced with difficult choices, the first of which will be the choice of biometric mode. Biometric mode refers to different technologies, such as fingerprints, facial recognition, iris scanning, or vein patterns.
Once a choice for one (or multiple) modes has been made, you will want to rapidly integrate the biometric technology into your business application, without becoming dependent on any particular technology vendor. This is where technical challenges begin.
The Technical Challenge
Every biometric solution deals with two or three fundamental biometric processes:
- Enrolment
- Verification
- Identification
Enrolment refers to the process where we collect the biometric features of a person of interest, which may be a client, a supplier, or it may be an employee. From a business perspective, it is critical that we make sure that we enrol the correct person, as from this moment on, we will trust the enrolled information to authenticate this person over and over again.
Technically, it is critical that we perform the enrolment securely and with the best possible quality, so that future verifications have a good chance of accepting the right person and rejecting the wrong person. Failures to do so are called the False Acceptance Ratio (FAR) and False Rejection Ration (FRR), both of which must be kept low.
Verification is the process where we make use of an enrolled biometric information, and confirm that the person is how he or she claims to be. We compare a newly taken biometric sample to the enrolled one, and if we can confirm a match, we accept the authenticity of the person – in isolation or in combination with other means of identification. Technically, we also refer to verification as a 1-or-1 comparison.
The third biometric process is identification, and is only utilised by few users of biometric technology. Identification, or 1-or-many searches, tries to identify a person in a database of many enrolled persons. On a small scale, this can mean that your access control system searches through a database of 200 employees, and opens the door if a match against any employee is found.
On a large scale, this means searching through a national database of all citizens, ensuring that a person can only apply for an ID card or passport once. The South African Government makes use of large-scale identification for both civic purposes at Home Affairs, as well as criminal purposes at SAPS. Systems that are able to perform large-scale identification are specialised and not commonly used.
In order to implement enrolment, verification, or even identification, your business application needs to handle three fundamental integration points:
- Capture a biometric sample from the sensor.
- Feature extraction and comparison by the engine.
- Storage and retrieval of samples and features – to and from the store.
Capturing a biometric sample invariably means accessing biometric sensors (fingerprint readers, cameras) in your application. Unfortunately, no common device driver interface exists in Windows, as it does e.g. for printers. Although Microsoft has introduced the Windows Biometric Framework (WBF) in Windows 7, WBF is not aimed at aiding biometrically enabled business applications.
Feature extraction and comparison deal with integrating a third-party engine SDK and understanding biometric jargon. Although most SDKs only require 10-20 API calls, and are relatively simple to integrate, they are all different, and by directly integrating with the SDK of one particular supplier, you might be creating dependencies which are hard to undo.
Biometric features are often stored in proprietary formats, which, if not dealt with a profound understanding of biometric complexities, can deepen the dependency on a vendor. An increasing number of biometric engine vendors also support standard biometric formats, which, however, often are plagued by reduced verification accuracy. An aggravating fact is that vendors of biometric sensors offer their engine free of charge, which, of course, can save money in the short term, but once you have collected millions of enrollments, you are unable to change either the sensor or the engine, and this need will arise, sooner or later.
Storage and retrieval of biometric data could, of course be handled by the existing database of your business application. In this case you would create tight coupling between biometric capability and business data, which might not be desirable in all cases. And also, your developers would have to build a deep understanding of the intricacies of non-repudiable secure storage of biometric data, where there is an encrypted chain of evidence how the enrolment was performed – ensuring that it has not been tempered with, and you can proof in court that you have enrolled the right person. Emerging data privacy issues further complicate matters.
As a result, you might in many cases decide to use an off-the-shelf biometric store, which encapsulates these complexities and allows your business analysts, architects, and developers to focus on your business processes.
Alcazar Biometric Client Framework
Alcazar has responded to this technical challenge by creating the biometric client framework.
The framework is aimed at abstracting the complexities of biometric modes, biometric operations, devices, SDKs, and stores from the integrator, and provides a simple, easy to understand interface, without the need of understanding biometric standards and proprietary formats.
Biometrically enabling an application is comprised of a few, simple steps:
- Configure the framework to be aware of available biometric modes, sensors, engines, and stores.
- Use one of the WPF or Windows Forms controls to capture a biometric sample, typically with visual feedback to help the operator capture good-quality samples.
- Call the framework to enrol or verify the captured sample. All complexities of performing quality checks, extracting the correct feature, performing conversions and comparisons, or even handling fingerprints and facial recognition simultaneously are handled behind the scenes.
The BioClient framework is implemented as .Net libraries using the .Net Framework 3.5 – and can therefore be integrated with older business applications, which have not yet migrated to newer Microsoft technologies.
Release 2 of the framework has been implemented by large financial institutions, who have been users of biometric technology for many years. They are realising the benefit of one single integration point, allowing them to manage device and engine changes as may be required.
BioClient Features
- High-level .Net interface, supporting idioms like Capture, Enrol, Verify, or Identify. This allows the integrator focus on the business use of biometric capability, and not its internal intricacies.
- Ready-made WPF and Windows Forms UI. The integrator has a choice of using the high-level biometric idioms, or make use of one of the WPF or Forms controls, which encapsulate commonly required UI features, such as device-independent visual feedback, finger placement guides, and on-the-fly quality check.
- Universal adaptor architecture for sensors, engines, and stores. The integrator can configure which biometric devices, cameras, biometric SDKs, and storage locations are available and which should be used for which biometric mode. All common biometric devices and engines are supported.
- The configuration can be held in a configuration file or in a central database, allowing for easy management and maintenance.
- Support for simultaneous multi modal biometric operations. The framework can capture both fingerprints and a facial image and arrive at a combined match score.
- Support for local and centralised biometric operation. Depending on circumstances like frequency of verifications with a business transaction, network bandwidth, response time and security requirements, the integrator may choose to perform local verification (where the enrolment is first retrieved and held locally, and then verified multiple times during a transaction) or remote verification (where the remote biometric store performs the verification, without exposing enrolled data to the network.
- Support for local caching. In order to facilitate local verification, the framework allows local caching of biometric data, both in a persistent manner as well as temporary in memory.
- Available as .Net assemblies, from .Net framework 3.5 upwards
- Available for x86 and x64 architectures
Bioclient is part of our biometric solution suite. Explore our biometric solutions.