Subject: Potential Security Risk in Qualified Certificate images?

From: Dean Povey <[email-masked]>
Date: Mon, 02 Apr 2001 13:12:50 +1000

Hi all,

I have just being perusing RFC3039 (Qualified Certificates Profile) with
a view to coming up with a more concrete proposal for logotypes in 
certificates.

RFC3039 uses the following syntax to represent an image of the subject in 
its biometricInfo Extension.

      biometricInfo  EXTENSION ::= {
          SYNTAX             BiometricSyntax
          IDENTIFIED BY      id-pe-biometricInfo }

      id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}

      BiometricSyntax ::= SEQUENCE OF BiometricData

      BiometricData ::= SEQUENCE {
          typeOfBiometricData  TypeOfBiometricData,
          hashAlgorithm        AlgorithmIdentifier,
          biometricDataHash    OCTET STRING,
          sourceDataUri        IA5String OPTIONAL }

      TypeOfBiometricData ::= CHOICE {
          predefinedBiometricType    PredefinedBiometricType,
          biometricDataID            OBJECT IDENTIFIER }

      PredefinedBiometricType ::= INTEGER { picture(0),
          handwritten-signature(1)} (picture|handwritten-signature,...)

Specifically it states: 

   The predefined biometric type picture, when present, SHALL identify
   that the source picture is in the form of a displayable graphical
   image of the subject.  The hash of the graphical image SHALL only be
   calculated over the image data excluding any labels defining the
   image type.

i.e. The image type is not part of the digest and is therefore not 
authenticated.  This leads to a potential risk where the CA signs an image 
after viewing it one format, but it is presented to the user in a different
format.  It is an open question whether it would be possible to produce
a single binary data file crafted such that it would appear as a plausibly
different image to both the CA and the user when presented in different 
formats. However, I think we would have to concede that it is possible.

It gets worse.  Even if the image type is included in the certificate many 
modern image formats have different options for how they are displayed.  
For example, I seem to recall that animated gifs on old browsers would just
display the first image rather than the whole animated sequence.  It may be
possible to fool a CA into signing an animated gif, where an initial image 
is shown for an imperceptibly brief time, before showing the final image.  
The user with the old browser then sees just the initial image.  

There may well be many other ways of attacking specific formats.

Can anyone come up with a solution to this?  I can think of three 
less than perfect alternatives:

1. The risk could be avoided by requiring the CA to always generate the image 
   from an analog source rather than certifying a digital image, but this
   obviously makes such a scheme less flexible.  

2. Another approach might be to recommend a profile for common
   image types and their options outlining which are appropriate for use.
   The main disadvantage of this, is that these image types will evolve 
   over time, meaning they will need continual updating.  Another 
   disadvantage is that it may be very difficult for a CA to verify what
   particular combination of options are being used in a particular
   image they are being presented.

3. A third approach might be that the CA and end-user must use the same 
   software/hardware to view the image.  However, in an environment with
   many versions this would quickly become unworkable.

Are there any views on this?

Cheers.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Sun, 01 Apr 2001 23:34:28 -0500

If you are interested in the secure biometrics
(techniques for digital signatures and encryption) 
you may want to have a look at "X9.84 Biometric
Information Management and Security". This standard
was recently approved by ASC X9 for use in the 
financial services industry. It is very flexible 
and well thought out.

X9.84 defines the requirements needed to manage,
secure, and audit biometric information for customer 
identification and employee verification. It was 
developed in conjunction with the BioAPI Consortium,
the NIST Information Technology Laboratory's Common 
Biometric Exchange File Format (CBEFF) initiative, 
and the International Biometric Industry Association
(IBIA). 

X9.84 provides a solid set of guidelines for the
secure implementation of biometrics within financial
transaction environments, and is well suited for use
by other industry sectors as well.

The IBIA serves as the registrar for new biometric 
types, matching methods, processing algorithms and 
vendor specific formats that will be allocated under
an X9 defined OID arc that the IBIA will manage. See
http://www.ibia.org/formats.htm.

There is a lot more going in this effort than just
pictures and written signatures. The current set of 
biometric types defined for use in X9.84 secure 
messages in the financial services industry are:

BiometricTypes BIOMETRIC ::= {
   { BIOMETRIC id : body-Odor          } |
   { BIOMETRIC id : dna                } |
   { BIOMETRIC id : ear-Shape          } | 
   { BIOMETRIC id : facial-Features    } | 
   { BIOMETRIC id : finger-Image       } |
   { BIOMETRIC id : finger-Geometry    } |
   { BIOMETRIC id : hand-Geometry      } |
   { BIOMETRIC id : iris-Features      } |
   { BIOMETRIC id : keystroke-Dynamics } |
   { BIOMETRIC id : palm               } |
   { BIOMETRIC id : retina             } |
   { BIOMETRIC id : signature          } |
   { BIOMETRIC id : speech-Pattern     } |
   { BIOMETRIC id : thermal-Image      } |
   { BIOMETRIC id : vein-Pattern       },

   ... -- expect additional biometric types --
}

A CMS module is defined in X9.84 based on X9.73,
which is closely aligned with the work in SMIME,
but which extends the IETF effort. So the familiar
cryptographic types, SignedData, EnvelopedData, and
AuthenticatedData are used in X9.84 for security. 

And the x9.84 OID 

x9-84 OBJECT IDENTIFIER ::= {
   iso(1) identified-organization(3) tc68(133) 
      country(16) x9(840) x9Standards(9) x9-84(84) }

can be paired in any of the certificate formats defined
in X9.84 and X9.73 (X.509 identity certificates and 
AttributeCertificates, X9.68 Domain certificates, and
any other formats that may arise, such as WTLS and XML)
to carry a value of 

BiometricSyntax ::= CHOICE {
   biometricObject            BiometricObject, -- unprotected
   integrityObject            IntegrityObject,
    privacyObject             PrivacyObject,
   privacyAndIntegrityObject  PrivacyAndIntegrityObject
}

to allow applications that need to do so, to deal 
with privacy concerns, and to also support those
applications that have no such concerns. A very
flexible design.

You can find out more about this new standard at
http://www.x9.org. I believe that the work is now 
in a period of public review for those who would
like to comment. X9.84 has also been proposed as
a NWI for international standardization in ISO
TC 68.

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  +1-919-832-7008   1625 Glenwood Avenue
f:  +1-919-832-7390   Hayes Barton at Five Points
e:  [email-masked]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------