Key rotation in publish-subscribe systems

Abstract

The present disclosure relates to a method for encryption key rotation in a publish-subscribe system that provides a broker service for routing stored encrypted messages to one or more subscribers of a topic to which the routed messages are assigned. The routing includes decrypting the stored messages. The encryption key rotation includes re-encrypting the stored messages using an encrypted replacement key. The re-encryption is performed by an encryption module of the publish-subscribe system as a background process while the broker service continues.

Description

[Technical Field]

[0001] The present disclosure relates to the field of publish-subscribe systems, and more particularly to methods, computer program products, and computer systems for encryption key rotation in publish-subscribe systems. [Background technology]

[0002] Distributed data streaming systems, such as publish-subscribe systems, play an increasing role in distributing data, for example, within businesses and other types of organizations. Publish-subscribe systems allow messages provided by publishers to be broadcast asynchronously to different parts of the system, i.e., subscribers. Messages published to topics are broadcast to the respective topic subscribers. To protect messages stored in a publish-subscribe system, the stored messages may be encrypted. Summary of the Invention

[0003] According to one embodiment of the present disclosure, a method for encryption key rotation in a publish-subscribe system is provided. The publish-subscribe system stores a plurality of messages, each of the stored messages being assigned to a topic from a group of topics, and each of the stored messages being assigned an encryption key from one or more groups of encryption keys and encrypted with the assigned encryption key. The publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topics to which the routed messages are assigned. The routing includes decrypting the routed messages using each of the messages' assigned encryption key and sending the decrypted messages to one or more of the subscribers of the assigned topics.

[0004] The encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, where each of the first messages is assigned to a common first topic from a group of topics, assigned to a first encryption key from a first set of one or more first encryption keys from the group of encryption keys, and encrypted with the assigned first encryption key, where the re-encryption is performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route the first messages and receive additional first messages from the common first topic.

[0005] The re-encrypting includes adding a second set of one or more second encryption keys to the group of encryption keys. Each of the second encryption keys is a replacement key for one of the first encryption keys. The method further includes decrypting each of the encrypted first messages using a first encryption key assigned to each of the first messages. The decrypted first messages are re-encrypted using a replacement key for the assigned first encryption key. The replacement key used to re-encrypt the re-encrypted first messages is assigned to each of the re-encrypted first messages. A switch from using the encrypted first messages and the assigned first encryption key for routing to using the re-encrypted first messages and the assigned replacement key is performed.

[0006] According to a further embodiment of the present disclosure, there is provided a computer program product for encryption key rotation in a publish-subscribe system, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor of a computer system of the publish-subscribe system to cause the computer system to perform encryption key rotation.

[0007] The publish-subscribe system stores a plurality of messages, each of which is assigned to a topic from a group of topics, and each of which is assigned an encryption key from one or more groups of encryption keys and encrypted with the assigned encryption key. The publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topics to which the routed messages are assigned. The routing includes decrypting the routed messages using each of the messages' assigned encryption key and sending the decrypted messages to one or more of the subscribers of the assigned topics.

[0008] The encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, where each of the first messages is assigned to a common first topic from a group of topics, assigned to a first encryption key from a first set of one or more first encryption keys from the group of encryption keys, and encrypted with the assigned first encryption key, where the re-encryption is performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route the first messages and receive additional first messages from the common first topic.

[0009] The re-encrypting includes adding a second set of one or more second encryption keys to the group of encryption keys. Each of the second encryption keys is a replacement key for one of the first encryption keys. The method further includes, for each of the first messages, decrypting the encrypted first message using the first encryption key assigned to each of the first messages. The decrypted first message is re-encrypted using a replacement key for the assigned first encryption key. The replacement key used for the re-encrypted first message is assigned to each of the re-encrypted first messages. A switch from using the encrypted first message and the assigned first encryption key for routing to using the re-encrypted first message and the assigned replacement key is performed.

[0010] According to a further embodiment of the present disclosure, a computer system for encryption key rotation in a publish-subscribe system is provided. The publish-subscribe system stores a plurality of messages, each of the stored messages being assigned to a topic from a group of topics, and each of the stored messages being assigned an encryption key from one or more groups of encryption keys and encrypted with the assigned encryption key. The publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topics to which the routed messages are assigned. The routing includes decrypting the routed messages using each of the messages' assigned encryption key and sending the decrypted messages to one or more of the subscribers of the assigned topics.

[0011] The encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, where each of the first messages is assigned to a common first topic from a group of topics, assigned to a first encryption key from a first set of one or more first encryption keys from the group of encryption keys, and encrypted with the assigned first encryption key, where the re-encryption is performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route the first messages and receive additional first messages from the common first topic.

[0012] The computer system includes a processor and a memory storing program instructions executable by the processor. Execution of the program instructions by the processor causes the computer system to perform re-encryption. The re-encryption includes adding a second set of one or more second encryption keys to the group of encryption keys. Each of the second encryption keys is a substitution key for one of the first encryption keys. The method further includes, for each of the first messages, decrypting the encrypted first message using the first encryption key assigned to each of the first messages. The decrypted first message is re-encrypted using a substitution key for the assigned first encryption key. A substitution key used to re-encrypt the re-encrypted first message is assigned to each of the re-encrypted first messages. A switch from using the encrypted first message and the assigned first encryption key for routing to using the re-encrypted first message and the assigned substitution key is performed.

