JP2002521970A - Message management system with security - Google Patents

Abstract

(57) [Abstract] A messaging system for transferring messages between any two of a plurality of user machines. The system includes a message manager (112) for managing secure message operations. The message manager (112) is associated with a management database (114) that stores the characteristics of the individual secured channel for each message channel between each user machine and its manager (112). Furthermore, it has a local message processor (130) provided for each user machine to secure messages. This local processor (130) is associated with a local database (122). The local database (122) has a secure channel for each channel between a user machine and each of the other user machines including the message manager (112) with which the user machine communicates. Store the characteristics.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001] Field of the Invention The present invention generally relates to electronic messaging management system, in particular, to an electronic mail communication to ensure security through a public digital network.

[0002] One of the main uses of electronic data communications Background of the Invention is the transfer of a message including e-mail, documents and the like and, for any other type of electronic data transfer. The message includes at least a source address, a destination address, and message data. When a message is forwarded over a communications network, the message may be sent directly from the originating user to the destination user, or may be relayed between one or more servers on its forwarding path. This may result in the message, including the email, being disclosed or stolen to users, other entities, etc. at multiple locations.

[0003] E-mail security is an important issue for digital network users, such as Internet users. Each user is concerned that others may steal the user's personal messages. Companies are concerned about the possibility of e-mail containing the secrets of their transactions leaking or being stolen.

FIG. 1A shows details of an email network architecture 10 designed to protect the privacy of email communications.

[0005] The system 10 includes a plurality of e-mail clients that are users and a plurality of Internet servers 12 shown as servers 12A, 12B, etc. in the figures. In the illustrated situation, when User 1 sends an e-mail to User 2, the e-mail is sent from server 12A to server 12B via the Internet, and the e-mail finally reaches User 2, its destination. ing.

Normally, in this example, a destination user who is User 2 has a mailbox 13, and the mailbox is located on a server 12 B that provides a service to User 2. The mailbox 13 temporarily stores the mail of the user 2 while the user 2 is offline. The user 2 retrieves the user's mail from the mailbox 13 when logging on.

[0007] The user has a computer 26 on which an operating system 28 such as Windows (registered trademark) is installed. Further, an email package program 20, a security channel database (SDB) 22, and a mail securer 30 are installed on the computer 26 and exist on the operating system 28.

When an e-mail is sent from one user to another with security, the e-mail is sent through a secure channel.
A secure channel between any two users is a property known only to the two users, such as an encryption algorithm using a given data and key, key, key length, etc. (Characteristics).

Although only two users, User 1 and User 2, are shown in FIG. 1A, it should be understood that the transfer of e-mail can occur between any number of users. Further, FIG. 1 shows only the user 1 in detail, but the user 2
It is evident that all other users, including, have similarly configured elements.

The electronic mail package program 20 is, for example, Outlook, Eudora, or Netsc
It is a commercially available e-mail package program such as ape. The e-mail package program 20 includes a normally electronic address book 18, an inbox 23, and an outbox (Out), such as those commonly used in commercial e-mail programs.
box) 24. These elements are used in the methods commonly used for this type of element that are commercially available.

The mail securer 30 is provided by Vanguard Se, Haifa, Israel, the assignee of the present application.
Any commercially available secure email management system, such as MAILguardian, available from curity Technologies. In general, the mail securer 30 secures an e-mail packet by performing the following four steps. (2) a random number as a key and a commercially available encryption algorithm such as Data Encryption Standard (DES) or Blowfish. Encrypt. (3) The random number key is encrypted using a predetermined key and the selected encryption algorithm, and is attached to the encrypted packet. (4) Encapsulate the secure e-mail packet into a normal e-mail message that displays only the minimum information necessary for transport.

The SCDB 22 exists on the mail securer 30 and includes only addresses of users who have a secret handling permission for sending and receiving secure emails. Typically, these users who are secured in communication are called members. There are usually two ways to add users or members to the SCDB 22.

