Re: Certificate profile for Biometrics information.

[Stephen Kent <kent@xxxxxxx>]

Title: Re: Certificate profile for Biometrics information.

Phil,

> > For individuals and/or organizations
> > that are concerned about privacy
> > issues, one could consider support of an encryption option where
> > selected
> > "trusted readers" could be enabled using specific
> > session-key tokens,
> > possibly included (under user or organization control) on the same
> > smart-card that holds the certificate(s) with the biometrics
> > extension(s).
> >  
> Privacy objects are already available in
> X9.84 and XCBF and rely on
> the familiar
> EnvelopedData and
> EncryptedData, and a named variant of
> EncryptedData. But
> biometric information is public, not private. It's in your
> hair left on the brush in the hotel, in your prints left on the glass
> at dinner, and
> by anyone who wishes to scan or photograph for the purpose of trying
> to mimic
> another.

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.

> So rather than opt for creating a
> certificate extension payload from a value of
> type
> BiometricSyntaxSets, I decided that the encoded value of a
> series of
> biometric objects was probably enough. Some communities of course
> will
> need privacy, but the general public will not. Authentication will
> likely do for
> templates.

I disagree with the suggestion that the general public will not demand privacy for this data.

> 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 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.

> 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.

Steve