[0013] In the following, embodiments of the present disclosure will be described in more detail, by way of example only, with reference to the drawings in which: [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 shows a schematic diagram illustrating an exemplary computer system. [Figure 2]1 shows a schematic diagram illustrating an exemplary publish-subscribe system. [Figure 3] 1 shows a schematic diagram illustrating an exemplary publish-subscribe system. [Figure 4] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with broker-implemented topic encryption. [Figure 5] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with proxy-implemented topic encryption. [Figure 6] 1 illustrates a schematic flow diagram of an exemplary method for encryption key rotation. [Figure 7] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in a broker. [Figure 8] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in a broker. [Figure 9] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in a broker. [Figure 10] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in a broker. [Figure 11] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in proxies. [Figure 12] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in proxies. [Figure 13] FIG. 1 shows a schematic diagram illustrating an exemplary publish-subscribe system with topic aliases implemented in proxies. [Figure 14] 1 illustrates a schematic flow diagram of an exemplary method for encryption key rotation. [Figure 15] 1 shows a schematic diagram illustrating an implementation of re-encryption using a brokered re-encryption service. [Figure 16] 1 illustrates a schematic flow diagram of an exemplary method for encryption key rotation. [Figure 17] 1 shows a schematic diagram illustrating a cloud computing environment. [Figure 18] FIG. 1 is a block diagram illustrating a set of functional abstraction model layers provided by a cloud computing environment. DETAILED DESCRIPTION OF THE INVENTION

[0015] The description of various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments described herein.

[0016] The messages of the plurality of messages stored by the publish-subscribe system may be ordered messages, e.g., time-ordered messages. Switching from using an encrypted first message and an assigned first encryption key for routing to using a re-encrypted first message and an assigned replacement key may be performed automatically such that service to the broker and / or client is uninterrupted and no reconfiguration of the broker and / or client is required.

[0017] Embodiments may implement temporal continuity of encrypted data streams provided by publish-subscribe systems during key rotation. Embodiments may enable data producers / consumers, i.e., publishers / subscribers, to write / read to the encrypted data stream without interruption during key rotation, i.e., while encryption / decryption keys are updated. Thus, key rotation may be performed without interruption of service in distributed data streaming systems in the form of publish-subscribe systems.

[0018] A publish-subscribe system is a system that implements the publish-subscribe messaging pattern, in which message senders, called publishers or producers, categorize the messages they publish into categories, called topics, instead of sending messages directly to any receivers, called subscribers or consumers. Subscribers subscribe to one or more topics and receive only messages for the topics to which they subscribe. Thus, publishers, for example, may be unaware of what subscribers exist, and at the same time, subscribers, for example, may be unaware of what publishers exist. Both publishers and subscribers may only reference topics when sending requests to a publish-subscribe system. The publish-subscribe messaging pattern can have the beneficial effect of enabling network scalability and dynamic network topologies.

[0019] In a publish-subscribe system, subscribers can receive only a subset of the total amount of published messages. The process of selecting published messages for receipt and processing is called filtering. Filtering may be topic-based, for example. In a topic-based publish-subscribe system, messages are published to topics. Subscribers in a topic-based system can receive all messages published to the topics to which they subscribe. For example, a publisher may be responsible for defining the topics to which subscribers can subscribe.

[0020] In a publish-subscribe system, publishers post messages to, for example, an intermediate message broker, and subscribers register subscriptions with the broker, allowing the broker to perform filtering. The broker can perform a store-and-forward function to route messages received from publishers to subscribers. Additionally, the broker can, for example, prioritize messages in a queue before routing. Subscribers can register for particular messages, for example, at build time, initialization time, or run time. For example, in a GUI system, subscribers may be coded to process user commands such as button clicks, which may correspond to build-time registration. For example, XML configuration files may be used to register subscribers. These configuration files may be loaded at initialization time. For example, subscribers may be added or removed at run time. Such run-time registration may be used, for example, in database triggers, mailing lists, or RSS ("Really Simple Syndication" or "Rich Site Summary").

[0021] An advantage of a publish-subscribe system may be the loose coupling between publishers and subscribers. Publishers may not even need to know that subscribers exist. For example, if the focus is on topics, publishers and subscribers may be allowed to remain unaware of the system's topology. Publishers and subscribers can operate independently of each other. A publish-subscribe system can decouple publishers and subscribers in time as well as their locations. A subscriber may subscribe to a topic for the first time and receive messages for that topic that were previously published.

[0022] A further advantage of publish-subscribe systems may be their scalability, which may be improved, for example, by parallel operation, message caching, tree-based or network-based routing, etc. Publish-subscribe systems may provide Internet-wide distributed messaging, for example, via web syndication protocols.

[0023] Server nodes called message brokers act as intermediate hubs, writing the data they receive to storage and forwarding that data to clients upon request. As is common in publish-subscribe systems, data is organized into categories called topics. Message brokers support the so-called streaming paradigm: data can arrive on any topic at any time, and the flow of data is continuous for a bounded or unlimited period of time. Clients of the broker subscribe to one or more topics and receive the data as a stream.

[0024] A topic's data may be stored in one or more topic partitions distributed across a cluster of brokers. Each topic partition may be an ordered sequence of messages. The entire data for a topic is the union of these partitions. A publish-subscribe system may support strict ordering within a partition, but not between partitions. Partitions may be replicated to support fault tolerance. A publish-subscribe system may maintain the following information about a topic: the set of active partitions for a topic and the lead broker (i.e., leader) serving them, the offsets within the partition of the oldest and newest messages, the last read offset for the partition for each consumer group, and the brokers serving replicas of the partition.

[0025] Consumers can connect to the bootstrap broker and get the location of the partition of the topic they want to consume from and the offset of the last message their consumer group read from that partition. They can then request the next offset from each of these partitions. If a broker becomes unavailable, it can organize to nominate a leader for all the unavailable partitions. Once elected as leader, followers must have an In-Sync Replica (ISR) of that partition. Followers receive messages from the leader by consuming from it, just like regular consumers.

[0026] Clients can switch connections to such new leaders. Producers do something similar, but they don't need to care about the latest offset. In summary, publish-subscribe systems can be designed to handle very high loads thanks to the concept of distributed partitions, and to handle failures seamlessly thanks to the concept of replicated partitions.

[0027] Regulations and security best practices may require key rotation, which typically involves re-encrypting data with a new key as a periodic risk mitigation measure or in response to the exposure of an active encryption key. Key rotation poses challenges for publish-subscribe messaging systems due to their continuous, "live" nature. Key rotation, in principle, requires the system to be suspended during re-encryption and resumed only upon completion of the re-encryption process. However, the messaging system must be continuously available to receive and provide data without interruption. This disclosure describes various methods that may enable a messaging system to rotate keys without interrupting its service.

[0028] According to an embodiment, a publish-subscribe system may include a message broker that stores topic messages in encrypted form. This may be accomplished by encrypting incoming data, i.e., messages, and decrypting the same data when responding to client requests.

[0029] Message encryption and decryption may be performed by an encryption module in a broker or proxy in a publish-subscribe system, which has access to the topic encryption key and may be configured to send and / or receive notifications about key rotation events.

[0030] For example, a topic alias can be used to enable key rotation with re-encryption in a publish-subscribe system. The topic alias directs requests to and from a different topic. From a client's perspective, the topic alias appears and behaves like a regular topic. The key rotation process can utilize the alias to create a new, re-encrypted copy of the topic log for the topic to which the topic alias currently directs requests. The new, re-encrypted copy of the topic log is created as a new topic in the background. Once this re-encryption process is complete, the topic alias is redirected to the new, re-encrypted topic. The previous topic log can be safely deleted or archived. For clients of the alias topic, nothing changes (the topic name, i.e., the alias, remains the same, connections remain intact, and service continues uninterrupted). For example, key rotation with re-encryption can be implemented in a publish-subscribe system as an internal broker service. The internal topic management service may be extended to include, for example, a new re-encryption service. Such a re-encryption service can gradually replace stored messages with re-encrypted versions of each message in the background. For large topic logs, the re-encryption process can be optimized using parallelization: the lead broker in a publish-subscribe system can coordinate other brokers in the cluster to share the re-encryption workload, thereby parallelizing the computation.

[0031] According to one embodiment, the encryption keys used to encrypt and decrypt messages in a publish-subscribe system may be symmetric encryption keys.

[0032] According to an embodiment, the encryption module is configured by a broker of a publish-subscribe system. An embodiment may have the beneficial effect that key rotation re-encryption can be performed by the broker.

[0033] According to an embodiment, the encryption module is configured by a proxy in the publish-subscribe system, through which a broker in the publish-subscribe system communicates with clients in the publish-subscribe system. An embodiment may have the beneficial effect that key rotation re-encryption may be performed by the proxy. Thus, only the proxy needs to be coordinated to perform re-encryption, and the broker in the publish-subscribe system may not need to be coordinated to perform re-encryption.

[0034] Both the message decryption and re-encryption processes may require a means of knowing which key encrypted a given message. That means may include an index that maps message IDs to keys or key IDs. An alternative strategy may involve storing the encryption key in encrypted form along with the encrypted message. The encryption key may be encrypted or "wrapped" with another key, a technique known as envelope encryption. During decryption, the encryption module requests that the encryption key be unwrapped, and the unwrapped encryption key can be used to decrypt the message. Because the encryption key is always stored with the message, no index needs to be maintained, greatly simplifying implementation.

[0035] In one embodiment, a Key Management Service (KMS) can be used to support the wrapping and unwrapping operations. The KMS is expected to store the wrapping keys in a highly secure manner so that they never leave the KMS. In a publish-subscribe setting, the encryption module can store the wrapped key in a message header when the message is encrypted and strip the header when decrypting the message before responding to a client request.

[0036] According to one embodiment, encrypted messages stored in a publish-subscribe system each include a header that identifies an assigned encryption key of a group of encryption keys, which may have the beneficial effect that the encrypted messages themselves may identify the encryption key that is used to decrypt the respective message.

[0037] According to one embodiment, the header identifying the assigned encryption key is stripped during routing before sending the routed and decrypted message to the subscriber, which may have the beneficial effect of preventing information regarding the encryption and / or decryption of messages stored in a publish-subscribe system from being shared with clients such as subscribers.

[0038] According to one embodiment, the headers of the encrypted messages each include the identified encryption key in encrypted form using envelope encryption with an envelope encryption key. Decrypting each of the encrypted first messages further includes decrypting an assigned first encryption key provided by the header of each of the first messages using the envelope encryption key. Re-encrypting each of the decrypted first messages further includes encrypting an assigned replacement key used to re-encrypt each of the re-encrypted first messages with the envelope encryption key and replacing the encrypted first encryption key in the header of each of the re-encrypted first messages with the encrypted replacement key.

[0039] Embodiments may have the beneficial effect that the encrypted messages themselves may provide the encryption key used to decrypt the respective messages.

[0040] According to one embodiment, a publish-subscribe system includes an index that identifies, for each stored message, an assigned encryption key from a group of encryption keys. Embodiments may have the beneficial effect that the index can identify, for each stored message, the encryption key used to decrypt the respective message. For example, the index may identify, for example, individual messages, or the index may identify, for example, topic segment files in which messages are stored. For example, the index may include identifiers of stored messages that have been assigned identifiers of encryption keys used to decrypt the respective messages. For example, the index may include identifiers of stored messages that have been assigned identifiers of encryption keys used to decrypt the respective messages.

[0041] According to one embodiment, the re-encryption further includes, for each first message, using an index to identify a first encryption key assigned to the first message, and assigning a replacement key for the identified first encryption key to the re-encrypted first message in the index. For example, the index may identify the original first message encrypted using the first encryption key as well as the re-encrypted first message encrypted using the replacement encryption key. In this case, an identifier of the re-encrypted first message may be added to the index in addition to an identifier of the original first message, and the identifier of the re-encrypted first message may be assigned an identifier of a replacement key used to decrypt the re-encrypted first message. For example, the identifier of the re-encrypted first message may be assigned with the replacement key used to decrypt the re-encrypted first message. For example, the original first message may be replaced in the index by the re-encrypted first message. In this case, the identifier of the original first message may be replaced by the identifier of the re-encrypted first message, and the identifier of the first encryption key may be replaced by the identifier of the replacement key used to decrypt the re-encrypted first message. For example, the first encryption key configured by the index may be replaced by the replacement key used to decrypt the re-encrypted first message.

[0042] Below, various techniques are provided for re-encrypting topic data without interrupting the broker's service.

[0043] The first technique introduces the concept of a topic alias, which directs requests to or from a different topic. From a client's perspective, a topic alias looks and behaves just like a regular topic. The key rotation process uses the alias to create a new, re-encrypted copy of the topic log in the background. Once this re-encryption process is complete, the topic alias is redirected to the new, re-encrypted topic. The previous topic log can then be safely deleted or archived. For clients of the topic, nothing changes (the topic name, i.e., the alias, remains the same, connections remain intact, and service continues without interruption).

[0044] The embodiment may have several beneficial effects (for clients of the topic, i.e., producers and consumers, the topic may behave the same as a traditional topic): It may leave a label to which requests may be directed; Clients need not be particularly aware of the topic alias or any kind of change; Clients may be unaware of the re-encryption process; Re-encrypted data may preserve all metadata such as timestamps, headers, etc.; An uninterrupted publish-subscribe service may be provided to clients; Techniques involving aliases implemented in proxies may implement re-encryption without changes to the broker.

[0045] According to one embodiment, each of the stored messages is stored as a member of the topic to which it is assigned. The method further includes providing a first topic alias from the first set of messages that points to the common first topic. One or more subscribers to the common first topic subscribe to the first topic alias. An additional common second topic is added to the group of topics, and the re-encrypted first message is stored as a member of the common second topic. Switching includes reassigning the first topic alias to the common second topic so that one or more subscribers subscribed to the first topic alias become subscribers to the common second topic.

[0046] Embodiments may have the beneficial effect that a topic alias may be used to implement re-encryption. Switching from the encrypted first message to the re-encrypted first message may be implemented by reassigning the topic alias. While the topic alias is assigned to the common first topic, broker services continue to be provided using the encrypted first message. Once the topic alias is reassigned to the common second topic, broker services continue using the encrypted first message.

[0047] According to one embodiment, the switching further includes deleting the common first topic with the first encrypted message. The embodiment may have the beneficial effect of conserving storage space. According to an alternative embodiment, the switching further includes archiving the common first topic with the first encrypted message.

[0048] According to an embodiment, the switching further comprises deleting the first encryption key. The embodiment may have the beneficial effect of saving storage space. According to an alternative embodiment, the switching further comprises archiving the first encryption key.

[0049] According to one embodiment, additional first messages received by the publish-subscribe system from the publisher for each topic alias are assigned to a common second topic, assigned with one second encryption key from a second set of second encryption keys, and encrypted using the assigned second encryption key.

[0050] Embodiments may have the beneficial effect that additional first messages, in particular first messages received during re-encryption, can be directly encrypted with a second encryption key and assigned to a common second topic.

[0051] Topic aliases are sometimes used to perform key rotation. To clients of a publish-subscribe system, such a topic alias appears as a normal topic, but is actually an intermediary to another topic. Topic aliases may be managed by administrative actions. The minimum administrative actions that support the existence and management of topic aliases may include creating an alias, assigning the created alias to a topic, detaching the alias from a topic, and deleting the detached alias.

[0052] A topic alias that exists but is not assigned may be treated by the broker as non-existent or inactive. This is an implementation choice and affects the error message returned when a client attempts to deal with an unassigned alias. A configurable option allows topic visibility to be automatically revoked once an alias is assigned, resulting in clients accessing the underlying data exclusively through the topic alias.

[0053] Topic aliases may be integrated consistently with all facilities of the respective broker. For example, a broker that integrates with a schema registry may support the registration and updating of aliases in the registry. Similarly, security policies may be applied to topic aliases in the same way as regular topics.

[0054] A typical workflow for rotating a topic encryption key using a topic alias includes creating a topic and a topic alias, assigning the alias to the topic, and configuring the topic alias for encryption. Clients can begin sending and receiving messages through the alias. Key rotation includes adding a new topic and creating a new encryption key for the new topic. The encryption key used by the topic encryption module may be updated with the new encryption key so that new messages received by the publish-subscribe system are encrypted with the new encryption key. A re-encryption process is initiated to copy data, i.e., messages, from the old topic to the newly created topic and re-encrypt the copied data with the new encryption key. During the re-encryption process, new messages that arrive during the re-encryption process may be added to the new topic. Once all data comprising the old topic has been copied to the new topic and re-encrypted, the re-encryption process ends, and the alias is re-assigned to the new topic. Optionally, the previously active topic log for the old topic may be deleted. The above workflow may be performed transactionally.

[0055] Topic aliases may be implemented directly in proxies or brokers in a publish-subscribe system, for example. For example, a publish-subscribe system may include a proxy. If a proxy is implemented in a publish-subscribe system, clients may not communicate directly with the broker in the publish-subscribe system, but rather through the proxy. Similarly, a broker may communicate with clients through the proxy. Proxies may be used for tasks such as implementing a particular access control model in a publish-subscribe system.

[0056] The proxy functionality may also be extended to support topic aliases. In this approach, one or more independent topics may be associated together in the same alias group. Creation and management of this alias group is handled external to the broker. An alias group specifies the number of partitions, replicas, etc., just like a topic. Topics can be added / removed from an alias group, which creates corresponding topics on the cluster in a publish-subscribe system using the alias group's configuration. For example, all topics in the same group can have the same configuration. At any given moment, zero or one topic may be designated as the active topic.

[0057] Clients can communicate with a topic alias as if it were a normal topic, using the standard protocols of the publish-subscribe system. In particular, the program instructions that control the broker of the publish-subscribe system may not need to be modified. Producers can use the standard protocols to send messages to a topic alias, and consumers can use the standard protocols to receive messages from a topic alias. However, a broker or cluster of brokers in a publish-subscribe system does not have a topic log with the alias name. Instead, a proxy may rather map the alias name provided by the topic alias to the name of a topic on the broker or cluster of brokers in the publish-subscribe system. Each topic referenced by a topic alias can play the role of an actual active topic, making it appear as if the topic alias were an actual active topic.

[0058] The encryption module is integrated into the proxy so that the proxy can encrypt messages sent to the topic alias and decrypt messages received from the topic alias. To achieve this, the proxy, or more precisely the encryption module integrated into the proxy, can use the current encryption key. As mentioned above, the current encryption key used for encryption may be added in a wrapped format to the message header of the encrypted message for storage and may be removed from the message header upon decryption to respond to the client request.

[0059] Alternatively, topic aliases may be implemented in the broker of a publish-subscribe system. Such an implementation may require modifying the program instructions that control the broker of the publish-subscribe system. If the program instructions of the broker can be modified, topic aliases may be implemented in the broker without requiring an additional proxy. An implementation that does not require a proxy may have the beneficial effect of removing one additional architectural component from the system. However, proxies may still be used for other benefits, for example, to introduce a specific access control model into the publish-subscribe system. The concepts of aliases and alias groups are the same as above, only integrated directly into the broker along with the encryption module.

[0060] The second technique implements a new re-encryption service. Such a new re-encryption service could, for example, extend the broker's internal topic management service. Similar to a log cleaner in a publish-subscribe system, the re-encryption service could gradually replace stored messages with re-encrypted versions in the background. For very large topic logs, the lead broker coordinates with other brokers in the cluster to share the re-encryption workload, thereby providing an optimization to parallelize the computation. This second technique runs without interrupting the broker service.

[0061] According to one embodiment, switching from encrypted first messages with an assigned first encryption key to re-encrypted first messages with an assigned replacement key includes replacing each encrypted first message with a corresponding re-encrypted first message. Embodiments may have the beneficial effect of performing re-encryption using, for example, a brokered re-encryption service in a publish-subscribe system.

[0062] According to one embodiment, the re-encryption of the first message and the replacement of the encrypted first message with the corresponding re-encrypted first message may be performed continuously. The encrypted first messages may be stored, for example, in segment files, which are continuously re-encrypted. For example, the continuous re-encryption may start from the most recent segment file, i.e., the youngest segment file in terms of time.

[0063] According to one embodiment, the encrypted first message is stored in a set of segment files, one segment file of the set of segment files is currently used to store the encrypted first message, and the remaining segment files of the set of segment files that are already filled with the encrypted first message are closed, and when an open segment file is filled, the open segment file is closed and an additional segment file is added to the set of segment files and used to store the encrypted first message.

[0064] When re-encryption is initiated, the segment file currently being used to store the encrypted first message is closed, and an additional segment file is added to the set of segment files to be used to store additional encrypted first messages received by the publish-subscribe system from publishers on the common first topic.

[0065] The re-encryption of the encrypted first message is performed segmentally, and the segmental re-encryption includes selecting, in succession, the remaining closed segment files, generating, for each selected segment file, a replacement segment file that includes, in encrypted form, the encrypted first message of the selected segment file, and replacing the selected segment file with the replacement segment file.

[0066] The embodiment may have the beneficial effect that the first message is re-encrypted in order and successively.

[0067] According to one embodiment, segmental re-encryption starts with the newest segment file of the set of segment files. The newest, i.e., youngest segment in terms of time, may be the most recently closed segment file and contain the most recently received message. The offsets of these newest messages are the smallest difference from the offset of the message at which encryption using the second encryption key begins in the publish-subscribe system's storage. Embodiments may further have the beneficial effect that the newest message, i.e., the most recent message, may be the message that becomes available first in re-encrypted form. According to embodiments, segment files may be deleted, for example, upon expiration of the maximum retention time of the message constituted by the respective segment file. Embodiments may further have the beneficial effect that the oldest message is re-encrypted last, preventing the publish-subscribe system from unnecessary re-encryption of messages that may later be deleted due to key rotation due to expiration of the maximum retention time.

[0068] According to one embodiment, an offset value is determined that identifies an offset of the additional first message at which encryption using the second encryption key begins in storage of the publish-subscribe system. According to one embodiment, the determined offset value is stored. An embodiment may have the beneficial effect of enabling a publish-subscribe system, for example a broker in the publish-subscribe system, to use the offset value to determine when re-encryption has finished.

[0069] According to one embodiment, each additional first message received by the publish-subscribe system from a subscriber for the common first topic is assigned to the common first topic, assigned with one second encryption key from the second set of second encryption keys, and encrypted using the assigned second encryption key.

[0070] Embodiments may have the beneficial effect that additional first messages, in particular first messages received during re-encryption, can be directly encrypted with the second encryption key and assigned to the common first topic.

[0071] According to one embodiment, the publish-subscribe system includes multiple additional brokers. The publish-subscribe system includes multiple additional replicas of the set of segment files. Each of the additional replicas is assigned to one of the additional brokers. Re-encryption of the segment files is distributed among the brokers of the publish-subscribe system, which performs parallelization of the re-encryption. The re-encrypted first messages are distributed to other replicas of the set of segment files.

[0072] Embodiments may have the beneficial effect of implementing parallelization of the re-encryption, which may allow the re-encryption to be performed more efficiently.

[0073] Key rotation with re-encryption can be implemented, for example, using an internal broker service. Thus, instead of introducing topic aliases, topic management within a broker may rather be extended with additional functionality. Such an approach may require modifying and / or extending known protocols used to control brokers in publish-subscribe systems. Such an embodiment may have the beneficial effect of being more efficient, for example, compared to introducing additional topic aliases and / or using additional proxies.

[0074] A publish-subscribe system can store data, such as messages related to a topic partition, in a directory that may contain log segment files whose name is the topic partition name and whose contents include several files containing the actual messages and metadata. Log segment files can have a fixed maximum size, for example, 100 MB. When a log segment is full, a new log segment file may be created, and messages are appended to the newly created log segment file. A publish-subscribe system can run a background thread that deletes log segment files, for example, when a message's maximum retention time expires. For compacted topics without a maximum retention time, a compaction process may be used to compact these topics. For example, only the last valid value for a given key may be available in a topic, and keys that map to null values ​​may be removed.

[0075] Similar to so-called log cleaner services, such as the compaction service and expiry service described above, a re-encryption process can be added as an encryption service to a broker in a publish-subscribe system that re-encrypts data in segment files using a new encryption key as a replacement for the current encryption key. As soon as the re-encryption process is initiated, all new messages may be encrypted using the new encryption key. The broker may store an offset value indicating the offset into stored messages at which it will begin using the new encryption key to encrypt new messages. Actual re-encryption of old messages already stored in the publish-subscribe system and encrypted with the old encryption key may then begin. The broker may re-encrypt all old messages, starting from the determined offset value and continuing until it reaches the oldest message and re-encrypts it in the same way. Once the last old message has been re-encrypted, the re-encryption process may end, and the old key may be discarded.

[0076] For example, if the maximum log segment size is 100 MB, a 1 TB topic partition will have 10,000 log segment files of this size. Re-encryption can include decrypting and encrypting all of these segment files. According to embodiments, re-encryption can be performed solely by a single broker, e.g., a leader broker, and the re-encrypted log segment files can be distributed to followers. According to embodiments, re-encryption can be performed by multiple brokers in a publish-subscribe system that implements parallel re-encryption. For example, the internal protocol controlling brokers in a publish-subscribe system can be modified to allow all brokers with replicas of a partition to each re-encrypt some subset of the log segment files composed by the replica and then coordinate among themselves to exchange the re-encrypted segment files with all other brokers with replicas of the same partition.

[0077] Embodiments may have the beneficial effect that parallelizing the re-encryption may only change the interaction between brokers, and clients of the publish-subscribe system may remain unaware that the brokers are performing this. Therefore, such parallelization may be suitable as an optimization in publish-subscribe systems that include the provision of a management server.

[0078] An exemplary algorithm used to re-encrypt a topic using segment files includes the following: TIFF0007737214000001.tif232155

[0079] For example, the computer program product may further include program instructions executable by a processor of a computer system of a publish-subscribe system configured to perform any of the embodiments of the method for encryption key rotation in a publish-subscribe system described herein.

[0080] For example, the computer system may be further configured to perform any of the embodiments of the method for encryption key rotation in a publish-subscribe system described herein.

[0081] 1 illustrates an exemplary computer system 100 configured for encryption key rotation in a publish-subscribe system. The exemplary computer system 100 may be, for example, a broker or proxy in a publish-subscribe system. It will be appreciated that the computer system 100 described herein may be any type of computerized system including multiple processor chips, multiple memory buffer chips, and memory. The computer system 100 may be embodied in the form of a general-purpose digital computer, such as, for example, a personal computer, a workstation, or a minicomputer. The computer system 100 may be implemented in the form of, for example, a server.

[0082] In an exemplary embodiment, from a hardware architecture perspective, as shown in FIG. 1 , computer system 100 includes a processor 105, a memory (main memory) 110 coupled to a memory controller 115, and one or more input / output (I / O) devices (or peripherals) 140, 145 (shown as peripheral storage media) communicatively coupled via a local input / output controller 135. The input / output controller 135 may be, but is not limited to, one or more buses or other wired or wireless connections, as known in the art. The input / output controller 135 may have additional elements, omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communication. Additionally, the local interface may include address, control, or data connections, or a combination thereof, to enable appropriate communication between the aforementioned components.

[0083] Processor 105 is a hardware device for executing software, particularly that stored in memory 110. Processor 105 may be a custom or commercially available processor, a central processing unit (CPU), a coprocessor among multiple processors associated with computer system 100, a semiconductor-based microprocessor (in the form of a microchip or chipset), a microprocessor, or generally any device for executing software instructions.

[0084] The memory 110 may include any or a combination of volatile memory modules (e.g., random access memory (RAM) (e.g., DRAM, SRAM, SDRAM, etc.)) and non-volatile memory modules (e.g., ROM, erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), or programmable read-only memory (PROM)). It should be noted that the memory 110 may have a distributed architecture, in which additional modules are located remotely from one another but may be accessed by the processor 105.

