Device Fingerprinting: Friend or Foe?

Verifying the possession of a device to strengthen the security of a payment is nothing new. In some way or another, it has been with us since the 1990s when one-time-code text messages for verifying phone ownership became common (OTP by SMS).

Using the text message to a mobile phone method as a 2nd factor increased security in two ways: by using a separate 2nd channel from the PC and by verifying the user’s identity through ownership of the phone number. Ultimately, this verification step rose to popularity simply because using PCs for online banking made you vulnerable to viruses and malware, and the world was looking for a solution.

However, with the introduction of smartphones, text messages as a verification method became a bit problematic, primarily because they were and still are easy for banking malware to access. Which, of course, makes it possible for attackers to gain account access and verify fraudulent transactions. The solution to this problem seemed pretty straightforward: Why not use an app to check the possession of the device through a fingerprint established during onboarding and then require the same fingerprint when validating the transaction? 

With the advent of PSD2 and the two-out-of-three factors requirement, verifying the possession factor through a device fingerprint became more common. Having one factor implemented through a fingerprint leaves you with either “something you know” or “something you are” as the second factor. In addition, as security requirements grew in strength, the device fingerprint became a way of checking that the integrity of the underlying device wasn’t compromised. Furthermore, if your fingerprint checks enough factors, it can also help you detect that the app is not running in an emulated environment.

The importance of checking device fingerprints has also been recognised by EMVCo, which has its own standard for device information in its 3-D Secure specification. This specification lists about 150 factors that can be collected on Android and about 20 that can be collected on iOS.

If we go back to the first mobile payment apps, device fingerprinting was pretty basic. Usually you would check the International Mobile Equipment Identity (IMEI) number, which was built into the device during production and was guaranteed to be unique. On Android, some other device identifiers were commonly used, such as IMSI, SIM, and various other serial numbers. The critical term here is that these are device identifiers that didn’t change over time. Of course, there were some cheap phones didn’t have unique IMEI numbers, and some even randomised the IMEI every time they were restarted.

But alas, nothing stays the same forever. By iOS version 6 and Android OS release 10, it was no longer possible to read these device identifiers. The reason was probably that both Google and Apple realised that advertisers could misuse these to track users across applications. So, developers were instead directed to using identifiers unique to the installed application. This was somewhat of a problem, as a reinstall of the app could result in a new identifier, which might require the user to go through a cumbersome know-your-customer (KYC) procedure.

Around the same time, Google and Apple started to support, and eventually require, a new feature that also could be used to identify the device. Namely, hardware-backed secure enclaves for storing private keys. A hardware-backed enclave or separate secure execution environment is usually a separate processor that runs its own small operating system with very basic functionality. Third-party apps can store cryptographic keys in these enclaves and then call the enclave to have it encrypt and decrypt data. This can be used without the app having access to the key itself, making it an option for creating a possession element. 

A related feature is ID attestation, which can return proof of its IMEI and other device identifiers on Android. With Android being much more fragmented than iOS, this is still an optional feature. Still, it is implemented by at least some major vendors, such as Samsung flagship devices from the Note 10 and onwards. 

When evaluating security solutions, I like to put myself in the role of a criminal trying to subvert the security systems. The criminal is typically motivated to find the easiest way to access accounts or validate fraudulent transactions. Basically, to get access to customer funds the easiest way possible. 

Taking advantage of insufficient device fingerprint solutions is one way of doing this. Examples of such an attack are solutions that blindly check a few identifiers. In this case, an attack goes as follows:

Devices running the app are infected by malware, perhaps through a phishing campaign. Next, the malware gets root access to the underlying operating system. The next step is to copy the files of the banking app to a cloud-based emulator, where the device identifiers that the app relied on are recreated. This makes for a much more accessible environment for automating attacks on the accounts.

If you use keys stored in secure enclaves, there are other problems. Android in itself creates issues, as it supports about 7 different mechanisms for storing keys, each with its advantages and disadvantages. It is also safe to say that all major vendors have had issues with their hardware-based key storage, including both Samsung and Qualcomm. Basically, doing both hardware- and software-based secure key storage is tricky to get right. Only through a combination of features, depending on the operating system, can you implement a genuinely sufficient device fingerprint.

After all, the security of a system is not through the security of all the different mechanisms implemented. It is through the security of the least secure part of the chain from the user initiating a transaction, and then having that transaction verified. If that is the device fingerprint, that is also where you would expect an attack to happen.

Hopefully this has been an interesting look into one of the required SCA factors! If you’re interested in learning more, please see our blog, follow us on LinkedIn, or sign up for our newsletter by sending an email to hello@okaythis.com.