11

Take Verisign's website, for example, which has a root CA with a sha1 hash signature. Am I mistaken with understanding that were one to find a collision, they could impersonate the Verisign root CA, and use that to generate an intermediate and then server cert that would be trusted by a browser or OS.

https://www.entrust.com/need-sha-2-signed-root-certificates/ states:

In short, the signature on a root certificate is not verified as the software trusts the root certificate public key directly. A root certificate is self-signed and is not signed by another entity that has been given authority. The root certificate gets authority through the root certificate program managed by the operating system or browser developer.

and references a Google link: https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash

Assume I am the writer of a new browser - SuperUserBrowser. How else would I trust that the root certificates I ship with my browser are real other than the hash signature?

Why is a root CA with a SHA1 signature "not a problem"?

10
  • To put it simply, SHA-1 hashes, are no longer secure from brute force attacks. Since you don't provide the Google link, I can't comment on it, because I personally don't see Google starting that in recent documentation. If Google really felt that way then they wouldn't have plants to reject SHA-1 certificates when it comes to Chrome. Any certificate using a SHA-1 certificate is a problem
    – Ramhound
    Sep 7, 2016 at 21:59
  • cURl exists for the purposes you describe. You also as the browser allow the OS to determine what certificates to trust.
    – Ramhound
    Sep 7, 2016 at 22:07
  • @ramhound, added google link. Note is near bottom of Article.
    – Chris K
    Sep 8, 2016 at 14:26
  • So that article is out of date in my opionion. It does not match what Google currently is doing with SHA1 certificates. Its not clear if the article has been recently update Q1 2015, lots has changed since then, and I know SHA1 certiicates are being retired by Microsoft which means at least on Windows SHA1 root certificates are indeed effected. I honestly don't understand the "note", explaination of that note, doesn't appear in the article. Makes me wonder if the note is from 2014 and thus not relevant.
    – Ramhound
    Sep 8, 2016 at 15:03

2 Answers 2

12

Am I mistaken with understanding that were one to find a collision, they could impersonate the Verisign root CA, and use that to generate an intermediate and then server cert that would be trusted by a browser or OS.

You are wrong.

As for the security of the signature itself:
To signature of a certificate is used to verify the issuer of that certificate in order to build a trust chain. Since a root CA is the trusted end of the trust chain because it is pre-trusted (i.e. stored in the trust store of the OS) the issuer of the root CA does not need to be verified and thus the signature of the root CA does not matter.

And for using root CA signed with a weak hash algorithm to create new certificates:
To sign another certificate (i.e. creating a leaf or intermediate certificate) you would need to have the private key of the CA. The private key matching the public key of a certificate can not be derived from the signature issued by the issuer of the certificate, even if the certificate is self-signed (i.e. signed using the private key one is trying to get).

Signing a certificate is done by first hashing the essential part of a certificate using an irreversible hash algorithm and then "encrypting" it with the private key of the issuer. To get to the private key needed for signing a new certificate you would need to attack the encryption (RSA or ECC), i.e. find a key which results in the same signature when "encrypting" the hashed certificate. But, since RSA/ECC signing is not broken yet you cannot extract the private key and thus can not generate new certificates using this key. Another way to have a new certificate signed by this certificate would be to create a certificate which results in the same hash value. But while SHA-1 is vulnerable to collision attacks (i.e. find two inputs with same output) it is (contrary to MD5) currently not vulnerable to a preimage attack (find input for given output) you would need. This means that this attack vector fails too.

12
  • So from the root CA I'm not really using the signature to verify, I'm using the actual RSA2048 key encrypted therein to validate the intermediate and end-point? The signature on the intermediate/endpoint is a computational cheap way of verifying trust?
    – Chris K
    Sep 8, 2016 at 14:30
  • @darthcoder: >Yes, this is correct: to verify a signature on a leaf/intermediate certificate you use the public key (RSA, ECC) from the issuers certificate. To create a valid signature you need to have the private key of the issuer. Sep 8, 2016 at 14:32
  • So pub key in intermediate verifies signature of endpoint, pub key in root verifies signature of intermediate, yes?
    – Chris K
    Sep 8, 2016 at 15:57
  • @darthcoder: exactly Sep 8, 2016 at 16:32
  • What is pub key of intermediate using to compute signature of the endpoint? I grok the basics of public/private key, but I guess I'm losing it on assertion of trust - what parts of the endpoing key am I using to compute that hash, using the public key of the intermediate as some derivative component to that? I thank you for putting up with my questions and helping!
    – Chris K
    Sep 8, 2016 at 18:07
3

Am I mistaken with understanding that were one to find a collision, they could impersonate the Verisign root CA, and use that to generate an intermediate and then server cert that would be trusted by a browser or OS.

You are mostly mistaken about being able to impersonate a root CA with just a hash collision as a successful attack on a root CA's certificate would require more steps, as explained in detail below.

You could however, as explained below, successfully impersonate an intermediate CA using just a hash collision.

