WO2001024434A1 - System for providing messages - Google Patents

System for providing messages Download PDF

Info

Publication number
WO2001024434A1
WO2001024434A1 PCT/IL2000/000526 IL0000526W WO0124434A1 WO 2001024434 A1 WO2001024434 A1 WO 2001024434A1 IL 0000526 W IL0000526 W IL 0000526W WO 0124434 A1 WO0124434 A1 WO 0124434A1
Authority
WO
WIPO (PCT)
Prior art keywords
recipient
message
key
query
encrypted
Prior art date
Application number
PCT/IL2000/000526
Other languages
French (fr)
Inventor
Avraham Nahir
Original Assignee
B.M.N. Technology
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 B.M.N. Technology filed Critical B.M.N. Technology
Priority to AU68621/00A priority Critical patent/AU6862100A/en
Publication of WO2001024434A1 publication Critical patent/WO2001024434A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key 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/0822Key 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key 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/083Key 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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42Anonymization, e.g. involving pseudonyms

Definitions

  • the present invention relates to message sending systems in general, and in particular to message sending systems which are designed to protect anonymity.
  • Message sending systems including systems for sending a message to a plurality of recipients in accordance with a recipient profile, are well known in the art.
  • profile-based messaging systems the follow main elements are present: a message to be sent; a profile defining the type of recipient who is intended to receive the message; and one or more actual addresses to which the message was or is to be sent.
  • Consumer privacy is a major concern in contemporary messaging systems. It is widely deemed desirable to keep the actual addresses secret from the sender of the message.
  • Patent 5,614,927 which describes a method for protecting confidential information in a database for enabling targeted advertising
  • the present invention seeks to provide an improved message sending system.
  • a message provider provides a message and a profile of intended recipients.
  • the message and the profile are processed separately, in order to protect the anonymity of the intended recipients, who are determined based, at least in part, on the profile.
  • the objects of the preferred embodiment are realized with a careful division of responsibilities between system components and appropriate use of encryption.
  • a method is provided for anonymous extraction of information from a database, in which the question and the answer are separated, preferably so that no entity knows both the question and the answer.
  • the encryption key and the decryption key are identical.
  • the integrator is also operative, before sending the encrypted message and the decryption key encrypted according to the recipient key, to further encrypt the encrypted message and the decryption key encrypted according to the recipient key, according to a second recipient key.
  • the recipient key and the second recipient key are identical.
  • the anonymous profile handler is operative to determine the recipient list by formulating at least one database query and utilizing a response to the at least one database query to determine the recipient list.
  • the anonymous profile handler includes a query manager operative to decompose the database query into a plurality of database sub queries, and a plurality of query handlers, each query handler receiving a database sub query from the query manager and being operative to determine at least a portion of the recipient list by formulating at least one database sub query and utilizing a sub response to the at least one database sub query to determine the at least a portion of the recipient list, wherein the query manager is also operative to provide, to each query handler, a destination and each query handler is operative to transmit the portion of the recipient list determined by the query handler to the destination provided to the query handler.
  • At least one of the query handlers includes a plurality of query handling sub-components, the plurality of query handling sub-components being operative, when operating together, to determine the at least a portion of the recipient list.
  • the formulating at least one database query includes formulating the at least one database query using secure methods to control use of the at least one database query.
  • the system also includes an answer manager, wherein the query handler is operative to determine information about the recipient list, not including information about an address of each recipient, and the answer manager receives the information about the recipient list and is operative to determine the information about the address of each recipient based, at least in part, on the information about the recipient list.
  • the information about the address of each recipient includes the address of each recipient.
  • the system also includes a comparator operative to compare the addresses of each recipient and to remove duplicates from the addresses. Additionally in accordance with a preferred embodiment of the present invention the information about the address of each recipient does not include the address of each recipient, and the system also includes an address translator operative to receive the information and to determine therefrom the address. Moreover in accordance with a preferred embodiment of the present invention the address translator is located remotely to the query handler. Further in accordance with a preferred embodiment of the present invention the query handler and the answer manager are distributed on separate systems.
  • a method for providing a message from a message provider to a message recipient including receiving a message to be sent to the at least one message recipient, and encrypting at least the message in accordance with an encryption key, receiving a profile defining characteristics of at least one message recipient and determining based, at least in part, on the profile, a recipient list including one or more recipients for the message, receiving the recipient list and a decryption key associated with the encryption key and separately encrypting the decryption key in accordance with a recipient key of each recipient, and ' receiving the message encrypted in accordance with the encryption key and the encrypted decryption key. separately encrypted in accordance with the recipient key of each recipient, and sending to each one recipient the encrypted message and the decryption key encrypted according to the recipient key of the one recipient.
  • the encryption key and the decryption key are identical. Still further in accordance with a preferred embodiment of the present invention the receiving the message encrypted step also includes, before sending the encrypted message and the decryption key encrypted according to the recipient key, further encrypting the encrypted message and the decryption key encrypted according to the recipient key. according to a second recipient key. Additionally in accordance with a preferred embodiment of the present invention the recipient key and the second recipient key are identical.
  • FIG. 1 is a simplified block diagram illustration of a message providing system constructed and operative in accordance with a preferred embodiment of the present invention:
  • Fig. 2 is a simplified flowchart illustration of a preferred method of operation of the system of Fig. 1 ;
  • Fig. 3 is a simplified block diagram illustration of a preferred embodiment of a portion of the apparatus of Fig. 1 ;
  • FIG. 4 is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 3;
  • Fig 5 is a simplified block diagram illustration of an alternative preferred embodiment of a portion of the apparatus of Fig. 1: and
  • Fig. 6 is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 5
  • Fig. 1 is a simplified block diagram illustration of a message providing system constructed and operative in accordance with a preferred embodiment of the present invention.
  • the message providing system of Fig. 1. designated generally 100, is designed to allow a message provider 130 to send a message to one or more recipients while the identity of the recipients remains shielded from the message provider 130. It is appreciated that the message provider 130 may alternatively be considered as external to the system 100, so that the remainder of the elements of Fig. 1 comprise a subcombination which may, without the message provider 130. comprise a preferred embodiment of the present invention.
  • the message providing system 100 comprises a provider domain 1 10 and a system domain 120.
  • the provider domain 1 10 comprises elements of the message providing system 100. described below, which are associated with the operation of a sender, also termed provider, of a message.
  • the system domain 120 comprises elements of the message providing system 100. described below, which are associated with the processing and carrying out of requests received from the provider domain 1 10.
  • Assignment of particular elements to the provider domain 1 10 or to the system domain 120. as described below, is believed to be a preferred assignment in order to maintain security and to achieve the objects of the system of Fig. 1 in an optimum way: it is appreciated, however, that it would alternatively be possible to assign elements to the provider domain 1 10 or to the system domain 120 in a different way. or to assign all elements of the system of Fig. 1 to a single domain.
  • the provider domain 1 10 preferably comprises a message provider 130, referred to above.
  • the message provider 130 is typically implemented in an appropriate combination of hardware and software and may operate in accordance with the instructions of an operator (not shown) external to the message provider 130. such as a human operator or an automated operator.
  • the message provider 130 is preferably operatively associated with a request encryptor 140 and with an anonymous profile handler 150.
  • the request encryptor 140 is preferably implemented in a suitable combination of software and hardware and is preferably operative to encrypt its input and to output the encrypted input 146 and, preferably separately, a decryption key 143 with which the encrypted input 146 can be decrypted. It is appreciated that many appropriate encryption schemes are well known in the art. and that any appropriate scheme may be used. In the case of a symmetric encryption scheme, as is well known in the art. the decryption key 143 may or may not be identical to an encryption key (not shown) according to which the encrypted input 146 is encrypted. In the case of an asymmetric encryption scheme, as is well know in the art, the decryption key 143 will generally be different from the encryption key (not shown). It is appreciated that, in a preferred embodiment, the present invention is meant to include all appropriate possibilities of the relationship between the decryption key 143 and the encryption key.
  • the request encryptor 140 is preferably comprised in the provider domain 1 10.
  • the request encryptor 140 may use any appropriate key-based encryption method known in the art such as. for example, a public key encryption method, a symmetric encryption method, or any other appropriate encryption method. It is appreciated that, in practice, tradeoffs such as security versus ease of computation may play a part in determining which encryption method is used by the request encryptor 140. A preferred mode of operation of the request encryptor 140 is described in more detail below.
  • the decryption key 143 corresponding to each encrypted input 146 is different from every other decryption key 143 corresponding to another encrypted input 146.
  • the anonymous profile handler 150 is preferably comprised in the system domain 120.
  • the anonymous profile handler 150 is preferably implemented in a suitable combination of hardware and software and is preferably operative to produce a list of message recipients from a profile describing preferred qualities of message recipients. A preferred mode of operation of the anonymous profile handler 150 is described in more detail below.
  • the message providing system 100 also preferably comprises a recipient handler 160. which is preferably comprised in the system domain 120 and is preferably implemented in an appropriate combination of hardware and software.
  • the recipient handler 160 is preferably operatively associated with the request encryptor 140 and with the anonymous profile handler 150.
  • the recipient handler 160 is preferably operative to receive a first key. also referred to herein as a decryption key.
  • the message providing system 100 also preferably comprises an integrator 170. which is preferably comprised in the system domain 120 and is preferably implemented in an appropriate combination of hardware and software.
  • the integrator 170 is preferably operatively associated with the request encryptor 140 and the recipient handler 160.
  • the integrator 170 preferably receives a message encrypted with an encryption key and a plurality of encrypted forms of a decryption key associated with the encryption key as described above, each decryption key being encrypted with a different recipient key associated with one recipient of a plurality of recipients.
  • the integrator 170 also preferably receives a plurality of addresses, each associated with one recipient of the plurality of recipients.
  • the integrator 170 is preferably operative to send a message to each of the plurality of recipients, shown for simplicity of description as a message recipient 180.
  • Each message preferably comprises the message encrypted with the encryption key and the encrypted form of the associated decryption key encrypted with the encryption key of the message recipient 180. comprising a compound message.
  • the compound message is preferably further encrypted using an encryption key of the message recipient 180. either the same key as referred to above or another encryption key of the message recipient 180. It is believed that the further encryption of the compound message has the effect of increasing the security of the system of Fig. 1.
  • the message provider 130 preferably send a message 190 to the request encryptor 140.
  • the message provider 130 also preferably sends a profile 200 to the anonymous profile handler 150.
  • the profile 200 preferably comprising an appropriate list of characteristics which may be used to identify one or more intended recipients of the message 190.
  • the profile 200 may specify "residents of neighborhood X of city Y who subscribe to cable television " , with X and Y being used in the example to represent real names which would be used in a real profile 200 instead of X and Y.
  • the profile 200 may be expressed in any appropriate form such as, for example: in a natural language form, in which case the anonymous profile handler 150 preferably comprises a natural language interpretation module (not shown), as is well known in the art: in an internal form, preferably an internal form readable by the anonymous profile handler 150; or otherwise.
  • a natural language interpretation module not shown
  • the request encryptor 140 preferably receives the message 190. preferably determines an encryption key (not shown), the encryption key being associated with the decryption key 143 as described above, for use in processing the message 190. encrypts the message 190 in accordance with the encryption key. and sends the encrypted message 146 to the integrator 170. The request encryptor 140 also preferably sends the decryption key 143. which can be used to decrypt the message 190. to the recipient handler 160.
  • the anonymous profile handler 150 preferably receives the profile 200 and determines therefrom a list of recipients 210.
  • the list of recipients 210 preferably comprising a plurality of recipient entries 220.
  • Each of the plurality of recipient entries 220 preferably comprises information for one recipient, said information for one recipient comprising a recipient key and an address for sending messages to the one recipient.
  • the recipient key may, for example, comprise a public key known to be associated with the one recipient, or may comprise some other key known to the one recipient.
  • a preferred implementation of the anonymous profile handler 150 is described in more detail below with reference to Fig. 3.
  • the anonymous profile handler 150 preferably supplies the plurality of recipient entries 220 to the recipient handler 160.
  • the recipient handler 160 preferably performs the following tasks for each recipient in each of the plurality of recipient entries 220:
  • the key of the recipient as described above, is used to encrypt the decryption key 143, and a key entry 230 is created comprising the decryption key 143 encrypted with the key of the recipient and the address of the recipient.
  • the plurality of key entries 230 thus produced is passed on to the integrator 170.
  • the integrator 170 preferably creates, for each message recipient 180, an output message comprising: the message 190 encrypted with the encryption key; and the decryption key 143 encrypted with the key of the recipient, as received in the key entry 230 for the recipient.
  • the output message preferably encrypted with a recipient key as described above, is then sent to each message recipient 180.
  • Fig. 2. is a simplified flowchart illustration of a preferred method of operation of the system of Fig. 1.
  • the method of Fig. 2 preferably comprises the following steps:
  • a message is received, the message intended to be sent to at least one message recipient (step 250).
  • the message is encrypted in accordance with an encryption key (step 260).
  • a profile is received, the profile defining characteristics, but typically not the actual identity, of at least one message recipient (step 270).
  • a recipient list is determined, based, at least in part, on the profile (step 280).
  • the recipient list and the decryption key are received, typically by a system component different than the components which carried out the previous steps (step 290).
  • the decryption key is separately encrypted, typically being encrypted once in accordance with a recipient key of each recipient in the recipient list (step 300).
  • the message encrypted in accordance with the encryption key and the encrypted decryption key, separately encrypted in accordance with the recipient key of each recipient, are received, typically by another system component (step 310).
  • Each one recipient is then sent the encrypted message, along with the decryption key encrypted according to a recipient key of the one recipient (step 320).
  • the encrypted message and the encrypted decryption key are further encrypted according to a recipient key. which may be the same as or different from the recipient key used to encrypt the decryption key.
  • Fig. 3 is a simplified block diagram illustration of a preferred implementation of a portion of the apparatus of Fig. 1.
  • the apparatus of Fig. 3 comprises a preferred implementation of the anonymous profile handler 150 of Fig. 1 : it is appreciated that other preferred implementations are also possible.
  • the apparatus of Fig. 3 is preferably implemented in software running on appropriate hardware; alternatively, portions or all of the apparatus of Fig. 3 may be implemented in special purpose hardware, for performance, for security, or for other considerations.
  • the anonymous profile handler 150 preferably receives the profile 200 and determines therefrom a list of recipients 2 10.
  • the profile 200 may be considered a question or query directed at a database, while the list of recipients 210 may be considered an answer to the question.
  • the anonymous profile handler in structure and in function, is designed to insulate information about the question from information about the answer, such that preferably there is no component of the anonymous profile handler 150 which knows both the question and the answer.
  • the system of Fig. 1 is considered as an "application " , as the term is commonly used in the art, than the application is to be prevented from such knowledge, while such knowledge is only to be available in full at the level of an underlying "systeirT. as the term is commonly used in the art. which system may be chosen for fulfilling appropriate security constraints.
  • the apparatus of Fig. 3 preferably includes a question handler 330 and an answer handler 340.
  • the question handler 330 is preferably operative to receive the profile 200 and to pass the profile 200 on, as described in more detail below, for further processing.
  • the answer handler 340 is preferably designed to receive an answer, as described in more detail below, and to output the answer in the form of the list of recipients 210.
  • a QA-Wall implementation the separation of the Query-Response is achieved across space; that is, across the virtual space of a database schema. Considering a database schema as a map. the QA-Wall method divides the world of the schema between owners.
  • the data is preferably organized in tables, which are organized - conceptually - using links. For example, if a telephone call at a switch originates in an extension, then the Call table will have a link - a foreign key. to the Extension table.
  • the field at the Call table may be called something like "OriginExtension " . and it will preferably contain values that will preferably correspond to the key in the Extension table, probably called ID.
  • ID the number of each table may also be considered to be bound to each other by a link - the fact that they belong to the same table.
  • “Avi” is bound to "Nahir " in the record "Avi Nahir " because the columns holding the two parts of the name "Avi Nahir" are in the same table.
  • one connecting columns of a table which is broken, it is typically necessary to add linkage information for the spawned table.
  • linkage information for every relation that spans a partition boundary, it is necessary to add a work table to each partition such that one owner can write linkage information to it. and the other owner can read linkage information from it.
  • a type of temporal separation is preferably employed: someone creates a procedure and then another person executes it.
  • a stored procedure must be stored in a manner that the source of the stored procedure can not be retrieved.
  • Microsoft SQL for example, it is possible to encrypt stored procedures in order to obtain the feature of non-retrieval of the source.
  • a stored procedure is created from an
  • any SQL Query-Response can be modified to run using the ESP.
  • the SQL queries discussed above with reference the QA-Wall implementation can, and sometimes should, be run using this technique. It is thus appreciated that appropriate QA-Wall and encrypted stored procedure features, as described above, may be combined in a single embodiment as appropriate.
  • the question handler 330 and the answer handler 340 are insulated from each other, except for a carefully defined interface, so that only permitted data may pass between them.
  • Techniques for insulating one system component from another, including isolation in separate processes under operating system control, are well known in the art.
  • the apparatus of Fig. 3 also preferably comprises a question source 350.
  • the question source 350 preferably comprises, for each entry therein, a question field 360 and a link field 370.
  • the link field is designed to be uncorrelated either with the question field or with any information related to the question field. For example, and without limiting the generality of the foregoing, some questions and links might be: Questions Links
  • the question handler 330 is then operative to pass the links 420 to the answer handler 340; passing the links for resolution is preferably the only communication permitted between the question handler 330 and the answer handler
  • the apparatus of Fig. 3 also preferably comprises an answer source 380. which may comprise an appropriate table in an appropriate database management system.
  • the answer source 380 preferably comprises, for each entry therein, an answer link field 390 and an answer field 400.
  • the link field comprises link information corresponding the question link field 370.
  • some answers and links might be:
  • the answer handler is preferably operative to look up the links 420 in the answer source 380. and to extract the answer 430 therefrom.
  • the answer 430 would comprise: xxx@qqq.com: and yyy@yyy.com.
  • FIG. 4 is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 3.
  • the method of Fig. 4 is self-explanatory with reference to the above discussion.
  • Fig 5 is a simplified block diagram illustration of an alternative preferred embodiment of a portion of the apparatus of Fig. 1.
  • the apparatus of Fig. 5 comprises an alternative preferred implementation of the anonymous profile handler 150 of Fig. 1 ; it is appreciated that other preferred implementations are also possible.
  • the elements of the apparatus of Fig. 5 are preferably implemented in an appropriate combination of software and hardware, as is well known in the art; alternatively, the apparatus of Fig.
  • the software components of the apparatus of Fig. 5 may be partly or wholly implemented in special purpose hardware, as is well known in the art.
  • the software components of the apparatus of Fig. 5 are preferably implemented in an appropriate database management system, such as. for example. Microsoft SQL 7.0. commercially available from Microsoft Corporation.
  • the software components of the apparatus of Fig. 5 may be implemented in any other appropriate database management system, or otherwise as appropriate.
  • the apparatus of Fig. 5 preferably comprises a stored procedure definer 450. which is preferably operative to receive the profile 200 (Fig. 1) and to produce therefrom an appropriate procedure 460.
  • the procedure 460 is preferably operative, when executed, to produce an appropriate answer based on the profile 200. typically using a database management system as described above.
  • the stored procedure definer 450 is preferably designed, typically using security features of the database management system such as Microsoft SQL 7.0. to be capable of producing the procedure 460 but not of executing the procedure 460.
  • the inability of the stored procedure definer 450 to execute the procedure 460 may be based on the stored procedure definer 450 lacking privileges necessary to access database tables in which information necessary to execute the procedure 460 is stored.
  • the stored procedure definer 450 is preferably operative to store the procedure 460 in a procedure store 470.
  • a procedure store 470 which may comprise any appropriate procedure store, such as a store defined within the database management system or another appropriate store.
  • the apparatus of Fig. 5 also preferably comprises a changer 475, which is preferably operative to change one or more of procedure permissions, ownership control information, or other information associated with the procedure 460 stored in the procedure store 475.
  • the change carried out by the changer 475 should allow a stored procedure executor 480. also comprised in the apparatus of Fig. 5, to execute the stored procedure 460, upon retrieval of the stored procedure 460 from the procedure store 470.
  • permissions are set and access granted such that the stored procedure executor 480 may only execute the stored procedure 460. and may not in any other way access underlying data, such as database tables, which are accessed by the stored procedure 460.
  • the output of the execution of the procedure 460 by the stored procedure executor 480 typically comprises the list of recipients 210 (Fig. 1).
  • Microsoft SQL 7.0 includes facilities such as procedure permissions, ownership control, and other similar facilities which could be used by a skilled person of the art in implementing the apparatus of Fig. 5.
  • Microsoft SQL 7.0 includes appropriate facilities which are documented, inter alia, in a section entitled "SP Deferred Name Resolution and Compilation" in the Microsoft SQL 7.0 server documentation, referred to above.
  • Fig. 6. is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 5. The method of Fig. 6 is self-explanatory with reference to the above description.
  • all communications between various elements are preferably secure and authenticated, preferably using methods well known in the art, to prevent an attack on the integrity of the system by eavesdroppers, impersonators, and so forth.