In the first method, the user 1 contacts the user 2 using an arbitrary method (for example, telephone) and exchanges keys to generate a secure channel between the two. This procedure, known as secret sharing, must be repeated each time a new user is added to SCDB 22.

In the second method, when user 1 receives an e-mail from user 2, mail securer 30 of user 1 recognizes that user 2 uses the same security software, and automatically performs security. Generate a channel that secures
Such a scheme is achieved by a handshake process using an internal e-mail message between user 1's mail securer 30 and user 2's mail securer 30. This method eliminates the need for a user interface as in Method 1, but allows one or more email packets to secure before a secure channel with the appropriate key is created between them. It will be transferred through the unsecured channel.

The secure channel generated by either of the above two methods is a channel dedicated to two users who are members of the channel. As an example, when User 1 sends an e-mail to User 2 through their secure channel, Securer 30 of User 1 uses the properties (characteristics) of the secure channel to secure the e-mail packet. To secure. The same applies to the case where the user 2 sends an e-mail to the user 1. This is known as e-mail transmission over a secure channel between user 1 and user 2.

For email packets sent to two or more users or addresses, known as multicast packets, each recipient receives the packet over a secure channel between the recipient and the sender. Furthermore, multicasting may be sent not only to user members who have a secure channel between the sender and receiver, but also to non-user members who do not have a secure channel between them. is there.

Referring now to FIG. 1B, there is shown a flowchart illustrating an example of the transfer of an email via the email network system of FIG. 1A.

The user 1 writes an e-mail addressed to the user 2 using the e-mail package program 20 (step 40). The user 1 retrieves the address of the user 2 with reference to the address book 18 (step 42). User 1 finishes writing the e-mail and requests "SEND". The e-mail package 20 places the e-mail in the outbox (Outbox) 24 (step 44) and starts a connection with the server 12 (step 46). The e-mail packet is passed from the level of the e-mail package 20 to the communication protocol layer (ie, TCP socket) of the operating system 28 (step 48). An interceptor (i.e., a layered socket program) hook monitors packets before or in the communication protocol layer and identifies the packet as an email packet to be sent. The interceptor hook supplies the packet to the mail securer 30 (step 49).

The mail securer 30 attempts to confirm that the sender and recipient, ie, User 1 and User 2, are each a member of a set of SCDBs 22 (step 50).
. Once both are identified as a set of members (step 52), they are classified as capable of transmitting and receiving secure email. The mail securer 30 ensures the security of the e-mail packet as described in detail above (step 54).

However, if mail securer 30 does not identify user 1 and user 2 as a set of members of SCDB 22 (step 56), the packet is not classified as to be sent over the secure channel. At this time, Mail Securer 3
0 sends a warning notifying the user 1 that the packet is going to be transmitted without security (step 57) and waits for an instruction. User 1 can choose to send the packet without security over an open (unsecured) Internet channel (step 58) or discard the packet (step 59). .

The secured e-mail packet is transmitted to operating system 28
(Step 60). The packet is the communication medium (ie the Internet)
Through the server 12 (step 62) to provide services to the user 2
The mail reaches the mailbox 13 of the user 2 in B. The packet is user 2
Is stored in the mailbox 13 of the user 2 until it is extracted by the electronic mail package program 20 (step 64). The message is intercepted at the communication protocol layer (step 66) and provided to the securer 30 of user 2. User 1 and user 2 in the pair are both SCDB2 of user 2.
If so, the email is decrypted (step 67) and returned to user 2's operating system 28. The email package program 20 of the user 2 receives the email in the plain text format (step 6).
8) Put the mail in the inbox (Inbox) 23 and notify the user 2.

[0022] One purpose of (this summary of the invention) The present invention is, from the time it is installed initially, is to automatically provide security for electronic messaging system.

Thus, according to a preferred embodiment of the present invention, any two of a plurality of user machines
A messaging system is provided for the transfer of a message between two. The system has a message manager for monitoring secure message operations. The message manager is associated with a management database that stores the characteristics of the individual secured channels of each message channel between the manager and each of the user machines.

