Changes Coming Soon to Code Signing Certificate Security Requirements
The CA/B Forum Is Mandating That the Minimum Key Size for Code Signing Certificates Increase to 3072 Bits on June 1, 2021
Changes are coming soon to the world of code signing certificates. Starting on June 1, 2021, the minimum key size for code signing certificates will increase from 2048 bits to 3072 bits. The change, mandated by the CA/B forum, is meant to boost certificate security and better prepare for future technological advancements that will result in increased computational power.
Code signing certificates are employed by software developers to digitally sign their products – whether it be applications, drivers, executables, or other programs. The signature acts as a means for end users to verify that the product they’re downloading and installing is actually coming from the software’s creator and that the code hasn’t been altered or tampered with by a third party while in transit.
Signatures can be valid for long periods of time (we’re talking several years), and in the meantime, advances in technology can leave these older, weaker crypto keys vulnerable to brute force attacks. Therefore, one way of future-proofing these signatures is to increase the minimum key length used by code signing certificates.
So, what does key length mean exactly? What does the change entail, exactly? And most importantly, what effect will this have on your current and future certificates?
Let’s hash it out.
What Does Key Length Mean?
Before we get into the specifics of the key length change, let’s first take a quick look at what key lengths mean, what purpose the key serves, and how their strength changes over time.
The key length is the number of bits in the certificate’s associated key pair (used for cryptographic functions such as signing and encryption). Basically, it sets the upper limit on the security of the algorithm, and a larger key means a stronger digital signature. Any algorithm can theoretically be broken by a brute force attack with a strong enough computer, and an increase in key length means the processing power required to crack it will also go up.
The increase isn’t linear either – for example, when the size of an RSA key is doubled, the associated decryption task will be exponentially slower. So ideally, the minimum required key length should be long enough that it requires a degree of computational power that doesn’t exist yet in the real world to brute-force it (and ideally, brute-force cracking will remain infeasible for a significant period of time).
After all, there are plenty of software products that are still in widespread use years after their initial release. It certainly wouldn’t be a good thing if attackers were simply able to wait a bit for processor technology to improve and then be able to brute-force the code signing certificate. Then they’d be able to maliciously tamper with the application without anyone knowing. That’s the primary motivation behind this latest key length change – to future-proof our current digital signatures and ensure that they will still be able to hold up for years to come.
What is the Change to Code Signing Key Lengths, Exactly?
Right now (prior to June 1) the minimum key length for a code signing certificate is 2048 bits. Currently, 2048-bit RSA keys are considered secure, while 1024-bit keys are no longer considered sufficiently safe. It wasn’t that long ago that 1024-bit keys were the standard – for example, the key length requirement for SSL certificates jumped from 1024 bits to 2048 bits just over eight years ago. Therefore, it’s perfectly reasonable to assume that 2048-bit keys won’t cut it in five to ten years from now.
The National Institute of Standards and Technology (NIST) felt the same way. They issued NIST SP 800-57 in May of 2020, with the main takeaway being that 2048-bit RSA keys are not recommended for use past the year 2030.
The Certification Authority Browser Forum, which is a group comprised of certificate authorities, browser and operating system vendors, and other PKI-related application vendors, is in charge of key length changes. After analyzing the NIST recommendations, they voted in early 2020 to go ahead with the key length increase, and after a few delays (mainly to allow vendors more time to update their infrastructure and thus be able to issue the new 3072-bit certificates) settled on a June 1, 2021 implementation date.
How Does This Impact Code Signing Certificate Users?
Certificates issued after June 1, 2021 will automatically chain to 3072-bit root certificates, so end users don’t need to worry about buying a different product or specifying a 3072-bit trust chain.
If you have existing code signing certificates, then you can still use 2048-bit versions as long as they were issued before June 1, 2021.
If you are re-issuing or renewing your existing certificate after June 1, 2021, then when you go to generate your CSR, you’ll need to make sure that you are specifying 3072-bit RSA and not 2048-bit.
Even if you have a 2048-bit certificate that was issued before June 1, we still recommend making the switch to 3072-bit by re-issuing your certificates as soon as possible.
How Do I Find My Current Key Length?
Not sure of the key length of some of your existing certificates? Checking the key size is easy and can be found in just a few clicks. For example, on Windows, you just need to navigate to the certificate file, right click on it, and select “Properties”. Then, go to the “Details” tab and you should see a field that says “Public key”. It should say “RSA” and then in parentheses have the specific key length in bits, as seen below:
If you see 2048 bits there, then you should consider re-issuing your certificate off one of the new 3072-bit roots after June 1.
The Key to Secure Code
While the key length increase isn’t an insignificant change, it’s one that shouldn’t have a detrimental impact on end users. Software developers need to be aware of the change, especially when it comes to the renewal of existing code signing certificates. The rest of the work is being done behind the scenes by the certificate authorities and operating system vendors. All in all, it’s a small price to pay for the increase in security that the change is providing, keeping our applications safe from meddling attackers for years to come.
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownPayPal Phishing Certificates Far More Prevalent Than Previously Thought
in Industry Lowdown