[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[iaik-jce] Bug in verification of X509Certificate



Hello,

yesterday I could not completely verify a certs chain that I got from a CA
as a response to a certificate signing request. While other tools could
verify the chain, IAIK library could not.

The chain consists of a root CA cert, an intermediate CA cert and an end
user cert. Verification of both the self signed root CA cert and the
intermediate CA cert is successfull while verification of the end user cert
is not.

After extensive debugging, I think to have discovered yet another bug in
*both* IAIK-JCE2.51 and IAIK-JCE2.6beta1 (production releases, although I
guess that eval releases have the same behaviour)


I report the X509 ASN.1 specification here:

 Certificate  ::=  SEQUENCE

   tbsCertificate       TBSCertificate,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING  }


where:

 TBSCertificate  ::=  SEQUENCE  {
   version         [0]  EXPLICIT Version DEFAULT v1,
   serialNumber         CertificateSerialNumber,
   signature            AlgorithmIdentifier,
   issuer               Name,
   validity             Validity,
   subject              Name,
   subjectPublicKeyInfo SubjectPublicKeyInfo,
   issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                        -- If present, version must be v2 or v3
   subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version must be v2 or v3
   extensions      [3]  EXPLICIT Extensions OPTIONAL
                        -- If present, version must be v3        }


Now, while debugging the guilty X509Certificate, I see that there is a field
f of type Signature that has the following String representation:

Signature object: MD5/RSA<initialized for verifying>

On the other side, the String representation of the field n of type ASN1
contains the following sequence as its component with index 1 (the
Certificate signatureAlgorithm)

  SEQUENCE[C] = 2 elements
    OBJECT ID = 1.2.840.113549.1.1.5
    NULL = null

which shows that the signature algorithm used to compute the signature is
SHA-1/RSA.

It is obvious that if the field f is used to verify the signature, it will
report an error. It seems that the field f is initialized with the
TBSCertificate signature, which is in fact MD5/RSA, instead of being
initialized with the Certificate signatureAlgorithm, which can be different,
of course.

The problem happens to the end user cert because the outer Certificate
algorithm is SHA-1/RSA while the inner TBSCertificate algorithm is MD5/RSA
and because f is wrongly initialized with the inner algorithm.

The other two certs can be successfully verified because it happens that
both the outer and the inner algorithm are the same (namely SHA-1/RSA)

*********************
CONCLUSIONS
The field f shall be initialized with the outer algorithm (Certificate
signatureAlgorithm) not the inner one (TBSCertificate signature)
*********************


IS THERE A GOOD AND VIABLE WORKAROUND?


Thanks
Raffaello Giulietti
Sobaco Software

--
Mailinglist-archive at http://jcewww.iaik.at/mailarchive/iaik-jce/jcethreads.html

To unsubscribe send an email to listserv@iaik.at with the folowing content: UNSUBSCRIBE iaik-jce