81–90 of 163 posts
> In order to generate the “validation data”, pieces of information about the device such as its serial number, model, and disk UUID are used. Sadly, this is a clear sign the project is going to stop working eventually. At some point, the Apple is simply going to pull the plug. I remember doing similar tricks when I was a kid. Nowadays I simply won't even care trying. The problem clearly isn't supposed to be solved t…
Earlier 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…
Some of those services require individual opt-in to turn on e2ee. Some of them don't support e2ee for group messaging. Of the services listed that do support e2ee, I have the most trust in Apple's (well, Signal's, but..) being "actually" [0] and "only" [1] end-to-end encrypted. The entire basis of that trust is the money they've spent positioning themselves in the market as a privacy-focused brand.
Meta runs three of the listed services (whatsapp, facebook messenger, instagram), and their positioning is not exactly "privacy-focused". I haven't looked into Telegram much, but I would want to at least understand how they generate revenue before trusting them. Neither Discord nor Slack are what I would call privacy-focused. Signal is probably better than iMessage in terms of how much I trust their company, their clients, and their protocol, but its adoption is so vanishingly small among my friends that I stopped asking people if they used it.
[0] I've seen services in the past [0a] that have tried to argue that as long as every link is encrypted from originating client through servers to destination client, or from originating client to destination server, then it's "end to end encrypted"
[0a] https://news.ycombinator.com/item?id=21528437
[1] that is, not only are message contents (and as much metadata as is feasible) encrypted such that the same ciphertext passes all the way through the system and the recipient's client can decrypt the ciphertext, but also 1. the intermediary service doesn't have a copy of the recipient's secret key and 2. the plaintext wasn't encrypted also to a public key belonging to the intermediary service or some other party.
edit This other comment https://news.ycombinator.com/item?id=38537444 talked sense into me -- Apple doesn't seem to have designed iMessage to keep up with the times, crypto-wise. There's a huge, aging installed base that admittedly gets updates more often than any other competitor in their space, but that still means that iMessage has to be able to talk to them. I guess this is similar to the deprecation of SSL 0.9 and TLS 1.0; browser vendors collectively decided to kill them when a low enough proportion of servers were using them, but I don't know if Apple would be willing to cut off the older devices to make things better for owners of newer ones.
> When making an IDS registration request, a binary blob called “validation data” is required. This is essentially Apple’s verification mechanism to make sure that non-Apple devices cannot use iMessage. I wonder, will this be in violation of the EU's DSA and/or DMA once they are in force?
And I’m completely fine with that.
I just got an iPhone for the first time, and it is a noticeably better device than my previous Android phones. One downside is that I can't use iMessage on my Windows and Linux computers. Will look into pypush Honestly, the iPhone is nudging me further to giving a Macbook/OSX a try one day, but the major blocker to me is the poor state of gaming on Macs.
Gonna 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…
https://security.apple.com/blog/imessage-contact-key-verific...
My prediction is that Apple will start to use attestation (device check) to lock down iMessage. The problem is that this would require a software update for older devices.
They already partially do. > Warning: In order to generate the “validation data”, pieces of information about the device such as its serial number, model, and disk UUID are used. This means that not all validation data can be treated equivalently: just like with Hackintoshes, the account age and “score” determine if an invalid serial can be used, or if you get the “customer code” error. The "customer code" error is a…
you'd need the key from the TPM/secure enclave too, which is much much harder to extract
> In order to generate the “validation data”, pieces of information about the device such as its serial number, model, and disk UUID are used. Sadly, this is a clear sign the project is going to stop working eventually. At some point, the Apple is simply going to pull the plug. I remember doing similar tricks when I was a kid. Nowadays I simply won't even care trying. The problem clearly isn't supposed to be solved t…
Reverse engineering is a valuable art that can't be learned just from a canonical reference for "the right way". It cultivates the same skills used in debugging.
> In order to generate the “validation data”, pieces of information about the device such as its serial number, model, and disk UUID are used. Sadly, this is a clear sign the project is going to stop working eventually. At some point, the Apple is simply going to pull the plug. I remember doing similar tricks when I was a kid. Nowadays I simply won't even care trying. The problem clearly isn't supposed to be solved t…
Not to be too harsh (maybe to be somewhat harsh given I had such a distaste for what you wrote?), but why would you post this on a site called Hacker News? I can't think of a better implementation of the "hacker ethos" than this project: look at a hard problem, and when the "straightforward" approach doesn't work, find a workaround.
More to your specific point about "Apple is simply going to pull the plug", there are technical and business reasons why they might not want to, at least not quickly. First, as mentioned in the other Beeper thread, there are lots of older Mac devices without a secure enclave, and breaking Beeper would likely break them as well. Second, from a business and regulatory perspective, Apple might have to do a careful dance regarding how to shut this down without looking blatantly anti-competitive.
Gonna 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…
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 actually be solved on the pypush side: there's nothing preventing pypush from alerting you when a new key is inserted, or providing you with the fingerprints of each of the keys.
I'm not an expert on these things, but I do think it is time that another analysis by a proper cryptographer was done: the one you linked was from 2015, and a lot has changed since then.
Anyway, the point of iMessage is convenience, if we're being honest here. It provides a reasonable level of security that will keep out all but the most entrenched and determined attackers, and that's really all most people care about.
Gonna 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…
> 7. iMessage allows undetectable key insertion attacks. https://security.apple.com/blog/imessage-contact-key-verific...
https://restoreprivacy.com/apple-to-introduce-contact-key-ve... apparently states that but I'd rather have something official.
Also it seems to be opt-in, at least for now https://9to5mac.com/2023/10/27/turn-on-contact-key-verificat...