August I996 Network Security

Providing Secure, Recoverable E-mail Padgett Peterson

While most of the attention lately has been focused on the polittcal aspects of cryptography, some attention has been paid to he mechanisms required for the implementation of such a scheme. To encrypt is simple, numerous means exist from simple ciphers to complex algorithms thought to require thousands of years to break. Concerns have been raised, primarily by law enforcement agencies, that widespread use of strong crypt0 will make their jobs more dlfflcult. My feeling is that ultimately strong crypt0 will be used and that will lower the demands on law enforcement, not increase them.

The rationale is simple: strong crypt0 will reduce the potential for crimes relating to electronic messaging (such as loss of sensitive/proprietary material or credit-card information). By reducing the number of crimes that are committed, those which remain, even though some will be more difficult to investigate, we require less total effort than would be required to handle more crime even if each individual investigation were easier. Further, there is a mechanism that can be used to reflect the increased difficulty: a ‘multiplier’ if crypt0 is used. Just as the severity if a crime is increased if firearms are used, increasing the severity if an offence if crypt0 is used will have the same effect without regulating cryptography in any way.

I suspect that if any notice is given by jurists to cryptography (after all, legalese is full of its own special terms and words), it will be ultimately in this manner since it also has the advantage of being able to be written in such a way as to avoid having to define exactly what cryptography is.

01996 Elsevier Science Ltd

(Most attempts thus far would also eliminate many spoken dialects.) However, once the political difficulties are solved, there is still the matter of defining procedures that could be followed within a corporation. Most mechanisms in use today require complex manoeuvring to encrypt/ decrypt. Further, until recently little thought has been given to the problem often faced by businesses: data recovery.

With the systems in use today if an executive were to become flattened by steamroller, any protected messages may be irretrievable. Similarly, an extended visit to Brazil may have the same result. In the future ‘due care’ will require that such data be recoverable by the corporation.

Some years ago a product was purchased that provided full disk encryption. Being a quality product for the time, the passphrase was not stored on the disk but instead required input from the user. If the wrong passphrase was used, the machine produced gibberish. If the user forgot/lost

the passphrase, the disk had to be reformatted.

More recently, a California company called MicroVault has what I considered to be a very good concept: the passphrase was stored in a ‘lockbox’ on the hard disk. Several sectors were allocated that contained the master disk passphrase encrypted with a corporate public key, If the user or the passphrase became unavailable, corporate representatives had the ability to retrieve the contents. Since an asymmetric key was used, no-one else could access the information.

Consequently, I have been looking at what a file and message encryption mechanism would look like. Not so much from a user standpoint since any number of mechanisms exist, but more from the standpoint of what would be required of a responsible corporation or organization for management.

I personally have been using Viacrypt’s PGP for some years (since the first commercial product was offered) and this will be the basis for the discussion that follows. Interestingly, for those who have been following ‘Clipper Ill’, my studies indicate that it would take a trivial code change in PGP itself (limited to the IDEA key generation) to make it compliant with the current US Government initiatives.

Requirements

To achieve this goal, I envision a three-tiered approach: the user, the local agency, and the corporate repository with different requirements on

15

Network Security August 1596

each. In a smaller organization, the back-up and recovery centre duties could be performed in a cooperative nature between two (or more) sites. if the size does not justify the multiple site approach than the organization would be a candidate for a Trusted Third Party (TTP) or an offsite repository for the keys.

Minimal effort should be required on the part of the user and the repository with the most effort occurring at the local site/program/ agency level. To understand how this works, first a basic understanding of how a typical asymmetric/ symmetric file/message encryption system works,

Pretty Good Privacy

The ‘freeware’ or public version of PGP has been in use worldwide since 1990 and, when properly used, can provide an acceptable level of security for transmission of all unclassified documents. In its most basic form, PGP contains three elements: an asymmetric (public/private) keying mechanism, a symmetric (IDEA) mechanism, and a key generation mechanism.

To protect a message, a user must first create a public/private key pair. The public portion may be freely distributed to all potential recipients or placed on a public key server for retrieval by any using party. The private or secret portion of the key pair must be protected from disclosure at all times (if disclosed or believed to have been potentially disclosed the key pair must be publicly revoked and a new key pair generated).

16

A message is then selected for protection and all recipients identified (the user may identify only themselves if a message is to be protected from all others). PGP then generates a random symmetric 128-bit IDEA key and encrypts the message/file. Next, the 128-bit key is encrypted via the RSA algorithm using the public key of each recipient. The IDEA key is then discarded. Finally, a header containing an identification field for each recipient and a field containing the RSA encrypted IDEA key for each is then concatenated with the encrypted file/message. The file/message may then be stored or transmitted publicly without compromising its contents.

With PGl? the easiest means to provide for data recovery is to add a ‘hidden recipient’ to every message encrypted; said recipient being the administration group. In this way, even though none of the intended recipient’s private keys are known, the message may always be retrieved by the owning organization, The capability for adding such a ‘corporate key’ is built into version 4.0.

