NFC SECURITY ON ANDROID DEVICES

by

MATTHEW QUINLAN

Advisor

DR. ELAARAG

A senior research paper submitted in partial fulfillment of the requirements

for the degree of Bachelor of Science

in the Department of Mathematics and Computer Science

in the College of Arts and Science

at Stetson University

DeLand, Florida

Spring Term

2013

1

TABLE OF CONTENTS

TABLE OF CONTENTS .................................................................................................... 1

LIST OF FIGURES ............................................................................................................ 3

ABSTRACT ........................................................................................................................ 4

1. INTRODUCTION .................................................................................................. 5

2. Related Work .......................................................................................................... 7

3. NFC ....................................................................................................................... 10

3.1 NFC PROTOCOLS ............................................................................................. 11

3.2 NDEF FORMAT .................................................................................................. 13

4. NFC SECURITY ON ANDROID DEVICES ...................................................... 16

4.1 NFC ATTACKS ................................................................................................... 16

4.2 SECURE ELEMENT............................................................................................ 20

4.3 CLONING............................................................................................................. 22

4.4 COMMUNICATION ............................................................................................ 23

5. FUZZING ANDROID’S NFC STACK................................................................ 26

5.1 PROTOCOL LAYER FUZZING ......................................................................... 28

5.2 APPLICATION LAYER FUZZING .................................................................... 29

6. IMPLEMENTATION ........................................................................................... 30

2

6.1 NFC Lab Setup ..................................................................................................... 31

6.2 TEST CASE GENERATION ............................................................................... 32

6.3 PROTOCOL LAYER FUZZING ......................................................................... 34

6.4 APPLICATION LAYER FUZZING .................................................................... 36

7. FUZZING RESULTS ........................................................................................... 39

8. CONCLUSION ..................................................................................................... 40

APPENDIX ....................................................................................................................... 42

FUTURE RESEARCH ..................................................................................................... 43

REFERENCES ................................................................................................................. 44

3

LIST OF FIGURES

Figure 1: NFC Protocol Stack………………………………………………………….. 3.1

Figure 2: Sample NDEF Smart Poster Tag……………………………………………. 3.2

Figure 3: NFC attack surface if NFC can communicate with browser…………………... 5

Figure 4: Galaxy S 3, ACR-122U, and SCL-3711 card reader/writer/emulator………. 5.1

Figure 5: Smart Poster Fuzzing Example using Sulley Fuzzing Framework…………...6.2

Figure 6: Bluetooth Fuzzing Example using Sulley Fuzzing Framework………………6.4

Table 1: Sulley Fuzzing Framework Smart Poster Fuzzing Example ………………….6.3

Table 2: NDEF Message Test Cases………………….....................................................6.4

4

ABSTRACT

In this paper we investigate the impact that the addition of NFC technology has

had on Android mobile devices. We explore the NFC specifications and their inner-

workings. We investigate new attack vectors created by NFC, show real-world case

studies of attackers utilizing attack vectors, and we provide solutions or mitigations to

help reduce these attacks. Researchers have shown that NFC-enabled mobile devices are

prone to various flaws in their NFC stack implementation. We discuss the NFC stack’s

implementation on Android phones and also the changes that it has undergone on newer

versions of Android. Next we will talk about the process of fuzzing the NFC stack on

Android to find various errors and bugs. These flaws in the NFC stack have shown to

result in compromised user data or attackers gaining remote control of the mobile device.

For this research, we implemented two test case generation scripts that utilize the Sulley

Fuzzing Framework to generate/fuzz NDEF test cases. In addition, we have implemented

two python scripts namely an libnfc script and an nfcpy script. These scripts are used to

load test cases and automate the Android fuzzing process. Finally, we propose two

mitigations that help to protect the security and privacy of the user.

5

1. INTRODUCTION

Near Field Communication (NFC) is a newly-emerging technology that has been

recently incorporated into mobile devices. NFC builds upon the existing radio-frequency

identification (RFID) specification. NFC operates on the low-range 13.56 MHz frequency

umbrella and can therefore read 13.56 MHz RFID or NFC tags. The NFC specification is

unique from RFID in that two-way communication is now possible and even at data

transfer speeds of up to 424 kbit/s. Two NFC-enabled devices can communicate as long

as the devices are within range (about 4 centimeters). The speed and convenience of

device to device data transfer has opened up the doors for continued innovation and

adaptation of NFC into more markets. NFC hardware has been integrated into newer

Android smartphones and NFC functionality has already been incorporated into many

mobile Android apps. Google Wallet is one example of an Android app that uses NFC

technology. It is an app that allows you to use your credit cards, gift cards, and other

highly sensitive financial information over NFC to checkout at supported (PayPass) card

terminals. As with any new technology implemented, we must look into NFC’s

implementation and assess the risk of any new attack vectors and possible malicious NFC

apps on mobile devices. We will assess the security of NFC on Android devices and

discover the degree of impact that this new functionality will have on the overall security

of mobile devices.

6

This paper investigates the security of the Android OS version 4.1 codename

Jellybean. Research in this area focuses on NFC security and mobile devices but more

thorough research is needed with a focus on Android. This is especially important due to

its high market share and mass incorporation of NFC technology into smartphones. This

paper recognizes and provides mitigations for the NFC attack vectors introduced. Also

discussed, are the steps and scripts needed to fuzz or, test a numerous variety, of NFC

tags and, in doing so, find bugs or errors in the implementation of NFC on an Android

device.

The rest of this paper is organized as follows. Section 2 presents related work and

research concerning the security of NFC and Android devices. Section 3 covers the

background of NFC as well as information about its workings and protocols. Section 4

presents the NFC attacks on Android and organizes them into four categories. Section 5

describes the background and information necessary to fuzz the NFC stack on Android.

In Section 5.1 we discuss three NFC devices used in this research namely the Samsung