[0085] The software in memory 110 may include one or more separate programs, each of which includes an ordered list of executable instructions for implementing logical functions, particularly functions involved in embodiments of the present disclosure. The executable instructions may further be configured for encryption key rotation in a publish-subscribe system. In particular, the executable instructions may be configured for re-encryption of messages in the publish-subscribe system using, for example, an encryption module provided by computer system 100 in the form of executable instructions. The software in memory 110 may further include a suitable operating system (OS) 111. OS 111 essentially controls the execution of other computer programs, such as software 112, in some cases.

[0086] If computer system 100 is a PC, workstation, intelligent device, etc., the software in memory 110 may further include a basic input / output system (BIOS) 122. The BIOS is a set of essential software routines that initializes and tests hardware at startup, starts OS 111, and supports data transfer between hardware devices. The BIOS is stored in ROM so that it can be executed when computer system 100 starts up.

[0087] When computer system 100 is operating, processor 105 is configured to execute software 112 stored in memory 110, to communicate data to and from memory 110, and to generally control the operation of computer system 100 in accordance with the software. The methods and OS 111 described herein are read by processor 105, possibly buffered within processor 105, and then executed, in whole or in part, but typically the latter.

[0088] Software 112 may further be provided stored on any computer-readable medium, such as storage 120, for use by or in connection with any computer-related system or method. Storage 120 may include disk storage 127, such as HDD storage. Publish-subscribe system messages may be stored on computer system 100 using internal storage, such as storage 120, or peripheral storage, such as storage medium 145. Alternatively, or additionally, publish-subscribe system messages may be stored on another computer system, such as computer system 170, accessible to computer system 100 via a network, such as network 160. Alternatively, or additionally, cryptographic keys used to encrypt and decrypt publish-subscribe system messages may be stored on or accessible to computer system 100.

