Electronic mail - is it secure?

Author: Colin Robbins

Within certain industry sectors the use of electronic mail as a primary means of business communication is increasing rapidly. Not only is electronic mail being used for the transfer of textual messages, but the transfer of documents and spreadsheets. As the use of electronic mail increases the sensitivity of the data transferred also increases, however the integrity of this data is rarely questioned. This is clearly a problem; the door is open for eaves dropping on details of contracts between rival companies. Even worse, there is the potential for malicious modification or falsification of messages. There have been numerous reported cases of such attack, it is a certainty that even more go undetected or reported.

Security Technology.

A number of technology based solutions exist, all using a public key based cryptography solution. In these systems a user has two token keys used to secure a data source. One key is public and publicised to make it widely available, the other key is kept secret to the user. Using asymmetrical mathematical functions, the secret key can be used to sign a data stream, such as an electronic mail message. This signature (called the digital signature) is carried alongside the data when transferred. On receipt, it can then be used to verify that the message has not been altered during transfer, by using the mathematical function and this time the public key. It also proves the sender must have known the private key.

One well known set of asymmetrical functions that use this technique are the RSA algorithms. RSA is often used in conjunction with the data encryption standard DES to provide a complete security system, providing electronic mail with security services such as:

Secure Messaging The three main systems using this technique for securing electronic mail transfers are: secure X.400; Privacy Enhanced Mail (PEM) and Pretty Good Privacy (PGP).

In the PGP system, a mail user decides upon an name and then generates a public and private key pair using publicly available software for the chosen name. The private component is obviously kept secret to the user. The public key is widely published, although no formal publication procedure is in place. Typically it is posted on bulletin boards, and transferred amongst colleagues.

When a PGP message is sent, it can be signed or encrypted using the private key, with the security information being attached to the message itself in a textual format. On receipt it is validated by recovering the appropriate public key (from somewhere) and verifying the signature on the message.

This simple model has lead to a quickly growing, pragmatic secure mail community, mainly on the Internet. However the informal nature does lead to problems of scale. Names are not guaranteed unique, so there is the potential for using the wrong key to encrypt data for a particular user. More importantly, as the key publication mechanism is ad-hoc, there is no fully controlled method of recalling a key if the private key is accidentally or maliciously revealed.

X.509

These issues are addressed by the X.509 security model used by PEM and X.400. In this model, the public keys are published by certification authorities, and stored within an X.500 directory. Use of X.500 instantly ensures the names are unique. The issuing certification authorities, will typically be part of a hierarchy of authorities, making the location and validation of the public key a simple task, and more importantly allows for a key to be revoked.

Using this model, PEM secures a message in a similar way to PGP - the security information is contained within the text of the message, for example: 

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4, MIC-CLEAR
   Content-Domain: RFC822
   Originator-ID-Asymmetric: 
    MCExCzAJBgNVBAYTAkdCMRIwEAYDVQQKEwlORVhPUiBMdGQ=,2c9ee165
   MIC-Info: RSA-MD5, RSA,
    RlOWSKAGcQZpSmLcfHJYUdu4ZjrIOpci/0MhG6rzy4gsjFEjHHzMxZAL5pcBme4m
    W+jAP9JCnbFW32Xi7/pJ4w==


   This is an example clear text PEM message.  Above are the
   security headers, used to validate this message.

   -----END PRIVACY-ENHANCED MESSAGE-----
X.400 is rather different to PGP and PEM. In X.400 the digital signature is contained in the envelope of an X.400(88) message in ASN.1 (non-text) format. Putting the signature in the envelope adds extra functionality, as the whole message including subject line can then be secured, and not just selected body parts. As the format is non-text, however, the message has to be passed end to end on an X.400(88) system, it cannot be gatewayed to non-X.400(88) systems, which is currently a major practical problem.

Using the X.509 framework as a key part of the X.400 and PEM security systems does present a pragmatic problem. An X.509 certification infrastructure and X.500 directory infrastructure is required. This has the effect that systems using this technology will take longer to become established than the PGP model.

PASSWORD Project

Recognising these infrastructure problems, the European Commission has funded the PASSWORD project to set up an X.509 infrastructure, and pilot the use of security services based upon the X.509 framework.

The infrastructure set up was then used to pilot X.400 and PEM in Europe and beyond; the software has been used worldwide, including pilots at NASA and the US Navy. PASSWORD as a project has now ended, but the infrastructure still remains, and is likely to be used as the basis for projects under the new Framework 4 initiative.

