Part IV in this series sketched how it is possible to build a mobile wallet using NFC that can protect its secret keys even against an adversary executing code with Android root privileges. But there is one subtlety not explored in that discussion: keeping an attacker from getting hold of cryptographic keys is not the same as preventing unauthorized spending. The logical implications holds in one direction. If payments are authorized based on possession of cryptographic secrets– as is the case with EMV chip & PIN suite of protocols– being able to extract the key from the mobile device is game-over. But while key-recovery is sufficient for the hypothetical attacker to go around printing money compliments of another user, it is not necessary.
Remote relay attacks
Consider a less ambitious attack that relies on merely interacting with the secure element, to simulate a payment operation. Legitimate transactions take place by having a point-of-sale terminal send commands to the secure element over NFC. What if malware resident on the mobile device emulated that behavior but then relayed the responses from SE to another phone controlled by the attacker? More specifically:
- Attacker walks up to the cash-register and begins to pay for a purchase using NFC using his own Android phone.
- But when the point-of-sale terminal sends a command to the attacker phone, these are not routed to the secure element. Instead they are delivered to a special application running on the phone via host-card emulation. (It used to be that rooted devices running Cyanogenmod were required for this; starting with Kitkat it can be implemented on stock Android.)
- This special application receives the command from the merchant terminal, then forwards it over the Internet to malware running on the victim’s device
- That malware uses its root privileges to deliver the command to the secure element– necessary since Android only allows whitelisted applications to interface with SE.
- When SE responds to the command, the response is likewise ferried over the same network connection back to the attacker, who promptly forwards it over NFC back to the point-of-sale terminal.
In effect the POS at the store is communicating with the victim phone, although these communications are taking a rather circuitous route through the Internet instead of simply traversing a short distance as usual with NFC.
Implications for security model
What has the attacker achieved after all this effort? If payments implemented in hardware secure element were still susceptible to attacks from local malware in this fashion, it would violate our earlier assumption that the Android operating system does not have to be trusted. With remote relay attacks, Android malware could still conduct unauthorized payments by channeling SE communications to a remote attacker, allowing them to make purchases without physical possession of the targeted device. That would also reduce one of the main advantages of SE-based implementation over HCE. Clearly an HCE solution implemented in pure software has no defense against root-level malware; secret keys can be permanently extracted out of application memory. In that sense HCE is an easier target. You only need to run the exploit once to extract keys; it is not necessary to maintain persistence on the victim device to continue making fraudulent payments. But relay-attack implies that even when cryptographic keys are safely tucked away in a dedicated chip, they can be exploited remotely as long as the phone itself is reachable over the network.
Are such attacks feasible? At first two practical limitations jump out, both related to network connectivity in real-time. (“Real-time” is the operative phrase. EMV protocols involve challenge/response interaction with the terminal. It is not possible to collect and store all possible responses from the SE ahead of time before starting a new transaction.) That presents the first obstacle for successful exploitation: the victim device may not be reachable at all. If the legitimate user turns off their phone or wanders outside the coverage area, it is not possible to relay commands in real-time this way. Likewise the attacker also needs connectivity for their own device, although that part is easier to control by carefully choosing the retail location where the scam will carried out. Second problem is around the quality of the connection measured in bandwidth and latency. Bandwidth turns out not to be a problem since the amount of data exchanged is on the order of hundreds of bytes. Latency is a bigger concern. There are timeouts at different levels of the protocol stack, from the raw NFC exchange– which also has an option to request an extension to buy more time– to application logic in the NFC reader. For example MasterCard recommends a limit of around 200 milliseconds for completing the entire tap & pay transaction, and that includes multiple command/response round-trips. (Granted some of the expected responses are predictable and do not require relaying the command all the way to the remote SE to find out the required answer.) But suppose the stars line up and our enterprising attacker does indeed have access to a high-bandwidth, low-latency connection to the victim device controlled by his malware? Or perhaps the point-of-sale terminal is very lenient and does not mind waiting longer than expected to complete the transaction?
It turns out there is a more fundamental defense available for preventing relay attacks against secure element applications: interface detection. That will be the topic of the final post in this series.
[continue to part VI]