Simplified addressing for private communications

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to encrypted communication in general, and particularly to a system and method for simplifying the procedure of public key type encrypted communication. [0002]

[Conventional technology]

With symmetric key encryption, both the sender and the recipient of the message use the same secret key. The sender uses the secret key to encrypt the message, and the recipient uses the same secret key to decrypt the message. However, difficulties arise when the sender and receiver try to determine the secret key without being found by a third party. For example, if the sender and receiver are in separate physical locations, they must trust the telephone system or other transmission medium communication to prevent the secret key from being exposed. If a third party intercepts the secret key, the third party will be able to read, modify, and forge all messages encrypted or authenticated using the secret key. For this reason, the symmetric key encryption system presents a difficult problem regarding key management. [0003]

Public key ciphers have been developed as a solution to this key management problem. Public key ciphers use two keys: a public key and a private key. The public key is public and the private key is kept secret. The public key and the private key are mathematically related to each other, but it is virtually impossible to derive either of them from the other. [0004]

When sending a personal message using public key encryption, the message is encrypted using the recipient's public key (which is freely available) and uses a private key known only to that recipient. And be deciphered. The sender only needs to know the recipient's public key, and the private key is never sent or shared. [0005]

Private key ciphers have the additional advantage of being able to generate digital signatures over symmetric key ciphers. One of the key issues with encryption is determining whether an encrypted message has been forged or modified during its transmission. As mentioned 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, the public key allows the sender to digitally "sign" the message using the sender's private key. The recipient then uses the sender's public key to verify that the message received was actually sent by the sender and has not been modified during transmission. This allows the recipient to be confident that the message was actually sent by a particular sender and has not been modified during transmission. [0007]

Despite its many advantages, public key cipher presents three basic problems. First, in order to send a personal message, the sender must know the recipient's public key in advance. Traditional public key systems typically rely on the sender's locally maintained public key address book. Therefore, if the recipient's public key does not exist in the sender's address book, the sender must contact the recipient by phone or email, for example to request the recipient's public key. It doesn't become. Such a system is cumbersome and inconvenient and hinders the widespread adoption and use of public key ciphers. [0008]

More basically, another problem with public-key encryption is that the recipient must first have a public key in order to receive an encrypted message. Due to the relatively new technology, only a small number of users have obtained public keys at this time. This fact alone poses a major barrier to the adoption of public key ciphers. This is because the sender cannot encrypt the message to the recipient until the recipient completes the process of obtaining the public key. [0009]

Yet another problem with public-key cryptography is that it is relatively easy to "spoofing" public keys. In other words, it is possible for a first user to publish his public key in the name of a second user and receive personal communications addressed to that second user. Various solutions have been proposed to address this issue, such as digital authentication or certificate authorities (CA's), but these solutions have nothing to do with the application. [0010]

[Problems to be Solved by the Invention]

Therefore, a system and method for securely transmitting an information package using public key encryption, which does not require the sender to know the recipient's public key before sending the information package. Is needed. In fact, there is a need for a system and method for securely transmitting an information package using public key encryption, which does not require the recipient to have a public key before sending the package. Has been done. [0011]

[Means for solving problems]

The present invention solves the above problems by providing a system and a method for securely transmitting an information package (10) to a receiver via a network (108). According to the present invention, the public key directory (112) is examined to determine if the recipient of package (10) has a public key. If the recipient does not have a public key in the directory (112), the package (10) is encrypted with an escrow encryption key. The package (10) is then stored in the escrow for the recipient until the notification to the recipient and the acceptance notification from the recipient are completed. Notifications such as E-mail messages are sent to the recipients of package (10) in escrow. When the recipient notifies that the notification has been received, a new public key and private key will be issued to the recipient. A new public key for the recipient is then added to the directory (112), allowing subsequent packages (10) to the recipient to be encrypted using the recipient's public key. Become. Finally, the package (10) is sent to the recipient. [0012]

Further, according to the present invention, a system (100) that securely transmits an information package (10) to a receiver via a network (108) looks in a directory (112) and the receiver has a public key. It is configured to provide a directory interface (110) configured to determine if it is present, and an escrow encryption key combined with the directory interface (110) to encrypt the package (10). An escro key management means (116), an encryption module (114) coupled to the escro key management means (116) and configured to encrypt the package (10) using the escro key, and the like. A computer-readable medium (ie, a computer-readable medium) (118) that is coupled to an encryption module (114) and configured to store the package (10) in a receiver escrow, and said. A notification module (120) that is coupled to a computer-readable medium (118) and configured to send notifications to the recipient via the network (108), and a notification module (120) that is coupled to the notification module (120) from the recipient. A key registration module (124) configured to issue new public and private keys to the recipient in response to the notification of acceptance of the notification, the key registration module (124) and the computer readable medium (118). It includes a transmission module (122) that is coupled to and configured to transmit the package (10) to the receiver over the network (108). [0013]

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 does not need to have a public key before the package (10) is sent. If the recipient does not currently have a public key, the recipient will be issued a new public and private key, which will be stored for future reference. This makes it possible to encrypt subsequent personal communications using the recipient's public key. Therefore, the present invention removes a large barrier to adopting public key encryption and at the same time improves the security of personal communication. [0014]

BEST MODE FOR CARRYING OUT THE INVENTION

Here, a preferred embodiment of the present invention will be carried out with reference to the drawings. In the figure, similar reference numerals indicate the same or functionally similar components. Further, in the figure, the number at the left end of each code corresponds to the drawing number of the drawing in which the code is first used. See Figure 1. The figure shows a functional block diagram of a secure communication system 100 for transmitting an information package according to an embodiment of the present invention. [0015]

The main components of the system 100 are a transmission system 102, a server system 104, and a reception 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, public)" computer network 108, such as the Internet. Preferably, all transmissions over network 108 are by secure protocols such as S / MIME (Secure Multipurpose Internet Mail Extension) and / or SSL (Secure Sockets Layer). [0016]

