--- tags: messaging, specification --- # Privacy preserving broadcast pub-sub When sending messages to a specific recipient, the sender has the ability to encrypt the payload with the recipient's public key and make sure that only the holder of the associated private key can decrypt it. This is more challenging in a broadcast setup (e.g. RabbitMQ, Waku, Nats) in which the sender has no control over the list of subscribers and should not have to care. In addition to the problem of listing active subscribers, a broadcast channel should have the ability to replay messages, making it impossible to know in advance who will read the messages. ## Broadcast channel privacy challenges The following requirements have to be covered by the proposed solution: * Each subscriber shall have their own decryption key which must be used in conjunction with their private key. This removes the ability of the subscriber sharing the key with other participants. * The decription key shall be linked to the subscriber's identity to make it more onerous to share. If you share the decription key, you give access to your identity. * It shall be possible to decouple the decryption effort from the message delivery system in order to avoid penalizing the message throughput performance * The decryption key must only be usable in conjunction with the recipient's secret key * It must be possible to generate a decryption key without the necessity to share the recipient's secret key * The messaging service shall never gain access to message content ## Proposed encryption scheme We propose to use a proxy re-encryption scheme to achieve the above requirements. The proxy re-encryption comes at the cost of additional computing resources to achieve the desired security, as it is necessary to re-encrypt every message for the specific subscriber. ### How it works ![taken from the NuCypher website](https://i.imgur.com/U8WB0hz.png) [origin: NuCypher](https://www.nucypher.com/proxy-re-encryption) This diagram should be interpreted as follows: * Alice encrypts a message `m` with the public key `pkA` and produces the cyphertext `CA` * Alice creates a re-encryption key `rkA->B` by running the `createReEncryptionKey` function with parameters `skA` and `pkB` * The re-encryption key can be applied to the cyphertext `CA` to transform it into `CB` which is still a cyphertext but which can be decrypted with the secret `skB` controlled by Bob * Bob is now able to decrypt the cyphertext `CB` with his own secret key `skB` ### Generalization for the message broadcast use-case In the message broadcast use-case, we can generalize the case by introducing `Key Manager` which manages the message encryption key. #### Creating a broadcast channel The sequence of events to creating a channel and broadcasting a message on it is: ```mermaid sequenceDiagram participant alice as Alice participant msg as Messaging Service participant km as Key Manager alice ->> msg: create channel C msg ->> km: channel key pair creation km -->> msg: channel public key pkC msg -->> alice: channel public key pkC alice ->> alice: encrypt message with pkC alice ->> msg: broadcast encrypted message ``` #### Publishing a message on a broadcast channel Subsequent uses of the channel replace the creation with a query for the public key. This step is required because the public key for the channel might need to change in response of external events such as the revocation of access rights. ```mermaid sequenceDiagram participant alice as Alice participant msg as Messaging Service participant km as Key Manager alice ->> msg: get public key for channel C msg ->> km: request channel public key km -->> msg: channel public key pkC msg -->> alice: channel public key pkC alice ->> alice: encrypt message with pkC alice ->> msg: broadcast encrypted message ``` #### Subscribing to a broadcast channel Once the channel exists, users can subscribe to it: ```mermaid sequenceDiagram participant bob as Bob participant msg as Messaging Service participant km as Key Manager note over bob, km: Bob has authenticated and hence provided his public key pkB bob ->> msg: subscribe to channel C msg ->> km: request re-encryption key for pkC to pkB km ->> km: compute re-encryption key rkB km -->> msg: return rkB msg -->> bob: return rkB msg ->> bob: new message on channel C bob ->> bob: re-encrypt message with rkB bob ->> bob: decrypt with skB ``` ## Permission verification In order for this scheme to work, the Key Manager must be able to verify the roles of the participants before doing work or giving access to information. The Key Manager must receive the signed login information from the messaging server. The information required to grant permission is the list of roles the user claims to have and access to the claim data in order to verify their correctness. The format this is provided in is a Verifiable Presentation. When a subscriber requests a re-encryption key, the Key Manager must first check that the user is permitted to perform this action. This can be done by getting the channel description from the messaging server. The channel description should be signed by the creator of the channel. ### Channel key management The key-pair which is generated for a channel is held outside of any account. It does not belong to any one user but to the messaging application. It must not be possible for anyone, except the key-manager service, to access a channel's secret. This can be achieved by implementationg the KeyManager as a decentralised AppNet which uses Decentralised Key Generation (DKG) to generate the keys and MPC to perform the cryptographic operations. Thus making sure that no single party ever gains access to the information on its own and colusion is always necessary. ## Custom key manager > As a channel creator I want to be able to specify a custom key manager server in order to guarantee the privacy of my data in a trustless manner The Decentralised-Messaging application defines a default key manager service which can be used by anyone. In order to allow organisations to use the messaging service as a transport mechanism which they control entirely, it must be possible to define a custom key manager for each channel. The linked key manager must fulfill the following requirements in order for the messaging server to be able to use it: * expose the same API as the default key manager * be publicly accessible in order to allow any messaging node to communicate with it Publishing a message on a channel with a custom key manager does not require any change in the sequence of events to publishing or subscription.