Figure 9-1 Google Wallet utilizes a “virtual” MasterCard in all contactless transactions.
Over the past several years mobile payments, which have seen some success worldwide, have finally started to catch on in the United States. The wide adoption of smartphones has helped fuel the adoption of mobile payment solutions, so now there are several competitors vying for a spot on your device (and a piece of the payment transaction pie). As with any sort of application that deals with financial transactions, mobile payment applications have gotten a lot of scrutiny, both from consumers looking to protect themselves and security researchers looking to poke holes in them. Not surprisingly, there have been several high-profile attacks against payment applications that have gotten quite a bit of attention in the media. Mobile payments have come a long way in the past 15 years, so in this chapter, we’ll take a look at where the technology is currently, where we think it’s going, and then dive in to see how secure these mobile payment solutions really are.
Say “mobile payments” and a number of different scenarios come to mind. A multitude of mobile applications exist, ranging from the more traditional mobile banking applications, to NFC-based or barcode-based mobile payment applications used by consumers to purchase goods from merchants, to mobile applications used by merchants that accept payments via old-school magnetic stripe cards from consumers. Or mobile payments could refer to premium-rated SMS messages, which provide the user with services, or virtual goods, within a mobile application via SMS (for example, digital songs or items in a game). Users are then billed later via their normal telephone bill. We will not cover every type of application that falls under this wide category within this chapter, but we will highlight some of the applications that are representative of mobile payments trends and discuss relevant security implications.
Banks ranging in size from small credit unions to multinational banks have developed mobile applications that allow their customers to perform all the normal banking transactions using their phone, such as viewing their account balances or transferring money between internal or external accounts (mobile transfers). Many of these applications are simply web applications designed to be displayed within the mobile browser or within a WebView inside of a native mobile application (see Chapters 6 and 8 for more on WebView) and, therefore, often share the same back-end components as the bank web application that clients use via their desktop computer. The vulnerabilities that we see in a mobile banking application are often the same types of vulnerabilities that we see in the bank’s web applications. But with mobile, you also need to consider the device theft scenario in which sensitive data may be stored on the device improperly. If the victim’s banking credentials are stored on the device, a thief may be able to make banking transfers on behalf of the victim.
Contactless payment systems have also started appearing in the United States. Released in late 2011, Google Wallet is a notable example of a mobile payment system based on NFC (Near Field Communication) technology. (We’ll explore how transactions occur over NFC and some of the publicly disclosed vulnerabilities in this system later in this chapter.) In its latest incarnation, Google Wallet supports all major credit cards (Visa, MasterCard, American Express, and Discover), which are stored in the cloud, but a “virtual” MasterCard account number is actually sent to the contactless POS terminal via NFC and then Google charges the selected credit card, as shown in Figure 9-1. Another noteworthy mobile payment system based on NFC technology is Isis, which is a joint venture among Verizon, AT&T, and T-Mobile in collaboration with a number of major banks. Isis started a pilot program in two major cities in the fall of 2012. The lack of ubiquitous contactless POS terminals at stores may hinder rapid mainstream adoption of both the Isis Mobile Wallet and the Google Wallet, but the universal contactless smartcard reader symbol is becoming a common sight in more locations.
Figure 9-1 Google Wallet utilizes a “virtual” MasterCard in all contactless transactions.
Yet another contender in the mobile payments space is MCX, which stands for the Merchant Customer Exchange. MCX is a consortium of merchants, including some large players like Wal-Mart, 7-Eleven, and Target, who are coming together to reportedly develop a mobile payments system based on QR codes (a type of barcode) as opposed to NFC technology because most merchants already commonly deploy barcode technology. In hopes of reducing transaction costs, MCX is seeking to develop a system for merchants that allows them to avoid paying traditional transaction fees to VISA and MasterCard by using ACH transactions instead.
A number of mobile applications also accept magnetic stripe cards via an external card reader plugged into the mobile device. Square is one notable example that provides merchants with a free card reader that plugs into the audio jack of iOS and Android devices. One of Square’s competitors, VeriFone, and its former CEO, Doug Bergeron, made an allegation that Square’s product could be easily hacked in an “open letter” because “Square’s hardware is poorly constructed and lacks all ability to encrypt consumers’ data, creating a window for criminals to turn the device into a skimming machine in a matter of minutes.” VeriFone created a sample skimming application and a video demo to back up its claims against the security of Square. We explore the validity of these statements later in the chapter. VeriFone also develops POS hardware that you can use in junction with mobile devices, along with developing POS hardware and software solutions. As the mobile payments ecosystem continues to expand, seeing which applications become popular should be fascinating.
Now that we’ve covered the current field, let’s first look at how contactless smartcard payment systems work. We’ll follow that up with specific attacks and countermeasures for some of the existing players.
The first contactless payment cards were released in the United States in 2005. These cards allow a consumer to “tap” his or her card to a contactless POS terminal to make a payment, instead of swiping the card in a magnetic stripe reader (like a traditional credit card). In 2011, Google released Google Wallet, which took advantage of the already existing contactless payment infrastructure to allow mobile phones to be used in contactless transactions instead of using a more traditional credit card form factor. The technology behind mobile contactless payments is similar to contactless credit cards, with the primary difference being that a mobile phone allows for much greater flexibility and security. We’ll go through the various components that make up a contactless payment application like Isis Mobile Wallet or Google Wallet to see how they differ from contactless credit cards.
The Secure Element (SE) is the core of the mobile payment platform. The SE provides secure storage that the mobile payment application can use to store sensitive information; it primarily stores the payment applets that represent the contactless payment cards. A number of SE form factors are available for mobile devices. The first is the embedded SE, which is an SE that is contained within the mobile device itself. The Galaxy Nexus contains an embedded SE. Another SE form factor is the UICC, more commonly known as the SIM card. Although traditionally only available to mobile network operators, this form factor is now being used with the Isis Mobile Wallet. SEs can also be packaged into microSD cards. These microSD cards typically have their own built-in NFC radio and are designed for devices that do not normally support NFC.
Regardless of form factor, all SEs are essentially Java Card smartcards (see oracle.com/technetwork/java/javacard/overview/). Java Card is a strict subset of Java Standard Edition, designed to make Java Card applets portable across a variety of smartcards. The Java Card Runtime Environment (JCRE) provides several security features for Java Card applets, including an applet firewall restricting Java Card applets from accessing each other’s information and robust cryptographic operations such as AES and RSA. Payment applets, which contain the necessary information to make contactless transactions, are Java Card applets that run in this environment. Contactless payment cards function in the same way.
Most Java Cards, including SEs, are GlobalPlatform compliant. The GlobalPlatform association (globalplatform.org) is comprised of over 100 member organizations, including device manufacturers, mobile network operators, and payment card companies. The GlobalPlatform specifications offer a standard way to securely manage Java Card applets and related sensitive information. The specifications are freely available on the GlobalPlatform website (be warned, they are quite extensive!). In practice, what this means is that the owner of the SE is the only one who can directly read or write data into the SE. This is accomplished through the use of shared keys that are used to perform mutual authentication to establish a secure channel with the SE. Typically, a SE will lock after a number of failed attempts at mutual authentication, which makes brute forcing the keys unlikely.
As mentioned before, the payment applets that contain the information necessary to make contactless payments with mobile wallet applications are Java Card applets that are stored and run inside the SE. Although many applets may be installed on the SE, the two that are of interest to us are the Proximity Payment System Environment (PPSE) and the payment applets themselves. The PPSE acts as a registry of all payment applets that are stored in the SE. It has a standard application identifier that all compatible contactless payment terminals know. The PPSE’s job is to tell the contactless terminal what payment applets are available and their application identifiers. Because not all payment cards may be accepted by any particular POS terminal, this method allows the terminal to select which card it wants to use of the ones available.
The payment applets are actually responsible for making the contactless payment. They contain sensitive information that is associated with a particular payment account. They are also able to leverage the cryptographic capabilities of the JCRE to perform cryptographic operations that allow the issuing banks to securely verify transactions. The implementation of this verification process varies between applets and banks, but it can be something as simple as generating a one-time card verification value (CVV) for each transaction (known as a dynamic CVV, or dCVV), or it may involve generating and signing a cryptogram created from information about the transaction and POS terminal.
Finally, applets in the SE are little more than simple state machines. To communicate with applets on the SE, instructions are sent to the applet in the form of an application protocol data unit (APDU), which is a specially formatted string of bytes. There are two types of APDU: command (C-APDU) and response (R-APDU).
A C-APDU consists of the following:
If the amount of data that needs to be transmitted to the applet is greater than 256 bytes, multiple C-APDUs can be chained together.
R-APDUs have a simpler structure:
On mobile devices, there are two ways to send APDUs to the applets on the SE. The first way is via the contactless interface. This interface is connected to the NFC radio and is how POS terminals send commands to the SE to perform payment transactions. This interface is not available to applications on the phone because you need to be able to enter the NFC field the phone itself is generating. The second interface is the contact interface, which, as you might imagine, is the connection between the SE and phone itself. Applets on the SE can distinguish between the two, which allows them to deny communications over either interface. When we take a deeper look at Google Wallet later in the chapter, you’ll see why this is an important feature.
Figure 9-2 shows an example of a (simplified) contactless payment transaction. Let’s take what we’ve described so far and walk through the transaction.
Figure 9-2 An example of a contactless payment transaction
1. The contactless POS sends a SELECT command to the PPSE applet.
2. PPSE responds with a list of available payment applets.
3. The POS chooses a payment applet and then issues a SELECT command.
4. The payment applet responds, letting the POS know the SELECT command was successfully processed.
5. The POS sends the GET PROCESSING OPTIONS command, including information requested by the payment applet about the POS itself.
6. The payment applet responds with the processing options that both it and the POS support.
7. The POS sends a READ RECORD command to the payment applet.
8. The payment applet responds with the so-called Track 1 and Track 2 data per ISO/IEC 7813, which includes the Payment Account Number (PAN).
9. The POS sends the COMPUTE CRYPTOGRAPHIC CHECKSUM command to the payment applet, including an unpredictable value.
10. The payment applet responds with CVC3s (MasterCard’s version of a dCVV), generated using dynamic data (unpredictable value and transaction counter) and a secret key.
This is a simplified overview of a contactless transaction, as there are many different implementations in place, such as the use of static card verification codes as opposed to dynamic ones, or the many implementation differences between Visa and MasterCard payment applets. Whereas the EMV/GlobalPlatform standards define how the contactless POS and payment applets communicate with each other, how the payment applets function is defined by their issuers, who control what sort of security measures are in place. Now that you’ve seen what happens when a mobile device is tapped to a POS, let’s take a look at how the mobile device handles communicating with the SE.
For an application to access the SE, it needs a way to communicate with it. Android 2.3.4 (Gingerbread) added internal APIs for accessing embedded SEs. This addition coincided with the launch of Google Wallet, as Wallet needed to access the SE. From 2.3.4 to the initial release of Ice Cream Sandwich (4.0), this access required system-level permissions. This restriction was loosened a bit in Android 4.0.4 by allowing any application whose signature was contained in the /etc/nfcee_access.xml. Currently, this file only contains the signature for Google Wallet, by default, and requires root access to update (as it resides on the read-only system partition), preventing other applications from accessing the embedded SE. This SE API is very basic, allowing an application to open a channel to the SE and transmit APDUs in the form of byte arrays.
Although this internal API gives applications a way to access embedded SEs, it does not have the ability to connect to UICC or microSD SEs. Luckily, an open source project called Secure Element Evaluation Kit (SEEK) for Android (https://code.google.com/p/seek-for-android/) provides a way to connect to these SE form factors. The project provides a SmartCard API that can be built into Android to provide support for these SEs, although it is not included in the main Android distribution. One thing to note is that even with SEEK included on a device, you still may not be able to access a UICC-based SE. The UICC is not directly attached to the application processor, so Android applications must communicate with the UICC via the Radio Interface Layer (RIL), which provides the application processor with a means to access the UICC via the baseband processor. The RIL library implementation is proprietary, so unless the device manufacturer specifically adds the necessary AT commands (essentially old-school modem commands), SEEK cannot communicate with the UICC. This is not a problem for microSD-based SEs, however.
Whereas access control for embedded SEs was provided by a whitelist on the file system (/etc/nfcee_access.xml), SEEK implements the GlobalPlatform access control system. This system works by having an additional applet on the SE that contains a list of application signatures and a list of applets that the associated applications should have access to. The SmartCard API contains a module called the Access Control Enforcer, which is in charge of determining if an application should have access to the SE on the Android side. It does this by checking the signature of the calling application against the signature stored in the SE to see if the calling application has permission to communicate with the chosen applet. If not, communication is not allowed.
The most visible part of the mobile contactless payment platform is the application consumers interact with. This application is responsible for creating an association between payment cards and the mobile device, making multiple payment cards available in the wallet. A user can select which card in the wallet they want to make payments with. The mobile wallet applications typically contain other functionality, such as retrieving transaction data from the issuing banks, but as far as mobile payments themselves go, they should be seen as the gatekeeper protecting the payment card information stored in the SE.
Both Google Wallet and the Isis Mobile Wallet require the user to authenticate with a four-digit PIN to use the application. This adds a defense against device theft, as an attacker must know the user’s PIN to use the payment cards in the wallet application. While this protection is not foolproof (we’ll go into the details of why shortly), it improves on the security offered by contactless credit cards.
Google Wallet’s security has been criticized by a number of security researchers since its release in late 2011. In this section, we cut through the hype and explore vulnerabilities that have been identified publicly in Google Wallet and discuss potential countermeasures.
PIN Storage VulnerabilityIf a thief steals your traditional wallet or purse, then she or he has access to your money and credit cards. Your only recourse is to call your bank and cancel all of your credit cards. But with Google Wallet, you have to type in a PIN prior to using the application to make a transaction at a contactless POS terminal, as shown in Figure 9-3. You are only given six tries to type in your PIN correctly, so thieves can’t directly type in all 10,000 possible PINs. This setup is arguably more secure than your leather wallet, which once physically obtained, effectively compromises all payment instruments inside. But can an attacker bypass the protection provided by the PIN?
Figure 9-3 The Google Wallet Android application is protected by a four-digit PIN.
Joshua Rubin of Zvelo, who is also known as miasma on the XDA Developers website, disclosed in February 2012 that it is possible to perform an offline brute-force attack against Google Wallet that can recover the PIN within seconds. Although this attack raises many concerns, a number of caveats are worth pointing out. Here are the steps that an attacker needs to take to exploit this vulnerability to fraudulently use the Google Wallet to purchase goods in person.
1. The attacker steals the victim’s mobile device. While acquiring the PIN remotely via malware with root access is possible, remote access is of little use to a remote attacker because the PIN protects the Google Wallet application locally on the mobile device. The PIN is only valuable to a remote attacker if the victim also reuses that PIN to protect online resources in some other system. The standard Google account password is used to protect the Google Wallet web application, not the PIN.
2. The attacker roots the mobile device via a privilege escalation exploit such as mempodroid (CVE-2012-0056) or the Samsung Exynos kernel exploit (CVE-2012-6422). Installing an exploit application on the mobile device is easy for the attacker if the victim did not set up Android’s screen lock. An attacker could also install an exploit application if the victim had previously enabled ADB debugging (adb install). The ideal situation for the attacker is for the victim’s device to already be rooted and devoid of an Android screen lock. Another ideal situation for the attacker is if the victim’s device is already rooted, has ADB debugging enabled, and ADB shell is set up to be allowed root access via Superuser, which is commonly used to grant and manage root access on an application-by-application basis.
3. The attacker then installs an application on the mobile device designed to perform the offline brute-force attack.
4. The application, which has root access, recovers the PIN based on information stored in the Google Wallet’s data directory and now the attacker can use the Google Wallet application to purchase goods. Joshua Rubin developed an application called Wallet Cracker to demonstrate this attack (forum.xda-developers.com/showthread.php?t=1487725), which is shown in Figure 9-4.
Figure 9-4 The Wallet Cracker application can recover the Google Wallet PIN within seconds on a rooted mobile device.
Now that you know the basics of the attack, let’s review the details of Google Wallet’s PIN verification functionality at the code level. When a user sets his or her PIN, the doSetPin function within the PinManagerImpl class converts the entered PIN into an integer and also generates a random 64-bit salt value using the SecureRandom class as shown in the following Java code. The doSetPin function then calls the hashPin function that concatenates the PIN together with a salt and then uses the SHA-256 hashing function to produce a hash of the concatenated value. Additionally, the PIN retry counter is set to six attempts within this function.
Google Wallet later stores the SHA-256 hash and the salt into a SQLite database located within its data directory (/data/data/com.google.android.apps.walletnfcrel/databases/walletDatastore). More specifically, the row with the id equal to deviceInfo within the nebulously named metadata table contains the relevant PIN data. The PIN data is stored in a serialized format using the Protocol Buffers library, which was also developed by Google.
After the PIN data is stored in the SQLite data, users must type in their PIN prior to using the application or after a PIN timeout. The following decompiled Java code shows how Google Wallet verifies the entered PIN. A SHA-256 hash is again calculated based on the entered PIN and the salt stored in the database. If the calculated hash equals the hash stored in the database, then the user is allowed to use the Google Wallet. Otherwise, the PIN try counter is incremented.
Now that you understand Google Wallet’s PIN verification functionality, let’s look at how Wallet Cracker works. Besides providing a slick user interface, this application extracts the PIN data from Google Wallet’s SQLite database, deserializes the PIN data, and then launches an offline brute-force attack using the known SHA-256 hash and salt. The following Java code shows how Wallet Cracker brute-forces the PIN. Basically, the application tries the first possible PIN, concatenates it with the salt, hashes the result, and then compares it with the recovered hash. If the calculated hash does not match the recovered hash, then the application moves on to the next PIN. The PIN should be identified within seconds, since there are only 10,000 possible PINs. Furthermore, because the attack is against a copy of the hashed version of the PIN stored outside of the Google Wallet, the PIN counter mechanism has no bearing and Wallet Cracker can proceed with an unlimited number of guesses (the so-called offline attack noted earlier).
PIN Storage Vulnerability CountermeasuresGoogle’s response to the disclosure was that
the zvelo study was conducted on their own phone on which they disabled the security mechanisms that protect Google Wallet by rooting the device. To date, there is no known vulnerability that enables someone to take a consumer phone and gain root access while preserving any Wallet information such as the PIN. We strongly encourage people to not install Google Wallet on rooted devices and to always set up a screen lock as an additional layer of security for their phone. (quoted in the Bits blog, The New York Times, http://bits.blogs.nytimes.com/2012/02/10/google-wallet-vulnerability/)
Assuming that no privilege escalation vulnerabilities exist in the Android operating system is incorrect, and although Google does not recommend running Google Wallet on a rooted device, that does not mean everyone will listen.
A stronger defense against this type of attack is to store the PIN in a tamper-resistant hardware element with well-defined interfaces, such as a SE coprocessor with associated APDU communications interface, which we discussed earlier in this chapter. Google Wallet could craft an APDU command that includes the PIN in the data field, which would be sent to a particular applet on the SE. The applet executing within the Java Card runtime environment on the SE would process the APDU command in the Applet.process(APDU) method. If the PIN was successfully verified, then the applet should return a status word with the value of 0x9000 as part of the response APDU. Otherwise, the applet should increment its PIN try counter (again stored in the SE). If the PIN try counter exceeds a certain threshold, such as 5 or 10 attempts, then the applet should lock itself in order to prevent brute-force attempts. Any future attempts to access the applet should always fail, and the payment applets must not be permitted to be accessible over the contactless interface, so transactions cannot be conducted with a POS.
Countermeasures for Google Wallet CrackerGoogle Wallet end-users should be aware of this attack and take a few steps to make exploitation substantially more difficult for the thief who just stole their mobile device. As stated previously, rooting your own mobile device makes it easier for a thief to pull off this attack, so don’t root your device if you want to also use Google Wallet. Additionally, users should enable the Android lock screen, disable ADB debugging, and keep up-to-date with the newest Android OS patches (this, of course, depends on manufacturer and MNO diligence with patch release cycles).
Relay AttacksRelay attacks occur when an attacker relays a message from the victim to the intended receiver without modifying the message. The attacker may not understand the contents of the message if it is encrypted or obfuscated, but the attacker is simply replaying the messages to the intended receiver. This attack is certainly not new, but in 2005 Gerhard Hancke showed that relay attacks were a practical attack vector against contactless smart cards (rfidblog.org.uk/hancke-rfidrelay.pdf). These attacks are also applicable to mobile payment applications utilizing NFC to conduct contactless transactions. Figure 9-5 shows the layout of the relay attack against a NFC-based mobile payments application.
Figure 9-5 A relay attack against a NFC-based mobile payments application
The following are the basic steps required to carry out a relay attack:
1. The “mole” contactless reader controlled by the attacker gets close to the victim’s mobile device or contactless credit card.
2. The attacker’s mobile device gets near a contactless POS terminal in order to buy something. The attacker’s device is using software NFC card emulation. Card emulation is a feature that allows a NFC-enabled device to emulate a contactless smartcard in software. NFC card emulation is supported by all Blackberry 7 and 10 devices that support NFC. Although Android does not officially support NFC card emulation, the custom ROM Cyanogen mod does.
3. The contactless POS terminal sends an APDU command to the attacker’s mobile device. The first APDU command selects the PPSE applet, which, in turn, provides information about available payment instruments on the mobile device, in preparation for making a payment.
4. The attacker’s mobile device sends the APDU command to the “mole” contactless reader over the Internet or via some other communication channel, such as Bluetooth (assuming the attacker’s mobile device and the “mole” are within range).
5. The “mole” contactless reader relays the APDU command to the victim’s mobile device over NFC.
6. The victim’s mobile device responds by sending an APDU response to the “mole” contactless reader over NFC. The response to select the PPSE applet should include the File Control Information (FCI) template that includes a list of available payment instruments.
7. The “mole” contactless reader sends the APDU response to the attacker’s mobile device over some communication channel.
8. The attacker’s mobile device then sends the APDU response to the contactless POS terminal. This process continues until the transaction is complete. After receiving the information from PPSE, the contactless POS terminal then selects the relevant payment applet and acquires the processing options, payment credentials, and so forth.
The important part to note about this attack is that attacker’s mobile device and the “mole” contactless reader are simply relaying the APDU commands and responses between the actual contactless POS terminal and the victim’s mobile device. The attacker does not need to understand the contents of the messages between the victim and the intended receiver. Therefore, using message-level encryption or integrity checks would not prevent this type of attack because the attack is a simple range extension of the contactless communications.
It’s also important to note that this is a relay attack, not a replay attack. The attacker is not replaying legitimate activity, but is instead relaying attacker-initiated activity between the victim and the intended receiver. Thus, the attacker can perform arbitrary transactions without understanding the contents of the messages, which is probably much more interesting than replaying static prior transactions.
This type of relay attack has a few caveats: one, the attacker’s “mole” contactless reader needs to be relatively close to the victim, and two, the victim’s mobile payment application must be unlocked; that is, the payment applet must be available over the contactless interface during the attack. For contactless credit cards, the payment applet is always available over the contactless interface, but for mobile payment applications such as Google Wallet or the Isis Wallet, the payment applets are only exposed over the contactless interface after the user has entered his or her PIN and unlocked the virtual wallet.
Security researchers have started to demonstrate the feasibility of relay attacks against mobile payment systems, e-passports, and other smartcard-based systems to demonstrate the risks involved. Researcher Michael Roland disclosed in late 2012 that Google Wallet was vulnerable to a more severe version of the relay attack (arxiv.org/pdf/1209.0875.pdf) because mobile malware on a victim’s phone could directly communicate with PPSE and the payment applets contained within SE over the contact interface. Normally, these applets are only used over the contactless interface to transfer the payment credentials to a contactless POS terminal. Figure 9-6 shows the layout of this next-generation relay attack against Google Wallet or similar mobile payment systems that expose payment credentials over the contact interface.
Figure 9-6 A next-generation relay attack against a NFC-based mobile payments application that exposes payment applets over the contact interface
For this type of attack, we assume the victim’s mobile device has been compromised by malware that is capable of gaining root privileges, such as a piece of malware similar to the DroidDream malware (see Chapters 4 and 5). The victim might be tricked into installing a rogue APK via a phishing email or a compromised website. Acquiring root access to the device allows the malware to bypass Android’s Secure Element API authentication controls that restrict which Android applications can communicate with the SE. This malicious relay software now has the ability to communicate with the SE and starts listening for a connection over the Internet from the attacker’s mobile device. Here are the steps required to carry out this type of relay attack:
1. The contactless POS terminal sends an APDU command to the attacker’s mobile device, which is using card emulation.
2. The attacker’s mobile device relays the APDU command to one of the compromised mobile devices over the Internet.
3. The network API on the victim’s mobile device passes the APDU command to the malware.
4. The malware sends the APDU command to the Android’s SE API. Note that the malware can perform this action because it has bypassed the SE API authentication at the OS level.
5. The SE API sends the APDU command to the SE. Again, in the case of a contactless transaction, the first APDU command is directed at the PPSE applet and then the subsequent APDU commands are directed toward the proper payment applet.
6. The SE provides an APDU response to the SE API. In the remaining steps shown in the diagram, the APDU response is relayed via the same communication channel all the way back to the contactless POS terminal. This process continues until the transaction is complete.
As you can see, the next-generation relay attack is more serious than the traditional relay attack because a malicious actor could remotely compromise a large number of Android devices that are running Google Wallet and then pick one to use when the attacker wants to purchase goods in a store. Essentially, the malicious actor could create a mobile payments botnet for the purpose of committing credit card fraud.
Relay Attack CountermeasuresA number of academic proposals have been made to prevent relay attacks. One proposal is that contactless POS terminals should enforce a time-out constraint on all transactions as per the globally recognized EMV specifications for chip-based consumer payment applications (see emvco.com), since the relay attack increases the time required to perform a transaction because it has to relay the same information over NFC and some other communications channel such as Bluetooth or the Internet. In theory, this anomalous time difference would block fraudulent transaction attempts by setting a time-out appropriately. This solution may not be ideal given that errors may cause the expected processing time for a normal transaction to vary greatly, and this mitigation may only prevent relay attacks over a long distance and not prevent relay attacks conducted over a shorter distance or a high-speed communications channel.
Another proposed solution is to use location information to detect that a relay attack is in progress. If the victim’s mobile device is not in the same geographic location as the POS terminal, then the transaction should be aborted. The main drawback to this mitigation is that it requires that the mobile device and POS terminal have GPS service during the time of a transaction, which may not be the case if the mobile payments system is designed to work in an offline mode. In addition, consumers would have to consent to having their locations tracked by the payments industry in order to validate transactions, a potentially unlikely scenario due to privacy concerns.
While preventing traditional relay attack is difficult in current systems, protecting against the next-generation relay attack is relatively straightforward, and the Google Wallet is no longer vulnerable to such attacks. Google Wallet no longer exposes the payment applets over the contact interface; therefore, malware installed on a mobile device can no longer pull payment credentials from the SE. These applets are now only exposed over the contactless interface because they only need to interact with a contactless POS terminal. A Java Card applet can programmatically determine whether it is being invoked over the contact interface or the contactless interface by invoking the getProtocol function associated with the APDU class and deny access over the contact interface or the applet can be configured to only be exposed over the contactless interface declaratively during personalization via installation parameters.
The Square mobile payment system was released in 2010. It consists of a mobile application (Square Register) that interfaces with a magnetic stripe reader that plugs into a mobile device via the headphone/microphone jack. Square provides the magnetic stripe reader free of charge to anyone who signs up for the Square service. The Register software in combination with the reader allows anyone to take credit card payments and have the funds deposited into a bank account, with Square taking a small percentage of every transaction.
Square caught the eye of several security researchers (and one of their competitors, VeriFone), who publicly released exploits against their software in 2011. Let’s take a look at these exploits and where the software stands today.
SkimmingThe Square reader works by encoding a swiped credit card into an audio stream, which is then sent to the Square servers for decoding and payment processing. Because the reader is a piece of external hardware, it cannot determine what application it is passing the audio-encoded card information to; it simply records the swipe and passes it to the mobile device.
VeriFone (a competitor to Square) released an application in 2011 that abused the functionality of the Square reader to turn a mobile device essentially into a credit card skimmer. VeriFone showed that any application could receive the audio data from the Square reader and, in turn, could decode the credit card information from it. An attacker could then clone the information stored on the credit card. Combine this with some malware repackaged as the Square Register software that sends a copy of the credit card information to a remote server, and now you have a botnet harvesting credit card information from unsuspecting customers and merchants!
Skimming CountermeasuresThe main caveat to this attack is that if the attacker is using the Square card reader to skim your card … they already have your physical card in hand! This is no different than a rogue waiter skimming your card at a restaurant or a skimmer installed at a POS. The biggest issue here is that Square effectively lowered the price for attackers—now anyone can skim credit cards with a free reader and some software they download off the Internet.
The potential for a botnet of rogue Square readers makes this issue more severe, though to our knowledge no such attack has ever been performed. Both of these issues were addressed, however, when Square updated its reader hardware. Where the original Square reader consisted of just the magnetic stripe reading heads attached to the audio jack, the new Square reader released in early 2012 contains additional hardware designed to encrypt the audio stream before it is passed to the device. This prevents a malicious application from decoding the card information from the reader. The encrypted card information is sent to Square’s servers where it is decrypted for payment processing, meaning the Register application does not need to touch the encrypted data and can simply pass it along with the other transaction data.
Replay AttackAs you saw in the skimming attack, any application on a mobile device could record the audio stream from the Square reader. This capability leads us to a more interesting attack, one in which an application can record the information provided by the reader and replay it back to the Register application at a later date to make another payment. Security researchers Adam Laurie and Zac Franken presented this attack at Black Hat 2011. They showed it was possible to record the card information from the reader to a computer and then replay that information back to the mobile device by connecting the two with a stereo cable, allowing them to reuse the skimmed credit card information repeatedly for payments.
More interestingly (and where this attack deviates from the previous skimming attack), they figured out the format for how the Square reader was encoding the Track 2 data from the credit card. Armed with this knowledge, they were able to build an application that allowed them to enter credit card details and generate a new sound file containing the encoded credit card information, which they could then play back to the Register application the same way described previously. This meant that with just the Track 2 data, they were able to make a valid payment via Square. They never needed physical access to the card! This attack could provide anyone with stolen credit card information with a way to “cash out” those cards without needing to clone fake magnetic stripe cards.
Replay Attack CountermeasuresKilling two birds with one stone, Square’s addition of encryption hardware in the reader also helped to prevent this sort of replay attack. Although Square hasn’t released any details about what exactly their encryption entails, we decided to do a little testing of our own to see if this replay attack was still possible. After hacking together a custom cable (wiring a stereo cable into a cellphone headset microphone), we used the Square reader connected to a laptop to record a credit card swipe. Figure 9-7 shows the results of our testing.
Figure 9-7 Encrypted card data dump taken from Square reader
Once we had a copy of the swipe, we connected our cable to an Android phone with the Register software installed and played back the sound file. The first time we did this, the transaction went through successfully, which is what we expected to happen; we hadn’t really changed the way the application worked at this point. Next, we attempted to replay the sound file a second time. The Register application recognized the sound as a swipe again, but this time we got an error message from the application informing us that this was not a valid payment card. After several more attempts, it appears that it is not possible to replay the encrypted card information.
While we’re not sure exactly what Square is doing, we have some ideas about how they might be checking for replays. For example, the reader might be generating a random encryption key that is used to encrypt the Track 2 data, and then encrypting that key along with a nonce and a counter value with a preshared symmetric key or the Square server public key. Then they could concatenate the encrypted key with the encrypted Track 2 data, sign it, and pass it off to the server for verification and decryption, checking the counter to make sure the same request wasn’t being replayed. Of course, this is just speculation on our end, but whatever Square is doing, it seems to be working!
Mobile payment systems have been on the verge of breaking into the mainstream for the last few years. Consumers are now being exposed to working systems such as Google Wallet and Isis. Forrester is predicting that 90 billion dollars will be spent via mobile payment systems in 2017, which is a striking predication considering only 12.8 billion dollars were spent in 2012. Their predication is based largely on the assumption that more and more people will make proximity payments via a system such as Google Wallet or Isis. We’ll have to wait to see what happens, but as the mobile payments industry grows, fraudsters will no doubt try to capitalize on the trend. While mobile payment systems have some clear security advantages over traditional magnetic stripe cards, including PIN protection and the use of dynamic transaction verifiers, such as dCVVs to prevent replay attacks, the devil is in the details. Attackers will no doubt discover and exploit implementation bugs and design flaws, so we will need to harden our mobile payment systems further to resist known attacks and continue researching and testing to uncover previously unknown weaknesses.
