Verify Signature on received PKIMessage fails

[Sebastian Hempel]

Hi,

I'm using BouncyCastle (bc) to communicate with a CMP handler. The
source code was first implemented using BouncyCastle 1.51. I want
update to the latest version 1.64 of bc. All works well for bc versions
including 1.58. Starting with version 1.59 I get an error verifying the
signature of the received PKIMessage.

I digged down the source code and found the following reason.

A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for the
signature (protection) and a sequence of extra certificates. To
validate the signature I take the PKIHeader and the PKIBody of the
PKIMessage and use the sequence of these to objects to verify the
signature that is contained in the field protection. The verification
sometimes succeeds and sometime fails. Rolling back to version 1.58
everything works fine.

I found out, that the result of getting the header of the PKIMessage
differs from the bytes received from the CMP handler. The field
messageTime of the header was changed by bc when getting / encoding the
field to DER.

There was a change in the class DERGeneralizedTime in 1.59. The class
now contains a method getDERTime to (re-)encode the timestamp. In all
versions before 1.59 the byte array was returned directly. All versions
starting with 1.59 return the result of the getDERTime method. This
method eleminates trailing 0 in the fraction part of the time.

Timestamps directly received from the CMP handler:

20191127144414.20Z
20191127150803.570Z
20191127150848.630Z
20191127151008.290Z
20191127151157.630Z

The method getDERTime returns a different encoding:

20191127144414.2Z
20191127150803.57Z
20191127150848.63Z
20191127151008.29Z
20191127151157.63Z

When calculating the hash for the "new" timestamp there will be no
change to get the same value as using the "original" timestamps.

Is this behaviour expected? Is there a way to get the original encoding
of the header / messageTime to calculate the hash?

Best regards
Sebastian
--
Sebastian Hempel
Veilchenweg 4 · 95195 Röslau · Germany
eMail: [hidden email]
GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7 B49F

[David Hook-3]

Yes, this would be expected, the signatures in the failing cases are not being properly calculated.

Assuming you can't get whoever is generating these to mend their ways, you could provide an alternate verify method which read something like:

private boolean verifySignature(byte[] signature, ContentVerifier verifier)
    throws IOException
{
    ASN1EncodableVector v = new ASN1EncodableVector();

    v.add(pkiMessage.getHeader());
    v.add(pkiMessage.getBody());

    OutputStream sOut = verifier.getOutputStream();

    sOut.write(new DERSequence(v).getEncoded(ASN1Encoding.DL));

    sOut.close();

    return verifier.verify(signature);
}

If I have understood correctly that should work. Note I would still not make this the default - it would be better if the faulty signatures were corrected.

Regards,

David

On 5/12/19 1:30 am, Sebastian Hempel wrote:

Hi,

I'm using BouncyCastle (bc) to communicate with a CMP handler. The source code was first implemented using BouncyCastle 1.51. I want update to the latest version 1.64 of bc. All works well for bc versions including 1.58. Starting with version 1.59 I get an error verifying the signature of the received PKIMessage.

I digged down the source code and found the following reason.

A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for the signature (protection) and a sequence of extra certificates. To validate the signature I take the PKIHeader and the PKIBody of the PKIMessage and use the sequence of these to objects to verify the signature that is contained in the field protection. The verification sometimes succeeds and sometime fails. Rolling back to version 1.58 everything works fine.

I found out, that the result of getting the header of the PKIMessage differs from the bytes received from the CMP handler. The field messageTime of the header was changed by bc when getting / encoding the field to DER.

There was a change in the class DERGeneralizedTime in 1.59. The class now contains a method getDERTime to (re-)encode the timestamp. In all versions before 1.59 the byte array was returned directly. All versions starting with 1.59 return the result of the getDERTime method. This method eleminates trailing 0 in the fraction part of the time.

Timestamps directly received from the CMP handler:

20191127144414.20Z
20191127150803.570Z
20191127150848.630Z
20191127151008.290Z
20191127151157.630Z

The method getDERTime returns a different encoding:

20191127144414.2Z
20191127150803.57Z
20191127150848.63Z
20191127151008.29Z
20191127151157.63Z

When calculating the hash for the "new" timestamp there will be no change to get the same value as using the "original" timestamps.

Is this behaviour expected? Is there a way to get the original encoding of the header / messageTime to calculate the hash?

Best regards
Sebastian
--
Sebastian Hempel
Veilchenweg 4 · 95195 Röslau · Germany
eMail: [hidden email]
GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7 B49F

[Sebastian Hempel]

Thanks for the awnser.

I tried your alternative solution to verify the signature. But this solution also fails on validating responses with a trailing 0 in GeneralizedTime entries. I think the reason for this is, that the method toDLObject in the class ASN1GeneralizedTime also returns a DERGEneralizedTime.

Do you have any links to a document, that describes the conventions / rules howto DER encode a generalized time? I would like to talk to the producer of the CMP handler. It would be easier to give him a kind of refrence about the problen then saying, bouncy castle does not like his encoded PKIMessage. ;-)

Best regards

Sebastian

Am Do, Dez 5, 2019 at 10:12 schrieb David Hook <[hidden email]>:

Yes, this would be expected, the signatures in the failing cases are not being properly calculated.

Assuming you can't get whoever is generating these to mend their ways, you could provide an alternate verify method which read something like:

private boolean verifySignature(byte[] signature, ContentVerifier verifier)
    throws IOException
{
    ASN1EncodableVector v = new ASN1EncodableVector();

    v.add(pkiMessage.getHeader());
    v.add(pkiMessage.getBody());

    OutputStream sOut = verifier.getOutputStream();

    sOut.write(new DERSequence(v).getEncoded(ASN1Encoding.DL));

    sOut.close();

    return verifier.verify(signature);
}

