Certificate Trust Model
Here is another challenge. When you receive a certificate, for example, from email.
The certificate indicates the owner's name is Bob. How can you be sure that the
certificate really belongs to Bob? Remember Eve can generate a certificate with
same name called "Bob" and can snooping on the net to intercept the emails between
Bob and you. Refer to FAQ: man-in-the-middle-attack
for more information about this kind of attack.
Fortunately each certificate has its unique thumbprint, like a person does. If you
can find a way to verify the certificate's thumbprint with Bob then you are sure
that the certificate really belongs to Bob not someone else.
One way to verify the thumbprint is your calling Bob and having him read his certificate's
thumbprint to you. Once the thumbprints match you are sure that the certificate
is really Bob's and any emails encrypted with this certificate can only be read
by Bob with his private key. This is so call direct trust in which the communicating
parties are responsible for doing all the hard work of thumbprint verification.
This is the most basic form of certificate trust.
If the number of people you correspond with is small you can, for example, call
each of them to verify the certificate thumbprints. If, however, you correspond
with a lot of people this is not an easy task. That is why we need to use other
mechanisms to verify the validity of a certificate.
Note: Direct trust is the only way of
trusting a certificate in iSafeguard™ versions before 3.0.
In the hierarchical trust model everybody's certificate is issued by a third party
called Certificate Authority (CA). If one trust the CA then he automatically trust
the certificates that CA issues. This is a simplified form of hierarchical trust
model. In reality there are a number of root certificate authorities from which
trust extends. These CAs may issue certificates themselves, or they may issue certificates
that are used to issue certificates down some chain.
The whole structure is like a trust tree. End (leaf) certificate is verified by
tracing backward from its issuer to the issuer's issuer until a directly trusted
root CA is found. Again we see direct trust here.
The above description is simplified for illustration purpose. But it does make the
point: a trusted third party is required to build the trust relationship without
direct contacts among communicating parties.
Indirect Trust Model
The trusted party, however, does not have to be a CA. Actually not everyone has
a certificate from a CA. Many people use self-signed certificates for communicating
with their friends and family members. They can use direct trust or use the so-called
indirect trust described below.
When Bob hands you his certificate on a disk you know the certificate is really
his. You establish the trust through direct trust. Therefore you mark this certificate
as trusted. Bob does the same thing with your certificate. So Bob and you can communicate
securely. In the similar way you trust Alice's certificate and mark hers as trusted.
One day Bob wants to communicate with Alice securely. It is impossible for Alice
to hand her certificate to Bob personally since they are hundreds of miles away
from each other. Bob could ask her to email her certificate to him and then give
her a call to verify the thumbprint. This may not be always possible; Bob may not
have her phone number, for example.
Or alternatively Bob could ask you to sign Alice's certificate and send the signed
certificate to him since you have her certificate and have verified the thumbprint
with her. When Bob receives Alice's certificate with your digital signature he can
verify the digital signature with your certificate he has already had and trusted.
Once the verification is successful Bob can be sure he gets Alice's certificate
and can communicate with her securely. This is so called indirect trust.
The trust between two communicating parties is established through a trusted third
party - you.
This trust model is particularly useful when communicating parties don't use a common
Trust Models Used In iSafeguard™
Starting from version 3.0 iSafeguard™ supports direct trust, indirect trust
and hierarchical trust. For self-signed certificates (including root CA certificates)
direct trust and indirect trust models are used. For CA-issued certificates hierarchical
trust model is used.
The following is a list of the trust rules used in iSafeguard™:
- Self-signed certificates are trusted directly by verifying their thumbprints with
the certificate subjects.
- Self-signed certificates with private keys are trusted; no matter they are CAs or
- Self-signed certificates, including root CA certificates, signed by directly-trusted
certificates are trusted.
- Certificates, with or without private key, issued by a trusted CA certificate is
- A CA certificate is trusted only if its issuing CA certificate is trusted.
Note: A certificate is called directly-trusted
- The certificate is self-signed and you have the corresponding private key; or
- You get the certificate through a secure channel, someone hand you his certificate,
for example; or
- You have verified its thumbprint with its subject through a secure channel.
Certificate Validity and Certificate Trust
A certificate is said to be trusted if you are sure the certificate really belongs
to the subject shown on the certificate.
A certificate is said to be valid if it is trusted and in its valid time period
and not being revoked.
Here is another question you may have regarding certificate. What if my private
key is compromised? Or I don't use a certificate anymore? Well if you use certificates
issued by a Certificate Authority (CA) you may revoke your certificate by working
with the CA. The CA will publish a list of revoked certificate, called Certificate
Revocation List, periodically. For example Thawte allows you to revoke your certificate
using their web site. Thawte then will add your certificate to the list of revoked
iSafeguard™ fully supports Certificate Revocation List. When checking the
validity of a certificate iSafeguard™ will check against your CA's CRL to
make sure it is not revoked before allowing you to use it to sign and encrypt data.