PKCS#7/CMS verify reports bad signature

Matt Caswell matt at openssl.org
Tue Apr 2 08:44:30 UTC 2019



On 01/04/2019 22:23, Steffen wrote:
> Hello,
> 
> I believe that I have narrowed the problem down to one specific version of
> OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.

Using the cert/data files you provided me off-list (thanks), I was able to
confirm the above and narrow it down further to the following commit:

commit b71079a375116a8a52ed493afcd8f69cb08c195a
Author: David Benjamin <davidben at google.com>
Date:   Sat Aug 20 13:35:17 2016 -0400

    Implement RSASSA-PKCS1-v1_5 as specified.

    RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
    the DigestInfo struct and then compare the result against the public key
    operation result. This implies that one and only one encoding is legal.

    OpenSSL instead parses with crypto/asn1, then checks that the encoding
    round-trips, and allows some variations for the parameter. Sufficient
    laxness in this area can allow signature forgeries, as described in
    https://www.imperialviolet.org/2014/09/26/pkcs1.html

    Although there aren't known attacks against OpenSSL's current scheme,
    this change makes OpenSSL implement the algorithm as specified. This
    avoids the uncertainty and, more importantly, helps grow a healthy
    ecosystem. Laxness beyond the spec, particularly in implementations
    which enjoy wide use, risks harm to the ecosystem for all. A signature
    producer which only tests against OpenSSL may not notice bugs and
    accidentally become widely deployed. Thus implementations have a
    responsibility to honor the specification as tightly as is practical.

    In some cases, the damage is permanent and the spec deviation and
    security risk becomes a tax all implementors must forever pay, but not
    here. Both BoringSSL and Go successfully implemented and deployed
    RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
    this change should be compatible enough to pin down in future OpenSSL
    releases.

    See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

    As a bonus, by not having to deal with sign/verify differences, this
    version is also somewhat clearer. It also more consistently enforces
    digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
    wasn't quite doing this right.

    Reviewed-by: Kurt Roeckx <kurt at roeckx.be>
    Reviewed-by: Rich Salz <rsalz at openssl.org>

    GH: #1474
    (cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836)

Implemented via this pull request:
https://github.com/openssl/openssl/pull/1474

So, based on the above description, it appears that older versions of OpenSSL
were unduly lenient in tolerating incorrectly formatted signatures. As a
security hardening measure that tolerance was removed. If you want to know more
then David Benjamin may be able to expand.

Matt



More information about the openssl-users mailing list