Subject: RE: QC Sample Sucks (a bit)

From: Anders Rundgren <[email-masked]>
Date: Thu, 18 Mar 1999 08:43:27 +0100

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

I will, although my thought applications for this was limited to
the same situations as you use ID-cards in today.  That should NOT lead to 
severe problems.  See below:

>First, certificates often are stored and transmitted without
>confidentiality protection.

Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key Infrastructure,
this cannot (should not at least) be interpreted as public for anybody. 
Just to your own selection of trusted RPs. 

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

This is solved by only letting such certificates be fetched from the CA by the OWNER using a
"light" certificate.  Naturally using strong authentication/encryption.  The private/public keys
can be the same for the "heavy" ID to eliminate unnecessary key distribution

>It notes that if capture of a biometric if not physically secure, then
>there is a terrible risk of spoofing.

Absolutely, biometric capture is possible to spoof but in a PROTECTED area like
in a Bank or Passport-control, the scheme I have described would work much
better than current authentication systems.  Imagine a security officer that gets
a nice high-resolution picture on his PC instead of trying to see if that 1.5 inch
photo really is you!

And if you package the "light" cert in a CyberPhone you would just have to point to
a receiver, Click Yes if you agree to be authenticated by the RP and that's it!

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

The algorithms MUST IMO be known and servers can be made secure.  If the
staff running a CA are crooks the whole PKI idea is dead-meat so I do not
take this in account.

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

Again, the applications for biometrics are not for remote and unsecured use.

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

---

From: Michael Sierchio <[email-masked]>
Date: Thu, 18 Mar 1999 08:23:45 -0800

> Just to your own selection of trusted RPs.

This runs counter to the very idea of a cerificate -- which is a 
verifiable credential.  That there might be opaque parts of a
certificate which are meaningful only to a verifier,  perhaps
with active participation on the part of the cert holder to
protect privacy, is another matter.  If I read the above
correctly,  you're suggesting that the ID-certficate be
encrypted?  

> can be the same for the "heavy" ID to eliminate unnecessary key distribution

There seems to me to be some confusion here between the notion of
Certificate and a Personal Security Device, such as a smart card,
which might carry a certificate,  and embedded private key, and
perhaps other private data (such as biometric data of the owner,
encrypted of protected).  There are systems, such as the DynaSoft
BoKS software,  which extend this notion to a "soft" PSD, which
is downloaded from a central repository (or a replica server).

> >there is a terrible risk of spoofing.

Biometric data is as sensitive as a private key -- perhaps more so,
it's harder to revoke.  It shouldn't be in a cert, which is a public
credential.

---

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

Anders,

>Just to your own selection of trusted RPs.

Well, if you plan on making use of a growing installed base of products
designed for general X.509 certificate use, this assumption will not be
true, although I agree that one COULD provide better protection with a
different set of applications, etc.

>can be the same for the "heavy" ID to eliminate unnecessary key distribution

From a CA?  CA's do not necessarily store certs for retrieval by clients.
Directories do this, and I have relatively little confidence in the
assurance of the confidentiality offered by directory products.

>a receiver, Click Yes if you agree to be authenticated by the RP and

No argument here.  Under suitably controlled conditions, biometrics can be
very useful.

>staff running a CA are crooks the whole PKI idea is dead-meat so I do not

If the algorithms are to be kept secret, then we are talking about a closed
system. Also note that if multiple, closed systems are built using the same
biometric basis, then compromise of ANY of them can lead to the problems I
decribe.  However, if the system is closed, the algorithm is secret, and
the certificates have to be affored a level of confidentiality not
consistent with genric X.509 products, why bother using X.509?

>Again, the applications for biometrics are not for remote and unsecured use.

I agree that the applications SHOULD not be for such use, but at trade
shows we see many companies selling fingerprint readers that plug into PCs
for procisely that sort of use.  Hence my warnings.

Steve