0

I realize SIMILAR questions have been asked before but I'm looking for certain specifics I can't seem to find elsewhere. The following question closely resembles mine but falls short for me on details: Encryption strategies for multi users access in production systems.

I'm creating an application that allows users to add content, which is then encrypted and stored in a database using a content key. This content key is a randomly generated string of 32 characters (since rijndael-256 doesn't seem to support more than 32 characters, or certain utf-8 characters for that matter, but that subject is outside the scope of this question). The content key is also stored in the database, encrypted with the private application key.

What doesn't make sense to me is that next, according to similar posts, each user that should have access to the encrypted content should be given a unique key.

How is this safer than let's say creating a reference for every encrypted row stating which users are allowed to view the encrypted content based on the user's id?

What I'm looking for is a detailed explanation on how to tackle these kind of situations, and furthermore what the keys and passwords (if any) should be derived of.

Community
  • 1
Kevin Op den Kamp
  • 103
  • 3
  • 1
    You may want to check out Mylar and try to leverage it as your framework: http://css.csail.mit.edu/mylar/ – Eric G May 02 '14 at 23:35

1 Answers1

1

And how does that table grant them access to the files? The entire point of encryption should be that the server can't access the files even if it wanted to. If you just have the data keys stored in a table with a list of who is allowed to access the key, the server can now access the files and encryption is pointless.

Instead, a copy of the content key for the file is encrypted with the public key of the user being granted access and stored in that users keyring (a table much like you described for saying who has access, but storing access keys rather than a simple permission lookup). Without that user logging in and providing their password, their private key can't be decrypted, the content key can't be decrypted and the file can't be accessed using their copy of the content key.

If you want to reject access, you simply remove the content key from their keyring and destroy it (provided that the server has never leaked the content key while they had access, slightly more secure would be to actually change the content key, but that gets costly as it requires re-encrypting the file and all the other keyrings).

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • My thought exactly. I'm still trying to figure out how this works in real life though. I create a user, provide him with a public key (random string?) and save it alongside the hashed password. If this is so, than wouldn't the application itself still be able to decrypt the content by first decrypting the content key with the public key saved in the table? I'm still trying to find a detailed real life example (including generation of public/private keys and the encryption itself) for this situation. – Kevin Op den Kamp May 02 '14 at 14:04
  • 1
    @KevinOpdenKamp - I suggest you read up on asymmetric cryptography. From your comment it sounds like you have some very basic misunderstandings. I was disagreeing with you as I understood what you were saying. Yes, the public key would be stored with the user's record, but it would need to be part of a cryptographically generated keypair. With asymmetric cryptography, the public key can be used to encrypt something such that only the private key can decrypt it. – AJ Henderson May 02 '14 at 14:19
  • I'll do some more reading then. From what I read so far it seemed that symmetric encryption was the way to go but I'm starting to think that is impossible on a multi user encryption platform. Thanks – Kevin Op den Kamp May 02 '14 at 14:20
  • So when a new user is created, you generate a public/private key pair. Store the public key on the user's record, use the user's password with a KDF (key derivation function) to produce an encryption key, use that key to encrypt the private key and store that on the user's record as well. From there, the public key can be used to encrypt any content keys that the user needs to have access to and the system can use the user's password on login to load their private key in to the session, thus making it so their keyring can be opened. – AJ Henderson May 02 '14 at 14:20
  • @KevinOpdenKamp - For a multi-user system, you need asymmetric cryptography unless both users are involved in encrypting the file. You use symmetric cryptography for encrypting data, you use asymmetric for exchanging keys with another user. In theory, if both users were online, you could have one user give the data key to the other and have them then encrypt it so only they can access it, but there is no secure way to save a content encryption key for another user with symmetric cryptography if the system doesn't have access to that user's key, which defeats the whole point of encryption. – AJ Henderson May 02 '14 at 14:23
  • Thanks for the clarification. However: if a user was to invite another user for access to a piece of encrypted content, how would the other user be able to watch this content without the server creating a different encrypted version specifically for this new user first? – Kevin Op den Kamp May 02 '14 at 14:23
  • That's why you use symmetric content encryption keys and share the key. The server keeps one copy of the file, encrypted symmetrically with a content encryption key. You don't make multiple copies of the file, you make multiple copies of the key. So say I want to share file Foo with Alice and Bob. I encrypt Foo with a new FooContentKey. I encrypt FooContentKey with Alice's public key and put the new FooContentKeyForAlice on Alice's keyring. I then encrypt FooContentKey with Bob's public key and put it on Bob's keyring as FooContentKeyForBob. – AJ Henderson May 02 '14 at 14:25
  • You can do the same thing with groups if you want by giving a group its own public/private keypair and then adding the private key for the group (encrypted with the user's public key) to each group member's keyring. – AJ Henderson May 02 '14 at 14:27
  • I think I'll read up on asymmetric first and then come back to this. I feel like I'm missing some crucial parts. A question I have right now for example is: if I save FooContentKeyForAlice in her keyring, and I have the public key stored as well, what is there to stop me from decrypting it myself? I'll check and see how I'm supposed to involve the user's private key in this I suppose :) – Kevin Op den Kamp May 02 '14 at 14:32
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/14281/discussion-between-aj-henderson-and-kevin-op-den-kamp) – AJ Henderson May 02 '14 at 14:33