Updating Sender-Keys and Key-Management

Question

This question is related to an earlier question I had: Encryption on Mobile Devices - Multiparty Encryption - Key Management

My situation: I have many mobile devices that want to send sensitive information to different clients by passing by the back-office which stores this information for some time. As described in the answer of my question I want to use sender keys to encrypt this sensitive information and make it accessible only for the clients. Since the communication is one-directional I have an easier key-management.

However, I am not sure if my idea of the protocol and the key updating is secure.

For simplicity let's only look at one mobile device A communicating with different clients C1, C2, ..., Cn.

Source : https://signal.org/blog/private-groups/

For the Setup: the back-office B passes the clients' public keys to A. Then, A generates a sender-key sk and encrypts it with each of the Ci's public keys. The Ci can decrypt and retrieve sk.

Then, when A want's to send sensitive information he encrypts it with the symmetric sk and sends it to B that stores it for some time without being able to access the information. Then B sends the encrypted information to the corresponding Ci.

To update the key sk

1st idea: A sends along with the message some update information. If a new member joins the group, we just have to send him the secret key sk encrypted with his public key.
If a member leaves the group, he will not receive the key update-information.

2nd idea: use a similar procedure as in the double-ratchet algorithm. A sends a secret k along with a root-key to the clients (encrypted with their public key). Then, we do a ratchet step deriving a chain-key from the secret k and the root key. Then, for each message a symmetric-key ratchet deriving a symmetric key from the chain key. This way, if a member leaves the group we send a new secret k to all the current members and derive a new chain-key. For a new member we send the current root-key to the new member and a new secret k to all group members.

Questions:
1) How expensive is the setup for many Ci?
2) Can the update information be sent unencrypted?
3) Does it suffice, if a member leaves the group, to just not send him the update information, or do I have to redo a key set-up with all the current members?
4) When we have many mobile devices A, all the clients need to store many secret keys sk. Might this be a problem? Since, if one of the Ci stores the keys insecurely they are corrupted for all the other Ci.

Answer 1

There is a potential man in the middle attack by the server (B) in your model. Server can give mobile (A) its own public key as if it is coming from a client and it can give its own symmetric key (sk) to the clients as if it is coming from you. You need to implement out of band end-to-end authentication for the clients in other to authenticate A where server is not a medium.

If the server is controlled by A itself then end to end encryption becomes optional.

About your 1st idea, that's the way it has to be implemented as WhatsApp group management does. So it's not an option. It's necessary.

There's no problem in using symmetric ratchet except that it only provides perfect forward secrecy and there is no future secrecy. It means if current chain key gets compromised, the entire future chain is now predictable and future messages can now be decrypted. The threat actor just have to compromise one client. This is also a problem with WhatsApp group messaging.

If a member leaves the group we send a new secret k to all the current members and derive a new chain-key.

You also have to generate a new root key else it is considered compromised when someone leaves. The root key is basically a seed value here.

Why are you using root key to initialise the chain? In symmetric ratchet, the chain can be initialised by first chain key itself using HKDF. Clients only need to know the first chain key sent by you.

You also have to digitally sign the messages to prove that it is indeed you who sent the messages and not a malicious client producing fraudulent messages. Public key to verify the signature can be obtained from B.

1. It's not really expensive as the actual load is carried by the server. You send one message and the server sends multiple copies of it.

2. It breaks end to end if you share keys unencrypted.

3. You and your clients have to clear all the existing keys once a client leaves else they are considered compromised. Both root key and chain key.

4. When we have many mobile devices A, all the clients need to store many secret keys sk. If one of the Ci stores the keys insecurely they are corrupted for all the other Ci.

And that's why imposing a group limit in multiparty encryption is important. Group management with large groups become very difficult. One compromised client in your case can expose all the keys along with the future chain attacker needs to know. The key exchange also becomes quite lengthy when someone leaves. For mobile devices A, lengthy key exchange is a problem.

What you can do is to associate limited number of clients with A1 (say 500) where A1 is the admin. Another 500 with A2 and so on. But don't merge them with each other else each client in the network becomes a single point of failure for every other client. Clients can also act malicious so one of them can intentionally release the keys in public but then the group is compromised anyway without involving the outsider.

It's not recommended to roll out your own implementation, see Why is it wrong to implement myself a known, published, widely believed to be secure crypto algorithm? But what you are implementing is already in use. What you need is a proper group management to exchange keys.