Skip to main content
replaced http://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

The system above is precisely what OpenPGPOpenPGP describes (see GnuPG for an opensource implementation). This was meant for secure emailing, but it works regardless of the actual transport medium, which could be a shared storage area.

The system above is precisely what OpenPGP describes (see GnuPG for an opensource implementation). This was meant for secure emailing, but it works regardless of the actual transport medium, which could be a shared storage area.

The system above is precisely what OpenPGP describes (see GnuPG for an opensource implementation). This was meant for secure emailing, but it works regardless of the actual transport medium, which could be a shared storage area.

Source Link
Thomas Pornin
  • 328.6k
  • 60
  • 800
  • 969

As @AviD points out, "secure" is a wide term, and there are several properties which can thus be called. Here, I will concentrate on confidentiality.

So you want some people to share some documents, which must remain unreadable for people out of that group, and such that you could afterwards add or remove some people to the group. One point to note is that, conceptually, you cannot force people to become amnesiac; hence, if a member of the group could read a document at some point, then he perfectly could have kept a copy somewhere. Therefore, revoking access of a user is about not making new documents readable by that user; for old documents, this is "too late". Given that point, a possible solution looks like this:

  • Every document is encrypted symmetrically with a random key K (a new key for each document).

  • Each user has his own public and private key pair, suitable for asymmetric encryption (e.g. a RSA or El-Gamal key pair).

  • Every document has a header which contains the encryption of K with the public key of each user who is deemed authorized to read the document.

  • To revoke a user, simply stops encrypting the K of new documents with the public key of that user.

  • To add a user retroactively, compute the encryption of K with the public key of that user, for each old document to which access must be granted; this can be done, of course, only by another user who can access the said documents (i.e. obtain K).

The system above is precisely what OpenPGP describes (see GnuPG for an opensource implementation). This was meant for secure emailing, but it works regardless of the actual transport medium, which could be a shared storage area.

There are drawbacks in the scheme described above:

  • Whoever produces the document must know the list of who should be able to access the document. This is not an absolute requirement; we could imagine a setup where the document is propagated from user to user, each user adding the encrypted K for the next user.

  • Each document has a header which grows linearly in the number of users in the system; for reasonably secure RSA encryption (2048-bit RSA keys), that's 256 extra bytes per user. Depending on the context, the overhead can range from the utterly negligible to the ludicrously unbearable.

  • The list of users who can access the document can be deduced by anybody, by looking at the header of the encrypted document.

  • Users have public keys, which implies the usual problem of distributing public keys in a secure way -- i.e. while avoiding usurpers. If there are many users, the solution involves a Public Key Infrastructure (PKI); OpenPGP uses the kind of decentralized PKI known as "Web Of Trust". X.509 is another PKI standard, with a pyramidal, centralized structure. Both are good at managing easy cases, and bad at scaling up.

Another, very different scheme for secure document sharing, is what is done with Blu-ray discs, with the AACS copy-protection. The security model is that there is a kind of central authority, but offline; each user (a Blu-ray player) has its own symmetric key, that the central authority also knows. When the authority publishes a new document (say, a new movie), the document is symmetrically encrypted with its own symmetric key K, and that key K is made available to all players through broadcast encryption. The authority want to distribute K to N users, where N is big, while using relatively little bandwidth (N can be in the order of hundreds of millions, but there is not that much free space on a disc), being able to add new users retroactively without requiring any document-specific transmission (you cannot patch discs once they have been built and distributed), and still having the possibility to revoke specific users. The mathematical beauty of the broadcast encryption used in AACS is that it requires size only O(log N) on each disc, plus O(R) where R is the number of revoked users. New users can be added at will. The idea is that a "user" will be revoked only if it appears that a player key has been disclosed and began to be widely copied in rogue players; hopefully (that is, the Blu-ray consortium hopes it), the individual player-breaking cost will remain sufficiently high that no more than a few dozens of such keys will have to be revoked.

Broadcast encryption uses a structure of double-nested trees which would be a bit too long to describe here. See this article for details.

There apparently is some existing research on the topic of broadcast asymmetric encryption, which avoids the need for a central authority which knows all the keys. I do not know whether good, secure schemes to that effect are currently known.