WO2001008346A1 - Methods and systems for automatic electronic document management and destruction - Google Patents

Abstract

Automatic systems (200) and methods for electronic document (including records, documents, electronic mail, etc.) management and destruction are disclosed, comprising an encryption system that generates encryption/decryption keys, a key storage area (212) for storing said keys; communication media (214) whereby said keys may be disseminated to authorized user's workstation (218) within a company; and a key destroying system that destroys keys that are no longer valid. The encryption system creates encryption/decryption keys that may be communicated to a set of authorized users of the email system. Sender types in the email message in plaintext (220) at the workstation (218). The system encrypts the email message, which is subsequently sent to the recipient in its encrypted form. When the recipient opens the email message, the system uses the decryption key to decrypt the message and presents a plaintext (220) view of the message to the recipient. When the system (200) makes a backup to disk drive, tape drive, or other storage, the encrypted email message (224) is usually the object that is actually stored on the storage (222). Decryption keys are regularly destroyed in the normal course of business, thus effectively destroying the email.

Description

METHODS AND SYSTEMS FOR AUTOMATIC ELECTRONIC DOCUMENT MANAGEMENT AND DESTRUCTION

Technical Field The present invention relates to methods and apparatus for managing documents and, in particular, for automatically destroying electronic documents, such as email and other such electronic documents.

Background Art Every working business day, a typical company accumulates a large number of electronic documents. Such documents may come in the form of text files, spreadsheets, database reports, electronic mail (aka "email") and the like. These documents may either be generated internally or may be received from outside the company, typically from email messages and their associated attached file documents. The advent of the networked computer workstations has seen a revolution in the manner in which corporate communications take place. Such workstations — connected together by corporate intranets and, more generally, through internets, such as the World Wide Web — facilitate fast and inexpensive communication means, primarily through electronic mail, or email. The birth of electronic mail has, however, not come without its own concerns or problems for any corporation that allows such form of communication. Indeed, it seems that the ease of communicating between individuals with email lends itself to a false sense of security and privacy to these same individuals. As a result, email documents are invariably given to an informal, sometime shorthand, style of authorship. Emails are sometimes a stream of consciousness type of writing that reflects more the inner machinations of the author rather than factual statements reflecting the corporation.

Thus, it has come as no surprise whenever a company is sued — by either a past or present employee, or another third party individual or company ~ that internal emails of the defendant company represent a powerful weapon in the hands of a plaintiff individual or company. Such emails have been the subject of discovery motions and subpoenas; and once discovered, have sometimes made the difference between losing for lack of evidence and winning with a strong inference of wτongdoing on the part of the defendant company because of inartfully crafted emails of its employees.

The problem is that emails are not easily destroyed, even when the owner of the email has selected the DELETE option from his email menu. Figure 1 depicts the typical environment 100 in which email exists in a typical corporate intranet or on the Internet (e.g. World Wide Web). Email message 10 typically is sent from one user to another from workstations 12 communicating through a corporate intranet or Internet 14. To get an idea of how persistent email messages are, email message 10 is stored in a separate storage 16 (e.g. a mail server, if the communication net is a corporate intranet; or on an ISP server, if the net is the Internet). Apart from email message 10 residing in RAM storage when workstation 10 is ON (and the message may be displayed on screen), it is often stored on the workstation's hard drive 18. Additionally, the mail service may have the facility to backup email messages to tape drive 20. Thus, as can be seen in Figure 1, a typical email message may find itself in these and other storage areas that are not obvious to the users of the email system.

When a user desires to DELETE an email message from her email "in box", the email system may do one of many things in response to such a command. The system may deleted the email message only from the mail server or ISP server 16.

The system, thus, might leave untouched the email message stored on workstation hard drive 18 or tape backup 20, allowing these drives and backups to be later scanned ~ and the email message retrieved ~ in response to a discovery request in a subsequent litigation.

Additionally, even if the system might "delete" all emails from the various drives and backups, the manner of "deleting" such a message may only be to remove a pointer reference to the message in storage — leaving the raw data of the email message to be similarly recovered in response to a discovery request.

