1

The diagram below illustrates chaining digital certificates up to a publicly trusted Root Certificate:

Image
(source: globalsign.com)

I have been researching how trusted root authorities (such as GlobalSign or Verisign) are used to authenticate someone's public keys to identify that person as a trusted publisher. I think I am missing something, please let me know if I am misunderstanding something here.

So digitally signing involves hashing some data (message digest) with a trusted publisher's private key. Consumers of that data can use the trusted publisher's corresponding public key to verify the hashed data. Verifying the trusted publisher's public key (certificate) all the way up to a trusted root authority establishes the trust that the trusted publisher is who they say they are, correct?

In order for this chain of trust to work, I understand the importance of keeping private keys private. But I fail to see how this offers any trust or security on a compromised machine.

Say I am a malicious attacker who is trying to spoof a user on a machine I am already in control of. Like any good malware, I am going to want the user to think what they are doing is trusted. So it seems all I need to do is blow out any relevant valid certificates in the Trusted Root CA Windows Certificate Store and replace them with bogus self-signed certificates that appear to be valid. I could even re-create a chain of trusted certificates, such as in the image above.

This doesn't seem too far fetched to me yet. So, to complete the spoof, I would have to intercept the valid data and re-sign it with my bogus publisher certificate, "trusted" all the way to the "root CA". This seems far easier than stealing a publisher's private key.

EDIT: Is there a way to protect against such a targeted attack? For my very specific application, I need to know for sure that a cert is trusted, but that may not be possible on a compromised machine.

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
miesch1
  • 13
  • 3
  • 3
    please: **Signing isn't encrypting with private key**. – SEJPM Jul 16 '15 at 16:54
  • 1
    sure: manipulating the trust store is *bad*. But this only affects the targeted user. If you steal the private key, you can impersonate that person to *everybody*, i.e. to all clients / servers. – SEJPM Jul 16 '15 at 16:56
  • Thanks for the replies. I said signing is encrypting a hash with a private key, not encrypting the data. I am trying to determine how to protect against this attack vector, as my situation I'd concerned about targeted users. Will update the post to indicate this. –  Jul 16 '15 at 17:09
  • @miesch Signing is also not encrypting a hash with the public key. Signing and encryption are different operations. – cpast Jul 16 '15 at 17:22
  • Sorry for the confusion. I never said signing is encrypting a hash with a public key. Signing does involve encrypting a hash of the data with a private key, tho. See http://crypto.stackexchange.com/questions/12768/why-hash-the-message-before-signing-it-with-rsa – miesch1 Jul 16 '15 at 17:40
  • [These answers](http://crypto.stackexchange.com/a/2124/23623) may answer why everyone "dislikes" "encrypting with private key". – SEJPM Jul 16 '15 at 18:24
  • Also see [this answer](http://security.stackexchange.com/a/68836/18411). That said, the question isn't about signatures, so I'll leave it at this. – cpast Jul 16 '15 at 20:07
  • OK. I see what you guys are saying. As @cpast mentioned, this aspect is not important in this discussion. I have updated the question to avoid this ambiguity. – miesch1 Jul 16 '15 at 23:24

2 Answers2

3

That does indeed severely compromise security. There are no ifs, ands, or buts about it: if you have CAs that your computer trusts but are not the real ones, anything that relies on the OS store won't work (I believe Firefox has its own certificate store, but then that has to stay secure). See: the Superfish debacle, where the problem was that a hardware manufacturer added a certificate into the Windows cert store and also included the private key on ad software shipped with the computer.

The reason this isn't such an issue in practice isn't that it's easy to mitigate; it's that it doesn't really let an attacker do anything they couldn't do anyway. Modifying the certificate store for a user requires access to that user's account or an administrative account. Modifying the certificate store systemwide requires access to an administrative account. On a machine where an attacker has this level of privilege, they can already access whatever your user account is doing. An attacker with an admin-level compromise can just install a keylogger and screen viewer.

Any security system has a threat model, which is the attack scenario it is designed to defend against. A compromised client is not part of the TLS threat model: the model only posits an attacker who can manipulate network traffic (including redirecting it to his own machines to serve up bad content). TLS is not intended to secure against a compromised machine on either end, nor is it capable of doing so.

In general, it is extremely difficult (or maybe theoretically impossible) to achieve security on a compromised machine. The correct approach is to prevent a compromise or detect and handle it, not to try to achieve security despite it.

cpast
  • 7,263
  • 1
  • 30
  • 35
0

Use RCC

On Windows, there is a small root certificate scanning tool called RCC that you can use to detect if your root store has been compromised. This won't prevent a malicious certificate insertion, but for detection purposes it is fine.

Community
  • 1
John Blatz
  • 991
  • 10
  • 17