What is an Assurance Protocol in Mobile App Security?

Mobile apps and mobile software components are rarely stand-alone as they frequently perform their most important operations on various backend systems. Both parties in this communication need assurance that they are talking to an authentic partner at the other end. The server needs assurance that the software it talks to on the mobile device is authentic and not tampered with. The software on the mobile device needs assurance that it talks to the authentic server (not a man-in-the-middle) and that data can reliably be sent to the server.

For mobile apps, an assurance protocol is a handshake protocol used to assure the back end that it is talking to a genuine app and to assure that the app it is talking to a genuine back end, thereby ensuring the confidentiality, integrity, and authenticity of the communication between the app and the back end server.

Assurance builds on a shared secret, as well as a public key that corresponds to a private key in the back end.

The TLS protocol protects content in transit and authenticates the back end that receives the data. When an app connects to a back end through TLS, the back end provides a certificate (or certificate chain) to prove its identity. The app must determine whether or not to trust this certificate, in order to prevent man-in-the-middle attacks. This can be enabled through certificate and public key pinning, which means that a back end’s X.509 certificate or public key is added to an app, typically at development time.

On the other hand, to control app access to a backend API, a secret (in a generic sense) can be embedded in the mobile software that is used as the root assurance that the software running is authentic.

Building on this initial assurance that the software can be trusted, a device-unique key can be established with the back end on the first encounter. This device-unique key is used to enable the back end to recognize when a given device with the installed software returns.

What is provided by OS providers?

In addition to the TLS protocol, both iOS and Android provide certificate pinning, app integrity checking and device attestation to help achieve assurance.

iOS

With iOS 14, Apple introduced “certificate pinning via configuration” as a simplified way of certificate pinning.

With its support of Automated Certificate Management Environment (ACME) added with iOS 16, managed device attestation is available as a tool to provide assurance of device properties.

Apple’s App Attest API, introduced in iOS 14 as part of the DeviceCheck framework, allows an app to deploy a hardware-based cryptographic key, thereby enabling the back end to verify the app’s and device’s genuineness.

Android

From Android 7 onwards, certificate pinning for any mobile app that targets API level 24 and above was made easier with the introduction of the network security config file.

ID Attestation, introduced in Android 8.0, allows the device to provide proof of its hardware identifiers, such as serial number or IMEI.

Google’s Play Integrity API, first released in Feb 2022 and replacing the SafetyNet Attestation API, is available for all apps distributed via the Google Play Store and is the Android equivalent to Apple’s App Attest API.

Limitations of current OS techniques

Certificate pinning comes at a cost, due to the loss in crypto agility. Since it hard-codes certificate requirements into the application any update to a revoked certificate requires an update of the application. In the meantime, the app is not able to connect to the back end unless it has a backup certificate installed. More importantly, there exist tools such as iOS SSL Kill Switch, that can disable certificate pinning.

While TLS provides authentication and protects data in transit, it only authenticates the back end to the app, not the other way round. So the app knows it is talking to the correct server but there is no guarantee the other way.

The OS device attestations let the OS sign that the certified private key is in hardware TEE on the phone. However, Google and Apple themselves say that this guarantee is off if the device is jailbroken or rooted.

Likewise, App Attest and Play Integrity are susceptible to being circumvented, for example by installing rooting software. Further, Play Integrity and App Attestation are designed to be used during login to an app where the signature can be verified at the server, upon which a shared key is obtained for use in subsequent requests; they are designed neither to sign ALL requests to the server, nor to ensure the back end that it’s a genuine app even before login or enrollment. An additional challenge is to ensure that the shared key is well protected in the device!

While it is recommended to incorporate these OS safeguards, they are too weak and not suitable for apps handling valuable digital assets.

How does Cryptomathic implement an assurance protocol?

The Cryptomathic assurance protocol and Assurance Service function as complementary security layered over the operating system to protect apps handling valuable digital assets.

The assurance protocol consists of two parts: a challenge-response protocol to assure the server that it talks to a genuine app, and a device-binding protocol for key agreement between the app and the back end.

Device binding

In the device-binding protocol, the app generates a temporary key and negotiates a unique device key which is only known by the app and the backend service. This key, which is protected against being moved to a different device, is used for subsequent responses to challenge messages.

Challenge-response protocol

When the app issues an HTTPS request to the assurance back end, it receives a challenge. The app then computes a response for the challenge demonstrating knowledge of a shared secret (the unique device key). Upon receipt of the response, the back end verifies the validity of the response and lets the request through.

Benefits of the assurance protocol

Since the assurance protocol is not reliant on certificate pinning which can be disabled, it provides adequate resistance against man-in-the-middle attacks.

The shared secret, established in the device binding on enrolment of the app, allows the back end to connect that secret with a user; it thereby allows the back end to link the enrolled app with the user of that app. As the shared secret is needed in the challenge-response protocol, the user can only login if they have the shared secret for that user. Since in Cryptomathic’s implementation it was made difficult to move that secret to another device, the user cannot suddenly login from another device without enrolling that device as well.

The assurance protocol also protects the backend against API aggregators, bots, click farms, etc.

Last but not least, the Cryptomathic implementation of assurance is light enough to use on ALL requests to the back end. This ensures the back end that it is a genuine app with a security core making the request, even before login or enrollment.

How is the assurance protocol delivered?

App-side, the assurance protocol is handled by Cryptomathic’s Mobile App Security Core (MASC), which is delivered as a native binary library/SDK to be integrated into the mobile app.

The Security Core is complemented on the back end by the MASC Assurance Service, which is offered as web service handling the server side of the assurance protocol. MASC continuously reports the health of the devices to the back end, and the MASC Assurance Service ensures storage of the health messages collected by the sentinels in a dedicated data base and takes care of health decisions, e.g. by defining if traffic shall be blocked for apps considered unsafe.

In summary, only a strong assurance protocol can ensure that communication between the mobile app and back end is mutually authenticated and confidential. This article highlights why TLS and the recent attestation technology introduced by Apple and Google do not provide sufficient security to provide the assurance required by apps handling critical assets. Cryptomathic offers a secure and easy-to-deploy implementation of the assurance protocol with the Mobile App Security Core.

Cryptomathic is a leader in strong mobile app defense mechanisms and our Mobile App Security Core (MASC) provides a comprehensive security solution for apps that store sensitive data. Download the white paper on mobile security or contact us for more information.