JP2002535922A - Simplified procedure for private communication - Google Patents

Abstract

(57) [Summary] A system for securely transmitting an information package (10) to a recipient via a network (108), and examining a directory (112) to determine whether the recipient has a public key And an escrow key management means coupled to the directory interface (110) and configured to provide an escrow encryption key for encrypting the package (10). (116), an encryption module (114) coupled to the escrow key management means (116) and configured to encrypt the package with an escrow encryption key, and a recipient coupled to the encryption module (114). A computer readable medium (118) configured to store the package (10) in an escrow for the computer and a network (108) coupled to the computer readable medium (118). A notification module (120) configured to send a notification to the recipient, and coupled to the notification module (120) to issue a new public and private key to the recipient in response to the receipt notification of the notification from the recipient. A key registration module (124) configured as described above, and coupled to the key registration module (124) and the computer-readable medium (118), configured to transmit the package (10) to the recipient over the network (108). A transmission module (122).

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to encrypted communications, and more particularly, to systems and methods for simplifying procedures for public key encrypted communications.

[0002]

[Prior art]

In symmetric key encryption, both the sender and the recipient of a message use the same secret key. The sender encrypts the message using the secret key, and the recipient decrypts the message using the same secret key. However, difficulties arise when the sender and receiver attempt to determine a secret key without being found by a third party. For example, if the sender and recipient are in separate physical locations, they must rely on telephone systems and other transmission media communications to prevent the disclosure of secret keys. If a third party intercepts the secret key, the third party will be able to read, modify, and forge all messages that have been encrypted or authenticated using the secret key.
For this reason, symmetric key encryption systems present a difficult problem with key management.

[0003] Public key encryption has been developed as a solution to this key management problem. In public key encryption, two keys are used: a public key and a private key. The public key is made public and the private key is kept secret. Public and private keys are mathematically related to each other, but it is virtually impossible to derive either from the other.

When sending a private message using public key encryption, the message is encrypted using the recipient's public key (which is freely available),
Decrypted using a private key known only to the recipient. All the sender needs is to know the recipient's public key, and the private key is never transmitted or shared.

[0005] Private key encryption has the additional advantage that a digital signature can be generated compared to symmetric key encryption. One of the key issues with encryption is determining whether an encrypted message has been forged or modified during its transmission. As described above, if the symmetric key is lost or stolen, the owner of the symmetric key can forge a message or make changes to the authentic message.

[0006] However, using a public key, a sender can digitally "sign" a message using the sender's private key. afterwards,
The recipient uses the sender's public key to verify that the received message was actually sent by the sender and was not modified during transmission. Thus, the recipient can be confident that the message was actually sent by the particular sender and has not been modified during transmission.

[0007] Despite its many advantages, public key encryption presents three basic problems. First, to send a private message, the sender must know the recipient's public key in advance. Conventional public key systems typically rely on a public key address book maintained locally at the sender. For this reason, if the recipient's public key is not in the sender's address book, the sender must contact the recipient by telephone or e-mail, for example, to request the recipient's public key. No. Such systems are cumbersome and inconvenient, and hinder the widespread adoption and use of public key cryptography.

[0008] More fundamentally, another problem with public key encryption is that the recipient must first have a public key in order to receive the encrypted message. At the moment, only a small number of users have obtained public keys because the technology is relatively new. This fact alone,
It presents a major barrier to the adoption of public key encryption. This is because the sender cannot encrypt the message to the recipient until the recipient has completed the process of obtaining the public key.

