Comment by jt2190
6 hours ago
Why is attestation always bad, all the time? When two people interact there’s a trust/risk calculation on both sides. Isn’t attestation just a means of reducing risk for both parties? (We can debate who should control the attestation process and how it should work but your point 1 suggests that there is never a good form of attestation.) What would we do instead?
> When two people interact there’s a trust/risk calculation on both sides.
You should never base your trust on the other party having a piece of hardware that has restrictions that you approve of. That is fragile, especially in a world where some people are better at making or modifying hardware than others. It is also a fundamental violation of basic freedoms to prevent people from modifying hardware that they own, and not something you can reliably police, and thus is a terrible way to establish trust from a technical perspective.
It's much better to base trust on established cryptographic methods on a protocol level. You treat them as a black box, and the trust is established by the inputs and outputs, not what's inside the box. An example of this would be handing them an image of a digital ID paired with a cryptographic signature that only the government holds the private keys to. They have no computationally viable way to edit the image and still have it match the paired signature. It's easily verified based on the government's public key, and they cannot re-sign it without the government's private key. It doesn't depend on hardware restrictions.
The fact that there is so much focus on hardware means there are likely deeper motives here, e.g. surveillence being dressed up as convenience.
I cannot think of any company that has appropriately used attestation as a trust/risk calculation. I work in major game studio; there is never calculation only a binary.
It never „let`s check if the mobile user has purchased in-game content server side to prevent pirating it“, its „suspend any account that has signed in with a device that fails safetynet, permanently ban any account that has failed a jailbreak or root checks“
It never „let`s check and calculate statistically cheating probability and move damage calculation server-side so that player cannot godmode or modify their APK“, its „all non-stock phones are cheaters and fraudsters, ban all of them, use invasive anti-cheat, while continuing to have client sided damage and health and energy because it is easier“
Something else has to change first otherwise the only option for businsinses do will be, after 2 is implemented : „while yes it is now possible to allow a neutral third party to control attestation, someone higher-up such as legal has said ONLY google can and we will ban everyone else“
As long as it is easier to don't give a fuck, that is the option that will be taken. z.B. the only reason our publisher allow the removal of play services was finding out that chinese players on definitely not google certified phone spends the most by orders of magnitude and even then it is only relaxing the check for specific region, forcing all EU players to continue to have this checking.
I would be wholly unsurprised if the result was to continue to require attestation but allow GrapheneOS f.e. only in Motorola factory shiped phones and disallow it if the user was involved in any way in the installation of it.
Suspending accounts of people who used Grapheme and not refunding them would lose you a lawsuit if you're in Europe
> permanently ban any account that has failed a jailbreak or root checks
Nice
It's an anti-competitive concern all the time.
If we gatekeep service access to specific implementation attestations, it becomes much harder for new implementations to emerge. It doesn't really matter who controls the process.
In that sense, it's always bad. In this specific scenario for example it directly blocks emergence of alternative Android ROMs and Android-mostly-compatible devices like the various Linux phones.
There may be times where that downside is worthwhile, but it's always a downside, and we should very strongly discourage attestation wherever possible on that basis for the health of both the tech ecosystem and the business market around it.
Only acceptable use of attestation is when done on behalf of device owner. So if they let me submit list of keys allowed for my account, fine, but any other use is just evil restriction of what software I can run on my own devices.
Definitely not bad all the time. For instance, GrapheneOS provides the Auditor app, with which you can verify from another phone or from a server that the OS is not tampered with. It also uses remote attestation.
So, there are certainly useful applications.
I question the usefulness of Auditor. It can flag if a modified version of GrapheneOS has been booted, for example. But flashing a modified version of GrapheneOS requires erasing userdata, which you'd notice the moment all your data isn't there. Unless someone uses an exploit, but Key Attestation cannot detect exploits.
I suppose if you've bought a device with GrapheneOS already installed, you can use it to verify the installation. But that could also be achieved by reflashing a known-good image yourself.
Largely agreed. Though I think there are useful applications: 1. the one you mention; 2. to protect against installation of a malicious image (e.g. because your browser/certificate store compromised); 3. a sophisticated attack where an attacker knows your credentials at some point (e.g. PIN), extract your data when the phone is unattended, flashes a compromised image, and restores the data (with the goal to surveil your phone).
Admittedly, most of these are probably nation state-level attacks, but I think some GrapheneOS users are the target of such attacks. Also, it doesn't hurt to run Auditor after a fresh install to protect against the second scenario. It only takes a minute, better safe than sorry.
A hypothetical useful use of attestation is that a company promising to process personal data securely could actually prove it to end-users, by open-sourcing their server-side code and using reproducible builds combined with remote attestation, to prove to the client that the server-side is running unmodified within a secure enclave.
I struggle to think of a useful use for it on the end-user client side, though.
Isn’t the client-side case something like “the banking app you’re entering your account password into is the binary the bank created and not a compromised binary that will drain your bank account”?
This is kind of already the case on Android.
If you've installed RealActualBankApp (with the ID of real.actual.bank.app) once (from whatever source!) then there cannot be another app installed with that same id but signed with a different public key (oversimplified version of the story, there is a key rollover scheme).
You can however install an imposter app that's also called RealActualBankApp, with the same icon. It'll need to go by a different ID.
So then we're down to the same problem, or pseudo-problem, of identity confusion, as we have for banking website URLs. Where is the ID/URL shown, and does the user know that it should be mybank.com and not mybank-incorporated.com ?
1 reply →
No, this would just require a publicly verifyable signature of the software, and the user would just choose to have their operating system verify it. No remote attestation or other hand-over-your-controls necessary.