Helping people with computers... one answer at a time.
Https encryption and digital signatures used to validate some programs rely on an infrastructure of trusted signing authorities. Interesting things happen when one of those authorities is breeched, or makes a mistake.
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.
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...
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.
Read that again; while simple, it's critical to this whole process. Here's what trips most people up:
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.
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.
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:
I create an email message (for example – any file or document would suffice).
After I'm done creating it, I run the email message through this hash algorithm to generate that hash value number.
I encrypt the hash value with my private key.
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.
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.
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.
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.
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.
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.
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.
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.
Comments on this entry are closed.
If you have a question, start by using the search box up at the top of the page - there's a very good chance that your question has already been answered on Ask Leo!.
If you don't find your answer, head out to http://askleo.com/ask to ask your question.