[0089] For example, a conventional keyboard 150 and mouse 155 may be coupled to the input / output controller 135. Other output devices, such as I / O device 10, may include input devices such as, but not limited to, a printer, scanner, microphone, etc. Finally, I / O devices 140, 145 may further include devices that communicate both input and output, such as, but not limited to, a network interface card (NIC) or modulator / demodulator (for accessing other files, devices, systems, or networks), radio frequency (RF) or other transceivers, telephonic interfaces, bridges, routers, etc. I / O devices 140, 145 may include any generalized cryptographic card or smart card known in the art. Computer system 100 may further include a display controller 125 coupled to a display 130. For example, computer system 100 may further include a network interface for coupling to a network 160, such as an intranet or the Internet. The network may be an IP-based network for communication between computer system 100 and any external servers, other clients, etc., such as computer system 170, via a broadband connection. Computer system 170 may be, for example, a publisher computer system, a subscriber computer system, a broker server such as a cluster of brokers, or a proxy in a publish-subscribe system. Network 160 transmits and receives data, e.g., messages, between computer system 100 and computer system 170. For example, network 160 may be a managed IP network managed by a service provider. Network 160 may also be implemented in a wireless manner, e.g., using wireless protocols and technologies such as Wi-Fi, WiMAX, etc. Network 160 may also be a packet-switched network such as a local area network, a wide area network, a metropolitan area network, the Internet network, or other similar types of network environments.The network may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN), a personal area network (PAN), a virtual private network (VPN), an intranet, or other suitable network system, and includes devices for receiving and transmitting signals.

