Public key cryptography makes communication on the Internet possible by providing means for a large number of people to exchange secure messages without having to first agree on a shared key. However, to be able to securely encrypt a message, or verify the digital signature on a document, you must be sure that you are using the correct public key for the intended recipient. If you were to encrypt or verify a message with the wrong public key, then you may inadvertently send out information that can be decrypted by an attacker, or you may rely on the integrity of a document that has been modified in transit.
Both confidentiality and integrity rely on authenticating the sender and recipient to be sure that information goes to, or comes from the person intended. Despite the fact that public keys were created to solve the problem of key distribution, it seems to have replaced one key distribution problem with another.
One method of authenticating public keys is to have these keys (and information about the entity they belong to) digitally signed by a third party. This signed information is called a digital certificate (or commonly just a certificate) and the third party is known as a Certification Authority (CA).
While it is still necessary to obtain and authenticate the public key of the certification authority by some secure means, the problem of obtaining the public keys of all the people you wish to communicate with has been reduced to a problem of just obtaining a single key for a CA that has issued certificates for these people. CAs can also issue certificates to other CAs, so that it is possible to produce a chain of certificates (called a certification path) from a root CA (sometimes called a trust anchor) to the person or end entity with whom we wish to communicate.
The collection of algorithms, protocols, policies and procedures which enable us to build a scalable infrastructure for communicating using public key cryptography and certificates is known as a Public Key Infrastructure (PKI). PKIs are in everyday use around the world to provide security for banks, online merchants, traders and consumers alike.
A Certificate authenticates public keys by binding the key with information associated with its user. A certificate also contains other information such as when the key is valid, what the key may be used for, and whether the key may be used to sign other certificates.
A Certificate Revocation List (CRL) is issued by a CA at regular intervals and lists certificates that have been invalidated or revoked before their expiry date.
When verifying whether a certificate is valid, a user must check both the certificate signature, and the current valid CRL to ensure that the certificate is not listed on it.
Reasons for revocation can include:
An example might be when a user leaves a company.
Authentication Services for Smart Cards uses Public Key cryptography to authenticate users to Active Directory. It uses keys and certificates stored on the smart card to perform a version of the Kerberos authentication protocol called PKINIT. When Active Directory has authenticated the user, it in turn authenticates itself back to Authentication Services for Smart Cards.
This mutual authentication is critical to the security of the PKINIT protocol, and requires that Authentication Services for Smart Cards verify the certificate presented by Active Directory as part of this exchange against one or more trusted certificates and CRLs.
Trusted certificates used by Authentication Services are stored in the /var/opt/quest/vas/certs directory.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy
