Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I believe it's possible to meet these requirements only if a third party is involved in a manual process. For example:

  • Each user is given the same public key
  • The private key resides offline at a third party
  • Alice creates a document. When she wants to share it, she sends it to the third party who signs the document and uploads the document to the central server.
  • If Bob wants to view it, he verifies the document's signature with the shared public key

I'd like to eliminate the third party from the process. However, I haven't come up with a way to do so. Everyone in the account would need the same public/private key installed. Documents signed by Alice and the private key could be verified by all other users since they also have the same key pair.

The problem: new users can be added at anytime so the public/private keys would need to stored at a central location so these new users can obtain the keys. If that location was compromised, a hacker could upload new documents and sign them with the compromised private key.

In a nutshell, storing the private key on a central server seems similar to storing plain text passwords.

So, is there way to securely share centrally-stored documents among a changing set of users?

share|improve this question
1  
Hi @Derek, welcome to the site! A bit more info wrt what you're looking for, when you say "secure" - do you mean protect confidentiality (i.e. no one else can see it)? Integrity - no one should be able to change it? Or, it sounds like you're more interested in Authenticity - ensuring the identity of whoever wrote the document? –  AviD Jun 18 '11 at 20:56
add comment

1 Answer

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.