For example, I use my SIM embedded digital signature on my mobile phone. Being able to verify that it’s not altered with, and being able to verify this state with a remote secure entity sounds nice.
Assuming you can select/provide the baseline state to be verified against, I fail to see how this is harmful.
Of course this can be used to force “desired configuration” on anyone, but this is a social problem rather than technical.
> Of course this can be used to force “desired configuration” on anyone, but this is a social problem rather than technical.
No, remote attestation as laid out with escrowed keys is a technical vulnerability through and through, which upends the existing social power relationships. You wouldn't write off the installation of police surveillance cameras in your house a mere "social problem" even though you could still organize politically to create restrictions on their use. Rather the social aspect only becomes an issue due to the addition of the technical ability (vulnerability).
Key-escrowed remote attestation is fundamentally a rejection of the longstanding concept of mediation by open protocols. Right now, the demarcation point between independent parties is what goes over the wire. On my computer I run software that represents my interests, on a server a company runs software that represents their interests, and we temporarily cooperate by communicating in a well-known manner.
No matter how powerful the remote entity is, they still cannot force me to run software contrary to my interests. Sure they can make it harder by only shipping proprietary executables and obfuscating the protocols, but ultimately if the interaction is important enough then it can be reimplemented in Free software to appropriately represent users' rights.
Meanwhile, key-escrowed remote attestation lets each party insist on what software the other party can run while they're communicating. Of course, an individual user will have zero negotiating power to affect what software a company is running, just as end users have zero negotiating power to cross out objectionable terms in those blobs of legalese shoved at us. Rather, commercial services will be provided on the same take-it-or-leave-it basis, then with the addition of mechanically enforced conditions of only running specific software. Once this is easy enough to do that insisting upon it will only marginalize a small number of customers, companies will reflexively adopt it - remember, "security" departments love checking boxes.
Facilitating key-escrowed remote attestation on Free operating systems undermines our hard-won freedoms, and splits the Free software market-power bloc. Right now, a basic binary-distributed Firefox-on-Ubuntu user appears essentially the same as a user who has modified their software. The basic Ubuntu user is happy to be running Free software, but if we're honest it's more of a theoretical/upstream concern until they start hacking. However, if Ubuntu gets the vulnerability to attest exactly what software it's running, then that's a stark difference between them. The basic Ubuntu user won't notice that they have lost some freedoms they weren't using, whereas the smaller contingent of people that wish to run modified software will have directly lost FSF Freedom 1.
The only way to keep remote attestation honest is for there to be no privileged signing keys embedded by the manufacturer. Ideally the end user would prompt their generation, but if initial keys are created at the factory then nothing about them (including the public identity) must be recorded.
Then there would be no way for a random third party to tell if you are running on bare metal hardware, or within virtualization with mock attestation. True owners of the hardware can still record the signing keys and build their own trust relationships. But no centralized databases that would allow arbitrary third parties to trust that users' own hardware is undermining user interests.