In November 1997, the Department of Defense (through the office of the Assistant Secretary of Defense for Command, Control, Communication, and Intelligence) promulgated a "Design Criteria Standard for Electronic Records Management Software Applications" (DOD 5012.2-STD) which purports to set out functionality requirements for software systems that manage electronic records and documents. In DOD 5012.2, record management systems "shall treat electronic mail messages (including attachments) that have been filed as records, as any other record". Another requirement of any record management system meeting this standard is that it "shall delete records and/or profiles that are stored in its repository and have been approved for destruction, in a manner such that the records cannot be physically reconstructed". Thus, any record management system meeting the DOD standard must address one of the problems; namely, that a proper DELETE command is carried out in such a manner that the underlying email message may not be physically reconstructed from the storage. However, the problem still exists in that, in order for email messages to be so treated, they need to be "checked into" the records management system, as a record itself. This requires active participation on the part of the users of the email system to recognize when an email message itself should be treated as a document or record deserving of such care and treatment. Otherwise, an email message may reside as usual on the system; and cause as much damage in subsequent litigation as before. Thus, there is a need to have an email system that destroys email documents automatically without the need to import (i.e. "check in") email documents specifically into a records management system.

Another concern of any email system that purports to effectively destroy email documents is the timing of destruction. The Federal Rules of Evidence explicitly recognizes that companies may destroy records and other documentation during the course of regular business practices. However, courts typically frown on a company's last minute efforts to destroy documents when threatened with litigation. If a company has been found to do so, a court might impose adverse consequences on such a company during litigation.

Thus, there is an additional need to provide companies a email document destruction service that seamlessly destroys an email document on a specified time interval, wherever copies of that email document reside.

Disclosure of the Invention

The present invention meets the aforementioned needs by providing a system that automatically destroys email documents ~ wherever copies of email documents may reside and without active intervention of the user/employees of the system and on a regular time basis according to a given company's specified email and document retention policy. The presently claimed email system comprises an encryption system that generates encryption/decryption keys; a key storage area for storing said keys; communication media whereby said keys may be disseminated to authorized user's workstation within a company; and a key destroying system that destroys keys that are of a specified age (i.e. after a time period during which the keys are consider to be "valid").

In one embodiment, the presently claimed system the encryption system creates encryption/decryption keys that may be communicated to a set of authorized users of the email system. For emails that are internally generated between authorized users, the sender types in the email message in plaintext at the workstation. The email system encrypts the email message, which is subsequently sent to the recipient in its encrypted form. When the recipient opens the email message, the email system uses the decryption key to decrypt the message and presents a plaintext view of the message to the recipient. When the email system makes a backup to disk drive, tape drive, or other storage, the encrypted email message is usually the object that is actually stored on the storage. Whenever a user wants to view a stored email message, the email system will provide the decryption key to that user, provided that the date (or age) of the email is still "valid", according to the time period specified by the company. If the email is still "valid", then the decryption key is used to provide a plaintext version of the message to the user. After a certain period of time, the email is no longer "valid" and the email system deletes some or all of the decryption keys earlier than the time period. As a result, with all copies of "invalid" email stored in encrypted form and the decryption key now destroyed, effective destruction of email messages occurs automatically without active participation of the users of the system. Additionally, this destruction occurs on a regular basis in the normal course of business for the company; thereby providing a way to destroy emails and other documents on a timely basis that has the best chance to pass legal scrutiny in a court of law.

In another embodiment, email messages are encrypted with a public key and after a period of time, in accordance with the document retention policy, the private key is destroyed, rendering the email effectively unrecoverable and destroyed. In yet another embodiment, computer files are encrypted with a public key and, as part of a company's document retention policy, the private key necessary for decrypting the files is destroyed.

Document retention policy involves setting a lifetime for documents and an intention to destroy or render illegible the documents. Documents may refer to email or computer files. Document destruction may occur after a predetermined amount of time, at a predetermined date, or upon some other event defined in the document retention policy. Destruction of the private key of a public-private key pair created for an asymmetric cryptographic algorithm render documents encrypted with the public key effectively destroyed. Since access to an encrypted document required decryption, and decryption requires use of the private key, this invention provides for a key server. Nodes request decryption of a document by sending a message to the key server and receiving a response. The response is either a denial of service or a granting of service with sufficient information to decrypt the document, but not providing the node with the private key.

