Subject: Certificate profile for Biometrics information.

From: "Ebbe Hansen" <[email-masked]>
Date: Sat, 2 Nov 2002 15:32:42 -0800

I am looking for biometrics profile-definitions on how biometrics reference
information may be encoded and embedded into X.509 certificates (Public Key
Certificates as well as Attribute Certificates). The only
"biometrics-data-extension" I have found so far is included in RFC 3039 as
the "biometricInfo" extension.

Are there other biometrics profiles that have been defined at this time?

Regards Ebbe Hansen

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Sat, 02 Nov 2002 19:56:17 -0500

See http://www.oasis-open.org/committees/xcbf/#documents,

    * XML Common Biometric Format (XCBF) Working Draft
      <http://oasis-open.org/committees/xcbf/docs/XCBF20021024.zip>
      October 24, 2002

    * XCBF ASN.1 Schema for XML Markup
      <http://oasis-open.org/committees/xcbf/docs/XCBFSchema20021024.zip>
      October 24, 2002

Certificate extensions have been defined here for both X.509 Certificate and
AttributeCertificate types, and for X.9.68 Digital Certificates for Mobile/
Remote and High Volume Transaction Systems for Financial Services. These can
be encoded in either ASN.1 Distinguished Encoding Rules (DER) or using 
the new
XML Encoding Rules (XER).

I'm cutting the same definitions into the current revision of X9.84 
Biometric Information
Management and Security this week. We hope to have this revision 
completed and into
X9 ballot by the end of the year. After this, the US will likely propose 
this revision into
ISO TC 68/SC2 Security and General Banking Operations as a new work item.

Working code from my company and from others already supports this 
certificate
extension payload. See http://asn-1.com/biolojava.htm for more information.

Phil Griffin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 13:33:30 -0500

>Are there other biometrics profiles that have been defined at this time?

Ebbe,

Many sorts of biometric info are inappropriate to place in a cert, 
due to concerns about disclosure of that info, e.g., to enable off 
line guessing attacks. This, in part, is why we don't have any 
extension defined for this purpose. Could you explain in more detail 
what sort of biometric info you envision storing in certs, and how it 
would be used?  That might help us better understand what might be 
appropriate.

Thanks,

Steve

---

From: "Ebbe Hansen" <[email-masked]>
Date: Mon, 4 Nov 2002 11:12:45 -0800

Steve,