Further, the system has a local security message processor provided for each user machine for ensuring security of the message. The processor is associated with a local database. The local database is a communication partner of the user machine and the user machine,
The characteristics of the secured channel are stored for each channel with each of the other user machines including the manager.

Further, installing the local security message processor on at least one of the user machines and providing the local database containing at least the characteristics of the secure channel of the channel between the manager and the user machine. Thus, a message manager is provided which has means for ensuring secure operation of messages from the moment of installation. The local security message processor is adapted to communicate with the message manager when the characteristics of the secure channel of the communicating user are unknown or when the local security message processor is unable to decode a message received from another user machine. Means for sending a message to

Thus, according to a preferred embodiment of the present invention, any two of a number of user machines
Generating a secure channel characteristic between a message manager and each of the plurality of user machines, comprising the steps of: Storing the characteristics of each secured channel between the message manager and each of the plurality of user machines in a management database; and a local security message processor on at least one of the plurality of user machines. Installing and providing a local database tied to the processor; characteristics of a secure channel between at least one of the plurality of user machines and at least the manager; and the plurality of user machines Storing the channel characteristics of each of the secured channels between each of the user machines and each of the other user machines in the local database; and from the moment of installation, any one of the plurality of user machines. Securing messaging between them.

Further, a method is provided that includes logging on at two or more of the plurality of user machines, and forwarding a secure message by sending a message to the message manager.

Further, the step of generating the characteristics of the secure channel includes automatically generating a key and performing automatic authentication, and / or using an authentication code. A method is provided for doing so.

[0029] The method may further comprise: when the characteristics of the secure channel of the other user to communicate with are unknown, or when the local security message processor is unable to decrypt a message packet received from another user machine. Sending a message to the message manager.

[0030] The method further comprises regenerating characteristics of the secure channel for the secure channel between any two of the plurality of user machines without interrupting a user's communication flow. Process. Alternatively, the step of regenerating the characteristics of the secure channel may include the step of regenerating the characteristics of the secure channel at predetermined intervals.
Alternatively, when the local security message processor cannot decode a message packet received from another user machine, the method may include regenerating the characteristics of the secure channel.

The present invention will be more fully understood by reference to the following detailed description when taken in conjunction with the accompanying drawings.

[0032] (Detailed Description of the Preferred Embodiment) FIG. 2 is constructed and operative in accordance with a preferred embodiment of the present invention, schematic view of the architecture of ensuring security electronic mail management system 100 is shown.

From the moment the agent is installed on the user's desktop, the present invention provides an end-to-end secure email communication channel. Unlike conventional systems, system 100 is transparent to the nominal user.

Similar to system 10, system 100 includes operating system 128
And a plurality of users who have the computer 26 on which is installed. The plurality of users exchange e-mails on the Internet via the server 12. Each user receives an e-mail package program 20, an electronic address book 1
8, an inbox (Inbox) 23, a transmission tray (Outbox) 24, and a mailbox 13.

The operating system 128 is any operating system such as, for example, UNIX (registered trademark), MAC, and Windows.

The system 100 further includes a mail security agent 130, a local security channel database (LSCDB) 122 that is a local secure channel database transparent to the user, and a secure channel database for global management. It has a mail security manager 112 with a global management security channel database (MSCDB) 114.

The basic functions of each mail security agent 130 are similar to the functions of the mail securer 30. Further, as described in detail below, each agent 130 automatically installs a member in each LSCDB 122 with the manager 112.

As in the conventional case, each LSCDB 122 is located locally for each user, and has the address and key of another member with which the local user communicates. In a preferred embodiment of the present invention, the local secured channel database is transparent to the user if user 1 does not need to enter a more secure user in LSCDB 122. In another embodiment, LSCDB 122 may be interfaced as in the prior art. That is, LSCDB can be used with options that are visible and / or editable.