Galaxy S3, the ACR122U, and the SCL271. These devices allow us to read, write, and

emulate NFC tags and even perform tests and attacks against the Android device. Section

6 discusses our implementation, scripts, and frameworks used in the fuzzing process.

This section is about the process of creating/emulating numerous different NFC tags of

the various protocols and types and watching to see how a specific Android device and

operating system reacts to the tag. We are expecting the web browser to open, the pdf

reader to open, the picture viewer to open, etc. This is a more hands-on approach to the

process of finding NFC bugs and exploits on Android. Finally, section 7 presents the

7

fuzzing and research results regarding NFC security on Android devices. It discusses the

changes that have taken place regarding NFC security on Android.

2. Related Work

Several researchers have been concerned about NFC security issues [1-3]. Since

the implementation of NFC technology into mobile devices, researchers have begun

looking for new attack vectors, testing, and performing attacks on NFC-enabled mobile

devices [4-15]. Little research has gone into testing the impact NFC has on the security of

Android NFC-enabled mobile devices [12, 16].

In [1], Miller explores the new attack surface that the addition of NFC adds to

mobile devices. He goes into great detail about both NFC and its various protocols. He

explores, tests, and fuzzes the NFC stacks of both the Galaxy Nexus S and the Nokia N9

NFC phones. He uses the ACR122U and a SCL3711 NFC devices as his NFC card

emulator. He also uses an automated python fuzzing setup for the NFC stack on these

mobile devices. Finally, he presents his success with the Nokia N9 NFC mobile device as

well as his success with Android as a result of the various crashes and interesting test

cases he generated.

Scharinger et al. [15] provides an analysis of the security of NFC technology on

devices. Their research focuses on the misuse of the different operating modes of NFC.

In this research they show several security issues in NFC devices and provide

8

countermeasures that could be implemented to further protect the security and privacy of

the end-user. They provided countermeasures for flaws such as phishing, skimming

secure element data, and denial of service. Their list of proposed countermeasures are

designed to deal with the various issues regarding the security and privacy of NFC

devices.

In [12], Mulliner analyzes the security of NFC-enabled mobile devices. To fuzz

NDEF messages he writes data to an NFC tag, scans the tag with the device he is testing,

and analyzes the output on the device. This method of fuzzing using NFC-tags was used

to analyze various NFC attacks on different mobile devices. Mulliner found that several

security vulnerabilities existed on NFC-enabled mobile phones such as the phishing of

websites, a POC NFC worm, Denial-of-Service attacks, and attacks on the underlying

telephony service. This research presents unique attacks against NFC devices.

Jara et al. explores in [13] the cryptography capabilities of various NFC devices in

hopes of implementing a cryptographic and secure way to transfer NFC data. A variety

of security problems of NFC are discussed as well as solutions provided. These attacks

include social engineering, privacy of the device, eavesdropping, and relay. They also

present great information about the speed and analysis of the timing and overhead of

various cryptographic ciphers. They propose a hybrid security solution for NFC in which

both asymmetric and symmetric cryptographic solutions are used for all of the

communication process.

In [14], Roland presents the advantages and disadvantages of implementing

software card emulation on mobile devices. Due to the lack of security and protection of

9

information against relay-attacks, their research concludes that software card emulation is

not necessary for NFC devices or the p2p mode of NFC. Roland finds that card emulation

cannot adequately protect the data in the card being emulated. He also believes that

restricting the functionality of software card emulation is not a robust defense against

software card emulation attacks as removing this restriction has already been done on

various Cyanogenmod ROMS.

In [11] Roland and Scharinger research the impact of embedding a secure element

or a smartcard into an NFC-enabled mobile device. Their research discusses new attack

scenarios against mobile devices given that a malicious application is installed on the

NFC-enabled mobile device. They present two attack scenarios against the smartcard in

NFC mobile devices namely the relay-attack and denial of service attack. They also

conduct research into various smartcard security frameworks similar to the SEEK for

android project that provides a protected API access to the smartcard to prevent malicious

usage. This research delves into a critical component of NFC hardware, the smartcard.

This research offers insight into the various solutions available for future implementation

that would provide a safe and secure way to access a smartcard’s API.

10

3. NFC

Near Field Communication is an extension of several Radio Frequency

Identification (RFID) communication standards. It essentially combines the RFID

standards and adds additional features which are composed of two new communication

standards. The two primary features added in the standards are peer-to-peer connections

between two active NFC devices and the emulation of a passive proximity RFID tag. The

NFC technology mainly focuses on contact-less smartcards that operate at a frequency of

13.56 MHz. There are three modes of communication using NFC. First, NFC can

communicate using card emulation in which it can emulate a passive RFID smartcard or

token. In NFC terminology a smartphone can become a passive target (for example, an

NFC tag) for an initiator such as an NFC reader. Second, there is reader/writer mode in

which smartcards and NFC tags can be read from and written to. Communication takes

place by an initiator, for example a mobile device, actively generates a radio frequency

(RF) field that powers a passive target such as an NFC tag. The target NFC tag answers

by modulating the existing field provided by the initiator. Depending on the target and

tag, which decides what protocol to use, the initiator may be able to read and write data to

the tag. Third and last, there is the peer-to-peer mode in which two NFC devices act as

active initiators and are able to communicate and send data bi-directionally to one

another. The two NFC devices must be able to generate their own RF field for

11

communication to occur. We will focus on fuzzing the protocol layers of these three

methods of NFC communication. The latter of the three, the P2P protocol or LLCP

(Logical Link Control Protocol) will be our focus in the testing of the NFC security on

Android Smartphone devices.

3.1 NFC PROTOCOLS

NFC communication could be thought of as a bridge between the physical and

digital world. It is with a simple NFC tag’s touch in which a virtual connection is

automatically established using NFC protocols. Understanding new attack vectors in

