[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Certificate profile for Biometrics information.

Title: Re: Certificate profile for Biometrics information.
Phil,

<SNIP>
i think there is some confusion here. My fingerprints and other biometrics are not secrets, but many folks consider them to be "private." The concern I coted is that anyone with access to a plaintext template, and knowledge of the scoring algorithm used by a vendor, could engage in analysis to try to construct a digital input which would be accepted by the algorithm as a match for the template in question. This, as Tony noted, represents a distinct form of attack from the covert acquisition of physical biometric samples, and it is a form of attack that is easy to effect from a distance, perhaps for thousands of individuals whose templates might be disclosed. So, I do think there is good cause to take precautions to prevent disclosure of this data wherever it is stored, transmitted, etc.
A possibility of course, but I think that there are much easier attacks to launch.
And this one depends on being able to guess algorithm details and to be able to
spoof input samples into a matching system where the biometric data in the
templates may have been obscurred or encrypted. And it is an overall security
system, which may integrate biometrics along with other factors, that must be
attacked, and not simply the biometric.

In the security business, we always assume that the attackers know the system config, algorithms, etc. So the impediments you cite here would be discounted.

I don't fully understand the second part of your comment. If biometrics are used as the primary (sole?) authentication mechanism (which is the usual proposal because the ease of use feature of biometrics is lost if one imposes other mechanisms such as passwords or crypto tokens), then defeating the biometrics defeats authentication, and that usually undermines access control (which is typically based on authentication), etc. Yes, in some circumstances there might be other safeguards that might limit the damage done by subversion of a user authentication mechanism, but user authentication is typically our first line of defense, and one would expect that someone who subverted this mechanism would, at a minimum, be able to pose as the user who is being impersonated and thus inherit the authorizations of that person.  That's a pretty serious security problem.

In all US standards, a template contains two basic parts, header information
and biometric data. At the message level, the  later is treated as opaque, having
no specified structural details. In fact there are details, but these are generally held
private by vendors as are the details of their processing algorithms and matching
methods, which frequently incorporate safeguards against spoofing the inputs.

Again, the proprietary nature of the algorithms is discounted; it falls under the rubric of "security by obscurity." I also have little confidence in the measures used by low cost biometric capture devices to deter spoofing. So, unless you have a more concrete example of the sort of safeguards you allude to above, I don't think we agree on there being any substantial countermeasures for a typical, remote user authentication application under these compromise scenarios.

Depending on the vendor, and where and how the template is used, the biometric
data portion of a template may be encrypted or otherwise obscured. Over the past
several years, I've heard of the data being protected by everything from Triple
DES, to strong cryptography but I can't tell you what it is, to it's a proprietary
format that you'll never be able to guess.

3DES is reasonably strong crypto, but it's not very useful in many attacks scenarios.  If all biometric capture devices from a vendor have the same key (a real example) then this is not much of a deterrent. None of the devices I've seen meet FIPS 140-1 criteria for protecting keys, so it would usually be easy to extract keys from any of these devices anyway.

Now this may sound bad at first blush. But there is a great range of products
to consider that can provide varying levels of security for protecting assets
with different values at different costs. At the low end, PKI and encryption
may be out of the question. At the high end, biometrics will likely be used
as part of a security solution along with other measures and factors. And
beyond the template format itself are the issues of just how inputs are
processed to create a template in the first place and how sample inputs
are processed or validated validated before a system attempts a match.

Biometrics are not intrinsically more secure than use of certs, say with good hardware tokens, so I object to the implied spectrum you cite above. Again, the major, credible push for biometric use stems from user convenience and possible cost savings. Arguments about superior security have usually been invalid, if examined in detail against mechanisms other than simple, static passwords.


But how enrollment data is collected and processed to form a template, and
how samples are used to perform matches are points at which there are often
safeguards that must be used against spoofing the system, perhaps even the
encryption of some or all parts of the data. An example being the Afgan girl's
iris data being detected as coming from a photograph and not a valid iris scan
camera. This on top of the proprietary methods being used, environmental
controls and hardware.

Encryption of the data during transmission from capture/sample point to the checking point is necessary, but far from sufficient to make these systems secure.


<SNIP>
In X9.84 and XCBF, when signature mechanisms are used for sample or
template protection, they must be used as part of an overall solution.These
standards support four basic mechanisms, SignedData, AuthenticatedData
and an ordinary digital signature like the one used to sign a certificate, and a
MAC (HMAC). A digital certificate then is really just another package for
biometric information, one that extends an ordinary signature to identify the
key of the signer and provide support for a hierarchy.

Putting the template into the cert is just plain bad in many, many instances. I don't claim that there are no contexts in which it might be appropriate, but we seem to have a dearth of them so far, and lost of examples where it is a bad idea.

<SNIP>

In most systems, I don't believe that privacy will be an issue for templates
at the message level. But here privacy will be needed for some communities
even for the header data. For example, knowing which version of vendor
product is being used or the age of a record of some biometric type may
assist an attacker.

yes, and there will be lots of ways to acquire that data. let's not forget the fake ATM attacks as a means of acquiring PINs and account info.

I think that biometric samples, how they are treated when they are collected
and processed to form a template, what becomes of them after this process,
and how they are treated when they are collected to perform a match, will
become the dominant points of public concern. I wouldn't much mind your
having my photograph if I knew that no system would grant you access to
something I valued based on your having a copy. I wouldn't mind your
collecting my fingerprint to match against the template on my smart card
if I knew the sample were handled properly - not retained or shared with
others.

That might be a rational level of concern, but only if the systems were a lot better than they are now. low cost sensors are readily fooled in many contexts, starting with that photo or fingerprint, or with a template. And, given that cost if always a major factor in system design processes, I expect that lower cost sensors that are more easily fooled will be deployed, with predictable results.


Biometric information seems destined to become the financial identifier that one
day replaces the social security number. There's much interest in using it to try
to combat identity fraud, said to be the fastest rising crime. On another front,
a DOD pilot is to use a biometric extension in a smart card certificate.

I think this is a very questionable assertion. The SSN is an ID and a convenient one. it is dangerous one in that people rely on it in the absence of any secure means of verifying that the individual asserting the SSN is the :owner" of that ID.  Biometric data is

SSNs can be reassigned, so they are not necessarily unique.

it is true that they are no necessarily unique, though not for the reason you stated. (I had the privilege of being briefed on this by the SSA folks in the course of a NRC study that I chair.) But, the combination of SSN and name is unique, for all practical purposes, and lots of systems rely on that and work well.

And I agree, and the point I tried to make above is that if
systems do not care who, what or where an input comes from,
then all bets are off.

But systems that try to verify user identity remotely, which is what we often do in the information systems arena, do not have much reliable info about exactly where the inputs originate.


not an ID. It varies from sample to sample and thus is a poor substitute for any form of static, globally unique ID. Also, as you noted, templates are vendor-specific, which makes this for of ID not useful for identifying the same individual in two contexts where different biometric systems from different vendors have been employed.
Not unlike having the same keys being certified by different authorities.

I disagree. the bits in the template will likely differ, the samples differ every time I capture them, but the public key is constant in this example.

The BiometricObject in X9.84 and XCBF contains a 'hole' that can carry an
arbitrary payload relevant to an application. There are many things this might
be, the blinded hash of a customer PAN as used in SET for cardholder common
names, an encrypted smart identifier, etc. This type can also carry the biometric
processing algorithm and matching method needed by a relying party. And most
importantly, a set of these can carry multiple occurances of a biometric, say three
fingerprints, or sets of mutiple biometric types, say ten fingerprints and two iris
images.

I don't think the representational flexibility you describe here addresses the fundamental security and privacy issues being raised.
I believe that the capability of binding access to an account, to a specific token,
and to a means of identifying the particular individual authorized to use the token
and thereby to access the account, can be used to address security issues. If the
template is stored only on the token and not on a centralized data base, then there
are also privacy issues that might be addressed.

Yes, if the token is stored only on the token and NOT sent to a central sever for comparison, many privacy issues are alleviated and some security concerns are diminished as well.  But, I don't need to put the template in a cert to support this usage model, since it is consumed locally by the card.

Steve