NFC on Smartphones. Final Report. Version 2.0. Semester Project Fall EIA-FR Telecommunications Department

Transcription

1 NFC on Smartphones Final Report Version 2.0 Semester Project Fall 2011 EIA-FR Telecommunications Department Students: Thomas Gerber and Yannick Gugler Professors: Jacques Bapst and Nicolas Schroeter January 25, 2012

2

3 What are the possibilities of the NFC implementation on smartphones? What functionalities are supported and are there security issues to consider? NFC is analyzed first on a theoretical level before showing the prospects of the Android platform dealing with NFC. For this purpose, the development basics for the Android platform are being described with simple examples. Those are the main topics of this report, described in different stages and under different circumstances. 3

4 4

5 Contents 1 Glossary 9 2 Introduction 11 3 Theoretical Part Base Technologies RFID Energy transmission Data transmission Uplink Downlink Multiple Access Smartcards Memory cards Processor cards Contact interfaces Contactless interfaces Security of smartcard chips NFC Engineer standards and protocols NFC Forum Combination of NFC standards and protocols Peer-to-Peer mode Passive communication mode Active communication mode Reader/Writer mode Card-Emulation mode Mode of operation and mode switching Security Attack possibilities NFCIP-1 Security Services and Protocol (NFC-SEC) NFC Data Formats NFC-Forum-Tags Type Type Type Type NFC Data Exchange Format (NDEF) NDEF Record NDEF Message MIME Media Types NFC Record Type Definition (RTD) NFC Forum Well-known Types NFC Forum External Types Text Record Type URI Record Type

6 Contents Smart Poster Record Type URI Record Title Record Icon Record Recommended Action Record Size Record Type Record Application Cases Generic Control Record Type Target Record Action Record Data Record Signature Record Type Connection Handover Negotiated Handover Static Handover Handover Request Record Handover Select Record Alternative Carrier Record Development Basics Android Application components User Interface HelloAndroid HelloNFC Smartcard Access Memory organisation Manufacturer block Data blocks Sector trailer Memory access NDEF Data management on Smartcards MAD Sector Access NFC Sector Access NDEF Managment Sniffer Scan content of a ski pass Password sniffing Practical Part Scenario Architecture & Design nwriter ntourist Implementation Android libraries Package android.nfc Class NfcAdapter Class NdefMessage Class NdefRecord Class Tag Interface NfcAdapter.CreateNdefMessageCallback

7 Contents Interface NfcAdapter.OnNdefPushCompleteCallback Package android.nfc.tech NDEF message structure NDEF TNF_WELL_KNOWN record types NDEF MIME_MEDIA record types File storage structure nwriter App Class Startscreen Class TagWriter Class NfcSpot ntourist App Class Startscreen Class SiteList Class SiteView Class GetMifare Class GetNfcSpot Class ShareSite Enumeration NFCType Tests Functional Tests nwriter Reader / writer mode Peer-to-peer mode ntourist Reading a passive tag Reading an active tag Sharing a site File handling Specification Tests Conclusion 103 List of Figures 105 Version Date Comment Author Gerber / Gugler Revisions according to discussion Gerber / Gugler Theoretical Part Final Version Gerber / Gugler Final Version Gerber / Gugler 7

8 Contents 8

9 1 Glossary AID application identifier API Application Programming Interface ASK Amplitude-Shift Keying CPU Central Processing Unit DoS Denial of Service ECMA European Computer Manufacturers Association EEPROM Electrically Erasable Programmable Read-Only Memory EPC Electronic Product Code FDMA Frequency Division Multiple Access FSK Frequency-Shift Keying GPB General Purpose Byte IANA Internet Assigned Numbers Authority IEC International Engineering Consortium I/O Input - Output ISM Industrial-Scientific-Medical ISO International Organization for Standardization JIS Japan Industrial Standard JNI Java Native Interface LLCP Logical Link Control Layer NDEF NFC Data Exchange Format NFC Near Field Communication NFCIP Near Field Communication Interface and Protocol NFC SEC Near Field Communication Security Service NRZ Non-Return-to-Zero MAC Media Access Control Layer MAD Mifare application directory structure MIME Multipurpose Internet Mail Extension MMU Memory Management Unit PIN Personal Identification Number 9

10 1 Glossary PCD Proximity Coupling Device PICC Proximity Integrated Circuit Card POR Power on Reset PSK Phase-Shift Keying OSI Open System Interconnection OOK On Off Keying RAM Random-Access Memory RFID Radio Frequency Identification ROM Read-Only Memory RTD Record Type Definition RZ Return-to-Zero SCH Secure Channel SDK Software Development Kit SDMA Space Division Multiple Access SIM Subscriber Identity Module SMS Short Message Service SSE Shared Secret Service TDMA Time Division Multiple Access TLV Type Length Value block TNF Type Name Format UHF Ultra High Frequency UTF-8 8-bit UCS Transformation Format UI User Interface URL Uniform Resource Locator URI Uniform Resource Identifier VCD Vicinity Coupling Device VICC Vicinity Integrated Circuit Card WLan Wireless Local Area Network 10

11 2 Introduction In a world that is getting faster and faster and where people have a growing emotional independence, technologies have to adapt. Applications in communication and transportation are getting more individual and therefore we need other simple-to-use and independent technologies. They have to support the needs of each of us without being complicated or taking to much time to handle. In this area we see a large possibility for contactless operations. Near Field Communication (NFC) gives us the opportunity to perform several operations with one and the same device. Simple applications like cash- and contactless paying or ticketing are just the beginning and many other application areas will be following (Fig. 2.1). Figure 2.1: Daily life applications [2] The goal of NFC is to establish an open standard for data transmission within shortest distances. A connection can either be performed between active devices or between active and passive devices. This means that simple identification applications as well as transmission of data are possible. The technology is simple-to-use and transaction-times are short. The connection does not have to be configured by the user, he just holds an active or passive device into the operation area of another device. The rest is performed by the standard. Therefore the user accepts a connection by holding the device to a specific spot. This is similar to a cash paying process where the customer gives the money to no one other than the cashier. In order to achieve those requirements, the engineers came back to the existing and proven technologies Radio Frequency Identification (RFID) and contactless smartcards. Specific parts of those standards are employed and proprietary features are cut off to allow interoperability between different manufacturers. The standards are defined in ISO/IEC

12 2 Introduction for communications between transponder and reader respectively in ISO/IEC and ECMA-340 for communication between NFC devices as illustrated on the following figure. Figure 2.2: Components of the technical architecture of NFC [2] The RFID technology was first introduced during second world war where it was used as friend or foe identification for airplanes. The technology made its breakthrough in the 70s with merchandise security systems. More applications like animal detection, immobilizer, ticketing, building access control, time recording and toll systems followed in the 80s and 90s. Smartcards origin in cashless payment systems. Diners Club and later Visa and Mastercard were the big companies behind the technology. The first cards just had a serial number and the signature of the cardholder as identification. Later magnetic stripes and chips were built into the cards to increase the security level. A Personal Identification Number (PIN) was introduced as an additional identification. Today microprocessor with crypto coprocessors are state of the art. The NFC technology was presented back in 2002 by NXP Semiconductors and Sony. Both companies are leading smartcard manufacturers. While NXP sells their MIFARE products mainly in Europe and America, the FeliCa line from Sony dominates the market in Japan. Though NFC integrates both systems they do not include proprietary encrypting algorithms. The smartcard industry considers them as unsafe why they use more and more open standards like 3DES. First field tests in France, Austria and Germany with contactless paying systems showed the potential of NFC. The users sensed it as a modern and simple-to-use technology. In 2007 the first big roll-out took place in Austria. In cooperation with the NFC Research Lab (University of Applied Sciences in Hagenberg) the Mobilkom Austria and the Austrian Railways introduced a contactless pay service for public transport. In 2011 Google launched its new service wallet. In cooperation with Mastercard and Citi they offer a service where the credit card is part of the smartphone. The service works with special payment terminals and the Nexus S smartphone which both support NFC. The following illustration shows the operation area of NFC compared to other wireless technologies. Figure 2.3: Working area of NFC [2] 12

13 Nowadays the technology is powered by the NFC Forum and its members. The forum was founded to develop standards, ensuring interoperability amongst devices and services, and educating the market about NFC technology. Manufacturers, application developers, financial service institutions build an ecosystem (Fig. 2.4) to promote the use of NFC technology in consumer electronics, mobile devices, and PCs. The goals of the NFC Forum are to [3]: Develop standard-based Near Field Communication specifications that define a modular architecture and interoperability parameters for NFC devices and protocols. Encourage the development of products using NFC Forum specifications. Work to ensure that products claiming NFC capabilities comply with NFC Forum specifications. Educate consumers and enterprises globally about NFC. Figure 2.4: The NFC Ecosystem [2] In order to get in touch with this interesting technology the theoretical part of the project explains the base technologies, the NFC technology including the security level and the basics of software development for the Android platform and the NFC Software Development Kit (SDK) we use. The different applications and ideas are discussed before we start the practical implementation and are described in the practical part of the report. 13

14 2 Introduction References [1] Josef Langer & Michael Roland, Anwendungen und Technik von Near Field Communication (NFC), Springer Berlin, 2010, p [2] NFC Forum - About NFC, October 2011 [3] NFC Forum - About Us, October 2011 [4] Goolge Wallet, October

15 3 Theoretical Part 3.1 Base Technologies In order to have a full overview of the NFC technology, it is necessary to understand the basics of the used technologies RFID and smartcard. This chapter explains the different RFID systems and the concepts of the energy and data transmission. You will not find detailed information about electrotechnical laws utilized with coupling methods, because this is not of interest for our project. The explanations concerning smartcards contain an overview of the different types, their concept and functionality but not detailed information about the individual transmission protocols RFID Basically NFC employs active and passive RFID chips which makes the technology backward compatible to existing RFID systems. This is especially important if we consider all the working ticketing systems around the world. NFC is capable of interacting with those systems. A RFID transponder consists of a microchip and a data storage module where the EPC (Electronic Product Code) of the device is stored. With a reader device the RFID tag can be read out of the memory. For that purpose neither visual nor physical connection is required. This fact allows use in harsh environments like heat or dust which results in a larger and more flexible application range compared for example to barcode systems. Figure 3.1: Active 1 and passive (smartlabel) 2 RFID transponders. RFID reader 3 RFID works on the free to use ISM (Industrial-Scientific-Medical) frequency bands where the used band pends on the system. There are three different coupling methods: Capacity coupled systems (high frequency electric field) Inductively coupled systems (high frequency magnetic field) UHF backscatter systems (Reflexion of electromagnetic waves - similar to radar) 1 cf. 2 cf. 3 cf. 15

16 3 Theoretical Part NFC implements the inductive coupling and works on a carrier frequency of MHz. This method takes advantage of the fact that current carrying conductors are surrounded by a magnetic field. This filed is used to transmit energy as well as data Energy transmission As mentioned before NFC devices are inductively coupled for communication. The coupling is realized with inductors like in transformers (Fig. 3.2). A current change in one inductor causes a fluency change that results in an induction of tension in the second inductor. This is how energy is transferred from the reader to the transponder. Figure 3.2: Diagram of inductively coupled RFID systems To ensure that enough energy is available to power the microprocessor, an oscillator circuit is utilized on the transponder. The better the oscillator frequency matches the carrier frequency, the higher the amplification of the signal. This means that the system is in resonance. The gain of energy produced by the oscillator circuit is measured with the factor of quality Q. A high factor Q means an efficient energy transmission (Fig. 3.3). Figure 3.3: Gain of induced energy with oscillator circuit [1] RFID systems can be divided in three modes of operation: Passive Semi-passive Active 16

17 3.1 Base Technologies While passive transponders uses the magnetic field emitted by the reader device to power the processor and to send data, active systems have their own power supply to create a high frequency signal. Semi-passive systems typically employe a battery to power the processor but they utilise the emitted field to transmit their data. Nowadays passive transponders cost about 10 to 40 cents while active transponders are in a cost range between 10 and 40 Dollars Data transmission In order to the three modes of operation there are also different ways of data transmission. Considering the fact that passive and semi-passive systems use the emitted field to transmit data, there are two communication channels - an uplink and a downlink. Active systems on the other hand utilise one and the same channel as uplink respectively as downlink. The sending device takes the role as reader and writer device. The main problem comes along with an efficient energy transmission. Systems in resonance have a long reaction time to signal changes on the input because they have a long reverberation time. This affects also the bandwidth of the system which is getting smaller with a higher resonance. A compromise between the energy and data transmission has to be found depending on the purpose Uplink The uplink describes the communication direction from the reader to the transponder. As mentioned before, for active systems this is the only way of communication (Fig. 3.4). Figure 3.4: RFID uplink The data signal is therefore modulated onto the carrier signal. For inductive RFID systems mostly an ASK (Amplitude-shift keying) process comes into action. For other systems there are alternatively PSK (Phase-shift keying) and FSK (Frequency-shift keying) processes available. The ASK (Fig. 3.5) process works with two states, one for 0 and one for 1. The modulation index is either 10 or 100%. A modulation index of 10% provides the power supply for passive systems even if a 0 is transmitted. Figure 3.5: 2-ASK with modulation indexes of 100 and 10 % [1] 17

18 3 Theoretical Part To adapt the signal to the transmission channel and the modulation process, several coding processes (Fig. 3.6), like NRZ (Non-return-to-zero), RZ (Return-to-zero), Manchester and Miller, are available. Figure 3.6: RFID coding processes [1] Downlink The downlink is only used for passive and semi-passive systems and describes the data communication from the transponder to the reader device (Fig. 3.7). Figure 3.7: RFID downlink This process is a bit more complicated than the uplink because data has to be modulated on the existing magnetic field emitted by the reader device. The coupling between reader and transmitter does not just have an impact in direction from the reader to the transponder but also vice versa. The impact depends on the impedance of the transponder circuit. A change of impedance causes either an amplitude change or an amplitude and a phase change on the carrier signal which is detected by the reader device. This kind of operation is called load modulation. For this purpose data is digitally coded and then sent over a resistance (OOK - On Off Keying) or a capacitor to change the transponder s impedance. The resistance causes an amplitude change on the carrier signal and the capacitor an amplitude and a phase change. 18

