secure authentication in near field communication based ...862212/fulltext01.pdf · degree project,...

DEGREE PROJECT, IN ELECTRICAL ENGINEERING, SECOND LEVEL

STOCKHOLM, SWEDEN 2015

Secure Authentication in Near Field Communication based Access Control Systems

ANDERS JAKOBSSON

KTH ROYAL INSTITUTE OF TECHNOLOGY

INFORMATION AND COMMUNICATION TECHNOLOGY

Secure Authentication in Near Field

Communication based Access Control Systems

Anders Jakobsson

2015-‐‑06-‐‑10

Examiner Prof. Li-‐‑Rong Zheng

Academic adviser Dr. Zhou Zou

Master of Science Thesis TRITA-‐‑ICT-‐‑EX-‐‑2015:102 School of Information and Communication Technology

KTH Royal Institute of Technology Stockholm, Sweden

Abstract

Today there exist a myriad of different types of access control systems that use a smart card or mobile device as a key. The mobile device enabled smart locks, as they are often referred to, operate using either Wi-‐‑Fi or Bluetooth. This thesis has explored the use of a third emerging wireless technology called Near Field Communication (NFC). NFC technology is a relatively new technology that is on the rise and is included in almost every new mobile device. Using a NFC enabled mobile device, a highly secure access control system was developed on a Raspberry Pi Linux platform. Several different authentication protocols, mobile operating systems and NFC modes of operation where analyzed and evaluated, to ensure that the system was as secure as possible. Eventually the system was implemented using the Secure Remote Password authentication protocol on top of a NFC card emulation scheme with the client application running on the Android operating system. The final system was a secure and responsive system that would be easy to deploy in many different situations. This project shows that NFC enables a mobile device to act as a key in a secure access control system and as the user base for NFC grows larger so will the likelihood that we will come to see more of these types of systems. Keywords: NFC, SRP, Authentication, Android, Raspberry Pi, NXP.

Sammanfattning

Idag finns det flera olika typer av inpasserings system som använder någon form av ”smart card” eller mobil enhet som nyckel. De smarta låsen, som det oftast kallas, som använder sig av en mobile enhet, använder antingen Wi-‐‑Fi eller Bluetooth för att kommunicera med inpasserings systemet. I den här uppsatsen kommer en relativt ny teknologi som kalls Near Field Communication (NFC) att utforskas. Användandet av NFC är på uppgång och det finns inkluderat i nästan varje ny mobil enhet som släpps på marknaden idag. Ett inpasserings system med hög säkerhet utvecklades genom att använda en mobile enhet med NFC kapabilitet tillsammans med en Raspberry Pi Linux plattform. Flera olika typer av autentiserings protokoll, mobila operativsystem och NFC användnings moder, analyserades och utvärderades för att säkerställa att systemet var så säkert som möjligt. Tillslut valdes ett autentiserings protokoll vid namn, Secure Remote Password (SRP), som integrerades ovanpå ett kort emulerings NFC ramverk som finns tillgängligt i Android operativsystemet. Det slutgiltiga systemet har hög säkerhet och är snabbt och responsivt och kan användas i flera olika situationer. NFC tillåter en mobile enhet att agera nyckel i ett inpasseringssystem och användandet kommer bara öka med den expanderande användare basen. Nyckelord: NFC, SRP, Authentication, Android, Raspberry Pi, NXP.

Foreword This master thesis was conducted during the spring of 2015 at the School of Information and Communication Technology, Royal Institute of Technology, Stockholm, Sweden. I would like to thank my supervisor Dr. Zhou Zou for his invaluable help and guidance throughout the work of this thesis. I would also like to express my deepest gratitude to my family and friends for their support and encouragements during the course of this project. Stockholm, 31 May 2015 Anders Jakobsson

Table Of Content 1 Introduction ................................................................................................................ 2 1.1 Goals and Requirements ..................................................................................................................... 4 1.2 Scope and limitations ........................................................................................................................... 4

2 Near Field Communication ........................................................................................... 5 2.1 Standards and protocols ..................................................................................................................... 5 2.2 Modes of operation ................................................................................................................................ 8 2.3 NFC in mobile operating systems .................................................................................................... 9

3 Authentication & Cryptography ................................................................................. 11 3.1 Introduction to authentication ...................................................................................................... 11 3.2 Attack on cryptographic systems ................................................................................................. 11 3.3 Cryptographic basics ......................................................................................................................... 14 3.4 Authentication protocols ................................................................................................................. 15 3.5 Existing Electronic Access Control Systems ............................................................................ 18

4 Analysis ..................................................................................................................... 19 4.1 Mobile devices ...................................................................................................................................... 19 4.2 Modes of operation ............................................................................................................................. 19 4.3 Authentication protocol ................................................................................................................... 20 4.4 Security Analysis .................................................................................................................................. 22 4.5 Cryptographic libraries ..................................................................................................................... 23

5 Implementation ......................................................................................................... 25 5.1 System Overview ................................................................................................................................. 25 5.2 System software components ........................................................................................................ 27 5.3 Android Application ........................................................................................................................... 34 5.4 Development Environment ............................................................................................................. 35

6 Results ....................................................................................................................... 36 6.1 Time measurements ........................................................................................................................... 36 6.2 Number of Users .................................................................................................................................. 37 6.3 System resources ................................................................................................................................. 37 6.4 Physical properties ............................................................................................................................. 38

7 Conclusions ................................................................................................................ 39

8 Discussion .................................................................................................................. 41

9 Future work ............................................................................................................... 43 9.1 Design refactoring ............................................................................................................................... 43 9.2 Internet of Things (IoT) .................................................................................................................... 43 9.3 The Android Application .................................................................................................................. 43 9.4 Device Pairing ....................................................................................................................................... 43 9.5 Security .................................................................................................................................................... 43 9.6 Admin interface .................................................................................................................................... 44

Bibliography .................................................................................................................... 45

List of Tables and Figure Table 1. APDU command packet structure 8 Table 2. APDU response packet structure 8 Table 3. Condensed view of the original SRP exchange 30 Table 4. Optimized one-‐way authentication SRP exchange 31 Table 5. Select command 31 Table 6. Select response 32 Table 7. Challenge command 32 Table 8. Challenge response 32 Table 9. Android HCE application protocol stack 34 Table 10. External library dependencies 35 Figure 1. Graphical system overview 26 Figure 2. Authentication time measurement 36

Master Thesis Anders Jakobsson KTH Spring 2015

2 (47)

1 Introduction This chapter will explain the purpose of the project and why it is an interesting and worthwhile subject to investigate. The project goals and requirements will also be presented along with the project scope and limitations. The year 2004 was an eventful year for the RFID technology Near Field Communication (hereafter NFC). The Finnish mobile giant Nokia developed the first mobile phone equipped with NFC and came together with Samsung and Philips to start the NFC forum. (Fine, Klym, Tavshikar, & Trossen, 2006) (Vanderkay, 2004) (Coskun, Ok, & Ozdenizci, 2012) The same year, ABI research predicted that 50 percent of mobile phones would be NFC-‐‑equipped by 2009. (Swedberg, 2004) However, Nokia is now a former shell of what it once was, and NFC has taken longer time than predicted to reach the general public. The reasons for the slow adoption rate are many, but one major problem has been the lack of infrastructure to support NFC where Bianchin and Nathanson argue that the key for success depends on collaboration between mobile device manufactures, mobile network operators and payment companies (e.g. Visa and MasterCard) among others. (Bianchin & Nathanson, 2008) Now, the adoption rate start to increase and the NFC technology is starting to be incorporated into everything from bus-‐‑fare token systems, concert tickets, secure login applications and much more. (Coskun, Ok, & Ozdenizci, 2012) One can also argue that the launch of the iPhone 6 and Apple Pay in 2014 marked the year that every major mobile device manufacturer incorporated NFC technology in their product lines. (Apple) So despite a slow adoption rate, NFC has yet again started to gain traction; “With 500 million NFC-‐‑enabled devices in the market, NFC is recognized as a key enabler of the connected world.” (NFC Forum, 2014). As mentioned above, NFC can be used in countless number of applications. For a better understanding of the different application areas where an NFC enabled mobile devices is used, these areas are usually divided into three main categories (Haselsteiner & Breitfuß, 2006). For the purpose of this paper a fourth category will also be included: Contactless token -‐‑ Grab information from NFC tags that can be attached to anything from movie posters to grocery store specials. Much like an evolved form of barcode.


3 (47)

Ticketing/Micropayments -‐‑ Used in ticketing systems to validate a purchased ticket or make payments in retail stores by swiping a NFC card or device over a NFC reader. Device pairing -‐‑ This is where NFC is used to pair two devices together and hand over further communication using a higher bandwidth/longer range communication interface i.e. Wi-‐‑Fi or Bluetooth. Secure authentication -‐‑ Makes it possible for two NFC enabled devices to establish a secure communication channel between each other. This can be used to grant access to users in a secure access control systems or when login onto a computer terminal. Given that NFC is more accessible now than ever, new exciting areas of application can be explored. One such area is security and more specifically one of the main categories, secure authentication. Today there exists a myriad of different secure NFC smart cards that can be used as secure tokens in many different kinds of systems. The problem is that the encryption on these smart cards is quite weak with varying degrees of security and is susceptible to different hacks and exploits that have been published over the years. (Garcia, Rossum, Verdult, & Schreur, 2009) These weaknesses will not do for more sensitive systems such as high security entry systems or data exchange systems. This project will focus on secure authentication and explore the benefits of using a NFC enabled mobile device as a secure token in an access control system as opposed to using a NFC smart card. The benefits of using a mobile device as a secure token can be summed up in the following four statements (Ahson & (eds), 2012):

• A user does not have to carry around several cards or tokens for all the different systems it needs to access, everything can be stored on one device. With other words, several authentication systems, one device.

• A user can be remotely granted access to a system through an application on the device. By sending the access credentials through a secure channel over the Internet, the user can then have instantaneous access without having to acquire a physical token.

• A mobile device has far more processing power, which means more computation intensive encryption schemes can be used.

• It can be used in conjunction with other security features on the mobile device such as PIN-‐‑ or biometric-‐‑lock.

This subject matter will be explored in detail in this project, finding out what level of security one could expect from a mobile device based authentication system. Different NFC modes of communication will be discussed as well as cryptographic


4 (47)

authentication protocols that can be used over a NFC communication channel. The end goal is to have a fully functioning proof-‐‑of-‐‑concept secure access control system.

1.1 Goals and Requirements The goal of this project is to evaluate different NFC technologies, mobile devices and cryptographic authentication protocols and see, which best suits the need of a NFC based access control system. This will then be implemented in a proof-‐‑of-‐‑concept application. The authentication system should meet the following requirements,

• The lock should utilize the highest available encryption standards. Effectively making all cryptographic attacks nearly impossible or take an unforeseeable amount of time to break.

• The authentication process should be as fast as possible. Requiring the user to hold the device at the reader for as short a time as possible. A long authentication time is tedious for the user.

• The authentication process requires as little user interaction as possible. The user should not have to interact with applications on the device.