Yet another problem with public key cryptography is that public key "spoofing" is relatively easy. In other words,
A first user publishes his public key under the name of a second user,
It is possible to receive personal communications addressed to other users. Various solutions have been proposed to address this problem, such as digital certificates or certificate authorities (CA's), but such solutions are not relevant to the application.

[0010]

[Problems to be solved by the invention]

Thus, a system and method for securely transmitting an information package using public key encryption, wherein the system and method do not require the sender to know the recipient's public key before transmitting the information package. Is needed. Indeed, there is a need for a system and method for securely transmitting an information package using public key encryption, wherein the system and method do not require the recipient to have the public key before transmitting the package. Have been.

[0011]

[Means for Solving the Problems]

The present invention solves the above-described problems by providing a system and method for securely transmitting an information package (10) to a recipient over a network (108). According to the present invention, the public key directory (112) is consulted to determine whether the recipient of the package (10) has the public key. The directory (
If the recipient does not have a public key during 112), the package (10) is encrypted using an escrow encryption key. Then the package (10)
Are stored in the escrow for the recipient until the notification to the recipient and the acknowledgment from the recipient are completed. A notification such as an E-mail message is sent to the recipient of the package (10) in the escrow. A new public and private key is issued to the recipient when the recipient is notified that the notification has been received.
Thereafter, the recipient's new public key is added to the directory (112),
Subsequent packages (10) to the recipient can be encrypted using the recipient's public key. Finally, the package (10) is sent to the recipient.

Further, according to the present invention, the information package (
A system (100) for securely transmitting (10) a directory interface (110) configured to consult a directory (112) to determine whether a recipient has a public key, and the directory interface (110). An escrow key management means (116) coupled to the face (110) and configured to provide an escrow encryption key for encrypting the package (10), and coupled to the escrow key management means (116). An encryption module (114) configured to encrypt the package (10) using the escrow encryption key, and the package (10) coupled to the encryption module (114) in an escrow for the recipient. A computer readable medium configured to store (i.e., a medium readable by a computer) (118) and coupled to the computer readable medium (118); A notification module (120) configured to send a notification to the recipient via the network (108); and a new public key coupled to the notification module (120) and responsive to the notification of receipt of the notification from the recipient. And a key registration module (124) configured to issue a private key to the recipient
A transmission module (122) coupled to the key registration module (124) and the computer-readable medium (118) and configured to transmit the package (10) to a recipient over the network (108). It has.

By using the present invention, the sender does not need to know the recipient's public key before sending the package (10). In fact, the recipient has the package (10)
Does not need to have a public key before it is sent. If the recipient does not currently have a public key, a new public and private key will be issued to the recipient, and the public key will be stored for future reference. This allows subsequent personal communications to be encrypted using the recipient's public key. Thus, the present invention removes a major barrier to employing public key encryption, while improving the security of personal communications.

[0014]

BEST MODE FOR CARRYING OUT THE INVENTION

Here, a preferred embodiment of the present invention will be described with reference to the drawings. In the figure, the same reference numerals indicate the same or functionally similar components. Also, in the figure, the leftmost digit of each code corresponds to the figure number of the drawing in which the code was first used. Please refer to FIG. The figure shows a functional block diagram of a secure communication system 100 for transmitting information packages according to one embodiment of the present invention.

The main components of the system 100 are a transmitting system 102, a server system 104, and a receiving system 106. The transmitting system 102 is coupled to the server system 104 and the server system 104 is connected to the receiving system 106 via an “open (ie, open)” computer network 108 such as the Internet.
Preferably, all transmissions over the network 108 are S / MIME (Secure Multipurpos
e Internet Mail Extension) and / or a secure protocol such as SSL (Secure Sockets Layer).

The sender system 102 is used by a sender to securely send an information package to at least one intended “recipient” (alternatively referred to herein as a “recipient”). In one embodiment, the transmission system 102 includes a directory interface 110 for communicating with an external public key directory 112 via a network 108. The directory 112 is a database of registered recipient public keys that can be selectively queried to determine the public key of each recipient of the information package. Preferably, the directory 112 can be queried using the recipient's e-mail address.

In one embodiment, public key directory 112 is located, for example, in VeriSign, Inc.
Implemented using the existing online directory infrastructure provided by. (Mountain View, California). However, in an alternative embodiment,
The directory 112 is implemented using a conventional database system, such as the database system available from SyBase, Inc. (Emeryville, California).
However, other databases can be used without departing from the spirit of the invention. Preferably, the directory 112 is an LDAP (Lightweight Directory Access).
Protocol) using the directory interface 110.

The transmission system 102 also includes an encryption module 114 for encrypting the information package 10. The encryption module 114 is connected to receive an escrow encryption key from the escrow key manager 116, as described in more detail below. Preferably, the encryption module 114 is, for example, RSA Data Security, Inc. (San Mateo, Ca.
lifornia) using a public key encryption system. But,
In an alternative embodiment, a symmetric key algorithm such as DES (Data Encryption Standard) is used. Preferably, each of the encrypted packages 10 is a well-known package in the art.
Complies with the S / MIME standard. In addition, it is preferable to use a key length of at least 128 bits (for symmetric keyed encryption) to provide a high level of data security.

The escrow key manager 116 generates and / or stores keys for use in encrypting and decrypting information packages to be stored in escrow. In one embodiment, the escrow key manager 116 is a process running on a separate escrow key management server (not shown), and the encryption module 114 communicates with the escrow key manager 116 over the network 108. . Alternatively, the escrow key manager 116 includes the transmitting system 102, the server system 104
Or a functional unit contained within one or more of the receiving systems 106.

The encryption module 114 is coupled via a network 108 to an escrow storage area 118 in the server system 104. In one embodiment, the escrow storage area 118
Is a database for storing encrypted information packages, for example
Managed by the SyBase database system. Once encrypted, the information package 10 is transmitted using a conventional protocol such as HTTP (Hypertext Transfer Protocol) and stored in escrow until notification to the recipient and acknowledgment from the recipient are completed. Stored in area 118. However, in an alternative embodiment, the escrow storage area 118 is included in the transmission system 102 and the package 10 is notified to the recipient and authenticates the recipient as an authentic recipient. Stored locally until

The server system 104 further includes a notification module 120 for sending a notification of the package 10 to a recipient in the receiving system 106. In one embodiment, the notification is an e-mail
And the notification module 120 is provided by Microsoft Corporation (Redmond, Washington)
Although an e-mail server such as Microsoft Exchange Server 5.5 available from Microsoft Corporation, those skilled in the art will recognize that other notification systems and methods may be used within the scope of the present invention. Like.

The server system 104 also includes a sending module 122 whose purpose is to
10 consists in transmitting 10 from the escrow storage area 118 to the decryption module 126 in the receiving system 106. In one embodiment, the sending module 122 is a Microsoft Corporati
It is a standard Web server such as Windows NT (registered trademark) Server 4.0 available from on. In addition, the decryption module 126 uses Microsoft Internet Explorer®
And the like, in which case the decryption logic would be housed in a plug-in or Java applet. However, one of ordinary skill in the art appreciates that various other transmission systems and methods can be used without departing from the spirit of the invention. Preferably, communication between the sending module 122 and the decrypting module 126 is performed by HTTP using SSL. Further, in one embodiment, the sending module 122 is coupled to receive the recipient's public key from the directory 112 to prove that the recipient is an authentic recipient, as described in more detail below. You.

Notification module 120 is coupled to key registration module 124 in receiving system 106 via network 108. The key registration module 124 is configured to issue a new public key and a private key (one that no one has at this time), and further stores the recipient's new public key in a public key directory.
It is configured to automatically add to 112.

In one embodiment, the key registration module 124 uses the information package 10
Is present in the receiving system 106 before is transmitted. However, in an alternative embodiment, the notification module 120 sends the key registration module 124 to the receiving system 106 as an attachment to the e-mail notification. In yet another embodiment, the e-mail notification indicates that the recipient at the receiving system 106 is a Netscape Communications Corporation (Mountain V
hyperlinks, such as URLs (Uniform Resource Locators) that allow the key registration module 124 to be downloaded using a conventional web browser, such as Netscape Communicator®, available from iew, Carifornia).

As described above, the receiving system 106 also includes a decryption module 126 for decrypting the information package 10. Like the encryption module 114, the decryption module 126
Preferably uses a public key cryptosystem available, for example, from RSA Data Security, Inc. However, in an alternative embodiment, DES (Data Encry
It is also possible to use a symmetric key algorithm such as ption Standard).

In one embodiment, decryption module 126 is coupled to receive an escrow decryption key from escrow key manager 116. Alternatively, the decryption module 126
Is coupled to receive the recipient's private key from key registration module 124. Decryption module using escrow decryption key or private key
126 decrypts the information package 10 and provides the decrypted information package 10 to the recipient.

Preferably, the systems 102, 104, 106 described above and the public key directory 112
The escrow key manager 116 is implemented using a conventional personal computer or workstation, such as an IBM® PC compatible personal computer or a workstation available from Sun Microsystems (Mountain View, Carifornia), respectively. For example, FIG. 2 is a physical block diagram illustrating details of a further embodiment of the transmission system 102, which is similar in all respects to the system described above.

As shown in FIG. 2, a central processing unit (CPU) 202 executes software instructions and interacts with other system elements to implement the methods of the present invention. CPU
A storage device 204 coupled to 202 provides long-term storage of data and software programs, and can be implemented as a hard disk drive or other suitable mass storage device. A network interface 206 coupled to the CPU 202 connects the transmission system 102 to the network 108. A display device 208 coupled to the CPU 202 displays text and graphics under the control of the CPU 202. An input device 210, such as a mouse or keyboard, coupled to CPU 202 facilitates control of transmission system 102 by a user.

An addressable memory 212 coupled to the CPU 202
It stores software instructions to be executed by the CPU 202, and is implemented using a combination of standard memory devices such as a random access memory (RAM) and a read only memory (ROM). In one embodiment, the memory 21
2 stores a number of software objects or modules, including the directory interface 110 and the encryption module 114 described above. Throughout this description, the above-described modules are described as separate functional units, but those skilled in the art will recognize that various modules can be combined or combined into a single application or device. Will be understood.

Reference is now made to FIG. 2, a flowchart of the system 100 according to one embodiment of the present invention is shown. Referring also to FIG. 1, the transmitting system 102 first receives the recipient's E-mail address from the sender (step 302). In one embodiment, the e-mail address of the recipient is used, but the sender
Those skilled in the art will appreciate that it is possible to specify the recipient by the name associated with the -mail address or other unique identifier of the recipient. In the following, the recipient will be described as unique, but those skilled in the art will appreciate that package 10 can have multiple recipients.

After the E-mail address is received, the sending system 102 searches the public key directory 112 using the recipient's E-mail address (step 304) to find the recipient's public key. . As mentioned, this is accomplished by the directory interface 110 in the transmission system 102 accessing the directory 112 using a standard protocol such as LDAP.

A determination is then made as to whether the recipient key was found in directory 112 (step 306). If the key is found, the package 10 is encrypted by the encryption module 114 using the recipient's public key and sent to the server system 104, where it is stored as a "normal" package. You. The term "normal" is used to distinguish the package 10 from packages stored in "escrow" for recipients who do not yet have a public key. In one embodiment, a separate storage area (not shown) is provided in the server system 104 for regular packages.

Next, server system 104 notifies the recipient that package 10 is stored for the recipient (step 312). As mentioned above, this is performed in one embodiment by the notification module 120 using an e-mail notification system. However, one of ordinary skill in the art appreciates that other notification systems and methods can be used without departing from the spirit of the invention. For example, the receiving system 106 can include a notification client (not shown) that receives a User Datagram Protocol (UDP) notification from the notification module 120. Upon receiving a UDP notification, the notification client generates a visual or acoustic desktop notification to the recipient, such as an icon blink, a chime, and a pop-up dialog box. Other forms of notification include voice notification via a voice synthesis module, pager notification via a conventional pager, or facsimile notification via a standard facsimile.

After the recipient receives the notification and notifies the reception of the notification by replying to an E-mail message or the like (step 314), is the person requesting to be the recipient actually the recipient? Prove that the person is a genuine recipient to determine
Step 316). One of ordinary skill in the art will appreciate that there are numerous ways to prove that a recipient is a true recipient. For example, a password or the like can be used.

