EP1099334A2 - Systeme de gestion de messages securises - Google Patents

Systeme de gestion de messages securises

Info

Publication number
EP1099334A2
EP1099334A2 EP99935024A EP99935024A EP1099334A2 EP 1099334 A2 EP1099334 A2 EP 1099334A2 EP 99935024 A EP99935024 A EP 99935024A EP 99935024 A EP99935024 A EP 99935024A EP 1099334 A2 EP1099334 A2 EP 1099334A2
Authority
EP
European Patent Office
Prior art keywords
user
message
manager
secure
mail
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99935024A
Other languages
German (de)
English (en)
Inventor
Raviv Karnieli
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vanguard Security Technologies Ltd
Original Assignee
Vanguard Security Technologies Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vanguard Security Technologies Ltd filed Critical Vanguard Security Technologies Ltd
Publication of EP1099334A2 publication Critical patent/EP1099334A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Definitions

  • the present invention relates generally to electronic messaging management systems and, in particular, to secure e-mail communication over the public digital network.
  • a message contains at least the source address, the destination address and the message data.
  • a message When a message is transferred over a telecommunication network it may be sent directly or relayed between one or more servers on its journey from a source user to a destination user. This opens up the possibility of message, including e-mail, exposure or theft by a multiplicity of unknown users, foreign entities and others.
  • E-mail security is a major issue for digital network users, such as Internet users. Individuals are concerned that unknown persons may intercept their personal messages. Companies are concerned about possible leaks or theft of e-mail containing proprietary trade secrets.
  • Fig. 1A details an e-mail network architecture 10 designed to secure privacy of e-mail communication.
  • System 10 comprises a plurality of e-mail clients, known as Users, and a multiplicity of Internet servers 12, generally designated in the drawings as server
  • the destination user in this example user 2, has a mailbox 13, which is located at the server 12B which services user 2.
  • Mail box 13 temporarily stores user 2's mail while user 2 is off-line.
  • user 2 logs-on, he retrieves his mail from mailbox 13.
  • the users have at their disposal a computer 26 installed with an operating system 28, such as Windows. Additionally installed in computer 26, and sitting on top of the operating system 28, is an e-mail package 20, a secured channel data base (SCDB) 22 and a mail securer 30.
  • SCDB secured channel data base
  • a secured channel between any two users is set of properties, known to just the two users, such as the agreed data and key encryption algorithms, keys, key lengths etc..
  • Fig. 1A shows only two users, user 1 and user 2; however, it is understood that e-mail transfer can be performed between any number of users. Additionally, although detail is shown in Fig. 1 for user 1 only, it is apparent that all other users, including user 2, comprise similarly configured elements.
  • the e-mail package 20 is any commercially available e-mail package such as Outlook, Eudora, or Netscape.
  • E-mail package 20 comprises a general electronic address book 18, an inbox 23 and an outbox 24, of the type generally available with commercial e-mail packages. These elements are employed in the t method typically used for commercially available elements of this type.
  • the mail securer 30 is any commercially available secure e-mail managing system such as MAILguardian, available from Vanguard Security Technologies of Haifa, Israel, the common assignee of the present invention. Generally, the mail securer 30 secures the e-mail packet by performing the following 4 steps:
  • a digital signature is attached to the e-mail packet
  • the random key is encrypted using a predefined key and the above chosen encryption algorithm, and is attached to the encrypted packet;
  • SCDB 22 sits on mail securer 30, and contains only the addresses of those users which have security clearance to receive and send secured e- mail.
  • Method 1 User 1 contacts User 2 using any method (i.e. telephone), and together they create a secured channel by exchanging keys. This procedure, known as the shared secret method, must be repeated for each new user added to the SCDB 22.
  • 1's mail securer 30 will notice that user 2 is using the same security software and automatically creates, a secure channel. This attempt will be achieved by a handshake process using internal e-mail messages between User 1's mail securer 30 and User 2's mail securer 30.
  • one or more e-mail packets may pass through non-secured before the secured channel is created for the two with the appropriate keys.
  • a secured channel that is created by either of the two above methods is dedicated to the two users who are paired members of that channel.
  • securer 30 of user 1 secures the e-mail packet with the properties of the secure channel, or alternately, this is known as sending a e-mail along the User 1 - User 2 secured channel.
  • each addressee receives the packet via its own secure channel with the sender. Additionally, a multicast can be sent to user members for which secured channel exists, along with non-user members for which there are no secured channels.
  • Fig. 1B a flow chart of an exemplary e-mail transfer via the e-mail network system of Fig. 1 A.
  • User 1 using e-mail package 20, writes (step 40) an e-mail to user 2.
  • User 1 refers to address book 18 and retrieves (step 42) the address of user 2.
  • User 1 completes the e-mail and request to "SEND".
  • the e-mail package 20 puts (step 44) the e-mail in the outbox 24, and initiates (step 46) connection to the server 12.
  • the e-mail packet passes (step 48) from the e-mail package 20 level to the communication protocol layer (i.e. TCP Socket) at the operating system 28 level.
  • An interceptor i.e. Layered Socket Program
  • the Interceptor hook provides (step 49) the packet to the mail securer 30.
  • Mail securer 30 tries to identify (step 50) the sender and the receiver, user 1 and user 2, respectively, as being a paired member of the SCDB 22. Once they are identified (step 52) as paired members, they are classified as being able to send/receive secured e-mail. Mail securer 30 secures (step 54) the e-mail packet, as detailed hereinabove.
  • mail securer 30 may send (step 56)
  • the secured e-mail packet is injected back (step 60) to the operating system 28.
  • the packet travels (step 62) through the telecommunication media (i.e. Internet), and arrives at user 2's mail box 13 at the server 12B which services user 2.
  • the packet waits (step 64) at user 2's mail box 13 until retrieval by user 2's e-mail package 20.
  • the message is intercepted (step 66) at the communication protocol layer and provided to user 2's securer 30. If the pair user 1- user 2 are members in the user 2's SCDB .22, the e-mail is decrypted (step 67) and injected back to user 2's Operating System 28.
  • User 2's e-mail package 20 receives (step 68) the e-mail in plain text, puts the mail in Inbox 23, and notifies user 2.
  • a messaging system for transferring messages between any two of a plurality of user machines.
  • the system includes a message manager for overseeing secure message operations.
  • the message manager is associated with a management database which stores separate secure channel properties for each message channel between the manager and each of the user
  • the device includes a local secure message processor which secures messages.
  • the processor is associated with a local database.
  • the local database stores secure channel properties per channel between the user machine and each other user machine with which the user machine communicates, including the manager, .
  • a message manager which includes means for installing the local secure message processor on at least one of the user machine and provides the associated local database with at least the secure channel properties of the channel between the manager and the user machine, thereby ensuring secure message operations from generally the moment of installation.
  • the local secure message processor includes means for sending messages to the message manager when the secure channel properties of a user to be communicated with are unknown or when the local secure message processor cannot decrypt a message received from another user machine.
  • the method including the steps of: generating a secure channel properties between a message manager and each of the plurality of user machines; storing in a management data base the secure channel properties for each secure channel between the message manager and each of the plurality of user machine; installing a local secure message processor on at least one of the plurality of user machines and providing the processor with an associated local database; storing in the associated local database secure channel properties between the at least one plurality of user machines and at least the manager, and secure channel properties per channel for each of the secure channels between each of the plurality of user machines and each other user machine; and securing messages between any of the plurality of user machines from generally the moment of installation.
  • a method which includes the steps of logging on at more than one the plurality of user machines, and transferring generally secure message by sending messages to the message manager.
  • generating a secure channel properties includes employing automatic authentication with an automatic key generation, and/or employing an authentication code.
  • the method additionally includes the steps of sending messages to the message manager when the secure channel properties of a user to be communicated with are unknown or when the local secure message processor cannot decrypt an message packet received from another user machine.
  • the method furthermore includes the step of regenerating the secure channel properties for the secure channel between the any two of a plurality of user machines without interrupting user communication flow.
  • regenerating the secure channel properties includes regenerating the secure channel properties every predetermined time period, and/or when the local secure message processor cannot decrypt an message packet received from another user machine.
  • Fig. 1A is a schematic illustration of the architecture of a prior art
  • Fjg. 1 B is a flow chart of the e-mail transfer via the e-mail network of Fig.
  • Fig. 2 is a schematic illustration of the architecture of a secured e-mail
  • Fig. 3A is a flow chart of a secured e-mail transfer procedure of the
  • Fig. 3B is a flow chart of an alternative secured e-mail transfer
  • Fig. 4A is a flow chart of an auto-authenticated installation procedure of
  • Fig. 4B is a flow chart of a user authenticated installation procedure of
  • Fig. 5A is a schematic illustration of the architecture of a multiple
  • Fig. 5B is a flow chart of a multiple location user e-mail transfer
  • Fig. 6 is a flow chart of a damaged key replacement procedure of the secured e-mail network of Fig. 2;
  • Fig. 7 is a flow chart of an aged key refreshing procedure of the secured e-mail network of Fig. 2.
  • FIG. 2 is a schematic illustration of the architecture of a secured e-mail management system 100, constructed and operative in accordance with a preferred embodiment of the present invention. From the moment of installation of the agent at the user's desktop, the present invention provides end-to-end secured e-mail communication channels. In contrast to prior art systems, system 100 is transparent to the nominal user.
  • system 100 includes a multiplicity of users, which have at their disposal computers 26, installed with an operating system 128.
  • the multiplicity of users transmit e-mail over the Internet via servers 12.
  • Each user has e-mail package 20, electronic address book 18, inbox 23, outbox 24, and mailbox 13.
  • Operating system 128 is any available operating system, such as UNIX, MAC or Windows.
  • System 100 further includes a mail security agent 130, a transparent local secured channel data base (LSCDB) 122, and a mail security manager 112 which includes a global management secured channel data base (MSCDB) 114.
  • LSCDB transparent local secured channel data base
  • MSCDB global management secured channel data base
  • the basic functions of each mail security agent 130 are similar to those of mail securer 30. Additionally, in a manner described in detail below, each agent 130, along with manager 112, automatically installs members in each LSCDB 122.
  • each LSCDB 122 is located locally per user and includes the addresses and keys to the other members with whom the local user communicates.
  • user 1 no longer needs to input secured users to the LSCDB 122, and hence, the local
  • LSCDB 122 can be interfaced with in a manner similar to prior art, and hence, LSCDB 122 is also available with a viewable and/or editable option.
  • Manager 112 is a user in system 100, and is serviced by one of the servers 12. Manager 112 holds the MSCDB 114, which is created and imported with members during set-up and continuously updated , as to be described hereinbelow in detail. MSCDB 114 holds the channel properties and keys to all the users in system 100. Thus, inasmuch as manager 112 holds (via the MSCDB 114) the channel properties and keys to all the users in system 100, manager 112 communicates with all the users of system 100. However, MSCDB 114 does not store any of the properties for the secured channel between any two users, these properties are stored only in the LSCDB of the two users involved.
  • the users, or members, of the MSCDB 114 are defined by the company which has installed system 100.
  • System 100 services any user with whom the company wishes to include as a recipient/transmitter of secured e-mail, regardless of their physical location or affiliation.
  • the members of MSCDB 114 can be the employees of the engaging company, who may or may not sit at the same physical site as the company.
  • the member list can also include clients or associates of the company, or any other user with which the company wishes to communicate with on a secured channel.
  • manager 112 Since manager 112 is a user of system 100 and is serviced by a server 12, it can communicate with any user anywhere on the Internet network. Once a user's name and address is added as a member of the MSCDB 114, messages
  • Manager 112 has the additional task of communicating with each agent 130 via control messages, which can be sent in both directions, from manager to agent, and from agent to manager.
  • Control. messages include commands such as "refresh key”, “installation complete”, “recovered key” “message recovered”, etc (to be described in detail hereinbelow).
  • the engaging company has the ability to generate a company policy data base 129.
  • Company policy data base 129 is located at the computer 26 of manager 112 and automatically distributed to computers 26 of each user and regulates the operations of illegal or non-secure e-mail transfer.
  • manager 112 does not participate in message transfer between two users. Manager 112 does participate in message transfers between users if the transfer is the first communication between the users or if there are problems in the transfer.
  • Figs. 3A and 3B illustrate two types of e-mail transfer.
  • Fig. 3A illustrates direct transfer of e-mail without the participation of manager 112.
  • Fig. 3B illustrates transfer of e-mail with the participation of manager 112. Steps of this embodiment which are similar to those which have been described hereinabove in prior art are similarly numbered, and will not be further described.
  • step 149 of Fig. 3A transfer of e-mail from user 1 to user 2 functions generally similar to the prior art of Fig. 1B, except that all steps previously performed by the securer 30 (steps 49, 50, 52, 54, 60, 66 and 67) of Fig. 1 B are presently performed by agent 130 (steps 149, 150, 152, 154, 160, 166 and 168) of Fig. 3A. Additionally, instead of referring in step 49 of Fig. 1 B to the SCDB 22, the present invention refers in step 149 of Fig. 3A to the LSCDB 122.
  • Fig. 3B which illustrates e-mail transfer with the participation of manager 112.
  • User 1 uses e-mail package 20 and writes (step 40) an e-mail to user 2.
  • User 1 refers to address book 18 and retrieves (step 42) the address of user 2.
  • User 1 completes the e-mail.
  • the e-mail package 20 puts (step 44) the e-mail in the outbox 24, and initiates (step 46) connection to the server 12.
  • the e-mail packet passes (step 48) to the communication protocol layer at the operating system 28 level.
  • the interceptor hook observes that the packet is in the communication protocol layer, and provides (step 149) the packet to the mail security agent 130.
  • Mail security agent 130 tries to identify (step 150) the sender and the receiver, user 1 and user 2, respectively, as being a paired member of the LSCDB 122. Agent 130 does not recognize (step 155) user 1 and user 2 as paired members in the LSCDB 122. Agent 130 secures (step 156) the e-mail packet with a predefined set of properties for the secure channel between user 1 and manager 112, and sends the packet to manager 112. Manager 112 refers (step 157) to the MSCDB 114 and tries to identify user 2.
  • manager 112 secures (step 159) the e-mail packet with a predefined set of properties for the secure channel between user 2 and manager 112.
  • the manager 112 generates (step 160) and sends a secured channel key for user 1 - user 2 to both user 1 and user 2. The generation and exchange of the keys allows the next e-mail transmission between user 1 - user 2 (or user 2 - user 1) to take place unaided by the manager 112.
  • Manager 112 sends (steps 161 , 62, 64, 166, and 167) the packet onto user 2, where it is decrypted.
  • the plain text e-mail packet is received (step 168) by Inbox 23 of user 2, which notifies user 2 of its existence.
  • the plain text message does not contain any sign of the manager intervention. It resembles messages sent directly from User 1 to User 2 message, as described previously for Fig. 3A. If user 2 is not found (step 170) in the MSCDB, then manager 112 follows (step 172) company policy as listed in database 129, which may include sending a non secured message, deferring the transfer until such a secured channel is created, discarding the message or returning an error message to user 1 , etc.
  • Fig 4A a flow chart of an automatic authentication installation procedure for the users of system 100 in accordance with a preferred embodiment of the present invention.
  • System 100 creates a secured channel between at least the manager 112 and each user of system 100.
  • the MSCDB 114 is imported and updated with at least the properties of the secured channel for manager 112 and each user of system 100.
  • the LSCDB 122 of each user is automaTJcally installed with at least the properties of the secured channel for manager 112 and said user.
  • the installation procedures commences with installation (step 202) of the manager 112 on the system 100.
  • the company which has engaged system 100, selects the members/users of system 100 and imports (step 204) their names into the MSCDB 114. If, at a later date, the engaging company selects to include additional users onto system 100, this step can be repeated for any new users.
  • Manager 112 then commences the process of securing the members per each user that the manager's operator decide to secure. This process begins by generating (step 206) a Diffie Hellmen (DH) private and public keys for each user member.
  • DH Diffie Hellmen
  • the flow chart in Fig. 4 details the distribution and generation for a single member, user 1; however, it is apparent that this procedure is repeated by manager 112 for all users imported in step 204.
  • Manager 112 saves the DH private key and sends (step 208) the DH public key to user 1 , along with an installation program of agent 130.
  • the installation software can be distributed in many various way, including as an attachment of an e-mail message.
  • User 1 starts the installation program by activating the attachment (i.e. double clicking on the attachment), commencing (step 210) with installation of agent 130.
  • Agent 130 generates (step 212) its own DH public and private keys. Agent 130 then generates (step 214) from its own private key and the received public key a whole DH key, and use it to generate the secured channel.
  • Agent 130 automatically sends (step 216) (from user 1) to the manager 112, along the now secured channel, a secured "Installation Complete” message, preceded with its DH public key (which is sent in clear text).
  • Manager 112 retrieves (step 218) User 1's DH public key and generates (step 220) from the retrieved key and the saved DH private key the same whole DH key. This allows manager 112 to read and decrypt (step 222) the secured "Installation Complete” message. If the "Installation Complete" message is correctly decrypted, Manager
  • Fig.. 4B a flow chart of the user authentication installation procedure for system 100 in accordance with a preferred embodiment of the present invention.
  • DH Diffie Hellman
  • Steps 202 and 204 from Fig. 4A are repeated for this embodiment even though they might be avoided if they where already performed earlier.
  • the manager 112 instead of generating the Diffie Hellman (DH) Private and Public keys, the manager 112 generates (step 250) a random Authentication Code, and provides
  • manager 112 uses the Authentication Code and creates (step 254) a key for the manager - user 1 secure channel.
  • Manager 112 records (step 256) the properties of the secure channel for sending between user 1 and manager 112 in the MSCDB 114 and sends (step 258) the agent 130 software installation program to user 1 , as an example, as an attachment of an e-mail message to user 1.
  • Agent 130 asks (step 266) for the Authentication Code and uses it to generate (step 268) a key for the secured channel.
  • Agent 130 automatically sends (step 270) (from User 1) to the manager 112, along the now secured channel, a secured "Installation Complete” message.
  • Manager 1 2 reads and decrypts (step 272) the secured "Installation Complete” message using the key saved in step 254. If the "Installation Complete" message is correctly decrypted, Manager 112 marks off (step 274) User 1 as being installed.
  • an e-mail packet is secured by performing at least the following steps. 1) A digital signature is attached to the e-mail packet;
  • the e-mail packet and the digital signature are encrypted, using a random number as a key and the secure channel data encryption algorithm which can be any of the commercially available encryption algorithm, such as Data Encryption Standard (DES) or Blowfish; 3) the random (number) key is encrypted using a predefined key of a secure channel and the secure channel key encryption algorithm, which can be any of the commercially available encryption algorithm, such as Data Encryption Standard (DES) or Blowfish, and is attached to the encrypted packet; 4) the random key is also encrypted using the key for the User 1 -
  • DES Data Encryption Standard
  • Blowfish Data Encryption Standard
  • manager secure channel and the above chosen data encryption
  • system 100 provides manager 112 with the ability to decrypt the e-mail random number key, system 100 provides the flexibility of the following alternative options;
  • Fig. 5A shows a schematic diagram of system 100 with one or more users in a multiple location setup. As may occur from time to time, one or more users may log-on at one or more locations. As illustrated in the exemplary situation in Fig. 5A, user 2 is registered at two different locations; location A and location B. However, both locations of user 2 use the same server 12 and the same mailbox 13.
  • System 100 is aware that user 2 has two different log-on sites; however, the system does not know where user 2 will be the next time that he logs on. Moreover, it is not practical for Manager 130 to update LSCDB 122 for each site user 2 is using.
  • manager 112 Once system 100 receives an "Installation Complete" message from user 2 with a new, or second, computer ID, manager 112 declares the user as a multi-location user. Manager 112 provides user 2 at both locations with the same key for User 2 - manager secured channel. Additionally, manager 112 ceases to create secure channels for users 2 with other member users . Moreover, manager 112 also tries to ask users 2 to clear all their secure channels with other users and leave only the secure channel with the manager 112 active. In this manner, user 2 can always receive his e-mail, secured, through his secure channel with manager 112.
  • Fig. 5B a flow chart illustrating the e-mail process for Users with Multiple locations. Steps of this embodiment which are similar to those illustrated in Fig. 3A have been described hereinabove in detail, will not be further described.
  • user 1 writes (step 302) e-mail to User 2.
  • the e-mail packet is encrypted (step 304) to be delivered to User 2.
  • the e-mail is detoured (step 306) and sent to manager 112.
  • Manager 112 receives (step 314) the e-mail packet from User 1. Manager 112 then decrypts (step 316) the e-mail packet using his user 1-
  • Manager 112 then re-encrypts (step 318) the opened e-mail packet with the properties of the user 2-manager secure channel, and sends (step 320) the now encrypted e-mail packet onto user 2.
  • User 2 which has a key for manager 112, receives (322) and decrypts the packet.
  • Fig. 6 a flow chart illustrating the steps to be followed in repair of a damaged key.
  • User 1 sends (step 350) a secured e-mail packet to user 2.
  • the e-mail packet is encrypted (step 352) to be delivered to user 2.
  • User 2 receives (step 354) the e-mail however, user 2 cannot open (step 356) the packet. Either the key held by user 1 is damaged, or the key held by user 2 is damaged.
  • the agent 130 at user 2 sends (step 360) the unopened packet to manager 112, along with a message informing the manager that he (user 2) has mail he cannot open.
  • all e-mail packets are encrypted with a key for the user - manager 112 secured line.
  • manager 112 received a key for the e-mail packet on the user 1 - Manager secured line in step 352, the original transfer of the e-mail packet.
  • manager 112 can decrypt (step 364) the packet using the user 1- manager 112 key carried by the original messages.
  • Manager 112 re-encrypts (step 366) the opened e-mail packet with the properties of the user 2-manager secure channel and sends the now encrypted e-mail packet onto user 2.
  • User 2 which has a key for the manager 112, receives (step 368) and decrypts the packet.
  • Manager 112 selects a random new key for (step 372) to user 1 and user 2.
  • the exchange of the replacement keys allows the next e-mail transmission between user 1 and user 2 to take place unaided by the manager 112. Refresh of an aged key
  • Manager 112 updates keys on a predetermined cycle, as an example, every three weeks. Upon the conclusion of the cycle, user 1 asks to refresh his key with user 2. Manager 112 updates (step 402) the user 1 - user 2 key by generating a new random key and sending it to the two users. Each new key is appointed with the manager's creation time, which is the manager's computer time of the key generation of the key. While user 1 receives the new key with the actual creation time, user 2 will receive a later creation time to reduce the probability that the two users will ask for key refresh at the same time, and thus create collision.
  • User 1 and user 2 can continue their communication without noticing the key refresh process being performed in the background. If user 1 receives the new key and uses it before user 2 received the new key, manager 112 still can recover the message.
  • user 1 receives (step 403) its new key.
  • User 1 sends (step 404) a secured e-mail packet to user 2.
  • the e-mail packet is encrypted (step 406) using the new key and delivered to user 2.
  • User 2 receives (step 408) the e-mail, however, since user 2 does not have the updated key, he cannot open (step 410) the packet.
  • the agent 130 at user 2 recognizes that the message is secured using a new version of the key.
  • User 2 sends (step 414) the unopened packet to manager 112, along with a message informing the manager that he (User 2) has mail he cannot open because it is encrypted using a new version of the key.
  • manager 112 When manager 112 receives (step 416) the message from User 2 about the e-mail packet from User 1 , manager 112 decrypts (step 418) the packet using his user 1 - manager 112 key.
  • Manager 112 re-encrypts (step 420) the packet with the properties of the user 2-manager secure channel.
  • Manager 112 sends (step 424) the packet onto User 2.
  • User 2 receives (step 426) and decrypts the packet. If User 2 sends a message to User 1 using the old key, User 1 can still decrypt it. Each user preserves old keys in the LSCDB until the first message is decrypted with the new key.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

