1

This is a follow up to this post:

Encryption strategies for multi users access in production systems

I don't see how this can work given the second bullet point:

  • Kc is stored on the computer n separate times, one per user. Each instance is encrypted by a different user key Ku1...Kun.

Two related questions:

  1. What happens when a new user is added to the system. Since that new user needs a copy of an unencrypted Kc, then it would follow that Kc is sitting on the disk somewhere, which begs the question, "Why does every user need their own self-encrypted copy of Kc?

  2. What happens when a user is deleted from the system? In the comments of the original post, user Thomas Pornin states Kc needs to be replaced every time a user is removed from the system, which means that each user would need to get a new key every time. If this is the case, wouldn't each user need to be logged out of a current session since the data will be unreadable with their suddenly outdated key?

Community
  • 1
Mreider
  • 11
  • 1
  • Can you use a HSM or server that controls access to the encryption keys? Would different directories need different keys (access controls)? Can you re-encrypt the disk at will? Or can you prevent raw access to the disk, letting a system service manage the encryption, giving users access to nothing but the plaintext they have the credentials for? – Natanael Oct 08 '15 at 15:42
  • To be clear, we aren't encrypting the entire disk. This is a web app and we are encrypting sensitive files on the file system. HSM is not an option in this case, as users will be logging in using their LDAP / Oauth2 / SAML credentials. We plan to store encryption keys as part of the user records in a local or remote encrypted database. – Mreider Oct 08 '15 at 18:50
  • Would something like Tahoe-LAFS be acceptable? – Natanael Oct 08 '15 at 19:00

1 Answers1

1

"What happens when a new user is added to the system."

A new user can only be added by an existing user who has already decrypted the disk. This existing user supplies Kc, which only ever resides in memory (not on disk).

"Why does every user need their own self-encrypted copy of Kc"

Because none of the alternatives are acceptable. Let's look at them. Suppose all user records shared an unencrypted copy of Kc. This Kc would have to be stored on disk somewhere to persist across reboots. In that case, the disk's data is encrypted, but the plaintext decryption key is stored on the same disk, so anyone with a disk image can decrypt the disk. Useless.

Suppose that each user had an encrypted copy of Kc, but all were encrypted with the same key. Then each user would have to supply this key, presumably in the form of a password or passphrase. But if every user has the same password, the system is not suitable for multiple users.

"What happens when a user is deleted from the system?"

A new master key Kc has to be generated, the disk's contents have to be reencrypted with the new Kc and every remaining users' Kui's has to be recreated.

Dave
  • 11
  • 2
  • 1
    I guess what I am asking is why each user would need a copy of the content key at all. The master key needs to exist somewhere, why not give the web app access to the master key, but not each user? – Mreider Oct 08 '15 at 18:52
  • I created a little Python app that takes our conversation and turns it into something real... https://github.com/mreider/multi-user-encryption – Mreider Oct 21 '15 at 05:16