However, public key encryption provides a convenient and highly secure way to prove that a recipient is a genuine recipient. In one embodiment, the recipient encrypts the standard message using the recipient's private key and sends the encrypted message to the sending module 122 in the server system 104.
The sending module 122 obtains the recipient's public key from the public key directory 112 and decrypts the message using the recipient's public key. If the message is successfully decrypted, the recipient
You know that you have a private key corresponding to the public key in,
This proves that the recipient is a genuine recipient. The above certification step can be performed automatically by a web server and a web browser (or a dedicated software program), in which case the recipient requires little active intervention. It will be understood by those skilled in the art.

After the recipient has been successfully authenticated, the sending module 122 sends the package 10 to the receiving system 106 via the network 108 (step 318), and the receiving system 106
Receives the package 10 from the server system 104 (step 320). Those skilled in the art will appreciate that a "push" or "pull" mechanism can be used within the scope of the present invention. Preferably, HTTP and SSL are used, but other standard protocols can be used without departing from the spirit of the invention. When the package 10 is received, the decryption module 126 decrypts the package 10 using the recipient's private key and provides the decrypted package 10 to the recipient.

The above description describes the case where the recipient's public key is found in the directory 112. However, the recipient's public key is
If not, a more difficult situation would arise. In fact, if the recipient does not yet have a public key, the conventional public key system cannot send an encrypted message to the recipient at all. This represents a serious drawback of conventional systems. The present invention solves this problem by retaining the recipient's package 10 in an escrow, as described in more detail below.