Système de messagerie destiné au transfert de messages entre deux machines utilisateurs d'une pluralité de machines utilisateurs. Le système comprend un gestionnaire de messages destiné à prévoir les opérations de messages sécurisés. Le gestionnaire de messages est associé à une base de données de gestion, laquelle stocke les propriétés séparées des canaux sécurisés pour chaque canal de message entre le gestionnaire et chacune des machines utilisateurs. De plus, par machine utilisateur, le dispositif comprend un processeur local de messages sécurisés, lequel sécurise les messages. Le processeur est associé à une base de données locale. La base de données locale stocke les propriétés des canaux sécurisés par canal entre la machine utilisateur et chaque autre machine utilisateur avec laquelle la machine utilisateur communique, y compris le gestionnaire.
EP99935024A 1998-07-26 1999-07-26 Systeme de gestion de messages securises Withdrawn EP1099334A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IL12551698 1998-07-26
IL12551698A IL125516A0 (en) 1998-07-26 1998-07-26 Secure message management system
PCT/IL1999/000408 WO2000007355A2 (fr) 1998-07-26 1999-07-26 Systeme de gestion de messages securises

Publications (1)

Publication Number Publication Date
EP1099334A2 true EP1099334A2 (fr) 2001-05-16

Family

ID=11071784

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99935024A Withdrawn EP1099334A2 (fr) 1998-07-26 1999-07-26 Systeme de gestion de messages securises

