Digital Certificate Operation in a Complex Environment
homebackgroundprojectdocumentsdesignglossary
navigation search
search query:

PKI Primer and Project Background

7. Security and digital certificates

7.1. But everything is 'public' on the internet?

  1. Anyone can copy my digital certificate!
  2. Anyone can copy the data I send with it!
  3. Anyone could build their own certificate!

Let's consider these real fears in turn.

In the explanations that follow, the term 'key' is used. This is explained later, when we reach the section on cryptography. However, you can think of a 'key' as a piece of code that can be used to digitally sign or encrypt (or de-crypt) a message or some data.

7.1.1. Copying a digital certificate.

Everything that is sent on a network or the internet can theoretically be copied by someone listening in or playing a surreptitious 'man in the middle' role.

So, anyone can copy my digital certificate? Well, yes. However, the way that you use your digital certificate is to reveal it, but then to sign some data with your private key, which is never sent over the network*. The recipient works out that your private key is sound, so it must have come from you as did your certificate.

* NOTE: It is possible to send private information over the network in an 'encrypted' form. However, a key is always needed for decryption.

Encryption always plays a role (actually, several roles) whenever you use your certificate, and this helps to keep the most important information safe. You have to trust the software to do this securely (which is another huge area for discussion). However, most of the exchanges - such as those used in Secure Sockets Layer - use agreed methodologies and protocols to stay secure.

7.1.2. Copying the data sent with your certificate

This can be a concern as it could expose you to replay attacks where someone or something copies the code that accompanies your certificate, electronic handshakes etc. and tries to use it later. This pre-supposes that, even though messages are encrypted, the interloper does not have to understand them, he can just pass them on or replay them to achieve a successful result.

This tends not to be a worry as different information is used each time you use your certificate and private key. Usually a randomly generated number or phrase (often called a challenge phrase or connection identifier) is used which makes this kind of 'attack' virtually impossible.

Also, each major transaction can be encrypted in a different way and, during a secure 'session', the encryption keys and method of encryption can be agreed-upon and changed by the participants. This has other benefits, but can also decrease the chances of this kind of attack.

7.1.3. Anyone can build their own certificate

This is true. However, for a certificate to be useful to you, it must be trusted by whomever you are communicating with or by services that you are trying to access. A certificate that is not signed by an 'authority' that the service or other individual trusts may be almost or entirely useless.

What happens is that a user may 'request' a certificate after having built parts of what will eventually form the certificate on their client computer. Then the request travels to the Certification Authority (CA) server which will sign the certificate request (if allowed to do so by the Registration Authority - RA). This signed block of code is the user's digital certificate .

*NOTE: Don't worry too much about the technical terms of Certification and Registration Authorities here. These are public key infrastructure terms meaning the body that has the responsibility for verifying 'the authenticity of your certificate' and the body that has the responsibility of 'verifying the true (physical) you', respectively. The RA confirms that you are eligible for a certificate and the CA signs your certificate.

Anyone can - with a little technical knowledge - build a certificate, but it is likely that no other user or service will trust that certificate and the certificate is useless.

Up: Contents Previous: 6. Authentication via digital certificates Next: 8. Public key infrastructure

Oxford University Computing Services Mimas Athens access management services Oxfore e-Science Centre Systems and Electronic Resources Service Joint Information Systems Committee