Android devices requires understanding some of the underlying protocol stack on which

NFC is based. Layer 1, the lowest layer of the NFC stack, will be regarded as the RF,

initialization, and anti-collision layer and will not be discussed as they handle the signal

and starting communication. The protocol layer is the layer for actually transmitting the

data intended to be sent or received with the communication. The data could

theoretically be anything, but a typical data payload; an NDEF message, is covered in the

next section. There are a variety of protocol layer protocols to communicate with the

various types of RFID and NFC tags. As shown in Figure 1, an NFC tag is scanned at

layer 1 it then goes up to layer 2 the protocol layer. At layer 2, each specific protocol for

the various NFC tag’s has a type assigned to it by the NDEF Spec. There are currently 4

various types of tags Types 1,2,3,and 4 and 1 standard NFC tag [17-21]. At layer 3, the

12

application layer, an NDEF message would be created using the type field of the protocol

being used. The appropriate Android application would then read and interact with the

NDEF message created. A response NDEF message could be crafted specifying a type

for the protocol one wishes to use can be sent back down the protocol stack. As an

example of this protocol stack, imagine now at Layer 1 a MiFare Ultralight NFC tag is

scanned by an Android device. At layer 2, the Android device recognizes the protocol

used and communicates with it using the MiFare Ultralight protocol. At layer 3 an NDEF

message with a type 2 field is created that contains communication from the tag. This

communication is then read by an Android phone and communication may be sent back

down the stack.

13

Figure 1: NFC Protocol Stack

3.2 NDEF FORMAT

In layer 3 of the protocol stack, NFC transport has been done and the data has

been delivered to the application layer in the final form of an NFC Data Exchange

Format (NDEF). The NDEF is a simple binary message format that is used to

encapsulate and represent the various RFID protocols and NFC tags in one NDEF format

14

[22]. NDEF contains different identifiers, fields, and flags for communication purposes

and to describe the type of data it contains. URI’s and Smart Posters are two examples of

the various NFC record types. More details about NDEF specifications for the various

types supported in NDEF as well as the specifications for each type can be found in [22-

25].

Figure 2 below contains a sample NDEF record for a Smart Poster NFC tag. This smart

poster has its URL field set to “google.com” and the optional title field set to “hi". Smart

Poster tags are designed to perform an action on the URL when scanned. For Android

devices, the scanning of the following tag will cause the Android browser to

automatically open the given URL.

Figure 2: Sample NDEF Smart Poster Tag

15

In Figure 2 above, the first two lines show the hexadecimal data of the Smart Poster tag

[24]. Below those lines are the hexadecimal values broken down into the NDEF format’s

blocks specified in the NFC Forum’s specifications. For example, the first two nibbles

“d1” in binary is equal to 11010001. Respectively the binary values represent the fields

MB, ME, SR, CF and TNF. The rest of the nibbles follow the NDEF specification and

similarly match to their corresponding field name.

16

4. NFC SECURITY ON ANDROID DEVICES

We have found various attacks against Android NFC-enabled mobile devices. We

organize them in the following four categories of attacks:

1. Fuzzing/NFC software stack errors

2. Secure Element

3. Cloning

4. Communication

For each attack we present the problem leading up to the attack, a case-study of

the attack, and also a solution or mitigation to the attack. This research and information is

useful to the end-user so that they can recognize when a malicious NFC tag as well as

when their mobile device is being attacked. NFC is typically used as a shortcut to trigger

an action. Consequently, NFC can be used as a shortcut to trigger different attacks against

the phone. A problem one can see is that users typically identify tags by scanning them

and observing the action. This research helps to inform users so that they are aware of the

security and privacy features that an NFC-enabled Android device can offer.

4.1 NFC ATTACKS

Web browser phishing and Smart Poster URI spoofing attack

17

Problem:

The Smart poster URI spoofing attack involves writing a Smart Poster tag’s data

by inserting multiple newline or return characters after the title in the title field so that it

appears to the user that they are going to the intended website in the tag title while they

are actually going to a malicious site. Smart Posters are a type of tag that act as shortcuts

in which, when scanned, they perform a default action for that tag or prompt for an action

to be performed. There are many listed types of URI’s (tag types) available that may

either prompt to open an Android app or by default auto-open themselves on the Android

device. This URI spoofing attack is a type of NFC web browser attack in that the URI of

the Smart Posters on NFC devices is automatically opened typically without user

interactions. The malicious intent with these attacks is to mislead or phish the web

browser to make the user believe he is on a legit website. The website however is a

malicious look-alike that may perform malicious actions like stealing user data or even

controlling the user’s device.

Application:

NFC Smart Poster tags can be placed in signs and in public places and contain

unchangeable links to malicious sites. These tags when opened by accident or on

purpose may open up a web browser that will attempt to install malicious content or

perform malicious actions on your device. The web browser may also open up a web

browser that appears like the user’s bank to con them into logging in and revealing their

password.

Solution:

18

The 4.1 version of Android tested was not found to be vulnerable to a URI

spoofing attack. However, due to NFC’s use as a shortcut, it provides a gateway to a web

browser phishing attack when a Smart Poster tag is scanned. Users typically have their

browser, by default, open the URI of a NFC tag when scanned. This URI could be a

malicious site that is then opened by the browser.

A mitigation to the web browser attack would be an option to allow NFC use only

when a user-defined button combination is held down. This would prevent NFC tags and

shortcuts from accidentally being triggered.

Samsung TouchWiz Denial of Service Attack

Problem:

NFC tags act as shortcuts and, at times, when scanned the user is unable to check

if the shortcut is intended to be used maliciously before it is opened. An NFC tag could

abuse a standard NFC app and use it maliciously against the user’s physical phone or

data. The Samsung TouchWiz attack is an example of a combination of a web browser

