It’s 2023 and I’m still really shocked how hard it is to download all your iMessages and archive or search through them.
iMessage, explained
141–150 of 163 posts
Re: iMessage, explained
#142Re: iMessage, explained
#143Earlier quoted context omitted.
There are lots of choices depending on your community and desired feature set: whatsapp, fb messenger, instagram messenger, telegram, signal, discord, or the direct messaging features of other programs like Slack. imessage is an outlier in that it also has a bidirectional link with SMS. I just read today that FB messenger used to have this (who knew?) but no longer does. My reading of the EU's complaint is that if im…
Unless I’m mistaken literally all of these services are locked down too, and few have E2E encryption… iMessage is indeed “Apple-only” but the rest is on “all” platforms only for purely economical reasons, as much as iMessage is on Apple platforms only for the same reason. At least iMessage falls back to SMS (soon RCS) when available, which is much more ubiquitous than the rest tbh… If you truly want to avoid a lock d…
[dead]
Re: iMessage, explained
#144Gonna repeat myself since iMessage hasn't improved one bit after four years. I also added some edits since attacks and Signal have improved. iMessage has several problems: 1. iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy. If the endpoint is compromised at any point, it allows the adversary who has a) been collecting messages in transit from the backbone, or b) in cases where clie…
I didn’t realize signal was so secure. Is this common to ga even post quantum guarantees?
Could you please elaborate, I didn't quite catch what you meant.
Re: iMessage, explained
#145Earlier quoted context omitted.
The actual mind-blowing scale is that Apple's push notification service isn't just carrying iMessages. It's also carrying push notifications for every third-party messaging app. And the non-messaging apps with notifications too. And the silent internal notifications. You added a meeting to your calendar on your Mac? Push notification to your iPhone to tell it that the iCloud data changed and it needs to update. Chang…
Centralized notifications is not a "genius solution", it is the "only possible solution" for power-constrained devices, if you think about it. Same thing applies to Android: in ideal world it keeps a single connection open to GCM servers to listen for notifications for ALL apps on the device, and then routes messages to the appropriate applications they are intended for.
I never said centralized notifications is conceptually a genius solution. I said actually building a system that can handle so many billion notifications is impressive. I'm curious how it works internally...
Re: iMessage, explained
#146Gonna repeat myself since iMessage hasn't improved one bit after four years. I also added some edits since attacks and Signal have improved. iMessage has several problems: 1. iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy. If the endpoint is compromised at any point, it allows the adversary who has a) been collecting messages in transit from the backbone, or b) in cases where clie…
> iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy.
It's (probably, to my knowledge) true that iMessage does not have forward secrecy, but that does not follow from it using RSA:
You can have forward secrecy using RSA (e.g. by exchanging ephemeral RSA encryption keys and RSA-signing these using identity keys), and vice versa you may also not have forward secrecy with (static) Diffie-Hellman.
Ephemeral keys (and/or periodic key rotation) are what yields forward secrecy, not any particular encryption, signature, or key agreement scheme.
> * Uses Diffie Hellman + Kyber, not RSA
iMessage apparently uses ECIES in newer versions of iOS instead of RSA: https://support.apple.com/lt-lt/guide/security/sec70e68c949/...
Re: iMessage, explained
#147Absolutely amazing work.
Just one nit: Per the article,
> While the pair format is much more documented and easier to implement, it does not provide forward secrecy using “pre-keys” (similar to Signal) as the new pair-ec format does.
Is there any indication that (modern, i.e. ECIES-using) iMessage really uses pre-keys? As far as I can tell, it only uses a drop-in replacement of ECIES instead of RSA for the encryption (and maybe signature?) part, but that alone does not yield forward secrecy.
If there isn't, I believe this might be a misinterpretation of how RSA, Elliptic Curves, and forward secrecy relate. The Wikipedia article on iMessage seems to propagate the same mistake:
> The post also noted that iMessage uses RSA key exchange. This means that, as opposed to what EFF's scorecard claims, iMessage does not feature forward secrecy.
(The quoted reference actually makes no such claim.)
Re: iMessage, explained
#148Gonna repeat myself since iMessage hasn't improved one bit after four years. I also added some edits since attacks and Signal have improved. iMessage has several problems: 1. iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy. If the endpoint is compromised at any point, it allows the adversary who has a) been collecting messages in transit from the backbone, or b) in cases where clie…
While I will definitely agree that Signal is more secure: There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES. Beeper implements it, I never got around to backporting it to pypush proper. Also, the new Contact Key Verification (I believe it is the same thing as "key transparency" internally) should prevent the man-in-the-middle. A lot of the things you mentioned can actua…
> There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES.
Does that scheme definitely use ephemeral keys? Do you know if there is any documentation on it available?
> Beeper implements it, I never got around to backporting it to pypush proper.
Ah, thank you, this is important context! I looked through pypush and couldn't find anything that looks like it might be providing forward secrecy, so I was wondering if that was a misunderstanding of the impact of (only) switching to ECIES, as forward secrecy would require more than that.
Re: iMessage, explained
#149Earlier quoted context omitted.
remote attestation would mean it's not possible to pull out the binary and run it externally you'd need the key from the TPM/secure enclave too, which is much much harder to extract
TPM did not get key from nowhere. The key need to come from network or locally generated as long as it is not preloaded when manufacturing. And in either way, it should be possible to intercept/fake it.
> as long as it is not preloaded when manufacturing
which is exactly what happens
Re: iMessage, explained
#150Earlier quoted context omitted.
It's only a matter of time until a company starts selling TPM dumps, right?
maybe, but for a task like this it doesn't really scale Apple aren't going to allow one phone to attest 5000 new iMessage clients
That's... amusingly, also a thing in Chinese marketplaces, for a similar purpose.
iCloud Activation Lock, on non-cellular devices (eg, Wi-Fi only iPads), relies on the device's serial number, Wi-Fi MAC, and Bluetooth MAC addresses as the three identifiers required to clear the Activation Lock check. Via special debug cables (eg, a "DCSD cable") there are ways to write in new SysCfg data to the flash to change those variables. This can also be done to Apple Watches (pre-Series 6) with a special dock also sold on the Chinese market.
You can (sort of easily) get your hands on a "clean" serial/MACs set for under $10-15 or so on the market.