In one embodiment, similar to S/MIME digital envelopes, a document is encrypted with a symmetric session key. The session key is separately encrypted using the public key corresponding to the key server's private key. To decrypt the document, the encrypted session key is sent to the key server and the plaintext session key is returned to the requestor if access is granted.

The session key decrypted by the key server may be transmitted in the clear since interception would only compromise one document and not the private key. Secure transport may be used to prevent this interception. In another embodiment, the key server may re-encrypt the session key with the requestor's public key - a public key for which the recipient holds the private half, such as a certificate from a certificate authority ("CA"). Thus, only the recipient can decrypt the message from the key server and recover the session key required to complete the decryption of the document.

In yet another embodiment, the requestor may sign the request message with his/her private key or in some other way identify him/herself. The key server may take the identification explicitly provided in the request or implicit in the requestor's digital signature and test to see if the request is authorized to decrypt the document. The key server may then use that identification to encrypt its response to the requestor using the requestor's public key.

In an embodiment involving more than one public-private key pair used for document retention, the encrypted document and the decryption request message may contain the public key, or another datum, which the key server can use to identify the public-private key pair and so select the correct private key for decryption.

One advantage of the present invention is ease of use. The present invention automatically and effectively destroys electronic documents (in particular, email) without the active participation of the user of the system. The encryption and decryption mechanisms preferably take place unbeknownst to the user. The only impact on the user is that, after a certain time period has elapsed, the user may no longer access the email or document — it is effectively destroyed as an encrypted file on the system. Another advantage of the system is regularity. Once the company decides for how long documents such as email should be accessible to the company, the present invention automatically and effectively destroys documents that exceed that time period. This regularity allows a company engaged in litigation a document destruction policy that will be better able to withstand judicial scrutiny — and avoid the potentially downsides to having been adjudged destroying documents in the face of impending litigation.

Yet another advantage is ease of destruction. The present invention effectively destroys documents by destroying a set of decryption keys that are at or over a certain age. There is no need to rewrite areas of memory with random patterns to insure that all copies of the email cannot be effectively physically reconstructed. Thus, email messages do not need to be "checked in" or "out" of a records management system, in order to keep track of each and every plaintext copy of the message.

Brief Description of Drawings Figure 1 depicts the typical environment of an email system.

Figure 2 shows one embodiment of the email/electronic document system, as constructed in accordance with the principles of the present invention. Figure 3 is a flowchart depicting one embodiment of how a user composes an email message at a workstation.

Figure 4 is a flowchart depicting one embodiment of how an email is read by an authorized recipient/user. Figure 5 is a flowchart depicting one embodiment of how the encryption/decryption keys are managed in accordance with the principles of the present invention.

Figure 6 is a block diagram of a network, user nodes, and key server node showing communication channels and storage locations. Figure 7(a) is a flow chart showing the creation of a key pair for the invention.

Figure 7(b) is a flow chart showing a process of destroying old private keys.

Figure 8 is a flow chart showing the receipt of a public key by a U A for the invention.

Figure 9(a) and 9(b) are flow charts showing the invention in use in a UA when sending an email message.

Figure 10(a) is a flow chart showing how the invention's key server might associate a user with authorization to decrypt some messages or files.

Figure 10(b) is a flow chart showing how the invention's key server might handle a request by a user to decrypt a message or file. Figure 11 is a flow chart of a receiver's UA using the invention to restrict or grant access to an email message.

Best Mode for Carrying Out the Invention

Referring now to Figure 2, there is shown one embodiment of an email system, as practiced in accordance with the principles of the present invention. Email system 200 comprises a key server 210 and key storage 212 connected to communications medium 214. Keys are generated by key generator 216 and communicated to the work environment through medium 214 to workstations 218. As shown in Figure 2, email messages are displayed in plaintext 220 on the workstations; but are backed up to local storage 222 in its encrypted format. Optionally stored at local storage 222 is local key storage 226. This optional local key storage 226 may aid in facilitating the quick generation of emails at the workstation without the need to query the key server for the current keys.