attack, an Android app being used unintentionally, and a device denial of service attack.

Application:

The USSD (Unstructured Supplementary Service Data) service codes are numbers

a person can dial into their phone. These codes usually beginning with a star or pound

sign and are used for diagnostics or retrieving sensitive phone information. The

TouchWiz attack is a real world attack that occurred on Galaxy S3 devices. This attack

used NFC as a shortcut to trigger this USSD, a developer’s backdoor, for malicious use.

19

One specific and dangerous USSD code was used as an attack vector as it allowed a user

to enter in a series of characters in the phones dialer to cause an un-cancelable factory

reset on the user’s phone. This attack can be demonstrated on a stock Galaxy S3 4.0.4. It

can also be triggered by either the web browser or NFC tel: URI tag.

Solution:

Fuzzing and testing is one way to test for other unknown developer backdoors.

Dangerous TouchWiz service codes such as this need to be removed to protect user data.

Samsung has submitted an update to TouchWiz disabling the USSD service code.

Meanwhile, a configurable user-button configuration to enable NFC would help prevent

an attack like this from being triggered.

Denial of Service (Device)

Problem:

Android and the various services and applications that can read in NFC tags

through the NFC stack may be vulnerable to DOS (denial of service) attacks. These DOS

attacks would take place through malformed NDEF messages or fuzzed LLCP packets.

Application:

Malformed NDEF messages could be placed in public places and if an NFC-

enabled mobile device reads such a tag either on purpose or accident their device will

crash and reboot or even force a factory reset of the user’s device.

Solution:

The solution to this problem is to fuzz NDEF messages and provide fixes to

20

various error and bugs in parsing malformed NDEF messages. Our goal is to find NFC

tags that cause such errors. A mitigation to this problem would be the same as above. An

option to allow NFC use only when a user-defined button combination is held down

would deter users from accidentally scanning a malicious tag.

4.2 SECURE ELEMENT

Denial of Service (Secure Element)

Problem:

NFC-enabled phones currently come with embedded secure elements or

smartcards. Android NFC devices require secure element access for card emulation. This

secure element however is vulnerable to a denial of service attack. The secure element

card is put into TERMINATED state after ten successive authentication failures for card

management. Once in TERMINATED state all installed applets will continue to be

available but card management is no longer possible. As a result, applets cannot be

installed or removed. An authentication to the card manager of the secure element

consists of three secure element commands: SELECT, INITIALIZE UPDATE, and

EXTERNAL AUTHENTICATE. For an embedded secure element, card management

must be available through the secure element API. On Android, access to the secure

element is limited to only a few select Google and manufacturer apps. This means that

these apps are able to make authentication attempts to the secure element. If a malicious

21

app were able to inject code or an exploit and gain access to the secure element api, the

result would be a permanently TERMINATED or locked secure element. Having a

locked secure element would make card emulation unusable on that Android device.

Application:

A game from the Google Play Marketplace is fun and easy. This game is actually

a malicious app which has utilized a new exploit and, in doing so, has escalated its

privileges and gained access to the secure element API. This malicious application then

authenticates incorrectly ten times with the secure element card manager and, in doing so,

has locked and TERMINATED that devices secure element and card emulation

functionality.

Solution:

Secure element access is currently restricted on Android devices. There are

currently several different existing APIs and projects that are being considered for

adoption on Android. These API’s would provide various levels of protection to the API

of the secure element from malicious usage. Access and protection against malicious

usage for the secure element API may come from using frameworks such as the SEEK

for Android project. This project provides a standardized, secure smartcard API for the

Android platform.

22

4.3 CLONING

Cloning tags

Problem:

The NFC specifications give each NFC tag only one “unchangeable” unique ID.

This manufacturer generated and given unique ID is used for identification as well as the

anti-collision algorithms. What is problematic is that this manufacturer given unique ID

is used in communication even when the other device is unauthenticated. This proves to

be a privacy issue as this unique ID is exclusive to that tag and owner. Along with this

privacy issue, NFC tags’ unique ID’s can be easily cloned. NFC tags that have a

programmable unique ID can be purchased online and there exists software NFC tag

emulators that also can completely clone and write unique IDs.

Application:

A new application for Android comes out on the Google Play market that gives

the user the functionality to unlock their Android device by just scanning their personal

NFC tag. This app uses the unique ID of the NFC tag as a key to unlock the owner’s

device. Since the unique ID of the user’s NFC unlock-tag is “given out” that unique ID

can be software emulated or cloned onto another tag. Due to this security hole, a

malicious user can now gain access to that user’s phone.

Solution:

For security, privacy, and anti-collision purposes, an NFC tag should use a fake,

23

randomly generated unique ID while communicating with an unauthorized user of an

NFC tag. The real unique ID assigned to that NFC tag should only be given to and used

by authorized users. Since tags can be cloned, users should never use NFC tags to unlock

their Android device.

4.4 COMMUNICATION

Relay Attack and Information Stealing

Problem:

With the introduction of NFC hardware, the Android OS has become a suitable

platform to access the contents of a RFID or NFC tag remotely. An Android app, once

NFC access control permissions have been given, that app has access to data scanned and

sent by the NFC controller. The app can then read and write tags and communicate with

the secure element (it is only restricted from card emulation mode which has been

restricted for nearly all apps on all Android devices). The relay-attack works by sending

commands (APDU’s) received from the point-of-terminal or RFID/NFC initiator device

and forwarding them over a network socket to a malicious app installed on a victim’s

device. The NFC controller on the victim’s Android device is accessed and the app

relay’s the victim device’s response (APDUs). Through this relay-attack one is able to

access the NFC controller of a device without physical access to the device. This attack

puts the victim’s privacy at risk as the malicious user can now use this forwarded

24

information maliciously.

Application:

A relay-attack in a real-world scenario begins with a mobile malicious game

