Native end-to-end encryption

[bramblebird-ux]

The opencloud project looks very promising but it still uses the old security model of central cloud services that leak all data once the server is compromised. There are already alternative solutions that show how this could be addressed through e2ee implemented using web technology. One open source example is Filen (doku) another commercial implementation with decent documentation is proton drive
These solution work by using the users login password as a key to encrypt all data on the client side (browser, app, desktop) before files are uploaded to the server. From the users point of view nothing changes but the resulting security is worlds apart from the previous approach that were attempted in next/owncloud.

I strongly believe that this should be offered as a native option in opencloud to provide an option for confidentiality that sets it apart from other solutions. The code to implement this is already available under AGPL and alternative solutions have shown this to be possible without requiring users to do any extra steps.

[micbar]

@bramblebird-ux interesting idea.

These solution work by using the users login password as a key to encrypt all data on the client side (browser, app, desktop) before files are uploaded to the server.

OpenCloud works with OIDC. So our access tokens are renewed every 5 mins (default). Every client (web, app, desktop) uses a different access token. OpenCloud itself is not holding the user credentials. How would these two solutions work under that circumstance?

[bramblebird-ux]

The most simple solution for OIDC may be to simply ask the user for the password again after authentication. Since most users will not clear their local browser storage, this second password input would only be required once per device (or whenever the browser cache is removed).
For apps this would also be required only once per installation.

I still believe there may be an option in oauth to automate this without any extra steps but I still need to find the time to look into that.
Perhaps someone with detailed knowlege on OIDC/OAuth2 knows a solution to this?

[butonic]

come on @refs ... give me a little insight into 👎

@bramblebird-ux OIDC is only concerned with authenticating and authorizing users. The public key mentioned in OIDC is used to authenticate various tokens. The private key is held by the IdP. E2E requires an additional set of keys that is only known to clients. The owner has to keep his private key secret.

While we could store a users public key in opencloud to let other users encrypt files for I would prefer we never store the private key on the server side. If we do E2E we need to first specify the threat scenario. For some attackers the filenames are more interesting than the blob content. With the spaces concept we could declare a space E2E encrypted and exchange public keys and blob data in it ... however then the server side is out of the loop and can no longer scan files for viruses or index the content.

E2E for E2Es sake is not a good strategy. I prefer to not implement features just to tick checkboxes.

[refs]

The most simple solution for OIDC may be to simply ask the user for the password again after authentication

@butonic Oh not a biggie, the whole point of OIDC or OAUTH is NOT to do exactly this and leave authentication to the protocol, this is the source of my 👎; unless what was meant here was user-derived encryption keys, if so terrible wording :D. It is also an anti-pattern because OAuth is designed to delegate authentication to a trusted identity provider. If your application asks for a password after OAuth authentication, it contradicts the purpose of OAuth, which is to avoid handling credentials directly.

Users also expect OAuth to fully authenticate them without requiring additional credentials. Asking for a password afterward might make users question how legit we are and will reduce trust.

the server side is out of the loop and can no longer scan files for viruses or index the content.

This is the first thought that pop in my head when discussing E2E, but honestly it is a small price to pay for sovereignty. Move some functionality to the clients.

<3

[bramblebird-ux]

@bramblebird-ux OIDC is only concerned with authenticating and authorizing users. The public key mentioned in OIDC is used to authenticate various tokens. The private key is held by the IdP. E2E requires an additional set of keys that is only known to clients. The owner has to keep his private key secret.

Yes, however I was hoping for an option in OAuth to return a parameter to the client after authentication that could contain something like a hash of the credentials, or another derived value that can be used as a key without revealing the actual credentials. But if there is no such option that intendes to do this, it would not be safe to reuse any of these original credentials.

While we could store a users public key in opencloud to let other users encrypt files for I would prefer we never store the private key on the server side.

You would need to store the private key in encrypted form on the server, since you do not want the user to manage this key (passwords are bad enough)

If we do E2E we need to first specify the threat scenario. For some attackers the filenames are more interesting than the blob content.

We could use an approach like filesystem based encryption (see android encryption or linux fscrypt). This would encrypt filenames as well and leave only metadata such as file size, which could probably also be addressed by padding on the server if required (but would likely be irrelevant for most users)

With the spaces concept we could declare a space E2E encrypted and exchange public keys and blob data in it

I would strongly argue against adding options such as this, it leaves quite a lot of potential for user error and makes the implementation more complicated.

however then the server side is out of the loop and can no longer scan files for viruses or index the content.

This is a big plus in my book. Regardless of the snakeoil argument, as a user I do not want my could provider to scan my files, be that scan for malware or to snoop around for my private data.

E2E for E2Es sake is not a good strategy. I prefer to not implement features just to tick checkboxes.

True! Either this can be done right or not at all. The nextcloud e2ee app shows how NOT to do this. It has the lowest possible user rating.

Users also expect OAuth to fully authenticate them without requiring additional credentials. Asking for a password afterward might make users question how legit we are and will reduce trust.

If this feature is an option that the user has to activate, followed by entering a password/secret, it would address this expectation.
If our assumptions about OAuth are correct, the only option to use the login password for this would be to use the internal OpenCloud user password when no OpenID is used. That said perhaps it is better to streamline the experience and not reuse the login password even when it is possible and instead ask for a seperate password for encryption independant of the identity provider.
The big issue I had hoped to avoid by reusing the password is that users will forget passwords and recovery keys ...

[jochumdev]

@butonic

For some attackers the filenames are more interesting than the blob content.

Filen seems to encrypt MetaData as well, that sounds like the right solution against Filename sniffing.

[Tronde]

Hi,
Maybe you could find some inspiration when looking at:

• Seafile encrypted libraries
• TeamDrive End-to-End Encryption (E2EE)

IMHO E2EE is an important feature that's worth to spend some time on thinking how to do it right. Especially when I'm looking for SaaS offerings it's important to know what technical mechanism prevent the SaaS provider to get access to my or my cusotmer's data.

[bramblebird-ux]

Seafile does not appear to use web based e2ee and for TeamDrive I could not find any whitepaper describing the implementation.
If you know where to find this, please point it out.