The manager 112 is one of the users in the system 100,
The service is provided by one of the two. The manager 112 has an MSCDB 114, which is created during setup and updates, as will be described in more detail below, and to which members are imported. The MSCDB 114 has channel properties (characteristics) and keys for all users in the system 100. Thus, as long as the manager 112 has channel properties and keys for all users in the system 100 (via the MSCDB 114), the manager 112 can communicate with all users of the system 100. However, the MSCDB 114 does not store the properties (characteristics) of the channel that secures security between any two users, and these properties (characteristics) are 2
Only stored in the LSCDB associated with one user.

The user of the MSCDB 114, that is, the member,
Determined by the company that has the 00. The system 100 provides services to any user that the company wishes to include as a secure e-mail recipient / sender, regardless of the user's physical location or affiliation. As an example, a member of MSCDB 114 may be an employee of an affiliated company that is at the same physical location as the company or not at the same physical location. Alternatively, the list of members may include the company's customers or business partners, or any other users that the company wants to communicate on a secure channel.

Since manager 112 is one of the users of system 100 and is served by server 12, manager 112 can communicate with any user on the Internet network. Once the user's name and address are added as a member of the MSCDB 114, messages sent to that user are secured regardless of the user's location on the Internet.

The manager 112 has the additional task of communicating with each agent 130 via control messages that can be sent in both directions from the manager to the agent and from the agent to the manager. The control message is
Includes commands such as "refresh key", "installation complete", "recovered key", "message recovered", etc. . In addition, participating companies can create a company policy database 129. The company policy database 129 is located on the computer 26 of the manager 112 and is automatically distributed to each user's computer 26 to regulate violations of rules or transfer of unsecured email.

Normally, the manager 112 does not participate in the transfer of messages between two users. Manager 112 is involved in message transfer between users if the transfer is the first communication between the users or if the transfer is problematic.

FIGS. 3A and 3B show two types of electronic mail transfer methods. FIG.
A shows the transfer of an e-mail in which the manager 112 is not involved. FIG. 3B illustrates an electronic mail transfer involving the manager 112. Steps of this embodiment that are similar to those described above in connection with the prior art are illustrated with similar reference numerals and are described in detail below.

As shown in FIG. 3A, in the transfer of the e-mail from the user 1 to the user 2, FIG.
What is generally similar to the prior art of B is performed. However, all steps performed by the securer 30 of FIG. 1B (steps 49, 50, 52, 54,
60, 66, and 67) are now performed by the agent 130 of FIG. 3A (steps 149, 150, 152, 154, 160, 166, and 168).
). Further, while the SCDB 22 is referred to in step 49 of FIG. 1B, the LSCDB 122 is referred to in step 149 of FIG. 3A in the present invention.

FIG. 3B shows the transfer of an electronic mail involving the manager 112.
The user 1 writes an e-mail addressed to the user 2 using the e-mail package program 20 (step 40). User 1 retrieves the address of user 2 with reference to address book 180 (step 42). User 1 finishes writing the e-mail. The e-mail package program 20 places the e-mail in the outbox (Outbox) 24 (step 44) and starts a connection with the server 12 (step 4).
6).

The e-mail packet is passed to the communication protocol layer at the level of the operating system 28 (step 48). The interceptor hook monitors that the packet is at the communication protocol layer and supplies the packet to the mail security agent 130 (step 149).

The mail security agent 130 has a sender and a receiver, ie, user 1
And an attempt is made to confirm that each of User 2 is a member of LSCDB 122 (step 150). Agent 130 assigns LSCD to user 1 and user 2
It is not recognized as a set of members in B122 (step 155). The agent 130 secures the e-mail packet with a predetermined set of properties (characteristics) for the secure channel between user 1 and the manager 112 (step 156) and sends the packet to the manager 112. . The manager 112 queries the LSCDB 114 (step 157) and attempts to identify the user 2.

If user 2 is found in MSCDB 114 (step 158) and identified, manager 112 sets a predetermined set of properties of the secure channel between user 2 and manager 112. To secure the security of the e-mail packet (step 159). In parallel, the manager 112 generates a key for the secure channel of user 1-user 2 (step 160) and sends it to both user 1 and user 2. By generating and exchanging the key, it is possible to eliminate the need for the assistance of the manager 112 in the next transfer of the e-mail between the user 1 and the user 2 (or the user 2 and the user 1).

