@alecmuffett On devices where updates bring antifeatures (e.g printers newly banning 3ed party ink) people have long known to block updates.
Under these scenarios, you get a known good snapshot OS and KEEP IT. If the device cannot be defended against hackers except by periodic factory reset, stop using it for shopping, banking, or secure communication.
@LukefromDC
The problem is that Apple is between a hard place and bad place.
They literally brag how they their platform under their thumb. So whenever little fascist states decide upon stupid ideas they need to implement, it's the China CCP scenario again and again: Apple needs to deliver and deliver promptly.
And because they have their platform nailed down like that, it's just a question of time till they'll start forcing upgrades on devices that are "not legal".
@LukefromDC
The reality bad part of the "force device manufacturers to break devices by law" is that the different jurisdictions can potentially force manufacturers to change their designs globally.
So then to end up with devices and software being shipped with hundreds of binary blobs for "age verification", "id checking" provided by authorities dormant. Absolutely brilliant from an ItSec perspective.
Trust us that age verification module from @alecmuffett
the Peoples Republic of North Korea is totally benign, and there is absolutely no legal reason it should not be sitting dormant on the secure mobile phone that President of the United States uses.
Oh sure it's loaded only once during initialisation like all the others to query it off it recognizes itself relevant for the locale.
Totally benign and harmless.
But unused shared libraries are additional attack surface for exploits.
@alecmuffett @LukefromDC
@alecmuffett @yacc143 This actually goes all the way back to the MS "Palladium" proposals for locked computing circa 2004, which came complete with failed proposals before Congre$$ to ban unlocked/older computers from the Internet.
MS ran into a problem: an internal document revealed a plan to first lock law firms to MS Office by changing the file format to an encrypted proprietary one, then making MS office subscription-only. This was way, way before Office 365 keep in mind. It blew up in their face, because the basic idea was to hold all files at law firms hostage for presumably very high subscription fees.
Secure boot was a limited implementation of Palladium, but with the antitrust law of that time we forced MS to require that "windows certified" x86 computers must be able to unlock the bootloader and we also got the ability to enroll user-generated keys. Some but not all phones (a decreasing percentage) also got this.
Pixels did-and the reason it is hard for cops to modify a captured Graphene phone they capture to log and report a passphrase or boot into an OS they control is the use of secure boot with Graphene's own keys. Secret Service and NSA are presumed to have Google's keys, but Google's keys cannot unlock Graphene.
The normal rule remains however that possession=root, and any device that has been unsupervised in enemy cannot be trusted for wartime or "felony level" purposes. I have destroyed such phones myself.
Suppose that F15 pilot shot down over Iran today was carrying a Graphene phone and it landed undamaged in the bushes.Suppose Iran returned it to the USAF? Would anyone in the Air Force not appoinrted by Trump be dumb enough to boot it?
They'd probably get away with it short of an exploit against the TPM itself, but the risk would still be there. ANY other phone, forget about it: unlocking it would also be presumed to unlock the copy of the filesystem held by the adversary that "returned" the phone.
@LukefromDC
Ah there is an issue with grapheneos. You literally pointed out yourself, the "TPM" element on the pixels.
Or more general with the concept of secure enclaves.
Who guards the guardians.
With the pixels we only have the weasel words of Google that the TPM has no backdoor. While we know that the legal system in the USA could more or less force then to backdoor it for national security purposes.
Secure enclaves in intel, AMD, and arm @alecmuffett
friend on remote hardware attestation signed with keys manager by companies under US control or that were at least in the past owned by such.
(I mean the enclave mechanisms that are available on clouds for secure private processing)
From a non US perspective there is little computing that is not US intelligence risk tainted.
@alecmuffett @LukefromDC
Wait until you find out about ARPAnet.
@yacc143 @alecmuffett Which is why a phone going through pol-ICE/CBP/TSA custody should be destroyed without being booted, even Graphene.
Cellbrite has said their tools can't get in, but copying the encrypted filesystem, modifying the bootloader to capture and message the passphrase somewhere, and then "returning" the phone is a presumed workaround until proven otherwise.
The TPM does not store the passphrase, rather it stores the keys used to validate the bootloader and OS. A TPM exploit thus does not directly defeat the encryption but does allow the above attack, which has been called an "evil maid" attack.
Alec Muffett
LukefromDC
Andreas K