The sender system 102 is used by the sender to securely transmit the information package to at least one intended "recipient" (also referred to herein as "recipient"). In one embodiment, the transmission system 102 includes a directory interface 110 for communicating with an external public key directory 112 over the 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 recipient's e-mail address can be used to query directory 112. [0017]

In one embodiment, the public key directory 112 is implemented using, for example, the existing online directory infrastructure provided by VeriSign, Inc. (Mountain View, California). However, in an alternative embodiment, the directory 112 is implemented using a conventional database system, such as a database system available from Sybase, Inc. (Emeryville, California). However, it is possible to use another database without deviating from the idea of the present invention. Preferably, the directory 112 is accessed by the directory interface 110 using LDAP (Lightweight Directory Access Protocol). [0018]

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 detail below. Preferably, the encryption module 114 uses a public key encryption system available, for example, from RSA Data Security, Inc. (San Mateo, California). However, in an alternative embodiment, a symmetric key algorithm such as DES (Data Encryption Standard) is used. Preferably, each encrypted package 10 complies with S / MIME standards well known in the art. In addition, it is preferable to use at least 128-bit key length (in the case of symmetric key encryption) to provide a high level of data security. [0019]

The escrow key manager 116 generates and / or stores a key for use in encrypting and decrypting an information package that will 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 is a functional unit contained within one or more of the transmitting system 102, the server system 104, or the receiving system 106. [0020]

The encryption module 114 is coupled to the escrow storage area 118 in the server system 104 via the network 108. In one embodiment, the escrow storage area 118 serves as a database for storing encrypted information packages and is managed by, for example, a Sybase database system. Once encrypted, the information package 10 is transmitted using traditional protocols such as HTTP (Hypertext Transfer Protocol) and is escrow-stored until notification to the recipient and notification of acceptance from the recipient are complete. Stored in area 118. However, in an alternative embodiment, the escrow storage area 118 is contained within the transmission system 102 and the package 10 is notified to the recipient to prove that the recipient is a genuine recipient (authenticated). Is stored locally. [0021] [0021]

The server system 104 further includes a notification module 120 for sending notifications of package 10 to the recipient in the receiving system 106. In one embodiment, the notification is an E-mail and the notification module 120 is an E-mail server such as Microsoft Exchange® Server 5.5 available from Microsoft Corporation (Redmond, Washington). It will be appreciated by those skilled in the art that it is possible to use other notification systems and methods within the scope of. [0022]

The server system 104 also includes a transmit module 122, the purpose of which is to transmit the package 10 from the escrow storage area 118 to the decryption module 126 in the receive system 106. In one embodiment, the transmit module 122 is a standard web server, such as Windows NT® Server 4.0, available from Microsoft Corporation. In addition, the decryption module 126 is available on Microsoft Internet. It can be implemented using a standard web browser such as Explorer®, in which case the decryption logic will be contained within the plug-in or Java applet. However, it will be appreciated by those skilled in the art that various other transmission systems and methods can be used without departing from the ideas of the present invention. Preferably, the communication between the transmitting module 122 and the decrypting module 126 is performed by HTTP using SSL. Further, in one embodiment, the transmit module 122 is combined to receive the recipient's public key from directory 112 to prove that the recipient is a genuine recipient, as detailed below. Ru. [0023]

The notification module 120 is coupled to the key registration module 124 in the receiving system 106 via the network 108. The key registration module 124 is configured to issue new public and private keys (those that no one currently has), and also automatically issues the recipient's new public key to the public key directory 112. It is configured to add to. [0024]