• The lock should not require Internet access. Not being able to access the locked door if the Internet connection is down is not acceptable.

• The lock application should work on as many devices as possible. The system should have as large a user base as possible.

1.2 Scope and limitations This project will be performed within the time frame of a Master thesis project. This means that some features have to be left out. The proof-‐‑of-‐‑concept system will not feature the following:

• The task of pairing a mobile NFC device to the systems is beyond the scope of this project. The user credentials will be entered manually on the mobile device. Device pairing will be discussed as future work.

• The application on the mobile device, will only have the bare minimum functionality to verify the proof-‐‑of-‐‑concept design and will only have the ability to hold user credentials for one access control system (i.e. lock)

• Only one secure authentication protocol will be implemented.


5 (47)

2 Near Field Communication This chapter presents the research conducted during the project, outlining the different NFC protocols, the communication modes and mobile devices NFC capabilities. It also describes what previous work has been done on this subject. NFC is an umbrella term for wireless communication technologies operating in the unregulated 13.56 MHz spectrum at a range of up to 10 cm. It differs from other wireless communication technologies in that it uses inductive coupling instead of radio waves to communicate wirelessly between two devices. An NFC device manipulates the electromagnetic fields in such a way that it can transmit binary data at a very short distance. This inductive coupling makes it possible for a NFC reader to power a low power NFC tag or smart card, thus eliminating the need to have a power source on the NFC tag or smart card. NFC traces its roots back to RFID technology, sharing many of its characteristics. (Coskun, Ok, & Ozdenizci, 2012)

2.1 Standards and protocols NFC is comprised of several standards and communication protocols defined by the ISO and ECMA organizations, the two major ones being ISO-‐‑14443 and ISO-‐‑18092, which are in part compatible with each other. On top of this there are several proprietary implementations like MIFARE developed by NXP and FeliCa developed by Sony. (ISO/IEC, 2008) (ISO/IEC, 2013) The NFC standard specifies two modes of operation and three different transfer speeds for the radio interface. An NFC device could either be active, meaning that it generates its own field or passive meaning that it relies on another device to generate a field and use load (NFC Forum, 2015)modulation to communicate. The Communication speeds are divided into two groups, one low speed and one high speed. The low speed communication is done at a rate of 106 kbps and the high speed is either 212 or 424 kbps. (ISO/IEC, 2013) NFC uses a carrier frequency of 13.56 MHz, with maximum field strength of 7.5 A/m. The communication is modulated with Amplitude Shift Keying (ASK), and has a modulation index between 8 percent and 100 percent. Further, the transmitted data is Manchester encoded, where the Manchester coding acts as a sub carrier for the data and makes the communication more robust. But the bandwidth is sacrificed when using this encoding, effectively cutting the bandwidth in half. This encoding makes the communication stream self-‐‑clocking thus preventing the loss of clock synchronization, or bit errors from low-‐‑frequency drift on poorly equalized analogue links. (ISO/IEC, 2013)


6 (47)

In the case of passive communication, only one device generates a carrier frequency, and all other devices uses load modulation to send data. Load modulation works by shifting the signaling level of the carrier, which is done by grounding the radio circuit thus lowering the signal level. Using this modulation scheme ones and zeros can be transmitted passively on the carrier wave. In the passive communication mode RF power is always on when communicating with targets. (ISO/IEC, 2013) In the active case, NFC works like most other wireless technologies, only keeping RF power on while actively communicating. And shall always, before turning it back on, perform RF collision avoidance. (ISO/IEC, 2013)

2.1.1 ISO 14443 The ISO 14443 standard defines the physical characteristics and transmission protocols for contactless proximity identification cards. The standard consist of four parts, each specifying a layer in the protocol stack, from the physical characteristics of the air interface to the initialization and transmission protocols.

• ISO/IEC 14443-‐‑1:2008 Part 1: Physical characteristics (ISO/IEC, 2008) • ISO/IEC 14443-‐‑2:2010 Part 2: Radio frequency power and signal interface

(ISO/IEC, 2010) • ISO/IEC 14443-‐‑3:2011 Part 3: Initialization and anti-‐‑collision (ISO/IEC, 2011) • ISO/IEC 14443-‐‑4:2008 Part 4: Transmission protocol (ISO/IEC, 2008)

The details of these protocols are out of scope for this project, as it will focus more on the higher-‐‑level communication protocols.

2.1.1.1 MIFARE MIFARE is a proprietary implementation of the ISO 14443 standard developed by NXP, one of the biggest manufacturers of NFC smart cards and transceiver IC. It includes varied selection of NFC smart cards (Classic, Ultralight, DESFire) that has a wide range of applications. (Coskun, Ok, & Ozdenizci, 2012) The MIFARE smart card extends the functionality of ISO 14443 by adding security. MIFARE features different kinds of advanced cryptographic methods, from the basic Single DES through triple DES up to AES. Only the most advanced MIFARE smart cards have the ability to authenticate via AES authentication, a very secure pre shared key (PSK) authentication method that belongs to the symmetric key class of cryptographic ciphers. (MIFARE, 2015)

2.1.2 ISO 18092 Also know as NFCIP (NFC Interface & Protocol), is the standard often referred to when talking about NFC in mobile devices. It is based on in part and is compatible


7 (47)

with the ISO 14443 standard. The NFCIP standard is the basis for the peer-‐‑to-‐‑peer data exchange protocols, commonly associated with data sharing between two NFC devices, for example contact information or an URL. (Coskun, Ok, & Ozdenizci, 2012) (ISO/IEC, 2013) The ISO 18092 standard specifies the radio interface and low-‐‑level communication protocols. Corresponding to the two lowest levels in the OSI model, the physical layer where electrical characteristics and modulation is specified and the data link layer where the frame formats and error correction schemes are specified. (Coskun, Ok, & Ozdenizci, 2012) (ISO/IEC, 2013) To get any usefulness out of a NFC system, higher-‐‑level protocols must be used for communication. If a larger text file is to be sent, it has to be fragmented into NFC protocol data unit frame sized chunks and sent one frame at a time. It has to contain information on when a file begins and when it ends, how many fragments of data there is and which fragment in order is being transmitted. These protocols are not specified in the ISO standard, and that is why the NFC Forum specified additional high-‐‑level protocols that work on top of the ISO 18092 standard. (NFC Forum, 2015)

2.1.2.1 Logical Link Layer Protocol (LLCP) The LLCP is a compact protocol that supports peer-‐‑to-‐‑peer bi-‐‑directional communication between two NFC enabled mobile devices. It is designed to support small applications such as transferring smaller files. The LLCP is designed as an OSI layer 2 protocol, which rests on top of the layer provided by the ISO 18092 protocol. The LLCP can be extended with TCP/IP protocol to further increase the robustness of the communication channel between devices. The specification defines two types of services, connectionless and connection-‐‑oriented. The connectionless service offers minimal setup with no reliability or flow-‐‑control guarantees, this have to be implemented by higher layer protocols if needed. The second service type is the connection-‐‑oriented service, which adds flow control, in-‐‑order reliable delivery and session-‐‑based service layer multiplexing. (NFC Forum, 2015)

2.1.2.2 Simple NDEF Exchange Protocol (SNEP) The SNEP standard was developed by the NFC Forum, and is used for small messages sent between two NFC devices. This protocol allows an application on an NFC enabled device to exchange NFC Data Exchange Format (NDEF) messages with another NFC device when operating in peer-‐‑to-‐‑peer mode. The protocol makes use of the LLCP connection-‐‑oriented transport mode to provide a reliable data exchange. (NFC Forum, 2015)


8 (47)

2.1.3 ISO 7816-‐‑4 The ISO 7816-‐‑4 also known as Interindustry Commands for Interchange protocol is not a NFC standard per se, but a standard that defines the high-‐‑level protocol commands for many kinds of smart cards like ATM or SIM cards. The MIFARE range of cards along with other NFC smart cards also utilizes this high level protocol defined by the standard. It is also used by the Host Card Emulation implementation in Android. The ISO 7816-‐‑4 protocol is a request/response protocol, with one master and one slave, exchanging messages of the Application Protocol Data Units (APDU) message format that is specified by the standard. The ISO 7816-‐‑4 protocol specifies two different message types, the command APDU message and response APDU message. (ISO/IEC, 2013) The command APDU message structure is quite simple as seen in Table 1. It features a header with four values, which define what type instruction the message contains, and a body consisting of a data payload of a given length. (ISO/IEC, 2013)

Table 1. APDU command packet structure

Code Name Length Description

CLA Class 1 Class of instruction INS Instruction 1 Instruction code P1 Parameter 1 1 Instruction parameter 1 P1 Parameter 1 1 Instruction parameter 1 Lc Length 1 or 3 Number of bytes present in the data field of the command Data Data Lc String of bytes sent in the data field of the command

Le Length 1 or 3 Maximum number of bytes expected in the data field of the response to the command

The response APDU message structure is even simpler, only containing a message body with data payload and a trailer consisting of 2 bytes status code. The message structure can be seen in Table 2. (ISO/IEC, 2013)

Table 2. APDU response packet structure

Code Name Length Description

Data Data Lr String of bytes received in the data field of the response SW1 Status byte 1 1 Command processing status SW2 Status byte 2 1 Command processing qualifier

2.2 Modes of operation We will have a closer look at the different communication modes that are supported by NFC, reader/writer, peer-‐‑to-‐‑peer and card emulation. How they are used and what characteristics each of them have.


9 (47)

2.2.1 Reader/Writer mode Reader/Writer mode is the most basic form of communication, used to read from or write to a NFC tag or NFC smart card. This is used in smart posters or tollbooths ticketing system. This is supported by the ISO 14443 standard and in extension the Mifare and FeliCa standards. (Coskun, Ok, & Ozdenizci, 2012)

2.2.2 Peer-‐‑to-‐‑peer mode In peer-‐‑to-‐‑peer mode, two NFC devices can share data between them. This could be anything from digital business cards to setup parameters for Bluetooth communication. The peer-‐‑to-‐‑peer functionality is implemented through the use of the LLCP and SNEP protocols that build on top of the ISO 18092 standard. (Coskun, Ok, & Ozdenizci, 2012)

2.2.3 Card emulation Card emulation is a further development of the reader/writer mode, allowing a NFC enabled mobile device to emulate a NFC smart card. The external reader will not notice any difference. This enables the NFC device to be used in contactless payment or ticketing systems without needing to change the existing infrastructure. The card emulation mode is a very versatile communication mode, but one drawback is that it requires a secure element to function. A secure element is a closed encrypted chip located outside of the operating system usually on the SIM-‐‑card supplied by the network operators. All traffic being sent and received over the NFC channel in card emulation mode will be routed via the secure element that handles encryption/decryption and authentication. Access to this secure element is very restricted and only available to the network operators or banking system vendors. (Coskun, Ok, & Ozdenizci, 2012) (Android Developers)

2.3 NFC in mobile operating systems The implementation of a secure access control system relies heavily on the mobile phone operating system and their support of NFC and the different reader modes. In this section we will have a closer look at the three major operating systems for mobile devices and their support of NFC and the different modes of communication.