Key storage 212 at the key server maintains keys that have been used to encrypt and decrypt emails for a specified period of time. While these keys are maintained in storage, any email message may still be "valid" ~ i.e. a decryption key is retrievable so that the email message might be decrypted and displayed to the user. Such a time period may be, but not necessarily, decided by the company running the email system in order to effect a document destruction policy. It will be appreciated that the keys generated by the present invention are to be construed very broadly. Such keys may be a single cipher key used for both encryption and decryption. Alternatively, key generator 216 might generate public/private key pairs whereby emails are encrypted with one key and decrypted with the other. Thus, the present invention should not be limited to the choice of any particular encryption method known in the art; and the scope of the present invention contemplates the use of any suitable encryption method. For purposes of present discussion only, a public/private key system is described below.

Communication medium 214 is likewise to be properly construed broadly. Medium 214 may be either a private inter/intranet or a public inter/intranet (to include the Internet). Similarly, it is unimportant to the present invention whether the medium is either secure or insecure as a communication medium, as the destruction of the emails and other documents is as secure as the type of encryption scheme used. Storage 228 for medium 214 might then be either mail server storage or ISP storage or any other suitable mail storage. It will also be appreciated that key server 210 may be embodied as a software process running internally to the company and may reside within the company's mail server itself. Alternatively, key server 210 might be a stand-alone server (possibly on the Internet) supplying keys to client companies. Thus, the scope of the present invention contemplates that key service may be supplied by a software package sold to the company directly, or as a service rendered in electronic commerce to a client company, or any combination of the above. Figure 3 is a flowchart depicting one embodiment of how a user composes an email message at a workstation. At step 300, the user starts the email interface program and composes an email message in plaintext on screen at 302. At 304, email interface program obtains the current encryption key. It will be appreciated that the current key may be obtained in a number of ways, including from the optional local key storage 226 or from key service 210. The email message is then encrypted with the key at step 306. Now, to send, each intended recipient of the email is checked to see if the recipient is an internal, authorized user of the email system at 308. If the recipient is not an authorized user (e.g. an entity outside the company, possibly on the Internet), then the email message is sent out plaintext at 310. If the recipient is an authorized user, then the encrypted email is sent at 312. As an alternative embodiment, emails may be sent out of the company encrypted; and the outside recipient must obtain the decryption key from the key server. In yet another embodiment, emails are always encrypted inside or outside the company and all recipient must acquire the decryption key.

At step 314, the encrypted email message is stored (in whatever form of storage) as a backup copy. It suffices for the purposes of the present invention that at least one backup copy is encrypted for some emails. Some plaintext copies of emails may reside on the system so long as they are tracked and, preferably, effectively destroyed on a timely basis.

Figure 4 is a flowchart depicting one embodiment of how an email is read by an authorized recipient/user. At step 400, the user starts the email interface program and selects an email message to be opened at 402. At this point, it must be determined whether the email message in question is still "valid" or accessible at 404. This may be accomplished in a number of different ways — validity of an email message may be determined by the date of the message (i.e. if the message is a certain age, then it is no longer valid): email system may check to see if the associated decryption key is still held in storage (either locally or at key server), or one of man> other ways that are known and obvious to those skilled in the art. In another embodiment involving asymmetric cryptography, whereby the key server holds the private key and the email message contains a session key encrypted with the public key. the recipient asks the key server to "validate" the email by testing the expiration of the private key according to the document retention policy implemented on the key server.

If the email message in question is no longer valid or accessible, then the system informs the user of this status at 406. Alternatively, any and all emails that are no longer valid may have their subject titles deleted from the list of possible emails to open at step 402. Thus, selecting invalid emails would not be an option at 402.

If the email message is still valid, then the decryption key is obtained at 408. The decryption key may of course be obtained in a number of ways ~ from local key storage or from the key server itself. Additionally, the decryption key may be associated with any particular email in any number of way ~ the email's date might associate a particular decryption key with that email; the email may be backed up with its encryption key and a look up (either locally or at the key server) is performed to locate the decryption key. It will be appreciated that many other ways are known and obvious to those skilled in the art and that the scope of the present invention should not be limited to any one particular method. In some embodiments, the mail header may identify the encryption key.