[0090] 2 illustrates an exemplary publish-subscribe system 200. The publish-subscribe system 200 includes one or more brokers 202 configured to receive messages 204 from one or more producers 206, or publishers, of received messages 204. The messages 204 are assigned to topics 210. The brokers 202 store the returned messages 204 in a message log for the topics 210. Consumers 208, or subscribers, can subscribe to one or more of the topics 210. The messages 204 stored in the topics 210 are forwarded by the brokers 202 to consumers 208 that have subscribed to the respective topics 210.

[0091] The broker 202 configured by the publish-subscribe system 200 may be configured as an encryption broker, including an encryption module. The encryption module may be implemented in the form of an internal component of the encryption broker 202 configured to handle cryptographic operations, such as encrypting and decrypting messages. The encryption broker 202 may encrypt messages 204 received from producers 206, resulting in encrypted messages 205 being stored in a message log for the topic 210 to which the messages 204 are assigned. The encryption broker 202 may further decrypt the encrypted messages 205 stored in the message log for the topic 210 in order to return the original messages 204, i.e., the unencrypted form of the messages, to consumers 208 that have subscribed to the respective topics 210 provided by the publish-subscribe system 200.

[0092] Such a publish-subscribe system 200 uses a publish-subscribe architecture, also known as a publish-subscribe pattern. The publish-subscribe system 200 of a broker 202 can persist all received messages 204 to a file system as a log. Messages 204 are written to and read from categories, so-called topics 210. The publish-subscribe system 200 may provide a massively scalable publish-subscribe message queue designed as a transaction log. For example, multiple brokers 202 may be provided forming a cluster, and the transaction log may be implemented as a distributed transaction log distributed across the cluster.

[0093] Figure 3 illustrates a further exemplary publish-subscribe system 200. The publish-subscribe system 200 of Figure 3 corresponds to the publish-subscribe system 200 of Figure 2, but additionally includes a proxy 203. Clients of the publish-subscribe system 200, i.e., producers 206 and consumers 208, do not communicate directly with the broker 202 of the publish-subscribe system 200, but rather via the proxy 203. Similarly, the broker 202 can communicate with clients 206, 208 via the proxy 203. The proxy 203 may be configured, for example, to implement access control measures for the publish-subscribe system 200.

[0094] FIG. 4 illustrates an example encrypted message broker 202 in more detail. The encrypted message broker 202 includes an encryption module 201. The encryption module 201 is configured to encrypt a message m received from a producer 206 using an encryption key k. Encryption of message m by the encryption module 201 using the encryption key k can result in a ciphertext c=E(k,m), i.e., an encrypted message that is stored in a message log for topic t 210. The encryption module 201 uses an encryption function E to generate the ciphertext c=E(k,m). The message log for topic 210 can include multiple encrypted messages 205 stored in segment files 211. When an encrypted message 205 stored in a segment file 211 for topic t 211 needs to be forwarded to a consumer 208 subscribed to topic t 210, the encrypted message 205 retrieved from storage in the broker 202 is provided to the encryption module 201 in the form of a ciphertext c. The encryption module 201 uses a decryption function D to recover the original unencrypted message m=D(k,c) from the ciphertext c using an encryption key k.

[0095] Embodiments may have the beneficial effect of improving security by enabling rotation of encryption keys. Key rotation may be performed, for example, periodically, as a risk management measure. For example, security regulations may require periodic key rotation. Key rotation may be performed, for example, in response to an incident that calls into question the security of an encryption key in use. Key rotation may involve key replacement, which may involve re-encrypting existing encrypted data with the new key.

[0096] FIG. 5 illustrates a further exemplary publish-subscribe system 200 having a message broker 202 and a proxy 203. Clients 206, 208 of the publish-subscribe system 200 can communicate with the broker 202 through the proxy 203. Similarly, the broker 202 can communicate with clients 206, 208 through the proxy 203. In FIG. 5, the encryption module 201 for encrypting and decrypting messages is configured by the proxy 203. Thus, the proxy 203 may be configured for encrypting and decrypting messages. The proxy 203 may be further configured, for example, to implement access control measures in the publish-subscribe system 200. The proxy may encrypt an incoming message m, resulting in a ciphertext c=E(k,m), which is forwarded by the broker 202 for storage in a topic t 210, and decrypt the ciphertext c, resulting in an outgoing message m=D(k,c), which is forwarded to a consumer 208 subscribed to the topic t.

[0097] Publish-subscribe systems 200 such as those shown in FIGS. 2-5 may be continuously online, i.e., continuously receive and send messages. Such publish-subscribe systems 200 are increasingly being relied upon to store and distribute data within organizations, for example. The following examples may describe key rotation, which allows for the replacement of an encryption key k used by the publish-subscribe system 200 to encrypt and decrypt messages with a replacement key. These examples may have the beneficial effect of enabling effective and efficient re-encryption of large amounts of data, comparable to the amount of data configured by the publish-subscribe system 200. Embodiments may not require taking the publish-subscribe system 200 offline to re-encrypt messages stored by the publish-subscribe system 200. The following describes different approaches for re-encrypting topic data, i.e., topic messages, stored in the broker 202 of the publish-subscribe system 200 without interrupting the publish-subscribe system 200.

