m. quinlan proposal
TRANSCRIPT
NFC SECURITY ON ANDROID DEVICES
by
MATTHEW QUINLAN
Advisor
DR. ELAARAG
A senior research [proposal/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 ...................................................... 15
4.1 FUZZING/NFC STACK ERRORS ...................................................................... 15
4.2 SECURE ELEMENT............................................................................................ 17
4.3 CLONING............................................................................................................. 19
4.4 COMMUNICATION ............................................................................................ 20
5. FUZZING ANDROID’S NFC STACK................................................................ 23
5.1 NFC LAB SETUP................................................................................................. 25
5.2 Protocol Layer Fuzzing ......................................................................................... 26
5.3 Application Layer Fuzzing ................................................................................... 27
2
6. Conclusion ............................................................................................................ 28
APPENDIX ....................................................................................................................... 30
FUTURE RESEARCH ..................................................................................................... 30
REFERENCES ................................................................................................................. 32
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
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 its inner-
workings. We investigate the new attack vectors created, 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 understand the process of fuzzing the NFC
stack on Android to find various errors and bugs. These flaws in the NFC stack have
been shown to result in compromised user data or attackers gaining remote control of the
mobile device.
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
and can read 13.56 MHz RFID 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 is
already being used and by many mobile Android apps most of which can be found in
Google Play (The android app market). PayPal and Google Wallet, are two examples of
Android apps that use NFC technology. PayPal has an NFC feature in their Android app
that allows two NFC devices to transfer funds between two PayPal accounts using NFC.
Google wallet has a similar such app that instead allows you to use your credit cards, gift
cards, and other 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 on
mobile devices. We will assess the security of NFC on Android devices and discover the
6
degree of impact that this new functionality will have on the overall security of mobile
devices.
This paper investigates, specifically, the security of the Android OS version 4.0.1
ice-cream sandwich (ICS) and Android OS version 4.1 jellybean after the addition of
NFC. Similar research in this area focuses on NFC security and mobile devices but more
complete 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 various new attack vectors introduced.
Also discussed, are the steps needed to fuzz or, test a numerous variety, of NFC tags and,
in doing so, finding bugs or errors in the security of NFC on an Android device.
The rest of this paper is organized as follows. Section 2 contains 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 fuzzing the NFC stack on Android. 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. It will also assist us in understanding how the NFC stack on Android works.
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.
7
Following the conclusion in Section 6, in the appendix, we discuss the future goal and
steps-needed to implement an automated fuzzing of Android’s NFC stack in hopes of
finding more bugs, attacks, exploits, or crashes of Android 4.0.1 ICS and Android 4.1
Jellybean.
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]. We investigate the security of NFC on
Android mobile devices and in future research will provide a fuzzing framework to
sufficiently test NFC security.
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 presents an automated python fuzzing setup for the NFC stack on
mobile devices. Finally, he presents his success with the Nokia N9 NFC mobile device as
well as his success with Android and the various crashes and interesting test cases he
8
generated.
Scharinger et al. [15] provides in 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
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.
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
9
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
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 an
NFC-enabled mobile device. They present two new attack scenarios against the
smartcard in mobile devices namely the relay-attack and denial of service attack. They
also research various security frameworks like SEEK for android project that provide a
protected API access to the smartcard to prevent malicious usage.
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 bidirectionally to one another.
The two NFC devices must be able to generate their own RF field for communication to
11
occur. We will focus on the latter two methods of NFC communication and test the
security of Android Smartphone devices using the new, built-in NFC technology as an
attack vector.
3.1 NFC PROTOCOLS
Understanding the new attack vector 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 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
12
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.
Figure 1: NFC Protocol Stack
13
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
[22]. NDEF contains different identifiers and fields to describe the type of data it
contains, to also hold the data (payload), and for communication purposes. URI’s and
Smart Posters are two examples of the various NFC record types. See the NDEF
specifications for the various types supported in NDEF as well as the specifications for
each type [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.
14
Figure 2: Sample NDEF Smart Poster Tag
In Figure 2 above, the first two lines show the hexadecimal values of the Smart Poster tag
[24] and its data. Below those lines are the hexadecimal values broken down into the
NDEF format. 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 go to their corresponding field
name.
15
4. NFC SECURITY ON ANDROID DEVICES
We have found various attacks against Android NFC-enabled mobile devices as
well as weaknesses in the NFC specification. 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, present a case-
study of the attack, and propose a solution or mitigation to the attack. This is to ensure
users are aware of and can take full advantage of the security and privacy an NFC-
enabled Android device can offer.
4.1 FUZZING/NFC STACK ERRORS
Web browser and Smart Poster URI spoofing attack
Problem:
The Smart poser URI spoofing attack involves writing a Smart Poster tag’s data
and inserting multiple newline or return characters after the title in the title field so that it
16
appears to the user that they are going to the intended site in the tag title while they are
actually going to a malicious site. These smart posters and their URI links most
commonly link to malicious sites that attack the Android browser. However, there are
many listed types of URI’s available to use in the Smart Poster. This URI spoofing attack
is a type of NFC web browser attack in that the URI of the Smart Poster on NFC devices
is automatically opened typically without user interactions. The malicious intent with
these attacks is to use the web browser to perform malicious actions be it steal user data
or control the device.
Application:
NFC Smart Poster tags can be placed in signs and in public places that contain
unchangeable links to malicious sites. These tags when opened by accident or on
purpose will attempt to install malicious content or perform malicious actions.
Solution:
The 4.0.3 and 4.1.1 versions of Android tested were not found to be vulnerable to
a URI spoofing attack. They are however still vulnerable to a web browser attack because
when a Smart Poster tag is scanned the URI of that tag is automatically opened.
A mitigation to the web browser attack would be to prompt users for permission before
opening any links or files. Another solution would be an option to allow NFC use only
when a user-defined button combination is held down.
17
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.
Application:
Malformed NDEF messages could be placed in public places and if an NFC-
enabled mobile device reads such a malformed tag either on purpose or accident their
device will crash and reboot.
Solution:
The solution to this problem is to fuzz NDEF messages and provide fixes to
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
18
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
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 utilizing an exploit 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:
There are currently several different existing APIs and projects that provide
19
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.
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
20
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,
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.
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. The Android OS, once
NFC access control permissions have been given to an app, that app has access to the
secure element of the phone. 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
21
device. The secure element on the victim’s Android device is accessed and the app
relay’s the victim device’s (APDUs). Through this relay-attack one is able to access the
secure element of a device without physical access to the device. Having read access to
the secure element puts the victim’s privacy at risk as the malicious user now has access
to and can read secure element data.
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 checkouts 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. The victim’s device is accessible due to the malicious app installed.
This app is able to communicate and send data to the secure element which Google
Wallet is emulating. The victim user may have to enter a pin or it may be brute forced.
The secure element will then respond to the attacker’s device with the correct 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
22
Virtual Google Wallet credit cards that have been linked to that user’s real credit cards.
Solution:
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 NFC
only when a certain 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
23
asymmetric and symmetric encryption on all NFC communication. That way, any private
RF data retrieved will be encrypted.
5. FUZZING ANDROID’S NFC STACK
The term fuzzing is used to refer to testing and scanning numerous different NFC
tags and observing the output on the Android device. The first place to fuzz the NFC
stack on Android is the protocol layer where data is 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 it receives it from the protocol layer. 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 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].
24
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 data and creating the
NDEF payload is located in a special “NFC Service” (com.android.nfc). Finally, the
application layer of the NFC stack is triggered and the appropriate action is taken by
opening Android Tags or Android Beam or even Android browser application depending
on the NDEF payload processed.
In Android 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 an Android
smartphone. Although Android apps are java based and memory corruption may not be a
possibility, there will be native code involved at the lowest levels (eg. a library or driver).
There are different approaches to find NFC vulnerabilities and bugs in the Android
25
smartphone devices, but the best way is to start at a low level and work your way up. In
our case, the most appropriate low level is the protocol layer of the NFC stack and we
work our way up to the application layer. In future research we will fuzz the NFC stack
starting with the protocol layer and then working our way up to the application layer with
the fuzzing of NDEF messages.
5.1 NFC LAB SETUP
For our purposes in this research we need to emulate various NFC tags. To do this
you need to be able to do card emulation. This 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 card emulation of various tags. The ACS ACR122U and
the SCL 3711 were used with our Android Galaxy S3 device as an NFC tag
reader/writer/emulator. With tweaking, these two readers support card emulation of most
NFC tags. The hardware relies heavily on the NFC libraries provided by libnfc [26]. In
addition, the SCL 3711 NFC device can support LLCP communication using the nfcpy
project [27].
26
Figure 4: (left to right) Galaxy S 3 NFC Android Device
ACR-122U and SCL-3711 card reader/writer/emulator
5.2 Protocol Layer Fuzzing
On the protocol level of the NFC stack, the goal is to emulate as many different
types of tags and fields as possible. When Android reads or parses these tags they are
going up the protocol stack and will eventually be converted into NDEF messages. We
are looking for errors, bugs, and crashes in the parsing or converting of these tags into
NDEF messages. Future fuzzing research needs to be continued with a goal of generating
test cases and observing the output.
27
5.3 Application Layer Fuzzing
Application layer fuzzing involves fuzzing NDEF messages and scanning them to
observe the action taken by, in our case, the Galaxy S3 Android device. Every NFC tag
scanned by a device is converted to an NDEF message. Knowing this, we fuzz by
creating as many NDEF messages as possible with as many different values in the
various fields as possible. The goal here is to \ create a malformed or invalid NDEF
message that causes the Android NFC stack parser to execute the code we want, show an
error, or crash. Application layer fuzzing needs to be further explored in later research.
28
6. Conclusion
NFC is a new technology and as with any new technology incorporated into
mobile devices we must test both its use and malicious use. The addition of NFC has
created new attack vectors on Android devices. In this paper we reviewed these attack
vectors, the case-studies of a real-world scenario, and the proposed mitigation. 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
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.
This mitigation also helps to prevent relay-attacks as the user-defined button combination
must be held down in order to use the NFC functionality. The second mitigation we
proposed concerns adding asymmetric and symmetric cryptography to 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 do also recommend that NFC-Android users use the more
secure version of Android, Android Jellybean. In addition, users must be aware of these
attack vectors and social engineering attacks so that they are aware of situations and
29
malicious activity where their phone is automatically opening webpages or their phone is
being used in a relay-attack.
30
APPENDIX
FUTURE RESEARCH
31
In future research, we will utilize our NFC lab to create a fuzzing framework that
automates the scanning of NFC tags, fuzzing, and software card emulation. We will
explore generating test-cases and utilize our NFC hardware to automatically fuzz
Android’s NFC stack. We will focus on fuzzing NDEF messages on the application layer.
Current Android devices current research shows, without user interaction, automatically
open NDEF messages that contain images, videos, or URLS for viewing. Research has
shown that these various applications that handle the NFC stack may be prone to attacks,
exploits, or bugs that give remote control of the device or access to private user data. For
this reason, our research delves into protecting Android mobile devices against possible
NFC attacks by finding, reporting, and proposing mitigations to these various attacks.
32
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.
[8] A. F. de Azevedo Figueiredo Cruz, “Nfc and mobile payments today,”
33
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.
http://www.medien.ifi.lmu.de/iwssi2012/papers/iwssi-spmu2012-roland.pdf, June 2012.
34
[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