Once the decryption key has been secured, the encrypted email message is decrypted and is presented plaintext to the user at the workstation at 410. Preferably, the entire process of encrypting and decrypting is completely transparent to the user. From the user's standpoint, only plaintext messages are composed, sent or stored in the system — and. hence, the user is never bothered with the details of electronic document retention and destruction. That is, preferably, there should be no need for explicit mechanisms to promote emails to document status; then to be managed as a document by a records management server. Of course, some emails, if deemed important, could be promoted to a record and handled accordingly.

As another embodiment — for emails arriving from outside the email system (e.g. from individuals on the Internet), the email system may intercept them as they arrive, encrypt them, and send them to the authorized user who then needs the decryption key to view the outside email in plaintext. Figure 5 is a flowchart depicting one embodiment of how the encryption/decryption keys are managed in accordance with the principles of the present invention. At step 500, key server generates new encryption/decryption keys for a new time period. This time period preferably should be frequent enough so that security of the encrypted email stored throughout the system is relatively strong. It is generally the case that the more raw data encrypted with a key is found and recovered, then the encryption is possible less secure (e.g. possibly subject to a statistical attack). This time period, of course, could vary from every few moments, a few hours, or even a few days, depending on the underlying security of the encrypted emails.

At 502, these new encryption/decryption keys are disseminated to the authorized users of the system. Any new emails generated at this time will use the new encryption key; and any new emails received will be decrypted by the new decryption key. It will be appreciated that the manner of disseminating the new keys may be accomplished in a number of ways — the keys may be broadcast too all of the authorized users of the system; users who desire email transactions may query for the current keys; and any other ways that are known and/or obvious to those skilled in the art. The decryption key may be disseminated to all, or some of the users, but holding the decryption key preferably in only one location makes destruction easier. However, caching the decryption key locally might speed the email system.

Once the new keys have been generated, then at least the decryption key is stored in key storage (or in other storage) at step 504. While new keys are added to storage, old keys that are designated as no longer valid are deleted from key storage at 506. The validity period is preferably selected by the company so as to affect their document retention and destruction policy. Such a validity period might conceivably range from a few days, a few months, to a few years.

AN ALTERNATIVE EMBODIMENT Figure 6 depicts a diagram of a network that connects two user nodes 610 and a key server 620. Although only two user nodes are shown for clarity, if should be apparent that many more nodes are possible. Messages exchanged between user node 1 and user node 2 may be placed in local storage 611 on either or both nodes, and that storage may be backed up to offline storage 612 on either or both nodes. Furthermore, within the network 630, a number of mail transfer agents 640 may hold email in local storage 641 or backup 642. The present invention will render all copies of a document or email destroyed without access to all of a document's or email's instances.

Figure 7(a) shows the creation of a key pair for use in implementing the invention. The public key is referred to as DIEpu and the private key is referred to as DIEpr. This flow chart is similar to the well understood process of creating personal certificates for use by a certificate authority (CA) in a public key system, except that the private key, DIEpr, remains on the key server and is never delivered to an individual. Step 702 represents the asymmetric key pair generation. Step 703 is the publication of the public key, DIEpu. In one embodiment, this is done in the same manner as personal certificates: through a CA, RA, PKIX. or delivered by email. The DIE certificate in step 703 contains the same signature by a trusted authority, typically the key server, as does a personal certificate. Unlike personal certificates and their corresponding private keys, in step 704 the private key DIEpr is kept on the key server's database storage and backup as represented by elements 621 and 622 of Figure 6. Recorded with the DIEpr is an expiration time and any other data required by a document retention policy as well as the public key DIEpu.

Figure 7(b) shows the destruction of private keys on the key server in accordance with a document retention policy. This process occurs at a regular or scheduled interval. Steps 712, 713, 714 and 715 implement a loop that steps through all key pairs on the key server. For each key found to have expired in step 713, all instances are removed from the key server's database and storage in element 621 by step 716. Upon completion of the loop in step 714, all expired private keys that occur in any backups or other storage represented by element 622 must be destroyed in step 717. This may be accomplished by erasing all backups. In another embodiment, keys may be sorted or segregated by expiration date and backups would only contain keys expiring in the same time interval, so destruction involves only erasing the appropriate backup(s).

