Sharing a secret key between many users

Question

I would like to know if there is any security issue in sharing a secret key (of an asymmetric cryptography) between several users.

I know that this secret key is no longer "secret", so it's no longer valid for signature.

The advantage of doing that is to allow a user to send a message to many others (all those sharing the secret key) at a time by encrypting it with the corresponding public key.

But I don't know if this will induce security problems.

Answer 1

Writing this as a serpate answer, but it goes along fgrieu's one

Key management, and specifically storing keys securely, is one of the harder tasks in the security field. By the principle "security is as strong as the weakest link", handing out private keys to multiple parties is a bad idea - an attacker wins as soon as he corrupts the most insecure device.

The advantage is, that you only have to encrypt something once in a multicast setting. However, this can also be achieved by hybrid encryption (as fgrieu already noted) very easily: Use a symmetric scheme with a randomly generated key to encrypt your data. You upload or broadcast this just once. And for each user you send this symmetric key encrypted with their own public key.

Especially with larger amounts of data, hybrid encryption is very efficient, because symmetric encryption is a lot faster than public key encryption (and depending on the scheme, even more so for decryption). The overhead for each user is quite low, as it only takes a single message of a few hundred bytes (e.g. RSA requires 150 byte (1200 bit) to 512 byte (4096 bit), and some additional overhead with user ID, etc.)

Answer 2

The only security issues that I can think of when sharing the same key among several users (in an asymmetric encryption system used to broadcast messages) are:

• We can't revoke a single user without impacting all the others.
• We loose the flexibility to encipher to an arbitrary set of users (which, for large messages and when using hybrid encryption, has moderate overhead).
• If the key is determined to have leaked to someone not authorized, we no longer know from which user (or user's device) it has leaked from.
• If the ability to decipher messages is determined to be available to someone not authorized, we can no longer selectively disable users to try to determine which user (or user's device) is involved in the leak.
• If extracting the key form one device requires making a large number of experiments, and that's practically not possible to an adversary (due to a usage counter, or the time required, or because the experiments are destructive), an adversary in a position to use multiple devices with the same key is in a better position than if each device had a unique key. This is an issue in side-channel protection of Smart Card (where resistance is quantified in number of power traces allowing to recover the key), and some fault-attacks that similarly require many experiments. As an extreme example, if an adversary could force any chosen key bit to 0 or 1, and when that has changed the key the device self-destructs together with all the key bits, and the adversary can find that, then there is a simple attack finding about $2n$ bits of the key shared by $n$ devices, when there is no threatening attack to any individual device.

Answer 3

Expanding further on tylo's point regarding key management: when a user leaves the group, there is a need to create a new group key and distribute that to the remaining members.

The most basic way to do this is for the server to first establish a session key with each user via a Diffie-Hellman or RSA key exchange in a manner similar to TLS, then use each user's session key to encrypt the group key. In the event the group key needs to change, the server encrypts the new group key with each user's session key. Because n-1 rekey operations are required, where n is the number of users, this is not scalable in the context of large groups or frequent member changes. This can be mitigated with the use of auxiliary keys.

A common way on managing auxiliary keys is to arrange them in a tree structure, with the group key at the top and the users at the bottom, where each user holds the keys at its own node and all ancestor nodes. At the time a user joins the group, the server uses the user's session key to send it the auxiliary keys in addition to the group key.

In the case of a binary tree, a total of $2n-1$ keys are generated (one for each node), and each user holds $\log_2n+1$ keys. So when a user leaves the group, only $\log_2n$ keys need to be regenerated. This is described in more detail in this paper.

A more recent advancement involves using an m-ary tree where each level of the tree (other than the root, which is the group key) only contains m keys, and the total number of keys is $m\log_mn + n + 1$ (in this case, the individual session keys are not part of the tree). Besides each user only needing $\log_mn$ keys, it reduces the total number of rekeying operations in the event of multiple users leaving the group at once.