Digital Certificate Operation in a Complex Environment
Sections in this document:search
PKI Primer and Project Background
7. Security and digital certificates
In the explanations that follow, the term ' ' 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.
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 - use agreed methodologies and protocols to stay secure.
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.
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 server which will sign the certificate request (if allowed to do so by the ). 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.