Let us assume I added a second device and a hacker (via malware etc.) has stolen the backup from Delta Chat to add a third device (without the user knowing).
Is there a way to shut the third device (and possibly also the second) to access to the future Delta Chat messages the user writes? I assume the already sent messages are already leaked, but I would be interest if I can avoid leaks of future messages in this scenario?
Another setting (but same outcome) would be countries at the airport would download and extract somehow the delta backup and add just another device to eavesdrop. (For this setting there might be an alternative of burner account etc.)
however, there are also some prior discussions for that, in general, it is doable, but it is not super-easy, as there is no central device or server (as on signal, whatsapp, telegram) or server that rules everything.
to mitigate the attack vector, already today, you need to enter your system secret on mobile before a backup or “add second device” is possible, so a shortly handed out phone, or accidentally left unlock is not enough for the unwanted party.
Thanks a lot. I definitely think it is worthy feature.
Currently my options would be to create another account and let everyone know (which might be challenging).
Unfortunately, I am currently not in the technical details of Delta Chat, so I cannot contribute now to possible solution ideas (I am happy though to review).
However, as far as I understood each device acts independently, so there seems to be a way to identify it. Maybe also the malicious actor gave a confirmation on the old device, so it is not visible to the user that this has taken place and the user may only find out later.
So the problem is about:
Being able to remove a device from accessing the server and messages
Doing cleanup work (key rotation for new messages and key should be available to the accepted devices)
On the device message part - I do not seem to receive it if there was a manual backup transfer.
Additionally, one could, for example, send a message if a new device is added to the existing devices and require that one of the existing devices sends a confirmation message (maybe signed?) - if that confirmation message does not come or any of the devices denies it then it should not access the server (and key should be rotated as the actor may have access to the server via (possilby legal or illegal) means.
As r10s has already said, this requires either a centralized server or a binding to personal data such as a mobile phone number. I can only propose a modest solution to reduce the likelihood of compromise, namely creating a master key during profile creation. After that, if an attacker attempts to create a backup or clone the profile, Delta Chat would request the master password to proceed with the process.
salt = random
key = KDF(password, salt, cost)
verifier = HMAC(key, "DeltaChat master key check")
I understand that there is already a system-level lock on Android. On Windows, however, it is possible to steal the blob and decrypt all the contents using the portable version. Still, it’s better than nothing — at least in cases where the attacker knows the system password.
The only thing that can realistically be done at the moment — and I have suggested this before — is at least to know the number of active sessions. For example, if Delta Chat were to send an email at least once a day to the user’s own address containing information about the current device with a specific subject line, the client could then display this data in the “Connection” section (where the current mailbox size is shown): the device name and the last session time. In other words, the time when the last email was sent would indicate when that device was last active in a session.
Perhaps it would make sense to rename this feature to “Add Additional Device” to raise awareness that it can be misused. Many users may believe that DC only allows two devices.
The new name would clarify that the profile can run on any number of devices simultaneously, making it especially important to securely archive backups and to be particularly vigilant with DC-Desktop in public places.
Furthermore, it’s obviously also a great feature that most messengers don’t have. A name change would emphasize this.
I agree being aware of multiple devices is a good add-on already.
What about two keys, e.g. the normal key (which is also in the backup) and a recovery key (which can be generated securely from a seed of clear text words). The recovery key is only displayed initially to the user (“please store it somewhere safely” - user has to print it, store it somewhere else etc.). The recovery key is not stored with the app. The recovery key could be used for an “out-of-order” reset of the normal keys and could be used to encrypt the new normal key (whatever makes sense, I am not in the Delta Chat code), so only devices where the user can enter some recovery key can use the new key. Probably I have not considered here all threat scenarios.
So in the end something DELTA_MAFIA already proposes.
Unfortunately, I am not aware of a similar system, but I guess we must find something in existing research that says what is possible and what not.
This could be also designed as an opt-in feature…
I do not think the current device protection mechanisms help a lot - as essentially all Androids and iPhones etc. have been largely broken when in other hands.
I think the simplest solution would be to implement a password prompt in DC-Desktop before adding an additional device and to encrypt backups in all versions. The latter could be done like in Threema for Android. Users would have to choose a password before each backup, which would then be used to create an encrypted ZIP archive.
In my opinion, changing the name would be a very simple measure to strengthen security awareness and at the same time highlight a feature that not every messenger has.
Due to password protection, someone who has brief access to the device cannot install the profile on an additional one. If an attacker steals a backup, the profile cannot be set up on any other device without the password.
In addition, security awareness is always necessary. However, users must know that a profile can run on an unlimited number of devices. The way this feature is named now is misleading people!
I see yes a password would for sure also help. It does not address all scenarios, but some of them.
Yes security awareness is needed, but malware and other malicious acts can happen. It would be then good to know what options one has or how one should work in the first place (e.g. having multiple accounts etc.).
I am not sure on the naming. I posted it originally in another forum. Maybe one needs to see if we talk about the same feature or different features. Probably password-protection would be a new different feature from what is discussed here.
I’m not an expert at all in DeltaChat, but if with DeltaChat I use a normal e-mail server there is a possible way to disable all “devices”, it is to change the password. Then I can update the password on the devices I want to keep-on using, and they should regain the ability to work. Am I wrong?
So, I think that an option to “change credentials to access the server (this will disable any other device)” should be implemented. Then the “add additional device” function should implement a check: if it detect that the identity is already present on the second device, it only updates the credentials, otherwise it copies everything as usual.
Of course, this means that if someone gains the access to one of my devices, they can “change the credentials” and lock me out of my own DC identity, but at least I’d be aware of the attack.
Does this proposal make sense?
Edit: the answer is “no, it doesn’t make sense”.
On Delta Chat, your identity is tied to your public key cryptographical key pair, not to any single relay you use to send and receive messages per se. I.e., the hash fingerprint is the identifier, not the email address.
This means even if you lock out a malicious device from a single mailbox, they can just add another relay and keep sending messages in your name (including ones that induce others to route their private and group messages towards the malicious actor, not the updated mailbox) and if they ever get into a MITM position may also be able to decrypt all incoming messages as long as forward secrecy is not implemented. You will have better luck with a workaround such as:
I’m not sure I understand all the details of your “clone profile“ proposal, but you are right: “identity is tied to cryptographical key pair” and “they can just add another relay“. My “solution” is not a solution.
I agree that this is a desirable feature. My concern is that for long-lasting identities, I will have multiple devices where one of them may get lost/stolen. What I would (ideally - if possible in the decentralized setup) do is:
Understand what devices have been added as 2nd devices
Invalidate (a subset) of 2nd devices from a master account.
Another option would be to (a) have a master secret / key that is stored offline and bound to an identity (“revocation secret”) that allows me to revoke all copies of my key/identity and (optionally) replace it with a new one.
Without multi-relay, this could be stored in “the relay” and broadcast to anyone receiving messages from this account. With the multi-relay feature, I understand that an attacker could switch relays and therefore avoid being revoked. I see that this would require some thinking and may not be solvable for all scenarios. Example: A compromised 2nd device is on an Internet Island (behind a great firewall) and no revocations will be able to get onto the island from outside.
An alternative (that reduces availability) would be to implement limited-lifetime of identities. I.e. an identity expires after a while and one needs to refresh the identity using the “revocation/master secret/key”. This would ensure any 2nd device that is no longer related with “the master” would display as being expired after some time. Probably - in real life - the effect would be that most users would not understand this idea and will continue using expired identities. After a while, users will get use to everyone using expired identities ;-/
i do ask without actually knowing properly how the encryption work here, but does rotating the encryption key, do not (in some sort of way) allow to disable any “second device”, in the fact ?
you warn the contact of a new, key, contact move to it, and you send a password change request to the relay.
Thay actually “exclude” any one that had access to a seconde device, as the device that required the change would be the only one to have the “new” access.
So the user can after that relink the device he trust ?
Edit : an added benefit, this “key rotation” can be reused when delta move to new encryption key (like post quantum etc).
OpenPGP key has a primary “identity” key which is used for signing, and “encryption” subkey. Rotating “encryption” subkey is definitely possible, even though it is tricky in multi-device case because you need all your other devices get decryption key somehow.
Just changing the encryption key on every device is possible, but this will create a “split brain” situation, there will be no way to distinguish you from an attacker. Attacker can do the same, rotate the key and lock you out.
For a situation of compromised key what you want is probably revoking the identity key.