19 3.1 Base Technologies Multiple Access A RFID system mostly consists of one reader device and several transponders. For NFC systems a border between transponders and readers cannot be drawn. So for both systems one transmission channel has to be shared for multiple devices. This circumstance requires multiple access. Therefore TDMA (Time Division Multiple Access) is generally employed for the reason of simplicity and cost efficiency. TDMA provides a time slot for each transponder, where it can communicate with the reader. In a few situations FDMA (Frequency Division Multiple Access) can be reasonable. FDMA works with two frequency bands for the up- and downlink. Often also SDMA (Space Division Multiple Access) is being applied. The reader antennas are placed so that their emitted field does not affect other antenna fields. Thanks to the small operation distance this can be realized rather easily. The technical implementation of multiple access is also known as anti collision. Anti collision processes are divided in two categories: Deterministic operation Probabilistic operaton Deterministic methods work with the Adaptive-Binary-Tree algorithm. A given interval of transponders are asked to send their serial number. If more than one device answers (collision) the interval is divided by two until only one device answers which represents a leaf of the tree. The process is repeated for all the intervals. For communication each leaf is activated at a given moment. Probabilistic methods use a slotted ALOHA algorithm. The reader device provides time slots to communicate where the transponders answer at a random moment. In the process transponders have no chance to detect a collision because they cannot detect other sending transponders. To minimize collisions the reader can switch off transponders for a following query round. 19

20 3 Theoretical Part Smartcards In addition to RFID, smartcards represent a core element of NFC. Early models just had a serial number as identification element, but nowadays smartcards are equipped with microprocessors that provide a high level of security but also a wide range of utilization. They are made of plastic. The chip contains data for identification as well as cryptographic functions which allow applications like access control, mobile telephony (SIM card), cashless paying and identity cards. Figure 3.8: Smartcard 4 Those different application areas require also different types of smartcards. They can either be grouped according to their functionalities (Fig. 3.9) or their interfaces (Fig. 3.10). Figure 3.9: Classification of smartcard functionalities Figure 3.10: Classification of smartcard interfaces Physical requirements for identification cards are defined in the ISO/IEC 7810 norm. It regulates the needs for flexibility, flammability, resistance against environmental stress and durability. There are four different types [5]: ID-1 ID-2: ID-3 ID cf. 20

21 3.1 Base Technologies For smartcards the standards ID-1 and ID-000 are used. While the ID-1 format (85, 60mm 53, 98mm) is employed for cash cards or driving licenses, it is the ID-000 format (25mm 15mm) for SIM cards (Subscriber Identity Module) in mobile phones Memory cards Basically memory cards are available with and without safety logic. The safety logic provides functions to protect access to the memory, reading and writing cycles. The safety is either granted by a simple PIN or by other more sophisticated identification or cryptographic processes. Memory cards without protection are utilized for simple storage applications where data is not critical or worthy of protection. There is a simple EEPROM (Electrically Erasable Programmable Read-Only Memory) module which can be read, written and deleted as many times as desired. The access to the storage is realized with simple direct wire connections or more complicated state machines. Additionally there are write-once-read-multiple and one-way-counter cards which are a mixed form of the before mentioned memory cards. Write-once-read-multiple cards are used for identification purposes and one-way-counter cards for phone cards. Phone cards have an initial counter value which can only be decremented in one direction by the telephone. Below is a diagram of the architecture of a memory card (Fig. 3.11). The I/O module is the interface to the reader device which can either be contact or contactless. The logic part provides access to the memory and is the essential piece of the mentioned card layouts. This is a straight access for cards without safety logic or a secured access for cards with safety logic. The EEPROM contains all the application data while the ROM (Read-Only Memory) contains identification data. The ROM module is written once during production. Afterwards it can only be read. Figure 3.11: Memory card architecture [4] Processor cards The microprocessor in the processor card permits a much bigger and more sophisticated application range compared to memory cards and has a higher level of security. Processor cards are distinguished over operation systems, available hardware and whether application software can be replaced or changed. The operating system serves as interface between hardware and software. In order to ensure a safe and accurate operation, operating systems are developed strictly modular. Every functional block has its own library. This method increases the level of security because access between different blocks can be cut or controlled easier. If there are several applications installed, which is possible with the processor card, the MMU (Memory Management Unit) provides separated memory areas for each application. Hence a program cannot access to the memory of another application. Application software is either installed fix in the ROM, changeable or installed after production in a EEPROM module or it is even adaptable during operation. The I/O module on the following architecture diagram (Fig. 3.12) has the same function as for memory cards. The RAM (Random-Access Memory) contains data which is only used and buffered 21

22 3 Theoretical Part during run time and deleted afterwards. The EEPROM and ROM store the operating system and the application software depending on the before mentioned modes. The CPU (Central Processing Unit) is the heart of the card. It handles multiple functions like calculations, memory access and cryptographic functions. For this purpose there can be several specialized coprocessors to support the CPU. For example a crypto-coprocessor and a random number generator to allow symmetrical as well as asymmetrical encryption functions. Figure 3.12: Processor card architecture [4] Contact interfaces The basic conditions and transmission protocols for contact smartcards are defined in the ISO/IEC 7816 norm based on the norm ISO/IEC The size of the microchip is restricted to 25mm 2, the thickness of the card to 0.76mm. The position and pins of the chip are strictly defined in order to assure the interoperability between the different manufacturers. For contact smartcards (Fig. 3.13) both ID-1 and ID-000 are utilized. Figure 3.13: ID-1 and ID-000 smartcards [1] For memory cards the following synchronous transmission protocols are available [1]: S=8 (Serial Data Access Protocol) S=9 (3-Wire Bus Protocol) S=10 (2-Wire Bus Protocol) SLE 4403 compatible Those protocols answer with a reset-signal containing data about the identification and the protocol type. 22

23 3.1 Base Technologies For processor cards the following synchronous transmission protocols are available [1]: T=0 (byte-oriented, asynchronous protocol) T=1 (block-oriented, asynchronous protocol) T=14 (national standards) USB (Universal Serial Bus) SWP (Single Wire Protocol) T=0 and T=1 are the most employed protocols and are part of every reader device. While USB smartcards emulate a reader device with USB interface, SWP was developed especially for NFC. The protocol ensures direct communication between the SIM card and the NFC chip of a mobile phone. The mentioned protocols use the following protocol stack (Fig. 3.14) based on the OSI (Open System Interconnection) model. The application data units are therefore packed in transport data units and sent over the physical layer. Figure 3.14: Protocol stack Contactless interfaces For contactless smartcards the physical characteristics are not as important as for contact smartcards. For communication a contact is not necessary so the card just has to be within the range of the reader antenna. This is the reason for the various designs of contactless smartcards. Nevertheless the ID-1 dimension is often used. On one hand the dual interface cards (contact and contactless interface) have to respect the ID-1 dimension and on the other hand the ID-1 is omnipresent so it fits perfectly into the wallet. For contactless interfaces the following transmission protocols are available [1]: Close coupling Proximity coupling FeliCa Vicinity coupling EPCglobal UHF Class 1 Generation 2 23

24 3 Theoretical Part While Close coupling was employed in early years of this technology, Proximity, FeliCa and Vicinity coupling are the base of NFC. They use inductive coupling and function on a frequency of MHz. Both FeliCa and Proximity work within a distance of 10cm. While FeliCa (212kbits) is a proprietary standard developed by Sony, Proximity (848kbit/s) is defined in the ISO/IEC norm. Vicinity-systems work within a distance of 1m which reduces the transfer rate to only 26kbit/s. EPCglobal UHF Class 1 Generation 2 is a new standard and works with electro-magnetic wave propagation on 900 MHz (UHF). Table 3.1: Overview of contactless transmission protocols System Reader Smartcard SC Reader Multi Access Standard Prox. Typ A 2-ASK (100%), mod. Miller OOK, Manchester Binary-Tree ISO/IEC PSK, NRZ-L Prox. Typ B 2-ASK (10%), NRZ-L PSK, NRZ-L Aloha FeliCa 2-ASK (10%), Manchester OOK, Manchester Aloha JIS X 6319 Vicinity 2-ASK (10 or 100%), Pulse OOK Manchester - ISO/IEC FSK, Manchester Security of smartcard chips In most application areas smartcards contain security-relevant information. Especially the security of information related to credit or SIM cards has to be prevent against different attacks. Already in the developing process of microchips, security is at top priority. The developing is divided into different modules. Nobody is involved in the process of all modules and no one has therefore detailed information about the entire chip. Furthermore every single module is documented down to the detail. Small auxiliary modules are often forgotten and could be used for attacks. In order to protect the microchip against manipulation, it is coated by a passivation-layer. Sensors would note their absence and turn off the chip. To avoid attacks on reading information directly through the hardware, the different modules are arranged randomly on the chip. Also the location from memory parts is not in order to their addresses. Another possibility to attack the chip is by using electric signals out of the norm. By feeding the chip with other clock speeds or operating voltage, a proper function could be affected. Senors measure those values and turn off the chip if they are not correct. Power-analyses are the latest trend. According to the power consumption of the microchip, conclusions to used algorithms or treated information can be drawn. Circuits which create a constant consumption help to reduce the possibility of those attacks. 24

25 3.1 Base Technologies References [1] Josef Langer & Michael Roland, Anwendungen und Technik von Near Field Communication (NFC), Springer Berlin, 2010, p [2] Matthias Lampe & Christian Flörkemeier & Stephan Haller, Einführung in die RFID- Technologie, October 2010 [3] Gregor Höfert, RFID und NFC - Technologien, Vergleich und Anwendung, Cours support, TU Munich, [4] Wikipedia - Chipkarte, October 2010 [5] ISO/IEC 7810, Identification cards - Physical characteristics, wiki/iso_7810, October 2010 [6] ISO/IEC 7816, Identification cards - Integrated circuit cards, wiki/iso_7816, October 2010 [7] ISO/IEC 14443, Identification cards - Contactless integrated circuit cards - Proximity cards, October

26 3 Theoretical Part 3.2 NFC This chapter specifies the NFC technology that we use for our project. It provides an introduction to engineering standards and protocols, thereafter an explication about the different types of communication and in the end an entering in security issues of NFC Engineer standards and protocols NFC is a combination of both independent RFID systems MIFARE (ISO/IEC typ A) and FeliCa. It contains two central standards, NFCIP-1 (ISO/IEC 18092) and NFCIP (ISO/IEC21481), that are normed by Ecma international. The abbreviation NFCIP stands for "Near Field Communication Interface and Protocol". Besides these two main standards, there are other small norms. The following table gives a brief overview of all NFC standards: Standard ECMA-340 ECMA-352 ECMA-356 ECMA-362 ECMA-373 ECMA-385 ECMA-386 Description NFCIP-1 NFCIP-2 NFCIP-1 RF Interface Test methods NFCIP-1 Protocol Tests methods NFC Wired Interface (NFC-WI) NFC-SEC: NFCIP-1 Security Services and Protocol NFC-SEC-01: NFC-SEC Cryptography Standard using ECDH and AES NFC Forum The NFC Forum is an association of manufacturers, developers, financial institutions and other companies and organisations. This forum has four main tasks: to merge several NFC specifications. to check if new products are developed on NFC Forum specifications. to control if NFC products comply with all standards. to inform consumers about NFC, its applications and advantages Combination of NFC standards and protocols As already mentioned NFC is a further development of RFID. NFCIP-1 combines the transfer protocols of MIFARE and FeliCA and extends it with other communication options. In NFCIP-1 three transfer speeds are available: 106kbit/s (MIFARE), 212kbit/s and 424kbit/s (FeliCa). NFCIP-2 combines NFC with proximity- (ISO/IEC typ A and B) and vicinity-reading devices (ISO/IEC 15693). Classic RFID systems always contain one active and one or more passive components. The active component is the reading device which allocates the magnetic field for the energy supply of passive components. At proximity systems, (systems with a coverage range less or equal than 10cm) active components are called Proximity Coupling Device (PCD) and passive transponders Proximity Integrated Circuit Card (PICC). For vicinity systems, (systems with a coverage range less or equal than 1m) active components are called Vicinity Coupling Device (VCD) and passive transponders Vicinity Integrated Circuit Card (VICC). NFC abolish this strict separation. A NFC device can be the controlling (initiator) or the controlled component (target). 26

27 3.2 NFC Figure 3.15: Classing of RFID and other standards into NFC standards Based on these basic standards the NFC forum expands an entire NFC architecture (NFC Forum Architecture). The architecture is divided into three different operating modes: Peer-to-Peer mode Reader/Writer mode Card-Emulation mode The following illustration gives an overview of the NFC forum architecture. Figure 3.16: Overview of the NFC forum architecture The peer-to-peer mode permits the data transfer between two NFC devices. The basics for this mode are normed in NFCIP-1. A NFC device can communicate with passive transponders (NFC forum tags) if it works in the Reader/Writer mode. The optional card emulation mode permits a NFC device to communicate with a RFID reading device. The fundamentals of these three operation modes are the physical layers (ISO/IEC 18092, ISO/IEC and JIS X from FeliCA. This process is also called transfer technology. Each communication mode works with one of this transfer communication modes and represents a different transmission speed. 27

28 3 Theoretical Part Peer-to-Peer mode This mode permits the data transfer between two NFC devices. protocol stack of this mode: The following figure shows the Figure 3.17: Protocol stack for data transmission The lowest layer is the physical layer of NFCIP-1. There exists an active and passive communication mode wherein the initiator determines which mode is used. The data link layer is divided in a Media-Access-Control-Layer (MAC) and a Logical-Link-Control-Layer. The MAC layer is responsible for establishing the connection and initialization of the data exchange protocol. The Logical-Link- Control-Protocol allows the exchange of data between two NFC devices. 28

29 3.2 NFC Passive communication mode The initiator generates the high-frequency carrier signal during the entire communication. It modulates the carrier signal with Amplitude Shift Keying (ASK) for the data transmission from the initiator to the target. The target uses a load modulation process to transfer the answers. Figure 3.18: Data transmission passive mode Active communication mode The initiator and the target produce their own high frequency transmission signal in this mode. The same modulation (ASK) methods are used for both communication directions: Figure 3.19: Data transmission active mode 29

30 3 Theoretical Part Reader/Writer mode The Reader/Writer mode enables communication with passive RFID transponders. Each device which implements the NFC forum architecture must be able, in addition to the data exchange into the peer-to-peer mode, to communicate with different NFC forum tags. NFC Forum tags are passive RFID transponder memories. These are explained in the following chapter "Data Formats". The passive communication partner indicates if it supports the peer-to-peer mode (NFC Data Exchange Protocol), or specifies if the RFID protocol (Reader/Writer mode) should be used during the connection. Figure 3.20: Communication Reader/Writer mode Card-Emulation mode The third mode is the card emulation mode. This optional mode enables to communicate with the RFID reader devices. In this mode, a NFC device behaves itself like a passive, contact-less smartcard. For this reason it is compatible with other existing smart card infrastructures. A NFC device which supports the optional card-emulation mode can take over the same responsibilities in a smart card system as a contact-less smartcard. Figure 3.21: Communication card-emulation mode The card emulation moden in combination with the Reader/Writer mode, gives an alternative option to the peer-to-peer mode. The peer-to-peer mode needs a multi protocol stack and additional software on the NFC device. As opposed to the peer-to-peer mode, in the card emulation mode the operation is directly controlled by the chipset. This makes it even possible to operate with a switched off NFC device. That means that informations (such as tickets, credit cards) stored on the emulated smartcard of a mobile phone can be read out even when the device is switched off or out of battery. 30

31 3.2 NFC Mode of operation and mode switching A NFC device can only use one mode of communication at a time. Before a device can begin with the data transfer it has first to select the right communication mode. As seen in the previous sections the NFC standard involves three operating modes with three different transmission technologies each. The selection of a suitable operating mode and the introduction of communication is called modeswitching. The mode switching procedure is responsible for various tasks: Detection of other devices (Initiator) Advertising of own presence (Target) Device deactivation The mode-switching is composed of a passive (listening) and active part. If a NFC device detects an external high frequency field its waits for start-commands with the corresponding mode from the other device (passive part). If no external field is detected the active part begins. The NFC device generates its own field and transmits cyclically a polling request for each mode. Once a passive device responds, the communication begins with the corresponding technology. This process is called Polling Loop Security The described NFC protocol layers do not include protection measures against difference attacks. The NFC interface can relatively easy be influenced and intercepted Attack possibilities Because there are no security protocols provided, the contact-less data transmission between two NFC devices has different vulnerabilities: The communication is easy to intercept, even between long distances to intercept. Relay attacks are easily possible. With an interfering transmitter a DoS (Denial of Service) attack can be provoked. Attack by Man-in-the-middle. Delivery of false information by changing one communication participant Many of those attacks can be prevented by cryptographic methods. Through the encryption of data is the channel secured against an acquaintance listening. Using authentication codes (MAC, Message Authentication Code) helps to prevent the manipulation of messages. 31

32 3 Theoretical Part NFCIP-1 Security Services and Protocol (NFC-SEC) NFC-SEC provides an independent protection by cryptographic methods for the peer-to-peer mode. NFC-SEC builds on NFCIP-1 and acts as an intermediate layer between NFCIP-1 and higher protocols, such as the LLCP. NFC-SEC has a standard modular composition and consists of a general framework (NFC-SEC) and several cryptography standards (NFC-SEC-XX). The following figure shows the structure of NFC-SEC. Figure 3.22: Structure of NFC-SEC NFC-SEC offers two services: Shared Secret Service (SSE): Key exchange for an application-specific encryption. Secure Channel (SCH): Key exchange and authentic, confidential data-communication. 32

33 3.2 NFC References [1] Josef Langer & Michael Roland, Anwendungen und Technik von Near Field Communication (NFC), Springer Berlin, 2010, p

34 3 Theoretical Part 3.3 NFC Data Formats This chapter gives an insight into the specifications of the memory and data formats. This includes the NFC forum tag formats and data exchange format NDEF NFC-Forum-Tags NFC tags are passive devices that can be used to communicate with active NFC devices. The NFC tags can be applied within applications such as posters and other areas where small amounts of data can be stored and transferred to active NFC devices. To use a NFC Tag into a NFC infrastructure it must have some basic functions. That includes reading and writing operations on the data memory and a possibility to secure the memory against further unauthorized writing operations. There are four basic tag types that have been defined by the NFC forum. All four are based on existing RFID tags Type 1 Type 1 includes simple storage tags based on NFC-A technology (ISO14443A standard). These NFC tags are reading and rewriting compatible and users can configure the tag to become read-only. The memory availability is 96 bytes which is more than sufficient to store a website URL or other small amount of data. However, the memory size is expandable up to 2048 bytes. The communication speed of this NFC tag is 106 kbit/s. As a result of its simplicity these tags are cost effective and ideal for many NFC applications Type 2 This type is also based on ISO14443A. These NFC tags are reading and rewriting compatible and users can configure the tag to become read-only. The basic memory size of this tag type is only 48 bytes although this can be expanded to 2048 byte. The communication speed is also 106 kbit/s. In contrast to type 1 there also exists an anti-collision process. This allows multiple tag 2 types to be at the same time in the field of the reader Type 3 The NFC tag 3 type is based on the Sony FeliCa system. It currently has a 2048 byte memory capacity and the data communication speed is 212 kbit/s. This type offers an anti-collision process as well. A FeliCa smartcard is assigned by a system code to a specific application. During the initialization, a reading device can chose all smartcards of a specific application by its system code and ignore all other cards from other applications. NFC has the system code 12FC. Therefore this NFC tag type is more applicable for more complex applications, although there is a higher cost per tag Type 4 The NFC tag 4 type is defined by a compatibility with NFC-A and NFC-B (ISO14443A and B) standards. These NFC tags are preconfigured at manufacture and they can either be able to read / rewrite or read-only. The memory capacity can be up to 32 kbytes and the communication speed is between 106 kbit/s and 424 kbit/s. In contrast to simple memory tags (tag type 1 and 2) are used processor-based smartcards technologies are applied in the this tag type. 34

35 3.3 NFC Data Formats NFC Data Exchange Format (NDEF) The NFC Data Exchange Format (NDEF) specification defines the format and regulations for the construction of data structures for the exchange of information between NFC devices or between NFC devices and NFC forum tags. On the basis of different transmission protocols and storage devices, NDEF guarantees a standardized format for data exchange in any NFC application. Thereby the NFC application and processing of data are independently used from the data source. NDEF is a lightweight binary message format designed to encapsulate one or more application-defined payloads into a single message construct. A NDEF message contains one or more NDEF records, each carrying a payload of arbitrary type and size NDEF Record The payloads of the application layer are clustered in NDEF records. Each NDEF record (Fig. 3.23) consists of a header and a data part (Payload). The header contains flags, length information for fields with variable lengths, information about the type of payload and a unique identifier of the user data packet. The header contains five flags: MB (Message Begin) ME (Message End) CF (Chunk Flag) SR (Short Record); is set to one IL (ID Length Present) MB and ME select the first or last record within a NDEF message. CF indicates that the data packet is shared between this two and at least the next NDEF record. SR signals a shortened NDEF record (is set to one into the Fig. 3.23). The field Payload Length is shortened from 32-bit to 8 bit in the Short Record. IL indicates if the record contains NDEF identification data. If this bit is not set, the record does not contain the field ID neither the field ID Length. Figure 3.23: NDEF-Record [2] 35

36 3 Theoretical Part The value of TNF (Type Name Format) determines the format of the field type. Figure 3.24 gives an overview of possible values. Type length is a 8-bit value and indicates the length of the type field. The field payload length and ID length is a 8-bit value and specifies the length of the payload field respectively the length of the ID field. The type field contains a format specification according to the criteria of the Type Name Format (TNF). These types are explained in detail in the following section. Figure 3.24: Possible values for the TNF field [2] NDEF Message A NDEF message is composed of one or more NDEF records. The first record in a message is marked with the MB (Message Begin) flag set and the last record in the message is marked with the ME (Message End) flag set. The minimum message length is one record which can be achieved by setting both the MB and the ME flag in the same record. The following figure shows the structure of a NDEF Message: Figure 3.25: NDEF-Message [2] The message head is to the left and the tail to the right. 36

37 3.3 NFC Data Formats MIME Media Types Multipurpose Internet Mail Extension Media Types are used to format messages with different content. MIME MEdia Types can specify the body of textual messages with any character set or other messages with textual content. With MIME Media Type NDEF records can be text, images, videos or other information that is transported in various formats. The type specification consists of two parts. A top-level type and a subtype: <Top-Level-Typ</<Subtype> The top-level type classifies formats into basic categories, "text" for text messages, "image" for image data, "video" for video data, "audio" for audio or "application" for application-specific data formats. The subtype specifies a specific format. For example: text/plain text without specific formatting information image/jpeg image file in JPEG format NFC Record Type Definition (RTD) Because NDEF does not define how data into NDEF records should be interpreted by the NFC devices, the NFC forum describes the NFC Record Type Definition (RTD) specification. The RTD specifications not only provide basic data structures, but also directives for processing and presentation of data. RTDs can be a single date record, such as a text or a URI (Uniform Resource Identifier) or can be composed of one ore more NDEF records. NDEF records include by encoding the TNF-field two classes of NFC record types: NFC Forum Well-known Types NFC Forum External Types NFC Forum Well-known Types NFC Forum Well-known Types are reserved for the NFC Forum. A NFC Forum Well Known Type is identified inside a NDEF message by setting the TNF field of a record to the value of 0x01. The names of the record types are composed according to the following pattern: urn:nfc:wkt:<name> Only the relative URN <name> is entered into the field type. For example, the Well-known Type urn:nfc:wkt:a would be encoded as a. The Well-known Type urn:nfc:wkt:very-complicated-type would be encoded as Very-complicated-type NFC Forum External Types The External Type Name is meant for organizations that wish to self-allocate a name space to be used for their own purposes. An External Type is identified in a NDEF record by setting the TNF field value to 0x04. urn:nfc:ext:<domain>:<name> The External Type is established like a Well Known Type. Only the relative URN <domain>:<name> is entered into the field type. 37

38 3 Theoretical Part Text Record Type The Text Record Type encapsulates simple text without formal criteria. This type is a NFC Forum Well-known Type and has the typ-name urn:nfc:wkt:t. The payload field of NDEF records consists of a status byte, a language code and the actual text. Bit 7 of the status byte indicates the character encoding of the text. The language code defines the language of the text and is specified in the form of an ISO or IANA language code. The following figure shows an example of a text record: Figure 3.26: Text Record URI Record Type URI records include a Uniform Resource Identifier (URI). This can either be a Uniform Resource Name (URN) or Uniform Resource Locator (URL). URIs can be addresses, internet addresses or phone numbers. This type is also a NFC Forum Well-known Type and has the typ-name urn:nfc:wkt:u. The payload field (Fig. 3.27) of a NDEF record consists of an identifier code and the URI. Figure 3.27: Payload of an URI Record Type [1] The following table shows some identifier codes: Identifier Code URI prefix 00 no prefix, the field contain the whole URI tel: 06 mailto: 13 urn:// 23 urn:nfc: 24 to FF future extensions 38

39 3.3 NFC Data Formats Smart Poster Record Type The Smart Poster is one of the key use cases for NFC technology. The idea is that an object can be made smart, which means, that it is capable of storing additional information about itself in the form of an NFC Forum Tag. By touching an NFC Forum Device to the tag, this information can be read and displayed to the user. The Smart Poster can also contain actions that will trigger an application in the device, for example, launching a browser to view a web site or sending a text message to a premium service to receive a ring tone. The Smart Poster Record Type is an extension of the URI Record and connects it with other elements. The Smart Poster NDEF-Record serves as a container for a NDEF-Message. This NDEF-Message is composed of a URI Record and various other records with metadata about the URI. The Smart Poster Record Type uses the NFC Forum Well-known Type urn:nfc:wkt:sp. The payload field consists of a NDEF message, which is composed of exactly one URI-Record and multiple optional records URI Record The URI Record is the central element of the Smart Poster. It can be a web address, an address, phone number, or even an entire or text message. The following table shows some URI examples: Function WWW adress adress telephone number SMS URI mailto:max.example@nfc-research.ch tel: sms: ?body=text mailto:max.example@nfc-research.ch?subject=subject&body=text Title Record The Title Record is an instance of a Text RTD Record. There may be an arbitrary number of title records in the Smart Poster. However, there must not be two or more records with the same language identifier. A Title Record contains a descriptive text to the URI of the Smart Poster. The receiving NFC device can select a matching Title Record by voice information and show it as a description of the URI on the screen Icon Record The Smart Poster may also contain a number of Icon Records that have an image NDEF MIME type. For example, image/jpeg, image/png. There may also be animated Icon Records, using common media types such as video/mpeg. A reader device should display only one of these Icons to the user, prior to acting on the URI Record Recommended Action Record The Action Record is a local type specified for the Smart Poster. It suggests what the device should do with the content. The local NFC Forum Well-known Type urn:nfc:wkt:act is applied. A Smart poster Record can contain a maximum of one Recommended Action Record. The payload field of this NDEF Record consists of exactly one byte, which encodes the proposed action (see following table [3]). Value Action 00 do the action (send the SMS, launch the browser, make the telephone call) 01 save for later (store the SMS in INBOX, save the telephone number in contacts) 02 open for editing (open an SMS in the SMS editor, open the URI in an URI editor) 02 to FF future extensions 39

40 3 Theoretical Part Size Record The Size Record is a local NFC Forum Well-known Type of a Smart Poster application and has the type name urn:nfc:wkt:s. A maximum of one Size Record can be included in a Smart Poster Record. The Size Record implies a four-byte, unsigned integer, which is composed of the size of the other object that the URI field refers to Type Record The Type Record is also a local NFC Forum Well-known Type of Smart Poster application and uses the type name urn:nfc:wkt:t. The payload of the Type Record is a UTF-8 formatted string that describes a MIME type which describes the type of the object that can be reached through the URI Application Cases Typical application cases of the Smart Poster Record Types are advertising posters with active content. Such a poster can invite someone for example, to visit a website or buy an electronic tickets for public transports. The user can identify a poster by the "N-Mark". The "N-Mark" is a special symbol, which was designed by the NFC Forum to signalize NDEF applications. Figure 3.28: N-Mark 5 The following example shows a Smart Poster which advertising an internet address. The area of the poster, which is equipped with the NFC tag, is marked with the "N-Mark". Figure 3.29: Smart Poster application N 1 [1] 5 cf. 40

41 3.3 NFC Data Formats This example shows a Smart Poster that enables the purchase of an electronic ticket for the public transport. Figure 3.30: Smart Poster application N 2 [1] Generic Control Record Type The Smart Poster concept focuses on the processing of URIs. It was designed for the control of mobile phones relating to advertising and information services. NFC is not limited to the Smart Posters scenario and can be used as activator technology for radio transmission or a variety of control tasks. For this purpose, the generic record type was developed by the NFC forum. The Generic Control Record Type uses the NFC Forum Well-known Type urn:nfc:wkt:gc. The payload field (Fig. 3.31) is composed of a configuration byte and a NDEF message. The NDEF message consists of one target record, a maximum of one Action Record and one Data Record. Figure 3.31: Payload of a Generic Control Record Type [1] Target Record The Target Record is a local NFC Forum Well-known Type and the type name is urn:nfc:wkt:t. The payload field contains a text or the individual URI record. The text or URI identifies a specific target endpoint on which the action and the data must be applied. 41

42 3 Theoretical Part Action Record The Action of Record is a local NFC Forum Well-known Type and has the type name is urn:nfc:wkt:a. The payload field includes the action flag byte and the action field. Bit 0 of the action flag byte determines the format of the action field. If this bit is 1, then the action box contains exactly one byte: the Action Numeric Code. Otherwise the action field contains a NDEF record that indicates an action interpreted by the destination endpoint, as follows: Value Action 00 default function for the specified destination endpoint 01 the control task is to be saved for use at a later point of time 02 the control task is to be opened for further editing 03 to FF future extensions Data Record The Data Record is a local NFC Forum Well-known Type and the type name is urn:nfc:wkt:d. The payload field contains data for transmission to the destination endpoint Signature Record Type The previously considered Record Type definitions and NFC Forum Tags offer no security measures for the data. Protective measures for data transmission can be divided in two categories: encryption and signature. The authenticity and originality of the data can be ensured by signing. On or multiple NDEF records in a NDEF message can be signed with a Signature Record Type. The Signature Record Type uses the NFC Forum Well-known Type urn:nfc:wkt:sig. The payload field (Fig. 3.32) consists of the version of information, the signature field and a certificate chain. The version byte defines the version number of the applied signature. Currently, 01 is the only valid version. Figure 3.32: Payload of a Signature Record Type [1] The signature field contains a signature or the reference to a signature. It consists of the "URI exists" bit, the type of signature and a signature or reference. If the "URI exists" bit is set to 1, then the Signature Records contain an embedded signature. A Signature Record without signature indicates 42

43 3.3 NFC Data Formats that the previous records of NDEF messages are unsigned. The following table shows possible values for the signature type field: Value Type of signature 00 no signature 01 RSASSA-PSS (with SHA-1) 02 RSASSA-PKCS-v1.5 (with SHA-1) 03 DSA 04 ECDSA-p-192 (with SHA-1) 05 to FF future extensions The field certificate chain includes all certificates that a NFC device needs to guarantee the authenticity of the Signature Record. The certificate format field indicates whether the certificates are in the X.509 (value 00 ) or in the X9.68 format (value 01 ). On the certificate format follows the number of certificates and all embedded certificates. If the "URI exists" bit is set to 1, then follows the reference to the next certificate into the hierarchy. A Signature Record signs all previous NDEF records in a NDEF message which has no previous Signature Record (Fig. 3.33). This means that the first Signature Record is responsible for each NDEF record from the beginning of a NDEF message up to the record standing directly in front of the signature. The next Signature Record signs all records between the first Signature Record and itself. Figure 3.33: Assignments of signatures in a NDEF-Message [1] Connection Handover Through its easy handling NFC is very practical for the rapid transmission of data. Today NFC systems possess only low data rates, that is why other wireless technologies (WLan, Bluetooth) are necessary to transmit a large amount of data. When a large amount of data is being transmitted via NFC, then the communication parameters of a different radio technology are being exchanged via the NFC interface. The connection will be established automatically and the data will be transferred from one device to the other. The Handover-Protocol can be used in two ways: First, the selection of connection options between two NFC devices are negotiated by the mutual exchange of handover messages (Negotiated Handover). Secondly, the handover of connection options can be effected immediately without any negotiating opportunities (Static Handover) Negotiated Handover Negotiated Handover allows two devices to negotiate one or more alternative carriers for further data exchange. The NDEF-Message exchange is effected in the peer-to-peer mode with a transmission protocol such as the Logical Link Control Protocol (LLCP). One of the two devices takes the role of the requester and the other of the selector. The requester starts the Negotiated Handover with 43

44 3 Theoretical Part a Handover Request NDEF-Message. The selector responds to the requests with a Handover Select NDEF-Message. The requester tells the selector all supported communication interfaces. Subsequent the selector select a proposed communication interface. The negotiation attempt fails if there is no common interface. In this case, the selector responds with an empty Handover Select record. The following figures shows various Negotiated Handovers. In the first example, the application running on the Handover Requester first announces its alternative carriers (WLan and Bluetooth wireless technology) to the Handover Selector, and then receives a carrier selection (Bluetooth wireless technology) as the only choice and finally performs Bluetooth pairing and data exchange. Figure 3.34: Negotiated Handover with Single Selection [4] If the Handover Selector supports multiple alternative carriers, it might return more than one selection (Fig. 3.35). In this case, the Handover Requester is free to choose any of the returned carriers or even try to simultaneously connect to more than one alternative carrier. However, if the Handover Requester attempts to choose one of the selected carriers, it should follow the order in which they are listed in the Handover Select message. In the example of Figure 3.35, the Handover Requester has decided against the Handover Selector s preference for Wi-Fi and has used Bluetooth wireless technology instead. Figure 3.35: Negotiated Handover with Multiple Selections [4] The next example (Fig. 3.36) illustrates how a Handover Requester might use a second alternative carrier selection to enhance the user experience. In this example, the Handover Selector again returns both Wi-Fi and Bluetooth wireless technology, but this time with Bluetooth wireless technology as the first preference. The Requester first tries to establish a Bluetooth connection which fails (for example, because the devices have moved outside of Bluetooth radio range). In this case, the application might decide to try the Wi-Fi connection before aborting. 44

45 3.3 NFC Data Formats Figure 3.36: Negotiated Handover with Multiple Selections [4] Static Handover The Static Handover can be used when the Handover Selector device does not constitute a NFC Forum Device but has a NFC Forum Tag attached. The NFC tag contains a Handover Select NDEF- Message. Figure 3.37: Static Handover [4] Handover Request Record The Handover Request Record uses the NFC Forum Well-known Type urn:nfc:wkt:hr. The payload field contains version informations followed by one or more Alternative Carrier Records Handover Select Record The Handover Select Record uses the NFC Forum Well-known Type urn:nfc:wkt:hs. The payload field contains version informations followed by one or more alternative carriers Records. For the case that there is no common communication interface the handover protocol provides to send a selected message without alternative carrier Records Alternative Carrier Record An alternative carrier Record describes exactly one communication interface. The payload contains a reference to a Handover Carrier Record (Reguest Message) or Carrier Configuration Record (Select Message). The handover Record Carrier identifies a single interface. It is used in request messages to show all interfaces of the requester. The record has the NFC Forum Well-known Type urn: fc:wkt:hc. The Carrier Configuration Record contains configuration parameters for a designed interface. It is used to send the configuration of interfaces to the requester. 45

46 3 Theoretical Part References [1] Josef Langer & Michael Roland, Anwendungen und Technik von Near Field Communication (NFC), Springer Berlin, 2010, p [2] NFC Data Exchange Format (NDEF), Technical Specification NFC Forum TM, maintag.fr/fichiers/pdf-fr/nfcforum-ts-ndef-1-0.pdf, July 2006 [3] Smart Poster Record Type Definition, Technical Specification NFC Forum TM, maintag.fr/fichiers/pdf-fr/nfcforum-smartposter-rtd-1-0.pdf, July 2006 [4] Connection Handover, Technical Specification NFC Forum TM, fichiers/pdf-fr/nfcforum-ts-connectionhandover-1-1.pdf, November

47 3.4 Development Basics 3.4 Development Basics This chapter of the theoretical report describes the applied SDKs. It does not give detailed information about the developing process or the application, which is going to be produced in a later step of this project, but it explains the basics and concepts of the SDKs in order to be capable of developing a NFC application. Figure 3.38: Android logo [5] Android Originally Android was developed by Andy Rubin in 2003 as an operating system and software platform. Today, Android is the fastest growing platform for mobile devices and has a market share of almost 50%. According to Google, over half a million Android devices are being unlocked every day. The search engine giant bought the brand in 2005 and pushed its development before it founded the Open Handset Alliance in 2007 which today has over 80 members in different industries like operators, software companies, hardware companies and marketing companies. The goal of the alliance is the creation of an open standard for mobile devices. The first Android smartphone (HTC Dream) was sold in The recently introduced version 4.0 (Ice Cream Sandwich) merges the two development branches for smartphones and tablets. Android bases on the 2.6 Linux-Kernel. Applications for the platform are written in the Java programming language. The code is compiled by the Android SDK into an.apk archive, which is then being used on the device for installation. Figure 3.39: Android 4.0 homescreen[5] 47

48 3 Theoretical Part Application components The main difference to normal Java applications is the fact that an Android app can have multiple entry points. This allows an app to use components of other applications. For this purpose they do not have to start the whole program, but just the specific, needed part of it. For example, if the user likes to send a note by , the note application just calls the send-new- activity from the app. An application can be composed of different components[3]: Activity An activity represents a single screen with a user interface. For example, an application might have one activity that shows a list of new s, another activity to compose an , and a third activity to read s. Although the activities work together to form a cohesive user experience in the application, each of them is independent of the others. An activity is implemented as a subclass of Activity. Services A service is a component that runs in the background to perform long-running operations or work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it. A service is implemented as a subclass of Service. Content receivers A content provider manages a shared set of application data. You can store the data in the file system, SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications can query or even modify the data. For example, the Android system provides a content provider that manages the user s contact information. As such, any application with the proper permissions can query part of the content provider to read and write information about a particular person. A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other applications to perform transactions. Broadcast receivers A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system. For example, a broadcast announcing that the screen has turned off, the battery is low, or a picture has been captured. Applications can also initiate broadcasts. For example, to let other applications know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers do not display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event. A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is delivered as an Intent object. Every application is launched in a separate process to assure a certain level of security. Thereby an activity belonging to another app can not be launched directly. Instead a message has to be sent to the system which starts the desired component. This message is called Intent. Every application has to be described in the AndroidManifest.xml file which is read by the system before it launches the app. The file contains the definition of the components, permission, required API level and so on. 48

49 3.4 Development Basics User Interface The view is the essential part of an application when we are talking about user interfaces (UI). This contains the layout of UI objects on the screen, menus, action bars, notifications, event listeners and others. Views can either be defined in a xml file or at runtime. Mostly xml files are used because this is the more convenient way. The xml file contains the specification of the layout and all the elements (like buttons or textviews) and their placement, margins, paddings et cetera. The view is then loaded on the activity startup with the setcontentview() method. Basically there are different types of layouts which can be interlaced with each other another to get the desired result. The most important ones are introduced here: FrameLayout Only one UI element is placed on the screen. LinearLayout The different elements are placed among or next to each other dependent on the definition of the layout (horizontal or vertical). TableLayout The UI elements are placed in a table. RelativeLayout Elements are placed in relativity to others depending on the definitions of the programmer. For UI elements the line-up goes from buttons, checkboxes, image buttons, image views, progress bars, radio buttons, spinners to textviews and many more. There are listen- Event listeners on UI elements can simply be realized with anonymous classes. ers for different purposes: onclick() onlongclick() onfocuschange() onkey() ontouch() oncreatecontextmenu() 49

50 3 Theoretical Part HelloAndroid The following sample code shows the mentioned concepts behind the Android development. By touching the button in the HelloAndroid activity the application passes an intent to the system to open the write-new- activity of the application. 1 public class HelloAndroid extends A c t i v i t y { 2 Button button ; 3 TextView t e x t ; 4 6 // This method i s c a l l e d when the a c t i v i t y f i r s t s t a r t s 7 public void oncreate ( Bundle s a v e d I n s t a n c e S t a t e ) { 8 super. oncreate ( s a v e d I n s t a n c e S t a t e ) ; 9 // Loading the xml view 10 setcontentview (R. layout. main ) ; // Getting the r e f e r e n c e o f the UI elements 13 button = ( Button ) findviewbyid (R. i d. button ) ; 14 t e x t = ( TextView ) findviewbyid (R. id. t e x t ) ; // Changing the comportment o f the UI elements at runtime 17 button. settext ( "Send an " ) ; 18 t e x t. settext ( " H e l l o Android " ) ; // Event l i s t e n e r 21 button. s e t O n C l i c k L i s t e n e r (new View. OnClickListener ( ) { 22 public void onclick ( View view ) { 23 // Creating a new I n t e n t 24 f i n a l I n t e n t e m a i l I n t e n t = new I n t e n t ( android. content. I n t e n t. ACTION_SEND) ; 25 // Adding a d d i t i o n a l i n f o r m a t i o n l i k e address, s u b j e c t and t e x t to the i n t e n t 26 e m a i l I n t e n t. settype ( " p l a i n / t e x t " ) ; 27 e m a i l I n t e n t. putextra ( android. content. I n t e n t.extra_ , new S t r i n g [ ] { " t e s n f c P r o j e c t. ch" }) ; 28 e m a i l I n t e n t. putextra ( android. content. I n t e n t.extra_subject, " Hello Android " ) ; 29 e m a i l I n t e n t. putextra ( android. content. I n t e n t.extra_text, " This i s a t e s t " ) ; 30 s t a r t A c t i v i t y ( I n t e n t. createchooser ( intent, "Send mail... " ) ) ; 31 } 32 }) ; 33 } 34 } 50

51 3.4 Development Basics As mentioned the manifest file contains all the information concerning the application. The SDK version as well as the activity are defined here in order to inform the system before launching the program. 1 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <manifest xmlns:android=" h t t p : // schemas. android. com/apk/ r e s / android " 3 package="ch. n f c P r o j e c t. HelloAndroid " 4 android:versioncode="1" 5 android:versionname=" 1. 0 " > 6 7 <uses sdk android:minsdkversion="10" /> 8 9 <a p p l i c a t i o n 10 a n d r o i d : i c o n="@drawable/ ic_launcher " 11 a n d r o i d : l a b e /app_name" > 12 <a c t i v i t y 13 a n d r o i d : l a b e /app_name" 14 android:name=". HelloAndroid " > 15 <intent f i l t e r > 16 <a c t i o n android:name=" android. i n t e n t. a c t i o n.main" /> <category android:name=" android. i n t e n t. category.launcher" /> 19 </ intent f i l t e r> 20 </ a c t i v i t y> 21 </ a p p l i c a t i o n> </ manifest> The following code shows the view xml file of the HelloAndroid application. It is realized with a simple linear layout, a text view and a button. The id field (Lines 8 & 13) of each component serves as reference to change its comportment during runtime. 1 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <LinearLayout xmlns:android=" h t t p : // schemas. android. com/apk/ r e s / android " 3 android:layout_width=" f i l l _ p a r e n t " 4 android:layout_height=" f i l l _ p a r e n t " 5 a n d r o i d : o r i e n t a t i o n=" v e r t i c a l " > 6 7 <TextView 8 a n d r o i d : i d="@+id / t e x t " 9 android:layout_width=" f i l l _ p a r e n t " 10 android:layout_height=" wrap_content" /> <Button 13 a n d r o i d : i d="@+id / button " 14 android:layout_width=" wrap_content" 15 android:layout_height=" wrap_content" /> </ LinearLayout> 51

52 3 Theoretical Part The following screens (Fig. 3.40) represent the launched activities. As soon as the Send an button is pressed, the intent is sent to the system. This causes the HelloAndroid activity to pause and the app to get the focus. With sending the the mail application is terminated and the HelloAndroid activity gets the focus again. Figure 3.40: HelloAndroid activity and new- activity 52

53 3.4 Development Basics HelloNFC Android lets us easily transmit data over NFC. The main reason for this is the driver for the NFC hardware, called NfcAdapter 6, from the package android.nfc 7. As soon as a tag is detected, the Android system reads it and looks for a matching application to handle it. An app can be attached to a NFC event by an intent filter, which is defined in the AndroidManifest. The intent is then sent to the corresponding activity getting the focus. The following code represents the Manifest file of the HelloNFC application. The ACTION TECH DISCOVERED intent filter is defined on lines 22 to 24. This kind of intent is used for smartcards. See the NFC permission on line: This entry in the Manifest is used to guarantee that the NFC functionality can be used by the app. Otherwise the application crashes. 1 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <manifest xmlns:android=" h t t p : // schemas. android. com/apk/ r e s / android " 3 package="ch. e i a n f c p r o j e t. HelloNFC" 4 android:versioncode="1" 5 android:versionname=" 1. 0 " > 6 7 <uses sdk android:minsdkversion="15" /> 8 9 <uses p e r m i s s i on android:name=" android. permission.nfc" /> <a p p l i c a t i o n 12 a n d r o i d : i c o n="@drawable/ ic_launcher " 13 a n d r o i d : l a b e /app_name" > 14 <a c t i v i t y 15 a n d r o i d : l a b e /app_name" 16 android:name="ch. e i a f r. p r o j e t n f c. HelloNFC. HelloNFCActivity " > 17 <intent f i l t e r > 18 <a c t i o n android:name=" android. i n t e n t. a c t i o n.main" /> <category android:name=" android. i n t e n t. category.launcher" /> 21 </ intent f i l t e r> 22 <intent f i l t e r > 23 <a c t i o n android:name=" android. nfc. a c t i o n.tech_discovered" /> 24 </ intent f i l t e r> <meta data 27 android:name=" android. nfc. a c t i o n.tech_discovered" 28 a n d r o i d : r e s o u r c e="@xml/ n f c _ t e c h _ f i l t e r " /> 29 </ a c t i v i t y> 30 </ a p p l i c a t i o n> </ manifest> Often an application uses a specific type of smartcard. The following code shows the detailed definition of the intent filter. The path to this file is defined in the Manifest (lines 26 to 28). Our sample just uses a Mifare Classic card that is in the tech list (lines 3 to 5). 1 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <r e s o u r c e s x m l n s : x l i f f=" u r n : o a s i s : n a m e s : t c : x l i f f : d o c u m e n t : 1. 2 "> 3 <tech l i s t>

54 3 Theoretical Part 4 <tech>android. nfc. tech. M i f a r e C l a s s i c</ tech> 5 </ tech l i s t> 6 </ r e s o u r c e s> The HelloNFC application simply writes a text message to the smartcard (line 23) and reads the NDEF message stored on the smartcard (line 25) which is then displayed on the screen. The Ndef 8 class permits operations on the detected Tag 9. 1 public class HelloNFCActivity extends A c t i v i t y { 2 TextView tv ; 3 NfcAdapter mnfcadapter ; 4 5 / Called when the a c t i v i t y i s f i r s t c r e a t e d. / 7 public void oncreate ( Bundle s a v e d I n s t a n c e S t a t e ) { 8 super. oncreate ( s a v e d I n s t a n c e S t a t e ) ; 9 setcontentview (R. layout. main ) ; 10 mnfcadapter = NfcAdapter. getdefaultadapter ( this ) ; 11 tv = ( TextView ) findviewbyid (R. i d. textview1 ) ; // Checking i f a NFC chip i s a v a i l a b l e and switched on 14 i f ( mnfcadapter == null! mnfcadapter. isenabled ( ) ) { 15 Toast. maketext ( this, "NFC i s not a v a i l a b l e! ", Toast.LENGTH_SHORT) 16. show ( ) ; 17 f i n i s h ( ) ; 18 } // Checking i f smartcard has been d e t e c ted 21 i f ( NfcAdapter.ACTION_TECH_DISCOVERED. e q u a l s ( g e t I n t e n t ( ). getaction ( ) ) ) { 22 // Writing a NDEF t e x t t a g to the smartcard 23 writendeftag ( g e t I n t e n t ( ), " Hello NFC" ) ; 24 // Reading the NDEF tag o f the smartcard 25 S t r i n g texttag = readndeftag ( g e t I n t e n t ( ) ) ; 26 tv. settext ( texttag ) ; 27 } 28 // No smartcard d e t e c t e d 29 else { 30 Log. d ( HelloNFCActivity. class. getsimplename ( ), 31 "No Smartcard d e t e c t e d " ) ; 32 Toast. maketext ( this, "No Smartcard detected ", Toast.LENGTH_SHORT) 33. show ( ) ; 34 f i n i s h ( ) ; 35 } 36 } private void writendeftag ( I n t e n t intent, S t r i n g t e x t ) { 39 // Getting the r e f e r e n c e to the d e t e c t e d smartcard 40 Tag mytag = i n t e n t. g e t P a r c e l a b l e E x t r a ( NfcAdapter.EXTRA_TAG) ; 41 Ndef ndef = Ndef. get (mytag) ; // Creating a NDEF message c o n t a i n i n g a NDEF t e x t r e c o r d 44 NdefRecord [ ] r e c o r d s = new NdefRecord [ 1 ] ; 45 r e c o r d s [ 0 ] = createndeftextrecord ( t e x t ) ; 46 NdefMessage message = new NdefMessage ( r e c o r d s ) ; 8 cf. 9 cf. 54

55 3.4 Development Basics // Writing the message to the smartcard 49 try { 50 ndef. connect ( ) ; 51 ndef. writendefmessage ( message ) ; 52 ndef. c l o s e ( ) ; 53 Log. d ( HelloNFCActivity. class. getsimplename ( ), 54 "Tag wrote s u c c e s s f u l l y! " ) ; 55 } catch ( Exception e ) { 56 Log. e ( HelloNFCActivity. class. getsimplename ( ), 57 e. getlocalizedmessage ( ) ) ; 58 } 59 } protected static NdefRecord createndeftextrecord ( S t r i n g t e x t ) { 62 // Creating a t e x t tag according to the d e f i n i t i o n o f the NFC Forum 63 // See Figure 2.26 (Ch Text Record Type ) f o r f u r t h e r 64 // i n f o r m a t i o n 65 S t r i n g lang = "en" ; 66 byte [ ] textbytes = t e x t. getbytes ( ) ; 67 byte [ ] langbytes = null ; 68 try { 69 langbytes = lang. getbytes ( "US ASCII" ) ; 70 } catch ( UnsupportedEncodingException e ) { 71 Log. e ( HelloNFCActivity. class. getsimplename ( ), 72 e. getlocalizedmessage ( ) ) ; 73 } 74 int langlength = langbytes. l ength ; 75 int textlength = textbytes. l ength ; 76 byte [ ] payload = new byte [ 1 + langlength + textlength ] ; // S e t t i n g the s t a t u s byte 79 payload [ 0 ] = ( byte ) langlength ; 80 // S e t t i n g the language code 81 System. arraycopy ( langbytes, 0, payload, 1, langlength ) ; 82 // S e t t i n g the payload ( t e x t ) 83 System. arraycopy ( textbytes, 0, payload, 1 + langlength, textlength ) ; return new NdefRecord ( NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_TEXT, 86 new byte [ 0 ], payload ) ; 87 } private S t r i n g readndeftag ( I n t e n t i n t e n t ) { 90 // Getting NDEF message from i n t e n t and c o n v e r t i n g i t to a NDEF record 91 NdefMessage [ ] msg = getndefmessage ( i n t e n t ) ; 92 NdefRecord [ ] record = msg [ 0 ]. getrecords ( ) ; 93 byte [ ] payload = r ecord [ 0 ]. getpayload ( ) ; // Checking i f tag i s a t e x t tag 96 i f ( r ecord [ 0 ]. gettnf ( ) == NdefRecord.TNF_WELL_KNOWN) { 97 i f ( Arrays. e q u a l s ( r e cord [ 0 ]. gettype ( ), NdefRecord.RTD_TEXT) ) { try { 100 // Getting the s t a t u s byte 101 S t r i n g textencoding = ( ( payload [ 0 ] & 0200) == 0)? "UTF 8" 102 : "UTF 16" ; 103 // Getting the l e ngth o f the language code 104 int languagecodelength = payload [ 0 ] & ; 105 Log. d ( HelloNFCActivity. class. getsimplename ( ), 55

56 3 Theoretical Part 106 "Tag read s u c c e s s f u l l y! " ) ; 107 // Returning the payload ( t e x t ) as a S t r i n g 108 return new S t r i n g ( payload, languagecodelength + 1, 109 payload. l e n g t h languagecodelength 1, 110 textencoding ) ; 111 } catch ( UnsupportedEncodingException e ) { 112 Log. e ( HelloNFCActivity. class. getsimplename ( ), 113 e. getlocalizedmessage ( ) ) ; 114 } 115 } 116 } else { 117 Log. d ( HelloNFCActivity. class. getsimplename ( ), 118 " Unsupportet tag type! " ) ; 119 f i n i s h ( ) ; 120 } 121 return null ; 122 } // Getting NDEF message from i n t e n t 125 private NdefMessage [ ] getndefmessage ( I n t e n t i n t e n t ) { 126 P a r c e l a b l e [ ] msgs = i n t e n t 127. getparcelablearrayextra ( NfcAdapter.EXTRA_NDEF_MESSAGES) ; 128 NdefMessage [ ] nmsgs = new NdefMessage [ msgs. l ength ] ; for ( int i = 0 ; i < nmsgs. l e ngth ; i++) 131 nmsgs [ i ] = ( NdefMessage ) msgs [ i ] ; return nmsgs ; 134 } 135 } 56

57 3.4 Development Basics If more than one application has an intent filter for a detected tag, the system lets the user choose the preferred app (Fig. 3.41, left side). The other screenshot (Fig. 3.41, right side) shows the HelloNFC application displaying the text read from the smartcard. Figure 3.41: Application list and HelloNFC activity 57

58 3 Theoretical Part Smartcard Access This section presents an insight on how the used smartcards are structured and how they can be accessed. With NFC, various types of smartcards operating on a frequency of Mhz (RFID and NFC) can easily be read or written. Most cards are similar, for this reason we have chosen the Mifare Classic 1k and 4k smartcard for our project. Both smartcards are equipped with a security mechanism which is more and more important in everyday life of the digital system Memory organisation The Mifare 1kByte smartcard has a bit EEPROM memory, organized in 16 sectors with 4 blocks of 16 bytes each. Figure 3.42: Memory organisation Mifare 1k smartcard [6] 58

59 3.4 Development Basics The EEPROM of the 4kByte smartcard is organized in 32 sectors with 4 blocks and in 8 sectors with 16 blocks. One block consists of 16 bytes. Figure 3.43: Memory organisation Mifare 4k smartcard [7] Manufacturer block The first data block (block 0) of the first sector (sector 0) is called manufacturer block. It contains the IC manufacturer data. Due to security and systems requirements, this block is writing protected after having been programmed by the IC manufacturer at production. The following figure shows the structure of this block. Figure 3.44: Manufacturer block [6] 59

60 3 Theoretical Part Data blocks Mifare 1k smartcard All sectors contain 3 blocks of 16 bytes for storing data. (Sector 0 contains only 2 data blocks and the read-only manufacturer block). Mifare 4k smartcard Sectors 0 to 31 contain 3 blocks and sectors 32 to 39 contain 15 blocks for storing data. (Sector 0 contains only 2 data blocks and the read-only manufacturer block). These Data blocks can be configured by the access bits as read/write blocks for contactless access control value blocks for electronic purse applications Sector trailer Each sector has a sector trailer which is located in the last block of each sector. He holds the: secret key A and B (optional) of the sector returning logical 0 when read the access conditions for all blocks of that sector that are stored in bytes 6 to 9. The access bits also specify the type (read/write or value) of the data blocks. Figure 3.45: Sector trailer [6] 60

61 3.4 Development Basics Memory access Before any memory operation can be carried out, the card has to be selected and authenticated. After Power On Reset (POR) of a card, it can answer to a request, that was sent by the reader, to all cards in the antenna field by sending the answer request code (ATQA according to ISO/IEC 14443A). Thereafter, in the anticollision loop, the serial number of each card is read. If there are several cards in the field of the reader, they can be distinguished by their unique serial numbers. One card can be selected for further transactions by its ID. The other cards return to standby mode and wait for a new request command. Figure 3.46: Connection establishment and card selection After the selection of a card, the reader specifies the memory location of the following memory access and uses the corresponding key for the three pass authentication procedure. After a successful authentication all memory operations are possible (read/write bock). The three pass authentication scheme includes key searching and mutual authentication, which can resist most attacks between reader and tag, including tracing, tracking, cloning, counterfeiting and eavesdropping. A three pass mutual authentication verifies both reader and tag. 61

62 3 Theoretical Part Three pass authentication sequence: 1. The reader specifies the sector to be accessed and chooses key A or optional key B (Query). 2. The card reads the secret key and the access conditions from the sector trailer. Then the card sends a random number called metaid as a challenge to the reader (pass one). 3. The reader calculates the response using the secret key and additional input. The response is transmitted together with a random challenge from the reader to the card (pass two). 4. The card verifies the response of the reader by comparing the response to the challenge and transmits it (pass three). 5. The reader verifies the response of the card by comparing it to its own challenge. Figure 3.47: Three pass authentication The possible memory operations for an addressed block depend each time on the key and the access conditions stored in the associated sector trailer. The following figure shows the general scheme of memory access from Mifare smartcards. Figure 3.48: Memory access [6] 62

63 3.4 Development Basics NDEF Data management on Smartcards A specific scheme is used to manage NDEF data on smartcards. The memory mapping of NDEF data for the Mifare classic smartcards uses the Mifare application directory structure (MAD). The Mifare application directory identifies to which application the information stored inside each memory sector belongs. Two Mifare application directories have been specified: 1. MAD1 The MAD1 is located in the MAD sector (sector 0). In case MAD1 is used on smartcards with a memory size bigger than 1Kbytes, only 1Kbytes memory can be used and addressed by the MAD1. The remaining memory is therefore not used for NDEF storage and stays free. 2. MAD2 MAD2 may be used in any Mifare standard smartcards with a memory size bigger than 1Kbytes. MAD2 is not applicable for products with a memory size smaller or equal to 1Kbytes. The MAD2 is located in the MAD sectors (sector 0 and 16) MAD Sector Access The memory sectors where MAD1 and MAD2 are stored, are protected using key A and key B. Anybody shall be allowed to read the MAD sectors. This is achieved by using a public key A described in the following table: Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 0xA0 0xA1 0xA2 0xA3 0xA4 0xA NFC Sector Access An NFC Sector is readable authenticating it with the public key A defined in the following table. The public key A for a NFC Sector is different from public key A for MAD sector. Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 0xD3 0xF7 0xD3 0xF7 0xD3 0xF7 63

64 3 Theoretical Part NDEF Managment To detect and access NDEF data (NDEF Message) inside the Mifare smartcard, the MAD should be used together with the GPB of the NFC sectors. An application identifier (AID) of the MAD, called NFC AID, is reserved to identify sectors with NDEF data. A sector with NDEF data is called NFC sector. The two fields of the NFC AID are set as follows: The function cluster code is equal to 0xE1 to identify the cluster of sectors with NDEF data. The application code is equal to 0x03 to identify the NFC sector that this application note is related to. The NDEF data is written starting from the NFC sector with the smallest sector number up to the biggest one. The General Purpose Byte (GPB) of each NFC sector provides information about the version number of the mapping model used to store the NDEF data into the Mifare standard and the writing access of the NFC sectors. The data format of the NDEF Message is defined by NDEF and was presented in the previous chapter. A NDEF Message is stored inside the value field of the NDEF Message TLV (Type Length Value block) using one or more NFC Sectors. At least one NDEF Message TLV is always present inside the Mifare standard tag. The three TLV fields of a NDEF Message are coded as follows: T (tag field, or T field) is supposed to identify the type of the TLV block. For NDEF 0x03 is used. L (length field, or L field) provides the size in bytes of the value field. It should be equal to the size in bytes of a stored NDEF Message. V (value field, or V field). The length field is either equal to 00h or there is no length field. It contains the NDEF Message. At the end of a NDEF Message a terminator TLV is added (0xFE). 64

65 3.4 Development Basics The following figure shows a Mifare 1k smartcard containing NDEF data (an empty NDEF Message). In this example, every sector is an NFC sector. Figure 3.49: Storing NDEF data in Mifare 1k smartcard [8] 65

66 3 Theoretical Part Sniffer In another phase we try to develop a sniffer allowing us to scan and copy several ski passes. Because we had some complications to complete this objective practically, we now provide in this chapter a theoretical sequence that could be realizable Scan content of a ski pass First of all we tried to scan the contents of a ski pass. This can be done with an existing android application of NXP Semiconductors. With its help we also found some important information about the smartcard used by the ski pass. Manufacturer: EM Microelectronic-Marin SA Memory size: 208 bytes 52 blocks, with 4 bytes per block Technologies: ISO/IEC compatible (NfcV) ISO/IEC compatible Android technology classes: android.nfc.tech.nfcv The following illustration shows the possible content of a ski pass. This ski pass we scanned in Fledberg Germany and dates from 31 December If we look closer, we see that the most blocks contain the value zero. Some blocks are protected with a password, like all Mifare smartcards. Because we do not know this password, we effect the scan of the ski pass with the default password of NfcV. Data of those sectors, which are not protected, can be read out without any problems while the others cannot be read out (value zero). Figure 3.50: Content of a ski pass 66

67 3.4 Development Basics Password sniffing The next step is to sniff the password which is sent out by the ski station. To achieve this, it is necessary to put the Nexus S into the card emulation mode. The goal is to simulate a smartcard with the Nexus S which corresponding to the previously scanned types and memory sizes. The Nexus S is equipped with the NXP PN544 NFC chip. With this chip it is possible to work in the card emulation mode. The problem is that Android provides no JAVA API which enables this mode. The following graphic shows how the hardware can be accessed with Java. The application, written in Java, can communicate with the hardware (NFC chip) using the Java Native Interface (JNI). Libnfc allows us to access the hardware with existing drivers and libraries. In order to enable the card emulation mode on the Nexus S we have to write a Java API that communicates through the JNI with the hardware. Figure 3.51: Hardware access with Java through JNI After some research in different NFC forums we found various prototypes of Java Code and API s who allowing to simulate a Mifare 1k cards. Because the ski station does not respond to any arbitrary smartcard, but only to the type "ski pass - NfcV", we cannot use this API and these code examples. Due to time-based issues we were incapable o writing our own API to enable this mode. If it were possible to operate in the card emulation mode with our mobile phone, we could put the emulated Nexus S in front of a ski station and try to read what the station is sending out. It is possible that the password is sent clear and not encrypted. We avoid this assumption because until now it has not been possible, further more there has not been any uncovering of such a safety problem with existing hard- and software. With the help of the Nexus S we now possess of a programmable mobile NFC chip. 67

68 3 Theoretical Part References [1] Zigurd Mednieks & Laird Dornin & G. Blake Meike & Masumi Nakamura, Programming Android, O Reilly Media, 2011, chapters 3 & 7 [2] Android Developers - What is Android?, what-is-android.html, October 2011 [3] Android Developers - Application Fundamentals, topics/fundamentals.html, October 2011 [4] Android Developers - User Interface, index.html, November 2011 [5] Wikipedia - Android (Betriebssystem), (Betriebssystem), October 2011 [6] Data sheet Mifare standard 1kByte Card IC, MF1 IC S50, functional specification, http: // May 2001 [7] Data sheet Mifare standard 4kByte Card IC, MF1 IC S70, functional specification, http: // October 2002 [8] AN1304, NFC Type MIFARE Classic Tag Operation, techarticles/nxp/an1304.pdf, May

69 4 Practical Part 4.1 Scenario Equipped with the know-how of the preliminary studies, the final part of this project is the development of a NFC application. The app should demonstrate the potential of the technology as well as it should be usable for everyone in a promising application area. In order to satisfy our demands we decided to realize a tourist app. The app is a platform for cities or tourist site operators to share information about a specific object. It allows visitors to either inform themselves about prearrangements for the most convenient and interesting stay prior to their visit or to take digital souvenirs back home. The range and form of shared information is multifaceted: Text (Entry fees, opening hours, general and historical information) Multimedia (Photo albums) Links (Additional web information sources) Figure 4.1: Scenario illustration with NFC information spot 69

70 4 Practical Part The exchange of information between the user and the system is passing the following stages: 1. The tourist arrives at the site and places his smartphone to the marked NFC information spot. 2. The smartphone downloads the information from the spot and stores it in the internal storage. 3. A list with an entry for each site, where information has been downloaded appears. 4. By clicking an entry, the stored content is being displayed. 5. Back home, the user can share the entries with family and friends. Figure 4.2: Application functional specification illustration 70

71 4.2 Architecture & Design 4.2 Architecture & Design For the implementation of the scenario we decided to create two separate Android applications. One to write NFC messages to tags and to work in peer-to-peer mode. This application is therefore used by the site operator. The second one is used by tourists or guests. It can read several types of messages and the application can share them with other NFC powered smartphones. The two applications are called nwriter and ntourist. Figure 4.3: nwriter and ntourist icons nwriter The nwriter application gives the user the possibility to either write several NFC message types to a passive tag like a smartcard (reader / writer mode) or to send data directly from smartphone to smartphone (peer-to-peer mode). The peer-to-peer mode is applied for messages with picture content, so the device corresponds to a NFC spot located in front of the touristic site. The used Mifare Classic 1K smartcard has just 1kB of storage which is not enough to store a picture on it. But it is perfectly suited to store text and URLs that could be used as lightweight information source for a specific part of the site. This application is designed for tourist site operators only and not available to the public. Class diagram The class diagram in figure 4.4 shows the structure of the nwriter application. Activity The Activity class represents a single screen to interact with the user. As mentioned in the theoretical part, an activity is an entry point to the application. It also takes care of drawing and displaying the UI. NfcAdapter The NfcAdapter class is the driver for the NFC hardware. Ndef The Ndef class provides a set of operations to access, write and read different types of tags. StartScreen The StartScreen activity asks the user to either start the NfcSpot or the TagWriter activity. NfcSpot If the NfcSpot activity is started, the device works in peer-to-peer mode. As soon as another NFC device is connected, the NfcAdapter sends the defined NDEF message. 71

72 4 Practical Part TagWriter The TagWriter activity gives the user a set of message types to write on a smartcard. It can choose from a palette of text; URI and smartposter messages. Figure 4.4: nwriter class diagram ntourist ntourist is the application for tourists and available to the public. It interacts either directly with the nwriter app within peer-to-peer mode (NfcSpot mode) or with another smartphone running the ntourist app to share information about a site. It can also read the content of a smartcard, that has been written with the nwriter application (TagWriter mode). Information is displayed in a structured way. Class diagram The class diagram in figure 4.5 shows the structure of the ntourist application. NfcAdapter.CreateNdefMessageCallback The interface NfcAdapter.CreateNdefMessageCallback invokes a callback as soon as an other NFC device is in contact. It defines the transmitted NDEF message. NfcAdapter.OnNdefPushCompleteCallback As soon as the NDEF message is sent, the interface NfcAdapter.OnNdefPushCompleteCallback invokes a callback. It defines the action after the transmission. 72

73 4.2 Architecture & Design NFCType The enumeration NFCType is employed to compare message types. StartScreen The activity StartScreen gets the focus when the application is started. It shows the logo of the application for five seconds and then automatically starts the activity SiteList. SiteList The activity SiteList reads all the sites out of the internal storage and displays them in tabular form. If an entry is clicked, the activity SiteView is started. A menu gives the user the possibility to delete the entries. SiteView The activity SiteView displays a single spot with all its content saved to the internal storage. The content includes text, URLs as well as pictures. A menu permits to share or delete the specific site. GetMifare The activity GetMifare is called when a Mifare Classic smartcard is detected. It reads the NDEF message and stores the content to the internal storage. As soon as the content is stored, an entry is being displayed in the SiteList activity. The activity is automatically started by an intent filter when a Mifare Classic card is discovered. GetNfcSpot The activity GetNfcSpot is launched when a peer-to-peer transmission is initiated. The received NDEF message is also saved to the internal storage and displayed in the SiteList activity. If a NFC spot is detected, the activity is started automatically by an intent filter. ShareSite The activity ShareSite is used to share a NFC message with another smartphone. This gives tourists the opportunity to pass information about a site to other persons. 73

74 4 Practical Part Figure 4.5: ntourist class diagram 74

75 4.3 Implementation 4.3 Implementation Android provides a set of useful libraries to work with NFC. The packages android.nfc and android.nfc.tech contain all the necessary classes and interfaces to allow an Android application to interact with tags and other smartphones employing NFC. While the package android.nfc consists of a hardware driver, the message types and peer-to-peer functionality, android.nfc.tech provides all the necessary material to manipulate different types of NFC compatible tags and smartcards. Furthermore we defined a few types of messages which are used to communicate in the different modes of operation and the structure of the files where the messages are stored in the internal storage. The employed classes and interfaces from the libraries, the classes of our applications as well as the data formats of the messages and the files are described on the following pages Android libraries Package android.nfc From the package android.nfc 1 the following classes and interfaces are implemented: Class NfcAdapter The NfcAdapter (Fig. 4.6) is the driver that lets the software interact with the hardware. Normally a smartphone has just one NFC chip and therefore just one NfcAdapter. Figure 4.6: Implemented Class android.nfc.nfcadapter Constants String ACTION_NDEF_DISCOVERED Intent to start a registered activity when a tag with NDEF payload is detected. ntourist uses this intent for peer-to-peer mode. String ACTION_TECH_DISCOVERED Intent to start a registered activity if a tag with a specific technology is discoverd. ntourist and nwrtier use this kind of filter to read or write a Mifare Classic smartcard. String EXTRA_TAG Constant to get the reference to a discovered tag as a Tag object. 1 cf. 75

76 4 Practical Part String EXTRA_NDEF_MESSAGES Extra containing the NDEF messages from a tag. messages from the intent. Used in ntourist to get the NDEF Methods static NfcAdapter getdefaultadapter(context context) Gets the default adapter of the NFC hardware. Method to instantiate the NfcAdapter. boolean isenabled() Returns the power state of the NFC chip. The chip can be switched on and off in the Android system settings. void setndefpushmessage(ndefmessage message, Activity activity) Sets the NdefMessage to send by an activity when a NFC device is discovered. If the parameter message is null, the function is disabled. Used in nwriter for peer-to-peer mode. void setndefpushmessagecallback (NfcAdapter.CreateNdefMessageCallback callback, Activity activity) Sets a callback to an activity in order to create a NDEF message to push over NFC. Employed in ntourist to share a site. void setonndefpushcompletecallback (NfcAdapter.OnNdefPushCompleteCallback callback, Activity activity) Sets a callback to an activity if a NDEF message has been sent successfully Class NdefMessage A NdefMessage (Fig. 4.7) (NFC Data Exchange Format Message) contains one or more NdefRecords. A NdefMessage is the object transmitted to tags or other smartphones by NFC. It follows the structure given by the NFC Forum. Figure 4.7: Genreral structure NdefMessage 76

77 4.3 Implementation Constructor NdefMessage(NdefRecord[] records) Creates an NdefMessage based on an array of NdefRecords. Methods NdefRecord[] getrecords() Returns an array of NdefRecords based on the NdefMessage Class NdefRecord A NdefRecord (Fig. 4.8) represents a record from a NdefMessage. It describes and contains the delivered data. A NdefRecord always consists of the TNF (Type Name Format), the type, an ID and the payload. See the theoretical part for further information on this subject. Figure 4.8: Genreral structure NdefRecord Constants short TNF_WELL_KNOWN This name format is used for simple records containing text, URI s or smartposters. The following types (Type field) are implemented: byte[] RTD_SMART_POSTER A smartposter contains a NdefMessage with several NdefRecords as payload. For example a text record and an URI record with a web address and a brief description. byte[] RTD_TEXT The payload is ASCII text. byte[] RTD_URI The payload consists of an URI address ( mailto: and so on). short TNF_MIME_MEDIA The MIME format is usually used for more sophisticated types. Those are typically images or references to an application to handle this particular record. Constructor NdefRecord(short tnf, byte[] type, byte[] id, byte[] payload) Creates a NdefRecord. The parameter TNF describes the format (TNF_WELL_KNOWN or TNF_MIME_MEDIA), type describes the type of the record (RTD_URI, RTD_TEXT, RTD_SMART_POSTER or others), ID is an identification and payload contains the data of the record. 77

78 4 Practical Part Methods byte[] getpayload() Returns the payload of the NdefRecord as byte array. short gettnf() Returns the TNF value of the NdefRecord. byte[] gettype() Returns the type in form of a byte array Class Tag The Tag object represents a discovered passive NFC device at the time of discovery. It is used to get the reference to a detected tag to perform operations on it Interface NfcAdapter.CreateNdefMessageCallback The setndefpushmessagecallback() method from the class NfcAdapter invokes a callback to this interface (Fig. 4.9) if a NFC device is detected. Figure 4.9: Implemented Interface android.nfc.nfcadapter.createndefmessagecallback Methods NdefMessage createndefmessage(nfcevent event) Creates and returns a NdefMessage to push process. This method is called when a callback for the relevant activity is registered on the NfcAdapter Interface NfcAdapter.OnNdefPushCompleteCallback The setonndefpushcompletecallback() method from the class NfcAdapter invokes a callback to this interface (Fig. 4.10) if a NFC device is discovered. Figure 4.10: Implemented Interface android.nfc.nfcadapter.onndefpushcompletecallback 78

79 4.3 Implementation Methods void onndefpushcomplete(nfcevent event) This method is called after completing the Ndef push. A callback for the relevant activity has to be registered on the NfcAdapter Package android.nfc.tech From the package android.nfc.tech 2 the following class is employed: Class Ndef The class Ndef (Fig. 4.11) permits the communication with a tag. The most common tag types are supported. To instantiate an Ndef object the get(tag) method is utilized, where the Tag object refers to the discovered tag. Figure 4.11: Implemented Class android.nfc.tech.ndef Methods static Ndef get(tag tag) Returns the reference of the Ndef object by passing the discovered tag as parameter. void connect() Connects to the tag before treating reading or writing cycles. NdefMessage getndefmessage() Returns the NDEF message stored on the tag. void writendefmessage(ndefmessage msg) Writes the parameter msg to the tag. This overwrites the current NDEF message stored on the tag. void close() Disables I/O operations on the tag. 2 cf. 79

80 4 Practical Part NDEF message structure nwriter and NTourist use NDEF messages that follow the guidelines of the NFC Forum. Nevertheless only a few types are implemented and useable with the two applications. In order to guarantee the interoperability, the defined structures for different purposes have to be used. ntourist allows to display information about a particular site. The defined scenario proposes information in form of text, URL s and pictures. The implemented NDEF records provide to transmit this kind of payload NDEF TNF_WELL_KNOWN record types With nwriter we have the possibility to write the following types of well known name formatted NDEF records to tags: RTD_TEXT To transmit simple ASCII text a NDEF message with one NDEF text record is employed. The record describes and contains the text (Fig 4.12). Figure 4.12: Implemented NDEF Text Record RTD_URI To share a URL address a NDEF message with one NDEF URI record is employed. The record describes and contains the URL (Fig. 4.13). RTD_SMARTPOSTER The structure of a smartposter (Fig. 4.14) is a little bit more complicated. It provides the possibility to integrate one or more text and URI records in one and the same message. Therefore there is a root NDEF message containing a smartposter record which itself contains another NDEF message as payload. This message is formed of multiple records. In our case there are just one text record and one or multiple URI records. ntourist is capable of reading, storing and displaying well known NDEF messages containing a text or a smartposter record as payload. Raw URI records are not supported. 80

81 4.3 Implementation Figure 4.13: Implemented NDEF URI Record Figure 4.14: Implemented NDEF Smartposter Record 81

82 4 Practical Part NDEF MIME_MEDIA record types For the peer-to-peer mode the simplest way to send a message is the MIME message type. Android automatically analyses the first record of a discovered NDEF message. The MIME type provides the option to add the name of an application in the type field to handle the discovered message. Another feature of MIME records is to transmit a picture. Therefore the type field states the instruction image/png. nwriter uses the structure below (Fig. 4.15) which is comprehensible for ntourist. The first MIME record contains the command to use ntourist as handler for this NDEF message. A second NDEF message is formed by a smartposter record with a third NDEF message built with one text record, one or more URI records and one icon record that including a picture. Figure 4.15: Implemented NDEF MIME MEDIA Record File storage structure In order to guarantee that collected information is persistent, ntourist stores all the discovered and supported NDEF messages to the internal storage before displaying them. To be sure that no information out of the received messages gets lost, an adequate structure of the file has to be evolved (Figure 4.16). The field type represents the type of the record (text, smartposter or MIME). Afterwards the payload of the text record, which is always present, is stored, followed from the URL s that are not present if there is just a text record. The file is named with the first token from the text record. Pictures are 82

83 4.3 Implementation stored on the external storage for reasons of simplicity. Figure 4.16: Implemented file storage structure nwriter App nwriter is the application which is occupied with writing NDEF messages to discovered tags. It handles reader / writer as well as peer-to-peer mode. See chapter Architecture for the class diagram Class Startscreen The class Startscreen (Fig. 4.17) is the main entry point to the application. If the application is started this activity appears asking the user to either work in peer-to-peer (NfcSpot) or in reader / writer mode (TagWriter). Extends the class android.app.activity. Figure 4.17: Implemented Class nwriter.startscreen Attributes Button tag UI element to start the activity TagWriter. Button spot UI element to start the activity NfcSpot. 83

84 4 Practical Part Method void oncreate(bundle savedinstancestate) Entry point to the applications. It contains two listeners for the buttons with the instructions to start the according activity. Overrides the method android.app.activity.oncreate Class TagWriter Activity (Fig. 4.18) to write a NDEF message to a passive tag. It is automatically started when an intent with the corresponding tag technology is created. However, only Mifare Classic tags are supported. Extends the class android.app.activity. Figure 4.18: Implemented Class nwriter.tagwriter Attributes int TEXTTAG Final integer to indicate writing a text record to a tag. int URITAG Final integer to indicate writing a URI record to a tag. int SMARTPOSTER Final integer to indicate writing a smartposter record to a tag. String BERN_TEXT Final string containing the text for the smartposter record. String[] BERN_URL Final string array containing a set of URL addresses for the smartposter record. ImageView iv ImageView to display a picture on the screen. 84

85 4.3 Implementation Methods void oncreate(bundle savedinstancestate) Entry point to the activity displaying an alert dialog asking the user the type of NDEF message to write to the discovered tag. Supported messages are text (one text record), URI (one URI record) and smartposters (one text record and one ore more URI records). Overrides the method android.app.activity.oncreate. void writendeftag(intent intent, String text, int tagtype) Method to write a message type (parameter tagtype) to a tag. The reference to the tag is got from the intent and the constant EXTRA_TAG from the class NfcAdapter. This procedure has been described earlier in the implementation report. The messages are created with the following methods permitting to create the supported message types. NdefRecord createndeftextrecord(string text) Returns a text NdefRecord with the parameter text as payload. The specifications conform to the suggestions of the NFC Forum. NdefRecord createndefurirecord(string address) Returns an URI NdefRecord with the parameter address as payload. The specifications conform to the suggestions of the NFC Forum. NdefRecord createndefsmartposterrecord(string text, String[] uri) Returns a smartposter NdefRecord with one text record and one ore more URI records. The specifications conform to the suggestions of the NFC Forum Class NfcSpot The class NfcSpot (Fig. 4.19) permits the peer-to-peer operation mode. This kind of functionality is used to directly push NDEF messages between active NFC devices. NfcSpot is employed to play the role of the NFC spot on a touristic site where tourists get their information. Extends the class android.app.activity. Figure 4.19: Implemented Class nwriter.nfcspot Attributes String FRI_TEXT Final string containing the text for the smartposter record. 85

86 4 Practical Part String[] FRI_URL Final string array containing a set of URL addresses for the smartposter record. NdefMessage msg NdefMessage to push to the target device. Methods void oncreate(bundle savedinstancestate) Entry point to the activity checking if NFC is available and active. The NdefMessage to push over NFC is defined here. It is a MIME record type structured as discussed earlier in the implementation report. The push message is activated with the method setndef- PushMessage() from the class NfcAdapter. Overrides the method android.app.activity.oncreate. void onresume() Launched if the activity is resumed. Resets the NdefMessage to push if NFC is available and active. void onpause() Deactivates the NDEF message push if the activity is paused in order to not interfere with other applications. NdefRecord createndefsmartposterrecord(string text, String[] uri) Returns a smartposter NdefRecord. The specifications conform to the suggestions of the NFC Forum. To create the text and URI records, the methods from the class nwriter.tagwriter are employed. NdefRecord createndeficonrecord() Returns a MIME type image NdefRecord. The specifications conform to the suggestions of the NFC Forum. The source picture is stored on the external storage ntourist App Tourists use this app to get information delivered by the nwriter app. It can read, store, display and share NDEF messages. See chapter Architecture for the class diagram Class Startscreen The class Startscreen (Fig. 4.20) is the main entry point to the application. It displays the App logo before starting the SiteList activity. Extends the class android.app.activity. Attributes boolean _active Boolean to indicate whether the screen has been touched or not. int _splashtime Integer to adjust the display time of the logo. 86

87 4.3 Implementation Figure 4.20: Implemented Class ntourist.startscreen Methods void oncreate(bundle savedinstancestate) Entry point to the application. It creates a Thread to wait while splashtime is running or until the user touches the screen before starting the activity SiteList. Overrides the method android.app.activity.oncreate. void ontouchevent(motionevent event) Is called when the user touches the screen while the logo is shown. This sets the boolean _active to false and affects the Thread to stop and launch the activity SiteList. Overrides the method android.app.activity.ontouchevent Class SiteList The class SiteList (Fig. 4.21) displays all collected NDEF messages in tabular form. Only the name of the site as well as a picture is shown. Extends the class android.app.listactivity. Figure 4.21: Implemented Class ntourist.sitelist Methods void oncreate(bundle savedinstancestate) Is called on activity startup. Invokes the displayitems() method to display the stored NDEF messages. Overrides the method android.app.activity.oncreate. void onresume() Launched if the activity is resumed. The list is updated. Overrides the method android.app.activity.onresume. 87

88 4 Practical Part void onlistitemclick(listview l, View v, int position, long id) This method is called when an entry from the ListView is pressed. The activity SiteView is launched and displays a particular information about the site. The name of the site to display is passed as parameter. Overrides the method android.app.listactivity.onlistitemclick. oncreateoptionsmenu(menu menu) Is called when the menu button is pressed to build and display the menu defined in a XML file. Overrides the method android.app.activity.oncreateoptionsmenu. onoptionsitemselected(menuitem item) If a menu item is pressed this method is invoked. The only option is to delete the stored NDEF messages. Overrides the method android.app.activity.onoptionsitemselected. void displayitems() Method employed to set the stored items to the ListActivity view Class SiteView Activity (Fig. 4.22) which displays all stored information about a site. There is text, URL and picture content depending on the stored NDEF message type. Extends the class android.app.listactivity. Figure 4.22: Implemented Class ntourist.siteview Attributes TextView text TextView to advise the NDEF text record content. TextView link TextView to display the NDEF URI record content if existent. ImageView iv ImageView showing the picture, if existent. String filename String indicating the file to display. 88

89 4.3 Implementation Methods void oncreate(bundle savedinstancestate) On activity startup, the content of the file is read and prepared to display in different TextViews and the ImageView. The content appears according to the type of the stored NDEF message. Overrides the method android.app.activity.oncreate. oncreateoptionsmenu(menu menu) Is called when the menu button is pressed to build and display the menu which is defined in a XML file. Overrides the method android.app.activity.oncreateoptionsmenu. onoptionsitemselected(menuitem item) If a menu item is pressed this method is invoked. There are options to share or to delete the stored NDEF message of this particular site. Overrides the method android.app.activity.onoptionsitemselected. String getfilecontent() Returns the content of the stored file as string. The string follows the definition of the file structure as discussed earlier in this report Class GetMifare The class GetMifare (Fig. 4.23) is started automatically with an intent filter if a tag with the Mifare Classic technology is discovered by the system. Extends the class android.app.listactivity. Figure 4.23: Implemented Class ntourist.getmifare Attributes String filename String indicating the name of the file to store. Methods void oncreate(bundle savedinstancestate) This method is called on activity startup and checks if NFC is available and active before passing the intent to the processintent() method. As soon as a tag is discovered, the system gets the NDEF message of it. Afterward the system creates an intent with the message 89

90 4 Practical Part as parameter. The activity with a corresponding intent filter receives the focus and the intent is passed to it. Overrides the method android.app.activity.oncreate. processintent(intent intent) Gets the NDEF message passed by the intent with help of the getndefmessage() method. The records are recuperated and the payload is analyzed. A string is created with all the content of the records and is passed, together with the message type, to the storeentry() method. NdefMessage[] getndefmessage(intent intent) Returns the NdefMessages passed by the intent which called the activity. For this purpose the constant EXTRA_NDEF_MESSAGED from the class NfcAdapter is employed. NFCType gettagtype(final NdefRecord record) Returns the type of the parameter record. Used to ensure a proper handling of the available records extracted from the original message. String getndeftype_text(final byte[] payload) Returns the payload of a text record as string. This method respects the structure of the payload for a text record suggested by the NFC Forum. String getndeftype_uri(final byte[] payload) Returns the URI in the payload of a URI record respecting the structure given by the NFC Forum. void storeentry(string text, NFCType type) Stores the NDEF message in the private storage area of the application. The file respects the proposed file structure discussed earlier in the implementation report. The first token of the text parameter is used as filename Class GetNfcSpot The GetNfcSpot (Fig. 4.24) activity is started automatically when a smartphone running the nwriter app in peer-to-peer mode is discovered. The system analyzes the first record and finds the instruction to launch ntourist.getnfcspot to handle the NDEF message. Figure 4.24: Implemented Class ntourist.getnfcspot 90

91 4.3 Implementation Attributes String filename String indicating the name of the file to store. Methods void oncreate(bundle savedinstancestate) This method is called on activity startup and checks if NFC is available and active before passing the intent to the processintent() method. The NDEF message is passed as a parameter of the intent by the system. Overrides the method android.app.activity.oncreate. processintent(intent intent) Gets the NDEF message passed by the intent with help of the getndefmessage() method. The records are recuperated and the payload is analyzed. A string is created with all the content of the records and passed together with the message type to the storeentry() method. The picture is stored with the storepicture() method to the external storage. NdefMessage[] getndefmessage(intent intent) Returns the NdefMessages passed by the intent which called the activity. For this purpose the constant EXTRA_NDEF_MESSAGED from the class NfcAdapter is employed. NFCType gettagtype(final NdefRecord record) Returns the type of the parameter record. Used to ensure a proper handling of the available records extracted from the original message. String getndeftype_text(final byte[] payload) Returns the payload of a text record as string. This method respects the structure of the payload for a text record suggested by the NFC Forum. String getndeftype_uri(final byte[] payload) Returns the URI in the payload of an URI record respecting the structure given by the NFC Forum. void storeentry(string text, NFCType type) Stores the NDEF message in the private storage area of the application. The file respects the proposed file structure discussed earlier in the implementation report. The first token of the text parameter is used as filename. void storepicture(byte[] payload, byte[] filetype, char name) Converts the parameter payload to a Bitmap and store it to the external storage. filename the first character of the site name is utilized. As Class ShareSite If the menu item Share is pressed during the activity SiteView has focus, the class ShareSite (Fig. 4.25) is launched. It sends the site in form of a NDEF message to another NFC powered smartphone. 91

92 4 Practical Part Figure 4.25: Implemented Class ntourist.sharesite Attributes String filename String indicating the name of the file to share. Methods void oncreate(bundle savedinstancestate) Entry point to the activity checking if NFC is available and active. The NdefMessage to push over NFC is defined here. It is a MIME record type structured as discussed earlier in the implementation report. The implemented interfaces CreateNdefMessageCallback and OnNdefPushCompleteCallback and its methods take care of the push process. Overrides the method android.app.activity.oncreate. NdefRecord createndefsmartposterrecord(string text, String[] uri) Returns a smartposter NdefRecord. The specifications dresses to the suggestions of the NFC Forum. Uses the methods createndeftextrecord() and createndeftextrecord(). NdefRecord createndefsmartpostericonrecord(string text, String[] uri) This method offers the same functionality as the one above. It only has an additional MIME picture record, created with the method createndeficonrecord(). NdefRecord createndeficonrecord() Returns a MIME type image NdefRecord. The specifications conform to the suggestions of the NFC Forum. The source picture is stored on the external storage. NdefRecord createndeftextrecord(string text) Returns a text NdefRecord with the parameter text as payload. The specifications conform to the suggestions of the NFC Forum. NdefRecord createndefurirecord(string address) Returns an URI NdefRecord with the parameter address as payload. The specifications conform to the suggestions of the NFC Forum. NdefMessage createndefmessage(nfcevent event) Method invoked when a callback is registered on the NfcAdapter (NfcAdapter.setNdefPush 92

93 4.3 Implementation MessageCallback()) for this activity. The callback is caused when an active NFC device has been discovered. The return parameter NDEF message is the message to push over NFC. Implements the method android.nfc.nfcadapter. CreateNdefMessageCallback.createNdefMessage. void onndefpushcomplete(nfcevent event) This method is launched once a NDEF push process has been completed. A registration on the NfcAdapter activates the callback (NfcAdapter.setOnNdefPushCompleteCallback()). Implements the method android.nfc.nfcadapter.onndefpushcompletecallback. onndefpushcomplete. String getfilecontent() Returns the content of the stored file as string. The string follows the definition of the file structure discussed earlier in the implementation report Enumeration NFCType The enumeration NFCType serves to indicate the message type for storage purposes and to compare types while extracting and converting NDEF messages and records in reading cycles. Figure 4.26: Implemented Enumeration NFCType Attributes UNKNOWN Corresponds to the constant TNF_UNKNOWN from the class android.nfc.ndefrecord. TEXT Corresponds to the field RTD_TEXT (TNF_WELL_KNOWN) from the class android.nfc.ndefrecord. URI Corresponds to the field RTD_URI (TNF_WELL_KNOWN) from the class android.nfc.ndefrecord. SMART_POSTER Corresponds to the field RTD_TEXT (RTD_SMART_POSTER) from the class android.nfc.ndefrecord. 93

94 4 Practical Part ABSOLUT_URI Corresponds to the constant TNF_ABSOLUTE_URI from the class android.nfc.ndefrecord. MIME_MEDIA Corresponds to the constant TNF_MIME_MEDIA from the class android.nfc.ndefrecord. 94

95 4.3 Implementation References [1] Android Developers - Near Field Communication, topics/nfc/index.html, January 2012 [2] Android Developers - References, html, January 2012 [3] Android Development - How to: Create a splash screen, how-to-create-a-splash-screen,561.html, December 2011 [4] Zigurd Mednieks & Laird Dornin & G. Blake Meike & Masumi Nakamura, Programming Android, O Reilly Media, 2011, chapters 16 95

96 4 Practical Part 4.4 Tests The final step of the implementation process is the testing. It guarantees a smooth functionality and checks if all specifications and needs are kept and followed. The tests are divided into two categories: Functional Tests This test takes care of the interoperability of the two developed applications. Are all features, as defined in the scenario, implemented and do they work respecting all circumstances? Specification Tests This test routine controls what happens if other messages are sent which are not supposed to work with the app ntourist Functional Tests nwriter The functional tests for the nwriter application cover the flawless action for writing cycles to a passive tag as well as the writing cycle to an active tag Reader / writer mode The following screenshots (Fig. 4.27) show the flow of actions performed to write a NDEF message to a discovered passive tag. 1. If a tag is discovered, the system asks the user to select the app to handle the tag. All applications with an intent filter for the Mifare Classic technology are listed. 2. If the nwriter app is selected, an alert dialog appears asking the user to select the type of NDEF message to write to the tag. 3. After selection the message is written and a pop-up message indicating the successful action is being displayed. 4. If the connection is lost while writing, a pop-up message with a corresponding note is displayed. The same happens when the application is started manually by the user without a tag in touch. 96

97 4.4 Tests Figure 4.27: Flow of actions during a writing cycle to a passive tag Peer-to-peer mode The following screenshots (Fig. 4.28) show the flow of actions performed to beam a NDEF message to a discovered active tag. 1. The peer-to-peer functionality has to be started manually by the user. The idle screen appears. 2. As soon as an active tag has been detected, the system launches the Beam functionality integrated into Android. Since API 14, Beam takes care of sharing information by NFC. A touch by the users starts the transmission. If the connection is lost during transmission, the idle screen appears. 3. After completing the process, the idle screen is relaunched. The progress of transmission is visualized by the shrinking activity screen. Figure 4.28: Flow of actions during to beam a NDEF message to another active tag 97

98 4 Practical Part ntourist The functional tests for the nwriter application cover the flawless action for reading cycles from a passive or an active tag as well as the sharing functionality to another smartphone Reading a passive tag The following screenshots (Fig. 4.29) show the flow of actions performed to read and display an NDEF message from a passive tag. Note that raw URI records are not supported by ntourist. 1. If a tag is discovered the system asks the user to select the app to handle the tag. All applications with an intent filter for the Mifare Classic technology are listed. 2. If the ntourist app is selected, the application reads the NDEF message from the intent, stores the content and launches the SiteList activity, displaying a message with the name of the spot as well as the list entry for the stored message. The touch of a list entry starts the SiteView activity. 3. A smartposter record (Bern) with one text record and three URI records has been read. 4. A text record (Zürich) with one text record has been read. Figure 4.29: Flow of actions during reading and displaying a passive tag Reading an active tag The following screenshots (Fig. 4.30) show the flow of actions performed to read and display an NDEF message from an active tag. 1. If a tag is discovered, the system creates an intent with the NDEF message. In addition, the system analyzes the first NDEF record and finds the instruction to launch the GetNfcSpot to handle the received message. Once the NDEF message is stored, the SiteList activity gets the focus. This process accords to the definition in the architecture as well as the implementation. 98

99 4.4 Tests 2. The SiteList activity displays the message with the name of the spot as well as the list entry for the stored message. The touch of a list entry starts the SiteView activity. 3. A MIME record (Freiburg) with one text record, two URI records and one picture record has been read. Figure 4.30: Flow of actions during reading and displaying an active tag Sharing a site The following screenshots (Fig. 4.31) show the flow of actions performed to share information, collected on a site, with another smartphone. 1. When the menu button is pressed, the option to share the content appears. The ShareSite activity is started. 2. The share activity creates the NDEF message and waits until a tag is within reach. 3. With an active NFC device in touch, the Android Beam functionality comes into action. This procedure is the same as used for the NfcSpot (nwriter - Peer-to-peer mode). 4. After transmission, the SiteView activity gets the focus again. 99

100 4 Practical Part Figure 4.31: Flow of actions during reading and displaying an active tag File handling Figure 4.32 illustrates the picture stored on the SD card with the first letter of the site name as filename. Figure 4.32: Picture stored on the SD card The following screenshots (Fig. 4.33) show the flow of actions performed to delete a site. 1. The SiteList activity has three entries. The entry "Bern" is touched, which causes the SiteView activity to get started. 2. When the menu button is pressed, the option to delete the entry appears. The SiteList activity is relaunched and updated. 3. A menu permits to delete all the entries at the same time. 100

101 4.4 Tests 4. The SiteList activity appears updated. Figure 4.33: Flow of actions during reading and displaying an active tag Specification Tests The specification tests only concern the ntourist app. The impacts of reading unsupported message types are analyzed and corrected if necessary. If an unsupported raw URI record is read by ntourist, the app refuses the message and displays (Fig. 4.34) a corresponding message. Figure 4.34: Test ntoursit reading unsupported message type When a message containing two text records has been read, only the first one is stored (Fig. 4.35). This accords the definition. A smartposter message with two text records, followed by URI records affects the application to interpret the second text record as URI record (Fig. 4.36). 101

102 4 Practical Part Figure 4.35: Test ntoursit reading message with two text records Figure 4.36: Test ntoursit reading smartposter message with two text records 102