Understanding certificate security

Question

I am reading Computer Networks by Tanenbaum and Weatherall. In chapter 8 they describe secure communication using public key exchange via certificates. They describe a situation where Alice is sending messages to Bob and a man in the middle (Trudy) is trying to intercept Alice's messages. They describe what Trudy can do to try and trick Alice into believing she is communicating with Bob. The conclusion they draw is she cannot.

However there is one situation not covered:

Suppose that Bob has a certificate containing his public key and a hash signed by a Certification Authority. He makes this certificate available to anyone as is common practice

Trudy gets Bob's certificate and modifies it replacing Bobs public key with her own.

Trudy intercepts Alice's request for Bob's page. Trudy sends back a fake page to Alice containing the modified certificate. When Alice get's this fake page she sees that when she runs the SHA-1 algorithm on the certificate, she will get a hash that agrees with the one she gets when she applies the CA’s public key to the signature block (the signature block has not changed from Bob's original). So Alice encrypts her message to Bob using Trudy's public key (Trudy put this in the certificate when she modified it). Trudy can now decrypt and read the message she intercepts from Alice.

Will the above scenario work?

score 7 · Answer 1 · edited Mar 17 '17 at 13:14

7

Hashing the certificate produces a unique fingerprint for the certificates contents, including name, dates, signer, key, everything. If you change any part of the certificate, (which includes replacing the public key with your own) then the stored hash no longer matches the contents.

So, you say you replace the hash as well? Not quite: each certificate is signed, and signed means that the hash is encrypted with the signer's private key. You can't replace the hash without replacing the signature (because the hash is part of the signature), and you can't replace the signature without re-signing the cert, and you can't re-sign the cert unless you have the signer's private key.

So the only party who could actually replace Bob's key with Trudy's is the CA. And the whole point of the PKI is that you trust the CA to not do that. If you can't trust the CA, then the whole system falls apart.

Real World Note
Note that this is precisely the problem with the global SSL PKI we have today. We don't know if we can trust the CAs anymore. Specifically, we don't know if powerful organizations (governments, etc) are pressuring CAs into signing illegetimate certificates. It's very possible that the Chinese military or US NSA has valid, signed certificates for Google, Facebook, or any other organization. This is where certificate pinning comes in to play. And in fact, Chrome and several other browsers by default pin certicates for Google and other popular services, so even a valid certificate isn't accepted unless it's a specific valid certificate, or signed by a specific CA.

edited Mar 17 '17 at 13:14

Community

1

answered Oct 24 '13 at 17:02

tylerl

82,225
25
148
226

There is also no need for governments to pressure Root CAs, as they can (and should) be public Root CAs for their own public government infrastructure so that *their* sites can be pinned to *their* CA. The transparent interchangeability of CAs is a bug treated as a feature, and is **broken to the core**. Certificate pinning is of limited effect within such a broken model as browsers obviously can not pre-pin every website on the internet and any declaration of pinning by a website would itself need to validated somehow. – LateralFractal Oct 24 '13 at 23:37
@LateralFractal the whole think can (should) be solved by by securing DNS and putting the key signature there. No CA, no trust. There's the root DNS key, but that's guarded closer than missile launch codes. – tylerl Oct 24 '13 at 23:46
A fully centralised trust hierarchy is probably not possible this side of a global (hopefully democratic) world government. A decentralised alternative for our current geopolitical landscape would be a multi-sig solution involving multiple antagonistic government CAs (security council + iceland, venezuela, north korea, etc). Chances are vanishing small that all governments in the multi-sig would collude except for real global pariahs. – LateralFractal Oct 24 '13 at 23:53
@LateralFractal which is why the root key is broken into so many pieces, all required to be present to be used. – tylerl Oct 25 '13 at 00:05
I'm not that familiar with next-gen secure DNS; so I'll assume it isn't replacing one trust problem with another :-) – LateralFractal Oct 25 '13 at 00:45
@LateralFractal **everything** is just replacing once set of problems with another. The question is, which problems do you prefer? – tylerl Oct 25 '13 at 06:46
I dunno. A v4 X.509 that includes true multi-sig support would be my preference. – LateralFractal Oct 25 '13 at 07:20

score 2 · Accepted Answer · answered Oct 24 '13 at 18:34

The certificate does not contain the hash; it is, somehow, the other way round.

It may be simpler to skip the notion of "hash" and talk about the signature directly. The contents of Bob's certificate (in particular, Bob's name and Bob's public key) are signed by the CA. Trudy cannot modify one bit of it without invalidating the signature; and Trudy cannot fix the signature afterwards because the signature algorithm is cryptographically strong, and Trudy does not know the CA private key. This is what avoids the problem you are alluding to. Indeed, a certificate is immutable.

Now, where does the hash function fits in that ? It is a technical component of the digital signature. When some data is to be signed, the data is first hashed, resulting in a hash value which is then used as input to the rest of the signature algorithm. We do this because signature algorithms use mathematical objects with some heavy structure which cannot accommodate data of arbitrary length; a hash value has a fixed, short size (e.g. 20 bytes if the hash function is SHA-1), so the signature algorithm works well on that. Using an intermediate hash function is also safe because the hash function is second-preimage resistant. This is a technical term which means that Trudy cannot modify the data without modifying the hash value as well (and thus invalidating the signature).

There is no "hash value" field in the certificate, which could be changed independently; instead, the hash value is dynamically computed over the complete certificate (that is, everything that is signed). This computation is done by the CA when it signs the certificate; it is done again by whoever verifies the signature.

(To be precise, the presence of this hash function is also important for the security of some signature algorithms, e.g. DSA, but that's technical. Let's not obscure the issue.)

Understanding certificate security

2 Answers2