Seeing SHA256 as hash algorithm for signature instead of SHA1

[Guest]

This isn't a problem (from a security perspective, obviously), I'm just trying to understand what is going on here. I have a US government CAC/smart-card with certificates and private keys for encryption/signatures, and my X.509 certificate clearly specifies SHA1 with RSA as the hash/signature algorithm that it supports. This is confirmed by some specifications from the card manufacturer. But when I apply a signature to a PDF using my card in Acrobat Reader DC, I don't see a "using SHA1 warning," and when I examine the signature with "signature properties," "advanced properties," it shows me that the hash algorithm used was SHA256. How is that possible? Is the hash just being computed by the Adobe software instead of on my card? If that's the case, why does it matter which algorithm is supported or implemented by the card? Why was Adobe software displaying the "SHA1 warning" to users just a few months ago?

[margueritek]

Hash is used multiple places. Your CAC certificate may be signed with SHA1/RSA, but the PDF is being hashed with SHA256. The SHA1 warning comes when the smart-card driver can't sign a SHA256 hash, which is 32 bytes (256 bits) long, Earlier drivers could only sign a SHA1 hash (160 bits) so Acrobat dropped back to SHA1 for the PDF. The RSA encryption of the PDF hash is independent of the hash used in the certificate itself.

[Guest]

If that's true, I have a follow-up question: It's my understanding that with PKCS #1 v1.5, the hash is padded to a fixed number of bits (1,024 or 2,048, whatever the modulus size for the RSA keys) before being signed. As you said, the signing procedure is independent of the hash function used. So why would a card be able to sign a SHA1 message digest, but not a SHA256 digest?

[margueritek]

It's a combination of the software on the card and the Driver (OS level). Often, updating the driver software will enable SHA256. In other cases, the card or driver insist on doing the hash themselves, but may not have SHA256 capability. When signing with Microsoft OS calls, it's the OS (or card driver) that does the hash. That's because the padding is dependent on the size of the data being encrypted, and the driver does the padding, since the caller doesn't necessarily know the size of the RSA key. Back in Windows XP days, SHA256 wasn't available until SP3. But many 3rd party drivers didn't upgrade their software to handle SHA256 until much later. Wait until we all move to SHA384... or SHA512... or the SHA3 series of hash algorithms.

[Guest · Accepted solution]

This seems relevant: [SOLVED] Why does my smart card / USB token generates a SHA1-based instead of SHA256-based digital s...

"...With the 20045 update, in case the driver is not able to perform the calculation of the required hashing algorithm, Acrobat DC will calculate it by means of internal cryptographic functions..."

Then is there a way to disable this feature and force the hash to be computed by the card/driver?