Re: Certificate profile for Biometrics information.

["Phillip H. Griffin" <phil.griffin@xxxxxxxxx>]

Steve,

Stephen Kent wrote:

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.

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

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. 

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.

We'll eventually evolve I think to standards in all three of these areas.
We've
only recently gotten to the point of defining common header formats. The
data
format for some biometric types will come next I think, and algorithms and
matching methods last if this ever happens at all. Most likely is that specific
algorithms and methods will become identified (perhaps named with an OID).
The point of enrollment and the enrollment process is of course critical
to control.
And you are correct that there is no standard way to tell that Fred may have
your fingerprints and my irises.

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. 

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.

It's a tool then that can be used to create a security solution, not necessarily
an end in itself.

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.

That's rational. But I think that fear and consumption will mitigate such
demands. People are willing to have a perfect stranger pat their thighs and
buttocks and run their hands inside the tops of their pants just to get on
an
airplane. People are willing to be monitored by camera in parking decks 
to feel more secure, and searched by machines and dogs to enter public 
venues. People are willing to divulge their frequency of use and brand
preference of sanitary products just to get price discounts.

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. 

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.

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.

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.

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.

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.

Steve

I just got your call late yesterday. I'll try to reach you.

Phil