Hacker News Reader

Comment by sneak | Hacker News Reader

It's crazy, because Apple already maintains a backdoor in the e2ee crypto of iMessage which permits them to read all iMessages and attachments and scan them serverside for CSAM (if they desire).

iMessage endpoint sync keys (for "Messages in iCloud") are backed up in the non-e2ee iCloud Backup (on by default), allowing Apple to use those sync keys from the backup to decrypt iMessages and attachments in realtime.

Note that enabling e2ee iCloud Backups (a new feature) on your device won't close this hole as the conversation partner for each iMessage is also escrowing keys.

I assume this is just brand marketing for Apple.

View on HN

"Advanced Data Protection" is an optional feature you can enable for iCloud that makes that not true. See the table at https://support.apple.com/en-us/HT202303 and note that iCloud Backup (including device and Messages backup) stores the keys on your trusted devices only when Advanced Data Protection is enabled:

"Advanced Data Protection: iCloud Backup and everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key."

These sorts of laws make Apple not able to support Advanced Data Protection in jurisdictions that pass them.

Except Apple can remotely execute any code they want on your phone at any time. That is how proprietary software works.

If Apple is ordered to ask a given device to return all keys in plain text, it can. So can any Apple employees also on payroll for state actors.

Yep same for Google/android and Microsoft devices

> Except Apple can remotely execute any code they want on your phone at any time. That is how proprietary software works.

No, that's not how any code works, proprietary or open source.

I've written proprietary software for 16 years, and none of it could remotely execute any code that I want.

Their OS may give them that capability, or it may not. There is no way to know.

There actually is a way to know. People can and do reverse engineer the code on device. I've done it myself many times.

I would also note that unless you compile an open source project yourself, there's no guarantee that the compiled product you download from an open source project actually came from the publicly available source. If you want to get all conspiratorial, I suggest that you're not conspiratorial enough. ;-)

If Apple is somehow dumb enough to leave an unscrubbed/unfuzzed backdoor in their shipping version of iOS, I'd almost be inclined to call it a red herring.

It stands a reasonably safe assumption that Apple has been compelled to add obfuscated adversarial code to iOS, just as you can assume BitLocker is about as secure as a Masterlock made out of Swiss Cheese.

No, it's not a safe assumption, and it's not clear that you even know what you're talking about, technically.

You use terms like "unscrubbed", "unfuzzed", "obfuscated", but what do you think they mean exactly? For example, how does "unfuzzed" relate, if at all, to https://en.wikipedia.org/wiki/Fuzzing

I think the core conclusion is perfectly sound. Apple is a capable company - they would not let the user discover malicious code unless they wanted you to find it. They intend for people to reverse-engineer their systems and run it through IDA, Ghidra and Cutter. Tools exist to mitigate that discoverability, and I think it's foolish to assume they don't use them.

The only safe assumption seems to be that they are hiding something. Proving the contrary requires tools we may never have.

> Apple is a capable company - they would not let the user discover malicious code unless they wanted you to find it.

Apple is not capable of magic, or the impossible.

> Tools exist to mitigate that discoverability

Citation needed.

> The only safe assumption seems to be that they are hiding something. Proving the contrary requires tools we may never have.

You can assume whatever you want, but with no evidence whatsoever, I wouldn't call it "safe", I'd call it "irrational".

Also, you didn't answer my question, which suggests that I was right about your not knowing what you were talking about.

> Citation needed.

There are hundreds of commercial and open methods for obfuscating a program during compilation. Since Apple controls Ring 0 they can also obfuscate syscalls and network traffic if they want. I'd ask you if I'm wrong about this, but you already seem convinced.

> You can assume whatever you want, but with no evidence whatsoever, I wouldn't call it "safe", I'd call it "irrational".

It's perfectly rational. Apple already does this in China. We know the CIA, FBI and NSA have a common interest in weakening all domestic cryptography. Taking Apple at face value when so many other FAANG companies have been embarrassed by PRISM revelations is a fool's decision.

