Right now you get away with spoofing basic integrity checks, but custom roms cannot pass hardware attestation. It's not a hard requirement right now in order to maintain backwards compatibility required to target 90%+ of android devices, but give it a few generations and it will be. At that piont I expect a majority of apps will simply be unusable on custom roms, and we'll have no choice but to embrace planned obsolescence.
So, once my smartphone dies, I'll be switching to a dumbphone.
Fairphone comes with a five-year guarantee for repairs and parts, so none of that early planned obsolescence, and it works with all the Linux mobile distributions I have had my eyes on.
What dumbphones you looking at? Everything retail I am seeing is a stripped down version of Android.
Some assembly required.
(this comment is most certainly not meant as any sort of defense of remote attestation)
But my point was that still doesn't indicate moving to a "dumb" phone. A dumb phone is just a locked down device with even fewer capabilities.
I'm quite annoyed that I can't watch HD movies on my phone but it's not as if I should toss it into the bin now.
My comment was suggesting that the majority of apps, not just banking/Netflix will likely adopt and require hardware attestation when 90%+ of Androids in use support it. Things like Uber/Lyft, Metro, food ordering, email, social media, etc are just as likely to pick it up and that's my point. No, it won't be a brick, but you'll likely lose quite a few apps.
[0] https://forum.xda-developers.com/t/mcdonalds-app.4067887/
So this is going to be the interesting question, because obviously they can, they just have to extract the keys from something first. Devices are made by all kinds of vendors and it only takes one vulnerability before you have a market for keys. There are <$200 phones, those cheap phones are more likely to have a vulnerability, and when one of them gets a cracked screen the market value drops to near-zero which makes it cheap to buy one to extract the key.
Which is also why remote attestation is totally worthless. An attacker can do the same thing, so relying on the attestation is completely insecure because in practice anyone with a couple bucks will be able to spoof it.
But if extracting a key is mildly inconvenient or legally questionable, it will be enough to deter honest casual users but not profit-motivated attackers, and you get the worst of both worlds.
So we need to do everything to make sure that doesn't happen. One way is to make extracting keys as easy as possible, of course.
Another is to make sure that everybody understands the perversity of this nonsense. It's snake oil the likes of export-grade encryption or EV certificates. Anyone caught using it should be mocked mercilessly and added to a list of disfavored vendors with uninformed security staff. Anything in a position to do so should warn if anything attempts to use it, or disable it to make it more difficult for anything else to rely on its availability. Warnings should emphasize that using it is a security risk that can enable hard to detect malware and is an indication of malice or incompetence.
It needs to go away.
And the attacker doesn't care if the key gets revoked after they've stolen your money.
it will also create a market for people selling and buying keys
it'll be like buying a grey market software key, you hop onto aliexpress, pay $5 and you'll have an iphone 11 attestation key
remote attestation as a process sows the seeds of its own destruction
Even if it's possible, that too will be a cat and mouse game which won't work for long. Hardware DRM has been an evolving industry, and now with the commonality of TPMs and HSMs it's here to stay.
HSMs often misbehave or leak data when operated out of spec, as when the OEM's cheap logic board has voltage drop. Moreover, using the same piece of hardware across a hundred million devices is its own vulnerability, because then that's the one everyone is focused on breaking, and when anyone succeeds now they can extract the keys from a hundred million devices.
> Even if it's possible, that too will be a cat and mouse game which won't work for long.
The nature of it is to be physical hardware, so vulnerabilities commonly require the hardware to be replaced. Now you've got an active vulnerability for the lifetime of that hardware, which is typically at least 3 years. Meanwhile they find new ones every year.
Preventing this may not even be physically possible. The key has to be inside the device and the attacker has physical control over the device. Even if the equipment needed to extract it is expensive, the device itself can't be if you expect everyone to have one, so someone with that equipment makes a business out of extracting keys and selling them over the internet.
> now with the commonality of TPMs and HSMs it's here to stay.
Nothing lasts forever. Especially if you make a good show of burning it to the ground.
Might as well buy an iPhone if that's how it's going to be.
For me this will be really bad if I’m traveling abroad since the website requires 2FA & SMS is the only option which will be roaming & even the annual number swap I do when I get a new SIM requires paperwork & waiting a week for processing. But maybe owning a phone is more of a burden due to lack of device control & privacy concerns.
That sounds quite doable? Basic sandboxing (flatpak/snap/whatever) and not assigning the tss group to system daemons will do that for you.
Hardware vendors could chose to, for example, make the keys available in printed form in an envelope with difficult to open without breaking vendor-branded seals that are expensive to manufacture in small quantities, and warn consumers not to open them if they don't know what they're doing.
This would prevent its use to lock consumers out from installing their own software on their own hardware, while still making it useful for legitimate applications. Consumers could chose to securely destroy the key if they wanted (with the caveat they could then not on-sell the device).
I would _love_ to stop programs from using my TPM against me, but I'm afraid DICE isn't it.
A computer I cannot choose what software I run and what state I expose to the software, and allow the software to impersonate the original software, is a SafetyNet locked-down device controlled by the owner of the TPM keys and programs running on it.
Taken in isolation your sentence is correct, I agree 100% with it: of course I want control over what runs on my computer. Of course the TPM is often used to steal that control away from me. Of course that is bad.
What made you think I don’t think that?
The evil part would need its own post, but frankly, other people have addressed this part much better than I ever could. Cory Doctorow's talk on The Coming War on General Computation is as relevant as ever.
Even then, TPM-like hardware can still be useful to me as a user, even if my computer is 100% Free Software. It is a shame though that its main use is stripping me of my freedoms instead.
Can't you already do that with an existing TPM? You just set an owner authentication password and an endorsement authentication password and no application can use it anymore unless you provide the password.
Technically it would still be possible to use it as a very slow cryptographic coprocessor I guess, but that benign and useless. It does still provide access to some platform measurements, but they can't be signed by a authenticated (or even safely stored) key, so they are easy to fake.
In addition to that the OS of course can be used to completely block access to it if needed.
The problem is not that people can't stop applications from using it, it is just that in practice people don't care.
How would one go about doing that?
To set the owner password (mainly for Storage) ``` tpm2_changeauth -c owner file:- ```
To set the endorsement password (e.g. to verify that the TPM is authentic): ``` tpm2_changeauth -c endorsement file:- ```
To set the lockout password (to recover the system without requiring a full reset): ``` tpm2_changeauth -c endorsement file:- ```
Then again, if you want to control what runs on your system, you probably don't run Windows in the first place.
Also if you want to stop Windows from booting, it's much more reliable to change the Secure Boot keys (and of course not adding the Microsoft keys afterwards). Then your system is guaranteed Windows free.
I could not care less about Microsoft's problem, but could this approach fix the major problem that I have with TPM?
TPM allows software to leverage my machine against me. If DICE allows me to revoke keys that have been stored for other applications (or, even better, to prevent the HSM from being used by anything without my overt permission), that might go a long way toward reducing that issue.