Sep 232013

What happens if an attacker compromises your root private key?

SSL certificates are used to authenticate clients and servers and to provide a means of securely sharing a secret key which is then used to encrypt communication between the server and client.

In order to do this, you have to have a level of trust in the body which issues the certificates; the Certification Authority or CA.

The way this works in practice is that you place the Root Certificate of the Certification Authority in your ‘Trusted Root Certification Authorities’ store on your computer. This says ‘I trust all certificates signed by the private key associated with this certificate’. Since the private key is only known by the Certification Authority, any certificate signed with the key must have been issued by the authority, and passed all the checks as defined in their CPS (Certification Practice Statement).

Once the infrastructure is in place, the flow is as follows:

SSL flow

Over complicated diagram showing keys and certificates.

  1. The client connects to the web server and requests a secure connection.
  2. The web server sends its certificate which includes a public key.
  3. The client verifies the certificate by checking the name matches the site name, that it has not expired (or been revoked) and that it is signed by a trusted authority.
  4. The client chooses a symmetric encryption key and encrypts it with the public key from the certificate. This is sent to the server
  5. The server decrypts the message with its private key. The browser and web server now share a symmetric key which is unknown to anyone else. This key is used to encrypt all communication for the rest of the session.

The security of the above transaction relies on the private key being stored securely by the web server. If someone had access to that key, they could decrypt the message containing the secret symmetric session key and therefor read all the encrypted messages which follow during that session. However, its unlikely that the owner of the web server would allow the key to leave the server. If an attacker managed to compromise the server to such an extent that he had access to the key, he would have full control of the server and would be able to access the communication anyway. If a government requested the key through legal means, they would be able to read all the communication but, again, they would get much more information by just requesting full access to the server.

So everything is nice and safe as long as the private key is kept secure. (There are, of course, other problems if, for example, there is malware on either end, but I’m ignoring that here).

So, what happens if someone gets access to the Certification Authority’s Private Key either by compromising their key store or by demanding it via legal channels?

Having the root private key would still not allow the attacker to intercept the symmetric key as it is encrypted using the public/private keypair generated by the web server, and the private key is still only known by the web server. It would, however, allow the attacker to create his own certificate and sign it with the Root CA private key. This would mean that it is trusted by the client computer and it would be very difficult to tell it apart from the genuine server certificate.

The attacker can now perform a ‘Man-in-the-middle’ (MITM) attack to capture all the traffic between the client and server. He does this by posing as the web server and authenticating with the client. The client now sends the symmetric key to the attacker encrypted with the attacker’s public key. The attacker decrypts the key and sets up a secure connection with the client. At the same time, the attacker connects to the genuine site and poses as the client. The attacker acts as a proxy between the client and server and can read both sides of the communication. Further, the attacker can change the information from either side. Say, for example, you think you are connected to your bank and you check your balance. The attacker can report the correct balance, but in the background could transfer all your money into his own account. If he needs any extra passwords, or a two-factor authentication, he can prompt you for those details and, if its convincing enough, you may be fooled into providing what he needs.

Feb 262012

What is an SSL certificate?
At its most basic level, an SSL certificate is used to encrypt electronic communication, to authenticate users or devices, and to sign electronic communication. There are various types of SSL certificate – Web Server certificates, Email certificates, code signing certificates etc.
Here, I will describe the process of creating a new SSL certificate for use on a website as this is the most common use for certificates. At some point, I may write further guides describing different types too.

What are the components of an SSL certificate?
SSL certificates contain a number of pieces of information:
Subject – the name of the entity being identified by the certificate.
Private key – never seen by the client.
Public key – associated with the private key.
Issuer – the name of the Certification Authority who has signed the certificate.
Serial number – a unique identifier for the certificate
Validity period – the start and end dates between which the certificate can be considered valid.
Usage – a description of what the associated public/private  key pair can be used for.
Digital Signature – the signature of the issuer.

The certificate uses Public Key cryptography to encrypt, sign and authenticate.
The private key is known only to the owner of the certificate. A piece of information encrypted with this key can only be decrypted by the associated public key.

How do we communicate securely?
Let’s assume a situation where I want to communicate securely with you. I make a connection to your web server and request your certificate. Your server supplies the certificate which contains your public key. I generate a master key which we will both use to encrypt our communication. I encrypt the master key with your public key and send it to you. You are the only person who can decrypt the master key as you are the only person who knows your private key.

We have now securely exchanged a master key without anyone else being able to know it and can communicate securely.

What is signing?
In the same way you can sign a letter to ‘prove’ that it was written by you (assuming no one is capable of forging your signature), you can digitally sign an electronic communication to prove it was created by you – this also confirms that the content has not been changed since you signed it (and means you can’t deny the document was created by you)
When you digitally sign a document, you hash the content and encrypt the hash value with your private key. This is then sent with your certificate and the document. When I receive the signed document, I can decrypt the hash using your public key from the certificate. I then hash the document myself and confirm the two hashes match.

But, how do I know you are you?
Communicating securely is fine, but how do I know you are who you claim to be and not someone pretending to be you?
Public Key Cryptography to the rescue again!
When you create a certificate, you can have it signed by a Certification Authority (CA) – they will do some checks to confirm your identity; generally by doing a WHOIS search against your domain name and verifying your name and address.
Once they have established that you own the domain for which you are creating the certificate, they will digitally sign the certificate for you. This means they are vouching for your identity.
Every web browser comes with a list of CAs which it trusts – there are hundreds of them. When I receive your certificate, I check who it was issued by. If it was issued by a CA which I trust, I am able to confirm that it is signed by them and I know that I can trust the certificate.

Great, how do I create a web certificate then?
The high level steps to create a certificate signed by a CA are:
Create a public/private key pair.
Send the public key and certificate info to a trusted CA
The CA creates and signs a certificate which contains your domain name and private key.
You install the certificate on your web sever where it is associated with the private key.

Creating the key pair.
I will use the Microsoft IIS web sever as an example because I am most familiar with it. Other web severs use similar steps.
IIS has a wizard to step you through creating a certificate…
In IIS, right-click on your website and choose ‘properties’.
On the Directory Security tab, click the Server Certificate button this will open the wizard.
Choose ‘Create a new certificate’ then ‘Prepare the request now, but send it later’.
Enter the details as you are prompted for them and, at the end, save the certificate request somewhere you can find it.

You have now created the keypair and prepared a Certificate Signing Request (CSR) ready to submit to your favorite Certification Authority.
The CSR is a block of text which is uploaded to the CA as part of the enrolment process. Once enrolment is complete, the CA will provide you with your new certificate – either as some text displayed on screen or as a file in an email. Either way, it should be saved as a file on your web server.

Installing to certificate
Back in the certificate wizard in IIS, choose ‘Process the pending request’
Choose the file supplied by your CA and follow the wizard to install your certificate.

The certificate should now be served when you visit the website in your browser on port 443. (https://)
You should probably make a secure backup of the certificate now by exporting it from the certificates snap-in.

For Apache servers, the CSR is created using the OpenSSL software – there are plenty of guides online.


If you have found this article useful, please consider purchasing an SSL certificate from Godaddy using my affiliate link – – It will help me keep the site online! Thanks.

Enhanced by Zemanta