Electronic messaging is vulnerable to eavesdropping and impersonation, and companies that do not protect sensitive information run a significant risk. Here we look at some of the issues associated with Public Key Infrastructure (PKI), and some less expensive options.

PKI
Secure messaging employing end-to-end architectures and PKIs offer message confidentiality through encryption, and message authentication through digital signatures. However, there are a number of implementation and operational issues associated with them.

One of the major criticisms is the overheads involved in certificate and key management. Typically, certificates and keys are assigned a lifetime of one to three years, after which they must be replaced (rekeyed). A current trend is to employ a rigorous semi-manual process to deploy initial certificates and keys and to automate the ongoing management processes. For the initial issuance, it is vital to confirm the identity of the key and certificate recipients; especially where messages between organisations are to be digitally signed.

Business partners must have trust in each others' PKIs to a level commensurate with the value of the information to be communicated. This may be determined by the thoroughness of the processes operated by the Trust Centre that issued the certificates, as defined in the Certificate Policy and Certificate Practice Statement.

The organisation's corporate directory plays a critical role as the mechanism for publishing certificates. However, corporate directories contain a significant amount of information which may create data-protection issues if published in full. Secondly, corporate directories usually allow wildcards in search criteria, but these are unwise for external connection as they could be used to harvest e-mail addresses for virus and spam attacks. Furthermore, organisations may publish certificates in different locations.

Dedicated line and routing
The underlying idea for this alternative to a fully blown PKI is to transmit messages on a path between the participating organisations that avoids the open Internet. There are two major options:

A dedicated line between the involved companies: With this option all messages are normally transmitted without any protection of content. The level of confidentiality for intracompany traffic thus becomes the same for the intercompany traffic and for many types of information that may be sufficient. Depending on bandwidth, network provider and end locations, however, this option may be expensive.

A VPN connection between participating companies: Such a connection normally employs the Internet, but an encrypted, secure tunnel on the network layer is established between the networks of participants. Thus all information is protected by encryption. An investment to purchase or upgrade the network routers at the endpoints of the secure tunnel might not be insignificant.

Most of the work to implement such solutions lies in establishing the network connection, and a dedicated line may have a considerable lead time. The same applies for new network routers as endpoints of a VPN.

Gateway to gateway encryption using TLS
Internet e-mail messages are vulnerable to eavesdropping because the Internet Simple Message Transfer Protocol (SMTP) does not provide encryption. To protect these messages, servers can use Transport Layer Security (TLS) to encrypt the data packets as they pass between the servers. With TLS, each packet of data is encrypted by the sending server, and decrypted by the receiving server. TLS is already built into many messaging servers, including Microsoft Exchange and IBM Lotus Domino, so that implementation may simply involve the installation of an X.509 server certificate and activation of the TLS protocol.

The downside is that data is protected only in transit between servers that support TLS. TLS does not protect a message at all stages during transport, unless TLS is implemented as a service in all the involved instances.

Gateway to gateway encryption using S/MIME Gateways
An obstacle to end-to-end PKI is the burden of managing certificates. Also, once encrypted, messages cannot be scanned for viruses, spam, or content. Gateways that use the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol to encrypt and decrypt messages at the organisational boundary can address these issues. S/MIME gateways use public and private keys known as domain certificates to encrypt and sign messages that pass between domains. They have the same format as those used in desktop-to-desktop S/MIME message encryption, except that the certificates are issued to domains, not individual users. Messages are signed and encrypted only while in transit between the S/MIME gateways.

An S/MIME gateway can co-exist with unencrypted SMTP messages and with end-to-end S/MIME encryption; it can send and receive unencrypted and unsigned messages to/from any e-mail domain; and it can receive messages signed or encrypted with conventional, desktop-to-desktop S/MIME. It will not decrypt the message or verify the signature, and it will deliver the message to the recipient's mailbox with the signature and/or encryption intact. However, it cannot currently sign or encrypt mail that is sent to a user in a domain that does not have an S/MIME gateway.

Pretty Good Privacy (PGP)
The OpenPGP and PGP/MIME protocols are based on PGP and rely on MIME for message structure. Today, a specialised S/MIME client can't normally communicate with a PGP client, although that may change. PGP has been described as a good example of what PKI is; but it enables the user to scale the PKI implementation from individuals to up several thousands of users. It comprises a number of products that can be implemented incrementally according to requirement.

With PGP there is no reason to hesitate to implement and make use of secure messaging capability because of cost or complexity: it's perfectly possible for the small to medium sized company to create an environment which is functional, inexpensive and easy to manage.

Attachment, encryption and compression
A number of products for document storage and communication are supplied with different types of confidentiality such as MS/Word, MS/Excel and the Adobe Family. Another collection is represented by file compressing tools. These allocate the smallest possible storage area for any number of files gathered, and are often equipped with advanced encryption capability. For example, the latest version of WinZip is supplied with 256 bit AES encryption.

There are some limitations with compression tools, in the area of secure messaging. Key handling is cumbersome and if used extensively it may cause trouble. Also, compression tools can't normally protect the actual message, just the attached file(s); and the password must be delivered to the recipient separately - preferably by phone. File compression is therefore a temporary or special solution, to be used with discernment.

Roger Dean is head of special projects, for Eema, an independent European non-profit association with a remit to educate and inform its members on all aspects of e-business. Eema also works with governments, standards bodies and its members on e-business technology and legislation. Catch up with Eema at Infosec, Europe's top information security event, on 26-28 April 2005 in the Grand Hall at London's Olympia.

This is an edited version of a report on secure messaging, produced by Eema's large multi-national user organisations. The full report is available to Eema members free, and to non-members for a small charge which can be offset against membership fees.