 |
|
| E-Mail
Security by Bob Walder Few organisations are without some form of e-mail communication these days, whether they operate their own mail server, or whether they rely on an Internet Service Provider. Some are still using e-mail as a purely internal messaging medium, whilst the vast majority have recognised the power of the Internet to act as a global transport mechanism for their inter-company electronic mail. Unfortunately, e-mail – particularly when travelling across a public network such as the Internet – is inherently insecure. Oh sure, if we implement a corporate messaging system such as Microsoft Exchange Server, Lotus Notes or Novell GroupWise, we can expect tight integration with the security of the host operating system. Data stored in the messaging database is secure, sometimes encrypted, and always protected by layers of passwords and Access Control Lists that determine exactly who is able to access which messages, and what they are allowed to do with them. Once a message leaves the sanctity of the Exchange Server, however, to wend its merry way along the Information Superhighway, the armoured car approach that we used internally suddenly becomes more of a convertible on a sunny day – the top is down and the contents are there for all to see. If the car has to pull up at some traffic lights, there is nothing to stop a passer by from lifting the contents altogether, and perhaps even replacing them with completely bogus information. The use of the Internet thus provides us with a number of dilemmas when it comes to electronic messaging. We would all dearly like to trust our e-mail system, but we cannot until we can impose some semblance of protection and security similar to that which we have with good old paper-based communications. For instance, we can type or write out a message on paper and then sign it at the bottom to provide proof of sender. This signature can easily be checked against permanent records held by the recipient, hence the reason we are asked to provide specimen signatures when opening a bank account. Next, we can seal the document in an envelope, perhaps adding another signature over the flap and covering that with sticky tape to ensure that it is tamper-proof during transmission. Finally, we can send it recorded delivery, thus providing us with proof that the recipient received the document in a timely manner. All of these precautions allow us to have absolute faith in our paper-based messaging systems, and thus enable us to use such mechanisms to send legal documents, contracts and so forth. S/MIME As it happens, you can do pretty much the same sort of thing with your e-mail messages too. We may have to wait some time yet before we can have true proof of delivery of e-mail messages across the Internet, but at least we can make sure that they remain confidential. Secure MIME (S/MIME) is an emerging e-mail standard that seeks to ensure this, providing for the secure transmission of e-mail using a combination of encryption and digital signatures to protect against three types of security violations: snooping, tampering, and forgery. Various levels of encryption and various types of digital signature are supported, the minimum level being a 40-bit RC2 symmetric (or "secret key") cipher - the maximum key length permitted for export by the U.S. Government. The idea is that as stronger algorithms come into regular use, S/MIME-compliant systems will negotiate the appropriate encryption algorithm between them, with all the necessary information being stored in the message header. The biggest problem with symmetric key cryptography is that it relies on both parties involved having access to the same secret key, since the sender uses the key to encrypt the message, and the receiver uses the same key (together with the same algorithm in reverse) to decrypt. Some of you may have already spotted the potential problem with this. If Bob wants to send a message to Alice (for some reason, the two parties involved in ANY cryptographic exchanged are ALWAYS called Bob and Alice), then the two of them must have previously exchanged secret keys in a secure manner. The only way to do this in a real-world scenario, where you are frequently sending one-off messages to people with whom you have never made contact before, is to send the key along with the message. But, why bother encrypting if we are going to send the key along with the message? The way around this problem is to use "public key" or "asymmetric key" cryptography, where each person gets a pair of keys, known as the public key and the private key. The public key is generated from the private key using a complex algorithm, following which the public key can be published, whilst the private key remains secret. Although it sounds far fetched, it is an accepted fact that any message encrypted with a given public key can only be decrypted using the corresponding private key, and there is no known way to derive the private key from the public key. This makes public key cryptography the perfect choice for messaging applications between strangers. Now, if Bob wishes to send a message to Alice, he will encrypt it using Alice’s public key (which can be published in a directory or distributed via unsecured e-mail). The only person who can decrypt the resulting message is the holder of the appropriate private key – Alice. The need for sender and receiver to share secret information is eliminated, since all communications involve only public keys, and no private key is ever transmitted or shared. Although providing the highest levels of security, public key cryptography is notoriously heavy on system resources, particularly when working on large messages. For this reason S/MIME uses a combination of the two type of cryptography. In simple terms, the main part of the message is encrypted using a DES secret key, which is randomly chosen and different for every message sent. This secret key is then encrypted using the recipient’s public key, and the encrypted key is stored in the message header for transmission. As the message is received, the recipient’s private key is used to decrypt the secret key stored in the message header. This secret key is then used to decrypt the main message – voila. It may sound complicated, but it an extremely efficient and secure way or exchanging encrypted mail messages, and the whole process is completely transparent to the end user. OK, so now we have our data encrypted to prevent snoopers discovering its content. We still need a means to prove that the message came from us (the equivalent of our signature on a piece of paper) and, that the message was not tampered with during transit (the equivalent of the signature and sticky tape on the envelope flap). As with encryption, the whole signing process sounds incredibly complicated, but it takes much longer to describe than it does to execute as part of an S/MIME client, where a simple click of the "Sign This Message" button is enough. The first step is to use a "hash function" to create a uniquely concise version of the original text - known as a "message digest" - which serves as a very much smaller "digital fingerprint" of the message. As with general encryption, there are several secure hash functions available such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA). It is infeasible that different documents will have the same message digest, and even small changes in a document will cause significant changes in the digest. Next, the message digest is encrypted with the sender’s private key, and this becomes the digital signature, which is transmitted to the recipient along with the message itself. Upon receiving the message and signature, the S/MIME client uses the recipient’s public key to decrypt the message digest. Note this is the opposite way around from the encryption process, where public key is used to encrypt, and private key to decrypt, and because of this it is possible to prove the sender of the message. In other words, only the holder of the sender’s private key - which we assume was Bob himself - could have sent the message (unless he has been careless enough to provide someone else with a copy of his key). The next stage to is hash the message with the same hash function the sender used and compare the result to the message digest decrypted from the signature. If they are exactly equal, the signature has been successfully verified. If, however, they are not equal, then the message either originated elsewhere or was altered after it was signed. The final piece of the S/MIME puzzle is the trust hierarchy. This is a method based on certificates for verifying that people really are who they say they are. A certificate is a public key signed with the private key of a trusted third party such as VeriSign. Because of the importance of the trust hierarchy, S/MIME products should include a certificate management system that lets you set trust levels, but not all do. One of the best known S/MIME implementations is WorldTalk’s WorldSecure, since it is actually used by RSA as the reference implementation to certify products for S/MIME compliance. One of the neat features of WorldSecure is that it is available in both client- and server-based implementations. The problem with client-based security is that you must, by definition, install and maintain it on every single client. This is a daunting task in a large network, and one that is eliminated by the use of a server-based product like WorldSecure Server, which provides message signing and encryption capabilities for every client sitting behind it. It installs as a native NT Service, and is reasonably easy to configure using the GUI management interface. It needs to know a few things like the names of the domains and hosts the mail server will be serving, to which external servers it will allow connections, and so on. From that point on, the Policy Wizards do a good job of guiding you through the process of defining your corporate e-mail security policy. Architecturally, the product resides on the internal network, between the network's Simple Mail Transfer Protocol (SMTP) gateway and the firewall. It is designed to complement, rather than replace your existing security systems (which may include WorldSecure Client), and will interoperate with any other S/MIME-compliant package. WorldSecure Server provides the ability to encrypt and digitally sign every message going out of the organisation, as well as decrypt and verify signatures of all those coming in. It employs the S/MIME protocol to provide e-mail confidentiality and authenticity, while protecting against e-mail tampering. The server product provides company-to-company or workgroup-to-workgroup e-mail encryption and signing. In addition, WorldSecure Server can enforce desktop encryption and signing policies depending on pre-defined security policies. WorldSecure uses a trust hierarchy to specify which digital certificates (which include the public keys of their owners) are trusted, and these trusts can be created on an individual, corporate or Certificate Authority-wide basis. Both VeriSign and "self signed" certificates can be used, and once the trust hierarchy has been created, all the encryption and decryption processes are completely transparent and seamless. E-Mail Firewall WorldSecure Server offers more than simple encryption services, however. One of the problems in many corporate e-mail environments is the fact that employees are free to transmit anything they like, including scandalous or inappropriate material, corporate secrets, or even a mailshot of their CV’s to local employment agencies. The increasing use made by organisations of the Internet and e-mail makes them correspondingly more vulnerable to an ever-widening range of content threats hidden in Internet traffic. Whereas firewalls allow or deny users or services when connecting any network to another, content security ensures organisations suffer no losses through data stream content threats such as e-mail or Web viruses, confidential information leakage’s, or the spread of defamatory comments. WorldSecure Server includes a range of content scanning capabilities, together with policy-based content filtering, e-mail blocking and "spam" filtering. Changing and otherwise administering policies is a cinch, and the intuitive GUI allows centralised management of all WorldSecure Servers within an organisation. Rules are specified on a per-domain, per-user basis or per-group basis, and multiple actions can be specified for each rule, such as notify, quarantine, reject, annotate, return to sender, or defer delivery, among others. Breaches can be accidental or deliberate, of course. For instance, replying to all recipients of a message without checking the list for non-company employees may lead to an unintentional leak of confidential plans. On the other hand, the premeditated distribution of a customer database may be a calculated act of sabotage. Consequently a key content security requirement is the ability to manage e-mail transfers according to recipient, sender, file type or identification of key words in e-mails such as "top secret", "company confidential", and so on. Anti virus scanning is another vital part of content security, whether or not the content scanner uses its own or integrates with third-party scanners. The widespread use of e-mail to transmit Word documents or Excel spreadsheets as attachments has opened the way for potentially harmful viruses to be propagated throughout an organisation in one fell swoop. Even if every user has a client-based AV scanner, the result is still hundreds, or even thousands, of infected files spread throughout a company, which at the very least will result in numerous support calls, and at worst could allow some to slip through and be transmitted to customers or business partners. It is important, therefore, that AV scanning is tightly integrated with the e-mail server or content scanning engine in order to ensure that messages with infected attachments are intercepted before they get to the end user, at which point they can be quarantined and disinfected or deleted. Summary So, can we send sensitive documents by e-mail? There is no reason why not, as long as some basic precautions are taken over content security in all its forms. Although most organisations are beginning to get to grips with the concept of firewalls to protect their networks which are facing the Internet, they are still allowing e-mail traffic through those firewalls unchecked. The idea of a specific "e-mail firewall" behind the main firewall is a relatively recent one, but one which demands equal attention from those responsible for the security of their corporate data. And what about legal documents, such as contracts? As we have demonstrated in this article, most of the mechanisms already exists for us to be able to use the Internet for secure document transmission. All that remains is for the ISP’s to find a way of providing proof of delivery, and for the legal profession to catch up and give the whole thing its seal of approval.
|
|
Send mail to webmaster
with questions or
|
