Difference between revisions of "Certificates"

From Clinfowiki
Jump to: navigation, search
m (typo)
m (typo)
Line 3: Line 3:
 
A certificate can also be self-signed, which reduces its trust utility but allows the continuity of software infrastructure.
 
A certificate can also be self-signed, which reduces its trust utility but allows the continuity of software infrastructure.
  
Public key encryption works through algorythms that require two keys.
+
Public key encryption works through algorithms that require two keys.
 
* The first key is the secret key. If it locks something (or encrypts it), only the second key can unlock it.
 
* The first key is the secret key. If it locks something (or encrypts it), only the second key can unlock it.
 
* The second key is the public key. If it locks something (or encrypts it), only the first key can unlock it.
 
* The second key is the public key. If it locks something (or encrypts it), only the first key can unlock it.

Revision as of 00:33, 23 November 2009

A certificate is a central element in public key encryption. It is a way of validating the authenticity of a public key through use of a third party, also known as a Certificate Authority. It also adds some useful meta-data to the public key, such as expiration date.

A certificate can also be self-signed, which reduces its trust utility but allows the continuity of software infrastructure.

Public key encryption works through algorithms that require two keys.

  • The first key is the secret key. If it locks something (or encrypts it), only the second key can unlock it.
  • The second key is the public key. If it locks something (or encrypts it), only the first key can unlock it.

The public key is freely given to others. If someone wants to send a secure message, they ask for the public key and encrypt their message using it. The receiving party is able to decrypt the message using their private key.

As an example, let's say that there is a public key encryption system for passing notes at Bedrock elementary school. Wilma wants to pass a coded message to Fred and requests his public key. Fred passes a note that anyone can read with his public key and Wilma encrypts the note to Fred with it. That way Barney, who sits in between them, can't read her message when it is passed. Fred is able to read Wilma's message by decrypting it with his private key.

This simple scenario has a big flaw. Someone intercepting the messages between those two parties could substitute the receiver's public key with their own. They can decrypt the message, read it and then encrypt it with the original public key.

So Barney could pass along his own public key to Wilma as if it were Fred's. Wilma would sign the message, and when it passed by Barney's desk, he could decrypt it, read it, resign the contents with Fred's real public key and then pass the message along to Fred as if Wilma had signed it.

The answer to this flaw is a certificate authority. It signs the public key (again using public key encryption) and provides some meta-data such as an expiration date and who the certificate authority is. Instead of just passing out a public key, the entire certificate is passed. The recipient of the public key, now encapsulated in a certificate, can now contact the certificate authority to verify that the public key is true before using it.

In Bedrock, Betty has started her own certificate authority, and Fred has signed up. When Wilma receives the certificate from Fred, passed through the perfidious Barney, she can answer the question "is this really Fred's key, or is Barney playing man-in-the-middle again?" by using Wilma as a trusted third party.