Here, the process returns to step 306. If the recipient's public key is not found in directory 112, escrow key manager 116 issues an escrow encryption key and an escrow decryption key for package 10 (step 324).
). The escrow encryption key is used to encrypt the package 10 prior to storage in the escrow, and the escrow decryption key is used to decrypt the package 10.

The escrow encryption key and escrow decryption key should not be confused with new public and private keys issued to the recipient as shown in step 336. Once the escrow encryption key and the escrow decryption key have been issued to the recipient, the keys must be sent to the recipient over the network 108, resulting in the same disadvantages as symmetric key encryption. Will happen. In public key encryption, the recipient's private key should never be sent to the recipient. Thus, in accordance with the present invention, the recipient's private key is generated locally at the receiving computer 106 and only the recipient's public key is sent to the directory 112 over the network 108.

In one embodiment, the escrow encryption key and the escrow decryption key are asymmetric keys generated according to the RSA algorithm for key generation. Alternatively,
These keys can be symmetric keys. In yet another embodiment, the keys are stored (not generated) by the escrow key manager 116 and hard-coded within the escrow key manager 116 or added by an external agent or process to periodically Be updated. In yet another embodiment, the public escrow key is published in the directory 112 and the server system 104 maintains the private escrow key in a hardware device that protects it from tampering to provide the highest level of security against escrow key tampering. provide.

