Hacker News Reader

Comment by danrl | Hacker News Reader

A convenient first step for European governments towards killing effective end-to-end cryptography usage in everyday messaging. It used to be checks notes „terrorism“ and „child safety“ and now the hot new thing is „interoperability“. Who would have thought, that of all the above, „interoperability“ would be the one that makes it into legislation.

View on HN

Fact check: The Digital Markets Act explicitly calls out end-to-end encryption as a feature that MUST be preserved if the platform supports it.

From Article 7:

"The level of security, including the end-to-end encryption, where applicable, that the gatekeeper provides to its own end users shall be preserved across the interoperable services."

Is there more on this? Can this as is really be enough to maintain the security guarantees Apple currently provides?

What security guarantees do Apple currently provide?

I can't imagine much more than E2EE & maybe encrypted-at-rest (which is not a protocol-level feature anyway).

Well, the security coprocessor on every iPhone and Mac runs a formally verified operating system that manages the at-rest encrypted messages. Also, all software running on the phone is vetted before being allowed to hit consumer devices, which adds an extra level of security between malicious developers and kernel APIs.

There's no way Android will support that stuff across its entire ecosystem, so I guess it means the law is toothless? Maybe it means it will be up to each hardware manufacturer to ensure interoperability?

1. I don't think "formally verified" means what you want it to here. You mean there a hardware checks signature chain from boot to kernel, secure boot. Apple's software has too many security vulnerability to be considered "formally verified".

2. Android does support device attestation and secure boot. I 100% would love to see our future SMS replacement require frequent signatures from device attestation hardware (why not every message) and require E2EE messages.

It is a fork of this:

https://people.cs.ksu.edu/~danielwang/BAS/klein-2014-microke...

This is not the kernel that runs on the host CPU. It is the one that handles keys in the security coprocessor. I don’t know of many hacks of that, in practice. There was one where you could guess the pin, and use a timing attack to power down the chip before it persisted the “bad guess” count, which let people brute force pins (with special hardware).

It’s worth noting that the kernel Apple ships is a fork of L4; no idea if they’ve introduced bugs since the paper was written.

Didn't realize you were talking about secure enclave.

Encrypted at rest does not actually do anything against interoperability of protocols (as I put in my comment), a secure element/coprocessor is nice but still does nothing against compatibility. Even if the entire protocol is somehow in the coprocessor (ala BPF/SGX) there is nothing preventing the counterparty from running it on a regular CPU.

Interoperability can break security properties though. If I send you an iMessage, I can be confident that someone that steals your phone (while it is locked) cannot read that message (ignoring things like state-sponsored attacks).

Prolonged unsupervised physical access is usually already seen as a compromise. Regardless although there is a lot more publicity on Apple's "online attack" difficulty, it's mostly the same story on any semi-recent version of android[0] (barring any unknown zero-days/backdoors from specific manufacturers).

[0]: https://theconversation.com/what-if-the-fbi-tried-to-crack-a...

Apple currently provides no encryption at all when their users communicate with the owners of the 75% of mobile devices that are not Apple. Apple could do better for it's customers.

The way appositives work is that they qualify the preceding subject. Here you have two appositives so you can read "where applicable" as qualifying "including end-to-end encryption" or "the level of security." If "where applicable" is qualifying "the level of security" the staement reads "the level of security, where applicable, that the gatekeeper provides to its own end users shall be preserved accross the interoperable services." (And this seems to me the most accurate meaning. In any case it can be read that way.) Even if it is qualifying "the level of security" it is still in the end only "where applicable" which can still be read to mean the same thing. In fact, reading "where applicable" to mean "where already existing" as you implied, is redundant because it is already given in "shall be preserved" and "the level of security." Now we can read "where applicable" to imply that e2ee does not apply when the EU says it shouldn't.

Civil law countries don't like textualism. The spirit/intent of the law can often trump a literal interpretation of the text, so all this grammatical arguing is moot.

Even worse.

Care to explain why?

If we can ignore what the law says in favor of its spirit, then the law certainly means that the EU can "shut off" e2ee at any point, given their track record. Second, even if the above is false, it doesn't matter as whoever gets to decide "the spirit" of this law can say that it doesn't apply to terrorists, or doesn't apply durring x type of situation.

I'm curious about this too. At least now I have fairly decent confidence that when I send an iMessage to someone, Apple protects their identity to whatever standard they have. Whatever trust I put in Apple, at least it's a single point of failure.

What happens if interoperability is enforced and messages have to be end-to-end encrypted? Wouldn't that mean that any side-loaded Android app would have to be able to get hold of my friend's private iMessage key?

On iOS I guess you could still keep the key private through Apple's SDK, but what about other platforms?

The protocol is just registering a public key for each device to the server-side directory. A device-specific private key is generated and kept client-side on every device that logs in to iMessage.

Of course, that makes sense. So you could revoke the key for each app individually.

> On iOS I guess you could still keep the key private through Apple's SDK, but what about other platforms?

It's such a huge win for Facebook and Google - I'm not worried about "sideloaders", it lets them crack open the privacy of iMessage by simply having a view on conversations they can't see under the guise of interoperability.

The EU are just rolling a surveillance capitalist's wet dream with rulings like these.

Do you have any actual facts so this doesn't look like just another uninformed conspiracy theory in this thread?

You can continue to put your trust in only Apple: the DMA also says users should be able to enable and disable interoperability.

Why would a side-loaded Android app get a hold of a binary blob owned by another app, without the user granting such access explicitly?

Reply on news.ycombinator.com