Companies such as Google and Apple promote hardware-backed key attestation as a security measure for protecting mobile apps and APIs.  This approach ensures that cryptographic keys are stored and used within secure hardware components, such as Trusted Execution Environments (TEEs), Secure Elements (SEs), or hardware security modules (HSMs). We will look at the limitations, why this must never be used alone, and explain why if it is used, verification must always be off the device. 

The FIDO Alliance promotes open standards for passwordless authentication. FIDO2 defines how an authenticator (e.g., a hardware security key or a device with a Trusted Platform Module) provides cryptographic proof of its identity and capabilities to a relying party (such as an online service). Yubico is an example of a company that provides an actual hardware key you can use with laptops or mobile phones and if you have a recent PC there is a good chance you have a Microsoft compatible HSM already in place. 

Our friends at Guardsquare also recently published a blog on the topic "Verifying OS Integrity with Hardware-Backed Key Attestation" presenting a methodology that, while technically sound in its description of attestation mechanisms, exhibits major shortcomings in addressing the complexities of modern mobile security threats. Critically, in this methodology, the verification of key attestation results are on the device, and this immediately opens up a new attack surface for hackers. The approach ignores the well-documented fact that mobile devices—no matter how "secure" they claim to be—are ultimately user-controlled environments, inherently vulnerable to sophisticated attacks such as root exploits, privilege escalation, and runtime manipulation.

Inherent Limitations of Device Based Security

Reliance on device-side attestation as a foundational security measure overlooks the fundamental reality that mobile devices, regardless of their hardware-based security features, are susceptible to sophisticated attacks. Once an attacker gains control of the device, they can compromise all resident security mechanisms using run time techniques. For instance, advanced root hiding techniques, combined with OS vulnerabilities such as CVE-2024-20015 and CVE-2023-42824, have demonstrated the ability to bypass attestation mechanisms like Google's Play Integrity API and Apple's App Attest. Attackers can manipulate the device’s state after the boot process, therefore rendering any boot verification useless. In addition, the level of support and implementation details vary on different types of device and of course, keys are device specific - a new device can mean new keys need to be generated. 

The Critical Role of API and Backend Security

Another significant oversight in the proposed methodology is the neglect of API and backend security. Modern mobile attacks often target APIs and cloud services, exploiting vulnerabilities to launch large-scale attacks. Just to be clear, even with hardware-based key attestation, an attacker who has access to a valid, attested device could abuse APIs (e.g., by running a malicious app on a genuine device). Attackers can extract API secrets, reverse-engineer app behavior, and utilize botnets to automate attacks. Therefore, security measures must prioritize the verification of requests at runtime and at the cloud level. Secure cloud attestation, which validates requests before they reach the backend, is a crucial component of a robust security strategy. 

Vulnerability to Runtime Manipulation

Even if hardware-backed key attestation were infallible, it would still fail to protect against runtime threats. Tools like Frida and Magisk enable attackers to dynamically modify application behavior, bypass detection mechanisms, and even forge attestation results. Therefore, security measures must incorporate runtime protection techniques, such as:

• Dynamic code obfuscation: To prevent reverse engineering and code tampering.
• API security enforcement: To validate and authorize API requests.
• Behavioral analysis: To detect and respond to anomalous application behavior.
• Runtime Application Self Protection (RASP): To detect and prevent attacks during execution.

Solutions like Approov mobile attestation add additional checks beyond hardware key attestation by continuously verifying runtime integrity.

The Need for Cloud-Based Mobile Attestation

Leading mobile security frameworks emphasize cloud-based attestation as a critical component of a comprehensive security strategy. Solutions like Approov focus on enforcing security at the API level, ensuring that only verified, untampered app instances can interact with backend systems. This provides scalable and effective protection against a wide range of mobile threats.

A cloud-based approach keeps any validation steps hidden from the device and app, where they can be manipulated.

This also allows policies, secrets and certificates to be updated immediately, avoiding any need for app updates or issues with device firmware dependencies. 

So Is There a Role of Hardware-Backed Attestation?

While hardware-backed attestation is not a full solution, it does provide value. It can be used as one layer of a multi-layered security approach. It can detect some forms of device tampering, and provide a signal to the backend that the device has had some form of verification. However, as we explained, it should never be used as the sole method of verifying the integrity of the application.

Hardware-backed attestation should always be integrated as part of a broader attestation solution. It is however critically important to evaluate how this works in practice in order to eliminate any threat of manipulation. For example, if the hardware-backed evaluation is built into the app, then the attacker may still be able to access and control the environment which reports that a key pair is “good”. 

Approov, on the other hand, verifies the certificate chain as part of the overall attestation. Crucially, this is an off-device step - there is no way for an attacker to interfere with the result. After the check, Approov adds the public key to the Approov token. With Approov in place, the app can use the generated key pair to sign messages that it issues to a protected back end. This elevates the application of key attestation to its intended function - verifying the origin of messages to a protected server. 

Additionally, Approov’s other defences all contribute to establish trust that an app is the original untampered and legitimate version. Key attestation is used to bind that trust to a single instance of an app.

So yes,  there is a role for hardware-backed attestation, but only if it is integrated in a way that doesn't open up other potential attack surfaces on the device.

The Need for a Multi-Layered Approach to Mobile Security

So hardware-backed key attestation can be a valuable tool in a comprehensive mobile security strategy. However, relying on it as the sole security measure is insufficient and potentially dangerous. Developers must adopt a multi-layered approach that includes:

• Secure cloud attestation: To protect APIs and backend systems.
• Runtime protection: To defend against dynamic attacks.
• API security enforcement: To validate and authorize API requests.
• Regular security audits and penetration testing.

By adopting a holistic security strategy that addresses the full spectrum of mobile threats, developers can significantly enhance the security of their applications and protect their users' data. Using key attestation with other security layers, such as device attestation, certificate pinning, anomaly detection and API protection is the right approach.

Approov are experts on app and API security. We would be happy to set up a call to see if we can help you quickly and effectively improve your mobile app security.