I was talking to Stacy Draper (a MOSS MVP, his blog is here) and we were discussing the BioPoint SDK (I just released it a like two days ago), and Stacy seemed bent on proving to me that biometrics can be circumvented. He had some wild ideas, but I think that he was just trying to get under my skin. Well, he inspired this post, so I guess he was successful in that particular endeavor.So Mr. Stacy Draper, this is for youâ€¦
Although biometrics, IMHO, is easily the most secure way for identification and verification (at a basic level, this is obviously not going to take into consideration large architectural consideration like an identity metasystem) of a relevant principal object to a declared resource, it is factual that under extraordinary circumstances there are vulnerabilities that exist in biometric systems. I am not talking about the typical things that you see in the movies, but some more pragmatic matters, even though everything introduced here is going to be pretty plain and straightforward stuff. We aren’t going to look at any of the mathematics behind it, or any of the actual coding for some of these that would be required, but, I hope to introduce some of the fundamental points on this subject to give the audience a better idea.
So, let’s talk about some of these and get it out of our system.
The first type of attack is fairly feasible is a spoofing attack. Although I don’t really even consider this very viable with the advances in the relevant biometric sensor, it does deserve mention in order to include it to be through. This really isn’t dissimilar than the spoofing as we are all familiar with hearing about (or using). It is where you are doing something like applying false fingerprints to a fingerprint sensor within the biometric hardware.
Along the same lines, this leads to another problem; suits not spending the appropriate amount of dollars on the right biometric devices. Although buying cheap devices seems like a good idea when exploring biometric devices at first because they can range to somewhat exorbitant in cost, it really is a poor idea because it will lead to a high False Rejection Rate (FRR) [also known as False Non-Match Rate (FNMR)] which means that legitimate users will not be verified within an acceptable ratio. We have seen that whenever there is a presence of a high FRR ratio, there is generally a corresponding FAR (False Acceptance Rate or False Accept Rate), which means that users that customarily aren’t verified, will be. Although the former is an inconvenience for users, the latter bypasses security protocols and degrades the overall security implementation, pretty bad stuff.
The second attack that has been seen in the past is a substitution attack. This is a little bit more prevalent, and has a higher level of apparent viability. As we saw in the SDK, there is the concept of templates that must be considered for a biometric process to occur. If a potential attacker could gain access to the medium of which the templates (biometric principal blueprints) are stored, it is possible that the source data could be altered which would in effect allow the user to succeed with the template comparison operation resulting in an acceptable verification ratio (which is why this ratio is controllable through the SDK, so take note of it).
There was something somewhat comparable done elucidated in C.J. Hills thesis Risk of Masqueraded Attacks Arising from the Storage of Biometrics submitted to the Australian National University in 2001. He established that artifact images could be used for the template matching for fingerprint verification. The artifact was basically fashioned from the stored template, and didn’t even really have to match the stored template in regards to the actual image representation. Although this required getting access to the templates that are stored in order to generate the artifact, it is a dangerous problem.
Along the same lines, if the attack understands the template storage types and the protocols that are required when the template verification occurs, it is possibly to do a false template injection attack. This would in effect circumvent the actual sensor process because instead it would directly inject the template into the comparison operation, which usually results in a high verification score.
Template verification systems are very black and white, which can lead to problems as well. Either a user is verified or they aren’t. It’s very simple binary logic. Because of this simplicity, during the communication between the biometric system and the relevant secured application, this switch suffers the possibility of being altered, which would result in the attack not really having to circumvent to the biometric readings at all.
That’s about all I can think off of the top of my head that wouldn’t require writing about for a couple hours, even though with Lisa in school I have the free time.
Hopefully, this has satisfied Stacy’s appetite for the time being.