Protect your customer data and your reputation with our state-of-the-art security
Secure valuable gaming revenue streams & maintain user trust with our Unity integration
Secure your e-commerce revenue & safeguard data by layering mobile app protection
Device binding is a powerful technique to boost your app's security. Essentially, it creates a trusted link between the app on a specific mobile device and the backend server. This link is established through a 'handshake' when a user logs into the app on a device for the first time. Once established, the server recognizes and trusts the app instance on that particular device, thanks to the initial handshake.
Before I explain what exactly device binding is, let’s have a look at a few attack scenarios on apps without device binding.
Case 1: You sign in to your mobile banking app with your credentials. Then you pass the second step of authentication with Multi-Factor-Authentication (MFA). Once signed in, the app doesn’t require you to pass the MFA anymore.
Attack 1: One day, a bad actor steals your session token from the app on your device. No matter if the app had a bug, if someone pulled off a MITM attack, or if someone used an exploit, the token got into the attacker's hands. As a result, the bad actor can now reuse your session token on their device to navigate the app signed in as you.
Case 2: Let’s think of an app that offers extra paid features or media to its users. A user buys them once and then can use them freely on their mobile device.
Attack 2: A bad actor jailbreaks a device and gains access to all these files. They copy them over to another device. As a result, the other device will have access to all premium content bought on the original device. The worst possible scenario is that the attacker publishes the files online making them available to anyone.
Device binding solves exactly these issues.
The following sections describe a way to use device binding in your app to protect against these 2 attacks. The whole concept of device binding is built on top of Asymmetric Cryptography. If you know what asymmetric cryptography is, feel free to skip the recap.
When a user signs in for the first time in an app, the app creates a public key and a private key. It sends the public key to the backend server but keeps the private key for itself. It’s important to use TEE (Trusted Execution Environment) such as Android KeyStore or iOS Keychain to generate the keys. TEE guarantees that the generated private key can’t be extracted from your device.
The whole signing process looks like this:
The server validates the username and password. If verification succeeds, the server stores the public key for this user in the database.
From this time onward, whenever the app sends a REST request to the backend site, it signs the payload with the private key. The signing process produces a signature - a cryptographic representation of the payload that ensures the integrity and origin of the payload. Then, the app sends the payload together with the signature to the server. When the server receives the message, it uses the public key to validate the payload with the signature
The diagram below shows a simplified communication between an app and a server after the handshake.
This technique mitigates Attack 1 mentioned above because the server trusts only session tokens that are signed with the correct private key. Even if an attacker stole the session token, they would need the private key from the victim's device. However, TEE guarantees that the private key is not extractable from the device. In this case, the only viable way for an attacker to still sign the payload is to compromise the system environment, e.g. root the device.
After the handshake, the app has the private key, and the server has the public key. The server can use the public key to encrypt the files before sending them to the app. The app stores the encrypted files on the filesystem and decrypts them with the private key only when necessary for a short period of time in the memory.
This technique mitigates Attack 2 because even if an attacker copies the files from the device, they will be encrypted. Only the device with the corresponding private key can decrypt them. Again, the TEE guarantees that the private key is not extractable from the device. Therefore, the only possible way for an attacker to access the decrypted files is to extract them from the app’s memory when decrypted and in use. To countermeasure it, the developers often use Runtime Application SELF Protection (RASP) to prevent attackers from inspecting the memory and hooking the app to extract the media content.
Device binding mitigates a lot of potential attacks out of the box thanks to asymmetric cryptography that ensures the integrity and author of the payload. To make the best use of device binding, you can configure TEE to require biometrics authentication when using the private key to sign or decrypt the data.
To learn more, check out the sample device binding implementation for Android.