2.3.1 Android Android has long been supporting NFC ever since version 2.3 (Gingerbread) of the operating system. Combine that with the plethora of available Android smart phones that incorporate NFC and Android is a cutting edge operating system for NFC development. Android supports all three operating modes, reader/writer, peer-‐‑to-‐‑peer, card emulation. (Android Developer)


10 (47)

An Android device can be used as a NFC reader/writer when running the phone in the reader/writer operating mode. This is used for reading/writing to/from NFC tags and other NFC smart cards. (Android Developer) Peer-‐‑to-‐‑peer mode on Android is called Android Beam, and is used for sending NFC data exchange format (NDEF) messages between two NFC devices. This communication is one directional, only passes a single NDEF messages per session before disconnecting the NFC channel. Usually used for sending small messages or other information in a neat and presentable manner. (Android Developer) The card emulation mode is, as stated previously, a very versatile communication mode with the drawback of requiring a secure element. But as of Android 4.4, a new type of card emulation was added called Host Card Emulation (HCE), which enables an Android device to operate as a NFC smart card without the need of a secure element. This enables third party developers to start utilizing the potential of card emulation for advanced NFC applications. It is implemented as an Android service, which is a background service that is called when an incoming APDU selected commands is received by the operating system. The operating system knows which service to call by looking at the Application Identifier (AID) included in the select command. Each HCE service registers a unique AID number in the operating system. (Android Developers)

2.3.2 iOS Apple has included support for NFC in its latest iPhone models, iPhone 6 and iPhone 6 Plus. Unfortunately the NFC API is closed to third party developers and thus no NFC applications can be developed for iOS. Although this might change as Apple has done the same with new technology in the past, where they later decide to release the API to developers. (Hein, 2014)

2.3.3 Windows Phone Windows phone has two types of NFC operating modes, Wallet platform and Proximity platform. The Wallet platform is a card emulation mode, which enables the device to mimic a NFC card using secure element. This platform is used, as the name implies, for contactless payments. (Microsoft, 2015) The proximity platform is an implementation of the NFC peer-‐‑to-‐‑peer mode, used for sending messages and picture via NDEF messages between two NFC devices. (Microsoft, 2015)


11 (47)

3 Authentication & Cryptography In this chapter we will explore the different cryptographic systems and authentication methods that can be used in a NFC based access control system. It goes without saying that this is the most vital part of the system, as a failure here will render the whole system completely useless. Cryptography is a very complex subject and relies heavily on advanced mathematical concepts, some of which are beyond the scope of this thesis report. The methods and concepts will be sufficiently explained so the reader will get a good understanding for the subject mater at hand.

3.1 Introduction to authentication To authenticate that a client or server is who they really claim to be, is no easy task. So how would one go about doing this authentication? All types of human authentication can be divided into three categories (FFIEC, 2001):

• The user is something (biometrics, fingerprint, voice, etc.) • The user has something (token, ID card, smart card) • The user knows something (Password, PIN, etc.)

All three can be used in an electronic access control system. They can also be combined for increased security, commonly referred to as two-‐‑factor authentication. (FFIEC, 2001) In this project the focus will be on the last paragraph, that the user knows something, like a password.

3.2 Attack on cryptographic systems Any cryptographic system is susceptible to attacks from third parties wanting to (Haselsteiner & Breitfuß, 2006):

• Disrupt or interfere with the communication between server and client. • Gain unauthorized access to a system or location. • Obtain classified information.

There are many different attack that can be performed on a cryptographic authentication system using a communication channel that is transmitting through the air. Lets us explore these different attacks that a security system must sustain, before delving deep into the different cryptographic protocols.

3.2.1 Eavesdropping A malicious attacker can listen in on the communication between client and server. This is the most basic form of attack and is very easy to deploy, the good thing is that


12 (47)

it is also easy to counter act. By encrypting the communication between client and server the attacker will not be able to obtain any useful information. (Haselsteiner & Breitfuß, 2006)

3.2.2 Offline attack This attack is typically used in conjunction with an eavesdrop attack, where the attacker eavesdrops on the messages exchanged between the two parties and then runs an offline attack on the encrypted messages to try to break the encryption. These attacks can employ a wide range of techniques, where the most basic technique is the brute force attack, where every possible combination of crypto key is tried to unlock the message. Another variant is the dictionary attack, where the attacker tries crypto keys from a dictionary of commonly used key values. A more sophisticated technique is the use of rainbow tables, these rainbow tables are pre-‐‑computed tables of password hashes for a finite amount of passwords using a given limited character set. Rainbow tables shift the space-‐‑time correlation of the brute force attack, by trading processing time for storage space. Rainbow tables require huge amount of storage, as they can grow very large. (Oechslin, 2003)

3.2.3 Data Corruption This is when an attacker is corrupting or disturbing the communication channel between client and servers, making communication impossible, which is commonly known as a Denial of Service attack. It has fast become one of the most common forms of attacks on the Internet and is very hard to guard against. The attacker does not gain any information but it will make it hard for the clients to use the server. (Haselsteiner & Breitfuß, 2006)

3.2.4 Data Modification In this scenario the attacker tries to modify the data passed between client and server in such away that it may gain access to the server. A cryptographic authentication protocol must be able to either sense that someone is trying to manipulate the data that it receives or not be susceptible to this form of attack. (Haselsteiner & Breitfuß, 2006)

3.2.5 Data Insertions This is another form of data manipulation where an attacker inserts data at precise instances, thereby authenticating itself to the server instead of the client. (Haselsteiner & Breitfuß, 2006)

3.2.6 Man-‐‑in-‐‑the-‐‑middle Commonly referred to as MiTM, is when an attacker tries to impersonate the server and tricking the client to send its user credentials to what the client thinks is the server. The communication channel can be as secure as anything, but if the other


13 (47)

party is not whom the client thinks it is, it does not matter. (Haselsteiner & Breitfuß, 2006)

3.2.7 Replay An attacker can record the messages being sent between client and server during the authentication handshake, and then “replay” i.e. send the exact same messages to the server. To guard against such an attack, it is important that the authentication protocol has a random part, usually this is done using a unique session token, making the messages used in different authentication sessions unique, i.e. the exact same message will never be sent again. (Aura, 1997)

3.2.8 Relay In the relay attack, a malicious third party uses an intermediary medium to physically connect two parties. By creating an artificial bridge between, between two device making it appear as if they are in close proximity of each other, when in reality they can be miles away. The attacker employs two relay devices that can seamlessly relay the traffic between the two parties without them even knowing it. A device is placed at each end of the bridge and the attacker can initiate a secure authentication session between for example a NFC smart card and a secure access control system, by holding the relay device close to a unsuspecting victims pocket and initiate the authentication session with the access reader at the other end of the bridge. This could possible lead access being granted to the unsuspecting victim, that is currently miles away from the system. This sophisticated attack has been proven effective against NFC enabled devices. (Francis, Hancke, Mayes, & Markantonakis, 2012)

3.2.9 Side-‐‑channel The side-‐‑channel attack is a very sophisticated attack where the attacker records physical parameters and characteristics of the target system. These parameters could be miniscule fluctuation in power drawn by the CPU during decryption, signal crosstalk from system busses or measuring the time it takes the system to perform a specific task. Basically any measurable information leaking out of a side-‐‑channel, hence the name, could glean some clues as to what the system is doing and how it is doing it, for example during sensitive operations such as decrypting/encrypting. The system must be designed in such a way that makes these attacks very hard to perform or rather, makes the information obtained from these attacks useless. This is usually done by not running the exact same pattern every time the system decrypt/encrypt a message, because if the system is to consistent executing the exact same processor instructions every time a cryptographic function is run, then the attacker could gather information from this and exploit any weakness found. (Zhou & Feng, 2005)


14 (47)

3.3 Cryptographic basics To understand the contents of the next chapters it is good to have some basic knowledge about cryptography. Why this section will briefly explain some core concepts in cryptography that are good to know when reading further.

3.3.1 Symmetric cryptography This is the classic definition of encryption, where two parties share a common secret key. When one party wants to send a secret message to the other party it uses the common secret key to encrypt the message, which can later be decrypted by the other party when it is received. (Delfs & Knebl, 2007)

3.3.2 Asymmetric cryptography Public key algorithms are based on hard to solve mathematical problems that have no known efficient solutions. One such mathematical problem is prime number factorization, which is very hard to do. Take two very large prime numbers that are multiplied together and produce a product. Given that multiplication product find the two original prime numbers by factoring the product, the only known way to do this is try every single combination, a very processor intensive task. This is the core principle behind many of the existing public key algorithms, such as Diffie-‐‑Hellman and RSA. (Delfs & Knebl, 2007) In recent years, as the available computational power increases exponentially, so do the need to use larger and larger prime numbers to guarantee security. (Moore, 1965) The recommendation today is to use 4096-‐‑bit prime numbers, but as the key sizes increases so does the computational power used by the client and server, as will the size of messages passed between client and server, which will make handshaking more and more cumbersome. To overcome this need of ever-‐‑larger key sizes, new mathematical problems have been introduced, that does not require large key sizes but still remains equally secure. One such new category of mathematical problems is the elliptic curve problem, or more precisely the elliptic curve discrete logarithm problem, where an elliptic curve with a set of starting points are used to make a traversal of the curve in an arbitrary amount of rounds. This traversal is very hard and computationally intensive to reverse. (Delfs & Knebl, 2007)

3.3.3 Zero Knowledge Proof In cryptography zero knowledge proof is when one party (the prover) proves to the other party (the verifier) that it knows a shared secret and this proof is done without divulging any information about the shared secret. This can be achieved by having the verifier issue challenges in an arbitrary amount of rounds that if answered correctly shows that the prover has to knowledge of the secret with a very high probability. (Goldwasser, Micali, & Rackoff, 1989) (Schneier, 1996)


15 (47)

3.3.4 Forward secrecy When talking about forward secrecy in cryptography it means that if an encrypted message sent between two parties is intercepted and brute force decrypted by a malicious attacker. Then the key that was found during the brute force attack cannot be used on future messages between the two communicating parties. This is a sought after property for a cryptographic system to have. (Diffie, van Oorschot, & Wiener, 1992)

3.3.5 Entropy Entropy is a very important characteristic in cryptography when it comes to defining password strength. One could say that entropy defines how hard a password or random key is to guess. The entropy of a simple password like `cat` is very low and easy to guess. The entropy for a long random string is on the other hand very high, and takes a long time to break through brute force techniques. (Schneier, 1996) Entropy is also vital when generating a random number using a computer. Computers cannot generate true random numbers, and have to settle for pseudo random numbers. These pseudo random numbers are generated using a random function that takes a seed, to start the generation. This seeds needs to be of high entropy, else an attacker could easily guess the seed and run the same random function. Computers can not just rely on using the current time stamp and use that as a seed for the random function, a time stamp has terrible entropy on its own, therefore several different system parameters are collected to construct a high entropy seed that can be used in the random function and in extension in a cryptographic system. (Schneier, 1996)

3.4 Authentication protocols There are a many number of authentication protocols that can be used in an access control system, here is a closer look at the most widely used protocols.

3.4.1 Public Key Cryptography Public key cryptography is a widely used cryptographic scheme used on the Internet. It enables a user to establish a secure communication channel to a server over an insecure public network. It relies on the use of asymmetric keys and a certificate authority to establish a secure channel where the user can pass its credentials to authenticate. The asymmetric keys are made up of one public key that is used by anyone who wish to encrypt or sign a message and send to the server and a private key that is kept secret and used to decrypt a message or verify a signature. The most widely used standard associated with PKI is the X.509 standard. (Delfs & Knebl, 2007)

3.4.2 Secure Shell (SSH) SSH authentication is used to establish a secure connection between client and server, the client can then pass on user credentials over this secure connection to


16 (47)

authenticate against the server. SSH can use either public key authentication or password authentication. In the SSH public key authentication scheme the user have to generate a public/private key pair. The private key is kept hidden by the user while the public key is stored on the server. It has some vulnerabilities, which is the private key stored on the client side, which could be compromised or stolen and use by an attacker to gain access to the server. (Ylonen, 2006) SSH password authentication is the second option when using SSH authentication. It establishes an encrypted channel and then sends the plaintext password to the server for authentication. The first time a user connects to the server, it will receive the server’s public host key. This key is not signed and is tied to the hostname or IP address of the server. If the server gets a new IP address the host key changes, and need to be sent to the clients again. This will display a warning on the client side, warning about the changed host key and that there might be a risk for a MiTM attack. (Ylonen, 2006)

3.4.3 Kerberos Kerberos is commonly used in enterprise class systems to securely communicate between nodes on an unsecure network. It operates on a client/server model and requires an external Kerberos authentication server. When a client logs on to the network it first has to authenticate against an authentication server that issues a time stamped ticket, which it encrypts with the clients password and sent back to the client. When the client wants to securely access a service on the network it will send its ticket to a ticket-‐‑granting service, which will check if the ticket is valid and that the client has the correct privileges to access the requested service. If the request is granted the ticket-‐‑granting service will return a ticket along with a session key. The client can then send this ticket and session key to the service it wants to access. (Ylonen, 2006) (Cisco, 2006)

3.4.4 Pre Shared Key (PSK) Pre shared key authentication is a pretty simple yet very secure form of authentication protocol. It relies on a symmetric encryption scheme, i.e. encryption/decryption is performed using the same key. It uses this pre-‐‑shared key to encrypt a message containing a user'ʹs credentials together with some random elements, which it sends to the server. The server, using the same key, decrypts the received message. The server then generates its own random elements and concatenates that with the message received from the user and sends it back. This gives a mutual authentication between user and server. There are many different types of encryption schemes that can be used in PSK authentication DES, BlowFish and AES are some of the more notable. Where AES is the de facto standard for secure


17 (47)

encryption today, and key length range from 128-‐‑bits to 256-‐‑bits. AES encryption is regarded as far the most secure encryption scheme, with no known attacks that are computationally feasible. (Delfs & Knebl, 2007)

3.4.5 Password-‐‑authenticated key agreement (PAKE) This is a group of authentication methods that lets two or more parties establish a cryptographic key using an exchange of messages. This method is based only on their knowledge of a shared password and an eavesdropper cannot gain any valuable information while engaging in the message exchange and is constrained as much as possible from brute force guessing the password. There are two main categories of Password-‐‑authenticated key agreement, Balanced PAKE and Augmented PAKE. In the Balanced PAKE a client and sever can negotiate and authenticate a shared key using the knowledge of a shared password. The Augmented PAKE works in a similar fashion as the balanced version but improves on the balanced version, as it does not need to store the password-‐‑equivalent data on the server, instead it only requires a password verifier to be stored. This makes the system more robust even if the server is compromised and the verifier data is stolen. It cannot be directly used by the attacker without first performing a brute force search for the password. The most interesting implementation of an Augmented PAKE cryptographic system is the Secure Remote Password authentication protocol. (Wu, 1998)

3.4.5.1 Secure Remote Password (SRP) SRP belong to the Augmented PAKE family of password authentication protocols and was created by Thomas Wu, Stanford University in 1996. When authentication is performed using the SRP protocol, the client never reveals the actual password to the server. Instead the client proves the knowledge of the password through an ingenious protocol exchange. The server only stores a password verifier and not the actual user password, a verifier is like a one-‐‑way hash of the password. This makes the password reasonably secure even if the server is compromised and a malicious attacker get access to the verifier, it has to be found by brute force. The exchange between client and server is also protected from eavesdroppers by no useful information is actually transmitted. (Wu, 1998) The SRP protocol is a mutual authentication protocol. In the original version of the SRP protocol there was six rounds of information exchange between client and server. This has been revised in later revisions to only require three rounds of exchange, by changing the order in which certain parameters are calculated and grouping them together. If not mutual authentication is required, i.e. only the user proves that it knows the password, then it can be reduced further to two rounds. It shares a lot of similarities with Diffie-‐‑Hellman asymmetric key cryptography. SRP is a hybrid between pre shared key and asymmetric key cryptography. The key needs


18 (47)

to be shared between the authenticating parties ahead of time. But the actual authentication uses a Diffie-‐‑Hellman style key exchange. (Wu, 1998)

3.5 Existing Electronic Access Control Systems Let us have a closer look at the existing types of electronic access control systems that employ a wireless interface. There exists quite a few different wireless access control systems and they can be divided into two main categories. A token-‐‑based access control system, which uses a NFC smart card or tag as a key, is the first category. The second category is sometimes referred to as Smart locks, here the user can unlock the door by using a mobile device.

3.5.1 Token based Access Control Systems The first category is those systems that use a physical token, like a smart card or tag to authenticate the user. These systems have been around for quite some time and are commonplace at office buildings, hotels and larger residential building. The most basic of these systems stores the tag ID number in a database and when the user presents its tag to the reader, the ID is read and the access if granted if the ID is valid. This is not very secure, as a malicious attacker can eavesdrop on the ID and program that ID into a new tag. These systems can be made secure using the newer versions of smart cards for instance MIFARE DESFire range of cards. These cards are what you might call “smart” as they have a microprocessor and a couple of Kbytes of storage space, where they can store one or more private key. They use an AES pre shared key cryptographic scheme to authenticate the card. These locks are what one might consider out dated, as they require a physical token.

3.5.2 Smart locks Smart locks are a new class of access control systems that have emerged in the last couple of years. Many of the major lock manufacturers have started to focus its R&D to develop these types of system, among them manufacturers like ASSA ABLOY and Yale. The smart locks typically use the short-‐‑to-‐‑medium length wireless technologies Bluetooth or Wi-‐‑Fi, to communicate with a mobile device, which holds the key. They usual employ one of the authentication schemes presented in this chapter, most common is the PKI scheme, which authenticates the user through an online certificate authority. These Smart locks are feature rich with advanced supervision that sends a message to the owner if it detects abnormalities. Other features include time-‐‑restricted access or granting access instantaneously even tough the owner is miles away. The popularity of these type of locks will probably increase in the near future as more and more people, see the convenience they and plethora of features they bring. At the time of writing none of these new generation smart locks employ NFC as communication medium. Using NFC is not only a very fast and reliable, but inherently safer option to use as the usage distance is very limited.


19 (47)

4 Analysis This chapter will analyze which mobile device, mode of operation, authentication protocol and cryptographic library that will best suit and fulfill the requirements and goals presented in chapter 1. It will also analyze different attack vectors and if they are valid for this system.

4.1 Mobile devices When choosing the mobile device to use in the proof of concept system several factors have to be taken into consideration.

• Are there any NFC enabled devices for the OS? • How open is the OS when it comes to API access, documentation and source

code? • How large is the potential user base? • Which modes of operations does the OS support?

Apple’s iOS and Microsoft’s Windows Phone have a long way to go, both in regards to functionality and openness. The iOS operating system is completely closed for third party developers, disqualifying it as a viable choice in this project. Windows Phone on the other hand is a competitor to Android, but it loses to Android'ʹs richer NFC library API and shear size, Android having a market share of 81.5 percent for the year 2014, according to IDC, compared with Windows Phone’s 2.8 percent. (IDC, 2015) Android stands out when it comes to NFC functionality. Developers have full access to all APIs regarding NFC. Android is also open source why all libraries and APIs are available for review, which can be very helpful during development where library features are sometimes poorly documented. Android has by far the most mature NFC libraries and widest array of NFC enabled devices supporting all modes of operation, it will be used as the client side mobile device operating system.

4.2 Modes of operation Most secure authentication protocols require the server and client to exchange several request/response messages during the authentication process. This means that the communication has to be bidirectional i.e. both the server and client have to be able to both send and receive messages during one session. The transfer speed is also important, as lower speeds translates into longer authentication times. At first the peer-‐‑to-‐‑peer mode (ISO 18092) together with the protocols (LLCP & SNEP) defined by the NFC Forum seems like the best choice. According to the


20 (47)

standard documentation it supports both bidirectional communication and high transfer speeds. Unfortunately the peer-‐‑to-‐‑peer implementation on Android, known as Android Beam, is lacking in this area. It only supports sending one NDEF protocol message one-‐‑way before it disconnects the session and the devices involved has to be physically separated from each other before a new session can begin. This makes it only suitable for sending smaller one-‐‑way messages, like contact information or URLs. The reason behind this is unclear. The most probable cause could be security concerns. Another explanation could be that Google wants to make it harder for third party developers to develop NFC enabled applications, for instance a payment application. The only real option when wanting bidirectional NFC communication when using an Android device is to make the device emulate an NFC smart card. Android has the ability to emulate a NFC smart card by using the Host Card Emulation (HCE) Framework as presented in chapter 2.3.1. From the reader’s perspective it will communicate with the Android device as if it where an ordinary NFC card or tag, using exactly the same protocols and parameters. This will enabled a bidirectional, half duplex communication channel, well suited for authentication protocol message exchange.

4.3 Authentication protocol When choosing an authentication protocol for the access control system, naturally the system requirement has a huge impact on the selected protocol. Below the different authentication protocols will be evaluated with regards to the requirements.

4.3.1 PKI This is the most widely used authentication protocol on the Internet and could be a usable protocol here as well. It is very secure, especially when using one of the newer Elliptic Curve asymmetric keys. Unfortunately the PKI protocol has two major drawbacks that make it incompatible with the system requirements. The first one is that it requires access to the Internet, it has to be able to verify the servers and/or users certificate using a third party certificate authority that will verify the authenticity of the certificate. The second draw back is, that it costs money to register the certificate with a certificate authority. Self-‐‑signed certificates can be used, but that defeats the purpose of using PKI in the first place. Since you have no way of knowing if the signed certificate is sign by the server or a malicious attacker.

4.3.2 Kerberos Not really an option in this system. It requires many external system components and is not a good fit for a lightweight, standalone access control system. It also needs all connected systems to have a precisely synchronized time, which requires a


21 (47)

Network Time Protocol Servers or similar, which further increases the complexity and number of required systems.

