HCE vs embedded secure element: relay attacks (part V)

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.

Remote-relay attack from SE-equipped phone to merchant POS

Relay attack visualized


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]


6 thoughts on “HCE vs embedded secure element: relay attacks (part V)

  1. Payment commands can only be deployed to the SE across a dedicated contact connected by SWP (Single Wired protocol) to the NFC router. An Android application can never deploy payment APDUs to the SE, so the attack described here is not feasible.

    • Hi Miguel.

      I’m not following how SWP is related to this problem.
      SWP is just one option for connecting secure element to the NFC controller and typically used for UICC.

      1. In some models of the Android embedded secure element, controller to SE connection does use SWP. Yet that has no bearing on the ability to prevent relay attacks, as described in part VI.

      2. Even with SWP, the host application processor has access to the contact interface– this is especially true for UICC since phone must be able to access applications such as SIM toolkit. Unless payment application in SE has additional logic to check interface, it will still be vulnerable to relay attacks.

      Consequently: SWP is neither necessary (point #1) nor sufficient (point #2) to defend against relay attacks.

  2. Alexej Muehlberg says:

    SWP protocol is as the name says a protocol implemented in software. If one manages to tinker with this protocol, it can be rerouted as described by Cem. SWP is even more vulnerable as part of the protocol, the initiation, is handled by the host in mobile. At the end it comes down to separate HW or some logical separation from mobile host. And this SW running in isolation needs to be protected from malicious updates.

  3. Alexej Muehlberg says:

    SWP is also the data link layer and on top is running HCI. SWP can also be used for embedded secure elements.

    Who is processing SWP/HCI? CLF, which runs some FW and mobile host. Consider if this SW gets attacked.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s