Figure 8 shows how a UA (i.e. user application, typically a mail client) can acquire a public key required by the invention. It will be apparent to one skilled in the art that a mail UA can acquire a public key in the same manner as a UA can acquire a personal certificate with public key. for example by email, through a certificate directory or hierarchy, a CA or RA or any other means developed in the future. However, in the present invention, the public key and certificate is not associated with another user, rather it is associated with a document retention policy. A UA may hold more than one public key and so participate in more than a single document retention policy. In step 805, the public key is stored such that the user can select a public key by action or default and so choose a document retention policy to apply to the email under composition. Different document retention policies may entail public keys with different expiration dates or access lists. Selection of the invention's public keys is different than the current practice of selecting the personal certificate and public key of the recipient. Figure 9(a) and 9(b) show the application of the invention's public key in encrypting an email. One skilled in the art will recognize that steps 903 through 906 and 913 through 917 represent encryption of email using S/MIME digital envelopes. Steps 902 and 912 differ from standard S/MIME implementations, where the public key used for encryption of the session key for the digital envelope is retrieved from the receiver's personal certificate. In the invention, the recipient does not have the private key corresponding to the encrypting public key. In steps 906 and 916, the message must contain sufficient information to identify the intended recipient and the public key used by the invention for encryption. It will be apparent to one skilled in the art that this can be accomplished in any number of ways such as recording the information in the message header outside of the encrypted message. In Figure 9(b). the preferred embodiment starts at step 91 1 with a signed or unsigned message. In Figure 9(a). another embodiment, the message may have been encrypted or signed and encrypted prior to encryption by the present invention.

Figures 9(a) and 9(b) are not meant to limit the application of the invention to S/MIME encryption or to implementations where digital signatures are applied before encryption. Details apparent to one skilled in the art such as conversion of the message to canonical form and transfer encoding is omitted from the flow charts so as not to obscure the present invention.

Figure 10(a) shows adding the name of an authorized user to a list for a DIEpr key on the key server. Start in step 1001 with an authorized request to add a user's name to the list of authorized users for a private key used in the invention. The request could come through a secure channel, a secure email, or be initiated by an authorized administrator at a secure terminal. If the request comes with a certificate for the user, then said certificate shall be validated. In the preferred embodiment, the request identifies the DIEpu-DIEpr key pair and the user such that the DIEpr can be identified and the user's personal certificate with public key can be retrieved. In another embodiment, the user's personal certificate is not used. The DIEpr key is identified and tested for validity, expiration date, and accessibility rights. If the key has expired or the key server determines that the user may not be granted access to the key, then the operation ends. Otherwise, the user's identify and personal certificate with public key is added to a database on the key server in step 1003. A DIEpr may have any number of users or domains of users authorized to use it. Use of a particular private key entails having the key server decrypt a packet encrypted with the key's public variant, DIEpu, typically toward the aim of recovering a session key used to encrypt a document. A user may be authorized for any number of DIEpr private keys. One skilled in the art can implement a data structure to associate user's identification, certificates, public keys, and DIEpr private keys with access rights to support the needs of the invention. The data structure is stored on elements 621 and 622 of Figure 6. In the preferred embodiment, the data structure will not hold the real key DIEpr, but will hold an ID that permits retrieval. The goal is to reduce the number of instances of the key DIEpr on the key server. Figure 10(b) shows the process for handling decryption requests, typically for session key recovery, on the key server. In the preferred embodiment, the decryption request message (decrypt-req) comes over a secure connection from the UA to the key server. The message contains three components: an identification for the requester, an identification of the DIEpu used, and a payload. The payload is the session key used to encrypt the document, itself encrypted with the public key DIEpu. One skilled in the art will see that the payload is the first part of a MIME multipart/encrypted message and recovery of the session key is required to decrypt the second part of the MIME message, the real document. One skilled in the art will also know how to implement a decrypt-req message which identifies the requester and DIEpu used to encrypt the session key. This present invention is not restricted to the described means of constructing or communication the decrypt-request message. The channel from the UA to the key server may be secure or insecure. The decrypt-req message may be plain-text, encrypted by the transport, encrypted with a key, and/or signed b> the requester. In step 1013, the DIEpr private key's expiration date is checked. If the key has expired, or if the key no longer exists, then decryption is refused and a message is sent to the requesting UA in step 1018. If the key has not expired, then the authorization database or data structure referenced is step 1003 of Figure 10(a) is searched in step 1014 for a record describing the requester's access rights. If the requester is not authorized to read documents encrypted with the DIEpu in the decrypt-req message, then decryption is refused and a message is sent to the requesting UA in step 1018. If the user is authorized, then the key server decrypts the payload in step 1015 using the private key DIEpr. In the preferred embodiment, the payload is encrypted again in step 1016 with the requester's public key from his/her personal certificate in the key server's database and returned to the requestor in step 1017. In the preferred embodiment, the response from the key server to the U A looks like the first part of an S/MIME multipart/encrypted message, that is a session key encrypted with the requester's public key. In another embodiment, the session key is not encrypted when it is returned to the UA. Either a secure transport such as SSL is employed or the session key is sent in the clear, permitting an eavesdropper to retrieve the session key and decrypt one document.