In short client verifies that the RSA encrypted signature on a certificate matches the RSA encrypted signature that would be generated using the CA's public key to sign the hash of the bytes of the TBS certificate in said certificate. While the CA's public key can be used to verify the the RSA encrypted signature of the hash of the TBS certificate, one would need to know the CA's private key to generate the signature allowing you to impersonate the CA.

Supposing you were able to generate such a hash collision of the TBS portion of a CA root certificate by modifying it to contain a public key for which you know the private key the problem is that your modified CA certificate would contain a different public key than the CA's actual certificate and any clients verifying a certificate signed by the CA will have a locally installed copy of the CA's real certificate. When validating a signed certificate the client will retrieve the signer's thumbprint or signature from the signed certificate and will retrieve the public key of their local copy of that certificate when attempting to verify the signature of a certificate signed by that CA.

Therefore in order to impersonate a root CA and generate an RSA encrypted signature a client would trust you first need to find a collision of the TBS portion of the root CA's certificate from a TBS certificate you generate that contains a public for which you know the private key. You also need to find such a collision that passes RSA signature verification using the CA's public key. At this point you would have a forged certificate with both a SHA1 hash collision and an RSA signature collision. If somehow you accomplished all of this you would finally need to trick a client so they retrieve your forged certificate when looking for the root CA certificate instead of retrieving their locally copy of the root CA's certificate.

In nearly all imaginable scenarios in which you could accomplish all of these things would have much more efficient attack opportunities that didn't involve needing to first find a SHA1 hash collision of a certificate that contains a private key known to you which also generates an RSA encrypted signature collision which then need to trick the client into using for signature verification instead of using the real root CA's certificate that, given the fact the client trusts it, will be stored locally on the client.

Instead a more plausible attack would be to find a hash collision of an intermediary CA's certificate with which you can use to impersonate the intermediary CA to sign certificates. This attack is more plausible for two reasons, first being you can easily get a client to download an intermediary CA's certificate and the second being the hash collision will verify against a trusted CA's RSA encrypted signature so there is know need to try to trick the client into trusting the CA that signed the certificate.

If a client is presented with a certificate from a website signed by an intermediary CA for which it does not have a local copy it will in attempt to download the intermediary's CA from the website which presented said ticket from the website which presented the certificate in the first place. Recalling that a client will take the hash of the TBS portion of this intermediary's certificate and then verify the RSA encrypted signature on this certificate was indeed signed using the public key of a locally trusted CA, or chain of CA's that leads to a locally trusted CA, a successful attack is now simplified to generating a hash collision of the TBS portion of a valid intermediary's CA's certificate.

Once one can replace the public key of a verifiable intermediary CA's certificate with a public key for which the private key is known and then modify other bytes as needed to generate a hash collision with a the verifiable certificate. This this altered certificate can then beused to sign other certificates. Such signed certificate's can then, for example, be installed on a web server along side this modified intermediary certificate. When a client retrieves the certificate it will read the thumbprint of the CA that signed it. If the client does not have this intermediary's certificate installed locally it will download the certificate from the website from it retrieved the certificate it is verifying. The client will then generate the hash of the TBS website's certificate and verify it was digitally signed using the public key in the intermediary CA certificate it downloaded. This process is recursive in that it then creates a hash of the TBS portion of the intermediary certificate it downloaded and reads the thumbprint of the CA that signed the intermediary certificate. It will then lookup that CA's certificate and verify the RSA encrypted signature on the intermediary certificate was generated using the issuing CA's public key to sign the hash of the TBS certificate in the intermediary certificate. Since the intermediary hash of the TBS certificate in the intermediary certificate matches the hash of the original intermediary's certificate and the signature also matches the signature of the original intermediary's signature our modified intermediary CA's cerfitificate will validate. The client will complete the process recursively until it finds a certificate issued by a CA it trusts and which point verification succeeds and we have successfully impersonated the intermediary CA.

NIST and the NSA warned that

"SHA-1 shouldn't be trusted past January 2016 because of the increasing practicality that a well-funded attacker or government could find a SHA-1 hash collision, allowing them to impersonate any SSL website" and Microsoft and Google began warning a year later of connections that use SHA-1.

http://windowsitpro.com/security/your-organization-using-sha-1-ssl-certificates

It's important that the certificate chain be encrypted with SHA-2 certificates. (A certificate chain consists of all the certificates needed to certify the end certificate.) This means that any intermediate certificates must also use SHA-2 after January 1, 2017. Typically, your CA will provide the intermediate and root CA certificates when they provide the SHA-2 certificate. Sometimes they provide a link for you to download the certificate chain. It's important that you update this chain with SHA-2 certificates. Otherwise, Windows might not trust your new SHA-2 certificate.

Root certificates are a different story. These can actually be SHA-1 certificates because Windows implicitly trusts these certificates since the OS trusts the root certificate public key directly. A root certificate is self-signed and isn't signed by another entity that has been given authority.

For the same reason, any self-signed certificate can use the SHA-1 algorithm. For example, Microsoft Exchange Server generates self-signed SHA-1 certificates during installation. These certificates are exempt from the new SHA-2 policy since they aren't chained to a CA. I expect, however, that future releases of Exchange will use SHA-2 in self-signed certificates.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.