RSA_SIGN_PKCS1_4096_SHA256 supported?

[dantheperson]

Hello,

I am trying to sign a binary with our certificate that was created with "4096 bit RSA - PKCS#1 v1.5 padding - SHA256 Digest", but SignTool gives me SignTool Error: No private key is available.

is this supported?

In the docs under limitations we have:

• The purpose for the CryptoKey is ASYMMETRIC_SIGN.
• The protection level for the CryptoKeyVersion is HSM.

Should that also state that RSA keys are not supported? I overlooked the section above that talks about ECDSA signing, but it's not clear if the single supported algo listed there is a limitation of EC Signing, or Signing altogether?

I guess i will have to get my certificate reissued for a private key with ECDSA on the P-256 Curve with a SHA-256 digest?

It shouldn't be a problem that the intermediate certificates are using RSA?

C:\certificate>certutil -repairstore My xxx
My "Personal"
================ Certificate 9 ================
Serial Number: xxx
Issuer: CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, O=DigiCert, Inc., C=US
 NotBefore: 04/08/2023 00:00
 NotAfter: 31/05/2025 23:59
Subject: CN=Commercebuild Holdings Inc., O=Commercebuild Holdings Inc., L=Burnaby, S=British Columbia, C=CA
Non-root Certificate
Cert Hash(sha1): xxx
I0804 10:15:58.264925    5864 object_loader.cc:52] INFO: version projects/xm-cloudbuild/locations/us/keyRings/build-ring/cryptoKeys/bc-connector-sign-1/cryptoKeyVersions/1 is not loadable due to unsupported algorithm RSA_SIGN_PKCS1_4096_SHA256

[tdbhacks]

Hello,

Indeed, I am looking at the user guide and see how that could be a little confusing. I will make sure to add a note to our docs before the next release.

Correct, our provider only supports ECDSA on P-256 with SHA-256 for now (EC_SIGN_P256_SHA256 KMS algorithm). It sounds like you will be able to have your certificate reissued, but let me know if you think this would be useful to have and I'll keep this issue open as a feature request for additional algorithms support.

It shouldn't be a problem that the intermediate certificates are using RSA?

I believe that shouldn't matter, but please let us know if that's not the case.

Thanks for using the new CNG provider!

[dantheperson]

Not sure if I can re-issue the Cert with EC, the DigiCert docs say they require RSA 3072 or larger for code signing, no mention of EC. Looks like I have a few more hours talking to the CA support line again to find out more :) So having CNG support RSA 4096 would certainly be useful, given the DigiCert are pushing to RSA. Thanks. https://docs.digicert.com/en/certcentral/manage-certificates/code-signing-certificates/order-a-code-signing-certificate.html#idm46526166580720

[pwae]

as a comment for @dantheperson (but maybe anyone else who finds this).

The page at https://icedev.pl/posts/setting-up-ev-code-signing-google-hsm-fips-140-2/ (which i suspect a lot of people are following for getting a windows app ci/cd process configured for hsm code-signing) does say to use a "4096 bit RSA - PKCS#1 v1.5 padding - SHA256 Digest" key.

However as noted above, it's not supported by this. but a "Elliptic Curve P-256 - SHA256 Digest" key does work as well.

I initially did the same thing (with Digicert) and if you try and reissue the existing certificate with a new CSR.. it will give you weird errors in their console (maybe they have fixed it since i reported it).

If you can actually cancel your certificate and re-purchase it (which you can do easily within the 30 day window), you can then generate a new CSR based on the new Algorithm.

So it an be changed, it may just require them to assist you. (and it will work fine with signing)

[dantheperson]

As the CAs and their resellers are directing people to use RSA, their staff are only experienced with RSA keypairs, and their tooling is based around RSA, i think at this point in time it would still be of great use for the CNG Provider to support RSA.

DigiCert support, after allot of checking did eventually confirm they would accept a p256 or greater EC key for a code signing certificate. But then trying to get the cert Reissued via our DigiCert reseller RapidSSLOnline has been days and days of endless support calls. Part of the problem with their tools check that the key size is 3076 bits which obviously EC keys are not, and so everything has to be handled with manual tickets to the CA instead of APIs to the CA via their tooling (and part of the problem is allot of their staff are just not familiar with Issuing HSM key based certs).

[tdbhacks]

This is all great context, thanks for the writeups @dantheperson & @pwae! Sorry to hear that the lack of RSA support has caused a significant overhead, that's good to know. I will keep this open as a feature request and see what we can do here, thank you.