I would consider storing of a biometrics "digest" (sometimes also called a
template) to be the minimum biometrics information that could be included in
a certificate (possible in an Attribute Certificate). Type of biometrics
(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
useful. I just learned the XML working group already has a draft out (Ref.
http://www.oasis-open.org/committees/xcbf/#documents).

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

Ebbe

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, November 04, 2002 10:34 AM
To: Ebbe Hansen
Cc: [email-masked]
Subject: Re: Certificate profile for Biometrics information.

Ebbe,

Thanks,

Steve

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 04 Nov 2002 14:56:40 -0500

Ebbe:

In general, I expect certificates to contain public information.  In some 
systems, the biometric template allows an attacker to compose a matching 
input.  This is essentially the information needed to masquerade.  For this 
reason, I do not want to see them in certificates.

Attribute certificates contain a mechanism for encrypting attributes in a 
manner that only intended recipients can decrypt them.  This seems like a 
better location for biometric templates.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 14:56:49 -0500

Ebbe,

I suspected that templates were what you envisioned putting in certs. 
The problem is that unless these values are encrypted, exposing 
templates makes them available for the sort of off line guessing 
attacks I mentioned.  This is not only a "privacy" issue, but very 
much a security issue. Certs are generally viewed as being 
transmitted over insecure channels and stored in repositories that 
are not necessarily confidentiality-secure.

If it is necessary to encrypt these values for security, as suggested 
above, then I would want to see a proposed solution that provides 
confidentiality in a fashion consistent with some credible example 
scenarios. Note that if the template in the extension is encrypted 
prior to inclusion in the cert (as I would expect), then the key 
management process for disclosing this data to a "trusted reader" is 
a lot more complex than typical "session key" management schemes of 
the sort I think you alluded to above.

Steve

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 04 Nov 2002 15:37:38 -0500

Ebbe and Steve,

>http://www.oasis-open.org/committees/xcbf/#documents).
This contains exactly the same types being defined in the X9.84 revision
that it is my turn to edit this week. The text states (for now):

Additional mechanisms can be used to provide integrity protection to
biometric information, when it is being conveyed with other data (e.g.,
a financial transaction).  Biometric templates in the form of
EncodedBiometricObjects can be bound to a public key associated
with a private key in a digital certificate.

This standard supports biometric certificate extensions that can be
incorporated into values of types Certificate and AttributeCertificate,
as defined in the Directory series of standards, and type DomainCertificate
as defined in X9.68 [???]. Biometric certificate extension values can be 
encoded
in either the Distinguished Encoding Rules (DER) or the canonical 
variant of the
XML Encoding Rules (cXER):

biometricTemplates EXTENSION ::= {
   SYNTAX         EncodedBiometricObjects  -- DER or cXER --
   IDENTIFIED BY  x509-biometricTemplates
}

domainBiometricTemplates PRIVATE ::= {
   NAME  oid : x968-biometricTemplates
   TYPE  EncodedBiometricObjects  -- DER or cXER --
}

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

Tracking the fameous girl in Afganistan on the cover of National 
Geographic to
a woman some twenty years later was done by iris scan analysis of the 
eyes in
the photographs. So, biometric information in most cases is just public 
data that
when used in open networks needs to have integrity and to be 
authenticated in
order to be trusted and relied upon.

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.

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.

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.

Phil

---

From: Sam Schaen <[email-masked]>
Date: Mon, 04 Nov 2002 15:42:51 -0500

Would an acceptable approach be to create a one-way function between the
biometric data and the digest?  Similar to the hash algorithm used for
signatures, the objective would be to make it virtually unlikely that two
biometric captures could lead to the same digest but that having the digest, it
would not be feasible to obtain the biometric.  Certainly a hash meeting those
characteristics could be included in a certificate without violating privacy
concerns and without making imperonation of the biometric characteristics easier
than they currently are.

-Sam

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 15:59:39 -0500

>concerns and without making imperonation of the biometric 

Sam,

That approach generally does not work, because a verifier needs to 
"score" the captured biometric data against the template values. 
It's never an exact match, unlike with passwords.

Steve

---

From: Sam Schaen <[email-masked]>
Date: Mon, 04 Nov 2002 16:18:28 -0500

"Phillip H. Griffin" wrote:
[snip]

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

[snip]

As someone responsible for documenting  the DOD PKI certificate profile
and verifying that numerous certificates have satisfied that profile, I
can say with assurance that there is no biometric data in the
certificate itself.

With somewhat less assurance, since I am not intimately familiar with
the process, it is my understanding that the fingerprint indicia are
stored centrally--not even on the smart card containing the
certificates.

Sam Schaen

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 04 Nov 2002 16:17:17 -0500

Sam:

That would allow someone who validated the certificate to determine whether 
a particular biometric template was known to the CA at the time the 
certificate was signed.  The relying party would need to obtain the 
template and an input form other sources.

I do not know the problem that Ebbe is trying to solve, so I do not know if 
this meets his needs.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 16:25:06 -0500

>stored centrally--not even on the smart card containing the

I can verify Sam's comment. The DoD Common Access Card (CAC) does not 
store biometric data in any form at this time. The fingerprint data 
are stored in a central database and that database is accessed when a 
user must authenticate him/herself to a verification officer to have 
a CAC issued or reissued.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 04 Nov 2002 13:39:36 -0800

At 03:37 PM 11/4/2002 -0500, Phillip H. Griffin wrote:
>EncryptedData. But biometric information is public, not private. It's in your
>by anyone who wishes to scan or photograph for the purpose of trying to mimic
>another.

I think there is a world of difference.  It is one thing for an individual 
to risk exposing themselves by physically following me around to gather 
hair from my comb, fingerprints from my dinner glass, etc.  It is another 
thing for someone half a world away to issue a query and obtain countless 
such samples.

The threat of the former capability does not justify enabling the latter 
capability.

(And if biometric data is essentially "public", what value has it in 
certification?)

Cheers!  ____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 04 Nov 2002 16:59:32 -0500

Stephen Kent wrote:

> "score" the captured biometric data against the template values. It's 
> never an exact match, unlike with passwords.
>
> Steve
>
The matching methods and sample collections are also vendor specific
and proprietary. There's a place holder for processing algorithms and
matching methods to be identified by NIST in X9.84, but to date none
have been registered. This situation will likely not change for at least the
near future.

Phil

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 04 Nov 2002 17:01:17 -0500

>stored centrally--not even on the smart card containing the
I omitted "said" above in "is to use". Hearsay on my part from a vendor
involved in producing product.

Phil

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 04 Nov 2002 17:07:20 -0500

Tony Bartoletti wrote:

>> hair left on the brush in the hotel, in your prints left on the glass 
>> at dinner, and
> I think there is a world of difference.  It is one thing for an 
> individual to risk exposing themselves by physically following me 
> around to gather hair from my comb, fingerprints from my dinner glass, 
> etc.  It is another thing for someone half a world away to issue a 
> query and obtain countless such samples.

I didn't speak of samples, but templates.

>
> The threat of the former capability does not justify enabling the 
> latter capability.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 18:05:48 -0500

>involved in producing product.

maybe wishful thinking on the part of a vendor ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 18:05:16 -0500

>have been registered. This situation will likely not change for at least the

Phil,

I agree that the templates and scoring systems are vendor-specific, 
but that does not change the problem to which I alluded, i.e., the 
scoring generally requires access to the original values, not to a 
1-way function of those values.

Steve

---

From: "Ebbe Hansen" <[email-masked]>
Date: Mon, 4 Nov 2002 14:08:09 -0800

Russ, Sam,

Yes - a hash of the template would suffice in cases where the template (and
other bio-parameters) can be obtained (securely) by other means. However, in
cases where such secure infrastructure is not available (or difficult to
manage), I think the encrypted Attribute extension as defined in RFC-3281
could be helpful.

One of the problems that may arise using encrypted Attribute extensions is a
possible need to add "recipients" to the list of trusted recipients already
included in a previously issued AC (holding an encrypted Attribute
extension).  One might consider issuing an additional AC (linking to the
previous AC, or the original PKC?) that will be used primarily to
"distribute" decryption tokens to the additional recipients?

Is their any immediate limitation on how many ACs that may be "linked" to a
previously issued PKC or AC?

Ebbe.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Monday, November 04, 2002 1:17 PM
To: Sam Schaen
Cc: Stephen Kent; Ebbe Hansen; [email-masked]
Subject: Re: Certificate profile for Biometrics information.

Sam:

Russ

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 04 Nov 2002 18:28:49 -0500

> maybe wishful thinking on the part of a vendor ...
I don't think so. I got the idea that it was an on card matching situation
and that it was X.509 certificates, not attribute certificates to be used.
But I'm not involved in the work.

For biometrics, I see certificate formats as just another package for
the data. I certainly don't envision biometrics becoming part of path
processing for example. And the biometric data components are
often encrypted or otherwise obscured, the details available only to
a given vendor. But header information, such as validity information,
quality or type, are becoming standardized and benefit from being
signed.

Phil

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 18:54:06 -0500

Phil,

>But I'm not involved in the work.

I am an advisor to the Executive Director for the DoD PKI and earlier 
this completed an analysis of most aspects of this PKI, the one that 
uses the CAC. I can speak with considerable confidence that this is 
NOT how it is used today.

I am willing to believe that someone who wants to promote the use of 
biometrics might be running some pilot somewhere in which this sort 
of thing is done, storing a template on a card for use in local 
verification, but it is almost certain that the template is not part 
of any cert. The cards have a facility to store data for private 
(i.e., local) application uses such as stored value systems. one 
could store a template in this fashion, using the controls offered by 
the Java applets for managing access to such data, so that only a set 
of authorized readers would be able to get the template.

>quality or type, are becoming standardized and benefit from being

There might be some scenarios in which encrypted template data could 
be carried in a cert and be acceptably protected. The question Russ 
asked is what are those scenarios. We know of lots of bad ideas on 
how to store this data in certs and we don't want to condone that.

Note that when we discussed inclusion of biometric data in a cert in 
the Qualified Certificate RFC, we intentionally limited it to data 
for verification by a human being, e.g., a photograph, not a 
fingerprint, voiceprint, etc.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 04 Nov 2002 16:33:08 -0800

>Note that when we discussed inclusion of biometric data in a cert in the 
>Qualified Certificate RFC, we intentionally limited it to data for 
>verification by a human being, e.g., a photograph, not a fingerprint, 
>voiceprint, etc.

Hmmm.  Well, most humans have a hard time reading voiceprints, and even 
fingerprints ... but I don't think machines will have a hard time reading 
photographs, certainly not for long.

Cheers!  ____tony____

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Mon, 04 Nov 2002 20:08:57 -0500

Too late. Technology already available.
http://www.webdesk.com/afghan-girl/
Phil

Tony Bartoletti wrote:

> Hmmm.  Well, most humans have a hard time reading voiceprints, and 
> even fingerprints ... but I don't think machines will have a hard time 
> reading photographs, certainly not for long.
>
> Cheers!  ____tony____
>
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 18:36:33 -0500

Phil,

>hair left on the brush in the hotel, in your prints left on the 
>glass at dinner, and

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

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

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

>arbitrary payload relevant to an application. There are many things this might
>names, an encrypted smart identifier, etc. This type can also carry 
>the biometric
>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

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Tue, 05 Nov 2002 09:56:01 -0500

Steve,

Stephen Kent wrote:

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

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

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

> 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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Nov 2002 14:54:38 -0500

At 4:33 PM -0800 11/4/02, Tony Bartoletti wrote:
>>Note that when we discussed inclusion of biometric data in a cert 
>>in the Qualified Certificate RFC, we intentionally limited it to 
>>data for verification by a human being, e.g., a photograph, not a 
>even fingerprints ... but I don't think machines will have a hard 
>time reading photographs, certainly not for long.
>
>Cheers!  ____tony____

Tony,

The focus is on the complementary set, i.e., we wanted to reject 
biometrics that only machines could process.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 05 Nov 2002 12:21:18 -0800

>biometrics that only machines could process.

Ok.  Got it.  That makes sense.

You want to ENABLE "human-in-the-loop" verification, as
opposed to DISABLE "no-human-in-the-loop" verification.

Cheers!  ____tony____

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Nov 2002 16:36:36 -0500

Phil,

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

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

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

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.

>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

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>
>biometric information, one that extends an ordinary signature to identify the

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

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.

>if I knew the sample were handled properly - not retained or shared with

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.

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

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.

>systems do not care who, what or where an input comes from,

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.

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

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.

>>>names, an encrypted smart identifier, etc. This type can also 
>>>carry the biometric
>and to a means of identifying the particular individual authorized 
>to use the token
>template is stored only on the token and not on a centralized data 
>base, then there

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