installed on installed on a device that utilizes an NFC payment system similar to that of

Google Wallet. This malicious game is the relay-application and it is assumed that it has

been given NFC permissions or been escalated to them. Using Google Wallet as an

example, an attacker checks out at the store using paypass and, in doing so, receives

commands from the paypass, the RFID initiator, and forwards these commands to the

victim’s device through a network. The victim’s device is accessible as a result of the

malicious app installed. This app is able to communicate and send data to the NFC

controller of which Google Wallet is manipulating. The victim user may have to enter a

pin or it may be possible to brute force or workaround the pin. The malicious app will

then respond to the attacker’s device with the correct NFC emulation information that

contains the victim’s payment information. The attacker’s phone emulates the data

received from the victim’s phone and then checks-out as if he physically had the victim’s

phone. As one can see the latency between sending and receiving data is the only factor

here as the victim must have a good connection to the internet. This attack is typically

performed using WIFI. As a second step in this attack, an attacker may retrieve all the

data from the victim’s secure element and because they are using Google Wallet the

attacker is able to retrieve all Virtual Google Wallet credit cards that have been linked to

that user’s real credit cards.

Solution:

25

There are two solutions that help mitigate the relay-attack. One solution to the

relay-attack that is already implemented in Google Wallet is that the user has to enter

his/her pin to unlock and open Google Wallet before completing every transaction. It may

be possible, however, to steal and sniff a user’s pin by catching where a user touches

when entering their pin and then replaying that information back. We propose a second

solution to this attack in which an option is present in Android that allows the use of the

NFC controller only when a user-defined button combination is held down.

Eavesdropping Attack

Problem:

NFC and RFID are two communication protocols intended on communicating

with recipients at a close range. However, it is possible for more expensive equipment to

communicate at a longer distance. In this eavesdropping attack, it is possible for an

unintended recipient to intercept and read messages.

Application:

NFC device Alice is trying to communicate private information to NFC device

Bob. Unaware of a third party reader, Alice’s data is eavesdropped by a malicious user’s

long range RF antennae pointed at Alice’s device.

Solution:

There are two solutions to this problem the first is to ensure that no other RFID or

NFC readers are able to intercept your RF field. The second, we propose, is to implement

asymmetric and symmetric encryption on all P2P NFC communication. That way, any

private RF data retrieved will be encrypted.

26

5. FUZZING ANDROID’S NFC STACK

The term fuzzing in our case is used to refer to testing the NFC methods of

communication with valid and invalid data. After each test, we record and observe the

output on the Android device. The process of fuzzing consists of the following. First, we

generate test cases for the various fields we wish to fuzz. In our case, we generate or fuzz

both NDEF messages and specific LLCP protocol packets. Second, we send or playback

the generated test cases on the Android device using our hardware and NFC

communication frameworks. Third, we observe the device’s output through USB

debugging services.

The first place to fuzz the NFC stack on Android is the protocol layer where data

is first communicated up the protocol stack and is parsed and converted into an NDEF

message. The next place to fuzz is the application layer which takes over and actually

reads and handles the NDEF message. Once the application layer receives the NDEF

message the Android NFC service prompts the user to set a default app to open or it

opens the default Android app using the NDEF message.

The NFC stack contains all the code necessary and responsible for parsing and

processing the NFC protocols mentioned in section 3.1. At the lowest level, a general

NFC stack consists of a driver for the NFC chip as well as a library used to communicate

with the driver. Next, a general NFC stack, specifically in the application layer, will

contain the code necessary to parse and process the various types of incoming NDEF

27

messages as well as the appropriate action to take once they are received. In Android, the

NFC stack is layered out as shown in Figure 3 [16].

Figure 3: NFC attack surface if NFC can communicate with browser

The NFC chip driver is located in the underlying Linux kernel in the Android OS.

Next, the library as well as the code responsible for parsing the NDEF payload is located

in a special “NFC Service” (com.android.nfc). This driver and the LLCP and NXP NFC

library stack’s above it are a target for protocol fuzzing. Finally, the application layer of

the NFC stack is triggered and the appropriate action is taken by opening Android Tags,

Android Beam or even Android browser application depending on the NDEF payload

processed.

In Android version 4.0.4, the Android Tags and Android Beam application have

been shown to, without user interaction, automatically open various programs to process

NFC data. There may be bugs in this NFC stack that would allow the remote control of

28

an Android smartphone. A foreseeable difficulty one can see is that Android apps are run

inside a java based virtual machine and memory corruption may not be a possibility.

However, native code will always be involved at the lowest levels (eg. a library or

driver).

There are different approaches to find NFC vulnerabilities and bugs in the Android

smartphone devices, but the best way is to start at the lowest level and work your way up.

In our case, the appropriate low level is the protocol layer of the NFC stack and we will

work our way up to the application layer.

5.1 PROTOCOL LAYER FUZZING

NFC bridges the gap between the physical and digital world. When touching two

NFC enabled devices or a device to a tag a connection is created. In other words, you

physically touch one object to another and through that they are able to connect and

communicate, without pairing, and share information. This background, almost magical,

connection between two different devices without pairing is the focus of protocol

fuzzing. The goal of fuzzing the protocol layer is to send unexpected data to Android

devices trying to abuse this automatic connection. By doing this, we are testing Android

and trying to figure out, crash, and get some sort of output on the Android device.

When fuzzing the protocol level of the NFC stack, the goal is to emulate as many

different types of tags, fields, and protocols as possible. We will be able to fuzz the

29

Capability Container and memory sectors of NFC Tags as well as the LLCP (or P2P

protocol) used by Android devices. When fuzzing, we want to use both valid and invalid

data packets in the protocol. By doing this, we wish to see how the Android library

responds. When an Android phone is placed near an NFC tag a communication is made

and credentials and authorization confirmed before tag data and memory access is