[davoustp]

Hi @tdbhacks,

I'd like to throw some additional context into this request.

We're currently using the CNG provider with ECDSA, as per documentation, to sign Microsoft Windows deliverables (mainly installers, but also device drivers very shortly).

The digital signatures of the artifacts are properly validated by Microsoft Windows itself, no issue here. In other words, the artifacts are correctly signed using the CNG provider.

However, these installers are still flagged by the Microsoft Windows Defender / Smart Screen system: the user is presented with a warning telling users that the artifact is unsafe.

After calling out to Microsoft, it turns out that Microsoft Windows Defender currently does not support ECDSA signed artifacts as of today (this not documented anywhere as far as I can tell). Microsoft is evaluating adding ECDSA support but without any ETA for now. The only workarounds proposed by Microsoft's support is to submit each and every deliverable to the Microsoft's https://www.microsoft.com/en-us/wdsi/filesubmission website (which must be done ahead of delivery time as this is not instantaneous and Microsoft's engine can take days before recognizing the artifact as safe), or to ask all our customers to add exclusion rules into their security policy (which is obviously not an option!).

The bottom line is that, as of today, using the CNG provider with ECDSA to sign Windows artifacts is not a practical option to sign Windows artifacts. :-(

Obviously, adding support for RSA as requested above would make this all possible again.

Any idea if RSA support could be added in a reasonable timeframe?

[tdbhacks]

Hi @davoustp, thanks for the additional context, that's actually very helpful for prioritization purposes. While I don't have a timeline to share at the moment, this is on our radar and I'll see what we can do here.

Based on your conversation with Microsoft, does Windows Defender support any RSA algorithm? Or more specifically, would adding support for RSA PKCS#1 v1.5 also unblock your use case? I'm double-checking because I'm unfamiliar with the details of Windows Defender support, and solving multiple use cases with a single RSA algorithm would make this feature request more compelling prioritization-wise.

Thank you!

[davoustp]

Hi @tdbhacks ,

Now that we've learned the root cause, we could dig out a Microsoft document about this very issue: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/operations/known-issues#known-issues:

Signatures using elliptical curve cryptography (ECC) aren't supported WDAC signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If you try to allow files by signature based on ECC signatures, you'll see VerificationError = 23 on the corresponding 3089 signature information events. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.

Always better to have an official document to work with. ;-)

Based on your conversation with Microsoft, does Windows Defender support any RSA algorithm? Or more specifically, would adding support for RSA PKCS#1 v1.5 also unblock your use case? I'm double-checking because I'm unfamiliar with the details of Windows Defender support, and solving multiple use cases with a single RSA algorithm would make this feature request more compelling prioritization-wise.

Yes, RSA is supported by MS Defender, as hinted in the MS document linked above. We're currently trying that out with an HSM-backed rsa-sign-pkcs1-4096-sha256 key using the alternate jsign tool, to confirm that once the RSA pub certificate has been approved by Microsoft site above, all artifacts signed using the same key validate and install without a warning.

Will keep you posted.

I'm also attempting to provide a pull request for supporting this use case in the meanwhile.

[davoustp]

@tdbhacks just submitted PR #29 .

[tdbhacks]

Hi @davoustp,

thanks for submitting the PR, that's awesome! It's the first external contribution we receive, so let me test your changes using the internal continuous integration infrastructure we have set up for the provider, and then I'll review the PR. I've taken a very quick look and it seems pretty neat though, thank you!

[tdbhacks]

Big kudos to @davoustp for contributing RSA support to the provider, much appreciated! 🎉

The provider now supports RSA_SIGN_PKCS1_4096_SHA256 at HEAD, but I'll keep this open until the next release as usual. While I don't have an ETA yet, I think this change on its own is probably worth a release, so I'll make the case internally and keep you posted!

[davoustp]

Hi @tdbhacks , any news about a potential upcoming release date? Thx

[tdbhacks]

Hi @davoustp, perfect timing! I was just putting together a small release for CNG after securing the required approvals, this is now part of CNG v1.1 🚀 Thanks again for being the first external contributor of this repo!

Let me know if everything works as expected and I'll close this issue.

[davoustp]

Hi @tdbhacks , I successfully installed and signed an executable with the 1.1 provider and an RSA key, and it passes with flying colors: no more Windows Defender warning! Thanks a lot, you can close this issue! 💯