After those keys have been issued, the encryption module 114 in the transmission system 102
The escrow encryption key is read (step 326), the package 10 is encrypted using the escrow encryption key, and the encrypted package 10 is sent to the server system 104. Next, the package 10 is stored in the escrow storage area 118 (step 328). As described below, server system 104 keeps package 10 in the recipient's escrow until the recipient is properly registered and receives the new public and private keys.

As in the case of a regular package, the recipient is then notified that the package 10 is stored in escrow and that registration must be performed for public and private keys ( Step 330). In one embodiment, the notification is an E-mail message. The notification message preferably includes a copy of the key registration module 124 as an attachment to the e-mail message. Preferably, the notification message including the key registration module 124 is digitally signed to verify the origin of the message. However, in alternative embodiments, the notification includes a hyperlink, such as a URL, which allows the recipient to download the key registration module 124 from the server system 104 or other location.

The recipient receives the notification, sends an acknowledgment for the notification, and extracts or downloads the key registration module 124, using the key registration module 124 for new public and private keys. Register (step
334). As noted above, those keys are not the same as those issued by escrow key manager 116. Preferably, the new public and private keys are generated according to the RSA algorithm for key generation and issued locally at receiving system 106.

In one embodiment, the above registration process includes the steps of issuing a certificate to VeriSign, In
c. Procedures similar to those used by other certification bodies, with requests to the recipient for various personal data, including, for example, the recipient's name, address, telephone number, e-mail address, etc. Become. Those skilled in the art will appreciate that various procedural safeguards can be used to increase the reliability of the data obtained from the recipient.

After the recipient has completed registration, the recipient's new public key is automatically transmitted over the network 108 and stored in the public key directory 112 (
Step 335). This is an advantage. This is because subsequent packages 10 to be sent to the same recipient will be encrypted using the recipient's public key, and without the escrow key will provide a high degree of security.

The recipient is then proved to be a genuine recipient to determine if the person requesting to be the recipient is in fact a recipient. As described above with respect to step 316, the certificate encrypts the standard message at recipient computer 106 using the recipient's private key and uses the recipient's public key obtained from directory 112. It may involve decrypting the message at the server computer 102.

After the recipient is proved to be a genuine recipient, the sending module 122 in the server system 104 sends the certified recipient's package 10 to the decryption module 126 in the receiving system 106 ( Step 338). The decryption module 126 then decrypts the package 10 and provides the decrypted package 10 to a recipient. This process can be performed in a number of ways, as described below.