[0098] One approach may be based on creating a topic alias that is used to enable re-encryption without disrupting the publish-subscribe system 200. A further approach may be based on extending the broker 202 with a re-encryption service that enables re-encryption without disrupting the publish-subscribe system 200. Either approach may have the beneficial effect of allowing the broker 202 to continue running uninterrupted. Thus, clients 206, 208 of the broker 202 may be unaware of the re-encryption at the broker 202. Furthermore, a proxy 203 may be used for re-encryption. The approach may also have the beneficial effect of preserving message metadata through the re-encryption process.

[0099] FIG. 6 is a schematic flow diagram of an exemplary method for encryption key rotation in a publish-subscribe system, such as the publish-subscribe system 200 of FIG. 4 or FIG. 5. The publish-subscribe system stores a plurality of messages. Each of the stored messages is assigned to a topic from one or more groups of topics. Each of the stored messages is assigned an encryption key from one or more groups of encryption keys and is encrypted with the assigned encryption key. The publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topics to which the routed messages are assigned. Routing includes decrypting the routed messages using each of the messages' assigned encryption key and sending the decrypted messages to one or more of the subscribers of the assigned topics.

[0100] The encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, where each of the first messages is assigned to a common first topic from a group of topics, assigned to a first encryption key from a first set of one or more first encryption keys from the group of encryption keys, and encrypted with the assigned first encryption key, where the re-encryption is performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route the first messages and receive additional first messages from the common first topic.

[0101] In block 300, one or more second encryption keys are added as replacement keys for one or more first encryption keys used to encrypt first messages of the first topic. For example, a single first encryption key may be assigned to the first topic, and all messages assigned to the first copies may be encrypted using the respective single first encryption keys. In this case, for example, a single second encryption key may be added to the first topic to replace a previously used first encryption key. For example, multiple first encryption keys may be assigned to the first topic, and different messages assigned to the first copies may be encrypted using different first encryption keys. In this case, multiple second encryption keys may be added to the first topic, including, for example, replacement keys for each of the previously used first encryption keys.

[0102] At block 302, each of the first messages assigned to the first topic may be decrypted using the first encryption key assigned to each of the first messages. At block 304, each of the decrypted first messages may be re-encrypted using one of the replacement keys added at block 300. For example, the replacement key may be assigned to a first encryption key previously used as a replacement key. At block 306, a replacement key used to re-encrypt the re-encrypted first messages may be assigned to each of the re-encrypted first messages. At block 308, the publish-subscribe system switches from using the encrypted first messages and the assigned first encryption keys for routing to using the re-encrypted first messages and the assigned replacement keys. Additionally, the previously used encrypted first messages and / or the previously used first encryption keys may be deleted.

[0103] FIG. 7 illustrates an exemplary publish-subscribe system 200 that implements encryption key rotation using a topic alias ta 212. To clients 206, 208 of the publish-subscribe system 200, the topic alias ta 212 appears as a normal topic, but is actually an intermediary to another topic t1 210. Messages can be received from producers 206 that are assigned to the topic alias ta 212. The topic alias ta 212 can point to topic t1 210, causing received messages to be further assigned to topic t1 210 and stored in segment files 211 of the message log for topic t1 210. To this end, the received message m can be encrypted using an encryption key k1, e.g., the encryption key k1 assigned to topic t1 210, to generate a ciphertext c1=E(k1,m). This ciphertext c1 can be stored as an encrypted message 205 in the message log for topic t1 210. A consumer 208 can subscribe to topic alias ta212 so that encrypted messages 205 stored in a message log for topic t1 210 are forwarded to the consumer 208. For this purpose, the encrypted message 205 to be forwarded may be read from the message log for topic t1 210 in the form of ciphertext c1 and decrypted to recover the original unencrypted message m=D(k1,c1) from the ciphertext c1 using an encryption key k1. The original unencrypted message m may then be sent by the broker 202 to the consumer 208. For encryption and decryption, the broker 202 may use an encryption module such as that shown in FIG. 4.

[0104] A topic alias, such as topic alias ta212, may be implemented in broker 202 or an additional proxy, as shown in FIG. 11 . A topic alias, such as topic alias ta212, may be integrated with all facilities of broker 202, such as policies, registries, and the like. Such topic aliases may be created and / or deleted by an administrator of broker 202 or a proxy. Furthermore, administrator actions may include attaching and / or detaching a topic alias, such as topic alias ta212, to and / or from a concrete topic, such as topic t1 210. A topic alias attached, or assigned, to a concrete topic is an intermediate pointer that points to the respective concrete topic. When a topic alias is attached to a concrete topic, the respective concrete topic may optionally be hidden from clients of publish-subscribe system 200. Clients, such as producer 206 and consumer 208, may therefore communicate only with the logical, aliased topic, i.e., the topic alias, such as topic alias ta212.

[0105] For example, a publish-subscribe system may only include topic aliases that are assigned to topics. For example, a publish-subscribe system may also include one or more unassigned topic aliases that are not assigned to any topic. Such unassigned topic aliases may be visible to clients but return errors when used to send or receive messages. Alternatively, unassigned topic aliases may be hidden from clients 206, 208 until they are assigned to a topic.

[0106] Re-encryption of encrypted messages 205 stored in the message log for topic t1 210 may be performed by broker 202 using a re-encryption process 214 that runs in the background, such as as a background thread. Re-encryption process 214 may be performed, for example, by an encryption module of broker 202.

[0107] FIG. 8 illustrates a publish-subscribe system 200 that performs re-encryption using a re-encryption process 214. The initial situation for re-encryption may be the configuration shown in FIG. 7. Using a topic alias, such as topic alias ta212, for re-encryption may include providing a topic, such as topic t1210. Each topic t1210 may be created, for example. Further, topic alias ta212 may be provided. Topic alias ta212 may be generated, for example. The provided topic alias ta212 may be assigned to the provided topic t1210. Topic alias ta212 may be configured to encrypt message m received from producer 206, for storage in the message log for topic t1210, for example, using an encryption module of broker 202. Producer 206 may send message m to topic alias ta212. Additionally, topic alias ta212 may be configured to decrypt encrypted messages stored in the message log for topic t1 210, for example, using an encryption module of broker 202, to recover the original message m sent to consumers 208 subscribed to topic alias ta212. Each message m may be encrypted and decrypted using an encryption key k1 assigned to topic t1 210. Clients 206, 208 of publish-subscribe system 200 can begin sending and receiving messages via topic alias ta212.

[0108] Re-encryption may be performed to perform key rotation, i.e., to replace the existing encryption key k1 assigned to the existing topic t1 210 and used to encrypt encrypted messages 205 stored in the message log of the topic t1 210. For example, a re-encryption workflow may be performed that includes adding an additional topic t2 220. Key rotation may be initiated, for example, by creating an additional encryption key k2 for the additional topic t2 220. The encryption module may be updated to encrypt new messages, i.e., messages received by the broker 202 or proxy, using the additional key k2. A re-encryption process for messages 205 stored in the message log of the existing topic t1 210 may be initiated, which includes copying data from the existing topic t1 210 to the additional topic t2 220. The copying includes re-encrypting the copied messages 205 with the additional key k2. For re-encryption, each piece of data configured in an encrypted format by the existing topic may be decrypted using the existing encryption key k1 of the existing topic t1 210 and encrypted using the additional encryption key k2 of the additional topic t2 220. Re-encryption may involve, for example, recovering the original message m = D(k1, c1) using ciphertext c1 and an existing encryption key k1 stored in topic t1 210. The recovered original message may be re-encrypted using additional key k2, and the resulting ciphertext c2 = E(k2, m) may be stored as encrypted message 225 in segment file 221 in the message log for additional topic t2 220.

[0109] The re-encryption process 214 may add new messages m that arrive during re-encryption to the additional topic t2 220. These new messages m are encrypted using the additional encryption key k2 to generate ciphertext c2 = E(k2, m), which is stored in the message log of the additional topic t2 220. Once the copying is complete, the topic alias ta212 may be reassigned to the additional topic t2 220. The additional topic t2 220 may contain the re-encrypted data copied from the existing topic t1 210 and the new messages encrypted with the additional encryption key k2. As a result, the existing topic t1 210 may become inactive, and the additional topic t2 220 may become active. Optionally, as shown in Figure 9, the previously active topic log, i.e., the message log of the existing topic t1 210, may be deleted, resulting in the situation shown in Figure 10. The creation of the additional topic t2 220 and the switch from the existing topic t1 210 to the additional topic t2 220 may be invisible to clients 206, 208 of the publish-subscribe system 200. The clients 206, 208 can continue to communicate with the topic alias ta212. The message m received from the producer 206 may be encrypted using the additional encryption key k2 to generate a ciphertext c2 = E(k2, m) and stored as an encrypted message 225 in the message log for the additional topic t2 220. Furthermore, the encrypted message 225 stored in the message log for the additional topic t2 220 can be decrypted using the additional encryption key k2 to recover the original message m = D(k2, c2) and sent to consumers 208 subscribed to the topic alias ta212. During the entire execution of the re-encryption process 214 , the publish-subscribe system 200 may continue to perform its services, namely, receiving messages m from producers 206 and forwarding the received messages m to consumers 208 .

