Skip to content

Possible incompliance with RFC 8017 on RSA PKCS-v1.5 validation #2273

@bsanchezb

Description

@bsanchezb

Hello,

It looks like BouncyCastle does not implement a strict validation of RSA signatures according to the requirements stated in RFC 8017.

In particular, the issue concerns the DigestSignatureSpi class, that implements a fallback mechanism for, in fact, incorrectly encoded signatures, such as the ones omitting within the signed DigestInfo the NULL parameter field of the AlgorithmIdentifier attribute.

Please see the RFC 8017:

A.2.2. RSAES-PKCS-v1_5

The object identifier rsaEncryption (see Appendix A.1) identifies the
RSAES-PKCS1-v1_5 encryption scheme. The parameters field associated
with this OID in a value of type AlgorithmIdentifier SHALL have a
value of type NULL. This is the same as in PKCS #1 v1.5.

It also lists the definitions for every digest algorithm scheme:

digestAlgorithm identifies the hash function and SHALL be an
algorithm ID with an OID in the set PKCS1-v1-5DigestAlgorithms. For
a discussion of supported hash functions, see Appendix B.1.

  DigestAlgorithm ::= AlgorithmIdentifier {
     {PKCS1-v1-5DigestAlgorithms}
  }

  PKCS1-v1-5DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
      { OID id-md2        PARAMETERS NULL }|
      { OID id-md5        PARAMETERS NULL }|
      { OID id-sha1       PARAMETERS NULL }|
      { OID id-sha224     PARAMETERS NULL }|
      { OID id-sha256     PARAMETERS NULL }|
      { OID id-sha384     PARAMETERS NULL }|
      { OID id-sha512     PARAMETERS NULL }|
      { OID id-sha512-224 PARAMETERS NULL }|
      { OID id-sha512-256 PARAMETERS NULL }
  }

Thus, a correctly encoded DigestInfo shall contain the NULL parameter of the AlgorithmIdentifier field, as shown in the example below:

SignatureValue : Rwu3d2y/U82j1y0ctJqXO/ODAFgoTdFlxUoiwqN91KH2LTn2aCZ8U5JNO4cAJdtMWxqpAddT0pmrNZIYIFMV0qLeVawhDVyUAYVj6/CFAfpAUjn8NV9FTGq8pGjQpidMAyODb363uG33TJebsa5useVerIhZzhgX17PvLLlbOahzzH4alDnM3+joIWU/8uytGrrgNqLF4RYOHDG2TBK3FQ8LYsZtVHdtSkFy7gw1nzD67eRciA2De5iWqxq3W4PEt3B845Kv+i9NZoGD0ss/3huFMjNU6MN4shhha6U9hcwLThNYqX0LGsUJKAmh4ZQDc7woVJA0GlC2r+inDvXb7g==
Public Key : MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtwrrGyhs4cyn01L1H24U5CzAX5/OY4j34JrxV2zQaHEYHl0l5JIKitzSqKOBkjKt9Mvd6BmYv69nbErqTVmJmVrVHvQrCS4MvuXqhwB/vuzzX4P3rTrZiC/6thS6OaaWOHiYj2OB/qBmTqrstHgbvdqSW4cZW4RzpW/NS7mRI5PQoXBeNM/YkNyghoT/jjHUn0+cwVUMX72DluZ+ONPWJjtTZefOszgufx82RmZ1c5m4hRpp9S5QP5hQT5i667B05uNa9U/MD1D4yw+6sg4XlIRq4t4KRaTFzHEb1ioIPsiO65r4LWwWqvyEIN35mdlS+5oJVVvEWkctIi6ki0l4swIDAQAB
Decrypted result (b64) : MFEwDQYJYIZIAWUDBAIDBQAEQFVT9QQ6+L8Afq8FHS3WQoHbW9/65BwAzpoGJVxweSuHjf2w1+XP03I8wrWncpBHfe18egg8voonmKpXfhO0DMg=
Decrypted result (string representation) : [[2.16.840.1.101.3.4.2.3, NULL], #5553f5043af8bf007eaf051d2dd64281db5bdffae41c00ce9a06255c70792b878dfdb0d7e5cfd3723cc2b5a77290477ded7c7a083cbe8a2798aa577e13b40cc8]

While BC intentionally (?) accepts signatures signing a wrongly encoded DigestInfo payload, omitting the NULL parameter, see an example of a such signature below:

SignatureValue : LWHJa8xbrrMvMtkKHBmIAH7k2kFt2N/dxqEptD5YdUDlhyo36XLmZQLBV4GTGA2PrL9i3xf/DNPbLT28CZfLoqxkJTOvTCCQ8aNzMZXh6tY8l0ukr1bqH+xboYYOojREBsEO0+QAKb7nOyj0ZiKRc52zepFvpSUFIkohCLNJJcAUIUI1R0Lv6Mipm2dq3vCCVdH80XLvTOwnnUgRjYk/QZC4PwPIgynkTk7m9RjvScqkf9+LKESopGfida/QyTtcJnAx8OaHmKZPapWrIhXAB3vfRsP9NDsxZTXk778zcsurMN2BkccMC4oFcVKt3iqlka+wg/gt8OGYJRmsi9fXvQ==
Public Key : MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4GdXNjzgapx6lLFUjZJS5f5rDIQE8fDr2ehYLFJSRNVOGGs/QtlxNYpsqK5K69qxPNal/gBns09vX3XCSUbKZYDXJmldNM5tmACL4O9qFCG3/u1ZCSxF8NYVu3TJ+Pwq13e51cu0MkMXdyRvr5fHE7nLuqSnrXirzTXgrQv0MaMOFtC2mplxKNGxlr9fbOMiC3rKaCoWSQwB4s9XxqdYspmJuDdH5hXlY6z/OFhlE0L6NjNDwCuOTOOucOw6Qog6PNHWtonfGS5HHYBPGX6d083dAqR8YtV0Si8qZpvrL4pMEBUpzTeQzqk0m9Vw+ZftK5jZq7qPu9Nt1v0AkdVhwQIDAQAB
Decrypted result (b64) : ME8wCwYJYIZIAWUDBAIDBEBsbCUYxKRiYfPZARXezD4vcqGfh2fVWJgrmHGwVHv37cOMLf+AWQ+Pg5Ke30fbBXttEjH18U9VioeRxR1rFAnF
Decrypted result (string representation) : [[2.16.840.1.101.3.4.2.3], #6c6c2518c4a46261f3d90115decc3e2f72a19f8767d558982b9871b0547bf7edc38c2dff80590f8f83929edf47db057b6d1231f5f14f558a8791c51d6b1409c5]

This lenient behavior on validation causes ambiguity on validation within security critical systems relying on the BouncyCastle provider for cryptographic validation.

I do not know how many incorrectly created signatures are in circulation today, but I think there shall be a way to enforce the strict validation mechanism, whether it is required by the organization policy.

KR,
Aleksandr

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions