| Concepts and Planning | << | >> |
|---|
Microsoft Exchange Server uses public/private key technology to provide advanced security. Keys are used to digitally sign and encrypt data. Each mailbox is given two key pairs: one for encrypting and decrypting, the other for signing and verifying. Each key pair consists of a public key (publicly known) and a private key (known only to the key's user). The KM server generates encryption keys, and Outlook generates signing keys.
The public encryption key is used to encrypt a message; the public signing key is used to verify the source. When a user encrypts a message, each recipient's public encryption key completes the process. When a user receives a signed message, the public signing key verifies the person who signed the message.
Private keys are stored in an encrypted security file (.epf) on each user's local disk. When a user receives an encrypted message, the private encryption key decrypts the message. When a user signs a message, the private signing key is used.
A bulk encryption key is also encrypted and sent with the message. The encrypted bulk encryption key is referred to as a lock box. The lock box ensures that the bulk encryption key is secure while the message is encrypted. If a message is sent to multiple recipients, the message contains a different lock box for each recipient. After the message and lock box are received, the lock box is decrypted and the contents of the lock box (the bulk encryption key) decrypts the message.
Public keys must be certified by a CA. In Microsoft Exchange Server, the CA is Microsoft Certificate Server. A certificate binds the user's public key to the mailbox.
Each certificate includes:
Every user has two certificates:
Encryption certificate Contains the user's public encryption key and is an attribute of the user's mailbox in the directory.
Signing certificate Contains the user's public signing key and is stored in the user's security file.
Revocation warns users when they verify signed messages that contain a revoked certificate. Revoking a user's advanced security is not the same as deleting a user, and should be done only if the security of the user has been compromised. For example, you should consider revoking advanced security if it appears that someone is signing messages on behalf of a user or someone has gained access to the user's security file and password. You can enable security again by assigning the user another temporary key.
A revocation list contains the serial number and expiration date of each revoked user's certificate. The KM server stores the revocation list in the key management database and then writes it to the directory. The revocation list in the directory is then cached on the client and updated daily.
You should limit the use of revocation. As the revocation list grows larger, the client's performance and advanced security operations degrade. This is because each time the client verifies a message's signature, it must access it in the revocation list. If the list is long, this operation may take longer.