Comment by AppAttestationz
1 day ago
The title is misleading.
App attestation does not require an Apple account nor a google account. For Android, it does limit the ROMs to Google certified ones and requires GMS to be installed if Play Integrity is used. An alternative option, would be to use the Hardware Attestation API directly, GrapheneOS would be thanking you.
I've spent a good amount of time implementing exactly this type of system for a backup service.
his document specifies a way to cryptographically attest the integrity of a HTTP request hitting a server.
The attestation proves the request came from a device and attest the legitimacy of the bootloader, OS and app.
Google and Apple are in a privileged position to be able to bypass the app attestation though, so depending on the threat model, it's not bulletproof.
edit: Play Integrity could the worst offender here, as it can be leveraged to force a user to have installed the app through the Play Store. Indirectly, requiring a Google account.
There's no such thing as "legitimacy of the bootloader, OS" that can be verified by someone who isn't the device's user. The bootloader that booted the phone I type this on is patched by me, which makes it more "legitimate" than any other bootloader that could be placed there.
The reason (or, depending on your inclinations, the excuse) for trusted computing to exist is not to guarantee that I didn’t patch the bootloader of the phone on which I type my comment; it’s to guarantee I didn’t patch the bootloader of the phone on which your grandma logs in to her bank without her knowledge.
No, the reason is to let application providers decide which platforms you can run their software on. The reasons why they need that are diverse: DRM, preventing reverse engineering, shifting liability, "cheating" prevention - to name a few, but ultimately they're all about asserting control over the user, just motivated differently in various use cases. "Think of the grandmas".
15 replies →
You can bicker about the words all day long. Legitimacy, or perhaps better: authenticity, in this context, would be a bootloader or OS that doesn't allow tampering with the execution of an app.
Any bootloader or OS that doesn't allow the user to tamper with it or the other tools they're using on it is obviously illegitimate malware.
2 replies →
Sorry but this is nonsense - most users, even the Linux toting power users - don't have the time, ability or knowledge to verify the contents of their OS in a way that would catch issues prevented by attestation.
The problem with modified phones containing malware is very real and unless you want a full on Apple "you're not allowed to touch the OS" model you need some kind of audited OS verification that you as a user or a security sensitive software can depend on.
No, what you're saying is nonsense. I can burn a key into efuses of this phone to make it only boot things signed by me and make the whole boot path verified, OS image immutable etc. and all of this can provide me some value, but it's absolutely not in my interest to let applications be picky on what can or can't happen in the OS (even if they would accept my key being there rather than Google's, which they won't). The only thing it manages to do is to prevent me from using the device the way I want or need it to be used.
2 replies →
There's also a problem with unmodified phones containing malware, namely an operating system made by an advertising company, which is designed to collect as much information about you as possible.
And this malware is largely based on open source code (Linux) that was originally developed on open, documented hardware, where the firmware boot loader did nothing more than load the first 512 bytes of your hard disk to address 0x7c00 and transfer complete control to it.
Yes, there were viruses that exploited this openness, but imagine if Linus Torvalds would have needed a cryptographic certificate from IBM or Microsoft to be allowed to run his own code! This is basically the situation we have today, and if you don't see how dystopian this is, I don't know what more to say.
I will never understand why such an overwhelming majority of people seem to just accept this. When frigging barcodes where introduced, there were widespread conspiracy theories about it being the Mark of the Beast -- ridiculous of course, but look at now where in some places you literally can't buy or sell without carrying around a device that is hostile to your interests. And soon it will be mandated by the state for everyone.
Google must be destroyed.
2 replies →
> App attestation does not require an Apple account nor a google account. For Android, it does limit the ROMs to Google certified ones and requires GMS to be installed.
To me, there is no difference between your sentences. You require the blessing of an American company to be able use eIDAS. Google has the power to disable eIDAS at a national scale by making the attestation services treat all devices as not certified.
There should be NO reliance whatsoever on a private company not under the control (direct or indirect) of the government let alone a foreign private company.
Edit: I just noticed your username and the fact that your account is very new. Are you astroturfing?
I made an account because I'm qualified to talk about this topic :-) I've spent a considerable time testing every corner case of UX, and DX of an app attested service.
App attestation can fail on simulators, Graphene OS, dev builds, I've seen it all. There is one check you can do to see if an app was side loaded, so indirectly, can require Google account.
Title is still misleading though, as it explicitly mentions accounts.
Come September, there will be no side loaded apps on Android.
2 replies →
I agree, there is still a reliance on the tech giants that produce the phones, who are the o'es embedding the cryptographic keys, to make this end to end attestation work.
But in pure technical & UX terms, you don't need to be logged in.
[flagged]
3 replies →