If I have understood correctly that should work. Note I would still not make this the default - it would be better if the faulty signatures were corrected.

Regards,

David

On 5/12/19 1:30 am, Sebastian Hempel wrote:

Hi,

I'm using BouncyCastle (bc) to communicate with a CMP handler. The source code was first implemented using BouncyCastle 1.51. I want update to the latest version 1.64 of bc. All works well for bc versions including 1.58. Starting with version 1.59 I get an error verifying the signature of the received PKIMessage.

I digged down the source code and found the following reason.

A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for the signature (protection) and a sequence of extra certificates. To validate the signature I take the PKIHeader and the PKIBody of the PKIMessage and use the sequence of these to objects to verify the signature that is contained in the field protection. The verification sometimes succeeds and sometime fails. Rolling back to version 1.58 everything works fine.

I found out, that the result of getting the header of the PKIMessage differs from the bytes received from the CMP handler. The field messageTime of the header was changed by bc when getting / encoding the field to DER.

There was a change in the class DERGeneralizedTime in 1.59. The class now contains a method getDERTime to (re-)encode the timestamp. In all versions before 1.59 the byte array was returned directly. All versions starting with 1.59 return the result of the getDERTime method. This method eleminates trailing 0 in the fraction part of the time.

Timestamps directly received from the CMP handler:

20191127144414.20Z
20191127150803.570Z
20191127150848.630Z
20191127151008.290Z
20191127151157.630Z

The method getDERTime returns a different encoding:

20191127144414.2Z
20191127150803.57Z
20191127150848.63Z
20191127151008.29Z
20191127151157.63Z

When calculating the hash for the "new" timestamp there will be no change to get the same value as using the "original" timestamps.

Is this behaviour expected? Is there a way to get the original encoding of the header / messageTime to calculate the hash?

Best regards
Sebastian
--
Sebastian Hempel
Veilchenweg 4 · 95195 Röslau · Germany
eMail: [hidden email]
GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7 B49F

[David Hook-3]

Hmmm... I don't if I'd describe that as a feature, thanks for letting me know, I might look into that one.

You can find the rules in 11.7.3 of https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf it's worth them fixing it - opening the door to arbitrary data for signed encodings is an excellent way to allow people to tamper.

Thanks,

David

On 6/12/19 1:10 am, Sebastian Hempel wrote:

Thanks for the awnser.

I tried your alternative solution to verify the signature. But this solution also fails on validating responses with a trailing 0 in GeneralizedTime entries. I think the reason for this is, that the method toDLObject in the class ASN1GeneralizedTime also returns a DERGEneralizedTime.

Do you have any links to a document, that describes the conventions / rules howto DER encode a generalized time? I would like to talk to the producer of the CMP handler. It would be easier to give him a kind of refrence about the problen then saying, bouncy castle does not like his encoded PKIMessage. ;-)

Best regards

Sebastian

Am Do, Dez 5, 2019 at 10:12 schrieb David Hook [hidden email]:

Yes, this would be expected, the signatures in the failing cases are not being properly calculated.

Assuming you can't get whoever is generating these to mend their ways, you could provide an alternate verify method which read something like:

private boolean verifySignature(byte[] signature, ContentVerifier verifier)
    throws IOException
{
    ASN1EncodableVector v = new ASN1EncodableVector();

    v.add(pkiMessage.getHeader());
    v.add(pkiMessage.getBody());

    OutputStream sOut = verifier.getOutputStream();

    sOut.write(new DERSequence(v).getEncoded(ASN1Encoding.DL));

    sOut.close();

    return verifier.verify(signature);
}

If I have understood correctly that should work. Note I would still not make this the default - it would be better if the faulty signatures were corrected.

Regards,

David

On 5/12/19 1:30 am, Sebastian Hempel wrote:

Hi,

I'm using BouncyCastle (bc) to communicate with a CMP handler. The source code was first implemented using BouncyCastle 1.51. I want update to the latest version 1.64 of bc. All works well for bc versions including 1.58. Starting with version 1.59 I get an error verifying the signature of the received PKIMessage.

I digged down the source code and found the following reason.

A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for the signature (protection) and a sequence of extra certificates. To validate the signature I take the PKIHeader and the PKIBody of the PKIMessage and use the sequence of these to objects to verify the signature that is contained in the field protection. The verification sometimes succeeds and sometime fails. Rolling back to version 1.58 everything works fine.

I found out, that the result of getting the header of the PKIMessage differs from the bytes received from the CMP handler. The field messageTime of the header was changed by bc when getting / encoding the field to DER.

There was a change in the class DERGeneralizedTime in 1.59. The class now contains a method getDERTime to (re-)encode the timestamp. In all versions before 1.59 the byte array was returned directly. All versions starting with 1.59 return the result of the getDERTime method. This method eleminates trailing 0 in the fraction part of the time.

Timestamps directly received from the CMP handler:

20191127144414.20Z
20191127150803.570Z
20191127150848.630Z
20191127151008.290Z
20191127151157.630Z

The method getDERTime returns a different encoding:

20191127144414.2Z
20191127150803.57Z
20191127150848.63Z
20191127151008.29Z
20191127151157.63Z

When calculating the hash for the "new" timestamp there will be no change to get the same value as using the "original" timestamps.

Is this behaviour expected? Is there a way to get the original encoding of the header / messageTime to calculate the hash?

Best regards
Sebastian
--
Sebastian Hempel
Veilchenweg 4 · 95195 Röslau · Germany
eMail: [hidden email]
GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7 B49F