In one embodiment, the key registration module 124 is present in the receiving system 106 before the sender sends the information package 10. 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 is keyed by the recipient in the receiving system 106 using a traditional web browser such as Netscape Communicator® available from Netscape Communications Corporation (Mountain View, Carifornia). Includes hyperlinks such as URLs (Uniform Resource Locators) that allow you to download Registration Module 124. [0025]

As mentioned above, the receiving system 106 also includes a decoding module 126 for decoding the information package 10. Like the encryption module 114, the decryption module 126 preferably uses, for example, a public key encryption system available from RSA Data Security, Inc., for example. However, in an alternative embodiment, it is also possible to use a symmetric key algorithm such as DES (Data Encryption Standard). [0026]

In one embodiment, the decryption module 126 is combined to receive an escrow decryption key from the escrow key manager 116. Alternatively, the decryption module 126 is combined to receive the recipient's private key from the key registration module 124. Using the escrow decryption key or the private key, the decryption module 126 decrypts the information package 10 and provides the decrypted information package 10 to the recipient. [0027]

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

As shown in FIG. 2, the central processing unit (CPU) 202 executes software instructions and interacts with other system elements to implement the methods of the invention. The storage device 204 coupled to the CPU 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. The network interface 206 coupled to the CPU 202 connects the transmission system 102 to the network 108. The 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 the CPU 202 facilitates control by the user of the transmission system 102. [0029]

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

See FIG. 3 here. The figure shows a flowchart of the system 100 according to an embodiment of the present invention. Also referring to FIG. 1, the sending system 102 first receives the recipient's e-mail address from the sender (step 302). In one embodiment, the recipient's e-mail address is used, but the sender may specify the recipient by a name associated with the e-mail address in the sending system 102 or other unique identifier of the recipient. Those skilled in the art will understand that it is possible. Although the recipient will be described below as the only one, it will be appreciated by those skilled in the art that Package 10 can have multiple recipients. [0031]

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 above, this is accomplished by the directory interface 110 within the transmission system 102, which accesses the directory 112 using standard protocols such as LDAP. [0032]

A determination is then made as to whether the recipient's key has been found in directory 112 (step 306). If the key is found, the recipient's public key is used to encrypt package 10 by the encryption module 114 and send it to server system 104 where it is stored as a "normal" package. Ru. The term "ordinary" is used to distinguish said 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 within the server system 104 for regular packaging. [0033]

The server system 104 then informs the recipient that the package 10 is stored for the recipient (step 312). As mentioned above, in one embodiment this is done by a notification module 120 that uses an e-mail notification system. However, those skilled in the art will appreciate that it is possible to use other notification systems and methods without departing from the ideas of the present invention. For example, the receiving system 106 can include a notification client (not shown) that receives UDP (User Datagram Protocol) notifications from the notification module 120. Upon receiving the UDP notification, the notification client generates visual or acoustic desktop notifications to the recipient, such as icon blinks, chimes, and pop-up dialog boxes. Other forms of notification include voice notification via a speech synthesis module, pager notification via a conventional pager, or facsimile notification via a standard facsimile. [0034]

After the recipient receives the notification and notifies the acceptance of the notification by replying to an E-mail message (step 314), whether or not the person requesting to become the recipient is actually the recipient. To determine, prove that the person is a genuine recipient (step 316). Those skilled in the art will appreciate that there are numerous ways to prove that a beneficiary is a genuine beneficiary. For example, it is possible to use a password or the like. [0035]

However, public key encryption provides a convenient and highly secure way to prove that the recipient is a genuine recipient. In one embodiment, the recipient encrypts a standard message using the recipient's private key and sends the encrypted message to the transmit module 122 in the server system 104. The transmission module 122 obtains the recipient's public key from the public key directory 112 and uses the recipient's public key to decrypt the message. If the message is successfully decrypted, it is known that the recipient holds the private key corresponding to the public key in directory 112, which proves that the recipient is a genuine recipient. Will be done. The above certification steps 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. , Will be understood by those skilled in the art. [0036]

After the recipient is correctly certified, the transmit module 122 sends the package 10 to the receiving system 106 over the network 108 (step 318), which receives the package 10 from the server system 104 (step 320). ). Those skilled in the art will appreciate that it is possible to use a "push" or "pull" mechanism within the scope of the present invention. Although HTTP and SSL are preferably used, it is also possible to use other standard protocols without departing from the ideas of the present 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. [0037]

The above description describes the case where the recipient's public key can be found in directory 112. However, a more difficult situation arises if the recipient's public key does not exist in directory 112. In fact, if the recipient does not yet have a public key, traditional public key systems will not be able to send encrypted messages to the recipient at all. This represents a serious drawback of traditional systems. The present invention solves this problem by holding the recipient's package 10 in an escrow, as detailed below. [0038]

Now return 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 the 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. [0039]

