 |
| Android encryption in action |
End-to-End Encryption
End-to-end encryption is usually associated with communication channels, think chat or video calls. Signal, Telegram and lately WhatsApp employ end-to-end encryption. So what does it mean?The main property of end-to-end encryption is that the data is encrypted on the one end and decrypted on the other end, so only the sender and receiver can read it.
As an example, take the Nextcloud Video Calls app. When you share a link for a call and the other person joins, the Nextcloud Server essentially gives the other user the address of your computer and helps you connect to each other. It will also send signals when others join the call, when you mute and so on. But the actual call takes place between your system and that of your conversational partner, directly. And before it is sent out, your browser will encrypt the data for the other side to decrypt. This way, nobody in between, like your internet provider, can listen in!
The main downside of the term is that the definition of that 'end' can vary: you can say that normal https encryption is 'end-to-end', defining one end as the browser and the other end as the server. So this brings us to the difference between server-side and client-side encryption.
Server-side encryption
Server-side encryption serves to protect data on or going through a server: as soon as the data arrives, the server encrypts it. When you use a cloud storage like Amazon S3 or a Dropbox account or a FTP at another office with Nextcloud, our Server-side Encryption encrypts the data before it gets sent to the other storage and decrypt it only after it has been retrieved. Server-side encryption thus protects your data from access by a third party storage solution.Note that encryption in the browser is essentially server-side encryption: the code that does the work comes from the server and thus the server controls what is going on. If a server is compromised, the attacker (or evil system administrator or government agency) can simply make a minor modification to that code so it gives them access to your private key!
When the data is on the server itself, however, the server admin has access to it as the keys are managed by the server. In case of Nextcloud, we encrypt that key with your login, making it impossible for the server to decrypt the files unless you are logged. That is called "protection of data at rest", but, of course, you log in all the time if you have the client running.
So the limitation of server-side encryption lies in what it does not protect you from: the server being compromised.
Client-side encryption
This is why server-side encryption is often contrasted with client-side encryption, which is what is employed by the end-to-end encryption Nextcloud introduced today. Where server-side encryption happens after transmission to the server, we encrypt the data on the Android, iOS or desktop client already. Then, only at the receiving end, it is decrypted again. That receiving end can be another device owned by the same user or a device owned by another user who has been given access to the data. But not anyone in between or otherwise not authorized! This is sometimes also called a zero-knowledge privacy: at no point in time can the server have any knowledge of the data. |
| The process of creating keys |
A little bit about keys
Usually, public and private keys are used for the encryption and decryption. How does that work?Everybody has a set of closely related keys, a 'public' and a 'private' key. They work a bit like a mail box works: anyone can throw a letter in the box, but only the mailman (or woman) can open and empty it. The public key is, as the name implies, public. Anyone can use it to encrypt something. But to decrypt the result, the private key is needed!
Nextcloud generates a public and private key pair the first time a user enables end-to-end encryption in their client. The public key gets signed by the server with 'certificate' to verify the user identity (our Cryptographic Identity Protection feature) and stored there for other users to encrypt files to that they wish to share. The private key gets encrypted with a locally, app-generated very secure and very long (12 word!) passcode which is displayed to the user and then the key gets stored on the server as well.
Another device owned by the user can download the private key, the user can enter the 12 word passcode to decrypt it, and this device will then also be able to encrypt and decrypt files. That is how you add your phone and desktop after you enabled end-to-end encryption on your laptop.
You can learn much more about exactly how the encryption and decryption work on the end-to-end encryption web page we made as well as the whitepaper you can download there.
Enterprise challenges
While consumers use end-to-end encryption for chat for years, larger organizations like companies and governments have struggled to find solutions that protect their sensitive data without disrupting productivity and legal requirements for audit logs.Indeed, many solutions create a new layer over existing solutions like Box and Dropbox or have poor key management, making sharing cumbersome and less secure. A real enterprise solution needs to take the burden of complexity away from users and, if it needs to be anywhere, put it on the shoulders of the system administrators. Nextcloud has done exactly that, not even allowing users to create their own, potentially insecure password and making adding devices easy. The 12-word passcode can be recovered from any of the devices an user owns and it is possible to enable a system wide recovery key. If enabled, users will get warned of this and the system administrator gets to see and note down the key once and only once. After that, the code is destroyed and no attacker would be able to steal it, provided the server administrator puts it in a safe location: we'd recommend an actual safe.
Another important feature for enterprises is support for a Hardware Security Module which could be used to generate user certificates. Without it, our design does not allow users to switch identities (as this could be abused by an attacker with control over the server) but this restriction can be relaxed if a secure HSM is in the mix.
You can learn more on our webpage about end-to-end encryption!
