Most people see digital certificates as a black art with layers of complexity. Having designed and deployed a Public Key Infrastructure for an Investment Bank I will try and convey the simplicity and risks.
A Digital Certificate has two parts, a public and private key. The public key can lock your door but only the private key can open it.
I am not all that turned on by the fact that mathematically a digital certificate can, given enough time and compute capability most likely be reverse engineered. That is to say create a private key from the public one.
The real risk comes from human social engineering. Certificates typically have parents who are responsible for issuing them. If you think of your passport you have the passport agency as the parent and ultimately you trust the government to control the process of issuing them (or not).
So who do you trust to issue certificates then?
The list is stored on your computer, and this is one of the fundamental problems with certificates. The list of trusted certificate authorities is in the case of Windows defined by Microsoft. You will see in Windows 7 that this list is an awful lot leaner and actually most of the vendors in question are now household names.
Can social engineering break this?
Absolutely, it’s a long time ago but someone pretending to be a Microsoft employee managed to get a digital certificate that we would have all trusted from the leading vendor of Digital Certificates. In fact if you care to look you will see those very certificates on any Windows computer now marked as un-trusted.
What can we do?
For organisations it is very important to manage the trusted root store on any device. For individuals be very careful if asked to install an un-trusted root certificate.
Why is this important?
As we move forward with integrated services across organisations I expect the demand for certificate based authentication and the associated trust we place on Digital Certificate will increase significantly.