GrapheneOSApple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too.
Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition.
The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it.
Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web.
Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems:
Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web.
Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more.
Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive.
Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on FreeBSD instead. You'll just be more locked out.
Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it.
Play Integrity API is highly insecure and it isn't particularly hard to temporarily bypass it. There are frameworks for spoofing the software checks and leaked keys for bypassing hardware attestation can be purchased. However, bypasses are getting harder and are becoming increasingly short lived.
It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source.
Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them.
Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security.
reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that.
This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere.
Services shouldn't ban people from using arbitrary hardware and operating systems in the first place. Google's security excuse is clearly bogus when they permit devices with no patches for 10 years but not a much more secure OS. It's for enforcing their monopolies via GMS licensing, that's all.
Unified Attestation is another anti-competitive system being pushed by multiple European companies. It will similarly lock people out from using arbitrary hardware and software. That's not a solution and is far worse than Android's much more open hardware attestation API.
Android's hardware attestation shouldn't be used to lock out users not using specific hardware or OSes. However, the fact that it permits arbitrary roots of trust and OSes at least allows services to permit more. Google could use it to permit GrapheneOS for Play Integrity if that was about security.
M/KΞ 🇪🇺@GrapheneOS if it was about security this system would be more close to Https certificate (not identique of course for obvious techical reason) than what google make now (with themselve as sole capable certificate controler).
ZaZen@GrapheneOS It is not. Nothing is about security, everything is about device lockdown so surveillance becomes unescapable. This is the ultimate goal of the system. It is quite evident on all fronts. Mobile, desktop, consumer electronics, vehicles etc. Only servers seem to get a lighter treatment because they are used by corporations.
vvanagIt is a proof that governments, banks and companies are one and the same.
Resilience Theatre@GrapheneOS You're just doing it wrong. Using current mobile hardware and android as base is just wrong approach. Happy to talk about this f2f.
Matúš@GrapheneOS We really need to start using containers for running the OS itself instead of flashing the OS. Shameless plug but LosOS (https://gitlab.com/losos-linux) does that.
@dasmatus AOSP and GrapheneOS already heavily use sandboxing throughout the OS and are in the process of heavily adopting hardware-based virtualization for isolation. Running an operating system in a container or VM doesn't help with attestation but rather makes it substantially harder to pass from apps doing detection of emulation and virtualization via anti-tampering. A large part of the Play Integrity API software checks are focused on detecting emulation or virtual machines.
@dasmatus It's worth noting the Play Integrity API software checks are largely not enforced up front but rather used to detect spoofing and the enforcement comes later. This prevents being able to know exactly how it was caught via GPU fingerprinting, etc. They don't care about small scale spoofing and wait until it's larger scale to take actions to stop it which is often done in a far more naive way than how it was detected. Over time, they're making it stronger and bypasses shorter lived.
@dasmatus The software-based checks alone are already impractical to bypass reliably over the long term. The hardware based checks where leaked keys from exploiting a TEE/SE are needed to bypass them are a whole separate story. They shipped a DICE-based remote provisioning model years ago for the hardware checks and that's going to make future leaked keys much less valuable due to their short lives so it will be necessary to keep leaking more which they can start cracking down on over time.
Mr. Scam Likely@GrapheneOS I am fucking furious at the attempted murder of the world wide web and open internet, and I swear to god I will become the grumpy old man using meshtastic email over digital HAM if I have to!
Just Bob
Linux Is BestIt's the goal.
For example, all those new laws for age verification are to prevent you from using an operating system or ROM that cannot be minored or controlled. Blocking reCAPTCHA on a non-approved, non-certified government and corporate sanctioned devices is just 1 piece of the big picture.
For example, the USA has made any new router not made in the USA illegal to import or sell. They can apply for an exception if they agree to include their new control chip or firmware.
Motorola has a security contract with the USA.
They will, depending on need, release a device with GrapheneOS — or delay it — and work closely with you to identify the methods and vulnerabilities you discover, as well as how you implement features to overcome the planned “new normal,” so that, behind the scenes, they can undermine and circumvent your work in the future. The investment — which includes you — is intended to strengthen relations and acquire additional contracts. 😭
Daniël@Linux @GrapheneOS Do you have a reference for that? You might be mixing up Motorola Mobility with Motorola Solutions, which are two separate companies.
I am the source.
Both Motorola Mobility with Motorola Solutions CAGE Code: 01113, 6H7Z2, 78205, and 7H229 (NCAGE).
If you’re looking for an actual document that says, “Yes, we’re trying to screw over the American people,” a written confession in a convenient PDF file, you won’t find one. Ever.
Yes, and money goes both ways.
@Linux Motorola Mobility is a subsidiary of Lenovo and definitely doesn't have the relationship you're describing with the US government. Motorola was split up in 2011 and Motorola Mobility was acquired by Lneovo in 2014. You're confusing entirely different companies together, not that it would make sense regardless since GrapheneOS is open source. They don't need to do anything special to see what we're doing.
@GrapheneOS
So true! One little thing: This would also be bad if it weren't a bogus excuse. Because Remote Attestation in a device for the general public in itself is evil, and it will always be abused. The whole purpose of Remote Attestation is to enable a service to ban people from using arbitrary hardware and OSes. And in extension, to ban people from using arbitrary client apps for those services.
So true! One little thing: This would also be bad if it weren't a bogus excuse. Because Remote Attestation in a device for the general public in itself is evil, and it will always be abused. The whole purpose of Remote Attestation is to enable a service to ban people from using arbitrary hardware and OSes. And in extension, to ban people from using arbitrary client apps for those services.
@thomas Using attestation doesn't imply allowing only a specific set of hardware and operating systems. That's not at all implied and isn't even possible for an implementation only providing pinning-based verification rather than root-based verification.
Ox1de@GrapheneOS @thomas I’m going back to bed
@GrapheneOS i complained on many official service they ignore it, the ombudsman was called and they seem to ignore it too.
they all aswer the bullshit that you are labelled insecure by official tool, because google tool automatically mark non licensed OS as insecure regardless of their actual security.
Papageier@GrapheneOS Google has the entirety of its commercial success thanks to the openness and interoperability of the #WWW. To try an captcha it to build a walled garden is, frankly speaking, an act of disrespect for @timbl and the entire web community.
Microsoft has tried it. Apple has tried it as well. Both have finally had the insight that working with the community is much more rewarding and profitable than working against it.
Let's work toward Google having that same revelation as well.
(Sorry for the pun, couldn't resist)