How Do Compromised Signing Certificates Affect Me? And How Do I Stay Safe?

In recent months, we’ve seen a couple of situations where problems at
certificate authorities allowed unauthorized, authoritative signing certificates to be created or existing signing
certificates to be used in ways that were not legitimate. In both cases, we’ve seen the certificate authorities that are involved quickly respond by revoking the certificates and push that revocation in high priority updates to as many computers as possible.

Great. But what’s all that gobbledygook mean?

For example, you could visit a website via https (thinking that by using https, you were guaranteed to be visiting the website you thought you were), but in fact, you were not.

Rogue signing certificates don’t cause this problem alone, but they can
remove one of the important checks that we all rely on and perhaps even take for
granted.

Don’t panic, because it’s not common, but don’t ignore it either, because
when it does happen it’s serious.

To understand this whole chain of events, we need to – at least at
a high level – understand how digital signatures and certificates work, how
they relate to websites, and perhaps most importantly, how they are
legitimately created.

And it all starts with a tiny refresher in one important form of encryption,
and the importance of keeping secrets.

Because that’s all just a little lengthy, I’ll begin with the bottom line.

]]>
<![CDATA[

Certificates: the bottom line

For the average computer user, it actually all boils down to a very simple
statement that we hear all the time:

Keep your system up-to-date

As I mentioned earlier, rogue certificates enable certain types of malicious
attacks. However, your system has mechanisms to effectively “de-authorize”
certificates that are known to be bad. But of course, it can only de-authorize
those that it knows about and that means making sure your system has that
knowledge.

In the case of the most recently detected scenario, Microsoft created an
out-of-cycle update that was quickly made available to all affected
systems.

Use Windows Update to keep Windows as up to date as possible. Keep your
browser as up to date as possible.

That’s the single best defense against this particular type of
vulnerability.

Now, on to what the fuss is all about…

Asymmetric encryption

Normally when we think of encryption, we think of supplying a single password
(or pass-phrase) to encrypt data and then using that same password to decrypt
the data. As long as you somehow know the appropriate password, you can decrypt
the data.

That’s referred to as symmetric encryption because
of its symmetry – you use the same password at both ends of the process.

As you might infer from the name, asymmetric encryption works
differently. The process begins by mathematically generating a pair of
passwords.

You cannot use just anything you like, but the password must be computed in a
special way that corresponds to the encryption algorithm to be used. The
results look nothing like passwords at all; they’re simply large numbers, so
instead of calling them passwords, they’re called “keys” and the two generated
together are called a “key pair.”

The magic is simply this: given a pair of keys A and B.

• Data encrypted with key “A” can only be decrypted with key “B”
• Data encrypted with key “B” can only be decrypted with key “A”

Read that again; while simple, it’s critical to this whole process. Here’s
what trips most people up:

• Data encrypted with key “A” can NOT be decrypted with key
  “A”.
• Data encrypted with key “B” can NOT be decrypted with key
  “B”.

Encrypt with one, decrypt with the other. That’s the only way it works.

To me, it’s all really magical, although I realize that it’s just complex
mathematics at work here.

Public versus private

In practice, when asymmetric key pairs are created, one is designated the
“public” key and the other is designated “private,” forming the basis of
Public Key
Cryptography. This enables two important uses of asymmetric encryption:

• If you encrypt something with my public key, then you know that
  only I can decrypt it using my private key. This allows you to
  securely send encrypted data to me that no one else can decrypt.
• If I encrypt something with my private key, anyone can decrypt it
  with my public key and in doing so, they then know that only I could
  have encrypted it. This allows me to prove that I was the source of that
  data because no one else could have encrypted it.

What’s important in this scenario is that the private key be kept
private. If my private key were to fall into the hands of someone
else, then they could decrypt data that was intended only for me and they
could claim that I had encrypted data, which I had not.

That’s why private keys are considered very high security items. I keep mine
on a Truecrypt-encrypted drive – yes, my private key used for asymmetric
encryption is protected by Truecrypt’s symmetric encryption using a Very Long
Password. My public key, on the other hand, is public.

Digital signatures

One more concept into the mix: the hash.

A hash is nothing more than a number calculated from other numbers.
Remember, however, that in computers, everything is a number. For example, the
text in this very paragraph is nothing but a series of numbers, one for each
character including spaces and the like.

A simple hash might just be the result of adding up all of those numbers.
Naturally in practice, hashes are significantly more complex than that.
Specifically, hashes used in cryptography need to have some very important
characteristics:

• Any change however small in the data being hashed should result in a large
  change in the resulting hash.
• It should never be possible to reconstruct the original data from its hash
  value.
• It’s not feasible to craft data that, when hashed, would generate a specific
  hash value.

What does this all have to do with signatures? Once again, the math is hard,
but the concept is very simple:

1. I create an email message (for example – any file or document would
   suffice).
2. After I’m done creating it, I run the email message through this hash
   algorithm to generate that hash value number.
3. I encrypt the hash value with my private key.
4. I include the encrypted hash value when I send the message.

That’s known as a digital
signature.

What does all that get me? Confirmation of my identity as the sender and
confirmation that the message was not altered after I signed it.

Here’s how:

• If the encrypted hash value can be decrypted with my public key, then
  only I could have encrypted it with my private key. It must have been
  me.
• If the decrypted hash value matches the hash value calculated from the
  message by the recipient, then the message hasn’t changed since I sent it.

With all those basics out of the way, we can start talking about
certificates and websites.

Certificates

It’s an oversimplification, but a certificate is not much more than a public key with
some additional data that has been digitally signed by a third party.

For example, if someone hands you a public key and says, “This is Leo’s
public key,” you are trusting them to be honest and actually hand you Leo’s
public key.

On the other hand, if that public key is also digitally signed by someone
else, then you don’t have to only trust the person handing you the key – by
validating the digital signature of a certificate, you’re also validating that
the third party that signed it also claims it’s Leo’s key.

If you trust that third party, then you can trust that it’s Leo’s key.

That’s what happens with https websites.

When you visit an https web site – I’ll use my own https://secure.pugetsoundsoftware.com/ as an example – one of the
first things that the website does is give the browser its public key in the
form of a certificate.

Now, without any additional validation, that actually tells you very little.
The site claims to be secure.pugetsoundsoftware.com, and the public key matches
what the site is using as its private key, but it could have been set up by
anyone.

However, my certificate is signed. I gave my public key to GoDaddy
who performed some basic validation that I was who I claimed to be, and they in
turn signed my certificate using their own private key. (This is all that
“purchasing an SSL certificate” really boils down
to).

Thus, if you trust GoDaddy – or rather, if your computer trusts GoDaddy –then you can trust that my certificate is valid and that the site you just
connected to – secure.pugetsoundsoftware.com – really belongs to me.

The same is true for signed software. A digital signature can be included
with software that can be used to confirm that the software has not been
altered and that it comes from who it claims to come from.

Certificate authorities

In the example above, GoDaddy is what’s called a “Certificate Authority” or
just “CA” – they are an entity that has been authorized to sign certificates
for use on the internet.

Now, if you’ve been paying close and detailed attention to this point (I
wouldn’t blame you if you’ve dozed off ), you
should be asking a question right now:

“If GoDaddy signed your certificate with their private key, how did
you get their public key, and how do you know that it is
valid?”

Enter the “root certificates.”

Installed on your machine and updated with Windows update (or, in some
cases, installed into your browser and updated by browser updates) are a set of
certificates that represent the CAs that your machine or browser will
implicitly trust from the start.

In Internet Explorer, click the Tools menu,
Internet Options menu item, the Content tab,
the Certificates button, and finally the Trusted Root
Certification Authorities tab. That lengthy sequence will bring up
something like this:

On my system, there are 39 “Trusted Root Certification Authorities” and
GoDaddy happens to be one of them.

If you’re really eagle-eyed, you’ll now ask this question:

“But wait! The trusted root certificate is for ‘Go Daddy Class 2
Certification Authority’, but your certificate was signed by ‘Go Daddy Secure
Certification Authority’ – they don’t match!”

Indeed they do not.

Certain types of CAs are allowed to create other CAs creating what’s called
a certification chain or path.

The certificate for “secure.pugetsoundsoftware.com” was actually signed by
an intermediate CA called “Go Daddy Secure Certification Authority” whose own
certificate was signed by “Go Daddy Class 2 Certification Authority.”

As long as a certificate chain ends in a trusted root certificate installed
on your machine, the chain of trust is intact.

Now, it gets interesting.

Rogue certificate authorities

You can see right away that if the private key of a root CA is ever stolen
then hackers can create certificates that would be trusted as valid by all
computers.

To the best of my knowledge, this has actually never happened.

However, the same cannot be said for intermediate CAs. In 2011, a couple of
CAs were hacked and the hacker was able to create intermediate CA certificates
that were signed by the root CA certificate, thus making them “valid.”

Using those certificates that he had created, he could then create website
certificates for any website that would be trusted simply because that
intermediate certificate looked valid and trusted by a root CA. These rogue
certificates were then allegedly used to perform “man-in-the-middle” attacks on
Iranians attempting to access secure sites such as Gmail.

In a different type of recent mishap, Microsoft accidentally set this “This
certificate can be used to sign code” flag on certificates that it provided as
part of its system software. Quoting Sophos’ Naked Security blog:

The Microsoft Terminal Server Licensing service is used for license
management and authorization in many enterprise environments. Microsoft had
been mistakenly issuing certificates for use on these servers that could be
used to digitally sign code.

This eventually allowed hackers to insert malware that looked like valid
software coming from Microsoft as part of Windows Update.

Why rogue certificates are bad

What you’re probably wondering right now is how this impacts you, the
average computer user.

Fortunately, it’s not common, but here’s one scary scenario:

• You bank at somerandombank.com and regularly connect to
  https://somerandombank.com.
• A hacker creates a rogue CA certificate, signed by a trusted root authority,
  that he can use to create certificates for any website he likes.
• The hacker creates a bogus, but valid-looking certificate for
  somerandombank.com.
• The hacker installs that certificate on a server that he owns and makes the
  website on that server “look like” the somerandombank.com website.
• The hacker manages to install malware on your machine, or your router, that
  causes the DNS lookup for “somerandombank.com” to return his server and
  not the actual somerandombank.com server.
• You visit https://somerandombank.com and are connected to the hacker’s
  server.
• The server provides the certificate created by the hacker.
• Your computer trusts this bogus certificate because it’s signed by a trusted
  root authority and therefore trusts that you are connected to the proper
  server and site, when in fact you are not.

You actually have no indication that you’ve connected to a bogus, malicious
website even though it’s via https.

Hopefully, you can see why this isn’t terribly common and not something that
I spend a lot of time worrying about. First, the hacker has to somehow breach
security at the actual trusted CAs (who, after recent events, are probably more
secure than ever). Then, the hacker has to also breach your security in
order to redirect your browser to his bogus server.

It’s no simple task. Possible, yes, and worth protecting against, but not
common.

Certificate revocation

The current defense against certificate compromise is the concept of a
“revoked” certificate.

Two tabs down in the dialog we opened from Internet Explorer is Untrusted
Publishers. These are certificates that have been explicitly revoked and
marked as not to be trusted. When a rogue signing certificate is found, it or
its parent certificate in the signing chain is revoked and all other
certificates that may have been signed by the rogue certificate are instantly
no longer valid.

This is why keeping your system up-to-date is so important. When
certificates are revoked – as Microsoft just did to some of its own
certificates – you want that revocation to be known to your system as soon as
possible.

The future

It’s been said that the current setup of digital certificate signing
authorities is fragile – some even say broken – for an assortment of reasons, the hacking scenario above being one example.

There are improvements, both proposed and actually slowly being implemented
to increase the security of the overall system.

But from a practical perspective, I still believe that the system is
basically trustworthy for everyday use and continue to do my banking and other
sensitive transactions online via https connections.

But I definitely keep my machine as up-to-date as possible.

And so should you.