Within PASSWORD, the main use of secure mail was based upon PEM, use of secure X.400 was a little less common. The major reason for this is the secure X.400 model requires use of X.400(88) end to end, however within the selected pilot communities, X.400 is often gatewayed onto the Internet, for delivery using SMTP mail. PEM however will traverse these gateways. This is unfortunate as the security service offered by X.400 has higher functionality than the PEM model, but it is a common problem.

Requiring the use of X.400(88) end to end is not a problem in specific communities where X.400(88) end to end is available, or where the gateways are capable of adding the relevant security. One such community is the US Defence community where DMS (Defence Messaging System) has been proposed. In this project there are gateways to existing systems, however, these gateways are trusted to add the required X.400 security components. NEXOR is using experience gained in PASSWORD to be a lead technical authority and software supplier in one of the DMS bids, work done by NEXOR has lead to a number of revisions to the system specification.

Secure Directories

The secure electronic mail solutions so far presented focus upon securing the electronic mail transfer between communicating parties. A secondary problem is the rise in the use of open directories (such as X.500) to support electronic mail. For example, using the NEXOR product set, if a user wishes to send an X.400 message to another user they can search the X.500 directory; visually confirm the identity of the remote user from the information presented (including a photograph in many cases); then ask the mail user agent to recover the mail address, and send the message to the identified user. This means the user does not necessarily see the mail address, which is clearly an operational advantage. However, this is also a potential weak link, as there is not necessarily a visual confirmation of the mail address. For example, if the mail address the directory returns for "President, Whitehouse" is "Hillary@whitehouse.gov" (or its X.400 equivalent) the user may not be aware the message may have gone to he wrong place.

The X.500 standard itself has mechanisms to prevent such attacks, using the X.509 model. Directory operations can all be signed so the originator of a query, and the validity of a response can be checked. In addition, using access control, the Directory can be structured to present different information sets to different categories of user. This is major component of the DMS project.

Key Management

Another important component is the secure storage of private keys. Within DMS these are stored on a hardware card called the Tessera card. For added security, the private key NEVER leaves the card, the implication is the card itself has to perform all functions relating to the key such as encrypting, signing and verifying messages.

This approach is being pushed hard in the US Federal market, and is being closely monitored within Europe as can be seen from the European Commission green paper on security.

There are however, some question over its acceptability publicly and commercially. The security algorithms are implemented in hardware, and kept a closely guarded secret. To implement a system, you buy a card from a trusted source, unaware of the exact security mechanism it uses. Will industry trust unpublished security algorithms?

Key Escrow

This also has the consequence that a third party has access to your private key in order to write it onto the card. A corollary to this is the key could be registered with an escrow agency to allow law enforcement agencies to monitor electronic mail, as proposed in the USA. Is this going to be acceptable in Europe? There are already signs that the US initiative to force key escrow upon specific communities is being toned down.

Once hardware solutions, such as Tessera or smart cards, are brought into being a security requirement, the cost of products inevitably goes up. This is being seen in many communities as one of the major blocking factors to the deployment of secure electronic mail. One of NEXORs key aims is to produce "affordable security" - to coin a phrase used by the UK Ministry of Defence in the definition of its Technology Development Program for security. Traditionally security products have been bespoke developments for specific requirements, if security is to become common, this has to turn around. Security enabling will have to be a key part of vendor product strategy.

Beyond the pilots stage

Once products are available, a commercially based security infrastructure, similar to the pilot PASSWORD infrastructure will be needed. The European Commission now looking at how the pilot infrastructures, such a PASSWORD can be extended to expand the scope of the security pilot. This will have to be combined with the developing infrastructures in the US.

So far, pilot security projects have clearly shown the technology can be made to work. Unfortunately the availability of technology is not the only issue, there are legal issues to resolve. There is confusion over what can and cannot be imported or exported across national borders. Within the US some algorithms fall under patent control. In some countries use of encryption technology is not allowed over public networks.

Despite these problems, it is looking increasing likely that a commercially based security infrastructure is not too far away. Products are starting to appear from a number of vendors. Can your company trust its unprotected electronic mail for much longer? The time is now right to start planning how secure protocols can be integrated.

Colin Robbins is a Networking Consultant for NEXOR.