The manager 112 sends the packet to the user 2 (steps 161, 62, 64)
, 166, and 167), at User 2 the packet is decrypted. The e-mail packet in the plain text format is received by the inbox (Inbox) 23 of the user 2 (step 168), and the existence is notified to the user 2. The plain text message contains no indication of manager intervention. As previously described with respect to FIG. 3A, it appears as if the message was sent directly from user 1 to user 2.

If user 2 is not found in the MSCDB (step 170), manager 1
12 follows the company policies listed in database 129 (step 172)
. Such company policies include sending unsecured messages, delaying transmission until such secure channels are created, discarding messages, or returning error messages to User 1. And the like.

Referring now to FIG. 4A, there is shown a flowchart of an automatic authentication installation procedure for a user of the system 10 according to a preferred embodiment of the present invention.

The system 100 creates a secure channel between at least the manager 112 and each user of the system 100. As will be described in detail below, the MSCDB 114 is imported and updated with at least the properties of the secured channel for each user and manager 112 of the system 110. As described in more detail below, each user's LSC
In the DB 112, at least the properties (characteristics) of the channel ensuring the security of the user and the manager 112 are automatically installed.

The installation procedure starts with the installation of the manager 112 on the system 100 (step 202). The company having system 100 selects members / users of system 100 and imports their names into MSCDB 114 (step 204). At a later date, if the company chooses to include additional users in system 100, this step can be repeated for any new users.

Next, the manager 112 starts a process of securing security for members for each user for which the operator of the manager has decided to secure communication. This process is based on Diffie Hellmen for each user member.
It begins by generating a (DH) method private key and public key (step 206). Although the flow diagram of FIG. 4 shows details of the distribution and generation of the program for one member, User 1, it is clear that Manager 112 repeats this procedure for all users imported in step 204. It is.

The manager 112 saves the DH private key, and sends the DH public key to the user 1 together with the installation program of the agent 130 (step 108). The installation software can be distributed in various ways, including by attachment to an e-mail message. The user 1 starts the installation program by activating the attached file (ie, double-clicking the attached file), and starts installing the agent 130 (step 210). Agent 1
30 generates its own DH public and private keys (step 212). Next, the agent 130 generates an all DH key from its own private key and the received public key (step 214), and uses it to generate a secure channel. Agent 130 secures (from user 1) to manager 112 through this newly secured channel with "
An "install complete" message is sent with the DH public key (sent in plaintext) prepended (step 216). Manager 112 is the DH of user 1
The public key is extracted (step 218), and the same all-DH key is generated from the extracted key and the saved DH private key (step 220). As a result, the manager 112 can read and decode the "installation end" message sent with the security ensured (step 222). If the "install complete" message is decoded correctly, manager 112 marks User 1 as installed (step 224).

Referring now to FIG. 4B, there is shown a flowchart of a user authentication installation procedure for the system 100 according to a preferred embodiment of the present invention.

As shown in FIG. 4A, instead of generating Diffie Hellmen's (DH) private and public keys, one or more imported members may be given a choice available to the company having the system 100. By providing an authentication code, which can be a string, the security of those members can be ensured. this is,
This is performed via the manager 112.

Steps 202 and 204 of FIG. 4A are repeated for this embodiment, even if those steps have already been performed earlier and need not be performed.
However, instead of generating Diffie Hellmen's (DH) private and public keys, manager 112 generates a random authentication code (step 250) and provides it to user 1 (step 252). Next, the manager 112 uses the authentication code to generate a key for a secure channel between the manager and the user 1 (step 254). The manager 112 determines the properties of the secure channel for transmission between user 1 and manager 112 (
The characteristic is recorded in the MSCDB 114 (step 256), and the agent 130 software installation program is sent (step 258), for example, in a form attached to an e-mail message to the user 1.

