Subject: QC Sample Sucks (a bit)

From: Anders Rundgren <[email-masked]>
Date: Wed, 17 Mar 1999 13:19:57 +0100

Hi Petra,
I have some comments on the QC "Sample Certificate" that contained data
about you.

Although a sample is just a sample I still think that a sample should be "typical".

I see two VERY different situations (which should be in the draft) when QCs are used:

1. Remote (the Relying Party has no visual or physical contact).   In that scenario
you cannot verify any biometrics like age, sex etc.   I.e. you should not require that
kind of information in a remote situation as it makes no sense for automated
identification purposes.   There may be exceptions when the RP needs biometrics 
but that calls for another QC that you would use in those rare circumstances.

2. Physical.  RP have visual or physical contact with the subject and *could* 
use biometrics to verify that the certificate holder seems to be matching.  In this case
you may need photo, fingerprint, age, sex etc in the QC itself as this data is not necessarily
printed on a smart card holding the QC.  The "card" could actually be a miniaturized
thing within a mobile phone.  ( www.mobilephones-tng.com/v100/cyberphonecards.html )

So I urge you to make room in the QC draft for some biometrics (in a structured way) and
to make TWO or more samples.

Consequence: You cannot have just one QC to cope with all possible uses!

Regards
Anders Rundgren
Senior Internet e-commerce Architect
Jaybis AB
http://www.mobilephones-tng.com

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Mar 1999 17:35:05 -0500

Anders,

I recommend to you the discussion on use of biometrics (like fingerprints,
hand geometry, iris or retinal image patterns, etc.)  in open, networked
systems contained in the recent "Trust in Cyberspace" report from the U.S.
National Academy of Science.

First, certificates often are stored and transmitted without
confidentiality protection.  This raises the question of how one protects
sensitive biometric data if it is embedded in a certificate.  Remember,
this data needs to available to any entity who will use it for user
authentication, yet it must not be made available to possible attackers,
for the reasons cited below.

It notes that if capture of a biometric if not physically secure, then
there is a terrible risk of spoofing.  The observation is that a server
with biometric data will, invariably be compromised.  The result is that
the user biometric templates contained in the server, as well as the
algorithms used for matching, will be exposed.  Knowledge of the templates
and the algorithms permits at attacker to generate bit streams that will
suffice to authenticate the user's whose templates were compromised. Thus,
unless there is very good technical and physical security for capture of
user biometrics, to preclude introduction of bogus bit streams that purport
to be real biometrics, such systems are fatally flawed.

Steve

---

From: Michael Roe <[email-masked]>
Date: Thu, 18 Mar 1999 12:20:37 +0000

> for the reasons cited below.

Steve,

I disagree with this view of how biometrics should be used.
They are *not* cryptographic keys, and shouldn't be used as if they were:

  * Unlike keys, biometrics cannot be revoked in the event of a compromise.

  * Unlike keys, biometrics cannot be assumed be secret

Consider a typical example of a biometric - your photograph, as used on
passports and U.S. driver's licenses. It's not a secret --- lots of people
know what you look like, and it's probably not hard for an attacker to find
another  photography of you. Furthermore, changing your apperarance (growing
a moustache etc...) would be inconvenient to say the least.

Nevertheless, a photo-id serves a useful authentication function. But any
protocol that assumes that biometric data is secret is fundamentally flawed.

Other sorts of biometrics, such as iris scans, fingerprints, and DNA samples
are not so obviously non-secret as photographs, as it's a bit harder
for an attacker to obtain them. But if any of them are routinely used
for authentication, they become public information. If you regularly let 
machines read your fingerprints (because that's what you have to do to
prove your identity) then it's likely an attacker will have ample opportunity
to obtain this information.

Protocols that use biometrics can be made to work. But you have to avoid 
falling into the trap of using biometrics like crypto keys.

There is a similar problem with identifiers (i.e. names) such as credit card
numbers and social security numbers. Protocols which treat them as if they were
secret keys for authentication purposes ("I know your SSN, therefore I am you")
are broken for similar reasons. However, such broken protocols are in common 
use.  I hope that this type of mistake is not repeated with biometrics.

Mike

---

From: "Petra Gl�ckner" <[email-masked]>
Date: Thu, 18 Mar 1999 15:02:02 +0100

Hi Anders,

I never meant to cope with all different scenarios with the 
one QC example. I just wanted to display the concept of our
PersonalData structure with the possibility to have multiple 
authorities responsible for different attributes.

The example doesn't say anything about which attributes are 
required. Of course a CA can only issue certificates with
information they or any other registration authority was able
to verify.

I'm not convinced that you need to have a fingerprint in a QC
certificate, but of course we could define an appropriate 
attribute in our next QC version, but maybe there is already
such an attribute definition ? Does anybody know ?

Regards - Petra

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Mar 1999 11:21:54 -0500

Mike,

I think we are in agreement on many points.  As you note, one can't easily
revoke a biometric; well, not more than 10 times for fingerprints, twice
for iris scans, ... :-).  I also agree that a biometric ought not be
assumed to be a secret in most cases.

The photograph example you gave does not fall into the class of systems I
was warning against.  The authentication function is performed by a person,
in the analog domain, under conditions that usually are viewed as providing
adequate physical security for transmission of the image from the user to
the authenticating system.

One can make use of biometrics in electronic systems, if one assumes that
the capture of the biometric is itself tamperproof, and that the
registration process is secure.  I was pointing out that even if
transmission security is afforded to a captured biometric, and even if the
templates are stored on a server (to ensure the confidentiality,
authenticity, and integrity of the reference biometric) that the system
would be flawed.

Your observations about the ease of capturning input biometrics are not
quite the same as my comments about confidentility of the reference
biometric (template). I suspect we agree that the integrity and
authenticity of the template is more critical than its confidentiality.

Finally, we are most definately in agreement re use of biometrics as keys;
it's just a bad idea.  However, a number of companies are pushing biometric
technology for use in precisely the circumstances that we all agree is a
bad idea, and so I wanted to take this opportunity to raise the issue
again.

Steve

---

From: Juergen Walter <[email-masked]>
Date: Thu, 18 Mar 1999 18:46:32 +0100

Petra,

> authorities responsible for different attributes.

But there is another concept probably more meaningful. The X.509
standard enables multiple authorities to issue attribute certificates.
The authorities are called attribute certification authorities. End
entity´s attribute certificate is linked to entity´s public key
certificate by entity´s distinguished name or certID.

Is there someone who is planning to implement a personal data record
where multiple authorities are responsible for different attributes?
Personally, I think that your approach leads to long vehicle
certificates of short life-time. The more attributes and different
authorities are involved the longer the certificate and the shorter the
lifetime. Certainly not designed for today´s smartcards.

Juergen

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: [email-masked]            Fax:  +49 3461 415072
--------------------------------------------------------------------