2

Looking at a potential solution where the thumbprint of a client cert is used to identify individual users and provide access control.

Supposing someone was able to view the thumbprint of a cert installed on a machine, would they be able to create/fake a cert with an identical thumbprint to impersonate another user?

I expect it would be a safe solution where the cert is issued by a trusted authority. That might or might not be an option, but at the moment looking at self-signed certs. (The process for creating, installing and recording the thumbprints of certs is considered secure. The bit I am not sure about is whether someone could just create a self signed cert with the same CN and thumbprint, were they able to view it.)

If the thumbprint approach is not good, is there an alternative way of identifying the certs that would be secure?

4
  • As long as the SHA2 family of hash functions remain unbroken it is not computationally feasable to create a collision, therefore your proposal should be secure. An alternative way of identifying certs is the simplest and most straightforward: simply compare the (DER-encoded) certs byte by byte for equality. Every method has its pros and cons. Oct 28 '21 at 14:53
  • According to this SHA2 certificates still use SHA1 for thumbprints. Therefore perhaps this would be a vulnerability - thesslstore.com/blog/ssl-certificate-still-sha-1-thumbprint
    – Peter
    Oct 28 '21 at 15:01
  • 1
    A cert thumbprint is simply a hash of the entire certificate. Since you are developing the systems you can simply use SHA2 rather than the vulnerable SHA1. Oct 28 '21 at 15:07
  • In your case the attack is not a collision, it is a secondary pre-image attack where SHA-1 is safe ( rather use SHA-512/SHA3-512/BLAKE2/3). see more here
    – kelalaka
    Oct 28 '21 at 18:24
3

It seems that your central question is:

Supposing someone was able to view the thumbprint of a cert installed on a machine, would they be able to create/fake a cert with an identical thumbprint to impersonate another user?

In other words, what you are asking is: can two different inputs produce the same SHA256 hash? This is known as a hash collision*. SHA256 is thought to be highly resistant to collisions; and to date, a SHA256 collision has not been found. See https://crypto.stackexchange.com/questions/47809/why-havent-any-sha-256-collisions-been-found-yet for why this is, and why it is not likely that one will be found anytime soon.

However, it's also worth noting that: in addition to your server verifying that the hash of the certificate that the user presents matches the hash that the server has on file - your server must also verify that the user is in possession of the private key that corresponds with the public key in the certificate. Otherwise, an attacker could simply steal another user's certificate (which is simple to do, because certificates are, by nature, public), and impersonate that user. See Could a stolen certificate show as trusted? for more info.

Edit: *Actually, it's not a collision, it's a secondary preimage. This makes it even more unlikely for such an attack to succeed. Thank you kelalaka for the correction.

2
  • To create a forgery, the attacker needs to execute a secondary pre-image attack. The collision is not related here. Although SHA-1 and MD5 are practically broken on their collision resistance, none of the cryptographic hash functions are broken on their secondary pre-image resistance. This doesn't mean that we can use them, using MD5 and SHA-1 can cause forgeries by the cert issuer though they are not inclined to do. In any case use SHA-512/SHA3/BLAKE3.
    – kelalaka
    Oct 28 '21 at 18:14
  • 2
    You're right, it's a secondary-preimage, not a collision. Thank you. This makes it even more unlikely for this type of attack to succeed.
    – mti2935
    Oct 28 '21 at 18:16
1

A cryptographic Collision is not related to your case;

  • Collision is finding two arbitrary input x and y such that h(x) = h(y)

This is rather secondary pre-image attack;

  • Given a message m and hash of it x = h(m) find another message m' != m such that h(m) = h(m')

If someone sees a cert thumbprint (simply a hash of the entire certificate) they need to find a secondary pre-image attack.

MD5 (corkami) and SHA-1 (shatteref.io)are broken in their collision resistances, whereas none of the Cryptographic hash functions is broken on the secondary pre-images resistances. This may be why some CA's still using SHA-1, bad for them.

In any case, we should not use MD5 or SHA-1 since a malicious cert issuer can use the collision attacks to create two different valid certificates.

One can use SHA-512, SHA3-512, or the faster on BLAKE2. Both are even secure against Grover's quantum attacks.

-1

Any hashing algorithm is subject for spoofing, because output size if fixed while the number of possible inputs exceeds the number of hash combinations. Whether it is MD5, SHA1 or SHA2, or something else. Any hash algorithm is vulnerable to collisions by definition.

The problem is how it is likely in practice. For SHA2 it is statistically unlikely (if you try to brute-force input in order to get known output).

cert with an identical thumbprint to impersonate another user

and this is a bit unrelated, because thumbprints are never used to identify someone. For example, if you use client certificate for Kerberos auth in Active Directory, then certificate content and chain is examinated before the certificate is linked to some entity in account databse. And no authentication provider would link only thumbprint to account because of maintenance questions.

3
  • Thank you for your answer. You said that a thumbprint would never be used to identify someone. However we are looking at using it to do so indirectly - it would identify the cert which would be associated with a company and role. I understand that this would need to be updated when the cert was reissued. However would there be additional issues with this approach?
    – Peter
    Oct 28 '21 at 15:00
  • That maintenance efforts outweighs the simplicity of thumbprint mapping. And often users may have multiple auth certificates on different devices (say, on laptop, on PC, on phone) and all they should work. It will work for a small user database, but will be a nightmare in enterprise-level.
    – Crypt32
    Oct 28 '21 at 15:03
  • To create a forgery, the attacker needs to execute a secondary pre-image attack. The collision is not related here. Although SHA-1 and MD5 are practically broken on their collision resistance, none of the cryptographic hash functions are broken on their secondary pre-image resistance. This doesn't mean that we can use them, using MD5 and SHA-1 can cause forgeries by the cert issuer though they are not inclined to do. In any case use SHA-512/SHA3/BLAKE3.
    – kelalaka
    Oct 28 '21 at 18:14

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.