Abstract

This invention discloses a system for providing a message (190) from a message provider (130) to a message recipient (180) where the identity of the message recipient (180) is unknown to the message provider (130). The system includes a request encryptor (140) operative to receive and encrypt a message (190) that will be sent to at least one message recipient (180). The system further includes an anomymous profile handler (150) that determines based on a profile of the message recipient (180) which message (190) to deliver to the message recipient (180). The system also includes a recipient handler (160) that encrypts the decryption key in accordance with a recipient key of each recipient and an integrator (170) that sends the encrypted message and the encrypted decryption key to the message recipient (180).

Description

SYSTEM FOR PROVIDING MESSAGES FIELD OF THE INVENTION The present invention relates to message sending systems in general, and in particular to message sending systems which are designed to protect anonymity.
BACKGROUND OF THE INVENTION Message sending systems, including systems for sending a message to a plurality of recipients in accordance with a recipient profile, are well known in the art. Generally, in profile-based messaging systems the follow main elements are present: a message to be sent; a profile defining the type of recipient who is intended to receive the message; and one or more actual addresses to which the message was or is to be sent. Consumer privacy is a major concern in contemporary messaging systems. It is widely deemed desirable to keep the actual addresses secret from the sender of the message.
The following references describe useful background technologies for understanding and appreciating the present invention: S. Loeb & Y. Yacobi, "Private Information Filters in a Public
Network". Proc. of the Con, on High Perf. Info. Filtering, pp. 1-3, 1991; US
Patent 5,614,927, which describes a method for protecting confidential information in a database for enabling targeted advertising;
Lecture Notes in Statistics 111, Leon Willenborg , Ton de Waal, Statistical Disclosure Control in Practice. 1996, Springer- Verlag, ISBN 0-387-94722-1, 1996;
Bruce Schneier, Applied Cryptography, John Wiley & Sons, Inc. ISBN 0-471-11709-9, 1996, chapter 2;
Nyms ZKS, which is described on the Internet World Wide Web (WWW) at www.zks.net;
SUBSTITUTE SHEET (RULE 26, Privacy Enhancing Technologies: The Path to Anonymity, Registratiekamer. The Netherlands. Information and Privacy Commissioner. Ontario. Canada August 1995: http://www.ipc.on.ca/web_site.eng/matters/sum_pap/summary.htm; "Technology and Privacy : The New Landscape", Philip E. Agre. et al. MIT Press. 1997; and
Microsoft SQL Server Books on Line, available for download from http://support.microsoft.com/download/support mslfiles/sqlbol.exe.
The disclosures of all references mentioned above and throughout the present specification are hereby incorporated herein by reference.
SUMMARY OF THE INVENTION The present invention seeks to provide an improved message sending system. In a preferred embodiment of the present invention a message provider provides a message and a profile of intended recipients. The message and the profile are processed separately, in order to protect the anonymity of the intended recipients, who are determined based, at least in part, on the profile. Preferably, the objects of the preferred embodiment are realized with a careful division of responsibilities between system components and appropriate use of encryption. In another preferred embodiment of the present invention, useful both alone and in combination with the previously mentioned preferred embodiment, a method is provided for anonymous extraction of information from a database, in which the question and the answer are separated, preferably so that no entity knows both the question and the answer. There is thus provided in accordance with a preferred embodiment of the present invention a system for providing a message from a message provider to a message recipient, the message recipient having an identity not known to the message provider, the system including a request encryptor operative to receive a message to be sent to the at least one message recipient, and to encrypt at least the message in accordance with an encryption key, an anonymous profile handler operative to receive a profile defining characteristics of at least one message recipient and to determine based, at least in part, on the profile, a recipient list including one or more recipients for the message, a recipient handler operative to receive the recipient list and a decryption key associated with the encryption key and to separately encrypt the decryption key in accordance with a recipient key of each recipient, and an integrator operative to receive from the request encryptor the message encrypted in accordance with the encryption key and, from the recipient handler, the encrypted decryption key, separately encrypted in accordance with the recipient key of each recipient, and to send to each one recipient the encrypted message and the decryption key encrypted according to the recipient key of the one recipient.
Further in accordance with a preferred embodiment of the present invention the encryption key and the decryption key are identical.
Still further in accordance with a preferred embodiment of the present invention the integrator is also operative, before sending the encrypted message and the decryption key encrypted according to the recipient key, to further encrypt the encrypted message and the decryption key encrypted according to the recipient key, according to a second recipient key.
Additionally in accordance with a preferred embodiment of the present invention the recipient key and the second recipient key are identical. Moreover in accordance with a preferred embodiment of the present invention the anonymous profile handler is operative to determine the recipient list by formulating at least one database query and utilizing a response to the at least one database query to determine the recipient list.
Further in accordance with a preferred embodiment of the present invention the anonymous profile handler includes a query manager operative to decompose the database query into a plurality of database sub queries, and a plurality of query handlers, each query handler receiving a database sub query from the query manager and being operative to determine at least a portion of the recipient list by formulating at least one database sub query and utilizing a sub response to the at least one database sub query to determine the at least a portion of the recipient list, wherein the query manager is also operative to provide, to each query handler, a destination and each query handler is operative to transmit the portion of the recipient list determined by the query handler to the destination provided to the query handler.
Still further in accordance with a preferred embodiment of the present invention at least one of the query handlers includes a plurality of query handling sub-components, the plurality of query handling sub-components being operative, when operating together, to determine the at least a portion of the recipient list.
Additionally in accordance with a preferred embodiment of the present invention the formulating at least one database query includes formulating the at least one database query using secure methods to control use of the at least one database query.
Moreover in accordance with a preferred embodiment of the present invention the system also includes an answer manager, wherein the query handler is operative to determine information about the recipient list, not including information about an address of each recipient, and the answer manager receives the information about the recipient list and is operative to determine the information about the address of each recipient based, at least in part, on the information about the recipient list.
Further in accordance with a preferred embodiment of the present invention the information about the address of each recipient includes the address of each recipient.
Still further in accordance with a preferred embodiment of the present invention the system also includes a comparator operative to compare the addresses of each recipient and to remove duplicates from the addresses. Additionally in accordance with a preferred embodiment of the present invention the information about the address of each recipient does not include the address of each recipient, and the system also includes an address translator operative to receive the information and to determine therefrom the address. Moreover in accordance with a preferred embodiment of the present invention the address translator is located remotely to the query handler. Further in accordance with a preferred embodiment of the present invention the query handler and the answer manager are distributed on separate systems.
There is also provided in accordance with another preferred embodiment of the present invention a method for providing a message from a message provider to a message recipient, the message recipient having an identity not known to the message provider, the method including receiving a message to be sent to the at least one message recipient, and encrypting at least the message in accordance with an encryption key, receiving a profile defining characteristics of at least one message recipient and determining based, at least in part, on the profile, a recipient list including one or more recipients for the message, receiving the recipient list and a decryption key associated with the encryption key and separately encrypting the decryption key in accordance with a recipient key of each recipient, and' receiving the message encrypted in accordance with the encryption key and the encrypted decryption key. separately encrypted in accordance with the recipient key of each recipient, and sending to each one recipient the encrypted message and the decryption key encrypted according to the recipient key of the one recipient.
Further in accordance with a preferred embodiment of the present invention the encryption key and the decryption key are identical. Still further in accordance with a preferred embodiment of the present invention the receiving the message encrypted step also includes, before sending the encrypted message and the decryption key encrypted according to the recipient key, further encrypting the encrypted message and the decryption key encrypted according to the recipient key. according to a second recipient key. Additionally in accordance with a preferred embodiment of the present invention the recipient key and the second recipient key are identical.
BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which: Fig. 1 is a simplified block diagram illustration of a message providing system constructed and operative in accordance with a preferred embodiment of the present invention:
Fig. 2 is a simplified flowchart illustration of a preferred method of operation of the system of Fig. 1 ;
Fig. 3 is a simplified block diagram illustration of a preferred embodiment of a portion of the apparatus of Fig. 1 ;
Fig. 4 is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 3; Fig 5 is a simplified block diagram illustration of an alternative preferred embodiment of a portion of the apparatus of Fig. 1: and
Fig. 6 is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 5
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
Reference is now made to Fig. 1 which is a simplified block diagram illustration of a message providing system constructed and operative in accordance with a preferred embodiment of the present invention. The message providing system of Fig. 1. designated generally 100, is designed to allow a message provider 130 to send a message to one or more recipients while the identity of the recipients remains shielded from the message provider 130. It is appreciated that the message provider 130 may alternatively be considered as external to the system 100, so that the remainder of the elements of Fig. 1 comprise a subcombination which may, without the message provider 130. comprise a preferred embodiment of the present invention.
The message providing system 100 comprises a provider domain 1 10 and a system domain 120. Preferably, the provider domain 1 10 comprises elements of the message providing system 100. described below, which are associated with the operation of a sender, also termed provider, of a message. Preferably, the system domain 120 comprises elements of the message providing system 100. described below, which are associated with the processing and carrying out of requests received from the provider domain 1 10.
Assignment of particular elements to the provider domain 1 10 or to the system domain 120. as described below, is believed to be a preferred assignment in order to maintain security and to achieve the objects of the system of Fig. 1 in an optimum way: it is appreciated, however, that it would alternatively be possible to assign elements to the provider domain 1 10 or to the system domain 120 in a different way. or to assign all elements of the system of Fig. 1 to a single domain.
The provider domain 1 10 preferably comprises a message provider 130, referred to above. The message provider 130 is typically implemented in an appropriate combination of hardware and software and may operate in accordance with the instructions of an operator (not shown) external to the message provider 130. such as a human operator or an automated operator. The message provider 130 is preferably operatively associated with a request encryptor 140 and with an anonymous profile handler 150.
The request encryptor 140 is preferably implemented in a suitable combination of software and hardware and is preferably operative to encrypt its input and to output the encrypted input 146 and, preferably separately, a decryption key 143 with which the encrypted input 146 can be decrypted. It is appreciated that many appropriate encryption schemes are well known in the art. and that any appropriate scheme may be used. In the case of a symmetric encryption scheme, as is well known in the art. the decryption key 143 may or may not be identical to an encryption key (not shown) according to which the encrypted input 146 is encrypted. In the case of an asymmetric encryption scheme, as is well know in the art, the decryption key 143 will generally be different from the encryption key (not shown). It is appreciated that, in a preferred embodiment, the present invention is meant to include all appropriate possibilities of the relationship between the decryption key 143 and the encryption key.
The request encryptor 140 is preferably comprised in the provider domain 1 10. The request encryptor 140 may use any appropriate key-based encryption method known in the art such as. for example, a public key encryption method, a symmetric encryption method, or any other appropriate encryption method. It is appreciated that, in practice, tradeoffs such as security versus ease of computation may play a part in determining which encryption method is used by the request encryptor 140. A preferred mode of operation of the request encryptor 140 is described in more detail below.
Preferably, the decryption key 143 corresponding to each encrypted input 146 is different from every other decryption key 143 corresponding to another encrypted input 146.
The anonymous profile handler 150 is preferably comprised in the system domain 120. The anonymous profile handler 150 is preferably implemented in a suitable combination of hardware and software and is preferably operative to produce a list of message recipients from a profile describing preferred qualities of message recipients. A preferred mode of operation of the anonymous profile handler 150 is described in more detail below. The message providing system 100 also preferably comprises a recipient handler 160. which is preferably comprised in the system domain 120 and is preferably implemented in an appropriate combination of hardware and software. The recipient handler 160 is preferably operatively associated with the request encryptor 140 and with the anonymous profile handler 150. The recipient handler 160 is preferably operative to receive a first key. also referred to herein as a decryption key. and a list comprising a plurality of recipients, each recipient having an associated recipient key. and to separately encrypt the first key a plurality of times, once for each recipient key. A preferred mode of operation of the recipient handler 160 is described in more detail below. The message providing system 100 also preferably comprises an integrator 170. which is preferably comprised in the system domain 120 and is preferably implemented in an appropriate combination of hardware and software. The integrator 170 is preferably operatively associated with the request encryptor 140 and the recipient handler 160. The integrator 170 preferably receives a message encrypted with an encryption key and a plurality of encrypted forms of a decryption key associated with the encryption key as described above, each decryption key being encrypted with a different recipient key associated with one recipient of a plurality of recipients.
The integrator 170 also preferably receives a plurality of addresses, each associated with one recipient of the plurality of recipients. The integrator 170 is preferably operative to send a message to each of the plurality of recipients, shown for simplicity of description as a message recipient 180. Each message preferably comprises the message encrypted with the encryption key and the encrypted form of the associated decryption key encrypted with the encryption key of the message recipient 180. comprising a compound message. The compound message is preferably further encrypted using an encryption key of the message recipient 180. either the same key as referred to above or another encryption key of the message recipient 180. It is believed that the further encryption of the compound message has the effect of increasing the security of the system of Fig. 1.
The operation of the system of Fig. 1 is now briefly described. The message provider 130 preferably send a message 190 to the request encryptor 140. The message provider 130 also preferably sends a profile 200 to the anonymous profile handler 150. the profile 200 preferably comprising an appropriate list of characteristics which may be used to identify one or more intended recipients of the message 190. For example, the profile 200 may specify "residents of neighborhood X of city Y who subscribe to cable television", with X and Y being used in the example to represent real names which would be used in a real profile 200 instead of X and Y.
The profile 200 may be expressed in any appropriate form such as, for example: in a natural language form, in which case the anonymous profile handler 150 preferably comprises a natural language interpretation module (not shown), as is well known in the art: in an internal form, preferably an internal form readable by the anonymous profile handler 150; or otherwise.
The request encryptor 140 preferably receives the message 190. preferably determines an encryption key (not shown), the encryption key being associated with the decryption key 143 as described above, for use in processing the message 190. encrypts the message 190 in accordance with the encryption key. and sends the encrypted message 146 to the integrator 170. The request encryptor 140 also preferably sends the decryption key 143. which can be used to decrypt the message 190. to the recipient handler 160.
The anonymous profile handler 150 preferably receives the profile 200 and determines therefrom a list of recipients 210. the list of recipients 210 preferably comprising a plurality of recipient entries 220. Each of the plurality of recipient entries 220 preferably comprises information for one recipient, said information for one recipient comprising a recipient key and an address for sending messages to the one recipient. The recipient key may, for example, comprise a public key known to be associated with the one recipient, or may comprise some other key known to the one recipient. A preferred implementation of the anonymous profile handler 150 is described in more detail below with reference to Fig. 3.
The anonymous profile handler 150 preferably supplies the plurality of recipient entries 220 to the recipient handler 160. The recipient handler 160 preferably performs the following tasks for each recipient in each of the plurality of recipient entries 220: The key of the recipient, as described above, is used to encrypt the decryption key 143, and a key entry 230 is created comprising the decryption key 143 encrypted with the key of the recipient and the address of the recipient. The plurality of key entries 230 thus produced is passed on to the integrator 170.
The integrator 170 preferably creates, for each message recipient 180, an output message comprising: the message 190 encrypted with the encryption key; and the decryption key 143 encrypted with the key of the recipient, as received in the key entry 230 for the recipient. The output message, preferably encrypted with a recipient key as described above, is then sent to each message recipient 180.
Reference is now made to Fig. 2. which is a simplified flowchart illustration of a preferred method of operation of the system of Fig. 1. The method of Fig. 2 preferably comprises the following steps:
A message is received, the message intended to be sent to at least one message recipient (step 250). The message is encrypted in accordance with an encryption key (step 260). A profile is received, the profile defining characteristics, but typically not the actual identity, of at least one message recipient (step 270). A recipient list is determined, based, at least in part, on the profile (step 280).
The recipient list and the decryption key are received, typically by a system component different than the components which carried out the previous steps (step 290). The decryption key is separately encrypted, typically being encrypted once in accordance with a recipient key of each recipient in the recipient list (step 300).
The message encrypted in accordance with the encryption key and the encrypted decryption key, separately encrypted in accordance with the recipient key of each recipient, are received, typically by another system component (step 310). Each one recipient is then sent the encrypted message, along with the decryption key encrypted according to a recipient key of the one recipient (step 320). Preferably, the encrypted message and the encrypted decryption key are further encrypted according to a recipient key. which may be the same as or different from the recipient key used to encrypt the decryption key.
Reference is now made to Fig. 3, which is a simplified block diagram illustration of a preferred implementation of a portion of the apparatus of Fig. 1. The apparatus of Fig. 3 comprises a preferred implementation of the anonymous profile handler 150 of Fig. 1 : it is appreciated that other preferred implementations are also possible. The apparatus of Fig. 3 is preferably implemented in software running on appropriate hardware; alternatively, portions or all of the apparatus of Fig. 3 may be implemented in special purpose hardware, for performance, for security, or for other considerations. As described above with reference to Fig. 1, the anonymous profile handler 150 preferably receives the profile 200 and determines therefrom a list of recipients 2 10. The profile 200 may be considered a question or query directed at a database, while the list of recipients 210 may be considered an answer to the question. Preferably, the anonymous profile handler, in structure and in function, is designed to insulate information about the question from information about the answer, such that preferably there is no component of the anonymous profile handler 150 which knows both the question and the answer. If the system of Fig. 1 is considered as an "application", as the term is commonly used in the art, than the application is to be prevented from such knowledge, while such knowledge is only to be available in full at the level of an underlying "systeirT. as the term is commonly used in the art. which system may be chosen for fulfilling appropriate security constraints.
The apparatus of Fig. 3 preferably includes a question handler 330 and an answer handler 340. The question handler 330 is preferably operative to receive the profile 200 and to pass the profile 200 on, as described in more detail below, for further processing. The answer handler 340 is preferably designed to receive an answer, as described in more detail below, and to output the answer in the form of the list of recipients 210.
It is appreciated that many different specific implementations are possible, based on technologies known in the art. for implementing the question handler 330 and the answer handler 340. For example, and without limiting the generality of the foregoing, the following is a discussion of salient aspects of two such implementations.
In a first implementation termed herein a QA-Wall implementation the separation of the Query-Response is achieved across space; that is, across the virtual space of a database schema. Considering a database schema as a map. the QA-Wall method divides the world of the schema between owners.
Consider the data, for simplicity of description and without limiting the generality of the present invention being assumed to exist in a single database that supports permissions. The data is preferably organized in tables, which are organized - conceptually - using links. For example, if a telephone call at a switch originates in an extension, then the Call table will have a link - a foreign key. to the Extension table. The field at the Call table may be called something like "OriginExtension". and it will preferably contain values that will preferably correspond to the key in the Extension table, probably called ID. Note that the columns in each table may also be considered to be bound to each other by a link - the fact that they belong to the same table. Thus "Avi" is bound to "Nahir" in the record "Avi Nahir" because the columns holding the two parts of the name "Avi Nahir" are in the same table.
Therefore, one may partition a database between owners any way one wishes, putting tables across partitions and even splitting tables, so that one part of a table belongs to this partition and another part to another. However, for each implicit relation, one connecting columns of a table, which is broken, it is typically necessary to add linkage information for the spawned table. And, for every relation that spans a partition boundary, it is necessary to add a work table to each partition such that one owner can write linkage information to it. and the other owner can read linkage information from it.
It is appreciated in the above discussion that being an owner of a partition means that one has permissions to that partition, and only to that partition, not to partitions owned by others. In another implementation termed herein an encrypted stored procedure implementation, a type of temporal separation is preferably employed: someone creates a procedure and then another person executes it.
It is appreciated that, in a preferred embodiment of the present message, a stored procedure must be stored in a manner that the source of the stored procedure can not be retrieved. In Microsoft SQL, for example, it is possible to encrypt stored procedures in order to obtain the feature of non-retrieval of the source. In other words, it is important in the encrypted stored procedure implementation to prevent the entity executing the stored procedure, and having access to the results, from knowing what question has been asked. In a preferred implementation, a stored procedure is created from an
SQL source string, and then the stored procedure is executed blindly. It is appreciated that it would be preferably to guarantee that the stored procedure will not carry out undesirable actions, such as actions of a "trojan horse" as is well known in the art. Thus, preferably, we parse and check the string of SQL to be executed prior to compilation and encrypted storage. It is appreciated that, in the case of an Microsoft SQL implementation, it may be desirable to operate by activating an ESP, also known as an Extended Stored Procedure, which is a user programmable extension to the SQL Server. The ESP will use preferably use an Open Data Services interface to log back into SQL server as the administrator, where it can do anything it wishes in terms of permissions.
It is appreciated that, generally, any SQL Query-Response can be modified to run using the ESP. Specifically, the SQL queries discussed above with reference the QA-Wall implementation can, and sometimes should, be run using this technique. It is thus appreciated that appropriate QA-Wall and encrypted stored procedure features, as described above, may be combined in a single embodiment as appropriate.
Preferably, as shown in Fig. 3, the question handler 330 and the answer handler 340 are insulated from each other, except for a carefully defined interface, so that only permitted data may pass between them. Techniques for insulating one system component from another, including isolation in separate processes under operating system control, are well known in the art.
The apparatus of Fig. 3 also preferably comprises a question source 350. which may comprise an appropriate table in an appropriate database management system. The question source 350 preferably comprises, for each entry therein, a question field 360 and a link field 370. Preferably, the link field is designed to be uncorrelated either with the question field or with any information related to the question field. For example, and without limiting the generality of the foregoing, some questions and links might be: Questions Links
New York 458903214
New York 689593402
Chicago 956587788
Thus, if a question equivalent to "find e-mail addresses for those with "New York"" were presented, the question handler 330 would look up the question or query 410 "CITY = "NEW YORK"", and would obtain as an answer the following links 420:
458903214
689593402 The question handler 330 is then operative to pass the links 420 to the answer handler 340; passing the links for resolution is preferably the only communication permitted between the question handler 330 and the answer handler
340.
The apparatus of Fig. 3 also preferably comprises an answer source 380. which may comprise an appropriate table in an appropriate database management system. The answer source 380 preferably comprises, for each entry therein, an answer link field 390 and an answer field 400. Preferably, the link field comprises link information corresponding the question link field 370. For example. and without limiting the generality of the foregoing, some answers and links might be:
Links Answers
458903214 xxx@qqq.com
956587788 zzz@bcd.com
689593402 yyy@yyy.com The answers, representing e-mail address, are given by way of example only and are not intended to represent any actual e-mail address.
The answer handler is preferably operative to look up the links 420 in the answer source 380. and to extract the answer 430 therefrom. In the case of the above example, for links 458903214 and 689593402. the answer 430 would comprise: xxx@qqq.com: and yyy@yyy.com.
Reference is now made to Fig. 4, which is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 3. The method of Fig. 4 is self-explanatory with reference to the above discussion.
It is appreciated that it would be desirable for the question 410 to be allowed to take a more complex form, as is well known in the field of database management systems, thus allowing questions like: "'find e-mail addresses for those with city "New York"* AND (age between 10 and 14 OR age between 17 and 19)". It is appreciated that a more complex system made up of units similar to the apparatus of Fig. 3 could be constructed, but it is believed that it would be difficult to construct a system which would be able to resolve complex queries while maintaining the appropriate security restrictions and still keeping the form of the apparatus of Fig. 3. In particular, it is believed that complex queries including field relationships, such as "find e-mail addresses for those whose weight is equal to three times their age", would be difficult or impossible to resolve as described above, particularly in a case where relevant fields were found in different partitions. Reference is now made to Fig 5, which is a simplified block diagram illustration of an alternative preferred embodiment of a portion of the apparatus of Fig. 1. The apparatus of Fig. 5 comprises an alternative preferred implementation of the anonymous profile handler 150 of Fig. 1 ; it is appreciated that other preferred implementations are also possible. The elements of the apparatus of Fig. 5 are preferably implemented in an appropriate combination of software and hardware, as is well known in the art; alternatively, the apparatus of Fig. 5 may be partly or wholly implemented in special purpose hardware, as is well known in the art. The software components of the apparatus of Fig. 5 are preferably implemented in an appropriate database management system, such as. for example. Microsoft SQL 7.0. commercially available from Microsoft Corporation. Alternatively, the software components of the apparatus of Fig. 5 may be implemented in any other appropriate database management system, or otherwise as appropriate.
The apparatus of Fig. 5 preferably comprises a stored procedure definer 450. which is preferably operative to receive the profile 200 (Fig. 1) and to produce therefrom an appropriate procedure 460. The procedure 460 is preferably operative, when executed, to produce an appropriate answer based on the profile 200. typically using a database management system as described above. The stored procedure definer 450 is preferably designed, typically using security features of the database management system such as Microsoft SQL 7.0. to be capable of producing the procedure 460 but not of executing the procedure 460. By way of example only. the inability of the stored procedure definer 450 to execute the procedure 460 may be based on the stored procedure definer 450 lacking privileges necessary to access database tables in which information necessary to execute the procedure 460 is stored. It is appreciated that, as described above with reference to Fig. 3, it is preferable to check the procedure 460 for possible undesirable behavior before the procedure 460 is compiled for use. as is well known in the art. It is also appreciated that it is preferable for the stored procedure 460 to be stored in such a way that the stored procedure executor 480, described below, is not able to read or otherwise determine the contents of the procedure 460, but only to execute the procedure 460. Methods, including permission based methods, for achieving such a result are well known in the art.
The stored procedure definer 450 is preferably operative to store the procedure 460 in a procedure store 470. which may comprise any appropriate procedure store, such as a store defined within the database management system or another appropriate store.
The apparatus of Fig. 5 also preferably comprises a changer 475, which is preferably operative to change one or more of procedure permissions, ownership control information, or other information associated with the procedure 460 stored in the procedure store 475. Preferable, the change carried out by the changer 475 should allow a stored procedure executor 480. also comprised in the apparatus of Fig. 5, to execute the stored procedure 460, upon retrieval of the stored procedure 460 from the procedure store 470. Preferably, permissions are set and access granted such that the stored procedure executor 480 may only execute the stored procedure 460. and may not in any other way access underlying data, such as database tables, which are accessed by the stored procedure 460.
The output of the execution of the procedure 460 by the stored procedure executor 480 typically comprises the list of recipients 210 (Fig. 1).
It is appreciated that appropriate commercially available database management systems known in the art such as. for example, Microsoft SQL 7.0, include facilities such as procedure permissions, ownership control, and other similar facilities which could be used by a skilled person of the art in implementing the apparatus of Fig. 5. For example, and without limiting the generality of the foregoing. Microsoft SQL 7.0 includes appropriate facilities which are documented, inter alia, in a section entitled "SP Deferred Name Resolution and Compilation" in the Microsoft SQL 7.0 server documentation, referred to above.
Reference is now made to Fig. 6. which is a simplified flowchart illustration of a preferred method of operation of the apparatus of Fig. 5. The method of Fig. 6 is self-explanatory with reference to the above description.
It is appreciated that, in a preferred embodiment of the present invention, all communications between various elements are preferably secure and authenticated, preferably using methods well known in the art, to prevent an attack on the integrity of the system by eavesdroppers, impersonators, and so forth.
It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are. for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.
It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined only by the claims which follow:

Claims

What is claimed is:CLAIMS
1. A system for providing a message from a message provider to a message recipient, the message recipient having an identity not known to the message provider, the system comprising: a request encryptor operative to receive a message to be sent to said at least one message recipient, and to encrypt at least the message in accordance with an encryption key; an anonymous profile handler operative to receive a profile defining characteristics of at least one message recipient and to determine based, at least in part, on the profile, a recipient list comprising one or more recipients for the message; a recipient handler operative to receive the recipient list and a decryption key associated with the encryption key and to separately encrypt the decryption key in accordance with a recipient key of each recipient; and an integrator operative to receive from the request encryptor the message encrypted in accordance with the encryption key and, from the recipient handler, the encrypted decryption key, separately encrypted in accordance with the recipient key of each recipient, and to send to each one recipient the encrypted message and the decryption key encrypted according to the recipient key of the one recipient.
2. A system according to claim 1 and wherein the encryption key and the decryption key are identical.
3. A system according to claim 1 or claim 2 and wherein the integrator is also operative, before sending the encrypted message and the decryption key encrypted according to the recipient key, to further encrypt the encrypted message and the decryption key encrypted according to the recipient key, according to a second recipient key.
4. A system according to any of the above claims and wherein the
-. recipient key and the second recipient key are identical.
5. A system according to any of the above claims and wherein the anonymous profile handler is operative to determine the recipient list by formulating at least one database query and utilizing a response to said at least one database 0 query to determine the recipient list.
6. A system according to claim 5 and wherein said anonymous profile handler comprises: a query manager operative to decompose the database query into a 5 plurality of database sub queries; and a plurality of query handlers, each query handler receiving a database sub query from the query manager and being operative to determine at least a portion of the recipient list by formulating at least one database sub query and utilizing a sub response to said at least one database sub query to determine said at 0 least a portion of the recipient list, wherein the query manager is also operative to provide, to each query handler, a destination and each query handler is operative to transmit the portion of the recipient list determined by said query handler to the destination provided to said query handler. 5
7. A system according to claim 6 and wherein at least one of said query handlers comprises a plurality of query handling sub-components, the plurality of query handling sub-components being operative, when operating together, to determine said at least a portion of the recipient list.
8. A system according to claim 5 and wherein said formulating at least one database query comprises formulating said at least one database query using secure methods to control use of said at least one database query.
9. A system according to any of claims 6 - 8 and also comprising an answer manager. wherein the query handler is operative to determine information about the recipient list, not including information about an address of each recipient, and the answer manager receives the information about the recipient list and is operative to determine the information about the address of each recipient based, at least in part, on the information about the recipient list.
10. A system according to claim 9 and wherein the information about the address of each recipient comprises the address of each recipient.
1 1. A system according to claim 9 also comprising a comparator operative to compare the addresses of each recipient and to remove duplicates from the addresses.
12. A system according to claim 9 and wherein the information about the address of each recipient does not comprise the address of each recipient, and the system also comprises an address translator operative to receive the information and to determine therefrom the address.
13. A system according to claim 12 and wherein the address translator is located remotely to the query handler.
14. A system according to claim 9 and wherein the query handler and the answer manager are distributed on separate systems.
15. A method for providing a message from a message provider to a message recipient, the message recipient having an identity not known to the message provider, the method comprising: receiving a message to be sent to said at least one message recipient, and encrypting at least the message in accordance with an encryption key; receiving a profile defining characteristics of at least one message recipient and determining based, at least in part, on the profile, a recipient list comprising one or more recipients for the message; receiving the recipient list and a decryption key associated with the encryption key and separately encrypting the decryption key in accordance with a recipient key of each recipient; and receiving the message encrypted in accordance with the encryption key and the encrypted decryption key, separately encrypted in accordance with the recipient key of each recipient, and sending to each one recipient the encrypted message and the decryption key encrypted according to the recipient key of the one recipient.
16. A method according to claim 15 and wherein the encryption key and the decryption key are identical.
17. A method according to claim 15 or claim 16 and the receiving the message encrypted step also comprises, before sending the encrypted message and the decryption key encrypted according to the recipient key, further encrypting the encrypted message and the decryption key encrypted according to the recipient key, according to a second recipient key.
~n
PCT/IL2000/000526 1999-09-30 2000-09-04 System for providing messages WO2001024434A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU68621/00A AU6862100A (en) 1999-09-30 2000-09-04 System for providing messages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IL13214799A IL132147A0 (en) 1999-09-30 1999-09-30 System for providing messages
IL132147 1999-09-30

Publications (1)

Publication Number Publication Date
WO2001024434A1 true WO2001024434A1 (en) 2001-04-05

Family

ID=11073289

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2000/000526 WO2001024434A1 (en) 1999-09-30 2000-09-04 System for providing messages

Country Status (3)

Country Link
AU (1) AU6862100A (en)
IL (1) IL132147A0 (en)
WO (1) WO2001024434A1 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002102009A2 (en) * 2001-06-12 2002-12-19 Research In Motion Limited Method for processing encoded messages for exchange with a mobile data communication device
US7546453B2 (en) 2001-06-12 2009-06-09 Research In Motion Limited Certificate management and transfer system and method
US7840207B2 (en) 2005-11-30 2010-11-23 Research In Motion Limited Display of secure messages on a mobile communication device
US7949355B2 (en) 2007-09-04 2011-05-24 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device
US7953971B2 (en) 2005-10-27 2011-05-31 Research In Motion Limited Synchronizing certificates between a device and server
US8191105B2 (en) 2005-11-18 2012-05-29 Research In Motion Limited System and method for handling electronic messages
US8355701B2 (en) 2005-11-30 2013-01-15 Research In Motion Limited Display of secure messages on a mobile communication device
US8473561B2 (en) 2006-06-23 2013-06-25 Research In Motion Limited System and method for handling electronic mail mismatches
US8661267B2 (en) 2001-08-06 2014-02-25 Blackberry Limited System and method for processing encoded messages
US8898473B2 (en) 2001-06-12 2014-11-25 Blackberry Limited System and method for compressing secure E-mail for exchange with a mobile data communication device
US9094429B2 (en) 2004-08-10 2015-07-28 Blackberry Limited Server verification of secure electronic messages
US9628269B2 (en) 2001-07-10 2017-04-18 Blackberry Limited System and method for secure message key caching in a mobile communication device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5751813A (en) * 1996-04-29 1998-05-12 Motorola, Inc. Use of an encryption server for encrypting messages
US5768391A (en) * 1995-12-22 1998-06-16 Mci Corporation System and method for ensuring user privacy in network communications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768391A (en) * 1995-12-22 1998-06-16 Mci Corporation System and method for ensuring user privacy in network communications
US5751813A (en) * 1996-04-29 1998-05-12 Motorola, Inc. Use of an encryption server for encrypting messages

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002102009A2 (en) * 2001-06-12 2002-12-19 Research In Motion Limited Method for processing encoded messages for exchange with a mobile data communication device
WO2002102009A3 (en) * 2001-06-12 2003-04-10 Research In Motion Ltd Method for processing encoded messages for exchange with a mobile data communication device
US7546453B2 (en) 2001-06-12 2009-06-09 Research In Motion Limited Certificate management and transfer system and method
US7653815B2 (en) 2001-06-12 2010-01-26 Research In Motion Limited System and method for processing encoded messages for exchange with a mobile data communication device
US9172540B2 (en) 2001-06-12 2015-10-27 Blackberry Limited System and method for processing encoded messages for exchange with a mobile data communication device
USRE45087E1 (en) 2001-06-12 2014-08-19 Blackberry Limited Certificate management and transfer system and method
US8898473B2 (en) 2001-06-12 2014-11-25 Blackberry Limited System and method for compressing secure E-mail for exchange with a mobile data communication device
US8539226B2 (en) 2001-06-12 2013-09-17 Blackberry Limited Certificate management and transfer system and method
US9628269B2 (en) 2001-07-10 2017-04-18 Blackberry Limited System and method for secure message key caching in a mobile communication device
US8661267B2 (en) 2001-08-06 2014-02-25 Blackberry Limited System and method for processing encoded messages
US9398023B2 (en) 2004-08-10 2016-07-19 Blackberry Limited Server verification of secure electronic messages
US9094429B2 (en) 2004-08-10 2015-07-28 Blackberry Limited Server verification of secure electronic messages
US8645684B2 (en) 2005-10-27 2014-02-04 Blackberry Limited Synchronizing certificates between a device and server
US8099595B2 (en) 2005-10-27 2012-01-17 Research In Motion Limited Synchronizing certificates between a device and server
US7953971B2 (en) 2005-10-27 2011-05-31 Research In Motion Limited Synchronizing certificates between a device and server
US8191105B2 (en) 2005-11-18 2012-05-29 Research In Motion Limited System and method for handling electronic messages
US7840207B2 (en) 2005-11-30 2010-11-23 Research In Motion Limited Display of secure messages on a mobile communication device
US8611936B2 (en) 2005-11-30 2013-12-17 Blackberry Limited Display of secure messages on a mobile communication device
US8355701B2 (en) 2005-11-30 2013-01-15 Research In Motion Limited Display of secure messages on a mobile communication device
US8473561B2 (en) 2006-06-23 2013-06-25 Research In Motion Limited System and method for handling electronic mail mismatches
US8943156B2 (en) 2006-06-23 2015-01-27 Blackberry Limited System and method for handling electronic mail mismatches
US7949355B2 (en) 2007-09-04 2011-05-24 Research In Motion Limited System and method for processing attachments to messages sent to a mobile device

Also Published As

Publication number Publication date
IL132147A0 (en) 2001-03-19
AU6862100A (en) 2001-04-30

Similar Documents

Publication Publication Date Title
Stanek et al. A secure data deduplication scheme for cloud storage
US6662299B1 (en) Method and apparatus for reconstituting an encryption key based on multiple user responses
JP5024999B2 (en) Cryptographic management device, cryptographic management method, cryptographic management program
Li et al. Efficient keyword search over encrypted data with fine-grained access control in hybrid cloud
CN105593871B (en) Attribute information providing method and attribute information provide system
US20080183703A1 (en) Uniform search system and method for selectively sharing distributed access-controlled documents
Hwang et al. Achieving dynamic data guarantee and data confidentiality of public auditing in cloud storage service
JP2016502153A (en) Privacy protection database system
WO2001024434A1 (en) System for providing messages
JP4006214B2 (en) Data search system, data relay server, database server, and database access method
JP6542883B2 (en) Database system, database processing method
Backes et al. Anonymous ram
Gritzalis Embedding privacy in IT applications development
Tawalbeh et al. Efficient and secure software-defined mobile cloud computing infrastructure
Li et al. A novel framework for outsourcing and sharing searchable encrypted data on hybrid cloud
CN109379345A (en) Sensitive information transmission method and system
Arora et al. Enhanced privacy preserving access control in the cloud
JP2002328904A (en) System for managing application service providers
Löken Searchable encryption with access control
Rosinosky et al. PProx: efficient privacy for recommendation-as-a-service
Xie et al. Protecting privacy in key-value search systems
Abur et al. Privacy protection and collusion avoidance solution for cloud computing users
Sánchez‐Artigas et al. StackSync: Attribute‐based data sharing in file synchronization services
Freisleben et al. Capabilities and Encryption: The Ultimate Defense Against Security Attacks?
Davies et al. Client-oblivious OPRAM

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP