To authenticate a digitally signed email message, you must have access to the sender's public-key certificate and you must have a way to validate its authenticity. Two methods exist for gaining access to the public key. First, the sender can provide a copy of the public key to recipients before sending any digitally signed or encrypted mail. This certificate is installed in the certificate repository on the recipient's PC. When the recipient receives a digitally signed or encrypted message, the email client matches the sender's address to the public key and uses the key to decrypt the message and verify its authenticity. A sender can also attach a copy of the public-key certificate to each message so that the public key is available even if the recipient didn't receive it ahead of time. The latter method is more convenient—but also less secure. When you attach the public key to the email message, anyone who intercepts the message would have a copy of the key. If the sender's certificate were used to encrypt the email message, the person who intercepts the message can use the public key to decrypt and read the message.
After the recipient has a copy of the public-key certificate, the recipient needs to determine whether the certificate is valid and hence the sender can be trusted. If you install a certificate into your PC's certificate repository, you can explicitly trust the certificate—in other words, force your system to assume the certificate is valid. The preferred and more secure method uses a trusted certificate chain and CRLs to determine a certificate's status. As I stated earlier, the certificate contains information about the CA that issued it. For the trusted chain to work as a validation mechanism, you need to store in every PC's certificate store a certificate representing the issuing CA or a root CA. This certificate, rather than the sender's certificate, is explicitly trusted (because typically, it's more well known). Because you explicitly trust the issuing CA or root CA, you implicitly trust the sender as long as all the certificate signatures are valid, all have valid dates, and none are found on a CRL. If the sender uses a well-known CA such as VeriSign, Thawte, or Baltimore Technologies, your PCs should already have the appropriate root certificates installed. If the sender uses a certificate from a less-known CA, you'll need to install that CA's certificate. For information about using digital certificates, see "Secure your Email, Part 1," http://www.winnet
mag.com, InstantDoc ID 24226, and "Secure your Email, Part 2," http://www.winnetmag, InstantDoc ID 24887.
The procedure for requesting and obtaining a certificate varies depending on the CA, but the process is generally easy. You provide some identifying information to the CA; the CA verifies the information and sends you instructions for installing the digital certificate. You can view the certificate by using Microsoft Internet Explorer (IE). To review the certificates stored in a PC's certificate repository, open IE; select Tools, Internet Options; then select the Content tab. Click the Certificates button to display the certificate repository. You should see your certificate listed on the Personal tab.
After you install the certificate, you need to configure Outlook to use the certificate to sign email. Open Outlook; click Tools, Options; then select the Security tab. Click Settings to display the Change Security Settings dialog box, which Figure 8 shows. The fields in the Certificates and Algorithms section will be populated with information from the personal certificate you just installed. If you have more than one personal certificate, you might need to click Choose beside Signing Certificate and beside Encryption Certificate and select the appropriate certificates from the lists. Unless you have a reason to change the algorithms, you should use the default values. SHA1 is the Hash Algorithm default, which tells Outlook how to generate the message digest; Triple DES (3DES) is the Encryption Algorithm default. If you don't want Outlook to attach your public certificate, clear the Send these certificates with signed messages check box. If you clear this option, you need to give a copy of your public key to all potential recipients. If you plan to use the personal certificate only for signing, you're relatively safe leaving this option selected, and it will significantly simplify your deployment. Click OK to close the Change Security Settings dialog box. On the Security tab of the Options dialog box, select the Add digital signature to outgoing messages check box if you want to digitally sign all outgoing messages. If you don't select this option, you can choose to digitally sign on a message-by-message basis.
Composing and sending messages works the same as without digital signing, but now Outlook will append a digital signature to each message that a user sends from the anonymous mailbox; the change will be seen on the recipient's end. When a recipient opens a digitally signed message in Outlook, they'll see a ribbon icon on the right side of the message header, as Figure 9 shows. If the digital signature of the message is valid, they'll see a red ribbon and know the message is legitimate. If the digital signature can't be verified or is invalid, Outlook shows a gray ribbon icon with a red exclamation point. Double-click this icon to display the problems with the certificate or the signature.
More Accountable Email
Configuring security features to log additional information can add accountability and tracking to your email system. Adding digital signatures helps recipients know that messages are legitimate and gives you a powerful tool that helps ensure the integrity of your company's business communications. In a future article, I'll discuss how to set up your own CA server and highlight some concerns and challenges associated with running your own CA.
End of Article
Prev. page
1
2
[3]
next page -->