4.3.3 SSH Since the certificate is not signed, a MiTM attack is very easy to perform. If the user does not heed the warning about possible MiTM attacks, it will send its plain text password to the attacker.

4.3.4 Pre Shared Key AES keys are typically between 128-‐‑bit and 256-‐‑bit long, depending on the required security level. The server and client need to exchange this secret key in order to communicate securely over an open network. This is not a trivial task, the server and client has to be at the same physical location exchanging the keys in a manner that no one can eavesdrop and gain access to the key. Once the key has been exchanged it has to be kept hidden, which poses the second problem with PSK; how to securely store AES keys? They are nearly impossible for a human to memorize, since they consist of a random string of 32 bytes. This means that they have to be stored locally on a mobile device, which make them susceptible to theft or other malicious attacks. This limits the usefulness of the PSK authentication protocol, even though it is very secure.

4.3.5 SRP SRP is a strong password authentication protocol that is starting to gain considerable attention in both the open source community and in commercial products. SRP does not require an Internet connection, and its protocol is very lightweight comparing to some of the others that have been evaluated. The SRP protocol does not expose passwords to either passive or active network intruders, making it impossible for an eavesdropper to gain knowledge about the secret password. The passwords are also stored as a one-‐‑way hash on the server, making it resilient even if the server is compromised. It is secure even when using low entropy passwords, thanks to the salt that is added when creating the SRP verifier.

With SRP one can weighting convenience vs. security, effectively choosing the level of security a particular system needs. By forcing the user to enter the password in every authentication session, one gets a very high level of security with SRP. On the other hand, the password can be entered once and stored on the device for future use. Then the level of security will drop significantly since the plaintext password is only protected by the device'ʹs PIN code. This level of flexibility is not given in the other PSK protocols that use a long random key with a length of at least 128 bits, making it nearly impossible for a user to memorize.


22 (47)

4.4 Security Analysis From the authentication protocol analysis in the previous chapter, the choice was between using PSK and SRP, they are similar in some sense, and they both fulfill the requirements,

• They are both very secure and lightweight protocols. • They both use a shared secret that needs to be shared between server and

client before authentication can be performed. • They do not require any Internet access.

In the end the SRP protocol is the one that best fulfills the system requirements. It’s ability to use memorizable low entropy passwords favored the SRP protocol over PSK which uses long random password strings. SRP will therefore be used as authentication protocol in the proof-‐‑of-‐‑concept implementation. Let us have a look at how susceptible the SRP protocol is to different cryptographic attacks. Some experts argue that the attack vectors on a NFC system are very limited due to the closely coupled nature of NFC, where the communication range is less than 10 cm. This attitude towards security in NFC could be dangerous, and lead the system designers to neglect certain situations and thereby creating security holes. Eavesdropping – SRP has been designed to counter the threat of password sniffing, as well as preventing a determined attacker equipped with a dictionary of passwords from guessing at passwords using captured network traffic. Offline attack – The SRP protocol allows the server to store passwords in a form that is not directly useful to an attacker. Even if the servers’ password database were publicly revealed, the attacker would still need an expensive dictionary search or brute force search to obtain any passwords. The exponential computation required to validate a guess in this case is much more time-‐‑consuming than the hash currently used by most UNIX systems. Data Corruption – A denial-‐‑of-‐‑service attack is hard to fend against, and this system will be no different. An attacker could always, corrupt the communication, and make the system unusable, though it is not a threat to the integrity of the system. Data Modification – The SRP protocol resists active network attacks such as data modification attacks. It would not help the attacker in any way to modify the contents of the exchanged protocol messages.


23 (47)

Data Insertions – Likewise it is not affected by precisely timed data insertions. This attack does not really make sense as the attacker would have to be standing next to the victim, who will probably notice the stranger standing close by, trying to gain access. Man-‐‑in-‐‑The-‐‑Middle – a MiTM attack does not really make sense as the communication range is very short. There might be situations where this is possible but a correctly implemented SRP protocol should not be susceptible to this kind of attack. Even if someone tries to pose as a Server trying to steal the password, no actual password information is ever passed from the client to the server. Replay – Mounting a replay attack on a SRP authentication system would not be possible, since the protocol uses random elements that are unique to each session. Therefore using the messages from a previous session would not be possible. Relay – The SRP protocol has no built-‐‑in guards against a relay attack, which means that the system could be susceptible to such an attack. This has to be considered when designing the system. Side-‐‑channel – A side-‐‑channel attack I very hard to guard against. But the attacker needs a to have complete access to the system to be able to study it in detail.

4.5 Cryptographic libraries When designing a cryptographic system, one needs to either develop a custom cryptographic functions and libraries or select an existing one. Designing a custom cryptographic library is never recommended unless you know exactly what you are doing, why a pre-‐‑existing cryptographic library has to be found. Cryptographic libraries are design by mathematical experts and peer reviewed by a large community of knowledgeable professionals, making them highly reliable and less prone to bugs or severe security holes. With this being said, there exists a large number of libraries that support a wide range of platforms, so selecting one is not the easiest task. The library or libraries used in this project has to have support for the chosen authentication method, in our case the SRP protocol. There are quite a few libraries that implement the SRP protocol. However the problem is that it has to be able to be supported on both ARM/Linux and Android, as this is the best situation which is less prone to errors as opposed to using two separate implementation of the protocol and having them work together.


24 (47)

The de facto standard cryptographic library used in Linux is the OpenSSL library, which supports a wide array of authentication methods and cryptographic protocols. It also has one of the largest user bases of all the libraries. Unfortunately Android does not support the SRP protocol out of the box, so a third-‐‑party solution has to be found. OpenSSL could be used here too, as Android is also a Linux distribution. The downside to this, is having to develop using the native development kit in C/C++ and making an API that can be called from the Java code, which the rest of the application is written in. This would add too much complexity to the application, making it harder to manage. An alternative third-‐‑party cryptographic library has to be found. If we instead start on the Java end of the spectrum there exist a widely used cryptographic library by the name Bouncy Castle. This library has support for SRP and is implemented in Java. As it happens there also exists an Android port of this library called Spongy Castle. It matches all the criteria this system has perfectly, so now the OpenSSL implementation of SRP has to be made working with the Spongy Castle implementation of the protocol, which could prove a challenge, due to the complex nature of cryptographic libraries and its protocols.


25 (47)

5 Implementation This chapter will describe and explain how the different parts of the system were implemented in accordance with the conclusions drawn during the analysis. The implementation description should be so detailed that someone could reproduce the system as a whole.

5.1 System Overview The proof of concept system was designed as a self managed system. Requiring no external systems or other supporting infrastructure, hosting all required functionality, such as authentication control, system administration interface and databases internally on the device. The reason for this is that the proof-‐‑of-‐‑concept system should work in a stand-‐‑alone configuration, which makes it easier to evaluate and demonstrate. To realize this self managed system a Raspberry Pi B+ was chosen, because of its low price, high performance, relatively small footprint and high number of third party peripherals. It features a Broadcom ARM11 CPU clocked at 700 MHz, 512 MB DDR2 RAM and flash based SD-‐‑card storage. The Raspberry Pi has a long list of peripherals that one might need to realize many different kinds of systems. HDMI, USB, SPI, I2C, Audio, GPIO, the list goes on. For this project it has all the necessary features except an NFC transceiver. But this is where the Raspberry Pi truly shines, when it comes to extendibility. It has a whole host of third party manufacturers making many different extension boards, or shields as they are known in the Raspberry Pi community. One of these extension boards is the Explore NFC extension board from NXP. It hosts a NXP PN512 NFC transceiver chip, capable of handling all major NFC protocols, ISO 14443, ISO 18092, Mifare and FeliCa at the highest speed ratings. The Explore NFC board also offers an integrated on circuit board antenna and the selection of using either SPI or I2C communication bus. It is connected to the Raspberry Pi through the 40 pins GPIO connector. The locking mechanism used in the proof of concept is an electric strike lock. It is operated by an electromagnetic coil, which when powered by a 12V 600mA current will release the locking bracket, letting the door lock bolt run free. To control the electric strike lock from the Raspberry Pi a relay is used which is connected to the 12V power source and one of the GPIO outputs on the Raspberry Pi. On the client side a LG Nexus 5 Android device was chosen because of its NFC capabilities. It features all available NFC modes of operation, and specifically Host


26 (47)

Card Emulation, which will be used in this project. This makes the Nexus 5 a good counterpart to the Raspberry Pi based reader. Since the Raspberry Pi is quite a powerful microcomputer, it is well suited to run an advanced operating system like Linux. There are many benefit of using Linux over other embedded operating systems, such as advanced memory management, a great multitasking scheduler and a plethora of supported peripherals through a large collection of device drivers. Not to mention the rich community surrounding Linux and it is open source. The Raspberry Pi is supported by a custom Linux distribution called Raspian, which is a port of the widely used Debian Linux distribution. The core software running on the Raspberry Pi is a Linux user-‐‑space daemon written in C. Its main responsibilities are the NFC communication with the client as well as the client authentication. It employs the SRP protocol from the OpenSSL cryptographic library.

Figure 1. Graphical system overview

The protocol design is a vital part in an access control system, as this will affect the responsiveness and reliability of the system. The goal was to minimize protocol overhead and keeping total transmitted data sizes as small as possible. This is to counter the fact that NFC transfer rates are comparatively slow, 106 -‐‑ 424 kbps. Given a transfer rate of 106 kbps and an accumulated protocol payload size of 3 kilobytes, the total transfer time is 226 ms. With this in mind the communication protocol was built on top of the ISO 14443-‐‑4 protocol standard. This is a protocol that operates in the very lowest level, just transferring payloads between reader and device. Another layer had to be added to manage the flow of information, as it happens the Android Host Card Emulation already uses the ISO 7816-‐‑4 protocol to communicate with the reader. The ISO 7816-‐‑4

DB

Daemon SQLite NXP1reader1library

Webserver

Web1Frontend

Lock1relay GPIO UNIX1sock

SPI

PN1512


27 (47)

protocol has been used in smart card based systems for a long time, everything from mobile SIM cards to credit cards, communicate using this protocol. The authentication protocol relies upon this protocol making it potentially compatible with a wide range of mobile devices. The system can be summarized as follows:

• Raspberry Pi hardware • NXP PN512 NFC transceiver • Debian Linux operating system • Linux user space access control daemon • ISO 14443 and ISO 7816-‐‑4 based communication protocol • OpenSSL cryptographic libraries • SQLite database • HTML/PHP frontend

5.2 System software components The secure access control daemon consists of several software components. This chapter will describe their purpose and functionality in detail. The functionality of the different components ranges from the ability to communicate with the hardware, cryptographic libraries and custom applications.

5.2.1 NFC reader library To interface with the NXP PN512 NFC transceiver the ANSI C NXP reader library was used. It supports all low-‐‑level NFC protocols, ISO 14443 & ISO 18092, as well as higher-‐‑level protocols such as Mifare, DESFire, FeliCa, NFCIP and many more. The library features a layered architecture consisting of seven layers. Each of these layers have a specific implementation and a generic interface, the different layers are; (NXP Semiconductor, 2013)