[0110] 11, 12, and 13 show alternative embodiments to FIGS. 7, 8, and 10, respectively, in which the topic alias ta 212 and re-encryption process 214 are implemented in the proxy 203 instead of the broker 202.

[0111] FIG. 14 is a schematic flow diagram of an exemplary method for encryption key rotation in a publish-subscribe system, such as the publish-subscribe system 200 of FIGS. 7-13. The method of FIG. 14 corresponds to the method of FIG. 6 and is adapted to use a topic alias for encryption key rotation. The topic alias points from a first message to a first topic. Subscribers to the common first topic subscribe to the first topic alias. Furthermore, a publisher, i.e., a producer, sending a message can assign the message to the first topic alias. Messages assigned to the first topic alias may be automatically reassigned to the common first topic.

[0112] At block 320, an additional common second topic may be added. Blocks 322 through 328 may correspond to blocks 300 through 306 of FIG. 6. At block 330, the re-encrypted message is stored in a message log for the additional common second topic added at block 320. At block 332, the publish-subscribe system may switch from using the encrypted first message and the assigned first encryption key for routing to using the re-encrypted first message and the assigned replacement key. Switching may include reassigning a topic alias from the common first topic containing the encrypted first message to the common second topic containing the re-encrypted first message. Additionally, the previously used encrypted first message, the previously used first encryption key, or both may be deleted. Deleting may include, for example, deleting the common first topic.

[0113] Figure 15 is a schematic block diagram illustrating an alternative implementation of re-encryption using a broker re-encryption service. The broker re-encryption service may be implemented in the broker 202, as shown in Figure 4. The broker re-encryption service may not involve topic aliases, but rather extend topic management within the broker 202, such as the management of topic t 210. For example, the broker's log cleaner service, which performs compaction and handles expiration via a background thread, may be extended to include re-encryption functionality to provide the re-encryption service.

[0114] Topic t 210 may consist of multiple partitions, each consisting of multiple segment files 211. A write operation to add an additional message, i.e., a new message, to topic t 210 may involve adding the additional message to the last open segment file 211, e.g., segment file "segment 3." Closed segment files may only be swapped or deleted by a log cleaner service, e.g., when the maximum retention time for messages stored in the respective segment file expires.

[0115] The re-encryption workflow by the broker re-encryption service may include issuing a command to re-encrypt an existing topic encrypted with a first encryption key with a second, or new, encryption key. In response to issuing the command, a re-encryption process may be initiated. The re-encryption process may be implemented as a background thread. New incoming messages may be encrypted using the second key. The broker 202 may close the current segment file "Segment 3" and open a new segment file 222 "Segment 4." The broker 202 may further determine and store an offset value of the message at which encryption using the second key has begun.

[0116] Re-encryption of previously received messages, i.e., messages stored in closed segment files 211 "Segment 1," "Segment 2," and "Segment 3," may be initiated by a background thread. All previous messages starting at the determined offset, i.e., all messages encrypted with the previous encryption key, may be re-encrypted, for example, file-by-file. For example, re-encryption may start with the most recent segment file 211 "Segment 3." Once segment file 211 "Segment 3" is re-encrypted, i.e., decrypted using the previous first encryption key and encrypted using the current second encryption key, the resulting re-encrypted segment file 221 "Segment 3" is swapped with the previous segment file 211 "Segment 3." For example, previous segment files 211 "Segment 2" and "Segment 3," containing messages encrypted using the previous encryption key, may be replaced with re-encrypted segment files 221 "Segment 2'" and "Segment 3'," containing the same messages as the previous segment files 211 "Segment 2" and "Segment 3" but re-encrypted using the current second encryption key. When the last message in the last segment file 211, e.g., the oldest segment file "Segment 2," is re-encrypted, the re-encryption process ends, and the previous first encryption key may be discarded. For example, segment file "Segment 1" may be deleted during key rotation because the maximum retention time for messages comprised by each segment file "Segment 1" has elapsed. Therefore, by starting re-encryption from the latest "Segment 3," the publish-subscribe system can prevent unnecessary re-encryption of segment files, such as "Segment 1," that are deleted during key rotation.

[0117] Re-encryption using the re-encryption service on broker 202, as illustrated in FIG. 15, may be optimized by implementing parallelization. The re-encryption workload may be parallelized, i.e., distributed across multiple brokers in a cluster of brokers configured by a publish-subscribe system. This may have the beneficial effect of increasing, e.g., optimizing, the re-encryption speed. A publish-subscribe system may include multiple brokers. The internal protocol of the publish-subscribe system may be adjusted so that all brokers in the publish-subscribe system that have replicas of a partition can coordinate among themselves to re-encrypt only some subset of the segment fields of their respective partitions. Each broker then exchanges the re-encrypted subset of segment fields with all other brokers that have replicas.

[0118] Figure 16 is a schematic flow diagram of an exemplary method for encryption key rotation in a publish-subscribe system, such as the publish-subscribe system 200 of Figures 7-13. The method of Figure 16 corresponds to the method of Figure 6 and is adapted to use a re-encryption service provided by a broker in the publish-subscribe system. Segment files may be used to store messages. When a segment file is full, storage continues using subsequent segment files.

[0119] At block 340, the segment file currently being used to store the message is closed, and at block 342, an additional segment file is opened for message storage. The message stored in the additional segment file is encrypted using a replacement key provided at block 346. For example, the replacement key may be provided before any of blocks 340, 342, or 344. At block 344, an offset value identifying an offset at which storage of the message encrypted with the replacement key begins may be determined, e.g., stored. Blocks 346 through 352 may correspond to blocks 300 through 306 of FIG. 6. Re-encrypting the message in the segment file may result in a re-encrypted segment file. At block 354, the stored segment file may be replaced with the re-encrypted segment file. For example, re-encryption may start with the most recently stored segment file and end when the oldest remaining stored segment file is reached and re-encrypted.

[0120] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0121] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, by way of example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, mechanically encoded devices having instructions recorded on punch cards or ridge-in-groove structures, or the like, and suitable combinations thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0122] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0123] Computer-readable program instructions for carrying out operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, as a standalone software package, or partially on the user's computer. Alternatively, the computer may be executed partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the computer-readable program instructions in order to carry out aspects of the present invention.

[0124] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0125] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored in a computer-readable storage medium connectable to a computer, programmable data processing apparatus, or other device, or combination thereof, that functions in a particular way, such that the computer-readable program medium having the instructions stored thereon constitutes one of the products including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0126] Computer-readable program instructions, such as instructions to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams on a computer, other programmable apparatus, or other device, can also be loaded into a computer, other programmable data processing apparatus, or other device to perform a series of operational steps on the computer, other programmable apparatus, or other device to produce a computer-implemented process.

[0127] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of executable implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which constitute one or more executable instructions for implementing the specified logical function(s). In some alternative embodiments, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0128] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0129] The characteristics are as follows:

[0130] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0131] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0132] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, resulting in a sense of location independence. However, consumers may be able to determine location at a higher level of abstraction (e.g., country, state, data center).

[0133] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly release to instantly scale in. To the consumer, the computing power available for provisioning often appears unlimited, and can be purchased at any time and in any quantity.

[0134] Metered Services: Cloud systems leverage measurement capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0135] The service model is as follows:

[0136] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functionality, except for limited user-specific application configuration settings.

[0137] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0138] Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating systems, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0139] The deployment model is as follows:

[0140] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0141] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0142] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0143] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0144] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0145] Referring to FIG. 17, a cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N shown in FIG. 17 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0146] Referring to Figure 18, a set of functional abstraction model layers provided by cloud computing environment 50 (Figure 17) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 18 are merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0147] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0148] The virtualization layer 70 provides an abstraction layer from which the following virtual entities can be provided, for example: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0149] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment; Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources; By way of example, these resources may include application software licenses; Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources; User portal 83 provides consumers and system administrators with access to the cloud computing environment; Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met; Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0150] The workload layer 90 provides examples of functionality available to a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and publish-subscribe systems 96.

