Deprecate user-key encryption in favor of master key

[PVince81]

User-key, while more secure, is impairing a lot of features in the ownCloud platform and also getting in the way of some functionality. It also doesn't provide a good way to recover data in case the keys are lost. There's the recovery key, yes, but enabling this is almost the equivalent like sharing all files with the administrator, which is almost equivalent to master key.

Some examples:

• not able to add users to groups: https://github.com/owncloud/core/issues/16332

As discussed before internally, we should discuss deprecating user-key encryption in favor of master key encryption.

This would require a big enough timeline for people to migrate to master key in the meantime until we can remove the code and the option. We already made "master key" the top item when selecting encryption type at setup.

@hodyroff @pmaier1 @DeepDiver1975 @tomneedham @butonic @sharidas

[butonic]

no. hsmdaemon works well with user individual keys. imo we should enforce chunked upload when encryption is turned on and encrypt each chunk in ram, then write it to the storage wherever it is. and always assemble (and decrypt) the file on the fly. all chunks must use the same filekey for this to be efficient. that should work well.

regarding groups: introduce group individual keys or use proper background jobs to reencrypt shares with new users in groups. syncing groups might also help, but I still think group individual keys are the cleanest solution, (even if it is the weakes from an encryption point of view).

[PVince81]

@butonic so if I understand correctly you are suggesting to use HSM stored keys instead of the user passwords ? One of the big limitations of user-key encryption is that for any encryption operation, the user's password is required.

The other thing is about the code of developing, testing and maintaining this complex solution vs the simpler master key way if the latter is already enough for most use cases.

[butonic]

yes. encryption is not the hard part. key management is. using an hsm we can decoulple storing the keys from the owncloud admin. he needs to change code to then access the files, which is a deliberate malicious act that can be logged. people can get sued over this. Full protection only comes with E2E encryption which comes with even harder key management. IMO we should define the threat models we want to protect against. It might be that server side encryption with user based keys is equal to master key based encryption under the light of any thread model we can come up with. But I highly doubt security people to bo ok with an adversary decrypting all files if he gets hold on on key (which is problematic if a recovery key is used, but in enterprise environments the keys are generated in a safe place and only imported as non exportable into the actual hsm. at least that is what I have seen in highly confidential enterprise environments)

[thommierother]

As 10.2 now includes HSM as a central encryption device, isn't it time to plan the sundown of user-based encryption? I migrated successfully already, maybe its time to move forward here ;-)

[butonic]

the hsm can be used for user individual keys as well ... someone needs to explain to ma again what the problem with that is. groups ... then use a group accessible key ... I see no technical reason to get rid of user based encryption ...

[thommierother]

I mentioned HSM only as it is an improvement of "central encryption" where the crypt device can be separated from the server. Not the same level of security than user based encryption but a bit better than classic master key or encrypted filesystems (LUKS etc).

I had problems with sharing data through groups since 8.x up to to 10.1x. And user keys prevent integration of online editing into OC (at least for Only Office, don't know the situation for LibreOffice/Collabora). But ok, let us discuss the best way ;-)

[butonic]

yes, HSM is definitely an improvement over the baked in solution.

Ultimately, the efficiency depends on the threat scenario. If you are trying to hide the data from a storage admin LUKS or the baked in encryption will meet that criteria.

In my experience the problem with group sharing is that we currently only use user individual keys, so that when a new user is added to a group we

1. need to detect that
2. need to reencrypt all files shared with that group with that users keys. To do that we need to have access to the content. But no key to decrypt is accessible if the use got added to a group (say in active directory). A key is only available when sharing happens, because we then have a session with a logged in user. It would be possible with a recovery or master key ... which would make user key based encryption pointless ...
3. The reencryption needs to finish for all files. Currently, there is no mechanism in place to restart or continue encrypting.

In my opinion group keys should be able to solve that properly ... but I may overlook something. In any case this is something to be considered for the next generation of the ownCloud architecture, where we can have proper background processes to handle these long running tasks.

[stale[bot]]

This issue has been automatically closed.