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

(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.

  • 3
    please: Signing isn't encrypting with private key.
    – SEJPM
    Jul 16, 2015 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, 2015 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.
    – miesch1
    Jul 16, 2015 at 17:09
  • @miesch Signing is also not encrypting a hash with the public key. Signing and encryption are different operations.
    – cpast
    Jul 16, 2015 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 crypto.stackexchange.com/questions/12768/…
    – miesch1
    Jul 16, 2015 at 17:40

2 Answers 2


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.



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.

  • Awesome! Thanks for the tip, that would help in our situation.
    – miesch1
    Jul 23, 2015 at 2:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .