Information is at risk today as never before.

Data that is the life-blood of our company is being sent on its journey down the Information Superhighway in the back seat of a convertible rather than in the back of an armoured car. Anyone who is interested in our private data can simply reach into the car as we pause at the traffic lights and help himself.

Of course, we may see him doing this in the rear-view mirror, but by the time we spot the intrusion and turn round to do something about it, the lights have changed and the perpetrator is on his way – and we cannot even report the infraction because he doesn’t have any license plates!

We are constantly being reminded that it is information that gives us our competitive edge in today’s market place. Yet we are oft-times prevented from protecting that information to the extent it deserves.

When information was represented almost entirely as words on paper documents, security was relatively simple. Since there was no means to glean the information without physical access to the documents, all you had to do was lock them away in a safe or filing cabinet and ensure that only trusted personnel had a key. By carefully controlling the number of copies produced and physical access to those copies, you could thus fully control the dissemination of corporate information.

Once computers started to appear on the scene, it became far easier to make vital information readily available to a greater number of people. At the same time, security became correspondingly more difficult, though in the early days, at least the centralised computing model enforced by the mainframe made it possible to apply the same sort of access controls we had used before.

With the PC came the distributed computing model. This introduced a myriad of potential security problems, none of which were irresolvable given the control we still had over our own networks. Yet with the Internet, this distribution became global. Now any organisation could find itself transmitting vital data across a public network that is anything but secure.

Given the fact that we can no longer keep our information locked away in a filing cabinet, we must implement other means of security. We cannot ignore the convenience of the Internet, nor the cost-effective way in which it allows us to link together remote networks, sharing data around the world as if we were all connected via a single corporate intranet.

However, nor can we ignore the fact that there is a whole sub-culture which has evolved in tandem with the Internet. A sub-culture which is bent on invading our privacy, reading our mail, stealing our corporate secrets. Privacy should be a serious concern for anyone who uses the Internet.

Every time you engage in a commercial transaction of any sort on the Web, send sensitive information via e-mail, or even simply browse a Web site, you are in danger of revealing private information about yourself or your company to individuals or groups that will modify that information, sell it to third parties or otherwise use that data for malicious purposes.

The necessity of reliable, fast data interchange is the reason for the Internet’s existence. But if you cannot preserve the confidentiality and integrity of your data, then the ‘Net potentially can cause you more harm than good.

In order to move our information from the back of the convertible to the back of the armoured car, we need just one tool – encryption.

In the best tradition of the James Bond novel, encryption is all about secret codes, transforming plain text into a form unreadable by anyone without a secret decryption key. It thus allows secure communication over a general purpose insecure channel, such as the Internet.

Although the mathematics behind it can be very complex, encryption itself is pretty straightforward. Cast your minds back to when you were kids and you wanted to send secret messages to each other. The simplest form of encryption was the one where every letter of the alphabet was substituted for the one "n" positions following it.

Here we are introduced fairly painlessly to the two most important buzzwords in the cryptography world: the "key" is the number of positions we are shifting the letters, whilst the "algorithm" is simply the idea that the encrypted letter is the one "n" places following the plain text letter.

There are two ways you can beef up security on this – increase the length of the key, and devise ever more complex algorithms. Luckily, we do not have to get involved in creating our own algorithms, since there are some perfectly acceptable standards out there, the main ones being DES (Data Encryption Standard), triple DES, IDEA (International Data Encryption Algorithm) and RC4 (an algorithm developed by Ron Rivest of RSA as a stream cipher with a variable key length).

Whereas the original DES algorithm uses 56 bit keys, later and more powerful systems use much longer ones, forcing potential hackers to run through trillions of combinations in any attempt to find the right one by brute force. Triple DES is an enhanced version of the original DES algorithm and encrypts data three times using three different keys (providing an effective key length of 112 bits). IDEA is a 128 bit mechanism developed by the University of Zurich in 1992 and is a favourite of European financial institutions.

As you would imagine, the longer the key length, the more secure the encryption. Going back to our simple cipher, if our single digit key is represented by a letter of the alphabet, a potential hacker only has to try 26 possible combinations in order to crack the cipher using brute force. Now, if we increased the length of the key and wrote it beneath our original message (repeating the key over and over until it was equal to the length of the message), each character in the key would represent a different shift for the letter above. Of course, if short keys are used, then repeating patterns may begin to emerge in the message - the most secure method is to use a key the same length as the message itself, but this is impractical in real life situations. Combine long keys with sophisticated algorithms, however (something a little more complex than "shift each letter of the message by the value of the key character beneath") and you are in business.

Unfortunately, "secret key" or "symmetric key" cryptography (as it is known) clearly 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 the message. This naturally introduces a potential problem – how do we ensure that the key is distributed in a secure manner?

If we have regular contact with the person, we can pass the key face to face – you cannot get much more secure than that. In business terms, secret keys (such as bank PIN numbers) are often distributed by mail in special tamper-proof envelopes, or can be encapsulated in hardware devices such as smart cards, where the issuing authority never gives the customer access to the key information at all.

But in the case of one-off Internet transactions with hitherto unknown parties, we do not have that luxury, since as a result of the unique key-pair arrangement between the two parties, it is impossible to exchange data with someone to whom you have not already been "introduced".

Neither of you has a shared secret key, and there is no secure channel over which to exchange one. For this reason, secret key cryptography works best when a single issuing authority is maintaining a service for a user base where there is some kind of registration process that takes place prior to the exchange of information.

With "public key" or "asymmetric key" cryptography, however, 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.

The mathematics behind public key cryptography are exceedingly complex, and beyond the scope of this paper, so you are simply going to have to trust me on this one – 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. Honest – this really works.

Now, if Bob wishes to send a message to Alice (Bob and Alice are the cryptography industry’s favourite couple), 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. The best known and most widely used asymmetric key technologies are Diffie-Hellman and RSA.

Although providing the highest levels of security, public key cryptography is notoriously heavy on system resources, particularly when working on large messages. For performance reasons, therefore, RSA is usually used only to exchange keys, whilst a conventional secret-key cryptosystem (such as DES) is used for the bulk of the message.

Suppose Alice wishes to send an encrypted message to Bob. She first encrypts the message with DES, using a randomly chosen DES "secret" key which can be different for every message sent. Then she looks up Bob's public key and uses it to encrypt the DES key. The DES-encrypted message and the RSA-encrypted DES key together form a "digital envelope" and are sent to Bob. Upon receiving the digital envelope, Bob decrypts the DES key with his private key, finally using the DES key to decrypt the message itself.

Modern cryptography is very advanced, allowing us to produce encrypted data which is – to all intents and purposes – uncrackable.

Given that it is impossible to determine a private key from either the encrypted data or the public key by any straightforward computational means, the only recourse for the would-be cracker is a "brute force" attack. This involves trying all possible key combinations one after another until the message is readable, and given that we can use computers for such tasks, it is certainly possible to crack any message – eventually.

The critical factor here is key length. Each "bit" added to the key makes brute force attacks twice as hard.  Using a 56 bit key, for instance, makes the task of cracking the key 2^16 (or 65,536 for the non-mathematicians amongst you) times as hard as with a 40 bit key.  This means that DES is over 65,000 times more secure than 40 bit RC4. 

Imagine, therefore, how difficult it would be to crack a 128 bit or a 1024 bit key! This is the unpalatable prospect facing the world’s law enforcement organisations, keen to protect their respective countries from the threats of terrorism, drug smuggling, money laundering, child pornography, and so on. With a burgeoning security industry, the US Government therefore imposed export controls on such products, limiting export to products incorporating specific algorithms with fairly small key sizes (RC2 and RC4 algorithms with a 40 bit key maximum.)  

US companies were only allowed to ship more advanced encryption products - based on 56 bit DES - out of the US if they were destined for foreign subsidiaries (more than 50 per cent US-owned) or to banks. Even then, banks are only permitted to use strong encryption for actual financial transactions – they still cannot use it for normal e-mail or EDI. The American-imposed export restrictions were therefore often seen as a major barrier to the widespread adoption of electronic commerce outside the US, given that 40 bit encryption is seen as too weak for commercial use in connection with financial transactions.

For instance, in January 1997, a student at Berkeley, California, successfully "broke" a 40 bit key in 3.5 hours, using 259 Unix scale computers. This means that it would take a single computer over 37 days to decrypt just one session, which is hardly likely to provide a huge incentive for criminals to start hacking away – after all, by the time the session could be cracked, the data would be out of date or redundant. However, the mere fact that a 40 bit key has been proved to be crackable within a reasonable amount of time is enough to render it useless for many applications – particularly those in the financial sector.

This makes all commercially available products exported from the US less than attractive to a world intent on maintaining its privacy. Of course, the financial world could still use 56 bit DES – in theory, given the time to break the 40 bit key and the fact that DES is 65,535 times more difficult to crack than RC5, it would take one computer over 6780 years to decrypt a single session. 

In June 1997, however, in response to the RSA Secret Key Challenge, a team from Colorado harnessed the power of tens of thousands of computers across the Internet to break a 56 bit DES encrypted message (which ironically read "Strong cryptography makes the world a safer place"). Although the team had to search just 18 quadrillion out of a possible 72 quadrillion keys, and although such a task is clearly beyond the realms of the average hacker, such feats only serve to highlight the need for stronger encryption – particularly for financial applications.

Certain other countries – the notable exceptions being the Scandinavian nations – are considering similar legislation to the US. In March 1997, a Public Consultation Paper entitled "Licensing Of Trusted Third Parties For The Provision Of Encryption Services" was put before the UK Government by Ian Taylor, Minister for Science & Technology.

In it, Mr. Taylor states that "These proposals - aimed at facilitating the provision of secure electronic commerce - are being brought forward against a background of increasing concern, not about the technology, but about the security of information itself. In a world where more and more transactions are taking place on open electronic networks like the Internet, there has been a growing demand from industry and the public for strong encryption services to help protect the integrity and confidentiality of information. These proposals have been developed to address those concerns, but at the same time are aimed at striking a balance with the need to protect users and the requirement to safeguard law enforcement, which encryption can prevent."

The document goes on to voice the concern as to how "the spread and availability of encryption technology will affect the ability of the authorities to continue to fight serious crime and terrorism, and protect UK economic well-being and national security. In particular, the Government considers it essential that the ability of security, intelligence and law enforcement agencies to conduct effective legal interception of communications under the Interception of Communications Act 1985 is preserved in any policy proposals."

But in the light of recent events, does the argument for export controls of strong encryption hold water? At this point, things get very political, so you have to make your own decision. It is hard to believe, however, that any criminal organisation would choose to make use of an encryption technology which is known to be susceptible to data or key recovery in any form. It should also be remembered that it is possible to obtain strong encryption products anywhere in the world – Pretty Good Privacy (PGP) is the obvious example.

In other words, the only people affected by such legislation are the law-abiding citizens and organisations who wish to make use of readily-available, standards-based products.

As the US administration bows to commercial pressure from domestic encryption companies unable to compete effectively in foreign markets, there are signs that things are changing.

An executive order – regarding Administration of Export Control on Encryption Products – took effect in the US on January 1, 1997, effectively allowing all vendors to begin shipping 56 bit key encryption products world-wide providing they agree to add Key Recovery to their products within two years. Once fully compliant with the US Government-imposed Key Management Infrastructure (KMI), vendors are then at liberty to begin exporting stronger encryption, using unlimited key lengths.

This was the first proposal, which involves lodging copies of your private keys with the TTP, a secure facility which exists for the purpose of storing such keys.

Should access be required by a law enforcement agency (LEA) or other Government agency, then some form of court order or official warrant is served on the TTP. The appropriate keys are then turned over to the LEA, following which the encoded sessions can be decrypted.

In the UK, TTP’s would be licensed by the Department of Trade and Industry (DTI), and the job of issuing warrants requiring disclosure of keys to law enforcement agencies would rest with the Home Secretary.

Although the very idea of depositing private keys with a third party in this manner is unacceptable to many organisations, there is one other alarming factor which is often overlooked.

Since keys must be deposited with the TTP in advance of any encrypted communication (otherwise there is no point in making the deposit), then the only keys that can exist to be deposited at that stage are the masters. 

Once any third party has access to your master private keys, it is possible to recover the keys of any session which had been encrypted using keys derived from the master. You would thus be entrusting the TTP with the means to access all of your encrypted data – this requires a high degree of trust indeed. It also raises the question of how the TTP facilitates the provision of decrypted data to the LEA. It is unlikely, for instance, that the LEA would supply copies of the potentially incriminating sessions to the TTP, meaning that the TTP would be forced to turn over the master keys themselves. Yet once in possession of these, the LEA can decrypt all sessions – past, present and future - encrypted using keys derived from those masters without obtaining individual warrants.

The other point to bear in mind is that if you are the "innocent" party in a series of encrypted communications with someone whose keys have been turned over to a LEA, then all your sessions with that party are open to be decrypted without your knowledge – no one has to ask your permission to decrypt those sessions.

In general terms, Key Escrow represents an unacceptable invasion of privacy, and an equally unacceptable risk in lodging master keys with a third party.

Given the strong resistance to Key Escrow by both end users and the cryptography industry alike (only the NSA seems to be really in favour of it!) the TTP idea was watered down somewhat to produce the Key Recovery proposal.

With Key Recovery, it is not necessary to lodge copies of keys with the TTP. Instead, the keys used to encrypt each session are themselves encrypted using the public key of the TTP and then embedded within the session data in a Key Recovery Field.

Should the LEA require access to encrypted data, the captured session Key Recovery Field is supplied to the TTP, who uses their own private key to decrypt it. This provides the LEA with the private keys necessary to decrypt that particular session, and only that session, and is thus slightly less invasive than Key Escrow.

Key Recovery also has the advantage that your keys are never actually stored at the TTP’s facility. Thus, should that facility become a target for hackers, your own information is less likely to be compromised as a result. Of course, once the TTP’s keys are compromised, a determined hacker could use them to decrypt previously recorded sessions, and since the same private keys could be used to cover a number of clients, the loss of even one private key could leave a number of organisations open to attack.

At the moment, products incorporating Key Recovery can make use of one of three proprietary, dynamic key management protocols – Internet Security Association/Key Management Protocol (ISA/KMP) Oakley (backed mainly by Cisco); Simple Key Exchange Internet Protocol (SKIP), backed by Sun; and Photuris Session Key Management Protocol, backed by Radguard.

Trusted Third Party has been heavily criticised by most of its likely users due to the potential for the criminal element to target TTP facilities in an attempt to gain access to thousands of sets of data in a single swoop. To the hacker, TTP’s represent an extremely valuable potential single point of failure for the system as a whole, made worse by the proposal that some TTP’s would use a single key for many users. It would take only a single error or disgruntled employee at one of the TTP’s in order for a large number of keys to be compromised, with disastrous consequences.

There is also the feeling, of course, that it does not make commercial sense to allow any third party – even a "trusted" one – to hold keys which could provide access to our most sensitive corporate data.

Furthermore, in both the Key Recovery and Key Escrow cases described above, it would be possible to investigate of one of the users of an information system without the knowledge or awareness of the organisation or the individuals being investigated.  Only the Key Recovery Agent and the courts granting access would be aware that the data had been revealed to the LEA. 

A report released by a number of industry experts and scientists earlier this year cautions that "the deployment of a general key-recovery-based encryption infrastructure to meet law enforcement's stated requirements will result in substantial sacrifices in security and cost to the end user. Building a secure infrastructure of the breathtaking scale and complexity demanded by these requirements is far beyond the experience and current competency of the field."

It is worrying also that even as we see the US administration preparing to adopt a more sensible and commercially-aware approach to export controls of strong encryption, the UK Government is about to embark on its own attempt at Orwellian legislation.

The proposal by Ian Taylor MP is somewhat misleading (those paranoiacs amongst the general populous might say deliberately so) in its confusion of several important terms and issues. For instance, it talks rather grandly of a Key Recovery scheme that is of great benefit to mankind – promising that TTP’s will be able to offer interoperability of secure services hitherto unavailable. This claim is clearly spurious, given that interoperability of encryption services actually stems from adopting standard encryption algorithms (DES, IDEA, etc.) and building products to a common architecture – in other words, such interoperability is available right now, without the hindrance of TTP’s. On closer inspection, in fact, it turns out that Mr. Taylor’s proposal is nothing more than Key Escrow, which offers no significant benefits to either end-users or vendors.

It also rather worryingly confuses the roles of Certificate Authorities and Trusted Third Parties, implying that these are one and the same. Whereas admittedly it would be possible for a single organisation to offer both services, it would not be wise to confuse the valuable role of the CA with the unwelcome one of the TTP.

It is almost inevitable that the introduction of Trusted Third Party schemes will be viewed as an intrusion into individual privacy, and will thus lead to a loss in confidence in the use of cryptographic techniques. Far from encouraging electronic commerce, such an approach is likely to stifle it before it gets off the ground. 

Trusted First Party (TFP) is a much more sensible approach, and one which is receiving the backing of both vendors and end users alike. The latter, whilst not exactly happy about any enforced method of data recovery, are at least prepared to accept TFP in the spirit of compromise, and as the only means to gain access to strong encryption previously denied to them.

The US Government, for example, now requires only that an acceptable Key Management Infrastructure (KMI) is implemented before software products containing strong encryption are exported. Whilst a KMI may be based on Key Escrow if required, the US administration has also accepted the idea of a KMI using a Trusted First Party implementation.

With Trusted First Party it is still possible to retrieve keys and thus decrypt data from a particular captured session, yet this time the entire process is under the control of the end user organisation. There is no need to deposit any keys with third parties, and only the end user can obtain access to session data.

The key (pardon the pun!) to the flexibility of Trusted First Party is the idea of unique session keys. These are generated from encrypted "challenges" exchanged between the communicating parties as a means of mutual authentication at the start of the session. These challenges are combined and encrypted using the users’ secret key, and the resulting "hybrid" key is used for the duration of that session only – no two session keys are ever identical. Meanwhile, the plain text version of the challenges is included as part of the session data – this is quite safe, since it is impossible to determine the actual session keys from these without access to the secret key also.

Should an LEA wish to gain access to an encrypted session, then an electronic "recording" of that session is presented to the customer’s Key Recovery Agent (KRA) – along with a valid warrant, of course. Since the recorded session will include the plain text challenges, and since the KRA obviously has access to the secret keys, then the KRA has everything he needs to recreate the session keys.

Once those keys have been regenerated, they can be supplied to the LEA who will then have the means to decrypt that particular session – and that session only (in stark contrast to a Trusted Third Party situation). Knowing one or more keys gives no information about any of the other keys for that user or any other, and the master keys from which the session keys are derived are never revealed. All other messages which are encrypted with keys derived from the same master key thus remain fully protected. 

Providing that the end user has been approved by the US Bureau of Export Administration (BXA) and fully-auditable key recovery procedures have been put in place, the US Government will allow export of encryption products using any key length. Full support for the Trusted First Party within encryption software would allow such procedures to be implemented, thus providing the necessary ability to respond to a legally sanctioned request for keys whilst allowing the end user organisation to retain complete control over the process.

The advantages of the TFP approach are numerous and very clear – especially when compared against Trusted Third Party.