Claims

1. 1. A method for encryption key rotation in a publish-subscribe system, comprising: the publish-subscribe system stores a plurality of messages, each of the stored messages being assigned to a topic from a group of topics, each of the stored messages being assigned to an encryption key from one or more groups of encryption keys and being encrypted with the assigned encryption key; the publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topic to which the routed messages are assigned, the routing including decrypting the routed messages using the assigned encryption key for each of the messages and sending the decrypted messages to one or more of the subscribers of the assigned topic; the encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, each of the first messages being assigned to a common first topic from the group of topics, assigned to a first encryption key of a first set of one or more first encryption keys of the group of encryption keys, and encrypted with the assigned first encryption key, the re-encryption being performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route first messages and receive additional first messages from the common first topic; The re-encryption adding a second set of one or more second encryption keys to the group of encryption keys, each of the second encryption keys being a replacement key for one of the first encryption keys; for each of the first messages: decrypting the encrypted first messages using the first encryption key assigned to each of the first messages; re-encrypting the decrypted first message using the substitution key for the assigned first encryption key; assigning the replacement key to be used for the re-encrypted first message; switching from using the encrypted first message and the assigned first encryption key for routing to using the re-encrypted first message and an assigned replacement key. method.

2. The method of claim 1 , wherein the encryption module is configured by a broker in the publish-subscribe system.

3. 2. The method of claim 1, wherein the encryption module comprises a proxy for the publish-subscribe system through which a broker for the publish-subscribe system communicates with a client for the publish-subscribe system.

4. The method of claim 1 , wherein the stored messages each comprise a header identifying the assigned encryption key of the group of encryption keys.

5. 5. The method of claim 4, wherein the header identifying the assigned encryption key is stripped during routing before sending the routed and decrypted message to the subscriber.

6. The decryption of each of the encrypted first messages further includes decrypting the assigned first encryption key provided by the header of each of the first messages using an envelope encryption key; The re-encryption of each of the decrypted first messages includes encrypting the assigned replacement key used to re-encrypt each of the re-encrypted first messages with the envelope encryption key, and replacing the first encryption key in a header of each of the re-encrypted first messages with the encrypted replacement key; The method of claim 4 further comprising:

7. 2. The method of claim 1, wherein the publish-subscribe system includes, for each of the stored messages, an index that identifies the assigned encryption key of the group of encryption keys.

8. The re-encryption includes, for each of the first messages: using the index to identify the first encryption key assigned to each of the first messages; assigning the replacement key for the first encryption key identified in the index to the re-encrypted first message; The method of claim 7 further comprising:

9. Each of the stored messages is stored as a member of the topic to which each of the messages is assigned, and the method further comprises: providing a first topic alias from the first set of messages that points to the common first topic, wherein the one or more subscribers of the common first topic subscribe to the first topic alias; adding an additional common second topic to said group of topics; storing the re-encrypted first message as a member of the common second topic, wherein the switching comprises reassigning the first topic alias to the common second topic such that the one or more subscribers subscribed to the first topic alias become subscribers to the common second topic; The method of claim 1 , comprising:

10. The method of claim 9 , wherein the switching further comprises deleting the common first topic with the encrypted first message.

11. The method of claim 9 , wherein the switching further comprises deleting the first encryption key.

12. 10. The method of claim 9, wherein additional first messages received by the publish-subscribe system from publishers for each of the first topic aliases are assigned to the common second topic, assigned to one of the second set of second encryption keys, and encrypted using the assigned second encryption key.

13. 2. The method of claim 1, wherein the switching from the encrypted first messages with the assigned first encryption key to the re-encrypted first messages with the assigned replacement key includes replacing each of the encrypted first messages with a corresponding re-encrypted first message.

14. the encrypted first message is stored in a set of segment files, one segment file of the set of segment files is currently used to store the encrypted first message, remaining segment files of the set of segment files already filled with the encrypted first message are closed, and when an open segment file becomes full, the open segment file is closed and an additional segment file is added to the set of segment files and the additional segment file is used to store the encrypted first message; upon initiating the re-encryption, the segment file currently being used to store the encrypted first message is closed, and an additional segment file is added to the set of segment files to be used to store additional encrypted first messages received by the publish-subscribe system from publishers on the common first topic; the re-encryption of the encrypted first message is performed segment-wise, the segment-wise re-encryption comprising: selecting, in succession, remaining closed segment files; generating, for each of the selected segment files, a replacement segment file containing, in encrypted form, the encrypted first message of the selected segment file; and replacing the selected segment file with the replacement segment file. The method of claim 13.

15. The method of claim 14 , wherein the segmental re-encryption begins with the most recent segment file of the set of segment files.

16. 15. The method of claim 14, wherein an offset value is determined that identifies an offset of an additional first message in storage of a publish-subscribe system at which the encryption using the second encryption key begins.

17. 15. The method of claim 14, wherein each additional first message received by the publish-subscribe system from the publisher for the common first topic is assigned to the common first topic, assigned to one of the second set of second encryption keys, and encrypted using the assigned second encryption key.

18. 15. The method of claim 14, wherein the publish-subscribe system includes a plurality of additional brokers, the publish-subscribe system includes a plurality of additional replicas of the set of segment files, each of the additional replicas being assigned to one of the additional brokers, the re-encryption of the segment files being distributed among brokers of the publish-subscribe system that perform the parallelization of the re-encryption, and re-encrypted first messages being distributed to other replicas of the set of segment files.

19. 1. A computer program product for encryption key rotation in a publish-subscribe system, the computer program product comprising: a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor of a computer system of a publish-subscribe system to cause the computer system to perform the encryption key rotation; the publish-subscribe system stores a plurality of messages, each of the stored messages being assigned to a topic from a group of topics, each of the stored messages being assigned to an encryption key from one or more groups of encryption keys and being encrypted with the assigned encryption key; the publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topic to which the routed messages are assigned, the routing including decrypting the routed messages using the assigned encryption key for each of the messages and sending the decrypted messages to one or more of the subscribers of the assigned topic; the encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, each of the first messages being assigned to a common first topic from the group of topics, assigned to a first encryption key of a first set of one or more first encryption keys of the group of encryption keys, and encrypted with the assigned first encryption key, the re-encryption being performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route first messages and receive additional first messages from the common first topic; The re-encryption adding a second set of one or more second encryption keys to the group of encryption keys, each of the second encryption keys being a replacement key for one of the first encryption keys; for each of the first messages: decrypting the encrypted first messages using the first encryption key assigned to each of the first messages; re-encrypting the decrypted first message using the substitution key for the assigned first encryption key; assigning the replacement key to be used for the re-encrypted first message; switching from using the encrypted first message and the assigned first encryption key for routing to using the re-encrypted first message and an assigned replacement key. Computer program products.

20. 1. A computer system for encryption key rotation in a publish-subscribe system, comprising: the publish-subscribe system stores a plurality of messages, each of the stored messages being assigned to a topic from a group of topics, each of the stored messages being assigned to an encryption key from one or more groups of encryption keys and being encrypted with the assigned encryption key; the publish-subscribe system provides a broker service for routing the stored messages to one or more subscribers of the topic to which the routed messages are assigned, the routing including decrypting the routed messages using the assigned encryption key for each of the messages and sending the decrypted messages to one or more of the subscribers of the assigned topic; the encryption key rotation includes re-encrypting each message of a first set of one or more first messages of the stored messages, each of the first messages being assigned to a common first topic from the group of topics, assigned to a first encryption key of a first set of one or more first encryption keys of the group of encryption keys, and encrypted with the assigned first encryption key, the re-encryption being performed by an encryption module of the publish-subscribe system as a background process while the broker service continues to route first messages and receive additional first messages from the common first topic; The computer system includes a processor and a memory storing program instructions executable by the processor, wherein execution of the program instructions by the processor causes the computer system to perform the re-encryption, the re-encryption comprising: adding a second set of one or more second encryption keys to the group of encryption keys, each of the second encryption keys being a replacement key for one of the first encryption keys; for each of the first messages: decrypting the encrypted first messages using the first encryption key assigned to each of the first messages; re-encrypting the decrypted first message using the substitution key for the assigned first encryption key; assigning the replacement key to be used for the re-encrypted first message; switching from using the encrypted first message and the assigned first encryption key for routing to using the re-encrypted first message and an assigned replacement key. Computer system.

Images