On receipt of the file/message, their local copy of PGP will examine the message for and identification field corresponding to a secret key possessed by the recipient. If one is found, a prompt will be issued for a passphrase which, when cryptographically corn bined with the key file, will produce the correct private (secret) key which may be used to extract the IDEA session key. Once the correct key is obtained the message may be decrypted.

The prime problem is in how such a mechanism may be used. The most basic system simply adds the capability for such a key to the user version and the user may select or deselect the function. It is doubtful that such a functionality is really desired on the workstationSince most corporations can afford administrators, it is necessary that this control be exerted. Since key generation is handled by the administrator there is no need for the user to have this capability,

Further, the ability to include/exclude the corporate key should not be under user control. For the very nervous, it might be appropriate to set the workstation level distribution to refuse any message that does not include the corporate key.

Business edition Backups

At the personal level, the user most do everything. For an industrial strength mechanism, it is desirable to move certain activities from the user to a ‘more trusted’ level. Examples of such things are key .generation and management, software version control and provisions for data recovery.

‘Due Care’ requires backups, preferably offsite. Since cryptographic keys require protection against disclosure as well as against loss, the site must be carefully chosen. Logically, there are three choices that depend primarily on the size of the organization.

01996 Elsevier Science Ltd

August I996 Network Security

Trusted Third Party: for the smallest organizations a trusted third party may be used as a repository. The third party should generate a set of keys for this specific installation, and encrypt the backup keying material (keys, passphrases, and indexes) with its public key.This protects the material onsite. Secret key information necessary for decrypts should be kept in a separate secure facility.

User responsibilities

User responsibilities for the use of encryption on the workstation are as follows:

issued keys shall be kept in this repository including all revoked keys.

l To protect at all times the keys and passphrases in use, While public keys may be disseminated, they should onlybeplacedon approved keyservers and given only to those with whom company-related exchanges are expected. Private keys and passphrases must be protected at all times, specifically passphrases may not be stored in cleartext on the workstation or as environmental variables,

The local agency shall prepare all asymmetric keys for users within its area.

User keys shall be at least 1024 bits long. In addition, each agency will maintain one (or more) local data recovery keys or 2048 bits minimum length.

Peer: in larger organizations, two sites/programs/agencies could provide backup for each other provided they are not co-located. In this case, each holding site should create a separate key for each site being backed up. The public portion is given to the backed-up site which uses that to transmit to the reposing site where the package is validated.

l Should possible compromise of a secret key be suspected, a report shall be made to the local issuing agency immediately. If the issuing agency cannot be notified then corporate security shall be notified.

For each user key issued, it shall be accompanied by the public portion of one of the local agency’s data recovery key. Each workstation shall be configured such that a data recovery field in the message header contains the symmetric session key encrypted with the data recovery key.

Corporate repository. In this case, very large organizations could provide a separate business element for key repository. Again each local site would have a designated key pair used to hold the keys from that site. Each is encrypted with a corporate key that is never used outside the repository. To prevent disclosure double encryption could be used with each key half held by a different person. Since, in general, only the public keys would be used, this is feasible.

l No changes shall be made to the installed configuration without the express approval of the issuing agency.

l No message shall be prepared, stored, or sent on or from a workstation that does not contain a data recovery key issued by the local agency without the express approval of that agency.

Should a suspected compromise occur, the local agency will generate a new key pair and passphrase for the user and shall issue a revocation order against the key to all keyservers along with the new public key.

Responsibilities l User asymmetric keys shall

be at least 1024 bits long.

For the largest organizations (say, over 10 000 workstations) the following responsibility organization could be used. For smaller organizations, the corporate repository task could be handled by a different site or trusted third party.

l Software updates shall only be accepted from the issuing agency.

Local agency responsibilities

l The local agency shall maintain a secure repository for issued cryptographic keys. All

All issued keys/ passphrases shall be encrypted with a corporate repository key of at least 2048 bits and shall be forwarded internally to the designated corporate repository. Encrypted messages using the corporate repository key shall never be allowed to pass outside the corporation. If such protection cannot be guaranteed, then the encrypted keys/ passphrases will be placed on a floppy disk with the designation

01996 Elsevier Science Ltd 17

Network Security August 7996

SENSITIVE/PROPRIETARY and shall be physically conveyed to the corporate repository in a manner appropriate to that designation.

l When workstation software is issued, it shall be configured such that it is incapable of creating cryptographic keys and is incapable of preparing/sending a message/file that is encrypted without the data recovery element,

l Equipment used for the generation of cryptographic keys shall be secured in the same manner as the keys themselves.

l Software updates shall be accepted only from the corporate repository.

Corporate repository

0

0

0

0

The corporate repository shall be responsible for the retention and the safe guard of all cryptographic keys used in unclassified applications by the corporation.

The corporate repository shall provide a level of protection for corporate keys, key generation equipment, and message retrieval equipment equivalent to that used for the most sensitive material.

The person in responsible charge shall possess appropriate clearances to retain such material,

The corporate repository shall have the responsibility of ensuring that encryption is being used in the corporation in