It will be irrational once we know for certain that Apple doesn't aid spying on their users. Until then, I figure I'm a safe skeptic. Pending evidence, both of our claims are equally substantiated. Only the uninvested parties have nothing to lose here, though.

> We know the CIA, FBI and NSA have a common interest in weakening all domestic cryptography.

To the extent that the CIA, NSA, or FBI have an interest in weakening cryptography, it applies at least as strongly (more strongly for most of them) to foreign cryptography, so I’d probably drop the modifier “domestic” from that sentence.

You're not wrong about that. The history of their interference with domestic corporations is why I add that in, though. They do have an interest in weakening all cryptography, but the ones they're best-suited to compromise are the ones relying on domestic trust.

> There are hundreds of commercial and open methods for obfuscating a program during compilation.

Obfuscation doesn't make reverse engineering impossible, only a little more difficult.

> It's perfectly rational. Apple already does this in China.

Does what exactly?

Remember, the original claim was "Apple can remotely execute any code they want on your phone at any time."

> Taking Apple at face value

I never said to take Apple at face value.

> It will be irrational once we know for certain that Apple doesn't aid spying on their users.

Which you claim is impossible to know forever, making your belief totally unfalsifiable. How convenient.

> Obfuscation doesn't make reverse engineering impossible, only a little more difficult.

Sometimes it works pretty well. It's easy money to wager the community doesn't fully understand iOS from a reverse-engineered best-guess. Especially if their adversary is a multi-trillion dollar company who anticipates reverse engineers.

> Does what exactly?

Violate their venerable "Commitment to Privacy".

> the original claim was "Apple can remotely execute any code they want on your phone at any time."

It is undeniably feasible, yes. They control the modem, have complete ring-zero knowledge and can send arbitrary data to and from your device. That qualifies pretty much everything needed for remote code execution. If they send data to the iPhone that exploits a decoding bug like NSO Group, then feasibly yes you could execute arbitrary programs on the device, using an unmodified OS image. Nevermind just a regularly installed backdoor.

> Which you claim is impossible to know forever, making your belief totally unfalsifiable. How convenient.

I've been wrong before! Let's both hope I've got their character wrong and we get to see the truth someday. Until then we're squabbling over unknowns. It's not my habit to put faith into the unknown, but to each their own.

> Let's both hope I've got their character wrong and we get to see the truth someday.

How would we ever "get to see the truth someday" on your conspiracy theory, if the truth happens to be that there's not actually an intentional remote code exploit?

That's my point: you've made yourself immune from the facts. You can't ever be proved wrong, by your own criteria of "proof", which posits that Apple always has the ability to avoid detection.

You could reverse engineer everything on -one- phone and one version of software and be confident every single CPU instruction involving crypto sufficiently random, in constant time, and not being exfiltrated. This is a -massive- effort, that would also need to rule out hardware backdoors and use some cutting edge techniques, but say you did it.

Now a dissident is targeted. Their phone is sent a special OS hotfix no one in the world has reviewed and that compromises the random number generator at a CPI microcode level that would take months of targeted reverse engineering to detect, then relevant messages are decrypted over the wire with the now weakend keys. It then reverts itself when done making detection that much less likely.

Whoever has the signing keys make the rules... or anyone who can give secret orders to those holding the signing keys.

> Now a dissident is targeted. Their phone is sent a special OS hotfix

You're moving the goalposts. What you originally said, which I objected to, was "Apple can remotely execute any code they want on your phone at any time."

In other words, Apple can remotely execute any code they want on my phone and your phone and everyone's phone now.

Anyone that has automatic software updates enabled, the default, yes.

And if you disable those you will not get security updates, thus allowing everyone access to execute code on your phone.

You do not need to compile it yourself. The build just needs to be deterministic and compiled by multiple independent parties you trust. This is the entire point of the reproducible builds project. Participating projects make themselves immune from a single release engineer executing whatever code they want on end clients.

