Hacker News Reader

Comment by arilotter | Hacker News Reader

AFAIK they are using a reverse-engineered Apple binary that does the real iMessage - and since Apple doesn't update apps outside of iOS updates, Apple can't, in theory, patch it without also breaking iMessage on older iPhones.

View on HN

I'd have assumed there'd be something more going on in iMessage, like each device has a private key that needs to sign the messages, and Apple can ban any private keys that leak -- but in theory couldn't they even be prevented from leaking by secure enclave?

I'm just speculating on what would have made sense, but I'm guessing that's not how it's working since Beeper Mini exists. It begs the question: why isn't that the way they do it?

You're asking why cryptographic attestation isn't a requirement to use a service that still supports >10-year old x86 Macs?

Yeah? Asymmetric cryptography has been around a lot longer than a decade.

That's the foundation of attestation, not attestation itself. Macs did not ship with a TPM, and had no facilities for hardware chain-of-trust until the T2 chip in 2017.

But you don't have to have everything in place to do the basics. Use private keys stored normally on the device. If they get stolen or leaked, brick iMessage on those devices and show a message saying, "Your system has been compromised and can't use iMessage until you visit an Apple Store or call 1-800-..." Then just hand out a new private key at the store or over the phone with little friction, but track which customers are given new keys and how often. If there's a trend of someone receiving a bunch of new keys, investigate them before issuing more.

Or just allow a user to obtain a new private key via their iCloud account and associate the key with that account so that it can't be used to send messages unless you're signed into that account.

Newer devices that can protect their keys don't need that, and you phase the old process out over time.

Oh, so what you're saying is equivalent to "Apple should have cryptographically signed serial numbers/UUIDs, instead of accepting user-generated values"

But they already have a record of which serial numbers were actually sold (at least since some point), signing a device token/private key would be redundant and allowing user-generated serials to sign in with degraded trust is a policy choice.

Got it. Well that makes sense for older devices.

Messages has existed longer than the Secure Enclave has.

Secure Enclave doesn't have to exist for the rest of the system to work as I described. (And once Secure Enclave does exist, it can be used to further secure the private keys generated after that date.)

Without Secure Enclave, remote parties (the servers) can't know where the key material came from. I'm assuming because old devices pre-SEP have to be supported, Beeper is exploiting this since there's no required residency or provenance attestation for the keys.

The Intel Management Engine has existed since 2008. Did Apple laptops/desktops avoid this for significantly longer than that?

Reply on news.ycombinator.com