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?

[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.

[zerodarkzone]

Maybe instead of supporting E2EE completely which will render useless all procesing done in the server (search, thumbnails, etc) you could add the posibility to have an encrypted space/vault where you can put files. This way you could actually ask the user for an extra password for that specific vault and each client then can simply ask for it when needed.

[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.

[CrypticCommit]

I’m not a fan of the idea of using a password to access key management. I believe we’re moving towards passwordless authentication, and I’m glad that Opencloud supports this through SAML/OAuth2 or SASL. E2EE definitely needs to work with FIDO2/WebAuthn!

I’m concerned about privacy as a politically or journalistically active person. As @bramblebird-ux mentioned, I don’t want my cloud provider to associate or access my content. More importantly, I want to ensure the integrity of my files; I don’t want the provider to delete or alter files without my knowledge. E2EE helps with targeted file deletion, but it would be great if this feature could be enabled for specific folders.

For a solution, I believe the mobile app (Android and iOS) should take on the responsibility of managing the E2EE private keys (Issue #16). Think of the app as a digital keychain. With this keychain, I can decide which doors I can see and which rooms I can enter.

Whenever I want to access my E2EE files from another device, I should send a request to the mobile app to get permission to open a specific door. The app must confirm each access attempt. After I confirm on the app, it should show me the doors I’m allowed to enter (file names).

When I want to step into a room (and open a file), I’d need to confirm again that I really want to go in. This way, I maintain control over what I can see and change. The digital keychain could also keep a history of when I opened which doors, so I can always track what’s happened.

Does that sound complicated? I’m looking forward to your feedback and suggestions!

[trendco]

Is there a way to integrate the Open Source Tool https://cryptomator.org into the clients, such as https://mountainduck.io does?

[smehrens]

Maybe encryption could work with a vault like openbao. This vault could store keys for fileencryption. for each folder a seperate key could be created and stored within openbao. Encryption could be implemented like in cryptomator or rclone.

Main benefits:

• openbao works fine with oidc
• multiple encryption keys could be used to enable per user-group or folder encryption
• hosting opencloud and openbao on different servers, hosting plattform etc... would provide security against single point of knowledge.
• no shared secret must be stored locally, possibility to rotate keys without user interaction.

Best regards