iOS has automatic updates enabled by default. All Apple has to do is make an update available for the device in question that has whatever backdoor in it they want. They can easily make updates available only to specific devices.

Any iPhone in a default configuration will happily download and install it.

This is RCE (with a slight delay).

Automatic unattended upgrades are on by default in iOS. The configuration wizard flow still has the screen that used to prompt you about them, asking for consent, but now it doesn't give you the choice, it just tells you it's going to update automatically. It's up to you to go into Settings after setup and disable it if you don't want Apple to be able to push new and unknown code to your device arbitrarily.

> This is RCE (with a slight delay).

Eh, that's really a stretch of the definition. Hardly anyone installs software via physical media anymore, so doesn't mean that all code execution is remote code execution?

"Software updates are RCE" is not the greatest take.

> It's up to you to go into Settings after setup and disable it if you don't want Apple to be able to push new and unknown code to your device arbitrarily.

Which you can do very easily.

Regardless, every user notices when Apple has shipped an OS update, because your device rebooted.

Furthermore, software updates can still be reverse engineered after they're released.

They notice there was an update, but they have no clue if that update just decrypted all their messages then reverted itself along with all evidence. If this is just done on select targets, capture and detection is highly unlikely.

A court order on whoever controls the Apple signing keys could do this. I would wager that this is already happening in China since the CCP took control of the signing keys.

If a system is not open, accountable, with distributed reproducible builds each adding their own signature, then you are in fact granting a central party access to execute any code they wish on your device if you accept updates without reverse engineering every single CPU instruction, driver, firmware bundle, and microcode change in every update bundle and sideloading them by hand somehow... which Apple does not permit.

> I would wager that this is already happening in China since the CCP took control of the signing keys.

Which signing keys are you talking about?

The various ones for CPU microcode, drivers, OS images, firmware, firstparty and third party app store updates. Any of these has the power to sign code that will compromise your messages.

Where in the world did you get the idea that the CCP took control of these?

> Regardless, every user notices when Apple has shipped an OS update, because your device rebooted.

I would venture to say that these users notice because of the notification that says "Your device has been updated to iOS <version>", not because of the 2 AM reboot.

That notification, of course, being entirely within Apple's discretion.

Apple can effectively silently run whatever code they want on most iPhones and iPads.

> I would venture to say that these users notice because of the notification that says "Your device has been updated to iOS <version>"

That's what I meant.

> Apple can effectively silently run whatever code they want on most iPhones and iPads.

You may feel that this is a powerful argument, but I'm completely unimpressed by it when anyone can easily go into Settings and turn off automatic updates. ¯\_(ツ)_/¯

I'm not a fan of automatic updates, especially as the default setting, but that's not because I think Apple is going to send down some secretly evil update. Rather, it's just because updates can break stuff that the user relies on, which is no secret.

So the defense you suggest, is for everyone to never accept updates to any software again? Are you serious?

I'm not suggesting any "defense", because I'm not suggesting any attack. You're the one suggesting an attack. I'm worried about Apple making the OS crappier, but I'm not worried about Apple attacking me, or anyone else for that matter.

Once again, you said, "Apple can remotely execute any code they want on your phone at any time", which is what I replied to. Until you're willing to admit that you misspoke, we're done here.

Someone has the signing keys for Apple os/apps, baseband drivers, oma-dm toolkits, etc.

Whoever that is can sign whatever they want, send an update notification targeting a single user, and the phone will then execute anything as instructed.

A court order could tell whoever holds those signing keys to sign something to decrypt all messages, or install a dummy encryption key, or make the random number generator always return 42.

Just because Apple has successfully gaslighted the courts by claiming they cannot decrypt phones, does not make it true.

Supply chain attacks on a proprietary system lacking reproducible builds and public accountability is indistinguishable from remote code execution as a service.