Figure 11 shows the decryption of an email at a UA. One skilled in the art will observe that the flow follows a general S/MIME decryption process with the change that recovery of the session key encrypted with an asymmetric public key occurs at the key server rather than at the UA. The UA requests decryption of the first part of the S/MIME multipart/encrypted message in Step 1 104 in order to recover the session key used to encrypt the second part. The decrypt-req message generated in step 1103 includes the some identification of the requestor and identification of the DIEpu public key used to encrypt the session key. In another embodiment, the decrypt-req message is signed by the requester's private key. The UA receives the session key from the UA in step 1107, or the service is denied by the key server and the UA receives notification of such in step 1106. The session key received in step 1 107 may have been encrypted by the key server with the requester's public key in a form similar to the first part of an S/MIME message. One skilled in the art can retrieve the session key in step 1 107 and use it to decrypt the document in step 1 108.

Claims

1. In a network connecting a plurality of users whereby said plurality of users may communicate by electronic mail, a system for automatically destroying email messages, said system comprising: a key generator, said key generator generating associated encryption/decryption keys; a key storage area for storing said decryption keys; whereby said system is connectable to a communication medium whereby encryption/decryption keys may be disseminated to said plurality of users; whereby said email messages are encrypted by said encryption key for sending said message and said associated decryption key is used to decrypt said message; and further wherein said encrypted email message is stored for retrieval and said associated decryption key is destroyed after a pre-selected period of time.

2. The system as recited in Claim 1 wherein said encryption key and said decryption key are the same key.

3. The system as recited in Claim 1 wherein said encryption key and said decryption key are different keys.

4. The system as recited in Claim 1 wherein said system resides on a user's network.

5. The system as recited in Claim 1 wherein said system is a service that resides on the Internet available for subscriber users.

6. The system as recited in Claim 1 wherein said users select the time period during which said associated decryption key is available for decrypting said email message.

7. The system as recited in Claim 7 wherein said users select said time period for each said email message according to a retention policy.

8. The system as recited in Claim 1 wherein said email messages are saved to user storage in encrypted form and later requests to open said email messages require said decryption key.

9. A method for automatically destroying electronic documents, said electronic documents comprising email messages; the steps of said method comprising: for each electronic document, generating an encryption key and associated decryption key; encrypting said electronic document with said encryption key; sending said encrypted electronic document to at least one recipient; upon request of said recipient to open said electronic document, sending said associated decryption key to said recipient for decrypting said electronic document; storing said associated decryption key for later requests to open said electronic document; and destroying said associated decryption key after a pre-selected time period.

10. The method as recited in Claim 9 wherein said encryption key and said associated decryption key are the same key.

1 1. The method as recited in Claim 9 wherein said encryption key and said associated decryption key are different keys.

12. The method as recited in Claim 9 wherein said method further comprises the step of storing said encrypted electronic document for later requests for opening.

13. The method as recited in Claim 9 wherein electronic documents are received into a network of connected workstations of authorized users from outside workstations; said method further comprises the steps of: receiving an electronic document from an outside workstation; generating an encryption key and an associated decryption key for said outside electronic document; encrypting said outside electronic document with said encryption key; sending said encrypted outside electronic document to at least one authorized user; upon request of said authorized user to open said outside encrypted electronic document; sending said authorized user said associated decryption key; storing said associated decryption key for later requests to open said electronic document; after a pre-selected period of time, destroying said decryption key.