October 10, 2023
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.
Asymmetric cryptography recap
Asymmetric cryptography is the fabric that ties all the elements in the device binding concept. To understand the content of this post, there are only 3 things you need to know about asymmetric cryptography:
- There are only 2 keys - public and private. You generate these keys at once. You keep the private key for yourself and give the public key to the other party
- The public key can encrypt data. The private key decrypts data.
- The private key can sign data. The signature assures that the data comes from the holder of the key and that the data hasn’t been tampered with.
The handshake
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.
Note
The diagram describes a simplified version of device binding for the sake of clarity. It’s possible to add more security guarantees to a handshake. More on this topic at the end of the article.
Communication after the handshake
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.
Note
Developers usually use JWT (JSON Web Token) tokens for such communication. The token has 3 fields Header, Payload, and Signature.
- Header describes the cryptography algorithm used for signing.
- Payload is your usual REST payload.
- Signature contains the signature of the Header and Payload fields.
Protecting your files with Device Binding
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.
Encryption with asymmetric cryptography is slow
Encryption with asymmetric cryptography is slow, so developers often combine asymmetric cryptography with faster symmetric cryptography. First, on the server side, they create a new symmetric key and encrypt the file with it. Then, they use a public key on the server side to encrypt the symmetric key. Finally, they send the file and the symmetric key to the device. Once the device receives the message, it can decrypt the symmetric key with the private key and use it to decrypt the file.
Summary
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.
