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 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

Ideally the following requirements would be covered by the proposed solution:

  • Every channel has its own encryption and decryption keys
  • The decryption key is only available to users which have been granted access to the channel
  • The keys can be rotated if the list of users with access changes
  • It shall be possible to decouple the decryption effort from the message delivery system in order to avoid penalizing the message throughput performance
  • 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

Encryption scheme

Each channel gets a unique Key-Pair which is used to encrypt and decrypt the messages on it. The private key is given to the subscribers of the channel only. The key pair is created by the KMS on behalf of the Message Broker. The Message Broker does not get access to the keys at any time.

Creating a broadcast channel

The sequence of events (checks for channel existance and authorisation are left out) to creating a channel and broadcasting a message on it is:

sequenceDiagram participant alice as Alice participant msg as Messaging<br/>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. Checks for channel existance and authorisation are left out

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. In such a case, a new key pair is created. The Message Broker might not be aware of such a change as it happens without its involvement.

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:

sequenceDiagram participant bob as Bob participant msg as Messaging Service participant km as Key Manager note over bob, msg: Bob has authenticated and hence<br/>provided his public key pkB bob ->> msg: subscribe to channel C msg ->> km: request access to the encryption key<br>for the channel on behalf of Bob km ->> km: verify that Bob has access to the channel km ->> km: encrypt private key with Bob's public key km -->> msg: return encrypted private key for the channel msg -->> bob: return encrypted private key for the channel msg ->> bob: new message on channel C bob ->> bob: decrypt message with channel private key

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.

When a subscriber requests a private 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. The channel creator must have the role channel-creator. roles.dmq.apps.energyweb.iam.ewc.

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 should not be possible for anyone, except the key-manager service, to access a channel's secret.

If a key pair can not be created without an owner, then the account which created the application the channel belongs to can act as the owner.

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 EW-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.