The user 1 starts the installation program (step 262), and the installation program starts installing the agent 130 (step 2).
64). Agent 130 requests an authentication code (step 266) and uses it to generate a key for the secure channel (step 2).
68). The agent 130 automatically sends a secure "installation complete" message (from the user 1) to the manager 112 through the newly secured channel (step 270).

Using the key saved in step 254, the manager 112 reads and decodes the “installation end” message sent with security assured (step 272). If the "install complete" message is decoded correctly, manager 112 marks it as installed by user 1 (step 274).

In a preferred embodiment of the present invention, the e-mail packet is secured by performing at least the following steps: (1) Attach a digital signature to an e-mail packet. (2) E-mail packets and digital signatures are converted to random numbers as keys and
Encrypt using a secure channel data encryption algorithm such as ta Encryption Standard (DES) or any commercially available encryption algorithm such as Blowfish. (3) The random number key is used to secure the predetermined key of the secure channel and the encryption algorithm of the secure channel key such as a commercially available encryption algorithm such as Data Encryption Standard (DES) or Blowfish. And attach it to the encrypted packet. (4) The random number key is also encrypted using the channel key ensuring the security between the user 1 and the manager and the data encryption algorithm selected above, and attached to the encrypted packet. (5) Encapsulate the secured e-mail packet into a standard e-mail message that displays only the minimum information necessary for transfer.

Because the system 100 gives the manager 112 the ability to decrypt the email random number key, the system 100 offers the flexibility of another option, such as: (1) A user can receive secure mail at a plurality of locations. (2) The damaged key can be automatically repaired. (3) The old key can be automatically refreshed. These three options are described in detail below.

Multiple Locations FIG. 5A is a schematic diagram of a system 100 in which one or more users are set up at multiple locations. Occasionally, one or more users may log on at one or more locations. As shown in the situation illustrated in FIG. 5A, the user 2 is registered at two different positions, a position A and a position B. However, the two locations of user 2 use the same server 12 and the same mailbox 13.

Although system 100 knows that user 2 has two different logon locations, the system does not know where user 2 will log on next. Further, the manager 130 sets the LS for each location used by the user 2.
Updating the CDB 122 is not practical.

When system 100 receives an “install complete” message from user 2 with a new or second computer ID, manager 112 declares the user as a multi-location user. The manager 112 supplies the same key for the secure channel between user 2 and manager to user 2 at both locations. Further, the manager 112 stops creating a secure channel between the user 2 and the other member users. Further, the manager 112 requests the user 2 to clear all secure channels between the user 2 and other users, and to leave only the secure channels with the manager 112 valid. Also try. In this way, user 2 will always be able to receive secure e-mail through a secure channel between it and manager 112.

Referring now to FIG. 5B, a flowchart illustrating an email process for a user having multiple locations is shown. The steps of this embodiment that are similar to those shown in FIG. 3A have been previously described in detail and will not be described here in detail.

In the illustrated situation, user 1 writes an email to user 2 (step 302).
). The e-mail packet is encrypted for sending to user 2 (step 30).
4). However, there is no secure channel between user 1 and user 2 and the email is bypassed (step 306) and the manager 112
Sent to

The manager 112 receives an e-mail packet from the user 1 (step 314). The manager 112 then decrypts the email packet using the user 1-manager 112 key (step 316).

Next, the manager 112 re-encrypts the e-mail packet opened in the properties (characteristics) of the user 2-manager secured channel (step 318), and converts the encrypted e-mail packet to the user. 2 (step 320). User 2 with the key to manager 112 receives (322) the packet and decrypts it.

[0071] With reference to FIG. 6 damage key repair, there is shown a flow diagram illustrating steps in damage key repair.

The user 1 sends a secure e-mail packet to the user 2 (
Step 350). The email packet is encrypted for sending to User 2 (step 352). User 2 receives the e-mail (step 354).
However, user 2 cannot open the packet (step 356). This is because one of the keys held by the user 1 is damaged or the key held by the user 2 is damaged.

The agent 130 at user 2 sends the unopenable packet to the manager 112 with a message notifying the manager that he (user 2) has a mail that cannot be opened (step 360).

