RE: New proposed solution to the QC biometric issue

[Anders Rundgren <anders.rundgren@xxxxxxxxxx>]

<snip>

Stefan,

This is a little bit like the DS issue.  Without any specified infrastructure the
inclusion of hashed biometrics in QCs becomes too theoretical.

Being the originator of the request for biometric data in QCs I feel bad about
the idea of hash of biometrics since this is very inconvenient (my guess) compared to
store the real thing in "signed, certified, structured, container" that a certificate
is.  If this is "all we get" you could IMO equally well drop it entirely as all serious
implementers will probably use other measures to achieve the functionality required. 

For an almost complete down-to-earth ASN.1-free solution trying solve today's problems
with current technology, please look into:

http://www.mobilephones-tng.com/papers/idcards.html

This solution is (mainly) intended for use locally in banks, security controls etc. where you want
to know that the bearer of a card is the person it was issued for.  Not exactly rocket-science
(application-wise) but pretty useful anyway.  And unlike current photo-cards impossible to forge.

But I do believe that fully automatic fingerprint verification as a COMPLEMENT to the ID-cert
and PIN-code would work wonders in entrance controls.   To steal both a person's card, PIN-code
AND forge a "finger emulator" seems pretty hard.  Actually there is a much bigger risk associated
with persons you trust which no digital signature, biometric or whatever has a cure for!

The presented solution works fine with current smart-card technology which I also find
important since most QCs will probably be stored in such.

Regards
Anders Rundgren
Senior Internet e-commerce Architect
+46   70 - 627 74 37

PS If you insist on the hash scheme I think that it makes sense to write a simple spec.
on how you meant that it should work as well.   There is a bit more to biometrics than
just ASN.1-code... DS


>Well, since then I have had a lot of off list discussions ending up in a
>new conclusion:

>1) It could be valuable to include support for biometric data aimed for
>human verification (not machine verification), e.g. human verification of
>picture image or signature image. In fact face recognition and signature
>recognition are regarded as the two major implementations which justify
>this proposed expansion of the draft. 

>2) The supported solution should only address storage of a hash value of
>biometric data. This would provide all necessary functionality for
>authenticating bio-data without loading the certificates to much.

>3) Storage of bio-data-hash should NOT be done in the PersonalData field
>since this data is conceptually different from id-attributes. Further,
>since bio-data need storage of 2 parameters (OID + hash), those values
>can't be stored in a single predefined attribute. Instead a new optional
>extension should be defined for this purpose.

>Petra Glöckner has prepared a proposal for this new extension in QC as
>follows:

>Extension ::=  SEQUENCE {
  >extnId              OBJECT IDENTIFIER,
  >critical            BOOLEAN DEFAULT FALSE,
  >extnValue           OCTET STRING }

>biometric 	EXTENSION ::= {
  >SYNTAX            BiometricSyntax
  >IDENTIFIED BY     id-qext-biometric }

>id-qext-biometric    OBJECT IDENTIFIER  ::= {id-qext xx}

>BiometricSyntax  ::=  SEQUENCE OF BiometricData

>BiometricData	::=	SEQUENCE {
  >typeOfBiometricData  OBJECT IDENTIFIER
  >biometricDataHash    OCTET STRING }



>So with this concrete proposal I would like to reopen the issue for
>comments on this.

Thanx!