WO2018208787A1 - Gestion d'accès à hautes performances et protection de données pour des applications de messagerie distribuée - Google Patents

Gestion d'accès à hautes performances et protection de données pour des applications de messagerie distribuée Download PDF

Info

Publication number
WO2018208787A1
WO2018208787A1 PCT/US2018/031615 US2018031615W WO2018208787A1 WO 2018208787 A1 WO2018208787 A1 WO 2018208787A1 US 2018031615 W US2018031615 W US 2018031615W WO 2018208787 A1 WO2018208787 A1 WO 2018208787A1
Authority
WO
WIPO (PCT)
Prior art keywords
encryption key
message
public
channel
publish
Prior art date
Application number
PCT/US2018/031615
Other languages
English (en)
Inventor
Mikhail EGOROV
Maclane Scott Wilkison
David NUǸEZ
Isaac AGUDO
Original Assignee
ZeroDB, Inc.
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 ZeroDB, Inc. filed Critical ZeroDB, Inc.
Publication of WO2018208787A1 publication Critical patent/WO2018208787A1/fr

Links

Classifications

    • 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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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
    • H04L63/0464—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 using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Definitions

  • the present disclosure relates generally to distributed computing and, more specifically, to high-performance access management and data protection for distributed messaging applications.
  • Some computer applications process data through an approach referred to as stream processing.
  • data flows through a collection of nodes (e.g., computers, virtual machines, containers, network hosts, processes, or other computational entities) in the form of messages, in some cases, asynchronously.
  • nodes e.g., computers, virtual machines, containers, network hosts, processes, or other computational entities
  • these messages may be routed according to a publisher-subscriber graph among those nodes.
  • the messages may contain data that is processed at the different nodes or instructions from one node to another node to invoke some functionality.
  • this type of approach is also referred to as dataflow programming, event stream processing, and reactive programming.
  • Some aspects include a process that enables delegated access to encrypted information for distributed messaging and queuing frameworks, or in general, to publish/subscribe architectures.
  • data is published by data producers and organized in channels or queues, which consumer applications can subscribe to, and that are managed by one or multiple broker entities.
  • Some aspects include a process, including: receiving, with a publish-subscribe application executed by one or more processors, from a first data producer, a first message and a first request to publish the first message to a first channel specified by the first request, wherein: at least part of the first message is encrypted by the first data producer, the first data producer is one of a plurality of data producers for which the publish-subscribe application publishes messages, the first channel is one of a plurality of channels on which the publish-subscribe application publishes messages on behalf of the plurality of data producers, at least part of the at least part of the first message is decryptable with a first private encryption key of a first public- private encryption key pair associated with the first channel, each of the plurality of channels is associated with at least one different respective public-private encryption key pair among a plurality of public-private encryption key pairs, private encryption keys of the public-private encryption key pairs are maintained in a first security domain, the plurality of data producers are external to the first security domain, and public encryption keys of the
  • Some aspects include a tangible, non-transitory, machine-readable medium storing instructions that when executed by a data processing apparatus cause the data processing apparatus to perform operations including the above-mentioned process.
  • Some aspects include a system, including: one or more processors; and memory storing instructions that when executed by the processors cause the processors to effectuate operations of the above-mentioned process.
  • Figure 1 illustrates an example logical architecture consistent with some embodiments
  • Figure 2 illustrates a process to publish messages consistent with some embodiments
  • Figure 3 illustrates a process to delegate access consistent with some embodiments
  • Figure 4 illustrates a process to transform encrypted messages consistent with some embodiments
  • Figure 5 illustrates a process to decrypt transformed encrypted messages consistent with some embodiments.
  • Figure 6 illustrates an example of a computing device by which the present techniques may be implemented.
  • Some embodiments include a computer system and method that affords delegated access to encrypted information for distributed messaging and queuing frameworks, or in general, to publish-subscribe architectures.
  • data may be published by data producers and organized in channels or queues, which consumer applications can subscribe to, and that are managed by one or multiple broker entities.
  • proxy re-encryption is a type of public-key cryptosystem that transforms data encrypted under an initial public key to into a ciphertext readable by a different private key from that of the initial public key, without being decrypted in this process by the delegator.
  • data is initially encrypted by producer applications under a public key specific to the channel in use (e.g., in cases where full- encryption mode is in place) or under a public key for each message field (e.g., in cases where granular-encryption mode is in place), and through the re-encryption process, the system transform the ciphertexts to encrypted messages that can be deciphered by authorized consumer applications.
  • the channel owner may previously authorize consumer applications, e.g., by creating special cryptographic keys, called re-encryption keys, that are handled to the brokers and that act as authorization tokens.
  • the data and messages in a channel are referred to as being owned by some "data owner" on a per-channel basis, rather than by the producer (which may be a mere data source).
  • keys are assigned to channel, and the channel owner may hold the associated private keys.
  • Some embodiments include a mechanism for distributing channel's public keys to producers. Since these keys are public, a variety of approaches to distribute the public keys may be used, depending on the deployment characteristics of the system (e.g., storing them at the administration/coordination module, publishing them in a public repository, broadcasting them to the producers, etc.)
  • Some embodiments implement a proxy re-encryption scheme.
  • Performing an act "with proxy re-encryption” can include generating a re-encryption key, using that key to transform a ciphertext, or both.
  • Certain existing public-key encryption schemes allow an entity holding a private key related to some public key to decrypt ciphertexts encrypted under said public key.
  • the encryption scheme proposed by ElGamal is one example of public-key encryption scheme (see ElGamal, T. (1984, August), A public key cryptosystem and a signature scheme based on discrete logarithms, in Workshop on the Theory and Application of Cryptographic Techniques (pp. 10-18), Springer Berlin Heidelberg.)
  • Other examples include those proposed by Blaze et al.
  • Patent Application 62/427,401 filed 29 November 2016, titled METHOD AND SYSTEM FOR SWITCHING PUBLIC KEYS IN CIPHERTEXTS, the contents of which are hereby incorporated by reference.
  • Examples also include those described in the following: Giuseppe Ateniese, Kevin Fu, Matthew Green, and Susan Hohenberger, Improved Proxy Re-Encryption Schemes with Applications to Secure Distributed Storage, in Cryptology ePrint Archive, at 2005/028; M. Blaze, G. Bleumer, and M. Strauss, Divertible protocols and atomic proxy cryptography, In Proceedings of Eurocrypt '98, volume 1403, pages 127-144, 1998; and D. Nu ⁇ nez, I. Agudo, and J.
  • the proxy re-encryption scheme prevents a delegate from accessing the content of a message or from accessing a private key corresponding to the public key with which the message was encrypted.
  • the proxy re-encryption schemes provide at least the following functionalities, embodied by these algorithms:
  • secParam the setup algorithm
  • PRE. Setup outputs an object that contains the public parameters of the scheme. In some cases, these parameters are publicly known.
  • PRE.KeyGen -> ⁇ pk#i, sk#i).
  • the key generation algorithm PRE.KeyGen outputs a pair of public and secret keys (pk#i, sk#i) for entity i.
  • secret key is also referred as “private key” in this description.
  • PRE.Enc(p / ' , m) -> ci On input the public key pk#i and a message m, the encryption algorithm PRE.Enc outputs a ciphertext c#i.
  • PRE.ReKeyGen (p / ' , sk#i, pk#j , sk#j) -> rk[i- j].
  • the re- encryption key generation algorithm PRE.ReKeyGen outputs a re-encryption key rk[i- j].
  • the re-encryption algorithm PRE.ReEnc outputs a second ciphertext c#j, which can be decrypted by entity j using sk#j.
  • the proxy re-encryption scheme is non-interactive, which means that the re-encryption key generation (i.e., the PRE.ReKeyGen function) does not use the secret key sk#j (the opposite implies the scheme is interactive).
  • the proxy-re-encyption scheme is interactive and is, therefore also based on the subscriber' s private key.
  • the PRE scheme has access to a secure source of randomness in the form of a cryptographically secure pseudorandom number generator (CSPRNG).
  • CSPRNG cryptographically secure pseudorandom number generator
  • the channel owner may be an entity external to the system (though some embodiments may include its features), outside its security domain in order to decouple if from the generation of channel encryption keys and re-encryption keys, and therefore, to eliminate or mitigate security risks associated to the protection of channel secret keys.
  • this protection is assumed to be responsibility of the channel owner, which usually may resort to various solutions on this respect (e.g., use of platforms with Hardware Security Modules (like secure enclaves) and/or key management software).
  • the channel owner may create a new pair of public and secret keys, namely PECKey and SECKey, using the PRE.KeyGen function as follows:
  • PECKey#i and SECKey#i are a proxy re-encryption public and secret key, respectively.
  • the SECKeys may be safely stored by the channel owner, while the PECKeys may be distributed to the producers.
  • Some embodiments include services configured to distribute a channel's public keys to producers, and since these keys are public, embodiments may implement a variety of different distribution techniques, depending on the deployment characteristics of the system (e.g., storing them at the administration/coordination module, publishing them in a public repository, broadcasting them to the producers, etc.)
  • CKeypairs are generated locally by the consumer application, and some embodiments may only send the public component (i.e. the PCKey) to the administration module after that, in order to be able to Since SCKeys are secret, special care may be taken to protect them properly and must be securely erased once they are not needed.
  • CKeypairs are generated using the PRE.KeyGen function as follows:
  • each CKeypair may belong to a whole consumer group, so consumers applications within the group share a single SCKey for decryption purposes.
  • Generation of the consumer keys is responsibility of the entity (e.g., an orchestration service) creating the group, usually the first consumer to join the group.
  • a channel owner may authorize consumers to read data and messages of an encrypted channel by generating the corresponding transformation keys.
  • owner of channel i may authorize consumer j to read from the channel. To do so, it uses the PRE.ReKeyGen algorithm using the secret key of the encrypted channel (SECKey#i) and the public key of the consumer (PCKey#j), as follows:
  • TK[i ⁇ j] PRE.ReKeyGen(SECKey#i, PCKey#j)
  • the channel owner may retrieve the PCKey of the consumer it wants to authorize. This can be achieved with a variety of approaches, e.g., either in a 'push' (i.e., the consumer attaches its PCKey when asking for authorization) or in a 'pull' fashion (i.e., the channel owner asks the consumer for its PCKey) together with the authorization request. It is also possible for the channel owner to retrieve the PCKey by other mechanisms, such as from a public key repository, so it is not necessary to interact with the consumer application.
  • Embodiments may include obtaining keys have been previously created, namely, channel encryption keys, consumer keys, and transformation keys.
  • a producer wants to write one or more messages into a channel / ' , in some embodiments, it connects to the broker that hosts this channel and establish a session with it, generates a random data encryption key (DEK) for the session (for example, a fresh AES-128 key), and produces an encrypted version of the DEK using the proxy re-encryption algorithm as follows:
  • DEK random data encryption key
  • EDEK PRE.Enc(PECKey#i, DEK)
  • the EDEK in some embodiments, is included as a part of every message sent by the producer to the broker during the session.
  • the content of each message in some embodiments, is encrypted with DEK while the metadata associated is kept in clear. If the system is required to interoperate with traditional message schemes, then, in some embodiments, for an encrypted message, the encrypted content and EDEK can be interpreted as the content of a message, as long as both producers and consumers agree on this. Another possibility is to include the EDEK as part of the metadata of the encrypted message, if the message format allows it.
  • the broker entity may store the encrypted messages, since metadata is maintained in clear in some use cases, respecting the message format in use.
  • the broker retrieves the pending encrypted messages and passes them through its re- encryption service, which may look for the EDEK into its EDEK cache in case it was previously re-encrypted and sends the cached response (which is a TEDEK element). If the EDEK is not cached, in some embodiments, then the re-encryption service performs a re-encryption operation using the corresponding re-encryption key between the channel and the consumer.
  • the re- encryption key is labeled as RK[i->j], as described before, and the re-encryption service in the broker, in some embodiments, performs the following operation:
  • TEDEK PRE.ReEnc(RK[i->j] , EDEK)
  • the re-encryption service stores the TEDEK in the cache, associated to the original EDEK, and sends it back to the consumer.
  • the consumer application now can decrypt the TEDEK using its private key (SCKey#j), obtaining a DEK, in some embodiments, as follows:
  • the consumer uses the DEK to decrypt the content of the message, which was encrypted using symmetric encryption techniques (e.g., AES-GCM), with DEK as the key.
  • the consumer application may also cache internally the DEK decrypted from the TEDEK, in case there are more messages using the same TEDEK, to save the decryption operation.
  • Granular encryption mode e.g., AES-GCM
  • Encrypted channels may also be created in the granular encryption mode.
  • the channel owner can establish granular encryption policies per message field, assuming all the messages in the channel share a common field-value format.
  • the message format of such channels follows a recursive structure of field-value pairs, ⁇ fieldl : valuel, field2 : value2, ... , fieldN : valueN ⁇ , where each value may be, in turn, another structure of field-value pairs.
  • Example of such a format is the JSON format.
  • channel owners do not use a single ECKeypair, and there will be per-field keys instead of a single per-channel key.
  • channel owners use a single per-channel secret of proper size (>256 bits), which is randomly (e.g., pseudo-randomly with an appropriate seed) generated. The present disclosure denotes this element as Channel Secret.
  • the channel owner may derive keys for the desired fields in the message format using a key derivation procedure on the Channel Secret.
  • Inputs to the key derivation procedure are the following parameters: (i) the Channel Secret; (ii) the field name (F); and (iii) an optional salt value.
  • FKeypair#F KeyDerivation(ChannelSecret, F, [salt])
  • KDF Key Derivation Function
  • auxiliary secret of enough size (e.g., > 256 bits)
  • CSPRNG Key Generation algorithm of the PRE scheme
  • public keys are computed with a deterministic function over the secret key, and admit to directly use the auxiliary secret as secret key, removing the need of the CSPRNG during key generation.
  • the result of this process is a keypair, referred to as FKeypair and consisting of a public key (PFKey) and a secret key (SFKey), for the corresponding field name. Since this keypair is derived from the Channel Secret, in some embodiments, then it is also owned by the channel owner.
  • Public keys of fields (PFKeys) may require the same distribution mechanisms, in some embodiments, as public keys of channels in the full encryption mode (e.g., storing them at the administration/coordination module, publishing them in a public repository, broadcasting them to the producers, etc.).
  • the channel owner may establish different decryption policies by authorizing consumers on a per-field basis by means of transformation keys. For example, the owner of a channel with a field i may authorize consumer j to read this field in messages of this channel. To do so, in some embodiments, it uses the PRE.ReKeyGen algorithm using the secret key of the field (SFKey#i) and the public key of the consumer (PCKey#j), as follows:
  • TK[i ⁇ j] PRE.ReKeyGen(SFKey#i, PCKey#j)
  • the channel owner may retrieve the PCKey of the consumer it wants to authorize, as in the full channel encryption mode.
  • a producer wants to write one or more messages into a channel
  • it connects to the broker that hosts this channel and establish a session with it, generates a random data encryption key for each encrypted field during the session (each key denoted as DEK#f), retrieves the public key of each field (each public key denoted as PFKey#f) and produces an encrypted version of each DEK#f using the proxy re-encryption algorithm, in some embodiments, as follows:
  • EDEK#f PRE. Erie (PFKey#f DEK#j) [0062]
  • the corresponding value of each message field / is encrypted, in some embodiments, with DEK#f using symmetric encryption, while the field name associated is kept in clear.
  • the result of encrypting a field value value#f with a DEK is denoted as evalue#f.
  • the EDEK#f is included as a part of the corresponding encrypted value evalue#f for the message field during the session.
  • field#2 is composed of two fields, and the channel owner produces keys only for fields field#l and field#2.1; then, encrypted messages will follow a format like the following (or other equivalent ways):
  • the broker entity stores the encrypted messages. Each time a consumer makes a read request for a certain channel, in some embodiments, then the broker retrieves the pending encrypted messages and pass them through its re-encryption service, which looks for the field EDEKs within the message into its EDEK cache in case they were previously re-encrypted. If an EDEK is not cached, in some embodiments, then the re-encryption service performs a re-encryption operation using the corresponding transformation key between the field and the consumer.
  • the broker may substitute the EDEKs in the message by the corresponding TEDEKs and sends the modified message to the consumer.
  • the consumer application in some embodiments, now can decrypt the TEDEKs in the message using its private key (SCKey#j), obtaining a DEK for each TEDEK, as follows:
  • the consumer uses each DEK to decrypt the content of the corresponding field, which was encrypted using symmetric encryption techniques (e.g., AES- GCM), with DEK as the key.
  • the consumer application may also cache internally the DEKs decrypted from the TEDEKs, in case there are more messages using the same TEDEK for a given field, to save the decryption operation.
  • the above and related techniques may be implemented in a computing environment 10 shown in Figure 1, e.g., on a plurality of computing devices like that of Figure 6, for instance, by executing processes like those shown in Figures 2-5.
  • the computing environment 10 may include a publish-subscribe application implemented with a plurality of brokers 14.
  • this application may be a distributed application executed on a plurality of different computing devices, and some cases on a plurality of different virtual machines or containers on those computing devices.
  • the publish-subscribe application is part of a larger distributed application, such as a website, gaming system backend, application program interface, or the like in which various processes reflected by the illustrated producers 12 inject information into the publish-subscribe application, the publish-subscribe application may routes that information in real-time and in sequence to a plurality of processes represented by groups of subscribers or other consumers 16, and those consumer processes execute operations in response to the conveyed information.
  • three data producers 12 are illustrated, but commercial implementations are expected to include substantially more, such as more than 10, more than 100, or more than 10,000 data producers, which may be distinct processes, microservices, computing devices, or other sources of information configured to send requests to convey that information on designated channels to the publish-subscribe application.
  • Producers may be, for example, services of a micro-services architecture, data from various sensors, lambda functions in serverless architectures, client-side code capturing user inputs to a user interface to be sent for server-side processing at the publish-subscribe application, and the like.
  • producers may be load balancers sitting behind a web server that route work to different data consumers via the publish-subscribe application.
  • producers 12 may communicate with consumers 16 on a channel- by-channel bases, with different consumers subscribing to different channels, and with units of communication being referred to as messages.
  • a given producer may send a given message on one or more channels, and a given consumer may subscribe to one or more channels.
  • a message on a given channel may be sent to every consumer that subscribes to that channel (though in some cases only a subset of the consumers may be able to decrypt some or all of that message in some embodiments described herein).
  • messages may be conveyed in real-time in a streaming format, for instance, within less than one minute of when the message is received by the publish-subscribe application, less than 10 seconds, less than one second, less than 500 ms, or less than 100 ms.
  • the ordering of the message within a channel may be preserved and conveyed to subscribers.
  • messages may be augmented to include timestamps, stored in data structures that preserve ordering like stacks or lists, augmented with sequence numbers, or the like.
  • messages should be read broadly to include either the message content injected into the system by the data producer or that message content along with accumulated information that follows the message through the system, like timestamps, encryption keys, channel identifiers, or subsets thereof. For example, statements that a "message is encrypted” do not require that both the message content and a timestamp appended to that message be encrypted, as it is enough to encrypt the message content in this example, or some other field.
  • messages may have formats, like a schema.
  • messages are conveyed in a hierarchical serialization format, like JavaScript object notation (JSON) or extensible markup language (XML).
  • messages may include a plurality of fields, which in some cases may be data associated with keys in keyvalue pairs in such a data serialization format or data associated with terms in a dictionary in such a data serialization format.
  • producers may access channel-specific data schemas and format messages according to the schema, for example, by populating various entries under various fields. Or in some cases, multiple schemas may apply to a single channel.
  • data formats are defined by application program interfaces of consumer processes with which the producers are communicating.
  • schemas may indicate which fields are to be encrypted, and in some cases, which channels are to be used to convey messages complying with the schemas and which consumer groups or consumers are to be granted access to messages under the schemas. Or in some cases entire messages may be encrypted, for example, in a single ciphertext.
  • producers may include an encryption component 24 configured to encrypt messages in a manner specified by schema before those messages are emitted by respective producers 12.
  • this encryption may be applied to both data at rest and in transit.
  • the encryption may be applied without first establishing a secure channel with a broker or in addition to establishing a secure channel of communication by the producer with the publish-subscribe application.
  • the presently described encryption may be a distinct layer of encryption from that applied in, for example, transport layer security encryption (or SSL) applied to data in flight.
  • the publish-subscribe application may process a relatively large number of messages at a relatively high rate, such as more than 100 messages per second, more than 1000 messages per second, or more than 10,000 messages per second, in some cases with messages being conveyed between data centers over a relatively large geographic areas, such as more than 10,000 km 2 , like areas larger than the United States, such as across the world.
  • the data producers 12 may execute a process described below with reference to Figure 2 to encrypt messages based on a public cryptographic key (also called a public encryption key) or set of public cryptographic keys associated with (for instance in a one- to-one association) a channel on which the encrypted message is to be conveyed.
  • the encryption may implement a hybrid encryption scheme in which the messages are first encrypted with a symmetric cryptographic key, such as a random value with greater than 127 bits of entropy, greater than 255 bits of entropy, or greater than 511 bits of entropy, and then that symmetric key is encrypted with an asymmetric encryption algorithm by encrypting the symmetric key with the public key of the channel.
  • different symmetric keys may be used to encrypt different fields of a given message and each of those different symmetric keys may be encrypted with the same public cryptographic key of the channel, or with field- specific public cryptographic keys of the channel on which the message is to be conveyed.
  • This two-stage encryption approach is expected to afford certain scaling advantages in subsequently described transformations, such as re-encryption, for example, with proxy re-encryption, and the encrypted symmetric encryption key may be relatively fast and impose a predictable amount of computational and network load compared to re-encrypted message fields that may vary in size and in some cases be relatively long.
  • producers 12 may send messages by calling a publish application program interface of the publish-subscribe application including brokers 14.
  • a schema of this API may specify various parameters, such as the content of the message to be conveyed, a value by which the data producer 12 indicates one or more channels on which the messages to be conveyed, and a command to convey the message.
  • the data producers 12 do not have access to which consumer processes or groups 16 of consumer processes that subscribe to a channel on which the message is requested to be conveyed. For example, producers 12 may not have access to the identity or network address of consumers that subscribe to a channel, thereby shielding developers of producers for managing this complexity and affording relatively manageable elastic scaling of resources on the consumer side by abstracting away service discovery from the producers.
  • messages may be allocated to the appropriate channel, sequenced, transformed, and delivered to subscribing consumers by respective brokers 14.
  • the data brokers 14 may be implemented in a relatively fault-tolerant architecture in which illustrated features are replicated on distinct computing devices, such that failure of a given computing device does not prevent a given message from being delivered.
  • each broker may include a plurality of partitions 28 and a re-encryption service 30 associated with each partition.
  • partitions may correspond to different channels, for instance, with each channel having one or more partitions specific to that channel, or in some cases, a given partition may service multiple channels.
  • the brokers may be managed by an administration module 20 of the publish-subscribe application, and in some cases the publish-subscribe application may execute a process described below with reference to Figure 4 to route messages to subscriber consumer processes and delegate access to designated subscriber consumer processes with proxy re-encryption.
  • each broker may manage a different channel, or in some cases a plurality of channels may be processed by single broker, or one channel may be processed by a plurality of brokers.
  • a channel owner service 18 may execute in a different security domain from the other described components and may determine which subscribers to a given channel are to be delegated access to which information on that channel, such as which messages or which fields of messages. To effectuate these results of these determinations, the channel owner service 18 may execute a process described below with reference to Figure 3 to generate consumer-set-specific transformation keys for designated channels, and in some cases field-and- consumer-set specific transformation keys for given channels.
  • these transformation keys may be conveyed outside the security domain of the channel owner service 18 to the re-encryption services 30, which may use the re- encryption keys to transform encryption that is only accessible with a secret encryption key of the channel owner into encryption that is only accessible with a secret encryption key of a set of designated consumers to which access is delegated.
  • access to different fields in messages on a channel may be differently allocated to different sets of consumer processes. For instance, different consumer groups 16 may be granted access to different sets of fields with different corresponding sets of re-encryption keys.
  • different messages on a channel may have different access grants to different consumer processes, for instance, one set of consumer processes may be delegated access to messages having a field with a value indicating a geographic region corresponding to North America, while a different set of consumer processes may be delegated access to messages on the same channel having a field designating South America.
  • the re-encryption services 30 may apply various criteria or other rules associated with sets of re-encryption keys to messages to determine which sets of re-encryption keys to apply to which messages and which portions of messages.
  • rules may further include rules specifying a set of re-encryption keys are to be applied to messages having a timestamp within a designated range of time, to messages with a prefix or suffix of a ciphertext of message content satisfying a regular expression (like delegating access to messages with a ciphertext that ends in a 0 to one consumer process and delegating access to messages with a ciphertext that ends in a 1 to another consumer process), a rule specifying that a smaller set of fields are to have access delegated to consumers for messages emanating from (or corresponding to users in) Europe than in those emanating from the United States, and the like.
  • a given field in a given message may have access delegated to different consumer processes in different security domains from one another, such that processes in one security domain do not have access to secret (also referred to as private) encryption keys of encryption key pairs for which a public encryption key was used to generate re-encryption keys used on the given field.
  • secret also referred to as private
  • multiple transformed encrypted symmetric encryption keys for the field may be appended to the message, for instance, in association with respective identifiers of the corresponding consumer process having a secret encryption key suitable for decrypting the corresponding transformed encrypted symmetric encryption key.
  • Consumer processes receiving these messages may parse these keyvalue pairs to select the one associating their identifier with the corresponding transformed encrypted symmetric encryption key, and upon detecting their identifier (which may be their public encryption key), select the corresponding one of the multiple transformed encrypted symmetric encryption keys to decrypt with their corresponding private encryption key. Or in some cases, different versions of the message with different corresponding transformed encrypted symmetric encryption keys may be provided to different sets of consumer processes depending upon which consumer-set-specific re-encryption keys were used to transform encryption in the respective message.
  • the channel owner service 18 may generate re-encryption keys based on a set of public-private encryption key pairs for a channel (like one for each field subject to encryption to which access is separably delegable) and a public encryption key of a set of consumers to which access is to be delegated.
  • the channel owner service may generate re-encryption keys without decrypting the encrypted symmetric keys or the underlying ciphertext encrypted with those symmetric keys.
  • the channel over owner service may generate the re-encryption keys without the message, and encrypted portion thereof, or any portion thereof in some cases, entering the security domain of the channel owner service 18.
  • the channel owner service 18 may generate the re- encryption keys without the private encryption key of the set of consumers to which access is delegated entering the channel owner service's security domain.
  • the channel owner service 18 may maintain a relatively limited attack surface with a relatively narrow channel of communication.
  • the channel owner 18 may delegate access with relatively low bandwidth and relatively low latency communication with the portions of the publish-subscribe application outside the security domain of the channel owner, thereby facilitating physical architectures that are potentially more secure, such as physical architectures in which the channel owner service 18 is executed on a different subnet, in a different physical facility, on a different computing device, on a different processor, or otherwise isolated from the other portions of the publish-subscribe application.
  • the illustrated environment 10 includes a single consumer group 16 with a plurality of consumer services 32 though embodiments are expected to include substantially more in commercial deployments, such as more than two, more than five, more than 50, or more than 1000.
  • the illustrated consumer group 16 includes three consumer processes 32, though again some consumer groups are expected to include substantially more, such as more than 10, more than 50, or more than 1000.
  • the consumer services 32 may each be different hosts on a network or set of networks, or in some cases the consumer services 32 may be different processes within a given computing device or combination thereof.
  • a service may be both a data producer and a consumer.
  • various stream processing applications like Apache FlinkTM, Apache StormTM, Apache SparkTM, and the like may execute real-time complex event processing on messages on channels to which they subscribe and then output results as messages on other channels in which they serve the role of data producer.
  • each consumer group may have a set of consumer group decryption keys, which may be private encryption keys corresponding to the public encryption keys with which the channel owner service 18 generates the re-encryption keys for the channel for the consumer group.
  • each consumer service 32 may include a decryption component 34 operative to access the private decryption key of the consumer group, decrypt the transformed encrypted symmetric encryption key or set thereof appended to (or otherwise associated with) the message, and then decrypt the corresponding ciphertext in the message with the accessed symmetric encryption keys, in some cases on a field-by-field basis.
  • each consumer group 16 may be in a different security domain, such that the private encryption key used by that consumer group is not accessible outside of that consumer group, for instance, to other components of the illustrated computing environment 10.
  • the consumer group 16 may maintain these keys in a consumer group decryption key management system 36, which in some cases may publish the public cryptographic key corresponding to the private encryption key to the other components outside the security domain of the consumer group 16, for instance, to the channel owner service 18, and some cases in association with an identifier of the consumer group if distinct from the public key.
  • the administration module 20 may be configured to route re- encryption keys to the appropriate re-encryption service on behalf of the channel owner 18 and manage operation of the illustrated brokers 14. Further, in some embodiments, the administration module 20 may be configured to detect failed partitions or brokers and instantiate new instances thereof. In some embodiments, the administration module 20 may be configured to elastically scale a number of brokers, partitions, or servers therein according to an amount of workload. In some embodiments, partitions 28 may be implemented with fault-tolerant collections of redundant servers, such as a plurality of servers including a leader server and a plurality of follower servers that replicate the leader server. Upon failure of a leader server, some embodiments of the follower servers may elect a new leader server, for instance, with RAFT or Paxos or other decentralized consensus algorithms, or in some cases the administration module 20 may select a new leader server.
  • the channel owner service 18 may be configured to cause access to be delegated.
  • the channel owner service 18 may reside within a security domain in which channel-specific sets of private encryption keys 40 are accessible. Generated re-encryption keys may be stored and distributed from a key repository 38 in the security domain of the channel owner 18.
  • the channel owner 18 may publish public keys thereof to the a public-key repository 22 accessible by data producers 12, and in some cases with associated values mapping public keys to channels, to message formats on those channels, and to fields within those message formats.
  • the channel's secret keys also called private encryption keys
  • the channel owner service 18 may provide the re-encryption keys directly to the consumer groups 16 to which the re-encryption keys apply, and the consumer groups 16 may convey those re-encryption keys to the re- encryption services 30, for example, as access tokens in access requests. Or in some cases the re- encryption services 30 may reside within the security domain of the consumer groups 16, and the illustrated transformations may be executed further downstream.
  • the producers 12 may obtain the channel-specific sets of public encryption keys 26 from the public-key repository 22. For example, upon determining to send a message on a given channel in a given format, a producer 12 may send a query to the public key repository 22 for a set of public encryption keys of the channel owner service 18 corresponding to that format and receive the keys in response.
  • a single channel owner service 18 is illustrated, but some embodiments may include substantially more, each in a different security domain, such that private cryptographic keys thereof are not accessible to the different channel owner services other than the channel to owner to which the keys pertain.
  • a given channel owner service's security domain may correspond to multiple channels or one and only one channel.
  • Figure 2 is a flowchart depicting an example of a process 50 that may be executed by one or more of the above-describe data producers 12, though embodiments are not limited to that implementation, which is not to suggest that any other description herein is limiting.
  • instructions by which the process 50, the other processes herein, and the other functionality herein are implemented may be stored on a tangible, non-transitory, machine- readable medium, such that when those instructions are executed, the described operations are effectuated.
  • the process 50 begins with obtaining a message in a format with a plurality of fields, as indicated by block 52. Some embodiments may then select a channel to which the message is to be published, as indicated by block 54. In some embodiments, the channel may correspond to an application program interface of a set of consumer processes for which services are requested. Some embodiments may then obtain the channel's set of one or more public encryption keys, as indicated by block 56. In some embodiments, the set may be a set of one, and the format may indicate that the entire message content is to be encrypted in a single ciphertext with the single public encryption key. Or in some cases, different fields of the message may have different corresponding public encryption keys.
  • Some embodiments may obtain a set of symmetric encryption keys, as indicated by block 58.
  • the symmetric encryption keys may be random (pseudorandom with a suitable sued seed value, like based on thermal noise or electromagnetic noise) of greater than, for example 127 bits of entropy.
  • each resulting ciphertext to be generated may have a different symmetric encryption key.
  • the symmetric encryption key is generated by the producer and not shared by the producer outside the security domain of the producer other than in the form produced by encrypting the symmetric key with the public encryption key to which a corresponds.
  • some embodiments may encrypt fields of messages with symmetric encryption keys, as indicated by block 60, for example by XOR'ing content of the fields with the symmetric key. Some embodiments may then encrypt the symmetric encryption keys with the channel's corresponding public encryption key, as indicated by block 62. Some embodiments may then merge the encrypted symmetric encryption keys with the message, as indicated by block 64, for instance associating within the message the encrypted symmetric encryption key of a field with that fields ciphertext.
  • Encrypted symmetric encryption keys may be associated with messages with a variety of techniques, including by adding the encrypted symmetric encryption keys to a separate data structure associated with the message in an index or by concatenating (or inserting) the symmetric encryption keys to (or in) a sequence of bits encoding the message, for instance prepending, appending, or otherwise inserting (which may include forming a new instance with the added information).
  • Some embodiments may send the encrypted message to a publish-subscribe application in association with the request to publish on a channel, as indicated by block 66.
  • this may include a publisher composing an application program interface calls to the above-described set of broker components that effectuate the publication of the message.
  • Figure 3 shows an example of a process 70 by which re-encryption keys are generated to delegate access to a channel to a subscriber.
  • the process 70 may be executed by the above-described channel owner service 18.
  • Some embodiments may determine to grant access to a channel to subscriber, as indicated by block 72.
  • the determination may be made responsive to a request by a consumer service, such as an authenticated request containing credentials by which a trusted party has designated the consumer as being an appropriate subscriber.
  • the determination may be a determination to grant access to a group of subscribers.
  • the determination may be a determination to grant access to a subset of messages on the channel or a subset of fields of messages on the channel.
  • Some embodiments may obtain the subscriber's public encryption key, as indicated by block 74, which may be part of a public-private encryption key pair in which the private encryption key is held within a security domain of the subscriber, such as a consumer, and not revealed outside of that security domain to other components.
  • the public encryption key may be received as part of a request to grant access and may serve as an identifier of the subscriber.
  • Some embodiments may obtain the channel set of encryption key pairs, as indicated by block 76. In some cases this may be a single encryption key pair having a public encryption key and a private encryption key, where the public encryption key is provided to publishers to facilitate encryption of inbound messages. In some cases, the set may include a set of field- specific or rule-specific encryption keys selectively a pride to different subsets of messages were fields. In some embodiments, the process 70 may include generating a set of re-encryption keys for the subscriber for the channel, as indicated by block 78. In some cases, the set of keys may be specific to the subscribers public encryption key and to the channels public encryption key, or set thereof.
  • Some embodiments may provide the set of re-encryption keys to message brokers, as indicated by block 80.
  • the re-encryption keys may be provided to the subscriber for use with API calls in the form of a authentication token that is used by brokers to transform messages, or the set of re-encryption keys may be held by the subscriber for purposes of transforming encryption by the subscriber.
  • Figure 4 shows an example of a process 90 by which brokers transform encrypted messages to grant access to a subscriber.
  • the process 90 includes obtaining an encrypted message published to a channel, as indicated by block 92.
  • Some embodiments obtain a set of authorized subscribers and respective sets of re-encryption keys for the subscribers, as indicated by block 94.
  • each group of consumers may have its own respective set of re-encryption keys for a channel, and each re-encryption key in the set may correspond to a different subset of fields of the message.
  • embodiments may apply a single re-encryption key to the entire message.
  • Some embodiments may transform the encrypted symmetric encryption keys of the message with re-encryption keys, as indicated by block 96.
  • the transformation may be effectuated with proxy re-encryption, such that the encrypted symmetric encryption keys are transformed from a ciphertext that is decryptable with the channel's private encryption key to a ciphertext that is decryptable with the subscriber's private encryption key.
  • the transformation is performed without decrypting the encrypted symmetric encryption keys.
  • the transformation is performed without having access to a private encryption key of a public encryption key with which the encrypted symmetric encryption keys are encrypted.
  • transformation may be performed in response to receiving the encrypted message, without waiting for a request for the encrypted message from a subscriber.
  • transformation may be performed in response to receiving a request for the message from a subscriber.
  • Some embodiments may provide the messages transformed for each subscriber to respective subscribers, as indicated by block 98.
  • messages may be added to a queue for the subscriber, messages may be pushed to the subscriber (or pulled), and different versions of the message may be provided to different subscribers with different transformations, or each subscriber may receive the same version of the message with only a subset of the encrypted symmetric encryption keys post transformation being decryptable by a respective subscriber.
  • Figure 5 shows an example of a process 100 by which encrypted messages are accessed by consumers or other subscribers.
  • Some embodiments include retrieving encrypted messages from a channel, as indicated by block 102. Messages may be retrieved in virtue of those messages being pushed, or messages may be retrieved by pulling messages from a queue, in some cases from a consumer-specific queue for the channel. In some cases, such queues may be first-in-first-out queues or last-in-first-out queue.
  • Some embodiments may obtain private encryption keys of the respective consumer, as indicated by block 104.
  • Some embodiments may decrypt the transformed encrypted symmetric encryption keys with the obtained private encryption key or keys, as indicated by block 106.
  • Some embodiments may then decrypt encrypted portions of messages with decrypted symmetric encryption keys, as indicated by block 108. (Or some embodiments may encrypt the message content directly with the public encryption key of the channel, using a purely asymmetric encryption scheme rather than a hybrid scheme.) Thus, consumers may access the encrypted portions of the message. In some cases, certain consumers may only access certain subsets of the message in virtue of not having transformed encrypted symmetric encryption keys for subsets to which they are not granted access.
  • access may be revoked for one consumer among a set granted access to a channel.
  • some embodiments may change the public-private encryption key pair of the channel, update the data producers with the new public key, and generate new re-encryption keys for all consumers for which access was grated other than that for which access is revoked.
  • Figure 6 is a diagram that illustrates an exemplary computing system 1000 in accordance with embodiments of the present technique.
  • Various portions of systems and methods described herein may include or be executed on one or more computer systems similar to computing system 1000. Further, processes and modules described herein may be executed by one or more processing systems similar to that of computing system 1000.
  • Computing system 1000 may include one or more processors (e.g., processors 1010a- 1010 ⁇ ) coupled to system memory 1020, an input/output I/O device interface 1030, and a network interface 1040 via an input/output (I/O) interface 1050.
  • processors may include a single processor or a plurality of processors (e.g., distributed processors).
  • a processor may be any suitable processor capable of executing or otherwise performing instructions.
  • a processor may include a central processing unit (CPU) that carries out program instructions to perform the arithmetical, logical, and input/output operations of computing system 1000.
  • CPU central processing unit
  • a processor may execute code (e.g., processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof) that creates an execution environment for program instructions.
  • a processor may include a programmable processor.
  • a processor may include general or special purpose microprocessors.
  • a processor may receive instructions and data from a memory (e.g., system memory 1020).
  • Computing system 1000 may be a uni-processor system including one processor (e.g., processor 1010a), or a multi-processor system including any number of suitable processors (e.g., lOlOa-lOlOn). Multiple processors may be employed to provide for parallel or sequential execution of one or more portions of the techniques described herein.
  • Processes, such as logic flows, described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating corresponding output. Processes described herein may be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
  • Computing system 1000 may include a plurality of computing devices (e.g., distributed computer systems) to implement various processing functions.
  • I/O device interface 1030 may provide an interface for connection of one or more I/O devices 1060 to computer system 1000.
  • I/O devices may include devices that receive input (e.g., from a user) or output information (e.g., to a user).
  • I/O devices 1060 may include, for example, graphical user interface presented on displays (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), pointing devices (e.g., a computer mouse or trackball), keyboards, keypads, touchpads, scanning devices, voice recognition devices, gesture recognition devices, printers, audio speakers, microphones, cameras, or the like.
  • I/O devices 1060 may be connected to computer system 1000 through a wired or wireless connection.
  • I/O devices 1060 may be connected to computer system 1000 from a remote location. I/O devices 1060 located on remote computer system, for example, may be connected to computer system 1000 via a network and network interface 1040.
  • Network interface 1040 may include a network adapter that provides for connection of computer system 1000 to a network.
  • Network interface may 1040 may facilitate data exchange between computer system 1000 and other devices connected to the network.
  • Network interface 1040 may support wired or wireless communication.
  • the network may include an electronic communication network, such as the Internet, a local area network (LAN), a wide area network (WAN), a cellular communications network, or the like.
  • System memory 1020 may be configured to store program instructions 1100 or data 1110.
  • Program instructions 1100 may be executable by a processor (e.g., one or more of processors 1010a- 1010 ⁇ ) to implement one or more embodiments of the present techniques.
  • Instructions 1100 may include modules of computer program instructions for implementing one or more techniques described herein with regard to various processing modules.
  • Program instructions may include a computer program (which in certain forms is known as a program, software, software application, script, or code).
  • a computer program may be written in a programming language, including compiled or interpreted languages, or declarative or procedural languages.
  • a computer program may include a unit suitable for use in a computing environment, including as a stand-alone program, a module, a component, or a subroutine.
  • a computer program may or may not correspond to a file in a file system.
  • a program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program may be deployed to be executed on one or more computer processors located locally at one site or distributed across multiple remote sites and interconnected by a communication network.
  • System memory 1020 may include a tangible program carrier having program instructions stored thereon.
  • a tangible program carrier may include a non-transitory computer readable storage medium.
  • a non-transitory computer readable storage medium may include a machine readable storage device, a machine readable storage substrate, a memory device, or any combination thereof.
  • Non-transitory computer readable storage medium may include nonvolatile memory (e.g., flash memory, ROM, PROM, EPROM, EEPROM memory), volatile memory (e.g., random access memory (RAM), static random access memory (SRAM), synchronous dynamic RAM (SDRAM)), bulk storage memory (e.g., CD-ROM and/or DVD- ROM, hard-drives), or the like.
  • nonvolatile memory e.g., flash memory, ROM, PROM, EPROM, EEPROM memory
  • volatile memory e.g., random access memory (RAM), static random access memory (SRAM), synchronous dynamic RAM (SDRAM)
  • bulk storage memory e.g.,
  • System memory 1020 may include a non-transitory computer readable storage medium that may have program instructions stored thereon that are executable by a computer processor (e.g., one or more of processors lOlOa- ⁇ ) to cause the subject matter and the functional operations described herein.
  • a memory e.g., system memory 1020
  • Instructions or other program code to provide the functionality described herein may be stored on a tangible, non-transitory computer readable media. In some cases, the entire set of instructions may be stored concurrently on the media, or in some cases, different parts of the instructions may be stored on the same media at different times.
  • I/O interface 1050 may be configured to coordinate I/O traffic between processors lOlOa- ⁇ , system memory 1020, network interface 1040, I/O devices 1060, and/or other peripheral devices. I/O interface 1050 may perform protocol, timing, or other data transformations to convert data signals from one component (e.g., system memory 1020) into a format suitable for use by another component (e.g., processors lOlOa-lOlOn). I/O interface 1050 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard.
  • PCI Peripheral Component Interconnect
  • USB Universal Serial Bus
  • Embodiments of the techniques described herein may be implemented using a single instance of computer system 1000 or multiple computer systems 1000 configured to host different portions or instances of embodiments. Multiple computer systems 1000 may provide for parallel or sequential processing/execution of one or more portions of the techniques described herein.
  • Computer system 1000 is merely illustrative and is not intended to limit the scope of the techniques described herein.
  • Computer system 1000 may include any combination of devices or software that may perform or otherwise provide for the performance of the techniques described herein.
  • computer system 1000 may include or be a combination of a cloud-computing system, a data center, a server rack, a server, a virtual server, a desktop computer, a laptop computer, a tablet computer, a server device, a client device, a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a vehicle-mounted computer, or a Global Positioning System (GPS), or the like.
  • PDA personal digital assistant
  • GPS Global Positioning System
  • Computer system 1000 may also be connected to other devices that are not illustrated, or may operate as a stand-alone system.
  • the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components.
  • the functionality of some of the illustrated components may not be provided or other additional functionality may be available.
  • instructions stored on a computer-accessible medium separate from computer system 1000 may be transmitted to computer system 1000 via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network or a wireless link.
  • Various embodiments may further include receiving, sending, or storing instructions or data implemented in accordance with the foregoing description upon a computer-accessible medium. Accordingly, the present techniques may be practiced with other computer system configurations.
  • illustrated components are depicted as discrete functional blocks, but embodiments are not limited to systems in which the functionality described herein is organized as illustrated.
  • the functionality provided by each of the components may be provided by software or hardware modules that are differently organized than is presently depicted, for example such software or hardware may be intermingled, conjoined, replicated, broken up, distributed (e.g. within a data center or geographically), or otherwise differently organized.
  • the functionality described herein may be provided by one or more processors of one or more computers executing code stored on a tangible, non-transitory, machine readable medium.
  • third party content delivery networks may host some or all of the information conveyed over networks, in which case, to the extent information (e.g., content) is said to be supplied or otherwise provided, the information may provided by sending instructions to retrieve that information from a content delivery network.
  • Statements in which a plurality of attributes or functions are mapped to a plurality of objects encompasses both all such attributes or functions being mapped to all such objects and subsets of the attributes or functions being mapped to subsets of the attributes or functions (e.g., both all processors each performing steps A-D, and a case in which processor 1 performs step A, processor 2 performs step B and part of step C, and processor 3 performs part of step C and step D), unless otherwise indicated.
  • statements that one value or action is "based on" another condition or value encompass both instances in which the condition or value is the sole factor and instances in which the condition or value is one factor among a plurality of factors.
  • statements that "each" instance of some collection have some property should not be read to exclude cases where some otherwise identical or similar members of a larger collection do not have the property, i.e., each does not necessarily mean each and every.
  • One or more tangible, non-transitory, machine readable media storing instructions that when executed by one or more processors effectuate operations comprising: receiving, with a publish- subscribe application executed by one or more processors, from a first data producer, a first message and a first request to publish the first message to a first channel specified by the first request, wherein: at least part of the first message is encrypted by the first data producer, the first data producer is one of a plurality of data producers for which the publish-subscribe application publishes messages, the first channel is one of a plurality of channels on which the publish- subscribe application publishes messages on behalf of the plurality of data producers, at least part of the at least part of the first message is decryptable with a first private encryption key of a first public-private encryption key pair associated with the first channel, each of the plurality of channels is associated with at least one different respective public-private encryption key pair among a plurality of public-private encryption key pairs, private encryption keys of the public- private encryption key pairs are maintained in a first security domain
  • re-encryption keys are generated for a plurality of pairs of subscribers and channels; at least some subscribers are associated with a plurality of re-encryption keys that afford access to a plurality of channels; and at least some channels are associated with a plurality of re-encryption keys that afford access to the respective channel by a plurality of subscribers.
  • the at least part of the first message is encrypted by the first data producer with a symmetric encryption key having more than 127 bits of entropy; the symmetric encryption key is encrypted with the first public encryption key of the first channel to which the first message is published to form an encrypted data encryption key; transforming the first message comprises transforming the encrypted data encryption key to form a transformed encrypted data encryption key; the encrypted data encryption key is not decryptable with the second private encryption key; and the at least part of the first message is accessible to the first subscriber by decrypting the transformed encrypted data encryption key with the second private encryption key to access the symmetric encryption key and then decrypting the at least part of the first message with the symmetric encryption key.
  • the plurality of public-private encryption key pairs have private encryption keys protected in a plurality of different security domains different from the first security domain, such that at least some private encryption keys are in different security domains.
  • the first channel is associated with a plurality of field-specific public-private encryption key pairs; each of the field-specific public-private encryption key pairs is associated with a respective subset of the fields among the plurality of fields; the first publisher encrypts different fields, or data encryption keys thereof, with different corresponding public encryption keys among the plurality of field-specific public-private encryption key pairs; a plurality of field-specific re-encryption keys are generated for the first subscriber; and each of the field-specific re-encryption keys corresponds to a different one of the plurality of field-specific public-private encryption key pairs.
  • a second channel among the plurality of channels is associated with a message format having a plurality of fields
  • different subsets of the plurality of fields are associated with different public-private encryption key pairs having respective private encryption keys by which the associated respective subset of the plurality of fields is decryptable; a first set of a plurality of re-encryption keys is generated for the first subscriber to afford access to a first subset of the plurality of fields; a second set of a plurality of re-encryption keys is generated for a second subscriber to afford access to a second subset of the plurality of fields; and the first subset of the plurality of fields is different from the second subset of the plurality of fields.
  • a first message broker of the publish-subscribe application receives the first message and the first request; the first message broker determines that the first subscriber has been granted access to the first channel and, in response, selects the first re-encryption key from among a plurality of re-encryption keys of subscribers to the first channel and transforms the at least part of the first message based on the first re-encryption key; and the publish-subscribe application comprises a plurality of message brokers including the first message broker.
  • any one of embodiments 1-14 wherein the operations comprise: obtaining a plurality of rules by which access to messages in the first channel is determined based on content of the messages; and determining to transform the at least part of the first message based on a determination that content of the first message satisfies at least one of the plurality of rules.
  • the first message is received with encryption that is not decryptable by any subscribers to the first channel; and the first message is transformed into a plurality of different instances each with different encryption that is decryptable by different sets of subscribers.
  • the publish-subscribe application includes a distributed streaming platform having fault-tolerant distributed storage of published messages and executable on a plurality of computing devices; and the data publishers and subscribers are computing processes that interface with one another via the publish-subscribe application.
  • each message published via the publish-subscribe application is appended to an ordered, immutable list of messages stored by the publish-subscribe application; the list is stored on a plurality of partitions each managed by a different server among a plurality of servers; at last part of the list is replicated from a leader server among the plurality of servers to one or more follower servers among the plurality of servers; and at least some of the follower servers are in different data centers from one another.
  • a method comprising: the operations of any one of embodiments 1-18.
  • a system comprising: one or more processors; and memory storing instructions that when executed by the processors cause the processors to effectuate operations comprising: the operations of any one of embodiments 1-18.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système informatique et un procédé qui permettent un accès délégué à des informations chiffrées pour des structures de messagerie distribuée et de mise en file d'attente, ou de manière générale à des architectures de publication/d'abonnement. Dans lesdites structures et architectures, des données sont publiées par des producteurs de données et organisées en canaux ou files d'attente auxquels les applications client peuvent s'abonner et qui sont gérés par une ou plusieurs entités de courtage.
PCT/US2018/031615 2017-05-08 2018-05-08 Gestion d'accès à hautes performances et protection de données pour des applications de messagerie distribuée WO2018208787A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762502938P 2017-05-08 2017-05-08
US62/502,938 2017-05-08

Publications (1)

Publication Number Publication Date
WO2018208787A1 true WO2018208787A1 (fr) 2018-11-15

Family

ID=64104942

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/031615 WO2018208787A1 (fr) 2017-05-08 2018-05-08 Gestion d'accès à hautes performances et protection de données pour des applications de messagerie distribuée

Country Status (1)

Country Link
WO (1) WO2018208787A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109660555A (zh) * 2019-01-09 2019-04-19 上海交通大学 基于代理重加密的内容安全分享方法和系统
US20200076777A1 (en) * 2018-08-29 2020-03-05 International Business Machines Corporation Encrypted data according to a schema
CN112235205A (zh) * 2020-09-21 2021-01-15 珠海市卓轩科技有限公司 一种发送和消费mq消息的方法、装置及存储介质
CN113475038A (zh) * 2020-01-29 2021-10-01 思杰系统有限公司 使用半信任中介的安全消息传递
US20220270088A1 (en) * 2019-01-09 2022-08-25 Visa International Service Association Method, System, and Computer Program Product for Network Bound Proxy Re-Encryption and PIN Translation
CN117614751A (zh) * 2024-01-24 2024-02-27 上海银基信息安全技术股份有限公司 内网访问方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090150675A1 (en) * 2000-06-15 2009-06-11 Zix Corporation Secure message forwarding system detecting user's preferences including security preferences
US20110131222A1 (en) * 2009-05-18 2011-06-02 Telcordia Technologies, Inc. Privacy architecture for distributed data mining based on zero-knowledge collections of databases
WO2015055762A1 (fr) * 2013-10-18 2015-04-23 Robert Bosch Gmbh Système et procédé de chiffrement symétrique dynamique, non interactif et parallélisable
US20160182242A1 (en) * 2005-07-22 2016-06-23 OnePatont Software Ltd. Distributing Messages in a Network Environment
US20170054716A1 (en) * 2015-05-07 2017-02-23 ZeroDB, Inc. Zero-knowledge databases

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090150675A1 (en) * 2000-06-15 2009-06-11 Zix Corporation Secure message forwarding system detecting user's preferences including security preferences
US20160182242A1 (en) * 2005-07-22 2016-06-23 OnePatont Software Ltd. Distributing Messages in a Network Environment
US20110131222A1 (en) * 2009-05-18 2011-06-02 Telcordia Technologies, Inc. Privacy architecture for distributed data mining based on zero-knowledge collections of databases
WO2015055762A1 (fr) * 2013-10-18 2015-04-23 Robert Bosch Gmbh Système et procédé de chiffrement symétrique dynamique, non interactif et parallélisable
US20170054716A1 (en) * 2015-05-07 2017-02-23 ZeroDB, Inc. Zero-knowledge databases

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200076777A1 (en) * 2018-08-29 2020-03-05 International Business Machines Corporation Encrypted data according to a schema
US11722470B2 (en) * 2018-08-29 2023-08-08 International Business Machines Corporation Encrypted data according to a schema
CN109660555A (zh) * 2019-01-09 2019-04-19 上海交通大学 基于代理重加密的内容安全分享方法和系统
US20220270088A1 (en) * 2019-01-09 2022-08-25 Visa International Service Association Method, System, and Computer Program Product for Network Bound Proxy Re-Encryption and PIN Translation
EP4220385A1 (fr) * 2019-01-09 2023-08-02 Visa International Service Association Procédé, système et produit de programme informatique pour rechiffrement de mandataire lié à un réseau et traduction de pin
US11736295B2 (en) 2019-01-09 2023-08-22 Visa International Service Association Method, system, and computer program product for network bound proxy re-encryption and PIN translation
US11757644B2 (en) * 2019-01-09 2023-09-12 Visa International Service Association Method, system, and computer program product for network bound proxy re-encryption and PIN translation
CN113475038A (zh) * 2020-01-29 2021-10-01 思杰系统有限公司 使用半信任中介的安全消息传递
CN112235205A (zh) * 2020-09-21 2021-01-15 珠海市卓轩科技有限公司 一种发送和消费mq消息的方法、装置及存储介质
CN112235205B (zh) * 2020-09-21 2022-07-01 珠海市卓轩科技有限公司 一种发送和消费mq消息的方法、装置及存储介质
CN117614751A (zh) * 2024-01-24 2024-02-27 上海银基信息安全技术股份有限公司 内网访问方法及系统
CN117614751B (zh) * 2024-01-24 2024-04-02 上海银基信息安全技术股份有限公司 内网访问方法及系统

Similar Documents

Publication Publication Date Title
US10574440B2 (en) High-performance access management and data protection for distributed messaging applications
Wei et al. RS-HABE: Revocable-storage and hierarchical attribute-based access scheme for secure sharing of e-health records in public cloud
US10691817B2 (en) Encryption for distributed storage and processing
EP3811560B1 (fr) Systèmes et procédés pour infrastructure à chaînes de blocs à permissions avec contrôle d'accès à granularité fine et messagerie de publication/d'abonnement préservant la confidentialité
US10581603B2 (en) Method and system for secure delegated access to encrypted data in big data computing clusters
EP3054648B1 (fr) Structure de contrôle d'accès pour réseautage centrique d'informations
WO2018208787A1 (fr) Gestion d'accès à hautes performances et protection de données pour des applications de messagerie distribuée
Esposito et al. On security in publish/subscribe services: A survey
Borcea et al. PICADOR: End-to-end encrypted Publish–Subscribe information distribution with proxy re-encryption
US10404450B2 (en) Schematized access control in a content centric network
WO2018208786A1 (fr) Procédé et système pour un accès délégué sécurisé à des données chiffrées dans des grappes de calcul de mégadonnées
Duan et al. A comprehensive security framework for publish/subscribe-based IoT services communication
Hahn et al. Efficient IoT management with resilience to unauthorized access to cloud storage
Huang et al. YI Cloud: Improving user privacy with secret key recovery in cloud storage
Huang et al. Adaptive Secure Cross‐Cloud Data Collaboration with Identity‐Based Cryptography and Conditional Proxy Re‐Encryption
Swetha et al. Security on mobile cloud computing using cipher text policy and attribute based encryption scheme
Pareek et al. Proxy re-encryption scheme for access control enforcement delegation on outsourced data in public cloud
US9294447B2 (en) Access control
Liu et al. Non-interactive Zero Knowledge Proof Based Access Control in Information-Centric Internet of Things
Ghoubach et al. Efficient and secure data sharing with outsourced decryption and efficient revocation for cloud storage systems
Fakude et al. The effect of data transmission and storage security between device–cloudlet communication
Cheng et al. Privacy-preserving publish/subscribe service in untrusted third-party platform
Radhakrishnan et al. Attribute and Time Factors Combined CP-ABE and RSA based Access Control Scheme for Public Cloud
Xiong et al. Cloud storage access control scheme of ciphertext algorithm based on digital envelope
Song et al. A decentralized crypto network with dynamic threshold change

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18798361

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18798361

Country of ref document: EP

Kind code of ref document: A1