As described above, all e-mail packets are encrypted with the user-manager 112 security line key. Accordingly, manager 112 receives the key for the e-mail packet on the original transfer line of the e-mail packet, i.e., the user-manager secure line in step 352. Thus, once manager 112 receives the message and packet from user 2 (step 362), manager 112 can decrypt the packet using the user 1-manager 112 key carried in the original message (step 364).

The manager 112 re-encrypts the e-mail packet opened with the properties (characteristics) of the channel secured between the user 2 and the manager (step 366), and converts the encrypted e-mail packet to the user 2. Send to User 2 with the key to manager 112 receives the packet (step 3
68), decrypt it.

The manager 112 selects a new random number key for “step 372” for the user 1 and the user 2. By exchanging the replacement key, the next transfer of the e-mail between the user 1 and the user 2 can be performed without the help of the manager 112.

Refreshing Old Keys Referring to FIG. 7, there is shown a flow chart of the steps in refreshing old keys. The principle is similar to the principle of repairing damaged keys.

The manager 112 updates the key at a predetermined cycle, for example, every three weeks. At the end of the cycle, User 1 requests to refresh his key with User 2. The manager 112 updates the key for user 1-user 2 by generating a new random key and sending it to the two users (step 402). Each new key is determined by the manager's generation time, which is the time calculated by the manager to generate the key. User 1 receives the new key at the actual generation time, but User 2 receives it at a later generation time, thereby reducing the possibility of two users requesting a key refresh at the same time and generating collisions. ing.

The user 1 and the user 2 can continue communication without knowing that the key refresh process is being performed in the background. If User 1 receives the new key and User 2 uses it before receiving the new key, manager 112 can recover the message.

In the situation illustrated in FIG. 7, user 1 receives the new key (step 40).
3). User 1 sends a secure e-mail packet to User 2 (
Step 404). The e-mail packet is encrypted using the new key (step 406) and sent to user 2. User 2 receives the email (step 408), but cannot open the packet because user 2 does not have the updated key (step 410).

The agent 130 of the user 2 recognizes that the message is secured using the new key. User 2 sends the unopenable packet to manager 112 with a message notifying the manager that he (user 2) has mail that cannot be opened because it is encrypted with the new key. (Step 414).

When manager 112 receives a message from user 2 about an email packet from user 1 (step 416), manager 112 decrypts the packet using his user 1-manager 112 key (step 418). )
.

The manager 112 re-encrypts the packet with the properties (characteristics) of the channel that ensured the security of the user 2-manager (step 420).

The manager 112 sends the packet to the user 2 (step 424). User 2 receives the packet (step 426) and decrypts it.

If User 2 sends a message to User 1 using the old key, User 1 can still decrypt it. Each user keeps the old key in the LSCDB until the first message is decrypted with the new key.

Those skilled in the art will appreciate that the present invention is not limited to the specific embodiments described above. Specifically, although embodiments of the present invention have been described herein in relation to the transfer of email, the present invention applies to any type of electronic message over a digital network used for communication applications. Can be. The true scope of the invention is limited only by the following claims.

[Brief description of the drawings]

FIG. 1A is a schematic diagram showing the architecture of a conventional secure email network.

FIG. 1B is a flowchart illustrating the transfer of an email via the email network of FIG. 1A.

FIG. 2 is a schematic diagram illustrating the architecture of a secure email network constructed and operative in accordance with a preferred embodiment of the present invention.

FIG. 3A is a flowchart showing an e-mail transfer procedure with security of the e-mail network of FIG. 2;

FIG. 3B is a flowchart showing an e-mail transfer procedure with another security in the secure e-mail management system of FIG. 2;

FIG. 4A is a flowchart showing an automatic authentication type installation procedure of the electronic mail network of FIG. 2;

FIG. 4B is a flowchart showing a user authentication type installation procedure of the e-mail network of FIG. 2;

FIG. 5A is a schematic diagram showing the architecture of a multi-location user system used in the secure email network of FIG. 2;