Country Status (6)

Country Link
EP (1) EP1099334A2 (fr)
JP (1) JP2002521970A (fr)
AU (1) AU5062599A (fr)
CA (1) CA2338530A1 (fr)
IL (1) IL125516A0 (fr)
WO (1) WO2000007355A2 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10008519C1 (de) * 2000-02-21 2001-07-12 Dica Technologies Ag Verfahren und Kommunikationseinrichtungen zum Aufbau von gesicherten E-Mail-Verkehr zwischen Mail-Domains des Internet
SE517116C2 (sv) * 2000-08-11 2002-04-16 Ericsson Telefon Ab L M Metod och anordning för säkra kommunikationstjänster
JP2003101493A (ja) * 2001-09-25 2003-04-04 Mitsubishi Electric Corp 情報端末、情報配信装置及び情報配信システム
US7529937B2 (en) * 2005-03-07 2009-05-05 Microsoft Corporation System and method for establishing that a server and a correspondent have compatible secure email
US8219623B2 (en) 2005-12-16 2012-07-10 Microsoft Corporation Email transport rule per-recipient condition
US8028026B2 (en) 2006-05-31 2011-09-27 Microsoft Corporation Perimeter message filtering with extracted user-specific preferences
US8726020B2 (en) 2006-05-31 2014-05-13 Microsoft Corporation Updating configuration information to a perimeter network
US8549295B2 (en) 2006-05-31 2013-10-01 Microsoft Corporation Establishing secure, mutually authenticated communication credentials
JP2011159244A (ja) * 2010-02-04 2011-08-18 Sumitomo Electric System Solutions Co Ltd 電子メール送信制御プログラム、動作方法、コンピュータ装置
CN108667609B (zh) 2017-04-01 2021-07-20 西安西电捷通无线网络通信股份有限公司 一种数字证书管理方法及设备
CN112583591A (zh) * 2020-12-23 2021-03-30 维沃移动通信有限公司 应用程序控制方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3263878B2 (ja) * 1993-10-06 2002-03-11 日本電信電話株式会社 暗号通信システム
JPH07245605A (ja) * 1994-03-03 1995-09-19 Fujitsu Ltd 暗号化情報中継装置とそれに接続される加入者端末装置ならびに暗号通信方法
US5944794A (en) * 1994-09-30 1999-08-31 Kabushiki Kaisha Toshiba User identification data management scheme for networking computer systems using wide area network
US5781632A (en) * 1995-02-08 1998-07-14 Odom; Gregory Glen Method and apparatus for secured transmission of confidential data over an unsecured network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0007355A2 *

Also Published As

Publication number Publication date
AU5062599A (en) 2000-02-21
WO2000007355A3 (fr) 2000-05-18
JP2002521970A (ja) 2002-07-16
IL125516A0 (en) 1999-10-28
CA2338530A1 (fr) 2000-02-10
WO2000007355A2 (fr) 2000-02-10

Similar Documents

Publication Publication Date Title
US6363480B1 (en) Ephemeral decryptability
US6988199B2 (en) Secure and reliable document delivery
US7277549B2 (en) System for implementing business processes using key server events
US7596689B2 (en) Secure and reliable document delivery using routing lists
US7409545B2 (en) Ephemeral decryption utilizing binding functions
US20080065878A1 (en) Method and system for encrypted message transmission
US7580980B2 (en) Email system restoring recipient identifier based on identifier-for-disclosure for establishing communication between sender and recipient
US20030196080A1 (en) Secure communication via the internet
CN1328735A (zh) 用于保护数据对象的方法与系统
CA2295150A1 (fr) Transmission de donnees
US20100037050A1 (en) Method and apparatus for an encrypted message exchange
JP2006520112A (ja) セキュリティ用キーサーバ、否認防止と監査を備えたプロセスの実現
US20060053294A1 (en) System and method for proving time and content of digital data in a monitored system
EP1099334A2 (fr) Systeme de gestion de messages securises
GB2339367A (en) Secure communication
WO2000031944A1 (fr) Passerelle securisee pour courrier electronique
US7392385B2 (en) Client server system and devices thereof
Kline et al. Public key vs. conventional key encryption
EP1357697B1 (fr) Communication sécurisée via l'Internet
JP2002118546A (ja) 公開鍵取扱装置及び通信装置
US20070079114A1 (en) Method and system for the communication of a message as well as a suitable key generator for this
JP2001094600A (ja) メッセージ転送ノード及びネットワーク
Bai et al. Access revocation and prevention of false repudiation in secure email exchanges
JP2001144798A (ja) メール配信システム、メール配信方法及び電子メール装置
JP2005010879A (ja) 電子メールシステムおよび電子メールサーバ

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010223

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

RIC1 Information provided on ipc code assigned before grant

Free format text: 7G 06F 13/00 A, 7G 06F 15/16 B, 7H 04L 9/00 B

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20020715