0

l

l

l

accordance with the requirements above. This shall include the periodic random sampling of messages to ensure that the key in use is on file with the repository and that the appropriate data recovery key is in use.

All keys used by the corporation, whether currently in use, disabled, or revoked, shall be retained by the corporate repository.

Newly issued keys shall be examined to verify that they are not the same as any previously issued keys. If a match is found before release by the issuing agency, they will be notified to generate a new key and to destroy the original. If the key has already been issued, both sets will be removed from service and the issuing agency instructed to issue replacements.

On receipt by the designated corporate entity of a properly executed court order, the corporate repository shall provide plaintext decrypts of specified messages to law enforcement agencies.

The corporate repository shall generate one or more repository keys for use by issuing agencies to transmit newly issued keys/passphrases to the corporate repository. Only the public key half shall ever be permitted to leave the repository, shall be given only to corporate issuing agencies, and shall be used only to encrypt keying data and revocation orders. Such

messages shall be transmitted in a manner that ensures that such a message never leaves the physical control of the corporation. If such control cannot be guaranteed physically, then the information shall be placed on a floppy disk marked SENSITIVE/PROPRIETARY and shall be conveyed by hand in a manner approved for such material.

Procedure for the issuance of cryptographic keying

issuing agency

On receipt of a request for issuance of a cryptographic key with proper managerial approvals, the following will occur:

l

l

l

l

l

The area around the issuing machine will be emptied of uncleared personnel.

If connected to a network, the machine shall be physically disconnected.

The machine shall be rebooted in a manner such that no non-essential software including caching capability is loaded.

If the workstation is in a normally open area, then all work shall be done on a removable cartridge stored in a secure container. If the station itself is in a secure area then temporary files may be created on the local disk.

The key is generated along with any necessary passphrase. One copy of the keys/passphrase

18 01996 Elsevier Science Ltd

August 1996 Network Security

issued user identification is encrypted using a corporate repository key and transmitted via a company channel to the repository.

function to any multilevel system while confining disclosure in the event of an incident: the workstation can only disclose its own key or keys but not the issuing agencies. The issuing agency can only disclose those it is involved with, it is not even able to disclose that of the backup site. While the corporate repository contains all the keys, since additions to the database do not require opening any other element of the database, an even higher level of trust can be provided, one that does not have to rely on a single individual.

Future directions

l A delay of three days is made to allow time for the corporate repository to receive the key and verify that it does not match any previously issued keypair.

The logical future direction for E-mail would be toward integration of the encryption into the post office, removing the need for updates at individual workstations except for ‘outside’ addresses.

l A second copy is then placed as a public/private keyring pair on a floppy disk marked SENSITIVE/ PROPRIETARY. If not already included in the issuing copy of Viacrypt, the public half of the data recovery key is included in the public keyring and the appropriate configuration flag is set in the user software to ensure its inclusion in all messages/files. This disk, along with any necessary software for its use may then wither be issued to the recipient or issued to an appropriately cleared technician for installation

(at issuing site’s discretion).

Thus far, such asymmetric cryptographic mechanisms have been used only between peers for shared information. The real potential of such mechanism is for storage of multiple pieces of separately, less-trusted information. Further, since disclosure can be fully separated from addition, different levels can be assigned to each.

To achieve this, one possibility would be for the workstation to have only three public keys: that of the user, the data recovery key, and a local post office key. Messages would be composed with a mailing list and the symmetric key encrypted with the data recovery and the post office key.

Conclusions

The advantage to this three-tiered hierarchy is that it can provide a classic ‘write up/read down’ protection impossible with symmetric keying. While there are a few symmetric products that have attempted this, in order to provide ‘write up’, the prohibition against ‘read-up’ must be enforced at the workstation. Since it is at a low level of trust, this is undesirable.

There might even be applications where the reverse would be desirable. Thus far, we have only considered the case of a statistical database, the desirable result might be “anyone can read, but few can write”. Either case is supportable within a distributed hierarchy, yet, few examples exist.

On receipt at the post office, the server would use its key to decrypt the session key (note: not the message itself), retrieve each recipients’ key encrypt with each and add to the header, and then send the message. If any recipient should exist for whom the post office is unable to locate a key that addressee would be deleted from the list and a notice sent to the sender,

Similarly, there is a major need for secure E-mail in the form of distributed public key servers, While some exist, there is no formal protocol as yet for query/response. Such a protocol would not be difficult to devise under TCP/Il? it just has not been publicly addressed.

To do this would, of course, require a secure server since if its private key were lost so would all messages. However, since the post key is only used between it and the workstation and only for one-way traffic, it could be changed daily and updated on each workstation as they log in. Again, not diflcult, just not yet done.

Asymmetric keying on the other hand allows ‘write up’ while making the workstation incapable of ‘read up’ providing a necessary

Thus, the underlying mechanisms for secure user-independent messaging are all in place, just not yet exploited. My estimate for widespread use is in the range of 18 months to three years for deployment and certainly before the millennium.

01996 Elsevier Science Ltd 19