5B is a flowchart showing a multi-position user email transfer procedure in the secure email network of FIG. 2;

FIG. 6 is a flowchart showing a procedure for exchanging a damaged key in the secure email network of FIG. 2;

FIG. 7 is a flowchart showing a procedure for refreshing an old key in the secure email network of FIG. 2;

──────────────────────────────────────────────────続 き 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, 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, CU, CZ, DE, DK, 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, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU, ZA, ZWF terms (reference) 5B017 AA00 AA03 AA07 BA07 CA16 5B085 AE13 BG07 CA04 5J104 AA01 AA16 EA01 EA04 EA15 NA02 PA08

Claims (15)

[Claims] 1. A messaging system for transferring messages between any two of a plurality of user machines, comprising: a message manager for monitoring secure message operations; said manager and said user; The message manager, associated with a management database storing the characteristics of the individual secure channels of each message channel between each of the machines, and a message machine provided for each user machine For each channel between the user machine and each of the other user machines, including the manager, with which the user machine communicates, the characteristics of the secured channel. Memorize Messaging system, characterized in that it comprises, coupled with the local database, and the local security message processor. 2. The message manager having the local security message processor installed on at least one of the user machines, including at least characteristics of a channel that secures a channel between the manager and the user machine. 2. The messaging system according to claim 1, wherein the local database is provided, thereby ensuring secure operation of messages from the moment of installation. 3. The local security message processor is unable to decrypt a message received from another user machine when the characteristics of a secure channel of a user with whom communication is performed are unknown. The messaging system of claim 1, further comprising means for sending a message to said message manager at times. 4. A message manager for monitoring secure message operations between any two of a plurality of user machines. 5. The message manager according to claim 1, wherein said message manager is tied to a management database storing characteristics of individual secure channels for each message channel between said manager and each of said user machines. The message manager according to claim 4, wherein 6. The channel, wherein the message manager installs a local security message processor and an associated local database on at least one of the user machines, and secures at least a channel between the manager and the user machine. The message manager according to claim 4, characterized in that the relevant local database is provided comprising the characteristics of (1), thereby ensuring secure operation of messages from the moment of installation. 7. A method for recovering a message when the characteristics of a secure channel of a communication partner user are unknown or when the local security message processor cannot decrypt a message received from another user machine. The message manager according to claim 4, characterized in that: 8. A method for ensuring secure transfer of a message between any two of a plurality of user machines, comprising: a message manager and each of the plurality of user machines. Generating the characteristics of a secure channel between; and storing the characteristics of each secure channel between the message manager and each of the plurality of user machines in a management database; Installing a local security message processor on at least one of the plurality of user machines and providing a local database tied to the processor; security between at least one of the plurality of user machines and at least the manager Secure Storing, in the local database, the channel characteristics of each of the plurality of user machines and the channel characteristics of each of the secure channels between each of the plurality of user machines and each of the other user machines; and Securing the messaging between any of the plurality of user machines. 9. The method of claim 2, further comprising the steps of: logging on at two or more of the plurality of user machines; and forwarding a secure message by sending a message to the message manager. 9. The method according to 8. 10. The method of claim 8, wherein generating the secure channel characteristics comprises automatically generating a key and performing automatic authentication. 11. The method of claim 8, wherein the step of generating a secure channel characteristic comprises using an authentication code. 12. The message manager when the characteristics of a secure channel of a user to communicate with are unknown, or when the local security message processor cannot decrypt a message packet received from another user machine. 9. The method of claim 8, further comprising transmitting a message to the server. 13. A method for regenerating characteristics of said secure channel for said secure channel between any two of said plurality of user machines without interrupting a user's communication flow. The method of claim 8, further comprising: 14. The method according to claim 13, wherein the step of regenerating the characteristics of the secured channel includes the step of regenerating the characteristics of the secured channel at predetermined intervals. The described method. 15. The step of regenerating the characteristics of the secure channel comprises regenerating the characteristics of the secure channel when the local security message processor cannot decrypt a message packet received from another user machine. 14. The method according to claim 13, comprising the step of performing.