Does the use of a smartphone's Secure Element really offer security benefits to a banking app?

Question

My bank's Android application allows users to perform financial transactions without the use of the physical token generator (which requires an ATM card to be inserted and a valid PIN to be provided) one would normally require when using the bank's web interface. However, this is only supported when using the app on a phone that comes with a hardware Secure Element in which it can store cryptographic keys and such.

Initially, this seemed like a good decision to me, since devices without a Secure Element would have to store keys in memory or on persistent storage, and are therefore vulnerable to attacks by malware installed on the same device.

However, when thinking this through I got the impression that using the Secure Element actually would leave one just as vulnerable to these attacks than when solely protecting keys through software; compare these two approaches:

• The system relies on the operating system to restrict access to the keys: other apps can't access them while in userland, but when an attacker manages to gain root access to the device they can steal the keys and sign or encrypt whatever they want, pretending to be the banking app. This allows them to forge transactions.
• The system stores keys on the SE and relies on the operating system to restrict access to this hardware: other apps can't access them while in userland, but when an attacker manages to gain root access they can instruct it to sign and encrypt whatever they want, pretending to be the banking app. This allows them to forge transactions.

Because of this, the use of the hardware chip for this purpose seems rather pointless to me. The same holds for similar applications relying on it to store sensitive material.

Am I missing something here? Is there a situation where the secure element does offer a clear security benefit to this banking app, making it reasonable to mandate it?

Answer 1

So both of your scenarios rely on the attacker having root access to the phone. In security, it's generally considered that once an attacker has root access, it's game over. That said, there are still interesting things to be said about your question.

You asked:

Is there a situation where the secure element does offer a clear security benefit to this banking app, making it reasonable to mandate it?

Being a little bit cheeky: Yes, normal use-cases where the user has a password / pin lock, and the attacker does not have root access.

---

Going a little more in-depth:

When you say "reasonable to mandate it" I assume you mean vs offering the same functionality to users with non-Secure Element devices by storing the key in software? A few things come to mind:

1. On Android > 6.0 (and I bevieve iOS) the crypto happens inside the Secure Element / Secure Enclave, so the private key never enters userland, so it is immune to potential vulnerabilities / sloppy coding in the banking app itself or the software crypto libraries they use. (generally a good practice).

2. Because the private keys never leaves the Secure Element's keystore, it is impossible to extract them from the device and run the spoof from a server; you need to do it from the physical device. If the owner discovers that the device has been stolen, they can do a remote wipe, which will clear the private keys, attack over.

3. If the keystore is password protected, then in the case of a software keystore, you can extract the file to a server and brute-force the password to your heart's content. In the case of a Secure Element, after some number of brute-force attempts, they can wipe the keys.

4. While still a bit experimental, Android and iOS are starting to offer neat access control mechanisms on when the hardware key store will unlock the keys and perform crypto for you. For example, you can program your app to request crypto from the SE in the following way "Sign this data, but only if the device was unlocked using password, fingerprint, or PIN, and if the device was unlocked more than 5 minutes ago, re-prompt them for their login first". That level of control is fundamentally impossible with software-based keys.

None of those things are 100% foolproof against an attacker with root access to the device, but I think they show that a hardware keystore / crypto module does add some value. My professional opinion is that it's a defensible choice for a banking app to allow you to bypass a physical token generator only if your device has a Secure Element.

[Disclaimer: the Android Secure Element underwent a major overhaul in Android 6.0, so what I said above does not apply to Android < 6.0 which did not do any crypto in the SE and did hand the private keys back to userland.]

Answer 2

A mere thought.

While the banking app, and the way it communicates with the bank's servers, might be technically sound, and virtually unhackable; what about the phone itself?

My major concern is about the security of the phone itself. If it gets stolen, or lost, then all a finder/thief needs to do is get around the lock screen.

Many people use unlock patterns, which can be traced back by studying the smear patterns on the physical screen. Once, the adversary succeeds in tracing back the unlock pattern, the adversary is me (as far as the banking app is concerned).

So, while the banking apps may be quite secure, I feel that the security of the phone itself is now the weakest link.