Server: Delete E2EE keys for fresh start

[unteem]

What is the clean way for a fresh restart when a user lost his passphrase and device?

We are not trying to recover any data, we just want the user to be able to reuse the E2EE module.

Steps to reproduce

We have 2 cases:

1. iOs app crashed before the user cloud enter passphrase
2. User formated his device and all his passwords

Expected behaviour

We want them to be able to reinitialise the E2EE. No data or passphrase to recover, just a fresh new start

[MorrisJobke]

cc @schiessle @tobiasKaminsky @rullzer

[tobiasKaminsky]

To circumvent case 1, we on android store the keys only after the user noted down the passphrase.
Case 2 should also not affect it, as the key is also stored encrypted on server, so you only have to enter the passphrase.

If you really want to reset E2E, there is currently only a manual way:

• go into app folder on server side, then end_to_end_encryption, remove the sure in question
• log into mysql and "DELETE FROM oc_filecache WHERE name like '%$USER%';"
  (please do a backup first)

[jospoortvliet]

@unteem this is not possible, by design, as it would allow posing as a user by a hacker. As all other accounts the user shared with will trust the user key on first use, they will reject any new identity from that user. So even if you created a new set of keys with a new passphrase, it would be useless.

If you lose your passphrase and device, you have to create a new account. There is no real way back.

The work-around by @tobiasKaminsky will be OK until we implement sharing: your user account will never be able to share with a user it shared with before, so we won't implement a feature to 'reset E2EE'.

Of course, we could, at some point in the future, go the Signal way of just adding new identities with TOFU but I think it is a security risk - users click away the warning that another user has a new digital identity and can thus easily be duped into sharing files with a hacker. This is the whole thing E2EE is designed to protect from...

The case of the iOS app crashing after creating an identity is a different issue, but that should be solved the right way: the app should always be able to show the passphrase. This is explicitly called for in the design, and the fact that that is not yet implemented means the app isn't yet ready to be really used with E2EE.

[ediazcomellas]

Reseting E2E keys is a feature that will be needed from time to time because, you know, shit happens and users usually forget passwords and everything else. I would expect that reseting E2E keys will cause users to lose access to the encrypted files, but nothing more.

[jospoortvliet]

@ediazcomellas yes, we discussed this, and I entirely understand.

The problem is that without a trusted separate key generation mechanism (a HSM or hardware security module) this creates a security breach.

So, either have a HSM, or you will need to create a new account when the keys get lost.

In discussion with our customers I found out they were fine with this - of course, those who need it don't mind using a HSM and those who don't need it are happy to shortcut calls to their service desk by just telling people: "We can't do anything. Don't lose the keys, or we can only create a new account for you."

The TU Berlin for example prefers to say "nothing we can do" over having a reset option, because that will increase the number of calls and the amount of work as users will be less careful.

Your situation might be different - and a HSM might be required. We have not yet implemented this. If you need this in the short term, you can contact our sales team...

[Alphakilo]

@jospoortvliet I'm afraid this approach just isn't feasible with external authentication (LDAP, AD, ...).
While I do see that having an escrow key to do a full recovery of seemingly end-to-end encrypted files is a major security issue and a breach of trust on top, I don't see why either an escrow key or HSM should be needed to completely reinitialize encryption keys for a user.

There ought to be an administrative command to do just that. Having to create a new LDAP / AD object isn't an alternative.

Somewhat off topic:

[...] are happy to shortcut calls to their service desk by just telling people: "We can't do anything. Don't lose the keys, or we can only create a new account for you."
The TU Berlin for example prefers to say "nothing we can do" over having a reset option, because that will increase the number of calls and the amount of work as users will be less careful.

This is a very hostile mindset, straight out of the '80s. IMO this sentiment reflects very badly on our line of business. It has no place near service desks and it should absolutely not affect software projects that care about UX and usability in any way, shape, or form.
Having it echoed by a "people person and all-things-open evangelist" makes me cringe.