Reference is now made to FIG. This figure shows a first embodiment of the exchange between the transmission module 122 and the decryption module 126. First, the sending module 122
Read package 10 stored in the certified recipient escrow (
Step 342), decrypt the package 10 via the network 108 into the decryption module 126
And the decryption module 126 receives the package 10. Thereafter, the decryption module 126 reads the escrow decryption key for the package 10 from the escrow key manager 116 (step 346). The decryption module 126 then decrypts the package 10 using the escrow decryption key (step 348).

Reference is now made to FIG. The figure shows a second more secure embodiment of the interaction between the sending module 122 and the decrypting module 126. First, the sending module 122 reads the package 10 stored in the certified recipient escrow (step 350). Thereafter, the sending module 122 reads the escrow decryption key from the escrow key manager 116 and decrypts the package 10 using the escrow decryption key (step 352). The sending module 122 then re-encrypts the package 10 using the recipient's new public key (obtainable from the directory 112 or the key registration module 124) (step 354). After re-encrypting the package 10, the package 10 is sent over the network 108 to the decryption module 126, which receives the package 10 (step 356).
), Decrypt the package 10 using the recipient's private key (step
358).

The above description illustrates the operation of the preferred embodiment, and is not meant to limit the scope of the invention. The scope of the present invention is limited only by the claims. From the above description, many modifications will be apparent to persons skilled in the relevant arts, but such modifications are also intended to fall within the spirit and scope of the invention.

[Brief description of the drawings]

FIG. 1 is a functional block diagram illustrating a secure communication system for transmitting an information package according to an embodiment of the present invention.

FIG. 2 is a physical block diagram illustrating details of a further example of a transmission system according to an embodiment of the present invention;

FIG. 3 is a flowchart of a secure communication system according to an embodiment of the present invention.

FIG. 4 is a flowchart illustrating a first embodiment of a transmission module and an encryption module according to an embodiment of the present invention.

FIG. 5 is a flowchart illustrating a transmission module and an encryption module according to a second embodiment of the present invention;

[Explanation of symbols]

 10 Information package 100 Communication system 102 Transmission system 104 Server system 106 Receiving system 108 Network 110 Directory interface 112 Public key directory 114 Encryption module 116 Escrow key manager 118 Escrow storage area 120 Notification module 122 Transmission module 126 Decryption module

──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SL, SZ, TZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID , IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, NO, (72) Invention NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW Sim, Pen-To, Singapore 650103, Singapore, number 03-233, Bukit Batok Central, Block 103F term (reference) 5J104 AA16 EA04 EA16 JA21 NA02 NA27 PA07 [Continued abstract] And a transmission module (122) coupled to and configured to transmit the package (10) to the recipient over the network (108).

Claims (28)

