[Encryption-Idea] use the recovery key to re-encrypt files if user was added to group

[schiessle]

I discussed the problem with @cdamken that user often have problems if they add new users to a group because by default the new user will not be able to decrypt the files shared with the group.

There is only one possible solution I could think of:

General thoughts:

• encryption is always a trade-off between security and convenience, you can't have both at 100%

Precondition:

• recovery key needs to be enabled
• all user need to use the recovery key

Solution 1:

• when adding a user to a group the admin could enter the recovery key and trigger a re-encryption with the new user list.

Advantage: the new user will get immediately access to the file
Disadvantage: for large installation this could take a long time.

Solution 2:

• have a script which re-encrypt the files with the recovery key when a new user was added to a group

Advantage: The script could be executed by the admin in the background
Disadvantage: extra manual step for the admin

I think solution 1 is a no-go because we can't expect that the admin needs to wait for a long time after he added a user to a group until all the re-encryption was finished.

Solution could be possible if we really want to go this way. What we need to consider:

• Adds complexity for a solution which only works under certain pre-condition.
• How often does a ownCloud installation meet this pre-condition that every user uses the recovery key (remeber: this also means less-security)?
• Already the calculation of the shares which needs to be re-encrypted could be quite expensive, think about re-re-...-shares where at some point the group was involved to whom the user was added. (would be much easier if Re-Sharing Behavior Update #9058 is implemented)
• It would still need manual interaction (if we go for the only feasible solution, solution 2)

I tend to stay away from the technical solution and continue with the personal solution: "Hey, I'm new in your working group, please re-share the document with me so that I can work on it." Other encryption systems also doesn't provide any automated solution to add new users. But if it is really important for some users we could think about implementing solution 2 after considering all the advantages and disadvantages.

cc @craigpg @karlitschek @MTRichards

[gnanet]

The "special cases" that brought this discussion alive were all from an environment where there is in fact a sysadmin, who will do the necessary manual steps, i think they even will be able to set up the recovery for all users affected.

I am for solution 2 (or something based on that), and will be happy if i can help to realize it in any way.

[karlitschek]

Interesting that no one found this corner-case before. I think option 2 is the best. But it should be visible in the web-interface somehow that is step is needed. It should also be integrated into occ.

[cdamken]

I'm for 2 also.I think when the administrator creates a user and add it into a group, he already knows that he has to run the script (overnight) to re-share the files.

I think a good documentation should be prepared, this way the user of ownCloud knows that encryption needs more attention after activated than a system without it.

@ser72 and @bboule can give us some input too

[bboule]

To be honest guys… I really don’t think this makes much sense in an enterprise setting…

There really needs to be some level of automation here.. you can’t expect an administrator of a 5000-10000 user OC system to be keeping track of these types of things (scripts he/she needs to run when adding a user to a group).  It really starts to impact our ability to scale if you force an admin to do this.

If we need to run this as a script, we need to automate it with a specific trigger, perhaps we can automate using cron and generate the job with a script that looks for new users in a group (could also be a database job) and then trigger the re-encrypt if needed….

I just don’t think we can hand this script to an admin and tell them to run it every time a group changes we just need to think more around automation for scale!!

Just my 2 cents!

BB
-- 
Bob Boule
Sr. Solution Architect 
ownCloud

On July 31, 2014 at 5:16:37 AM, Carlos Damken (notifications@github.com) wrote:

I'm for 2 also.I think when the administrator creates a user and add it into a group, he already knows that he has to run the script (overnight) to re-share the files.

I think a good documentation should be prepared, this way the user of ownCloud knows that encryption needs more attention after activated than a system without it.

@ser72 and @bboule can give us some input too

—
Reply to this email directly or view it on GitHub.

[schiessle]

If we need to run this as a script, we need to automate it with a specific trigger, perhaps we can automate using cron and generate the job with a script that looks for new users in a group (could also be a database job) and then trigger the re-encrypt if needed….

That's not possible, because the script needs the recovery password and you don't want to store a password in plain text (on the database or in a script) which gives you access to all files.

We need to keep the general thought in mind, which I stated at the beginning: "encryption is always a trade-off between security and convenience, you can't have both at 100%". You want to use encryption because you want more security. Namely, you want that only those people have access to your files to whom you grant access. This makes it impossible to implement any automated process to "randomly" give users access to your files without your explicit approval.

[gnanet]

From my view, especially an enterprise setting does not have 5-10 thousands of users who use group shared encryption, the opposite happens: there may be working groups, who have 5-10thousands of files shared with serverside encryption.

I support the idea to try to automate it with a specific backgroud job, BUT NOT CRON and in no means with storing any password plaintext (already begun some thoughts in #9386 )

[bboule]

I think you have to look at it from the perspective of an enterprise having 5-10k users (or larger)... orgs of that size you really can't have a product that expects the admin to keep track of changes in group membership and then manually running scripts every time this happens without some level if automation... It simply does not scale... As far as orgs that size not using encryption with groups that are sharing... I guess we can agree to disagree :) I guess we just need to account for the scalability of a solution from an admin overhead perspective for large scale deployments. Just something to consider I guess!!

---Bob BouleSr. Solution ArchitectOwnCloud978.751.1005Twitter: @bobboule

On July 31, 2014 at 7:56:18 AM EDT, Gergely Nagy notifications@github.com wrote:From my view, especially an enterprise setting does not have 5-10 thousands of users who use group shared encryption, the opposite happens: there may be working groups, who have 5-10thousands of files shared with serverside encryption. I support the idea to try to automate it with a specific backgroud job, BUT NOT CRON and in no means with storing any password plaintext (already begun some thoughts in #9386 ) —Reply to this email directly or view it on GitHub.

[ser72]

Also keep in mind if the enterprise uses LDAP authentication (which most do), The LDAP admin may add users to the groups, and the ownCloud admin, who may be a different person, may not be aware of these additions and then wouldn't know to run a script manually.

I agree with @bboule Needs to be automated in some way for the Enterprise.

[gnanet]

@bboule i accept your point of view, the only obstacle left, is the safe, and secure solution for the automation (containing LDAP polling etc)

[MTRichards]

The core issue is this:

if they add new users to a group because by default the new user will not be able to decrypt the files shared with the group

From my point of view, we do need to design in large scale operations, with many users coming and going and group memberships changing daily.
We need to think of a solution that can work with LDAP / AD, Shibboleth, ownCloud internal groups and possibly yet another standard auth mechanism (OAuth).

What if we created a group key? This is not simple, I know, but if a user is a member of a group and has that key too...it could solve this.

[schiessle]

What if we created a group key? This is not simple, I know, but if a user is a member of a group and has that key too...it could solve this.

This doesn't solve the problem but just moves it from the file key to the group key. To make sure that the group key can only be used by the group members you need to encrypt the group key with the public keys of the group members. Basically you will end up with the same pattern as for the file keys.

There is one thing which we could improve by introducing a group key: Given that the group key is also encrypted with the recovery key, we would only need to add the new user to the group key instead of adding him to all file keys. This way we could do it on the fly (solution 1) if the admin manipulates the groups on the web interface. It would also reduce the overall problem. Once the user is added to the group key he can access all group shares, also group shares initiated by someone else.
Still it wouldn't solve the LDAP issue and honestly at the moment I don't see how this can be solved without reducing the security to a level which would make our encryption a bad joke. But I have to talk to @blizzz how the LDAP groups are handled and if there is a way to get notified about group changes. But even then, we can only add a user to a group if we have a password from one of the users who already have access to the file. There are three ways how this can happen if we get informed about LDAP group changes (a) by the admin with the recovery key (b) by a user who shares a group share once more (c) if we can track the group changed we could perform the update during login as soon as a user log-in with access to the group. For (b) and (c) it is not predictable when it will happen while (a) can be controlled by the admin.

[MTRichards]

Ok, I see that.

Back to the top, there are a few use cases here to be sure we capture:
Type A:Group memberships that admins manually change:

• Using ownCloud for user and group management via GUI. This case, the admin is the one who changes the group membership and could also enter recovery key
• Using ownCloud for user and group management via API. This case, users are managed via the Provisioning API in addition to the GUI, so a group add or remove may not have a manual component.
• Using LDAP / AD for auth, but groups managed in ownCloud. This case, users are managed via the GUI.
• SAML / Shibboleth for auth, but groups managed in ownCloud.

Type B: Group memberships that admins change in other systems:

• Using provisioning API for group management.
• Using LDAP / AD for auth and groups. This case, no manual interaction.
• SAML / Shibboleth for auth and groups. No manual interaction
• Other external auth (custom stuff maybe)

So in this situation of A, there is probably a reasonable way for handling the process via a prompt or something in the UI cached in a session or with a timeout so it isn't stored on the server, but makes high volume changes easy.

The issue is B. If there is no interaction, there can be no prompt. For this, is there a way to store this password encrypted in the database?

Then an admin has an option: If they want to be secure, they have to use the Web UI and do this themselves. Or, if they mind being a little less secure but making it easier to manage, they can choose to store the passphrase encrypted in the database.

Reasonable?

[blizzz]

But I have to talk to @blizzz how the LDAP groups are handled and if there is a way to get notified about group changes.

There is a background job that runs once an hour and checks and updates group memberships. It will fire the corresponding hooks.

[schiessle]

@MTRichards thanks for the summery of the two use cases and thanks @blizzz for clarifying the LDAP issue.

I agree with @MTRichards that "Type A" can be handled within the ownCloud user management and the recovery key if we opt for the additional group keys and if we operate in a environment where the recovery key is enforced.

For Type B we could track the changes in database table. This should be possible at least for the provisioning API and for LDAP (as explained by @blizzz). I'm not sure about the other auth methods. But they could probably do something similar like LDAP. Basically this would mean that we would maintain a list of modified groups. Once a user log in we could check if the user is a member of one of the modified groups, if yes we could use the users private key to decrypt the group key and encrypt it again with the new list of public keys. As soon as one member of a modified group log-in, all group shares would work for the new set of group members again.
For the provisioning API we could probably also add a parameter to specify the recovery password. This way the provisioning API could be handled as "Type A".

I also thought about it during the weekend. I think the group keys is the best thing we can do to solve this issue from a user/admin point of view. It still wouldn't be a 100% solution because in order to work the ownCloud setup would need to meet some specific criteria (recovery key enabled for all users, and the TypeA vs TypeB differences). I think from the user/admin point of view this would work. I worry a bit about the additional complexity. Already today it is hard to understand how file-key, share-key, private-key, public-key and the special purpose keys (share-link-keys and recovery-keys) work together. With the group keys we would introduce quite some new keys. We would have additionally to the existing keys following extra keys:

• for each group a private and a public key
• the private key would be encrypted with the group members public key, so we would have n share-keys for every private group key, where n equals the number of group members.

Thinking about large set-ups you could imagine that this would result in a lot of extra keys we and also the admins would need to manage.

[schiessle]

The issue is B. If there is no interaction, there can be no prompt. For this, is there a way to store this password encrypted in the database?

Not really. Because how would you encrypt the recovery password? For encryption you would again need a key or a password, and where do you store this password/key then? To decrypt something encrypted you always need some kind of user interaction otherwise it will never be secure.

[cdamken]

@MTRichards @schiesbn How is the status for this issue?, will be planned for oC8? and if, which will be the procedure for the user?

[MTRichards]

Not entirely sure where we stand.
@schiesbn has this use case been addressed with the other encryption app changes?

[MTRichards]

I (and @gig13 , thanks Allen) tested this again today. We get a nice message now "please ask the owner of the file to reshare it with you". this is better than losing data.

Question: Can't we effectively do the same this programmatically if the recovery key is enabled?

[atroxix]

Our company has several OwnCloud servers set up in separate offices and all of those use LDAP authentication, so our use-case is indeed the one where admin interaction cannot be assumed at all times.

How about handing over the responsibility of re-sharing data to the file owner? Something like:

1. User A shares data to group 1 which has users B, C, D
2. User E is added to group 1
3. User A receives notification (either from some background process (cronjob) or in web UI) that he has data that needs to be reshared with group 1 because user E was added to the group.
   3.1. User A logins to OwnCloud web UI and somewhere among notifications there's link to list of files-folders that need to be re-shared. In that list for every file/folder it could be shown in the right-hand sidebar which users miss the re-encrypted data.
   3.2. User A goes to that list and can select some or all files-folders that need to be re-shared.
4. User E logins to OwnCloud and can use basically the same list/view about the files which have been shared to him, but haven't been encrypted with his certificate.

In that case re-encryption would be visible and not be done behind users' backs. All this activity should be logged too.

[bboule]

@cdamken looks like this has moved to 9 are you able to update the user?

[cdamken]

I informed to our partner, he is the one who has contact with the customer.

BTW, the new information from this case is here: https://github.com/owncloud/enterprise/issues/482

[atroxix]

The above link about enterprise#482 does not work :(

[MorrisJobke]

The above link about enterprise#482 does not work :(

It's internal stuff for employees only, because it could contain confidential data ;)

[PVince81]

Moving to 9.2. Might be worth looking into it.

But there was also this parallel discussion: #16332 (comment)

[PVince81]

Would move to backlog as this is a bigger topic, big in discussion and likely big in implementing the proposed solutions. Current workaround is to use master key instead of the complex encryption scheme.

@butonic @pmaier1

[PVince81]

Moving to backlog, needs to be reevaluated and scheduled.

This could take 5-10 md including research and testing.

[PVince81]

I think we should just implement an alternative and simpler system as discussed.

There is a simpler system nowadays: master key encryption

[stale]

This issue has been automatically closed.