[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Sep 2019 17:39:27 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Telegram privacy fails again.
On Mon, Sep 09, 2019 at 11:16:37PM +0400, Dhiraj Mishra wrote:
> well-known feature of deleting messages, which allows users to delete
> messages sent by mistake or genuinely to any recipient. It was observed
> that once the message (image) is sent to the recipient, it still remains in
> the internal storage of the user which is located at `/Telegram/Telegram
> Images/`path.
[...]
> Assume a scenario where Bob sends a message which is a confidential image
> and was mistakenly sent to Alice, Bob proceeds to utilize a feature of
> Telegram known as "*Also delete for Alice*" which would essentially delete
> the message for Alice. Apparently, this feature does not work as intended,
> as Alice would still be able to see the image stored under `*/Telegram/Telegram
> Images/` *folder, concluding that the feature only deletes the image from
> the chat window.
[...]
> You're relying on a functionality that is broken since your file would
> still be present in storage for all users. Aside from this, I found that
> since Telegram takes `read/write/modify` permission of the USB storage
> which technically means the confidential photo should have been deleted
> from Alice's device or storage.
>
> A compete, app for Telegram which is WhatsApp also has the same
> feature to "*Delete
> for everyone*". If you perform the following steps mentioned above in
> WhatsApp it deletes the confidential photo from Alice's `*/Whatsapp/Whatsapp
> Media/Whatsapp Images/*` folder and maintains the privacy however Telegram
> fails. WhatsApp takes the same permission when it comes to storage which is
> `read/write/modify`.
A question here is what the intended behavior is. Another question is
what the users' reasonable expectations are.
Sender-imposed message deletion or expiry is necessarily unreliable: the
recipient might have taken a copy of the message prior to deletion e.g.
by taking a picture of the device's screen. This should be clearly
communicated to users of such features.
However, it gets worse. Sure, a reasonably informed sender knows they
effectively trust the recipient not to bypass the message deletion
or/and knowingly accepts the risk. But do they also realize the deleted
message can possibly be extracted from the device(s) by a third-party
later? This, too, should be clearly communicated.
And, speaking of intended behavior, a question is: to what extent should
the messenger app protect deleted messages from possible recovery?
Another question is: to what extent such protection is even possible?
Dhiraj's message implies WhatsApp does what it should while Telegram
does not. This might be so. However, without clearly stated security
(or privacy) properties the apps are supposed to have, we can't tell.
Sure, by common sense Telegram should also delete the file since it's so
easy to do and defeats such an easy bypass, but I doubt the expected
behavior is clearly stated anywhere for either app.
Quite likely, WhatsApp merely deletes (aka unlinks) the file from the
filesystem. If so, that does not actually wipe the file's content,
likely allowing for its recovery by a more advanced user (or attacker).
Even if it did wipe the file's content, it is almost certainly unable to
reasonably achieve that at a physical level through portable Android
APIs due to how modern flash memories work. For wear leveling, the
flash memory controller would likely allocate new physical blocks for
the new writes, and leave the blocks with the deleted file's content
untouched until a lot later (such as until the total writes from that
point on exceed the device's free capacity, which might be never).
Again, an even more advanced user (or attacker) would possibly be able
to recover the deleted and wiped file through vendor-specific low-level
access to the flash memory chip.
What can we do to make data deletion more reliable? One thing we can do
is only store the data encrypted, and to use per-datum encryption keys.
Then if we can reliably delete the key, the data is lost for good.
Can we reliably delete a key? That's similarly tricky. Some devices
provide a hardware key store separate from the main flash memory, and
maybe by reusing key slots we can in fact delete old keys. Or maybe
not. I'd like more research on this.
Besides, use of (only) a hardware key store with a low number of key
slots is incompatible with the need to have per-datum keys (rather than
per-app). You wouldn't comfortably reinstall the messaging app each
time you want to have greater assurance the deleted messages are gone.
(And you wouldn't impose this on recipients of your messages.)
So I welcome research on use of (large) per-datum keys and their
deletion from flash memory, like I had suggested in this tweet thread in
May 2018:
https://twitter.com/solardiz/status/1002264067887763456
<solardiz> Use case for >256-bit symmetric keys: temporary storage on flash media (e.g., extra key material, on top of OS key store, for messaging apps' DBs on Android) with key bits spread across files numerous/large enough that unknown order of known bits provides security after deletion.
<mik235> I think that's already what LUKS does. If it changes a lot, you end up with atomicity/integrity issues.
<ryancdotorg> Yes, LUKS uses something it calls "anti-forensic information splitting". I'm not sure what the default size is. Here's a paper describing the scheme (TKS1): http://clemens.endorphin.org/TKS1-draft.pdf
<solardiz> Thanks! I just read this paper. It's related, but different: it talks about blocks (not) surviving whereas I talk about the ordering of blocks not sufficiently surviving (it'll take some research to figure out the probability and how to improve it for real-world flash media).
<ryancdotorg> If I'm understanding correctly then, your unstated assumption is that a large enough key will not be stored in a predictable sequence of blocks on the physical flash, and that erasure of the file will cause the bookkeeping data containing the sequence to be lost?
<solardiz> Sort of. But I realize this assumption might not hold true, or not on its own, which is why I say "it'll take some research [...] to improve it for real-world flash media". Not storing in a predictable sequence feels easier, ensuring the bookkeeping is lost feels hard/unreliable.
<ryancdotorg> I'd be very interested in seeing some research on how this works out on real-world flash media. WRT Signal specifically, are you aware that it (at least on Android) stores the db key in the secure element? You won't be able to read it from a filesystem or flash dump.
<solardiz> Per the tweet thread below, this is a relatively recent change (compared to Signal on iOS) and the actual behavior is at best device-specific - I asked whether any (only Google's own latest?) Android devices do it already and got no reply yet. Do you know?
Quote Tweet
<solardiz> @moxie @CopperheadOS Per Signal-Android commit "Migrate from SQLite and ciphertext blobs to SQLCipher + KeyStore" from Jan 2018, it looks like that's when Signal for Android also started to use OS native key store. Does that also use a secure enclave on any Android devices?
<ryancdotorg> My understanding is that it uses the secure enclave if available, but I might be wrong. I don't know what's needed to support it device and os wise. From the API docs, it sounds like the KeyStore API decides how to store it. There's a ".isInsideSecurityHardware()" call.
(There were more branches of these Twitter threads at the time; I quoted
the one I found most relevant.)
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
