We're building a data service that is expected to go out through a single "fat pipe" channel. The design requirement says that the data in the channel must be protected by authentication and encryption. I'm ready to argue that the strongest encryption for such a system (single channel, multiple subscribers) is the "cable box" method - a single key for all subscribers.

Is there a more secure method than this - one that doesn't have the same key for every subscriber?

What's the security goal behind having multiple keys? So that we can encrypt data that can be decrypted by a specific subset of the subscribers (e.g. Alice can decrypt it, but Bob can't, even though both Alice and Bob are both subscribers)? Alternatively, is it so that you can do traitor-tracing (that is, if someone leaks his key, we can figure out who that is)?
–
ponchoMay 14 '13 at 16:17

It's so that we can retire keys - Bob can listen today, but not tomorrow without disrupting Alice's ability to keep listening.
–
Yes - that Jake.May 14 '13 at 16:38

1 Answer
1

I'm assuming your broadcast stream is (or can be) somehow broken up in smaller messages (or "packets"), and you don't need to retire a key before a message is finished.

Then you produce a random session key for each message, and encrypt this session key with each of the subscribers' keys, prepend them (together with some tagging) to the message.

Each subscriber than filters the header for his section, decrypt the session key and then can decrypt the whole message.

This gives some overhead proportional to the number of subscribers for each message, so it works better when the messages are large enough and the number of subscribers is low. On the other hand, if subscribers can switch on at every time, you'll want to have the message size small so they don't have to wait long until the next session key comes around.

The OpenPGP protocol includes this feature, and is commonly used for sending encrypted emails to multiple receivers. I suppose S/MIME does it similarly.

This method works both with symmetric long-term keys as well as with asymmetric key pairs for encryption (such as RSA or ElGamal).

If you have a "normal" directed communication method in addition to your broadcasting channel, you could also send each subscriber the session key (encrypted with his key) directly, without the bandwith overhead for all the other subscribers.

There might be some more fancy method of encrypting a session key to more receivers without the linear bandwith growth, but I know of none. (1-of-n secret sharing or such?)

Well what you would be looking for is a (aptly named) broadcast encryption scheme. I think the notion was first introduced by Fiat and Naor at CRYPTO 93 (Broadcast Encryption") but I do not know what the current state of the art is.
–
MaeherMay 14 '13 at 20:29

Note that the method given in this answer does not offer the receivers any $\hspace{1.43 in}$ assurance that they won't get different messages. $\:$
–
Ricky DemerMay 14 '13 at 20:43

I welcome alternative answers which elaborate on the notion of a broadcast encryption scheme. I didn't know the term until now, and just wrote the "solution" I knew about. (@Maeher and everyone else.)
–
Paŭlo EbermannMay 15 '13 at 18:07

@RickyDemer I suppose you should have a MAC to the part encrypted with the session key (using the same session key or something derived from it). Then you either have a failed MAC (when using a wrong key) or the same ciphertext and key, and thus the same plaintext. Do you have a better scheme which allows more guarantees?
–
Paŭlo EbermannMay 15 '13 at 18:10

@PaŭloEbermann From an efficiency standpoint, it would probably be a disaster to use an actual broadcast-encryption scheme to stream large amounts of data. I was more thinking of a broadcast-encryption scheme as a solution to the problem you highlighted in your last paragraph.
–
MaeherMay 15 '13 at 18:21