[Claims] 1. A computer-implemented method for securely transmitting an information package to a recipient over a network, the method comprising: determining whether the recipient has a public key; Responsive to the person not having the public key, encrypting the package with an escrow encryption key, storing the package in escrow for the recipient, and providing the recipient with the package in the escrow. Issue a new public key and a private key to the recipient in response to receiving the acceptance notification from the recipient for the notification, and send the package to the recipient via the network A method for securely transmitting an information package. 2. The step of determining whether the recipient has a public key comprises consulting a public key directory for the recipient's public key.
The method of claim 1, comprising the substep of: 3. The method of claim 1, further comprising storing the recipient's new public key in a public key directory. 4. The method of claim 1, wherein the encrypting step comprises: providing an escrow encryption key and an escrow decryption key, wherein the escrow encryption key and the escrow decryption key comprise one of a symmetric key and an asymmetric key; The method of claim 1, comprising encrypting the package with: 5. The method of claim 1, wherein the notifying step comprises: sending a notification to the recipient over the network. 6. The method of claim 5, wherein the notification comprises one of an e-mail notification, a desktop notification, a voice notification, a pager notification, and a facsimile notification. 7. The method of claim 1, further comprising decrypting the package with an escrow decryption key corresponding to the escrow encryption key. 8. The method of claim 1, wherein the escrow encryption key is different from a new public and private key issued to the recipient. 9. The method of claim 1, wherein the acknowledgment from the recipient includes an indication of the recipient's name and email address. 10. In response to the recipient having a public key, encrypting the package with the recipient's public key, storing the package, notifying the recipient of the package, 2. The method of claim 1, further comprising the steps of: certifying that the user as the recipient is a genuine recipient; and transmitting the package to the certified recipient. 11. The step of transmitting the package comprises: certifying that the user as the recipient is a genuine recipient; and transmitting the package to the certified recipient over the network. ,
The method of claim 1, comprising the following sub-steps: 12. A computer-implemented method for securely transmitting an information package to a recipient over a network, the method comprising: determining whether the recipient has a public key; Responsive to the person not having the public key, encrypting the package with an escrow encryption key, storing the package in escrow for the recipient, and providing the recipient with the package in the escrow. Issue a new public key and a private key to the recipient in response to receiving the acceptance notification from the recipient for the notification, decrypt the package with an escrow decryption key, Re-encrypting using the recipient's new public key; Transmitting to a recipient, with the steps of, secure transmission method of the information package. 13. The step of determining whether the recipient has a public key,
13. The method of claim 12, comprising consulting a public key directory for the recipient's public key. 14. The method of claim 12, further comprising storing the recipient's new public key in a public key directory. 15. The method of transmitting the package further comprising: certifying that the user as the recipient is a genuine recipient; and transmitting the package to the certified recipient over the network. ,
13. The method of claim 12, comprising the following sub-steps: 16. The method of claim 12, further comprising decrypting the package using the recipient's new private key. 17. A system for securely transmitting an information package to a recipient over a network, the directory interface being configured to consult a directory to determine whether the recipient has a public key. An escrow key management means coupled to the directory interface and configured to provide an escrow encryption key for encrypting a package; and a package with the escrow encryption key coupled to the escrow key management means. An encryption module configured to encrypt a computer readable medium coupled to the encryption module and configured to store a package in an escrow for the recipient; and Combined and notify the recipient via the network A notification module configured to send; and a key registration module coupled to the notification module and configured to issue a new public and private key to the recipient in response to a notification of receipt of the notification from the recipient. And a transmission module coupled to the key registration module and the computer readable medium and configured to transmit the package to the recipient over the network. . 18. The system of claim 1, further comprising a directory coupled to the directory interface and configured to store a public key of at least one recipient.
8. The system according to 7. 19. The system of claim 18, wherein the key registration module is further configured to store the recipient's new public key in the directory. 20. The notification module of claim 1, wherein the notification module is configured to send one of an e-mail notification, a desktop notification, a voice notification, a pager notification, and a facsimile notification.
8. The system according to 7. 21. The escrow key management means is configured to provide an escrow decryption key, and the system is further coupled to the sending module to decrypt the package using the escrow decryption key. 18. The system of claim 17, comprising a decrypted module. 22. The system of claim 21, wherein said escrow encryption key and escrow decryption key comprise one of a symmetric key and an asymmetric key. 23. The directory interface and the encryption module are each configured to operate in a transmission system, and the computer readable medium, the notification module, and the transmission module operate in a server system. 18. The system of claim 17, wherein each is configured, and wherein the key registration module and the decryption module are each configured to operate within a receiving system. 24. The system of claim 23, wherein the key registration module is received by the receiving system as an attachment to a notification. 25. The system of claim 23, wherein the key registration module is received by the receiving system according to a hyperlink in the notification. 26. The transmitting module in the server system is configured to transmit the package in the escrow to the decrypting module in the receiving system, wherein the decrypting module in the receiving system comprises the transmitting module. 24. The system of claim 23, wherein the system is configured to receive the package from an Escrow key manager, receive an escrow decryption key from the escrow key management means, and decrypt the package with the escrow decryption key. 27. The transmission module in the server system receives an escrow decryption key from the escrow key management means, decrypts the package in the escrow using the escrow decryption key, and Receiving a public key from a directory, re-encrypting the package using the recipient's public key, and sending the package to the decryption module in the receiving system, A decryption module is configured to receive the package from the sending module, receive the recipient's private key from the key registration module, and decrypt the package using the recipient's private key. 24. The system of claim 23. 28. A computer program product for securely transmitting an information package over a network to a recipient on a computer readable medium, wherein the computer readable medium has a public key. Determining whether the recipient does not have a public key, encrypting the package with an escrow encryption key, storing the package in escrow for the recipient; Notifying the recipient of the package in the escrow, and in response to receiving an acknowledgment from the recipient for the notification, issuing a new public and private key to the recipient; Transmitting to the recipient via the network. A computer program product on a computer readable medium, including a program code.