It can be a bit annoying to try and extract the interesting technical stuff from articles with quite a bit of conspiracy-shaded noise in them, but the dumbed-down summary is:
- Apple devices request signatures in order to perform software updates
- Those requests include the device's ECID, which is fixed per-device and used to generate the signature
- Those requests are sent in plaintext to the signing server
- As a result, it would be possible for someone snooping on internet traffic on something like a backbone to correlate an ECID with the IP address the request was sent from, and over time track the movements of a unique device between different IP addresses.
It is worth noting that the ECID is not considered secret information, though it is unique and unchangeable. This is also not a surprising revelation; the functioning of TSS and SHSH blobs has been well-known since the early days of iOS reverse-engineering.
The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device. Encryption would obviously have no effect on Apple's ability to access the data, so that's a bit of a red herring.
My understanding from the Apple security documentation is that they explicitly opted for using HTTP "rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmware’s attack surface." I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway, though I'm sure some kind of challenge-response process would allow the ECID to be encrypted either way.
But I can't see a reason that requests wouldn't be made over HTTPS outside of this environment by default; it might not eliminate the attack surface but would curtail it quite a lot. It would be interesting to know if there's a specific reason behind that decision. I don't really find it that convincing that it might be done deliberately such that essentially "someone watching a network backbone might be able to figure out what city your ECID is in".
> The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device.
There is a set of organizations in the United States which have access to unencrypted backbone traffic, all credit card processing transactions in the country[1] (since 2010 at least!), and every flight record in the country (via the ironically named "Secure Flight") program.
It's not a lot of database querying to take this "pretty low-resolution" data and begin to narrow down which ECIDs map to which PNRs map to which payment cards (which, thanks to BSA/PATRIOT, always map to government ID without exception) with $1000+ payments to Apple for shiny new M1 macs. It's even fewer if you can query Apple's sales database directly without a warrant or probable cause via FAA702.
If you don't think that sort of information is ripe for abuse, you're not thinking very creatively.
> I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway
The request does not come from the firmware. It's a full on normal macOS application process, in normal macOS, on the main CPU that's doing the HTTP requests. They could easily use TLS.
This is why it strikes me as so odd that Apple is still using plaintext here.
(I don't even think there is internet access available to the ASPs in the traditional sense.)
- Apple devices request signatures in order to perform software updates
- Those requests include the device's ECID, which is fixed per-device and used to generate the signature
- Those requests are sent in plaintext to the signing server
- As a result, it would be possible for someone snooping on internet traffic on something like a backbone to correlate an ECID with the IP address the request was sent from, and over time track the movements of a unique device between different IP addresses.
It is worth noting that the ECID is not considered secret information, though it is unique and unchangeable. This is also not a surprising revelation; the functioning of TSS and SHSH blobs has been well-known since the early days of iOS reverse-engineering.
The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device. Encryption would obviously have no effect on Apple's ability to access the data, so that's a bit of a red herring.
My understanding from the Apple security documentation is that they explicitly opted for using HTTP "rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmware’s attack surface." I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway, though I'm sure some kind of challenge-response process would allow the ECID to be encrypted either way.
But I can't see a reason that requests wouldn't be made over HTTPS outside of this environment by default; it might not eliminate the attack surface but would curtail it quite a lot. It would be interesting to know if there's a specific reason behind that decision. I don't really find it that convincing that it might be done deliberately such that essentially "someone watching a network backbone might be able to figure out what city your ECID is in".