Basics

Remote attestation lets a trusted verifier check the integrity of a remote, typically untrusted, prover. Integrity checks can be done at: the firmware level (microcode, BIOS), the operating system level (kernel image, driver), and the application level (executable, dynamic library, configuration file).

The security assumptions of remote attestation are as follows:

• the provers come with pre-installed attestation code;
• the attestation code running on the provers can be trusted;
• the provers and verifiers share a common cryptographic secret.

Hardware-based attestation relies on a hardware root of trust. Examples of these are a Trusted Platform Module (TPM), secure memory encryption (AMD CPUs), a Software Guard Extensions (SGX) enclave (Intel) or a TrustZone enclave (Apple). Software-based attestation does not rely on any hardware root of trust. A hybrid approach is software attestation that can rely on a minimal trust anchor.

With all remote attestation systems, an adversary can wait for the remote attestation system to measure the system in an un-compromised state and modify the system thereafter. As a consequence, there is a trade-off between security and performance.

Mobile Attestation

Many mobile applications need to communicate with a backend to perform their duties. From the backend’s perspective, mobile attestation allows you to verify that it is an unmodified version of the application that sends queries. The goal is to avoid instrumented mobile applications or scripts or programs that emulate the mobile application’s behavior to send queries to the backend.

A successful mobile attestation strategy typically includes the following ingredients:

• It should detect if the device has been rooted or jailbroken.
• It should detect if there is a debugger or emulator running.
• It should detect if hooking or instrumenting frameworks arebeing used.
• It should detect if there are unexpected dynamic libraries in theapp’s memory.
• It should check the app runtime integrity.
• It should search for known signatures of third-party apps.
• It is likely to involve obfuscation and code tamper-proofing.
• It is likely to use white-box cryptography.

The main challenges are finding the best balance between security and performance; responding to attestation bypasses; ensuring that different app versions are adequately covered; and enforcing code versioning for attestation.

When properly implemented, mobile attestation can help:

• stop third-party application clones;
• stop spammers;
• defend against credential stuffing attacks;
• and contribute to build IP address / account reputation models.

Mobile attestation is a way to add an extra layer of protection. It can be used with other defenses, like rate limiting or custom intrusion detection systems. In practice, one can implement mobile attestation thanks to Google Play Integrity API (formerly known as SafetyNet) on Android, and Apple DeviceCheck API on iOS. These APIs leverage HW-secure capabilities of the underlying platforms.

Thanks for reading Crumbs of Cybersecurity! Subscribe for free to receive new posts and support my work.