2

Suppose I have N users who should be able to decrypt a subset of documents D1...Dk. N is very large and users are often being adding and removed so it is impractical to encrypt a given document Di using all of their public keys.

As I've read, a common solution here is to create a group G with its own key pair, and its public key is used to encrypt the document.

What I can't figure out is how to give all users coming in and out of G the ability to use G's private key without storing it on the server.

I thought about encrypting G's private key with the public key of all its members, but what happens when a new user joins? I feel as though I would need to encrypt the private key again, this time with the new user's public key mixed in, however as the server I no longer have access to the unencrypted private key.

The closest solution I've seen is to create a new key pair for G and re-encrypt Di, but for a large number of documents this too becomes very impractical.

I should add that the system shouldn't be allowed to decrypt user's documents.

Is there some pattern using PGP (or any other standard really) that can help me out here?

Improve this question
1
  • This cannot be done as there is no system that can retroactively "add" decryption keys without also having access to the plain data. The closest I can think of is dividing the systems where one has access to keys but not to data and the other way around. Security will then rely on the strength of the division between them. This is partially how a Secure Enclave works. – John Keates Jun 3 '17 at 2:20
2

I provided an answer to a similar, but not identical question, here: https://security.stackexchange.com/a/159962/60823

about dealing with this for an email list.

Your specific solution will obviously have to conform to your own, unique, threat model and business requirements, but essentially it will look something like this:

Encrypt D with a one-time, symmetric key (e.g. something like AES-256) cipher. Encrypt that key with the PGP public key(s) of each member of the group G. Add, and remove PGP keys as membership changes.

At least one key (belonging to an admin maintaining the group, or a central identity managing daemon) will have to decrypt the session key (not the whole document though) and re-encrypt it with the newly added public key.

Of course, removing people from the group won't help if they have copied the unencrypted data locally, but that's outside the scope of your question. If you want to "lock them out" assuming they haven't already accessed the plain text, you could re-encrypt D with a new session key, and re-encrypt that to only the remaining current members of the group G. But again, that's no help if the person leaving the group already accessed the plain text.

Improve this answer
3
  • Thanks Jesse. I unfortunately edited the question a bit while you were likely typing that, to mention that this system may also have many, many documents. So each time a member comes and goes, we'd be re-encrypting a lot of documents. To make matters worse, there could be multiple groups, all very large. That's a lot of processing power... Re: a central identity daemon is one way to manage the group private key decryption/encryption, however it gives the system administrator (me) the ability to read other people's documents, which is not allowed by requirements (I'll add that above). – Dan Jun 2 '17 at 23:09
  • There may still be something useful in my ideas for you. You don't have to re-encrypt the docs, just the symmetric key for each doc (much smaller). You'd only have to re-encrypt the docs with a new key if you knew someone who left had never accessed the plain-text and wanted to block them. If you just want to block future access, just removing their pgp-key-encrypted copy of the session key is all you need. Ultimately, you need one key per identity. Full disclosure - my employer - has a product which might be useful here. voltage.com/products/data-security/hpe-securefile – JesseM Jun 2 '17 at 23:42
  • Thanks JesseM. I was able to work out a limited central signing authority arrangement with the clients. Unfortunate that a completely blind arrangement doesn't exist, but I'll accept this as the best answer. – Dan Jun 4 '17 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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