allowed. We will preset fuzzed NFC tag data to the Android device in this Capability

Container and memory sector of NFC Tags.

Another protocol we will fuzz is the Android P2P protocol known as LLCP

(Logical Link Control Protocol) [21]. This protocol is used by Android for P2P

communication between two devices. We are looking to find errors, bugs, or crashes in

the LLCP connection between these two devices. We will modify and fuzz a variety of

LLCP packets used to establish a connection and relay the NDEF message. We are

fuzzing the LLCP packets associated with starting a connection. We will fuzz the LLCP

connect, parameter exchange, connection complete, and receive ready packets of the

LLCP protocol. More information about these packets and their functions can be found

on the NFC-forum website in the LLCP specifications [21]. We will present the P2P

protocol to the Android device using our NFC lab hardware see Section 6.1.

5.2 APPLICATION LAYER FUZZING

Application layer fuzzing involves creating test cases of NDEF messages and

30

scanning them to observe the action taken by, in our case, the Galaxy S3 Android device.

When an NFC tag is scanned by a device the application layer receives an NDEF

message. Knowing this, we can fuzz by creating as many NDEF messages as possible

with as many combination of values in the various fields as possible. The goal here is to

create both invalid and valid NDEF messages that cause undesired output on the Android

device. Perhaps one of these messages will cause the Android NFC stack parser or

arbitrary Android application to execute the code we want, show an error, or crash.

Application layer fuzzing of NFC will continue to be needed as more and more Android

applications are developed with NFC. Pressure is put on the developers as poorly coded

NFC functionality may allow that app to be used for malicious attacks.

6. IMPLEMENTATION

Our implementation of NFC fuzzing uses a hands-on approach utilizing an NFC

lab we created. This approach seems to go well with our low-level protocol fuzzing

purposes. With an external USB NFC card emulator/reader/writer we are able to do card

emulation and P2P LLCP communication which allows as to fuzz the protocol and

application layers. Section 6.1 provides more information about the NFC lab setup.

Along with the hardware, our fuzzing implementation needs a few pieces of

software as well. We need an NFC framework that allows us to communicate using the

NFC communication protocols and our hardware. We utilize python scripts to fuzz

31

(generate) test cases and also to automate the iteration of scanning, recording, and

observing Android device output. We use the Sulley Fuzzing Framework [28] to generate

the various test cases for NDEF messages. We implemented two scripts written in python

that automates the fuzzing and emulation of NFC tags on Android. These Python fuzzing

scripts are implemented for the libnfc and nfcpy frameworks. The scripts, for each test

case we have generated, emulates or communicates using the test case and retrieves the

Android device’s state through USB debugging. There is also an auto-fuzz mode

implemented that generates random, bit-flipped test cases for the protocols or NDEF

messages we are fuzzing.

6.1 NFC Lab Setup

For our purposes in this research we need to emulate various NFC tags and

protocols. To do this we need to be able to do card emulation as well as P2P

communication. Card emulation is where we have a device that emulates an NFC act as

a passive tag. We were able to find two pieces of hardware that, after some tweaking,

could perform both card emulation and P2P LLCP communication. The ACS ACR122U

and the SCL 3711 were used with our Android Galaxy S3 device as an NFC tag

reader/writer/emulator. With tweaking, together these two readers support card emulation

of two types of NFC tags and also Android’s P2P protocol LLCP. Our hardware relies

on the NFC libraries provided by the open source frameworks of libnfc [26] and the

32

nfcpy project [27].

Figure 4: (left to right) Galaxy S 3 NFC Android Device

ACR-122U and SCL-3711 card reader/writer/emulator

6.2 TEST CASE GENERATION

The test cases used in fuzzing were generated using mutation and generation

based fuzzing. Mutation based fuzzing is used when starting with a valid test case and

changing and mutating it as needed. In our case, mutation fuzzing begins with a valid

group of hexadecimal digits and randomly we select a binary bit and flip it. We also have

the capability of injecting a binary bit randomly. Using the bit-flip script we are able to

generate as many test cases as needed. A mutation based python script was used mainly

in protocol fuzzing due to the relatively small size of the packets.

Test cases used by the application layer were generated using a generation-based

33

Python fuzzing script. However, these test cases used a Python Fuzzing framework

known as the Sulley Fuzzing Framework [28]. The Sulley Fuzzing Framework is used to

map out the various payload blocks of the NDEF specification. With Sulley, one is able

to do what is known as smart-fuzzing which allows one to create combinations of test

cases within the parameters they provide.

Figure 5: Smart Poster Fuzzing Example using Sulley Fuzzing Framework

34

Figure 5 above is an example of a Smart Poster fuzzing script written using the

Sulley Fuzzing Framework. This framework relies on block-based fuzzing in which you

define a protocol you wish to fuzz in blocks. Sulley is able to generate data based on the

configurations, number of mutations, and settings the user provides. This script generates

the test cases for an NDEF Smart Poster message. One can see the various NDEF

message components defined inside the Python code.

When generating test cases, we implemented the on-the-fly generation with the

bit-flipped, mutation-based NFC test cases. This feature is implemented into our libnfc

and nfcpy python fuzzing scripts. This way, the fuzzing test cases do not have to be pre-

generated, but can be generated on-the-fly.

6.3 PROTOCOL LAYER FUZZING

The libnfc is an open source NFC library that communicates with USB NFC

hardware to allow the read/write/card emulation of NFC tags. We use it to do card

emulation and, being open source and c code, it allows us to fuzz the Capability

Container of the Type 4 tag and the memory sector of the Type 2 tag. To fuzz the

35

protocol layer of the NFC tags Type 2 and Type 4 we use a modified version of the open

source libnfc framework [26]. A modified version allows us to edit the communication

protocol and use our test cases into the protocol. The libnfc python script we

implemented resides inside this libnfc framework. This script automates the process of