The escrow encryption key and escrow decryption key should not be confused with the new public and private keys issued to the recipient as shown in step 336. Once the escrow encryption and escrow decryption keys are issued to the recipient, they must be sent to the recipient over network 108, resulting in the same drawbacks as symmetric key encryption. It will occur. With public key ciphers, the recipient's private key should never be sent to the recipient. Therefore, according to the present invention, the recipient's private key is generated locally on the receiving computer 106, and only the recipient's public key is sent to directory 112 over network 108. [0040]

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, those keys can be symmetric keys. In yet another embodiment, those keys are stored (not generated) by the escrow key manager 116 and are hard coded within the escrow key manager 116 or added by an external agent or process on a regular basis. Will be updated. In yet another embodiment, the public escrow key is exposed in directory 112 and the server system 104 maintains the private escrow key in a hardware device that protects it from tampering, providing the highest level of security against escrow key tampering. provide. [0041]

After the keys are issued, the encryption module 114 in the transmission system 102 reads the escrow encryption key (step 326), encrypts package 10 with the escrow encryption key, and encrypts the package 10. Send the package 10 to the server system 104. The package 10 is then stored in the escrow storage area 118 (step 328). As described below, the server system 104 keeps package 10 in the recipient's escrow until the recipient is successfully registered and receives a new public and private key. [0042]

As with regular packages, the recipient is then notified that package 10 is stored in escrow and that registration is required for the 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 containing the key registration module 124 is digitally signed to verify the source of the message. However, in an alternative embodiment, 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. [0043]

The recipient receives the notification, sends an acceptance notice for the notification, extracts or downloads the key registration module 124, and then uses the key registration module 124 to register for new public and private keys. Do (step 334). As mentioned 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 in the receiving system 106. [0044]

In one embodiment, the registration process described above is similar to the procedure used by VeriSign, Inc. and other certification bodies to issue certifications, such as the recipient's name, address, telephone number, E-. It involves a request to the recipient of various personal data, including mail addresses. 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. [0045]

After the recipient completes the registration, the recipient's new public key is automatically sent over network 108 and stored in the public key directory 112 (step 335). This is an advantage. This is because subsequent packages 10 that should be sent to the same recipient will be encrypted using that recipient's public key, and will provide a high degree of security because they do not involve an escrow key. [0046]

The recipient is then proved to be a genuine recipient in order to determine if the person requesting to be the recipient is actually the recipient. As already described for step 316, the proof uses the recipient's private key to encrypt a standard message on the receiving computer 106 and uses the recipient's public key obtained from directory 112. It can be accompanied by decoding the message on the server computer 102. [0047]

After the recipient is proved to be a genuine recipient, the transmit module 122 in the server system 104 sends the certified recipient's package 10 to the decryption module 126 in the receive system 106 (step 338). .. The decryption module 126 then decodes the package 10 and provides the decrypted package 10 to the recipient. This process can be done in a number of ways, as described below. [0048]

See FIG. 4 here. The figure shows a first embodiment of the interaction between the transmit module 122 and the decryption module 126. First, the transmit module 122 reads the package 10 stored in the certified recipient escrow (step 342), sends the package 10 to the decryption module 126 over the network 108, and the decryption module 126. Receives the package 10. The decryption module 126 then reads the escrow decryption key for the package 10 from the escrow key manager 116 (step 346). The decryption module 126 then decrypts package 10 using the escrow decryption key (step 348). [0049]

See FIG. 5 here. The figure shows a second, more secure embodiment of the interaction between the transmit module 122 and the decryption module 126. First, the transmit module 122 reads the package 10 stored in the escrow for the certified recipient (step 350). The transmission module 122 then reads the escrow decryption key from the escrow key manager 116 and decrypts the package 10 using the escrow decryption key (step 352). The transmission module 122 then re-encrypts package 10 with the recipient's new public key (available from directory 112 or 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) and receives the package 10 as the recipient's private key. Decrypt using (step 358). [0050]

The above description illustrates the operation of a preferred embodiment and does not imply limiting 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 obvious to those skilled in the art, but such embodiments will also be included in the ideas and scope of the present invention.

[Simple explanation of drawings]

[Figure 1]

It is a functional block diagram which shows the secure communication system for transmitting the information package by one Embodiment of this invention. [Figure 2]

It is a physical block diagram which shows the detail of the further embodiment of the transmission system by one Embodiment of this invention. [Fig. 3]

It is a flowchart of a secure communication system according to one Embodiment of this invention. [Fig. 4]

It is a flowchart which shows the 1st Embodiment of the transmission module and the encryption module by one Embodiment of this invention. [Fig. 5]

It is a flowchart which shows the 2nd Embodiment of the transmission module and the encryption module by one Embodiment of this 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 Cryptographic module 116 Escrow Key Manager 118 Escrow storage area 120 notification module 122 Send module 126 Decoding module