> Whoever that is can sign whatever they want, send an update notification targeting a single user, and the phone will then execute anything as instructed.

That wasn't the claim. The claim was "Apple can remotely execute any code they want on your phone at any time." In other words, Apple can do it right now, on your phone, without any software update. And there's zero evidence for this claim.

Software updates are not remote code execution. Moreover, users can choose not to install software updates.

> Software updates are not remote code execution. Moreover, users can choose not to install software updates.

However, automatic software updates are, as Solarwinds learned, and this is on by default on iOS, meaning that Apple can indeed execute code on all iPhones in the default configuration without user intervention.

Executing code remotely via default-enabled automatic updates with some delay, or via an ssh command with less delay, the result is the same. Someone chooses to run code on your client, and it runs.

The semantics do not impact the threat model here so who cares?

As I already said, "users can choose not to install software updates". So no, Apple can't "remotely" execute any code they want on your phone at any time, when you've made the simple, easy choice to change your Settings. This is not just "semantics".

This discussion is getting pretty tiresome to me. You and sneak want to redefine all software updates as "remote code execution". That's complete BS IMO, and I'm never going to agree to that redefinition.

If you fail to apply updates, then you fail to apply actual security patches to stop RCEs -anyone- can use. In exchange you agree to allow apple to execute any code they, or anyone coercing the key holders, want.

You can play semantic games, but the end result is the same under a threat model that does not trust any single entity to run code of their choosing on your device.

A supply chain attack is the correct term for this, but a supply chain attack is, in effect, and RCE path available to anyone in the supply chain.

Saying supply chain attacks are not a form of RCE because you can disable software updates is like saying no RCEs exist because you have the choice to disconnect from the internet. Security discussions should be grounded in threat models over semantics.

> Security discussions should be grounded in threat models over semantics.

There's no evidence that Apple is a threat.

You claimed that Apple could already remotely execute any code at any time. That sounded very sinister, as if Apple had added a secret back door to the OS, but it was extremely misleading at best, completely false at worst. Yes, Apple can ship software updates, as we all know. But that's not a threat in itself.

I don't want to hear what Apple could theoretically do. Your lover could theoretically kill you while you sleep. How's that for a threat model? Are you going to sleep alone for the rest of your life? I suspect it's actually more likely, though, than Apple shipping the malicious OS update that you fear.

> A court order could tell whoever holds those signing keys to sign something to decrypt all messages

No, I'm not a lawyer but my understanding is that this is compelled speech and is not permissible.

You do not have to incriminate yourself under US law, but corporate property is not the same as personal property. The NSA very likely could compel Apple to give up their signing keys if it came with an executive order citing national defense objectives... or more probably they will just manipulate the RNGs of the HSMs Apple uses, or get a special contract with their supplier, or bribe a release engineer. I know people who have been party to such arrangements first hand.

Any system that relies on a single private key with SPOFs in the supply chain should be considered compromised, if the targets it governs are high value.

The CCP did not need to do anything cloak and dagger and simply mandated overt access to Apples HSMs for chinese users.

No, please see my third paragraph. Your conversation partners are still escrowing their endpoint keys, allowing Apple to continue reading your iMessages.

Approximately nobody has this on because it's not default, so even if you enable it, ~100% of your iMessages are still readable by Apple (and by extension FBI/DHS without a warrant).

What is a "conversation partner"?

The person to whom you are sending your iMessages.

Actually most people are stuck on the free 5GB iCloud plan, and the backup will never complete because there isn't enough space.

This is only the case if you’re using iCloud backup for your phone, although yes that’s kind of annoying - presumably this is a usability issue and there use.

Happily there’s now advanced data protection option - though you the docs go into great detail on the “if you forget everything all your data is gone forever” usability problem.

Apple has done a good job balancing security and usability here.

I can see e2ee being default/recommended for people with iCloud family accounts though as every family member can be part of the account recovery process.

Reply on news.ycombinator.com