fuzzing Android. Our python script iterates through a list of test cases previously

generated, emulates them using libnfc’s framework, then checks and saves the state of the

Android device. When fuzzing the protocol layer, the NDEF message we send to the

Android device is not important to us at this point. We are interested in the protocol

fuzzing and, in this case, the fuzzed capability container/memory sector. We are

observing whether an NFC tag with a fuzzed container is detected, accessed, and read.

We are seeing if Android detects this emulated NFC tag as a valid tag, ignores the tag,

opens an app, or force closes.

To fuzz the protocol layer of the P2P Logical Link Control Protocol (LLCP) we

used a modified version of the open source nfcpy framework [27]. A modified version of

this framework allows us to inject our test cases into the LLCP protocol packets we are

fuzzing. We are fuzzing the LLCP connect, parameter exchange, connection complete,

and receive ready packets of the LLCP protocol. We are able to use our nfcpy python

script to automate the process of fuzzing Android. Our python script iterates through a

list of test cases previously generated, calls the test case using the nfcpy framework, then

checks and saves the state of the Android device.

In Table 1 below, one can see that we were able to fuzz 6 NFC protocols running

2,000 test cases per protocol for a total of 12,000 test cases for the NFC protocol layers.

36

Next to the number of test cases is the specific amount of bytes in the packet that we are

able to fuzz. During the protocol fuzzing, the Android device will attempt to connect and

communicate with the fuzzed protocol. There were cases where Android would not

accept the LLCP connection or recognize the NFC tag presented.

Table 1: NFC Protocol Fuzzing

Type of Protocol Fuzzing Test Cases Results/Notes

Type 2 (Ultralight) 1. Capability

Container

1. 2000 (18 bytes) 1. Not all tags recognized

Type 4 (DESFire) 1. Memory

1. 2000 (15 bytes)

1. Not all tags recognized

LLCP 1. Connect 2. Parameter

Exchange 3. Connection

Complete 4. Receive Ready

1. 2000 (19 bytes) 2. 2000 (19 bytes) 3. 2000 (6 bytes) 4. 2000 (3 bytes)

Device doesn’t accept fuzzed LLCP connection

6.4 APPLICATION LAYER FUZZING

To fuzz the application layer of Android we decided to use the libnfc framework’s

card emulation mode to emulate the NFC Tag with the NDEF message we generated. Our

libnfc Python NFC Fuzzing script iterates through the list of test cases, emulating each

test case and checking the Android phone’s output via USB (state checking).

37

Table 2: NDEF Message Test Cases

Type of Test Cases Test Cases

NDEF - short text 1626

NDEF - short URI 538

NDEF - short SMS 1265

NDEF – Smart Poster Example 1189

NDEF - short SP 3675

NDEF – Bluetooth OOB Pairing 4275

NDEF - short BT 1246

NDEF - long text 2440

NDEF - long vcard 32572

We were able to run a total of 48,826 test cases against our Android device.

Figure 2 above shows both the type and number of NDEF messages we were able to

generate. We were able to expand on Miller’s research and generate similar test cases

along with adding two additional NDEF test case generation scripts. We implemented a

NDEF Smart Poster fuzzing script, shown in Figure 5, along with a NDEF Bluetooth

pairing fuzzing script shown in Figure 6 below.

38

Figure 6: A Bluetooth Fuzzing Example using Sulley Fuzzing Framework

39

7. FUZZING RESULTS

Although we tested 12,000 test cases on the protocol layer as shown in Table 1

and 48,826 test cases on the application layer of Android as shown in Table 2 the test

cases and fuzz testing research was not able to cause a denial of service, take-over, or

force close on the Android device. We found that the NFC service would crash and

restart when certain invalid NDEF tags were scanned. Since there is no visual indication

and no errors or force closes we did not find this to be noteworthy. During testing we

also found that the device, the Galaxy S3, crashed and rebooted several times. This seems

to be caused by memory deallocation and since it is not reproducible with a specific NFC

tag or test case it is not used. The memory problems seem to occur most often with Type

4 NFC Tags possibly due to the 32KB maximum size compared to the Type 2 NFC Tag’s

size of 144 Bytes.

Our research discovered that the NFC implementation on Android has changed

vastly since Android OS 4.0.4. In subsequent versions, the Google’s Tags Android

application has been removed. This application previously accepted and logged all NFC

tags when scanned. Additionally, prior research has shown that this app was prone to

force closes and errors.

We have found that beginning in Android 4.1 Google has re-done their NFC

implementation and replaced their previous Tags application and instead use an NFC

service to re-direct tags. This NFC service is referred to as the NFC tag dispatch system

40

service. This service redirects a scanned NDEF message to an appropriate Android

application. Eliminating the Tag’s application has shown to stop the force closes, is more

secure, and so far no force closes are apparent to the user when an invalid or corrupt NFC

tag or NDEF message is scanned. We were able to run numerous test cases against the

protocol and application layers. Compared to generating test cases, we found that the

actual fuzz testing portion of the research was the most tedious and took the longest to

run.

8. CONCLUSION

NFC is a new technology and as with any new technology incorporated into

mobile devices we must test both its intended and malicious use. The addition of NFC

has created not only new attack vectors on Android devices, but a shortcut to existing

attack vectors. In this paper we discussed the following areas pertaining to NFC security.

We talked about the attack vectors created by the NFC stack. Next, we went through

case-studies of real-world scenarios and then proposed mitigations to these attacks. Then

we fuzz tested the low-level NFC libraries of the newer versions of the Android OS. In

doing so, we implemented additional LLCP protocol packets to fuzz as well as developed

numerous additional test cases with the Sulley Fuzzing Framework. Lastly, taking these

attack vectors into consideration, we propose the following two solutions that, if

implemented, will protect the security and privacy of the user. The first mitigation we

41

