-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
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