Hardware Attestation: A Developer's Look at Monopoly Risks

Hardware-based attestation, a technique designed to verify the integrity and authenticity of a computing device, is rapidly gaining traction. Initially, it promised enhanced security, ensuring that software runs on trusted hardware in a known, secure state. However, recent developments, particularly from major platform providers like Apple and Google, suggest a shift in its application. What began as a security measure is increasingly being seen by some as a mechanism to enforce platform lock-in and stifle competition, creating a duopoly in the mobile ecosystem and extending its reach to the wider web.

The Expanding Reach of Centralized Attestation

Apple's App Attest API and Google's Play Integrity API are prime examples of this trend. Both systems aim to provide services with confidence about the devices interacting with them. Google's Play Integrity API operates with different levels of integrity, with "strong integrity" explicitly requiring hardware attestation. Over time, the requirement for hardware attestation is gradually expanding, even for the more commonly used "device integrity" level. Apple has already established this as a core requirement for its App Attest API.

These systems rely on a trusted execution environment (TEE) or secure element (SE) within the device's hardware to generate cryptographic attestations about the device's state, including its bootloader, operating system, and installed software. The attestation is then verified by a remote server, which can decide whether to grant access to the service based on the received integrity verdict. This centralized control over device verification gives platform owners significant power.

Attestation's Leap to the Web

The implications of hardware attestation are no longer confined to mobile applications. Initiatives like Apple's Privacy Pass, which brought attestation to the web to aid with CAPTCHA verification on Apple devices, paved the way. Google is following suit with plans to integrate similar broad hardware attestation into the web. A notable example is Google's reCAPTCHA Mobile Verification, which proposes a system where desktop users on Windows, Linux, or other systems might be required to scan a QR code with an iOS or Google-certified Android device to pass reCAPTCHA challenges. This effectively extends the mobile duopoly's control to desktop web interactions, making access to vast portions of the web contingent on owning a specific type of mobile device.

Beyond Security: Enabling Monopolies

While often framed as essential for security, critics argue that these attestation systems primarily serve to disallow users from running hardware and software not approved by Apple or Google. The case of GrapheneOS, an alternative Android-based operating system known for its security focus, highlights this argument. GrapheneOS is explicitly banned by Google's Play Integrity API, not due to any inherent insecurity, but because it does not license Google Mobile Services (GMS) and adhere to what GrapheneOS describes as anti-competitive rules. This stands in stark contrast to the fact that Play Integrity permits devices that may have received no security patches for a decade.

Bypasses for these systems exist, ranging from spoofing software checks for device integrity to acquiring leaked keys for strong integrity. However, these bypasses are becoming increasingly difficult to maintain and are often short-lived. The real utility, therefore, appears not to be in providing impenetrable security, but in creating a strong barrier to entry for competing mobile operating systems and hardware, effectively locking users into the Apple-Google duopoly.

The Role of Governments and Public Services

Adding another layer of complexity, governments and financial institutions are increasingly mandating the use of mobile apps that leverage Apple App Attest and Google Play Integrity for critical services like digital payments, ID verification, and age verification. This direct participation by public and commercial services in requiring these attestation schemes further solidifies the market dominance of Apple and Google, turning what should be a choice of device and operating system into a mandatory gateway for essential digital access.

Technical Nuances and Alternatives

It's important to distinguish between the core hardware attestation technology and its implementation by platform owners. Android's underlying hardware attestation API, for instance, technically supports alternative operating systems and roots of trust through verified boot key fingerprints. This means a service could, in theory, be configured to permit a secure alternative OS like GrapheneOS by recognizing its verified boot keys. GrapheneOS has even documented how apps can utilize this more open aspect of the Android API. However, Google's Play Integrity API chooses not to leverage this flexibility, instead enforcing its GMS licensing requirements. Other initiatives, like "Unified Attestation" pushed by some European companies, are also viewed with concern, as they aim to create new centralized authorities for device approval, potentially leading to similar lock-in.

Practical Takeaways for Developers

For developers, understanding this landscape is crucial. When designing applications, especially those requiring strong security or identity verification, consider the broader implications of relying solely on centralized attestation services. Advocate for and explore authentication methods that are open, allow for diverse hardware and operating systems, and prioritize actual security posture over adherence to specific vendor ecosystems. This might include supporting FIDO2 standards or designing systems that can verify device integrity using more flexible, verifiable roots of trust. Services should not, by default, ban users based on their choice of hardware or operating system, especially when more secure, non-certified alternatives exist.

FAQ

Q: What is the primary difference between Play Integrity API's "device integrity" and "strong integrity" levels? A: The "device integrity" level primarily relies on software-based checks to verify the device's state. The "strong integrity" level, however, requires hardware-backed attestation, leveraging a Trusted Execution Environment (TEE) or Secure Element (SE) to provide a more robust, hardware-rooted verification of the device's integrity.

Q: How do these attestation systems impact alternative operating systems like GrapheneOS? A: Systems like Google's Play Integrity API often ban alternative operating systems, even highly secure ones like GrapheneOS, because they do not comply with the platform owner's specific licensing requirements (e.g., Google Mobile Services). This means users on these alternative OSes may be blocked from accessing apps or services that utilize these attestation APIs.

Q: Are there more open ways to implement hardware attestation? A: Yes, the underlying Android hardware attestation API itself supports allowing arbitrary roots of trust and alternative operating systems by enabling services to verify their specific boot key fingerprints. This allows for a more open approach where a service could explicitly permit a variety of secure OSes, rather than being restricted to a platform owner's certified list.