propose concerns implementing an option on Android devices that allows NFC use only

when a user-defined button combination is held down. This mitigation will prevent social

engineering attacks that use Smart Poster tags to automatically open malicious webpages.

It also helps to prevent relay-attacks as the user-defined button combination must be held

down in order to use NFC functionality. The second mitigation, we propose is optional

until the use of the Secure Element is given to Android devices. This mitigation proposes

adding asymmetric and symmetric cryptography to P2P NFC communication so that no

eavesdropping or data insertion is possible. The implementation of these mitigations will

help protect the privacy and security of the end-user of Android devices. We also

recommend that users with Android NFC-enabled smartphones keep their devices up to

date and use at least the Android Jellybean OS version 4.1 which has updated NFC

security features.

42

APPENDIX

This page is intentionally left blank.

43

FUTURE RESEARCH

In future research, we think that continued fuzz testing of NFC tags on Android

might show more bugs and errors in the NFC and LLCP protocols. We believe more

fuzzing needs to be done and more test cases generated to ensure that NFC protocols are

firmly and officially tested. We find that, with this NFC lab hardware, more fuzzing can

be done on NFC enabled mobile devices other than Android. We also believe as the NFC

technology develops virtualization should be utilized to speed up and expand the fuzzing

process.

44

REFERENCES

[1] M. Roland, J. Langer and J. Scharinger, "Security Vulnerabilities of the NDEF

Signature Record Type," in Proceedings of the 3rd International Workshop on Near

Field Communication (NFC), 2011.

[2] E. Haselsteiner, K. Breitfuß. Security in Near Field Communication (NFC). In

Workshop on RFID Security, 2006.

[3] M. Saeed and C. Walter, "A Record Composition/Decomposition attack on the NDEF

Signature Record Type Definition," in Proceedings of the International Conference on

Internet Technology and Secured Transactions (ICITST), 2011.

[4] S. Burkard, "Near Field Communication in Smartphones".

[5] L. Francis, G. Hancke, K. Mayes and K. Markantonakis, "Potential misuse of NFC

enabled mobile phones with embedded security elements as contactless attack

platforms," in Proceedings of the International Conference on Internet Technology

and Secured Transactions, 2009.

[6] R. Verdult and F. Kooman, "Practical attacks on NFC enabled cell phones," in

Proceedings of the 3rd International Workshop on Near Field Communication (NFC),

2011.

[7] G. Van Damme, K. Wouters and B. Preneel, "Practical Experiences with NFC

Security on mobile Phones," in Proceedings of the RFIDSec’09 on RFID Security,

2009.

45

[8] A. F. de Azevedo Figueiredo Cruz, “Nfc and mobile payments today,”

http://www.di.fc.ul.pt/nuno/THESIS/AndreCruz MSIT11.pdf

[9] G. Madlmayr, J. Langer, C. Kantner, J. Scharinger. NFC Devices: Security and

Privacy. In Third International Conference on Availability, Reliability and Security,

pages 642–647, 2008.

[10] M. Lange, S. Liebergeld, A. Lackorzynski, A. Warg, and M. Peter. L4Android: A

Generic Operating System Framework for Secure Smartphones. In Proceedings of

the 1st Workshop on Security and Privacy in Smartphones and Mobile Devices,

CCS-SPSM’11, 2011.

[11] M. Roland, J. Langer and J. Scharinger, "Practical Attack Scenarios on Secure

Element-Enabled Mobile Devices," in Proceedings of the 4th International Workshop

on Near Field Communication (NFC), 2012

[12] C. Mulliner, "Vulnerability Analysis and Attacks on NFC-Enabled Mobile Phones,"

in Proceedings of the ARES '09 International Conference on Availability, Reliability

and Security, 2009.

[13] A. J. Jara, A. F. Alcolea, M. A. Zamora and A. F. G. Skarmeta, "Evaluation of the

security capabilities on NFC-powered devices," in Proceeding of the 2010

European Workshop on Smart Objects: Systems, Technologies and Applications

(RFID Sys Tech), 2010.

[14] M. Roland: Software Card Emulation in NFC-enabled Mobile Phones: Great Ad-

vantage or Security Nightmare?. In Proceedings of the 4th International Workshop

on Security and Privacy on Spontaneous Interaction and Mobile Phone Use.

46

http://www.medien.ifi.lmu.de/iwssi2012/papers/iwssi-spmu2012-roland.pdf, June

2012.

[15] M. Roland, J. Langer and J. Scharinger, "Practical Attack Scenarios on Secure

Element-Enabled Mobile Devices," in Proceedings of the 4th International Workshop

on Near Field Communication (NFC), 2012.

[16] Exploring the NFC Attack Surface http://media.blackhat.com/bh-us-

12/Briefings/C_Miller/BH_US_12_Miller_NFC_attack_surface_WP.pdf

[17] Type 1 Tag Operation Specification http://www.nfc-forum.org/specs/

[18] Type 2 Tag Operation Specification http://www.nfc-forum.org/specs/

[19] Type 3 Tag Operation Specification http://www.nfc-forum.org/specs/

[20] Type 4 Tag Operation Specification http://www.nfc-forum.org/specs/

[21] Logical Link Control Protocol NFCForum-TS-LLCP_1.1http://www.nfc-

forum.org/specs/

[22] NFC Data Exchange Format (NDEF) http://www.nfc-forum.org/specs/

[23] NFC Record Type Definition (RTD) http://www.nfc-forum.org/specs/

[24] NFC Smart Poster Record Type Definition (RTD) http://www.nfc-forum.org/specs/

[25] Text Record Type Definition http://www.nfc-forum.org/specs/

[26] libnfc libraries http://www.libnfc.org/

[27] nfcpy project https://launchpad.net/nfcpy

[28] Sulley Fuzzing Framework https://github.com/OpenRCE/sulley