The first, and most obvious advantage, is that there is never a need to expose master keys to anyone outside the end-user organisation. It is no longer necessary to lodge copies of keys with third parties, nor is it necessary to provide master keys on even a temporary basis to LEA’s in order to recover an encrypted session.

Should a Law Enforcement Agency ever request access to encrypted data, the end user can be sure that only the specific session presented by the LEA can be decrypted, since only the session keys are released. This approach also provides tremendous flexibility over how the session data is recovered by the LEA.

For instance, the session can be provided to the customer’s Key Recovery Agent who decrypts it and passes it back. This might not suit the LEA, however, who might prefer that the KRA did not have sight of the decrypted session. In this case the session keys themselves could be released, allowing the LEA to decrypt the data at a later date. If even this level of exposure is worrying to the end user, however then another option would be to have the whole process carried out by e-mail and under control of some Key Recovery software.

In this case, the LEA could provide the recorded session along with a copy of its own public key. This package could be further encrypted using the end-user’s public key before being transmitted to the KRA. The KRA would decrypt the package and process the recorded session using the Key Recovery software. The software would automatically recreate the session keys, decrypt the session, and then re-encrypt it using the LEA’s public key before transmitting it directly to the LEA. This is certainly the most flexible approach, since it allows access to the decrypted session by the LEA without providing the KRA with sight of the suspicious session, and without releasing even the unique session keys to a third party.

Although most of the arguments for Key Recovery concentrate around the need for access by LEA’s, it should be remembered that it provides one major advantage to end users too – that of protection against key loss. The ability to recover any encrypted session internally, even when the required keys have been mislaid or deliberately hidden by a disgruntled employee, is an extremely valuable feature.

In future, it will be necessary to forge an agreement between the customer and the U.S. Department of Commerce Bureau of Export Administration before Trusted First Party Key Recovery can be implemented.

Most of that agreement will deal with secure operation of the Key Recovery software and ensuring best practices of operation.  There must be a willingness to accept the legal authority's warrant (or other document) and provide a timely response to a request for access. Once such an agreement is in place, there is nothing to prevent the supply of strong encryption software with any key length required.

Rather than concentrating on licensing Trusted Third Parties to operate Key Escrow systems, it would be preferable for the various Governments of the world to help to create a hierarchy of recognised Certificate Authorities (CA).

One potential barrier to the widespread take-up of electronic commerce is the inability to reliably identify potential users of such systems. Digital certificates bind a user identity to a public key and are then signed by the relevant CA – the resulting block of data provides the means to identify any user absolutely.

Currently these Certificate Authority requirements are being met by commercial initiatives such as VeriSign and Entrust. Some European countries, however (notably Scandanavia) are already working to establish a network of CA’s, and other countries should follow suit if the global electronic economy is to flourish.

Present uncertainty over the legal status of electronic signatures is also a potential barrier to the development of electronic commerce. Legislation to force legal acceptance of digital signatures would provide the required legal status of "signed" electronic documents, thus allowing them to be used to form the basis for legally binding contracts and agreements.

These measures would provide a framework for the increased use of electronic commerce, and together would be far more helpful than legislation of Key Escrow systems.

The almost universally hostile reaction to suggestions that encryption keys should be deposited with a US agency has led to a more considered approach by the US administration. Key Escrow – particularly where the escrow agency may be located overseas – is simply not a viable consideration for most commercial organisations.

The draconian legislation which existed prior to 1997 has done considerable harm to the encryption industry, certainly preventing the export and use of US-produced strong cryptography products around the world. If the UK introduces Key Escrow as detailed in Ian Taylor’s current proposal, then UK encryption vendors will face the same problem. Rather than promoting the export of robust encryption these proposals will damage it.  

The US administration has now recognised the commercial reality of the situation, and requires only Key Recovery and not Key Escrow for export of strong encryption. This is the only method allowing recovery of the transmitted session under the full control of the organisation operating the security system. It also provides much greater protection to individual privacy, and is thus much more acceptable to commercial organisations implementing electronic commerce.