Biometric Encryption

Well, so we have been talking about biometrics for a while, and eventually the concept of biometric encryption (fuzzy commitment schemes, secure sketching, biometric key binding, bioHashing, biometric signatures, etc. [it goes by many names]) was going to come up. To be honest the subject is actually relatively fascinating. I have just started researching it, so I figured I would share my findings about it. Maybe I will make up my own term like Super Adam Bio Hashing. That sounds sexy (said for the MVP group, who knows all about my desire to make every SharePoint feature as sexy as possible). Anyways, this is just going to be a general overview to introduce the concept, and give readers a better idea about the aggregate field.
Like some other things that come up on this blog, it really isn’t going to have a large relevance to SharePoint discussions, but either way it is interesting. I will look into maybe expanding this into the CryptoCollaboration concept sometime (which I am going to update in the next post with the programmatic sequence diagrams and a general architectural overview), but it is currently beyond my skill set honestly until I actually find some good research that describes the mathematics behind BE. I haven’t been able to pinpoint this type of material yet.

As stated, we already have a pretty good idea about the overall concept of biometrics, that it is measuring quantifiable objects about a principal, being either physical or behavioral parameters.  We know that biometrics generally runs on fundamental comparison operations, where the template (biometric blueprint) sample is taken from the principal and then this blueprint is employed for the actual identification and verification of the principal. This template is often referred to as the biometric template (which is why you see the fingerprintTemplateParams Property in the BioPoint API documentation) or a biometric principal blueprint. People often refer to the person that the sample (for template generation) is taken from as the enrollee of the template (since a lot of people consider a biometric system to be a publish / subscribe architecture), but I prefer to refer to the template person as the principal, so let’s refer to the user as the principal for the remainder of this post.

So, let’s talk a little bit about encryption, and we will then get into Biometric Encryption. We know a few things about encryption. We know that one of the more common cryptographic schemes that we see in general business applications consist of using a public and private key.

The concept of biometric encryption was originally coined by Dr. George Tomko, who really started to put the concept to work when leveraging fingerprinting biometrics. Although there a have been several grants in the past couple years that have allowed this area of research to expand, and some brief searching provides several smaller research firms that are integrating biometric encryption into their research schemes, it is IMHO still somewhat untapped. I think that it will be an explosive field once the true business value of it is taped though.

However, I digress….

So what the hell could we use biometrics for in the terms of encryption? We know the encryption is dependent on various types of strings, so how could we use biometrics as a string representation parameter and subject? That is an excellent question. The answer to the overall question to this is just a simple plain no, at first glance it is not feasible to use biometrics in the straightforward method that orthodox encryption routines function. A biometric sample is not representative of a string, it is an object, and therefore won’t work well within a typical encryption schemes.

Where BE becomes possible is when you slightly extend this concept into a more abstract sense. Although a template is going to be composed of a large bit representation, and it would be possible to extract a string from this representation, that is, IMHO, a poor approach. Furthermore, acquiring consistently exact biometric samples is never really possible because managing the distortion rates between the samples would become improbable, regardless of noisy compensators are factored into the software.  Cryptography is a rather exact science, and with that in mind, noise disturbances within the empirical data would not be acceptable and the related algorithms required for descrambling would fail.

It is also possible to use traditional cryptography against the stored biometrics blueprints in whatever medium that they are subject to depending on organization data storage standards. This would be a fairly customary situation, and not much different than traditional forms of cryptographic situations. The problem with this is there is still a point where someone, be it a server / database administrator, that would have access to the source template. Because the templates would have a period in which they are exposed to some user, there is a possibility for a breach. This is large concern with biometric data because the user would have access to some of the most sensitive information available regarding a user that could be used in order to possibly fabricate future biometric templates.

So, we have explored two options that are not very desirable, now let’s actually get to the point where BE shows us an actual favorable circumstance. If you want to view some more of the circumstances that arise from the use of biometrics and cryptography, A Study on PKI and Biometrics by FIDIS is pretty interesting and a lot more in-depth.

Rather, it is possible to instead unite an encryption key with a biometric template. This would, in essence, result in both the key, as well as the biometric template, becoming inaccessible and sheltered.

A cryptographic key is generated from a set of user input, usually something like a passphrase that can be remembered. For example, I could use the string sharepointsecurity in order to generate a cryptographic key, and because it is the name of my site, it is easy for me to remember. That cryptographic key can then be used in order to generate the encrypted string back into plain text. As opposed to taking this approach, we can graft the unique biometric parameters regarding a principal empirically, identically how it is done for normal template verification. Once the empirical data is harvested from the principal, it is united within the cryptographic key. In order to regenerate the cryptographic key, the correct sample must be provided to the system. As opposed to providing a passphrase which generates the cryptographic key, the key is generated when the principal first generates the template. It does not use the biometric template as a parameter for the key generation, and therefore the two units although united are not tangibly related. Because of this segregation between the biometric template and the key, they key can therefore be built, rebuilt, and destroyed regardless of the biometric sample.

This is neat, and results in the key protected by the biometric template. Sometimes people refer to this template as a private template or protected template. While the key is united with the biometric template, in its segregated state, as opposed to the key being used in order to encrypt a string representation, the biometric is used to encrypt the key. Quite an adjustment, and somewhat confusing at first, however really quite clever. This type of functionality has to be written by the user, as the algorithm doesn’t adhere to normal cryptographic criteria, so can branch in a variety of fashions.

Now, the concept of the two layers of keys is still consistent, there is a scrambling and descrambling process otherwise the cryptographic process being presented wouldn’t be an exceptionally impressive because it would only half way work.

When the actual process occurs, the principal will approach a biometric device in order to provide a sample. This template will be used in order to breach the biometric encrypted template, and the custom written algorithm will be used in order to present the sample. This algorithm will be architected so the presentation will captured and will be used in order to decrypt the key. This is pretty neat, because as opposed to any keys being used in order to the complete the cyclic encryption routines, the biometric template is used for the decryption, it’s kind of backswords however interesting.

There are some problems that have to be cleverly approach in regards to the biometric sample. When using biometric encryption, you are going to be querying against principal samples that tend to contain various amount of distortions. This type of variation has to be compensated for with custom code, and can be a pain in the ass without some sort of SDK provided with the biometric device in order to code compensate for the variations. In other posts I have talked about fuzzy logic, and the same thing is true with this, because there is a rather grey area that must be compensated for with the template comparison algorithm.

Once the key is extracted using this process, the actual application process can concurrently occur, which can be used for cryptographic key generation.

In any respect, this is just an overview of what BE is, and I am tired of writing about it. There a lot of other sources that will discuss it more in-depth if you really want to learn more about it.