nextcloud / end_to_end_encryption_rfc

🔒 Specification for end-to-end encryption used by Nextcloud sync & mobile apps
Other
31 stars 15 forks source link

Generic question regarding protocol security #45

Open ho1ger opened 6 years ago

ho1ger commented 6 years ago

I have a question regarding the security of the e2ee protocol. When I understand the purpose of the e2ee efforts / the white paper correctly, e2ee tries to defend against compromized servers or malicious admins. So essentially we distrust the server to host sensitive files in a secure way, which is a good thing to do.

But let us now look into the sharing of encrypted folders between two users, Alice and Bob. For this purpose, Alice first creates a new folder, enables encryption and decides to share it with her friend Bob. Alice now needs the public key from Bob which is sent from the server to Alice inside a certificate. When I understood things correctly, the server also acts as CA and signs all certificates.

Now let us assume that the server is compromized: an attacker has access to the server and can even manipulate the source code of the e2ee module, etc. This allows the attacker to manipulate the key exchange between Alice and Bob: 1) the attacker first creates and signs a certificate for user Bob which contains a public key whose private part is controlled by him (the attacker). Remember: this is possible, as the server also acts as CA, i.e., the CA's private key will be accessible by the attacker. 2) This bogus certificate is sent to Alice, who validates the certificate and fully trusts "Bob's" public key.

Later, Alice uses Bob's public key to encrypt this data (resp. the various layers of symmetric wrapping keys that finally encrypt Alice's data). In the end the attacker uses her private key to decrypt the data and the confidentiality of Alice's data is broken.

I really hope I am entirely mistaken and I missed something in the white paper and you can scatter my concerns. Otherwise the e2ee protocol would have - in certain situations - a major flaw.

I do not understand that on one hand side you do not trust the server to store data in a secure manner but on the other hand side you use the server to sign certificates and to exchange those certificates between users.

In my opinion, you could mitigate the situation either by separating server and CA to prevent that the attacker can easily generate authentic certificates, or every client must be equipped with a function that allows users to authenticate the exchanged keys comparable to what we know from the Signal app, etc.

rullzer commented 6 years ago

In future version there will the possibility to check fingerprints between users out of bounds (like signal does). It even might be possible to use a 3rdparty as CA.

But we are not there yet. For this reason we use trust on first use (like signal does as well) for now.

I hope this answers your questions.

ho1ger commented 6 years ago

Well, I understand that we are talking about alpha software. So I know there can be bugs that destroy my data or weaken the promised protection. But I can not understand that a known limitation of the current implementation or system design is not transparently communicated...

georgehrke commented 4 years ago

Moving to RFC repo since this is a protocol discussion.