• Bus Abstraction Layer (BAL) -‐‑ Implements the interfaces between physical Host-‐‑Device (Raspberry Pi) and physical Reader-‐‑Device (NXP PN512).

• Hardware Abstraction Layer (HAL) -‐‑ These are the Components, which are used to abstract the functionality of the physical reader device to a generic interface.

• Protocol Abstraction Layer (PAL) -‐‑ Contains hardware independent implementations of various contactless protocols.

• Application Layer (AL) -‐‑ Contains Application specific implementations for various contactless cards (DESFIRE (R), MIFARE (R), MIFARE Plus (R) and the like.


28 (47)

• Activity Layer (AC) -‐‑ This layer handles device discovery and includes the device discovery loop.

• Link Abstraction Layer (LN) -‐‑ Includes the components that handle Logical Link Control Protocol (LLCP).

• Network Protocol Layer (NP) -‐‑ Includes the components that handle Simple NDEF Exchange Protocol (SN (NXP Semiconductor, 2013)EP). Which enables two NFC devices to exchange messages on the NFC Data Exchange Format (NDEF). This is a stateless high level request/response protocol used for example in Androids Beam technology to push contact information or images.

For this project the card emulation communication mode was chosen, which falls under the ISO 14443 group of protocols. This includes the BAL, HAL and PAL layers. The rest of the layers are not used by the application, instead a custom authentication protocol built on the ISO 7816-‐‑4 protocol is added on top of the PAL layer. Each layer in the NXP reader library needs to be initialized before using. The application first initializes the low level context, BAL and HAL, using the phbalReg_Init() and phhalHw_Rc523_Init() functions, respectively. The read and write buffers are allocated by the application and registered with the HAL layer, to be able to receive and transmit data. The SPI registers and IRQ pins are then configured and the SPI is opened using the phbalReg_OpenPort() function. The system is now ready to begin communication over NFC. After the initial setup of the hardware, the detect device loop is entered. The detect loop begins by initiating the required PAL and AL layers, in this design only the PAL layers ISO 14443-‐‑3A and ISO 14443-‐‑4 needs to be initiated. This done by calling the phpalI14443p3a_Sw_Init() and phphalI14443p4_Sw_Init(). The RF field in then reset and the application starts to probe the near field for ISO 14443 enabled NFC devices, by using the phpalI14443p3a_RequestA() and then polling its status with phpalI14443p3a_ActivateCard(). Any device that is present in the near field will be selected one at a time and answer with is Answer To Request (ATQA) and Select Acknowledge SAK identifiers. The ATQA and SAK values can be used to identify a device’s manufacturer, tag type and application. If values matches those of the HCE Android device a Request for Answer to Select (RATS) is sent to the device using the phpalI14443p4a_Rats(). If the select is successful, the device responds with an Answer to select (ATS) and the ISO 14443-‐‑4 layer can be activated for further communication using the phpalI14443p4_SetProtocol().


29 (47)

From this point onwards all communication is performed using the phpalI14443p4_Exchange() function, to send and receive APDU command and response messages between reader and device.

5.2.2 The SRP Authentication Protocol As stated in the Analysis section (4.4) the Secure Remote Password authentication protocol was chosen for this proof of concept system, as it aligned well with the system requirements. This section offers an in-‐‑depth look at the SRP authentication protocol and how it is implemented in the application. The original SRP protocol needs three round trip message exchanges to mutual authenticate both client and server, using some clever rearrangement, this can be reduced to two round-‐‑trips and even further if mutual authentication is not required. In this system, mutual authentication is not needed, as only the server needs to verify the authenticity of the user, and not the other way around. (Wu, 1998) Before the authentication exchange can begin the server needs to generate a verifier and salt, which is stored together with the user´s username in a database. The verifier is a one-‐‑way hash that the server uses to authenticate the authenticity of the user. To generate this verifier, SRP employs a SHA1 hashing function algorithm, exponentiation operation (^) and modulo operation (%). (Wu, 1998)

(1) <salt> = random() (2) x = SHA(<salt> | SHA(<username> | "ʺ:"ʺ | <raw password>)) (3) <password verifier> v = g^x % N

The client stores the plain-‐‑text password either on the mobile device or in the users memory. The complete SRP protocol is explained in detail below. (Wu, 1998)

1. The SRP protocol exchange starts with the client sending its username to the server. The server then looks up the username’s verifier v and salt s.

2. The server then sends the retrieved salt s to the client and the client calculates its private key x by hashing the salt, username U and plain text password P.

3. The public key A is calculated from the generator g and private ephemeral key a. The generator g is a primitive root modulo n, both g and n are well-‐‑known values agreed upon beforehand. A is then sent to the server.

4. The Server uses the password verifier v, generator g and private ephemeral key b to calculate the public key B, which is then sent to the client together with a random scrambler parameter u.

5. Now both client and server calculates the common exponential S, which should match if both, have the correct password.


30 (47)

6. S is then hashed, on both sides, using a cryptographic hash function, to create the session key K. This session key K can later be used to symmetrically encrypt communication between client and server.

7. The client hashes the session key K together with the public keys A and B to create the final proof of authenticity, which its sends to the server for verification.

8. In the final step, the server will likewise prove its authenticity to the client. This final step can be omitted if mutual authentication is not required.

The two parties must also adhere to the following safeguards (Wu, 1998):

1. The client will abort if B == 0 (mod N) or u == 0. 2. The server will abort if it detects that A == 0 (mod N). 3. The client must show his proof of K first. If the server detects that the user'ʹs

proof is incorrect, it must abort without showing its own proof of K. Not following these safeguards would compromise the security of the protocol. The complete protocol exchange can be seen in the table below.

Table 3. Condensed view of the original SRP exchange

Client Actions Exchanged data Server Actions

1.

C -‐‑-‐‑> (lookup s, v)

2. x = H(s | H(U | "ʺ:"ʺ | p)) <-‐‑-‐‑ s

3. A = g^a A -‐‑-‐‑>

4.

<-‐‑-‐‑ B, u B = v + g^b

5. S = (B -‐‑ g^x)^(a + ux)

S = (A ·∙ v^u)^b

6. K = H(S)

K = H(S)

7. M1 = H(A | B | K)

M1 -‐‑-‐‑> (verify M1)

8. (verify M2) <-‐‑-‐‑ M2 M2 = H(A | M1 | K)

This protocol can be reduced from the total of three round trips to one and a half round tip, by consolidating some of the individual transactions, grouping together parameters that do not depend on earlier exchanges and omitting the mutual authentication. (Wu, 1998) In Table 4 the optimized version of the SRP protocol can be seen.


31 (47)

Table 4. Optimized one-‐way authentication SRP exchange

Client Actions Exchanged data Server Actions

1. A = g^a C, A -‐‑-‐‑> (lookup s, v)

2. x = H(s | H(U | "ʺ:"ʺ | p)) <-‐‑-‐‑ s, B B = v + g^b

3. S = (B -‐‑ g^x)^(a + ux)

S = (A ·∙ v^u)^b

4. K = H(S)

K = H(S)

5. M = H(A | B | K) M -‐‑-‐‑> (verify M)

This is the version of the SRP protocol that will be implemented in this system.

5.2.3 Application Protocol The main challenge in this project is to integrate the SRP authentication protocol on top of a NFC protocol. This will require a glue layer that will act as a mediator between the high level SRP authentication protocol and the low level NFC protocols. It was chosen to implement this glue layer on top of the ISO 7816-‐‑4 protocol, which is request/response-‐‑based protocol on top of the NFC ISO 14443-‐‑4 protocol. The ISO 7816-‐‑4 protocol states that the responding client should immediately response to the request. If the response cannot be returned immediately, a null response is sent back to the Reader. This will make the Reader keep the session open indefinitely, until a response is received. Otherwise the session will timeout and the authentication protocol will be terminated. The application continuously probes the near field for a device. When a device is found the protocol exchange is initialized by the Reader, which initiates the exchange by sending a select message to the mobile device. It includes the AID, which is interpreted by the Android HCE framework and forwards the message to the correct Service. The AID consists of two parts, a registered application provider identifier (RID) value that identifies the type of service. The second part of the AID is the proprietary application identifier extension, which uniquely identifies the Reader.

Table 5. Select command

APDU Header APDU Body CLA INS P1 P2 Lc RID PIX Le 0x00 0xA4 0x04 0x00 0x07 7 bytes 4 bytes 0xFF

The client will check if it has an entry for the selected RID and respond with the username associated to that RID. It will also calculate the client’s public ephemeral (A) and included it in the select response.


32 (47)

Table 6. Select response

APDU Body APDU Trailer UNAME APUB SW1 SW2 1 -‐‑ 20 bytes 128 bytes 0x90 0x00

The server will check the validity of the user and then calculate the Readers public ephemeral (B). This together with the 160-‐‑bit salt that is stored in the Readers database will be sent in a challenge command to the client.

Table 7. Challenge command

APDU Header APDU Body CLA INS P1 P2 Lc SALT BPUB Le 0x00 0xD0 0x00 0x00 0x94 20 bytes 128 bytes 0xFF

The client will respond with the session key verifier (M1). Now the authentication exchange is complete. We do not need to send the servers session key to the client, as mutual authentication is not needed.

Table 8. Challenge response

APDU Body APDU Trailer M1 SW1 SW2

128 byte 0x90 0x00

The Reader will calculate the Reader session key (K) and the session key verifier (M2). If M1 and M2 matches the client has proved it authenticity and the lock is opened. The OpenSSL implementation of SRP is focus on its uses together with the TLS protocol that secures TCP/IP connections. This unfortunately means it only supports generating session keys that are used to encrypt a secure communication channel and the actual authentication will be performed by other parts of the TLS protocols. The reader needs to be able to generate the session key verifier M2 in order to verify the session key verifier M1 sent by the client. This requires a custom cryptographic function to be implemented. To make this function compatible with the client software’s implementation of SRP, the corresponding method in the Spongy Castle library was ported from Java to C and used in the application. A total of four messages is exchange during the authentication procedure, this seems to be the theoretical limit for a secure authentication protocol, as proposed by (Steiner, Tsudik, & Waidner, 1995). The amount of data transmitted during the protocol


33 (47)

exchange varies between 432 bytes and 451 bytes, depending on the username length. On top of this the ISO 14443-‐‑4 protocol block format adds 5 bytes to each message. This gives a total maximum data size of 471 bytes.

5.2.4 Database The system needs to store a lot of information to function properly. The main information that has to be stored is the user information, username, and SRP verifier and salt as well as access logs. The information is of a sensitive nature and has to be accessed quickly to not make the system sluggish when a user wants to authenticate. To store all this information a database supporting the Simple Query Language (SQL) was chosen. A lightweight implementation of SQL made specifically for embedded systems is the SQLite database. It takes a minimum of system resources and has an API that is well supported by all major programming languages and frameworks. It is the perfect database for this system running on the Raspberry Pi.

5.2.5 Administration interface The system needs an administration interface where users can be added or removed, lock open duration can be adjusted, etc. To be able to remotely access the administration interface and not requiring an external display, a web-‐‑based solution was chosen. It consists of a HTML, JavaScript and CSS frontend with a PHP server backend, which interface to the SQL database and the NFC access control daemon. It has a session-‐‑based design, with user login, and protected by TLS to provide a secure environment in which to remotely operate.

5.2.5.1 User creation Adding new users is one of the most important tasks in the administration interface. The administrator will type in the user'ʹs full name, username and password, there is also an option whether or not the user shall have access immediately when it is created. When a new user is added the SRP verifier and salt has to be created from the chosen password. The creation of the verifier and salt has to be performed using the OpenSSL library and since access to that library is only available in the access control daemon, the information entered has to be passed there. One option would have been to do it in the PHP backend, but it currently does not exist an OpenSSL implementation that supports SRP in PHP. The user information is passed to the PHP backend in a json-‐‑formatted message by an asynchronous jquery operation. The PHP backend will then establish a connection with the access control daemon through UNIX sockets. The user information is passed along to the daemon, which will check that no user by that name exists and then calculate the necessary SRP parameters, returning a success/failed message depending on the outcome of the operation.


34 (47)

5.2.5.2 User administration The administration interface can also query the SQL database and list all the users. Here the administrator can enable/disable access to the lock for selected users or completely remove users from the system.

5.2.5.3 Access logs All authentication attempts are logged in the system, regardless of whether access was granted or not. If the authentication was performed correctly the logs will show the username and date and time of entry. If authentication failed or some unknown device was used, that will be shown as an attempt to breach the system. The logs are stored in the database and can be accessed through the administration interface.

5.3 Android Application The android application is based on the Host Card Emulation Framework. The central class that the access control client software is based upon is the HostApduService class. When extending the HostApduService class the application inherits the processCommandApdu method and the onDeativated method. These are the only two interfaces to the HCE framework and needs to be integrated with the authentication protocol flow. The processCommandApdu is called when an APDU select command is received that matches the AID of the access control client software as specified in the application resource XML file. All subsequent APDU commands are routed to the processCommandApdu method until a new APDU select command is received with a different AID. The onDeactivated method is called when the card emulation session is terminated either by the Reader or if Android detect a loss of communication.

Table 9. Android HCE application protocol stack

SRP protocol Application layer

Secure authentication protocol Card organization and structure (ISO 7816-‐‑4)

Android HCE protocol stack Transmission protocol (ISO 14443-‐‑4)

Activation and anti-‐‑collision (ISO 14443-‐‑3) RF Signal interface (ISO 14443-‐‑2) Physical Layer (ISO 14443-‐‑1)

The Android application needs to be able to handle the SRP protocol but unfortunately, SRP is not among the included cryptographic ciphers in the Android standard library. Instead the third-‐‑party cryptographic library, Spongy Castle, was used. The Spongy Castle cryptographic functions are called from the main state machine that handles the access control authentication protocol. The APDU messages are


35 (47)

passed to the state machine via the processCommandAPDU. When an authentication selection has been made the application will search its internal database for any user entry for that specific lock ID.

5.4 Development Environment When developing for Linux on the Raspberry Pi platform, there are many possible ways to structure the development environment. Either by setting up a cross-‐‑compilation environment on a PC where the application is compiled and then transfer the binaries to the Raspberry Pi. The Raspberry Pi is powerful enough to host and run the developer tool chain natively, which is a very convenient way to do rapid prototyping in a project of this size. A minimum amount of time is wasted on system configuration and setup. The tool chain is run natively on the Raspberry Pi and is based on the Gnu Compiler Collection (GCC) and Binutils. The Cmake build system was used for this project, as it has additional features compared to ordinary make and eases the developer’s burden when writing and managing make files. Using cmake the developer specifies the application source files and any dependencies to external libraries. Cmake then checks that all prerequisites and dependencies are satisfied then generates the required make files. The external libraries needed to build this project can be seen in Table 10.

Table 10. External library dependencies

eglibc 2.16 The GNU c programming language standard library libopenssl 1.0.1e Contains cryptographic chiffers and protocols, among them the SRP

protocol. glib 2.40 The Gnome library, extends the c standard library with several useful

features, used mainly by NXP reader library (nxprdlib) libsqlite3 3.7.13 C language API for the sqlite3 database. wiringpi 2.24 Provides low level access to SPI devices and GPIO pins nxprdlib Provides access to the NXP PN512 NFC transceiver

The Gnu debugger (GDB) was used extensively throughout the project to debug the application. GDB supports setting break points, watch points, single stepping through the application and dumping memory and register contents. All of this is very useful during the development. The application source code was version controlled through git and pushed to a remote repository.


36 (47)

6 Results This chapter will present the different measurements that were performed and the final results from these measurements. After the implementation phase was completed, all parts of the system were in working order. The system was stable and reasonably fast, why measuring the different system performance aspects was not a problem.

6.1 Time measurements The first interesting measurement to take, was the total time taken from first contact to successful authentication/unlock. This is the most important result to measure since it will give an idea if the system fulfills the system requirements. It is also interesting to break this process down and analyze the different subsystems and their performance. The authentication function is of special interest as this is the central part of the system, where most of the labor was put. The measurements where performed by inserting timing function into the source code at points of interest.

Figure 2. Authentication time measurement

From the measured values an average total authentication time was calculated to 330 ms, of this time 216 ms was protocol authentication time. The remaining 114 ms represent device discovery and initialization time. From the diagram above one notice a clear variance between the different runs, with the extremes differing by as much as 123 ms. This is most likely due to delays on the Android device, where the

0

50

100

150

200

250

300

350

400

450

1 2 3 4 5 6 7 8

Time (ms)

Run order

Total time

Auth time


37 (47)

Android operating system may prioritize the HCE task at a lower priority level. One other explanation is that packets are dropped and has to be resent. Analyzing the values further one notices, that authentication protocol time is polarized to values of 15 ms increments with (175, 230, 260, 300) probably this is the time it takes to retransmit a package. It would have been interesting to vary the length of the cryptographic keys to see how it affected the system performance. Unfortunately such measurements could not be managed within the scope of this project.

6.2 Number of Users The access control system only has one constraint on the number of authorized users that can be handled by the system and that is the size of the user database. Both the physical limitation, i.e. disk space used by the database and the fact that as the database grows larger so does the result query time. The result query time will eventually grow to large and make the system sluggish and unusable.

6.3 System resources Another interesting performance aspect is to look at how much system resources are used by the access control daemon and if it is constrained in some way by this. This also gives an ide of how resource intensive the system is, which is valuable information for future productization of the system. System resources can be categorized in three main categories CPU utilization, memory consumption and I/O usage. Using the resource supervison tool, top, to check how much resources the daemon process consumes during normal operation. When looking at the CPU utilization and memory consumtion, nothing stands out and a very limited amount of resources is used. During ideling the application uses 1 percent CPU and while actively running the authentication protocol the CPU utilization is around 10 percent. The only I/O constraint in the system is the NFC communication channel, which is the I/O bottleneck in this system, since the transferspeed is 106 kbps, well below what a 700 MHz CPU can handle. The Raspberry Pi platform seems more than capable to handle the workload, since the daemon runs well without any constraining resurce limitations.


38 (47)

6.4 Physical properties The complete system fits inside a box with dimensions 95x63x32 mm (WxBxH), requiring two different supply voltages, 5V to power the integrated circuits and 12V to power the electromagnet inside the locking mechanism. It has a reading distance of approximately 5 cm.


39 (47)

7 Conclusions In this chapter conclusions about the system performance will be drawn by comparing the results with the system requirements set at the start of the project. The proof-‐‑of-‐‑concept access control system is fully functional and performs really well. Conclusions will be drawn by comparing the obtained results with the goals and requirements as stated in chapter 1.1. The lock should utilize the highest available encryption standards. The system is highly secure thanks to the ingenious SRP authentication protocol, especially when comparing with other contemporary authentication protocol. It should be immune to most cryptographic attacks or they would at least take an unforeseeable amount of time to break. There are measures that can be taken that make the system even more secure by using other cryptographic hash functions (SHA1, SHA254, SHA384) or varying the length of the cryptographic keys (1024/2048/4096 bits) this would theoretically make the system harder to break, but it would also increase the amount of data needed to be exchange and in extension lengthen the execution time of an authentication session. To increase the security even further, one could ask the user to enter the password at the beginning of every authentication attempt. This would mean that no password information have to be stored on the phone. As with all secure system it has to be peer review before anything definite can be said about how secure it is. The authentication process should be as fast as possible. The measured average total authentication time was 330 ms. This is a very subjective parameter, but I would argue that anything less than half a second is considered to be reasonably fast. The measured result of 330 ms is well below that half-‐‑second mark, therefore the system fulfills this parameter too. The authentication process requires as little user interaction as possible. The user does not need to do anything other than to unlock the mobile device. The Android background service will then automatically engage when the Reader sends the select message. The lock should not require Internet access. By choosing to base the authentication protocol on SRP protocol, no Internet access is required. Many of the other evaluated authentication protocols requires a connection with a third-‐‑party server that is usually connected to the Internet. The ability to run the system in an offline environment enables deployment virtually anywhere.


40 (47)

The lock application should work on as many devices as possible. This requirement was fulfilled when deciding to base the client side software on the Android operating system, which has by far the largest global market share. Ideally all major mobile devices should be supported but that is not a concern in this project. After comparing the results to the system requirements, it is concluded that all requirements and goals where meet that was within the scope of this project.


41 (47)

8 Discussion This chapter conducts a discussion around the subject of security in this type of system; is there still security concerns, what could be changed, trying different options, other features that could be added. Here the author will speak freely and air his point of view. Could a NFC based access control system, that uses a mobile device as a key, be the future of Smart locks? The results look very promising and merit further investigation. The potential of using a NFC enabled mobile device as an unlock device instead of a key to ones house/apartment or office building is a great convenience. There would be no need to carry around all the keys and keycards needed to access all locations through out the day, as everything will be contained inside a mobile device. Then take into account the many features a system like this could be extended with. All this functionality together with the other emerging and existing functionality a mobile device possess, like electronic wallet and mass transit token system. Makes a very compelling case for the mobile device and its future roll as a virtual key. Where everything will be contained in one place, on the mobile device, this means no need for a wallet, credit cards, key cards or even keys. There are of course a couple of obstacles that have to be overcome before such a system can become a reality. The obvious one is, if your mobile device is stolen, lost or merely runs out of battery, what then? You will have no way to authenticate yourself and gain access. This applies equally to a key, which can also be lost or stolen. What about the security aspect, how secure is the system? Well I would argue that it is much more secure then an ordinary key. An ordinary key can be lost or stolen just as easily, it can also be copied, some times just from a photograph of the key. If one compares this solution to other modern electronic access control systems that uses smart cards, the SRP authentication protocol is immune to almost every cryptographic attack. However this system does not follow the SRP specification to the letter. It stores the users username and password on the mobile device, for the users convenience, this could potentially make the password fall in to the wrong hands if the mobile device was hacked. SRP states that the user should enter the password on every authentication attempt, to be as secure as possible. I would argue that one need not exclude the other. For very secure systems, the application can force the user to enter the password during every authentication attempt. On a system that does not require that level of security, the application can store the users password for future use.


42 (47)

One of the major remaining problems to solve is the issue of how to get the password from the server to the client in an elegant way. This was not within the scope of the project so no work has been done to solve this problem. I have been thinking of a few different solutions to this problem but not one that is really elegant. One possibility is to pair the Reader and the mobile device using NFC, and then the Reader will send its ID number along with the users username and password to the mobile device, there by pairing them. This would of course require the Reader and user to be in the same location, which in some cases is not an optimal solution. Another issue with this system is that it relies on NFC, which at this point in time is not included in the majority of mobile devices. Not only NFC is needed on the mobile device, but it also has to feature something similar to the Android HCE framework. One would also need to have the software tailored to each mobile operating system’s own bidirectional NFC framework. This system could also be further extended with Internet of Things capabilities, by connecting the system to the Internet, the owner can remotely grant people access to the lock. Which would be a very useful feature. Though it has some security concerns that have to be taken into account. When connecting a device to the Internet it is immediately susceptible to malicious attackers that might try to break into or disrupt the system. This has to be considered if such functionality should be introduced.


43 (47)

9 Future work This chapter will outline the futures and redesigned that can be undertaken in the future to be able productize a commercial access control system based on the finding in this project.

9.1 Design refactoring Depending on the intended use of this system it might need some hardware and software refactoring. It makes sense to have a self-‐‑contained system in a residential apartment, where you only have one front door. In the case of an office building the system would work better with lightweight readers at every door and a central authentication server with the database.

9.2 Internet of Things (IoT) This system could be one of the IoT connected devices in a home. This would give the owner the possibility to remotely control the lock, granting access to some one standing by the door, when the user is not at home.

9.3 The Android Application The current Android application is very thin, it consists only of a background service. This can be greatly improved with several must have features that are currently missing. The application should support multiple access control systems, with a easy to use graphical user interface that present the users keys and access privileges at different locations. Since the user might have several keys for the apartment, summer house, office building and even friend’s houses. It would be convenient to have different device pairing options, so that the user could receive access privileges electronically through email.

9.4 Device Pairing The problem of how to pair the reader and mobile device has to be solved. Ideally the system owner should be able to send the user credentials needed for authentication directly to the users mobile device over the Internet, in an email for instance. Another way would be to use NFC to relay the user credentials to the users mobile device, the drawback being that they need to be at the same location.

9.5 Security There are ways to increase the authentication security and make it even harder for a malicious attacker to brute force the system, by extending the access control authentication protocol to handle variable key-‐‑length and hash functions. This system utilized a 1024-‐‑bit key length and the 160-‐‑bit SHA1 cryptographic hash function, but could be extended to work with key sizes of 2048, 4096 or 8192-‐‑bits and use other cryptographic hash functions like SHA256 or SHA384. During the protocol


44 (47)

initialization, the server can tell the client which parameters to use, this way greater security can be achieved.

9.6 Admin interface The administration interface could be expanded with further functionality to control the time period a user has access privileges. Alternatively set an expiration date and time on a users access privilege.


45 (47)

Bibliography Ahson, S. A., & (eds), M. I. (2012). Near Field Communications Handbook . Auerbach Publications. Android Developer. (n.d.). Near Field Communication. Retrieved 2015, from Android Developer: https://developer.android.com/guide/topics/connectivity/nfc/index.html Android Developers. (n.d.). Host-‐based Card Emulation. Retrieved 2015, from Android Developers: https://developer.android.com/guide/topics/connectivity/nfc/hce.html Apple. (n.d.). Apple Pay. Retrieved 2015, from Apple: http://www.apple.com/iphone-‐6/apple-‐pay/ Aura, T. (1997). Strategies against replay attacks. Computer Security Foundations Workshop, 10, pp. 59 -‐ 68. Bianchin, L., & Nathanson, A. (2008). NEAR FIELD COMMUNICATION (NFC) -‐ Emerging Market Analysis. Automatic Identification and Data Collection Practice VDC Research Group, Inc. Cisco. (2006, January 19). Kerberos Overview -‐ An Authentication Service for Open Network Systems. Retrieved 2015, from Cisco.com: http://www.cisco.com/c/en/us/support/docs/security-‐vpn/kerberos/16087-‐1.html Coskun, V., Ok, K., & Ozdenizci, B. (2012). Near Field Communication: From Theory to Practice . Chichester: John Wiley & Sons Ltd. Delfs, H., & Knebl, H. (2007). Introduction to Cryptography: Principles and Applications (2nd Edition ed.). Springer. Diffie, W., van Oorschot, P. C., & Wiener, M. J. (1992, June). Authentication and authenticated key exchanges. Designs, Codes and Cryptography , 2 (2), pp. 107-‐125. FFIEC. (2001, August 8). Authentication in an Internet Banking Environment. Retrieved 2015, from ffiec.com: http://www.ffiec.gov/pdf/authentication_guidance.pdf Fine, C., Klym, N., Tavshikar, M., & Trossen, D. (2006). The Evolution of RFID Networks. Cambridge University Communications Research Network. Francis, L., Hancke, G., Mayes, K., & Markantonakis, K. (2012). Practical Relay Attack on Contactless Transactions by Using NFC Mobile Phones. London, UK: Royal Holloway University of London. Garcia, F. D., Rossum, P. v., Verdult, R., & Schreur, R. W. (2009). Wirelessly pickpocketing a Mifare Classic card. In Security and Privacy, 2009 30th IEEE Symposium on. Berkeley: IEEE. Goldwasser, S., Micali, S., & Rackoff, C. (1989, February). The Knowledge Complexity of Interactive Proof Systems. SIAM Journal on Computing , 18 (1), pp. 186-‐208. Haselsteiner, E., & Breitfuß, K. (2006). Security in Near Field Communication (NFC). Gratkorn, Austria: Philips Semiconductors. Hein, B. (2014, September 15). Apple confirms iPhone 6 NFC chip is only for Apple Pay at launch. Retrieved 2015, from Cult of Mac: http://www.cultofmac.com/296093/apple-‐confirms-‐iphone-‐6-‐nfc-‐apple-‐pay/ IDC. (2015, February 24). Worldwide Quarterly Mobile Phone Tracker. Retrieved 2015, from idc.com: http://www.idc.com/getdoc.jsp?containerId=prUS25450615


46 (47)

ISO/IEC. (2008). ISO/IEC 14443-‐1:2008 Identification cards -‐-‐ Contactless integrated circuit cards -‐-‐ Proximity cards -‐-‐ Part 1: Physical characteristics. Geneva, Switzerland: International Organization for Standardization. ISO/IEC. (2010). ISO/IEC 14443-‐2:2010 Identification cards -‐-‐ Contactless integrated circuit cards -‐-‐ Proximity cards -‐-‐ Part 2: Radio frequency power and signal interface. Geneva, Switzerland: International Organization for Standardization. ISO/IEC. (2011). ISO/IEC 14443-‐3:2011 Identification cards -‐-‐ Contactless integrated circuit cards -‐-‐ Proximity cards -‐-‐ Part 3: Initialization and anticollision. Geneva, Switzerland: International Organization for Standardization. ISO/IEC. (2008). ISO/IEC 14443-‐4:2008 Identification cards -‐-‐ Contactless integrated circuit cards -‐-‐ Proximity cards -‐-‐ Part 4: Transmission protocol. Geneva, Switzerland: International Organization for Standardization. ISO/IEC. (2013). ISO/IEC 18092:2013 Information technology -‐-‐ Telecommunications and information exchange between systems -‐-‐ Near Field Communication -‐-‐ Interface and Protocol (NFCIP-‐1). Geneva, Switzerland: International Organization for Standardization. ISO/IEC. (2013). ISO/IEC 7816-‐4:2013 Identification cards -‐-‐ Integrated circuit cards -‐-‐ Part 4: Organization, security and commands for interchange. Geneva, Switzerland: International Organization for Standardization. Microsoft. (2015, May 8). Near field communication (NFC). Retrieved 2015, from Windows Phone Dev Center: https://dev.windowsphone.com/en-‐us/OEM/docs/Driver_Components/Near_field_communication__NFC_ MIFARE. (2015). About MIFARE. Retrieved 2015, from MIFARE: https://www.mifare.net/wp-‐content/uploads/2015/04/About_MIFARE_Brochure_January_15.pdf Moore, G. (1965, April 19). Cramming More Components onto Integrated Circuits. Electronics Magazine , 38 (8), pp. 114–117. NFC Forum. (2015). NFC Forum Technical Specifications. Retrieved 2015, from NFC Forum: http://nfc-‐forum.org/our-‐work/specifications-‐and-‐application-‐documents/specifications/nfc-‐forum-‐technical-‐specifications/ NFC Forum. (2014, November 5). NFC Forum’s Paula Hunter to Speak at “Internet of Things Applications USA,” Nov. 20. Retrieved 2015, from NFC Forum: http://nfc-‐forum.org/newsroom/nfc-‐forums-‐paula-‐hunter-‐speak-‐internet-‐things-‐applications-‐usa-‐nov-‐20-‐2/ NXP Semiconductor. (2013, July 24). NXP Reader Library User Manual, 1.2. Retrieved 2015, from NXP: http://www.nxp.com/documents/user_manual/UM10663.pdf Oechslin, P. (2003). Making a Faster Cryptanalytic Time-‐Memory Trade-‐Of. Lausanne, Switzerland: Ecole Polytechnique F´ed´erale de Lausanne. Schneier, B. (1996). Applied Cryptography (2nd Edition ed.). John Wiley and Sons. Steiner, M., Tsudik, G., & Waidner, M. (1995, July). Refinement and extension of encrypted key exchange. ACM Operating Systems Review , 29 (3). Swedberg, C. (2004, July 9). Developing RFID-‐Enabled Phones. Retrieved 2015, from RFID Journal: http://www.rfidjournal.com/articles/view?1020 Vanderkay, J. (2004, March 18). Nokia, Philips And Sony Establish The Near Field Communication (NFC) Forum. Retrieved 2015, from NFC Forum: http://nfc-‐forum.org/newsroom/nokia-‐philips-‐and-‐sony-‐establish-‐the-‐near-‐field-‐communication-‐nfc-‐forum/


47 (47)

Wu, T. (1998). The Secure Remote Password Protocol. Internet Society Network and Distributed System Security Symposium, (pp. 97-‐111). San Diego, CA. Ylonen, T. (2006). The Secure Shell (SSH) Authentication Protocol. Network Working Group of the IETF. Zhou, Y., & Feng, D. (2005). Side-‐Channel Attacks: Ten Years After Its Publication and the Impacts on Cryptographic Module Security Testing. Institute of Software, State Key Laboratory of Information Security. Beijing, China: Chinese Academy of Sciences.

TRITA-ICT-EX-2015:102

www.kth.se

secure authentication in near field communication based ...862212/fulltext01.pdf · degree project,...

Documents