OU, IM990C, Master Computer Science. Thesis Security evaluation of the NFC contactless payment protocol using Model Based testing

Transcription

1 OU, IM990C, Master Computer Science Thesis Security evaluation of the NFC contactless payment protocol using Model Based testing Name: ing. J. (Jacob) Merkus Student number: Date: 30 April

2 2

3 OU, IM990C, Master Computer Science Thesis Security evaluation of the NFC contactless payment protocol using Model Based testing Open University of the Netherlands, Faculty of Management, Science and Technology Master's Programme in Computer Science Graduate commission: dr. ir. H.P.E. (Harald) Vranken, prof. dr. M.C.J.D. (Marko) van Eekelen, Open University 3

4 Content Content... 4 Abstract Introduction Research context: NFC payment architecture NFC enabled mobile device Technical components Logical components NFC payment processing EMV EMV contact EMV contactless Initialization phase Application selection Card authentication phase Card verification phase Transaction phase Online and offline PIN validation Related work NFC security threats Threats in the NFC landscape Eavesdropping and Replay Relay attack Data modification NFC Payment threats Security requirements Discussion Security properties Modelling security protocols NFC protocol stack: Identified weaknesses The NFC protocol NFC transaction in detail APDU s NFC transaction flow Defined steps

5 Initialization phase APP selection GET PROCESSING OPTIONS Verification and authentication phase Transaction completion phase Identified weaknesses Case 1: ISO/IEC 14443: POS activation sequence, error handling Case 2: ISO/IEC 14443: Phone and card contacting POS Case 3: ISO/IEC : Phone with multiple payment APP s Security evaluation Security modelling Detailed model Start APP Initialisation Select APP GET PROCESSING OPTIONS Verification Transaction result Simple validation model Simple POS simulator Security evaluation using Model Based Testing Test environment UPPAAL UPPAAL tool UPPAAL simulator Online testing Offline testing Simple UPPAAL model Validate the security related test case Validation of the simple model POS validations against the simple model Conclusions and future work Conclusions Future research References Other references

6 10 Internet links Abbreviations NFC related terms Secure elements and platform management Protocols and data formats Card management ISO/IEC abbreviations ISO/IEC abbreviations Appendix A: HCE versus SE Appendix B: POS architecture Appendix C: EMV Appendix D: ISO/IEC and ISO/IEC : Physical characteristics ISO/IEC : RF power and signal interface ISO/IEC : Initialization and anti-collision ISO/IEC : Transmission protocol ISO/IEC : Organization, security and commands for interchange Appendix E: Error detection Appendix F: APDU Appendix G: NFC transaction flow ATR GET PROCESSING OPTIONS Appendix H: UPPAAL Features of UPPAAL Coffee Machine Detailed model in UPPAAL Simple model in UPPAAL

7 Abstract Keywords: NFC payments, contactless, security evaluation, Model based testing. Contactless payments based on NFC are increasing each year. More and more consumers are now using their smartphones to pay contactless. According to the Dutch Payments Association, half a million consumers have already downloaded an APP for mobile payments with a smartphone and six banks are supporting NFC payments executed by the phone. Because NFC based transactions is still an emerging technology, this area is a nice target for hackers. The main goal of my research is to evaluate the security of the contactless payment protocol using Model Based Testing (MBT). Can MBT be used to support security testing by recognizing a wrong implementation of the system? The security evaluation is based on the following items: Research of NFC related attacks Investigation of security weaknesses in the NFC protocol Compare the behaviour of a security related test case executed via a model against the expected behaviour Execute test cases in a MBT simulation environment During the research I investigated the NFC payment protocol, identified a possible weakness and made a simple model. The weakness I identified is the case were multiple APP s are installed on the mobile phone from multiple financial issuers. When an APP is installed on the phone, the corresponding AID is registered in the routing table of the NFC controller. This routing table can be changed, which can result in unavailability of the payment APP. The simple model validates one step in the payment processing flow. Only the AID used during payment processing is checked. When the AID is valid the transaction is successful. I created a test environment, where I could validate, with the use of UPPAAL-TRON, the model against a simple POS Implementation Under Test. Based on research of related work I concluded the NFC protocol contains security weaknesses. Also I concluded modelling the NFC payment protocol is complex because the model should be in sync with the system and this system is complex. Modelling a small part can be useful to identify a wrong implementation of the system. 7

8 1 Introduction The use of contactless payments grows each year and more and more consumers are now using their Near Field Communication (NFC) enabled smartphones for contactless payments. According to the Dutch Payments Association, since April 2018 half a million consumers have already downloaded an APP for mobile payments with a smartphone and six banks are supporting these contactless payments. In the Netherlands, more than three quarter of all payment terminals are suitable for contactless payment and in 2019 this should be implemented to all manned payment terminals in Europe. In the past two years, the number of contactless payments increased to a record. In 2017 around 1540 million transactions were processed without contact [85] by using a debit card or mobile phone. These results were published by Betaalvereniging Nederland and are related to the use of contactless payments in the Netherlands. In the coming years it is expected that the number will increase further. Worldwide there are more than 50 countries where contactless payments are possible. Contactless payment is still much faster than using a debit card via contact. The insertion of a cash card accompanied by giving in a personal identification number (PIN) takes more time than a non-contact payment. Partly this time savings allows for strong growth in the numbers. Rabobank customers are able to pay using a smartphone from ING and ABN introduced this functionality in In 2017 also customers of SNS, ASN Bank and RegioBank can pay contactless. Currently most of the customers are using the ING APP. A contactless payment is a quick and easy payment by using a NFC enabled debit card or phone and keeping this near to a terminal, a so called Point Of Service (POS). The amount of the payment that can be paid is currently dedicated to 25 without a PIN. Amounts over 25 must be paid with entering a PIN code. With contactless payment customers keep their phone or debit card a few centimetres near to the POS. The payment is handled by the NFC chip and the POS makes contact with the NFC chip in the customer s phone or debit card. The final transaction is via the same network as used for traditional debit card payments. In the communication between the phone or debit card and POS a NFC related protocol is used. Security is an essential aspect of the success of this NFC technology in the payment area. Customers will use the service only if it is secure and stable for doing payments without any risk. For this reason the European Central Bank (ECB) published recommendations for the security of mobile payments. 8

9 Using contactless mobile payments is increasing fast. Because the amount of NFC based mobile transactions will grow coming years and due to the fact that it is still an emerging technology, this area is a nice target for hackers. The main goal of this research is to identify a security related weakness in the NFC protocol and validate if Model Based Testing (MBT) can be used to support the security testing. The environment used is based on an NFC enabled phone doing a contactless payment and making use of the NFC protocol. Another reason for this research is to give more awareness of possible risks and actions regarding the security testing that can be taken. Can MBT be helpful in increasing the speed of security testing? Can MBT be used to recognize a wrong implementation? For this reason a closer look is given in using MBT. The main question for the research is: What are possible security related weaknesses in the NFC protocol and how can Model Based Testing be used to validate these identified weaknesses? Steps to take during the research are: Set up security requirements for validation of the created model Set up a simple NFC model, based on the requirements and on the NFC protocol Derive and validate the security related test case by comparing the observed behaviour with the expected behaviour based on the contactless protocol Set up a simulation environment for executing a security related test case Proof of concept of a security related test case in a simulation environment Evaluate the outcome of the test case The following three parts are input for the security evaluation and validation if MBT can support this: 1. Research of security related work and investigation of NFC security weaknesses 2. Outcome of comparison of behaviour of the security related test case executed via the simple model against the expected behaviour 3. Execution of one of the test cases in a MBT simulation environment In this research first the overall NFC payment architecture will be given in chapter [2 Research context: NFC payment architecture]. The related work, security threats and security requirements for the NFC processing flow will be elaborated in chapter [3 Related work]. After this in chapter [4 NFC protocol stack: Identified weaknesses] a short description follows of the NFC protocol stack and one security related case will be explained, used for the MBT security evaluation. In chapter [5 Security modelling] the modelling steps will be explained of the detailed security case, also the simple model and simple POS will be given used in the security evaluation process. 9

10 Chapter [6 Security evaluation using ] explains the test setup and the used modelling tool. In this chapter an elaboration will be given on the validation of the simple model and Implementation Under Test (IUT - simple POS simulator). In chapter [7 Conclusions] the results are gathered and conclusions are given. The following sub questions will be answered in this research: 1. What security requirements are investigated? 2. How does NFC work and how is the interaction implemented between the NFC enabled phone and POS when doing a payment? 3. What (possible) security issues are known on the RF interface and data interaction between the NFC enabled phone and POS and what are the identified weaknesses? 4. What are the details of the simple model? 5. How can the model be used as input for the MBT tool? 6. What MBT tool can be used? 7. What security related test cases can be generated? 8. What is the expected behaviour of the test cases and does this differ from the execution result within the simple model? 9. How can a proof of concept (POC) be executed in a simulation environment? Two important definitions, part of the ISO/IEC and ISO/IEC 7816 protocols, are: Proximity Coupling Device (PCD) is equivalent to: o Reader/writer o POS (entry point) o Terminal Proximity Integrated Circuit Card (PICC) is equivalent to: o Tag o Card with NFC o Phone (device) with NFC Whenever these definitions are used in this report the similar equivalent can also be used. For example if a card is used in a certain context also the phone can be used in this context. 10

11 2 Research context: NFC payment architecture In this chapter first the high-level NFC payment architecture is given. Also the Euro pay, MasterCard and Visa (EMV) environment is explained because this environment is used on top of the NFC protocol. The next paragraphs give a more detailed overview on both of the topics and describe together the research area. 2.1 NFC enabled mobile device The mobile contactless payment architecture consists of the following parts: Mobile device (this can be a NFC enabled card or phone) Merchant POS Issuer (Bank) Acquirer [52] [18] The overall mobile payment architecture, given in Figure 1, consists of: An NFC enabled mobile device to execute payments Merchant POS: Any entity, a store, restaurant, etc. that accepts NFC payments Issuer: Financial Institution (FI) that provides the mobile wallet application including NFC contactless payment execution to consumers. The financial institution facilitates access to the (mobile wallet) account to complete the transaction Acquirer: FI that initiates and maintains contractual agreements with merchants for the purpose of accepting and processing phone contactless payments from customers Figure 1: Mobile Contactless Payment Architecture [52] The mobile device contains a contactless payment application. The payment account issuer will provision and personalize the contactless payment application on the mobile device. There may also be a side channel link between the issuer and the mobile device for updating of payment application information (i.e. EMV scripts). 11

12 The mobile device communicates with a POS over the contactless interface to allow the contactless payment application to perform a payment transaction. The payment system network is responsible for authorization, clearing and settlement. The merchant is connected to an acquirer, and through an authorization and clearing network to the issuer. EMV standards will ensure the merchant POS infrastructure for accepting mobile contactless payment [37]. See Figure 2 for an overview of the NFC related actors and corresponding roles. Figure 2: NFC roles and actors The mobile device consists of the following logical components: Mobile platform Logical component based on Host Card Emulation (HCE) or using Secure Element(s) (SE). See [12 Appendix A - HCE versus SE] for further HCE and SE details For this research the difference in using HCE or SE is not taken into account because the research is focussing on the data interaction used in the contactless payment protocol between the NFC enabled phone and POS. This difference in security can be a topic for another research. In this research the SE architecture is explained. The mobile platform is the device in which the SE is hosted if available and where the other components are such as a user interface, an application environment, a proximity, based on EMV contactless NFC connection. In case of using an SE the payment application is hosted in this SE. It provides a secure area for the execution of the applications and protection of several payment parts (e.g. payment data, keys and the payment application code) [17]. 12

13 2.1.1 Technical components The technical components used in the architecture of the NFC device are displayed in Figure 3. This architecture of the NFC device [17] is based on using a SE. Figure 3: General Architecture of the NFC Device In the general NFC architecture, the mobile application is a program loaded inside the SE. This SE is part of the handset which acts as a graphical interface to a specific mobile NFC service. The network access unit of the phone communicates using the telecom network (i.e. GSM or UMTS): Universal Integrated Circuit Card (UICC) or Subscriber Identity Module (SIM) API of the mobile handset allows any mobile application installed on the mobile handset to communicate with the UICC card using Application Protocol Data Unit (APDU) commands NFC API of the mobile handset allows any mobile application installed to communicate with the contactless frontend (CLF) when invoked by a POS Card Application Toolkit (CAT) provides a mechanism which allow applications to interact and operate with any Mobile equipment which supports the specific mechanism(s) required by the application 13

14 UICC NFC API Specific Java card API which allows the UICC card to communicate with the NFC controller NFC application Java card application which allows managing all NFC applications Contactless frontend (CLF) or NFC controller is a NFC chip which allows the mobile handset to communicate through NFC using three different modes: card emulation, card reader and peer to peer The Issuer Security Domain (ISD) is the primary, mandatory on-card representative of the card administrator (typically the card issuer) Supplementary Security Domain (SSD) is an additional, optional on-card representative of an application provider or the card issuer Mobile Network Operator (MNO) The NFC device uses a certain operating mode. This operating mode determines the specific kind of task that Near Field Communication (NFC) is performing. The devices interacting at the time allow for certain operating modes. The operating modes of the NFC related devices are: Peer-to-peer mode: exchange data between two NFC-enabled devices Reader/writer mode or active mode where the NFC behaves as a reader: one NFC device exchanges data with a passive NFC tag Card emulation mode [26] or passive mode where the NFC chip behaves as an RFID tag where the user interacts with an NFC reader and NFC enabled phone. This mode allows a phone to act as a contactless card based on ISO/IEC standards The research area focusses on the interaction of the NFC enabled phone which operates based on the emulation mode. In this mode the use of the phone is similar as the use of credit or debit cards. The POS initiates the payment request and the phone acts as a smart card and executes the payment Logical components The contactless mobile payment device has a number of logical components: An application environment in which applications can run. The application environment is hosting the user interface applications which allows communication between a contactless mobile payment application and a user User interface (UI) displays necessary information and provides the input mechanism for user selection and payment functions Secure Element 14

15 NFC controller, which interacts based on the EMV contactless communication protocol. The contactless module is also responsible for routing contactless communications between the antenna and one of the secure elements or the application host processor in the mobile device A wide area connection which provides network connectivity for the application and for provisioning and personalization of the payment application onto an SE In Figure 4 the zones are displayed which perform related functions in order to group together elements of the architecture. The research area is the data communication between the areas B, C and F (NFC controller and Contactless Payment Terminal). Figure 4: Contactless Mobile Payment System Architecture and zones [53] The table below shows the zones, descriptions and the contributing organizations. Zone Item Contributing organizations A Secure Element, highly secure crypto chips, provides memory for each payment application and other functions EMV Co, ETSI SCP, Global Platform, GSMA that can encrypt, decrypt, and sign the data packet B Contactless module, which implements the EMV contactless interface and is responsible for routing of EMV Co, ETSI SCP, NFC Forum contactless information. It includes the interfaces to the contactless module from components within the mobile device, including the interface to the application processor, and the interfaces to a secure element C The component (antenna) which implements the analogue EMV Co, NFC Forum part of the EMV contactless interface D The baseband, application processors and other components in the mobile device (excluding SE, contact - less module and antenna) which form the mobile device EMV Co, GSMA 15

16 E Contactless payment application Payment systems F POS EMV Co, Payment systems G Provisioning and personalization system EMV Co, GSMA, Payment systems H The application update system EMV Co, Payment systems ETSI: SCP: GSMA: European Telecommunication Standards Institute. Smart Card Platform, working group of ETSI focused on the UICC. GSM Association, an association of GSM operators. There are many organizations involved in the development of the architecture of contactless mobile applications. EMV Co seeks to work with these groups to define the architecture and specifications needed to support contactless mobile payment. EMV Co collaborates with other industry bodies and standards organizations [53]: 1. International Organization for Standardization (ISO): The EMV Chip Specifications are based on underlying ISO/IEC standards as follows: ISO/IEC 7816: Identification Cards Integrated Circuit(s) Cards ISO/IEC 14443: Identification Cards Contactless Integrated Circuit(s) Cards 2. The NFC forum: EMV Co has been working to extend EMV technology to the contactless and mobile channels. This has required alignment with the NFC Forum which is responsible for developing the specifications for communication between NFC devices and services 3. Global Platform: Part of EMV Co activities is to review the functionality and security of platforms on which an EMV chip payment application is installed 2.2 NFC payment processing First item of this paragraph is to clear the definitions of a card, phone, transactions processed and the POS. Definition of a NFC enabled card/phone: A NFC enabled card/phone is a consumer token supporting contactless payment transactions in the form of a payment chip card or phone. Definition of a transaction: A transaction takes place using the contactless interface with a contactless phone. A transaction start is defined differently depending on how it is initiated. It can be initiated by the merchant, typically by entering the transaction amount. Alternatively, it can be initiated when a card/phone enters the polling field and responds, indicating its presence. A transaction continues until the final transaction is indicated to the card/phone holder. 16

17 Definition of a POS system: A POS system is the device that communicates with the NFC enabled phone and processes the contactless transactions. The physical architecture of the POS can be a fully integrated terminal: All elements included in a single device, an intelligent card reader: The reader handles most of the contactless transaction processing, passing the results for completion by the terminal or a combination of terminal and transparent card reader: The reader provides communication with the card, kernels and other processes in the terminal. The basic functions of the POS system include: Communication with the contactless phone Application selection and kernel activation Displaying messages to the card/phone holder Displaying messages to the merchant Accepting merchant data entry of the transaction amount Card/phone holder verification (e.g. signature) Provision of online connections Provision of data capture for clearing and settlement Terminal functionality Entry Point (part of the POS) software that performs the initial analysis of a contactless transaction and invokes appropriate kernel software The architecture of the POS is explained in [13 Appendix B: POS architecture]. The POS contains terminal and reader software. The complete POS functionality is not needed for this research, the data communication between POS and NFC enabled phone will be investigated. The messages send from the POS for example a SELECT of an APP are part of the data communication and will be investigated. In the following section a short functionality is described of the POS. The Entry Point software contains five main functional sections: 1. Preliminary transaction processing. Processing prior to the activation of the contactless interface of the reader and before the cardholder presents a NFC enabled card/phone 2. Protocol activation: Activation of the contactless interface 3. Combination selection: Selection of the combination to use for the transaction For contactless cards this list is specified in the Proximity Payment System Environment (PPSE), returning Application Definition Files (ADF) and selecting also the Application Identifier (AID) this functionality is explained in chapter [4.2.2 NFC transaction flow] and [15.5 ISO/IEC : Organization, security and commands for interchange] 4. Kernel activation: Entry Point activates the selected kernel and this begins kernel processing based on APDU 5. Outcome Processing: Entry Point processes an outcome according to the type of outcome and the values of the outcome parameters 17

18 See Figure 5 below for a detailed overview. Figure 5: Entry Point High-level architecture [38] The main functionality of the POS System is [37]: Responsible for ensuring that a new transaction is not started until the completion of the previous transaction Cancellation. Once a transaction has been started, there must be a means to cancel the transaction in case the user is unable to present a contactless card or NFC enabled phone in time Displaying Amount Receipts Card/phone holder verification, optional when performing a contactless transaction Normal payment processing, using the phone is the following: User taps the device on the contactless POS Used APP is triggered (e.g. ING or RABO contactless APP) Contactless card/phone transaction is initiated At this point, standard contactless card/phone payment transaction is executed between acquirer and issuer authorization host For HCE the transaction message is sent to HCE Cloud Transaction Management System for HCE specific authorization controls 18

19 2.3 EMV The EMV Integrated Circuit Card Specifications for Payment Systems are global payment industry specifications that describe the requirements for interaction between chip-based consumer payment applications and POS systems to process payments. The specifications are managed by the organisation EMV Co. The EMV specifications are built on the ISO/IEC standards and See [14 Appendix C: EMV] for security details of EMV. The principles EMV Co developed are [54]: A mobile device can support multiple contactless mobile payment APP s from multiple financial issuers and carrying different brands The user determines which payment APP is to be used for a transaction EMV Co does not require a particular architecture or policy Where possible EMV Co will make use of industry specifications EMV Co will seek to make use of industry type approval programmes for qualification of mobile devices Contactless mobile payment must be compatible with existing EMV Co based contactless payment infrastructure The chip provides three parts: 1. Store information 2. Perform processing 3. Perform cryptographic processing These capabilities provide the means for secure consumer payments. When the chip is installed inside a non-card form factor, such as a phone, contactless is the only option for connection to the acceptance POS. The features defined by EMV are: Authentication of the chip card to protect against fraud for online authorised transactions and offline transactions Risk management parameters to define the conditions under which the issuer will permit the chip card to be used and force transactions online for authorisation under certain conditions such as offline limits being exceeded Digitally signing payment data for transaction integrity More robust cardholder verification to protect against lost and stolen card fraud for EMV transactions MasterCard supports two types of mobile contactless payment solution, SE and HCE. With the MasterCard Mobile solution, the payment application and sensitive payment credentials are stored on a SE or Trusted Environment on the handset or in the SIM. With MasterCard Cloud Based Payments (MCBP) solution, the payment credentials are stored securely on the device using HCE and the cryptogram is securely generated in the cloud. 19

20 Van den Breekel et al. [24] describes the kernels used for VISA and MasterCard. In the phone case this is compatible with the MasterCard Kernel version two software. For EMV contactless transactions the terminal has to select an APP on the phone. The phone can contain a list of AIDs of applets that are present combined with a priority per applet. For contactless cards this list is specified in the PPSE. A terminal will select the AID with the highest priority. Also the terminal will use the kernel specification that corresponds with the selected AID. The MasterCard contactless implementation is documented in EMV Book C-2 [41]. The initialisation of an EMV contactless transaction starts by reading the PPSE, to which the phone responds with the list of available payment applications with corresponding priorities. The terminal selects the application with the highest priority and then sends the GET PROCESSING OPTIONS command. The mobile then provides the Application Interchange Profile (AIP) and the Application File Locator (AFL). The mobile responds by sending the AIP, which the terminal can use to determine the transaction type, and the AFL, which contains the list of all files the terminal can read. The AIP on the card can indicate whether EMV Mode is supported [25]. An APP on the phone (in the ICC) includes a set of items of information mostly within files. These items of information may be accessible to the terminal after a successful application selection. An item of information is called a data element. A data element is the smallest piece of information that may be identified by a name, a description of logical content, a format, and a coding. It is up to the issuer to ensure that data in the card is of the correct format [47] EMV contact A successful transaction processed using EMV contact can be divided in several different phases. Roughly the phases are: Initialization, data authentication, cardholder verification and transaction phase [71]. 20

21 Figure 6 displays the steps while processing a payment using EMV contact. Figure 6: Processing EMV contact Explanation of the used codes in Figure 6: AAC: Application Authentication Cryptogram is a cryptogram from the card for the POS that indicates that the transaction is aborted. AAC is a cryptogram generated by the card at the end of offline and online declined transactions. It can be used to validate the risk management activities for a given transaction ARQC: Authorization Request Cryptogram is a cryptogram from the card for issuer, forwarded by the POS, indicating that the issuer must authorize the card to perform the transaction CDA: Combined Dynamic Data Authentication is a method to authenticate a card together with the transaction details to a POS with a challenge-signed response mechanism CVM: Cardholder Verification Method is a method to verify the identification of the cardholder DDA: Dynamic Data Authentication is a method to authenticate a card to a POS with a challenge-signed response mechanism SDA: Static Data Authentication is a method to authenticate a card to a POS with static data TC: Transaction Certificate is transaction proof from the card for the POS 21

22 2.3.2 EMV contactless The core of the protocol used by phone payment processing is based on EMV contactless and still the same as EMV contact. While EMV contact uses the contact chip in bank cards, Mobile contactless and EMV contactless uses the RFID chips. These RFID chips can communicate and process transactions with NFC enabled POS systems. The major difference between a contactless transaction (EMV / Mobile) and an EMV contact transaction is that the transmission of information between the chip and the terminal is faster for contactless and some of the transaction steps may be performed after the chip has left the proximity of the reader (i.e., online authorization). The goal is to minimize the amount of time that the chip must be held within proximity of the reader [70]. The contactless (EMV) specifications can be found on the EMV website [72] and consist of books A, B, C and D where book C specifies the behaviour of the kernel [40] - [46], which is software in the reader that is responsible for most of the logical handling of payment transactions. Book C comes in seven different versions, books C-1 through C-7. According to Section of Book A, the specification in book C-1 is followed by some JCB and Visa cards, specification C-2 is followed by MasterCard s, C-3 by some Visa cards, C-4 by American Express cards, C-5 by JCB cards, C-6 by Discover cards, and C-7 by Union Pay cards. Contactless MasterCard cards have been marketed under the name Pay Pass, contactless Visa cards under the name pay Wave, and contactless American Express cards under the name Express Pay. Feature of EMV is that the consumer payment application is running in a secure chip that is embedded in a payment card, often referred to as a chip card or smart card, or in a personal device such as a phone [70]. The contactless steps of processing an EMV transaction are the following [73]: Application selection Read Application Data Off-line Data Authentication Processing Restrictions Cardholder Verification Terminal Risk Management Terminal Action Analysis Go On-Line (card/phone)? On-Line Processing Completion Script Processing 22

23 See Figure 7 below for the transaction flow. Figure 7: Example transaction flow Initialization phase In the initialization process there is a pre-processing part. Some processing occurs before the reader's contactless interface has been activated and before the cardholder presents a contactless card, this is to minimize the time the card is within the readers RF field to ensure the transaction happens as quick as possible. At this point the reader can execute some risk management checks. After the pre-processing there is the card detection part. Since no card has been presented, the type of transaction is not yet known. Discovery processing is performed by the reader to check for the presence of contactless cards that entered the reader s RF field. At this point a contact transaction could be executed and this has precedence over the contactless one Application selection In the application selection part the Entry Point uses PPSE as the selection mechanism. The PPSE contains a list of applications which are selectable over the contactless interface. A single application can run on different kernels so Entry Point needs to know which Kernel to activate in addition to the AID. 23

24 A Kernel ID is used to differentiate between the different kernels that may be supported by the reader. Within these specifications, a kernel is software in the POS System that processes certain contactless transactions. For MasterCard cards, only kernel 2 can be used. Entry Point selects a kernel based on the characteristics of the transaction, the applications supported by both the card and the reader, and the priority that may be assigned to each application. The combination of AID and Kernel ID is called a reader combination. Every card application in EMV is identified by an AID. The structure of AID is defined in ISO/IEC It consists of 2 parts: RID (Registered application provider Identifier) which is uniquely assigned by ISO/IEC to an application provider, e.g. RID for Visa is A Optional field called PIX (Proprietary Application Identifier Extension) assigned by application provider [79] Entry Point sends a SELECT (PPSE) command to the card and the response is the File Control Information (FCI) which contains the list of directory entries. The FCI template, identified with the tag 6F is given in the below Figure 8. Figure 8: FCI Template Entry Point finds reader combinations by matching the data elements in the card to those available for use by the reader. Any reader combinations found by Entry Point are added to the candidate list. Next part is the kernel activation. The kernel selects the combination with the single highest priority and issues a SELECT command for the chosen application. If this is successful then Entry Point activates the corresponding kernel in the reader combination and this begins kernel processing according to the relevant card scheme rules. During initiate application processing, the reader executes the GET PROCESSING OPTIONS command to the phone and includes any data that the card has requested during APP selection. The response of the card/phone is the AIP and Application File (AF). The Initiate Application Processing step is different from that of an EMV contact transaction. In the contact case the application data is returned within the read records or generate Application Cryptogram (AC). This is a cryptogram provided by the card as a response on a request from the POS to perform a transaction. 24

25 The AIP contains the following information: Is Static and dynamic Data Authentication (SDA / DDA) supported? Is Combined Dynamic Data Authentication (CDA) supported? Is cardholder verification supported? Is terminal risk management being performed? Is issuer authentication supported? The AFL is a list that consists of the files and related records for the currently selected application that should be read by the terminal. The POS requests these records and the card sends them to the POS. These records contain information about: Application Expiration Date Application Primary Account number Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Certification Authority Public Key Index Issuer Public Key, Remainder and Exponent The reader indicates to the cardholder that the card read is complete, and the cardholder should remove their card from the reader s RF field. The contactless transaction has not yet completed. The reason the card is removed before the further processes is to keep the amount of time the card is in the RF field to a minimum, this helps to improve the customer experience and reduce the potential for card errors if it waivers from the RF field whilst in the customers hand. The reader checks the application data returned by the card to ensure it complies with the requirements for the chosen contactless path. The reader examines the Cryptogram Information Data (CID) to determine the cryptogram type, this can be AAC, ARQC, or TC. This indicates if the card expects the reader to decline offline, attempt online authorization or approve offline. However, this result is not the final outcome. The final outcome will be determined during the outcome processing step. CID contains the type of Application Cryptogram generated by the card during the Card Action Analysis stage. In addition, the card may also return a reason or advice code (e.g. service not allowed, or issuer authentication failed) to allow the terminal to perform any additional processing that may be required. There are 3 type of cryptogram that can be generated by the card/phone: AAC is generated whenever a phone declines a transaction ARQC is generated whenever a phone requests online authorization TC is generated whenever a phone approves a transaction During Processing Restrictions (conditional), the reader checks the application expiration date, application usage, and may check whether the card application is on the Terminal Exception File. 25

26 Card authentication phase For all transactions the used card is authenticated. The card can be authenticated offline by the terminal or online by the issuer. During a payment transaction, the card and the terminal agree to perform SDA, DDA or CDA (Combined Data Authentication). Only one method of offline data authentication is performed for a particular transaction. When offline data authentication is not performed, an EMV chip transaction must go online for authorization. All offline approved Maestro (Pay Pass) transactions must be authenticated using CDA. All offline MasterCard (Pay Pass) transactions must be authenticated by the terminal using either CDA or SDA. The difference between SDA and DDA is that while SDA indicates that the data read from the chip has not been manipulated or changed since it was issued, SDA does not necessarily mean that the card is real. It is possible to copy the chip card data, including the SDA cryptogram, and write it to another chip card to create a copy card that could successfully pass offline SDA at the POS. It should be noted that any copied card can be detected during online processing. CDA is strongly recommended for MasterCard Pay Pass transactions and the use of SDA is being phased out. All Pay Pass terminals support CDA. Pay Pass does not support DDA. For online Pay Pass transactions the issuer should perform online authentication by verifying the ARQC received in the online authorization. CDA uses asymmetric encryption to authenticate the card to the terminal and also authenticate the transaction information. The authentication is performed by means of a GENERATE AC command. Card issuers will choose an offline data authentication method based on factors such as cost per card and speed of transaction Card verification phase Cardholder verification checks that the person using the card is the cardholder. The card contains a list of verification methods that it supports, and the conditions under which they should be applied. During Cardholder Verification, the reader determines which, if any, Cardholder Verification Method is to be performed. Note that at this stage the card has already been removed from the reader s contactless field, hence, if a cardholder verification method is required then this will happen without the need for the card to be presented again. Five different methods to verify the cardholder: 1. Online PIN verification 2. Online encrypted PIN verification 3. Online plaintext PIN verification 4. Cardholder signature verification 5. No cardholder verification 26

27 Transaction phase The transactions phase is the last phase in this process. Transactions can be performed online, offline and they can be rejected. The cryptogram that is generated for the online authorization request is termed the ARQC and the cryptogram that is generated by signing data elements when a chip approves the payment for clearing and settlement is known as the Transaction Certificate (TC). If the transaction is declined, the chip will generate an AAC cryptogram. Payment will be rejected if required transaction disposition is failing. Online processing enables the card issuer to analyse the transaction details and decide whether it wishes to authorize or reject the transaction. This allows the issuer to check the account status and apply criteria based upon acceptable limits of risk defined by the card issuer, the payment scheme and the acquirer. The reader indicates to the cardholder the outcome of the contactless transaction. If the transaction has been authorized then payment can be submitted for settlement. Optional: Issue Update Processing requires the cardholder to present their card to the RF field for a second time. If issuer update processing is supported by both the contactless card and the contactless reader, then it is only performed when the online processing response contains either issuer authentication data or issuer scripts Online and offline PIN validation A Personal Identification Number (PIN) is a four to twelve-digit number known by a cardholder and used to authenticate the cardholder to the card-issuing bank. The transaction PIN is the PIN typed by the cardholder during a payment transaction. PIN verification can be of two types: online and offline [78]. The online PIN is the transaction PIN used to verify the cardholder online. The offline PIN verification is used with an ICC to verify the cardholder offline. The reference PIN is a stored, or derived PIN value used by the issuer to verify the transaction PIN. If stored in an ICC it may or may not be equal to the online PIN. The PIN may also be verified using a PIN verification value or a PIN offset either transmitted with the transaction PIN or stored at the issuer host. Offline transactions are used when terminals do not have online connectivity. In case of an online PIN verification the PIN entered by the cardholder is transmitted to the issuer (or its designated service provider) for verification, together with the card details (possibly read from the IC of the payment card or manually entered). Transmission is typically via the merchant acquirer or financial institution; or a third-party service provider. The PIN verification algorithm is selected by the issuer. EMV transactions can be authorized online or offline. 27

28 3 Related work This chapter describes the research related to security threats in the NFC protocol which is already done. This chapter is divided into two parts, part one is about NFC security threats, and the possible attacks, the next part is about the security related requirements which will be investigated for this research and a short description about the additional value of modelling security protocols. The discussed security attacks are in most of the cases related to the ISO/IEC protocol. In this research one of the security risk, related to interference of payment APP s when multiple APP s are installed on the same phone, will be used for the input of the simple model and model-based testing tool. The AID used during payment processing is picked from the phone s routing table. This routing table also can contain malicious APP s which can lead to an AID conflict during payment processing. Result is unavailability of the payment APP and impact on the integrity of the payments flow. The question if it is possible to create a model (or a part) of the NFC protocol for validating an IUT and the steps how to setup an environment, how to validate and is there added value to make use of MBT are investigated. 3.1 NFC security threats A lot of research is executed related to NFC security threats. Examples are paper [9], [11] and [34] which describe the existing security vulnerabilities in NFC-based phone systems. In the next chapter a short summarize of those threats is given Threats in the NFC landscape Papers [9], [11] and [34] describe several issues in the NFC security landscape. Examples of those threats are: 1. All NFC devices are readers and writers and can emulate a tag 2. The range of NFC is not enforced 3. NFC is a gateway to the attached device 4. Multiple NFC applications can run on a single device 5. No NFC security standard 6. The possibility to unintentionally connect to an NFC device 7. Privacy of the user is not protected, because data send over NFC is not encrypted 28

29 The mentioned number four describes the risk of improper application separation were the device contains multiple NFC applications. In such an environment, all applications use the same interface to communicate with the outside world. This introduces the risk that one application is capable of interfering with or eavesdropping on the communication of another application that runs on the same device. This risk will be the input for the model created in this research and used for validating the IUT. Also the papers [10] and [11] describe several vulnerabilities and attacks on data and also gives solutions for this attacks. These attacks are related to the Radio Frequency (RF) interface such as: Eavesdropping Man In the Middle (MIM) attacks Data corruption, insertion and modification DOS attacks (attack on availability) Relay attacks Phishing by social engineering Attacks related to the NFC Mobile environment and secure element: Running applications on host Installation of malware APP s on host controller or SE Attacking NFC controller Eavesdropping Over The Air (OTA) management of SE Adding modified SE to NFC mobile Skimming and token cloning attacks Security related vulnerabilities on the RF signal described in this research are eavesdropping, replay attack and relay attack. These attacks are described in the next chapter. Security related vulnerabilities on the data interaction, such as data modification, data insertion, data corruption and spoofing attacks are also described shortly in the next chapters Eavesdropping and Replay Eavesdropping is a common threat found in all wireless communication technologies like NFC. NFC uses radio frequency signals to communicate, so any equipment with an antenna in the range can receive the signal. The attacker can extract the information from the signal transmitted through experimentation and periodic analysis processes. This is very dangerous in the case of payments, where the users can use a password. The eavesdropper needs this information and can misuse it. It is very difficult to prevent eavesdropping as the attacker who uses a very precise antenna can receive the signal even if the signal strength is too weak. The only solution to eavesdropping is to use a secure channel for communication [38]. 29

30 A consequence of eavesdropping is that an unintended receiver can intercept sensitive information between sender and receiver (confidentiality of the information is violated). The hacker does not need to pick up every single signal to gather private information. The risk of an eavesdropping attack is low, since the required communication distance to allow transferring data is not more than a few centimetres, which makes an eavesdropping attack on NFC device a low possibility. An extension of this attack is the replay attack (see Figure 9). Suppose that the phone authenticates to the NFC reader by sending an unprotected secret identifier. An attacker can eavesdrop the communication between phone and the reader, receive the identifier and resend or replay the identifier from his own phone when located at the door enabling him to illegally gain access to the building. Figure 9: Eavesdropping and Replay attack [75] Aad van Moorsel et al. [13] states that contactless offline PIN verification requires the PIN to be transmitted wirelessly to the card which has a security risk from eavesdropping. Figure 10: Verify PIN protocol sequence [13] The process sequence is designed to guess (Figure 10) the PIN without locking the card. Locking occurs when all of the available PIN attempts are used. The protocol uses the minimum number of commands possible so that it can be completed quickly to avoid arousing the suspicions of the cardholder. 30

31 3.1.3 Relay attack A critical attack in NFC is the relay attack [8] [19]. A relay attack in computer security is a type of hacking technique related to man-in-the-middle and replay attacks [14]. In a man-inthe-middle attack [15], an attacker intercepts and manipulates communications between two parties initiated by one of the parties. In a relay attack, communication with both parties is initiated by the attacker who then relays messages between the two parties without manipulating them or even necessarily reading them. Relay attacks are used in challenge and response protocols for example the ISO/IEC displayed in Figure 11. In this attack the attacker is using the credentials of the victim and executes successfully a payment using NFC. Figure 11: Relay attack on the ISO/IEC [61] Christian Killer et al. [8] states the risk of relay attacks in RFID communications still exist in EMV-compliant POS terminals. Mainly due to the fact that, most of the contactless smart cards are based on the International Organisation for Standardisation (ISO) / International Electronical Commission (IEC) standard and are intended to operate over a distance of around 10 cm. The paper concentrates on the ISO/IEC of operation mode Type A standard which is used in most contactless cards. Also this paper implements a practical relay attack on public transportation EMV-compliant POS machines, only using two off-theshelf mobile tablets, a wireless router and a VISA credit card. The paper states that relay attacks could be prevented by introducing secondary authentication procedures (e.g. using a password). However, this additional verification countermeasures needs more user-interaction which increases the transaction time. This might not be acceptable in certain applications. 31

32 3.1.4 Data modification The threat related to data modification is when a hacker replies to a received message before the legitimate receiver (i.e. POS) can do. This can only be done if the legitimate receiver takes a long time before answering, i.e. has a high response time. If the attacker s spoofed reply (providing false information to the user, which seems legitimate) is not sent before the legitimate receiver starts sending, the two signals will overlap and interfere and thus the spoof fails. Data insertion affects the integrity property. An attacker alters the signals such that the legitimate receiver receives a valid but modified signal. In the case of NFC this attack is difficult to perform due to the short distance between the phone and the NFC terminal however it is feasible depending on the modulation and encoding used on the physical layer. See Figure 12 for the data modification flows. Figure 12: Data modification Data manipulation risk can also be significantly reduced with the use of secure channels to process payment transactions. Secure channels encrypt data so only an authorized device can decrypt this NFC Payment threats Several NFC related threats are described by Martijn Bolhuis [9] and by Ernst Haselsteiner et al. [11] when doing a payment. Examples of those threats are: Insecure storage, the storage in the phone is insecure allowing the credential in the phone to be stolen Relay attack, internal or external relay attack, this is explained in the previous chapter Insecure communication channel and untrusted reader: an hacker can apply certain attacks such as eavesdropping that allow to authenticate successfully to the system on behalf of a victim 32

33 Denial of service attack, a denial of service attack can be performed that render the phone unusable for authentication Privacy, an attacker can eavesdrop identity related information on the NFC interface without the user s knowledge and approval Also several papers are published which compare approaches to store payment keys and executing a payment application on a phone. An example is described by Diego A. Ortiz- Yepes [12]. This paper compares certain solutions and gives the plusses and minus of the solution. For example, using a secure element (SE) is very secure because of full hardware isolation, keys are very difficult to extract and malware-based relay attacks are very difficult. Using HCE some believe this is less secure because of the security provided by OS is used and a hacker s phone can extract payment keys and use them in other phones or conduct malware-based relay attacks. Vulnerabilities for example incompatibility between applications and the operating system can disable payment applications. Also on the EMV pages [63] several contactless payment processing threats are discussed. The papers states that the goal of an attacker is to perform unauthorized payments for financial gain or other reasons (e.g. denial-of-service). Primary NFC payments processing attacks are the following: An attack which enables an unauthorized party to perform fraudulent payments via remote access to legitimate devices that have been compromised Mobile APP cloning where a single compromised consumer device duplicates (clones) its assets to unauthorized devices or where data is duplicated so that the clones can all transact without detection A denial-of-service (DOS) attack that would prevent a consumer from making a payment Unauthorized payments made with lost and stolen devices Other examples given are abuse of the interfaces between the components that make up the payment application or alter behaviour of the mobile application where code is altered or malicious code injected, for example to present false information to the user. The discussed threat model shows that an attacker tries to compromise the mobile APP in the different phases of the mobile APP s life cycle with different windows of opportunity; for example, during enrolment, provisioning, card credential update, payment, and mobile APP update. Also there are payment threats looking at the transmission layer of the NFC protocol. An example is described by Aad van Moorsel et al. [1], in which the card collision phase is discussed when more than one card is presented to the payment terminal's field. In this situation the terminal does not know which card to choose to proceed with the transaction. 33

34 In this card collision phase the EMV protocol (which is the primary standard for smart card payments) specifies that the reader should not proceed when it detects a card collision and that instead it should notify the payer. In comparison, the ISO/IEC standard specifies that the reader should choose one card based on comparing the UIDs of the cards detected in the field. However, in the paper is stated that the implementation of NFC readers in practice do not follow EMV's card collision algorithm, also it does not match the card collision procedure specified in ISO. Due to this inconsistency between the implementation and the standards an attack is possible that can compromise the user's privacy by collecting the payment details. By designing and implement a malicious APP simulating an NFC card (which the user needs to install on the phone) this situation can be accomplished. When the user aims to pay contactless this APP engages with the terminal before the card does. Although the terminal detects a card collision, it proceeds with the EMV protocol. The malicious APP can retrieve from the terminal the transaction data, which includes information about the payment such as the amount and date. This data can be used to see the payment behaviour of customers. Figure 13: EMV Terminal main loop [39] The paper states according to EMV contactless Book D [39], the terminal is constantly running a main loop as illustrated in Figure 13. In the polling phase, the reader ensures that there only exists one type of technology (Type A or B) in the field by using Wake UP command e.g., WUPA for type A. Then it checks if there is only one card from the same technology in the field and activates the card. Next, the terminal application performs the transaction. Also the paper states that ISO/IEC specifies no termination in the case of a collision. Instead, a race condition is created in which depending on the implementation of the terminal, and the UIDs of the cards available in the field one card would be selected. Due to this inconsistency, it is possible to track the user's contactless payment activities, for instance through a malicious APP. The malicious app would have a chance to gather payment messages and Processing Options Data Object List (PDOL) data if the phone is closely located to the contactless payment card. 34

35 For each stage of the life cycle, the threat model considers two phases: identification and exploitation. In the identification phase, the attacker tries to develop a successful attack. The exploitation phase is the effort required to repeat the identified attack. In the end the most important consideration is whether the attack can be easily repeated, and especially whether it is scalable. Mobile application assets can be categorised as requiring one or more security services: Confidentiality, Integrity and Availability with the addition of accountability and authentication. Example of mobile payment assets used during payment processing are: Card profiles, related to both availability and integrity Payment system public keys and issuer public keys related to both availability and integrity Private and secret payment keys or payment session keys and related parameters related to both confidentiality and integrity Risk management data related to accountability/authentication 3.2 Security requirements In this chapter the security related requirements are described. In the communication between the phone and POS a NFC related protocol is used. Security is an essential aspect of the success of this NFC technology in the payment area Discussion Customers will use the NFC service only if it is secure and stable for doing payments without any risk. For this reason, the European Central Bank (ECB) published recommendations for the security of mobile payments [60]. One of the security related ECB recommendations is: Mobile payment service providers should have appropriate security in place to protect all components of mobile payment services (e.g. networks, servers, databases, payment terminals and communication links). These components should be securely configured in order to protect (harden) them and eliminate or reduce vulnerabilities of applications at risk. Access by the various applications to the data and resources required should be kept to an absolute minimum following the least privilege principle. This means that security has high priority and stakeholders as financial institutions, mobile providers and merchants should meet the requirements. 35

36 The system design of the NFC payment flow between the POS and phone should meet the next security requirements: Confidentiality and Privacy: Data communications between mobile application and POS should be confidential Data send via the flow should not be readable by unauthorized users Data in the flow should not be relayed or cloned with illegal purpose Privacy should guarantee information protection of the user s transactions Integrity: Data over the flow should not be altered, so the system is not working anymore Transaction content can be created or modified only by authorized parties Availability: The flow needs to be secure and available enough for the intended users These security requirements are discussed in several research papers for example [4] [5] [6]. The main safety and security related components in electronic financial systems are displayed in Figure 14 below. Figure 14: The main safety components in e-financial systems Regarding the paper [60] authorization, authenticity, confidentiality and integrity are stated as safety requirements for electronic financial systems like mobile payment systems. Also control of the electronic exchange of information and auditing of all actions related to the chronological recording system are mentioned. These items are security related but not part of the requirements of this research because in depth code knowledge is needed and this is not available. Conclusion of the paper [4] is that authenticity, authorization, confidentiality, control, auditing and integrity for payment systems are designed following the safety requirements and standards, and they must be always updated and improved. 36

37 The paper [7] describes for online transactions several security related requirements. Here a list of items discussed in the paper: Correctness, this means that if two trustful parties successfully complete a transaction, then the final receipt is constructed with the correct receipt attributes Integrity, this item refers to the tamper proof of the constructed receipt. If any receipt attribute is modified, then it should be possible to detect Single submission requires that the same receipt should not be submitted more than once Fairness requires that the proof of delivery from the buyer and the proof of origin from the seller are available to the seller and buyer, respectively Non-repudiation for two-party protocols: non-repudiation of origin, that is, providing the buyer with proof that the content received was the same as the one sent by the seller and non-repudiation of delivery, that is, providing the seller with proof that the content of the item or token received by the buyer was the same as the one sent by the seller Stealing prevention for receipts: if a receipt is issued to the user then another user should not be able to present as its own receipt The privacy requirement should guarantee protecting the collected information of the participants of transactions A list of security requirements related to the APP are: Must be securely installed and updated Must be protected against unauthorized modification and update Must have the ability to force a secure update to its latest version Must have a user-initiated roll-back to an earlier version that can transact successfully, unless explicitly allowed The integrity of the APP must be verified at and/or during runtime Must not run on non-supported platforms and/or devices Must not run in audit, debug, or test mode Must not log sensitive data in plain (unencrypted) format If the APP and/or server-side detect any compromise, the APP should have the capability to be deactivated and to securely remove all sensitive data Based on discussions mentioned in the previous papers the system design of the mobile payment transaction flow between the POS and phone application should meet the security requirements related to confidentiality, integrity and availability Security properties The test cases for security evaluation will be set up for validating availability and integrity of the APP in the situation where multiple APP s are hosted on the phone. 37

38 A phone can host multiple contactless APP s. Application choice is the process by which the user chooses which APP should be active at a particular time. In the preferred settings the user can give the default APP for starting a mobile payment. A deactivated APP is not accessible on the antenna interface. It is possible to access both activated and deactivated APP s on the device interface. Where there are multiple APP s related to a single service area, as this is for the payment area, there must be a priority assigned to the APP in order to establish which APP should be selected by a POS. The AID used during payment processing is picked from the routing table on the phone. This routing table also can contain malicious APP s which can lead to an AID conflict during payment processing. Result is unavailability of the payment system and impact on the integrity of the payments flow. The possible weakness is: the NFC protocol can execute a payment with an unwanted APP or the payment will be cancelled because the protocol cannot validate the APP used. The EMV protocol should select the APP with the highest priority. When multiple payment APP s installed on the phone also there is a possibility the APP s can interfere with each other. Availability means the application should be available to execute payments. Integrity means if an APP is selected the AID should be valid and not changeable during payment processing. A simple model will be setup to check if the validation can be done on the expected behaviour, displayed in the model against the real behaviour. This MBT will also be evaluated while implementing this simple model. So, the additional question is if MBT adds value to do the security testing Modelling security protocols In this research a simple model is created of a security related feature of the NFC protocol. Papers [2] and [3] discuss the modelling of security protocols. An example of a security protocol is the NFC protocol. The papers states security protocols are vulnerable to design errors. Many techniques have been proposed for validating the correctness of security protocols. Model checking is one of the preferred methods. Protocol designers can use it even if they are not very good in formal techniques. Another advantage is reducing the verification time using model checking. In paper [3] security related attacks are illustrated by model checking a security protocol using the modelling tool UPPAAL. Threats specifically involving timing can be can be input for model checking. In this research the simple model described in chapter [5.2 Simple validation model] is using timing parameters which should be extended by functional values in a more detailed model. 38

39 4 NFC protocol stack: Identified weaknesses The interface of contactless cards is standardized in the ISO/IEC protocol. This standard defines a proximity RFID [55] system based on inductive coupling with an operating frequency of MHz s. On top of the ISO/IEC protocol stack, a contactless smartcard can either use a proprietary protocol or use the APDU-based protocol defined in ISO/IEC The EMV specifications are built on top of the ISO/IEC and standards. 4.1 The NFC protocol The NFC protocol stack consists of the ISO/IEC to 4 and for the communication protocol the ISO/IEC In the ISO/IEC standard two hardware components are defined, the PDC and the PICC. The Figure 15 below shows a comparison of the protocol stack of contact and contactless cards. The ISO/IEC standard is split into four parts. Part one specifies the physical characteristics of the card and the antenna. Part two defines modulation and coding schemes of the bit transfer layer and the power supply of passive cards over the Radio Frequency (RF) interface. The last two parts are about the data transfer, in part three all information for selecting a correct smart card and in the fourth part how the transmission protocol should be initialized. Part three defines the activation and anticollision sequence and a frame-based communication protocol. Part four specifies a halfduplex block-oriented transmission protocol comparable to T=1. ISO/IEC14443 is split into two types: Type A and Type B. These types differ in their modulation and coding schemes, in their activation and anti-collision protocols and in their frame. Figure 15: Comparison of the ISO/IEC 7816 contact protocol stack [35] 39

40 The link with the OSI (Open Systems Interconnection) [80] model is also displayed in Figure 15 and Figure 16. Figure 16: OSI model [58] In contact systems, the ISO/IEC standard specifies the OSI layer 1 Transport, 2 Data link and 4 Physical. However, in contactless systems, these three layers are specified in ISO/IEC The communication protocol on OSI layer 7 application is the same as specified in for contact-based systems. Further, the transaction protocol supports the use of APDU. The ISO/IEC is the protocol used in the NFC payment flow. This standard consists of four parts which are shortly described in [15 Appendix D: ]. 4.2 NFC transaction in detail A phone can host multiple NFC APP s. Application choice is the process by which the user chooses which applications should be active at a particular time. The user can choose to activate or deactivate a particular APP s at (almost) the same time. A deactivated APP is not accessible on the NFC interface. It is possible to access both activated and deactivated APP s on the mobile interface. Where there are multiple payment APP s related there must be a priority assigned to the APP s in order to establish which APP should be selected by a POS. Michael Roland [35] describes four main elements in the contactless payment architecture: 1. APP activation user interface: There can be more than one APP Activation User Interface (AAUI) on a mobile, however at any one time only one AAUI can be active 2. NFC APP s (based on HCE or SE) 3. PPSE: An APP on the phone with the primary responsibility of indicating the user's choice of NFC payment APP s to be used by a POS 4. NFC module with a router configured by a routing table When multiple APP s are installed on the phone the default payment APP should be taken or should be given priority to the APP which is running and visible in the phone screen. 40

41 The AID of the active payment APP should be taken when doing an NFC payment. This AID is a unique number related to the payment APP and always will be the same during the payment processing time. The payment flow when doing a contactless payment with multiple APP s on the phone will be put in a simple model to simulate a test cases related to availability. The possible weakness is doing a payment with an unwanted APP and also the risk of improper APP separation when having multiple APP s on a phone. The approach to validate this risk and if MBT can be used for validation is the following: Investigate the payment processing steps based on NFC Model the steps in detail Extract a simple model to validate the security case Implement the simple model in a MBT tool Check if the security case can be evaluated by the model (against a simple test POS) The simple model covers a POS part and a phone part. These parts can synchronize with each other via channels. The model will be designed using UPPAAL. Several states in the transaction process will be defined and put into the model. The model is based on the payment processing steps executed between the POS and the phone APDU s The communication between the mobile device and POS is based on a master slave model. The mobile device is the slave and the POS is the master. In Figure 17 below the exchanging of APDU is viewed. In this figure the POS is the inactive part of the half-duplexed communication model. Figure 17: APDU exchange The Command APDU (C-APDU) is going from the POS to the phone. The Response APDU (R-APDU) is going from the phone to the POS. A command APDU exists of a mandatory header and optional body. 41

42 The header (4 bytes) consists of class of instruction (CLA), the instruction (INS) and parameters P1 and P2. The body consists of the length of the command data and the length of the expected response The response APDU exists of an optional body with the response data and a mandatory trailer, containing SW1 and SW2 (Status Word 1 and Status Word 2). See [17 Appendix F: APDU] for more details of the APDU NFC transaction flow A payment transaction needs to be initialised between a merchant POS and phone so that information can be exchanged. POS is the active entity to request a transaction creation. This POS sends a list of special instructions about the environment and POS restriction so the mobile can somehow review before agreeing to proceed with the transaction. An agreement should be made between these two entities for transaction creation. AID validation and protocol availability is part of this agreement Defined steps To build the model first the high-level transaction flow will be explained between POS and phone. Based on the EMV documentation regarding contactless transaction processing the below steps are defined. Step 1, activate APP: First step is starting the APP on the phone. When the APP is not started there is no processing at all. When the APP is started the POS will select this APP and start the communication. Step 2, APP selection: There may be multiple APP s on the phone. The POS and chip agree on common supported APP s and choose which to use for the transaction. This may involve the phone holder choosing the APP where there is more than one supported APP. In case of a mobile APP this need to be started before a payment can be executed. Step 3, initiate APP processing and read APP data: The selected APP is initiated and the POS reads necessary data from the phone. Step 4, offline data authentication: Offline Data Authentication via several possible methods: SDA, DDA or CDA. Combined Data Authentication (CDA) is a variation on DDA. 42

43 During a payment transaction, the chip card and the terminal agree to perform SDA, DDA or CDA. Only one method of offline data authentication is performed for a particular transaction. When offline data authentication is not performed, an EMV transaction must go online for authorisation. Step 5, processing restrictions: Checks are performed to confirm the chip is allowed to do the transaction requested. Step 6, verification phone holder: The holder is verified via a method supported by the POS and agreed by the phone. Methods can include signature, online PIN, offline enciphered PIN, offline plaintext PIN, or no CVM. Cardholder verification authenticates the cardholder. EMV supports four CVMs: 1. Online PIN, PIN is encrypted and verified online by the card issuer 2. Offline PIN, PIN is verified offline by the EMV chip card 3. Signature verification, where the cardholder signature on the receipt is compared to the signature on the back of the card 4. No CVM, where none is used (typically for low value transactions or for transactions at unattended POS locations Step 7, terminal risk management [51]: The POS performs several checks such as floor limit to determine whether there is a requirement for online processing. Step 8, POS action analyse: Based on results of offline data authentication, processing restrictions, phone holder verification, POS risk management and rules in the POS and from the chip, the POS application requests a result of decline offline. Based on issuer defined approve offline or go online. Step 9, phone action analyses: Based on issuer defined rules and limits, the chip will respond with ARQC: go online; AAC: offline decline; Transaction Certificate (TC): offline approval. Step 10, online processing (phone already left the proximity of the reader): If the chip requests to go online, then the terminal builds an online request to the issuer host for authorisation and online card authentication. If the response includes optional issuer authentication (ARPC), the terminal will send the data to the chip for verification. Step 11, transaction completion and script processing: Transaction completes. In case of online processing the chip will be requested to confirm with a TC (approval) or an AAC (decline) and will apply any script commands from the issuer host. 43

44 In the below Figure 18 the steps are displayed. Figure 18: Transaction process More technical steps, which are executed while initiating and executing a contactless payment transaction via a POS using a phone are summarized in the start and initialization phase, authentication and verification phase and authorization phase leading to payment transaction processing. Start and initialization phase: Start APP on the phone POS initiates transaction (start transaction) Bring phone into the RF field of the NFC reader (POS) The POS detects the presence of an NFC contactless type-4 tag Phone sends (pseudo) Answer To Reset (ATR) to the POS The pseudo-atr is used to pass information about the contactless protocol to the application layer. As Android does not use PC/SC for access to smartcards through NFC there is also no real ATR involved here. But for now I keep this as a pseudo- ATR Connection is set-up for exchanging APDU messages Authentication and verification phase: POS activates the PPSE APP by sending an APDU containing a SELECT command with the AID for PPSE POS interacts with PPSE to get a list of payment APP s available operating in NFC mode. Each APP is represented by a unique AID, in user preference order 44

45 Based on user preferences one of these options is chosen by the POS The POS selects the payment APP by AID and executes the protocol POS sends GET PROCESSING OPTIONS and the phone returns the AFL record list (explained further in the report) The POS reads the AFL and gets the public keys Authorization and transaction completion phase: POS request the phone to generate the Application Cryptogram ( GENERATE AC ) Phone replies with Authorization Response Cryptogram (ARPC) POS send in case of online authorization an ARQC to the issuer Bank. ARQC is a cryptogram used for a process called online card authentication. This cryptogram is generated by the card for transactions requiring online authorization. It is the result of card, terminal, and transaction data. The issuer validates the ARQC to ensure that the card is authentic POS gets in case of an online transactions the Authorization Response Cryptogram (ARPC) and ARC from the issuer Bank POS verifies PIN; in case of payments more than 25 euro the PIN need to be entered If the PIN is (in)correct or payment less than 25 euro and no PIN required GENERATE AC (ARPC) Phone sends the AC to the POS POS sends AC and transaction to issuer Bank Transaction completed (success or failed) Depending on payment network rules and issuer preference, chip cards in phones are personalized with one or more CVMs in order to be accepted in as wide a variety of locations as possible. Different terminal types support different CVMs. Chip cards can be configured to allow both online and offline authorization, depending on the circumstances. Most EMV chip transactions are now authorized online. See Figure 19 below for the phases of a NFC transaction initiated via a phone. The protocol phases are card authentication, cardholder verification and transaction authorization. Figure 19: Phases of a NFC transaction 45

46 The payment processing flow in high-level steps from the EMV book is displayed in below Figure 20. The combination selection in this figure matches the start authentication phase of the previous figure. Figure 20: High-level payment steps [42] For the MBT validation use case a few steps from the payment processing steps will be put into the model. Based on the small steps the evaluation of the security case can be executed. In future research the model can be extended to do system validations against a more detailed model. The approach in this research is to start with more detailed payment processing steps, resulting in a high-level model. This model can be used as input for a future verification process. For this research a part of this detailed model will be used to validate if MBT can be used and to validate all necessary steps to come to this verification. This model will be put into a MBT tool. Security cases will be extracted from this simple model. A simple POS simulator will be used to show if and how security testing can be executed. 46

47 First, we start with the more detailed model. This model will zoom into the next steps: Starting a transaction Authentication and verification Authorization Transaction completion (success or aborted) Start transaction: The POS detects exact one NFC contactless phone Phone sends pseudo ATR to the POS Connection is set-up for exchanging APDU messages Authentication and verification phase: POS activates the PPSE APP by sending an APDU containing a SELECT' command with AID POS interacts with PPSE to get a list of available payment APP s on the NFC enabled phone. Each APP is represented by a unique AID, in order of user preference Based on user preferences one AID is chosen by the POS and executes the protocol Initiate Application Process initiates the transaction process and provides to the phone a PDOL which contains necessary data. The phone returns the AIP and the AFL. The AIP shows which APP s are supported by the phone. The AFL list all files that are required for the transaction. The GET PROCESSING OPTION command initiates the transaction within the phone. The phone returns the AIP and AFL [49] The read application data reads all data from the Application File Locator (AFL). The AFL identifies the files and records which are necessary for the transaction Authorization and transaction completion phase: Data authentication (SDA, DDA), processing restrictions, cardholder verification and POS risk management (safety measures to protect from fraud) The Figure 21 below is displaying the steps of the interaction between the POS and phone. Step 4 and 5, selecting the AID, will be part of the simple model used for the security test case. Figure 21: Interaction between the phone and POS 47

48 Initialization phase When a phone or card is reset, it will respond with a pseudo ATR that specifies how the POS must interface with the phone. ATR is for contact cards and is specified in ISO/IEC For contactless cards, it is the POS that generates the ATR. The ATR is constructed based on the Answer To Select (ATS) for ISO/IEC Type A cards. As states in the manual : The PICC shall send its ATS as answer to the request ATS. The PICC shall only answer to the RATS if the RATS is received directly after the selection. The ATR message contains information on proposed phone communication parameters, phone APP issuer, APP selection options, country code and more. See attachment [18 Appendix G: NFC transaction flow] for more ATR details APP selection ISO/IEC defines the process for APP selection. The way APP selection is processed is described in book 1 of EMV [47]. Application selection is the first step after the ATR. It has the function to select the ADF for the transaction process. To get the right ADF the terminal reads out the necessary information to select the ADF. If there is no PPSE, the terminal will use a list of AIDs and get the right by trying. If the card is an NFC card then it will have Paypass Payment System Environment (PPSE) as 2PAY.SYS.DDF01. A PPSE application consist the following parts: A set of files in the phone providing data customised by the issuer POS data provided by the acquirer or the merchant An application protocol agreed upon by both the phone and POS The response from the phone consists of returning the FCI. An AID is defined within ISO/IEC A data label that differentiates payment systems and products. The card issuer uses the data label to identify an application on the card or terminal. Cards and terminals use AIDs to determine which applications are mutually supported, as both the card and the terminal must support the same AID to initiate a transaction. Both cards and terminals may support multiple AIDs. An AID consists of two components, an RID (alpha and numeric) and a PIX (numeric only). Applications supported by the terminal are identified by AIDs conforming to ISO/IEC Applications supported by the ICC are identified by DF Names conforming to ISO/IEC An AID is used to address an APP in the card, phone or ICC. An AID consists of a registered application provider identifier (RID) of five bytes, which is issued by the ISO/IEC registration authority. This is followed by a proprietary application identifier extension (PIX), which enables the application provider to differentiate among the different applications offered. The AID is printed on the EMV cardholder receipts. 48

49 Based on ISO/IEC the application selection uses at least one of the following application selection methods: 1. Implicit APP selection 2. Application selection using an AID as DF name 3. Application selection using EF.DIR or EF.ATR If an application is implicitly selected, then an APP identifier should be present in the historical bytes or in the initial data string. Such a presence denotes an implicitly selected application. If an application is implicitly selected with no application identifier in the historical bytes and in the initial data string, then an application identifier will be present in EF.ATR. The implicit application selection is not recommended for multi-application PICC s. The process of application selection is described in two steps: Create a list of ICC applications that are supported by the terminal Select the application to be run from the list generated above The set of data that the ICC contains in support of a given application is defined by an ADF selected by the terminal using a SELECT command and an AFL returned by the ICC in response to a GET PROCESSING OPTIONS command [47] GET PROCESSING OPTIONS The purpose of the GET PROCESSING OPTIONS initiated by the POS is to see if the phone should be used. Three data elements read in the previous step are checked: 1. Application version number 2. Application usage control 3. Application effective or expiration dates checking If any of these checks fails, the phone is not necessarily declined. The POS sets the appropriate bit in the Terminal Verification Results (TVR), the components of which form the basis of an accept or decline decision later in the transaction flow. The GET PROCESSING OPTIONS command initiates the transaction within the ICC. The ICC returns the AIP and the AFL. See for more information about the GET PROCESSING OPTIONS attachment [18.2 GET PROCESSING OPTIONS]. 49

50 Verification and authentication phase Cardholder verification checks that the person using the card/phone is the cardholder. The card/phone contains a list of verification methods that it supports, and the conditions under which they should be applied. During cardholder verification, the POS determines which, if any, Cardholder Verification Method (CVM) is to be performed. Note that at this stage the card/phone has already been removed from the POS contactless field, hence, if a cardholder verification method is required then this will happen without the need for the card/phone to be presented again. There are five different methods to verify the cardholder which are already discussed in paragraph [ Online and offline PIN validation]. Card authentication can, for example, be done using a challenge-response mechanism (DDA in the EMV standard) by invoking the INTERNAL AUTHENTICATE instruction. Cardholder verification can be done offline by checking the PIN code using the VERIFY instruction. In this case the PIN can be sent to the card/phone either in plaintext or encrypted. Checking the PIN can also be done online. In this case the PIN is sent to the bank back-end for checking Transaction completion phase The transactions completion phase is the last phase in this transaction process. Transactions can be performed online, offline and they can be rejected. For the actual transaction one or two cryptograms are requested using the GENERATE AC instruction. The cryptogram that is generated for the online authorization request is termed the ARQC and the cryptogram that is generated by signing data elements when a chip approves the payment for clearing and settlement is known as the Transaction Certificate (TC). If the transaction is declined, the chip will generate a cryptogram known as an AAC. Payment will be rejected if required transaction disposition is failing. Online processing enables the card issuer to analyses the transaction details and decide whether it wishes to authorize or reject the transaction. This allows the issuer to check the account status and apply criteria based upon acceptable limits of risk defined by the card issuer, the payment scheme and the acquirer. The POS indicates to the cardholder the outcome of the NFC transaction. If the transaction has been authorized then payment can be submitted for settlement. If there is an issue in update processing this requires the cardholder to present the card/phone to the RF field for a second time. 50

51 4.3 Identified weaknesses In this chapter the identified weaknesses are discussed. Both of the NFC protocols, ISO/IEC and ISO/IEC are investigated. Also the EMV protocol is examined because the EMV is built on top of the ISO/IEC and uses these commands for interchange. The transmission layer is implemented in the contactless ISO/IEC part and the application layer is reflecting in the ISO/IEC part. Case 1 describes the possible weakness in the ISO/IEC error handling related to the POS activation sequence for card type A (contactless). Case 2 describes the situation where the card and phone contact the POS at (almost) the same time. The last case describes the possible weakness were the phone contains multiple APP s. The simple model and test security case validation is only worked out for case 3 because case 1 and 2 were not feasible to work out in the reserved time. This can be part of a future research Case 1: ISO/IEC 14443: POS activation sequence, error handling In the transmission layer of ISO/IEC there should be a behaviour of the POS related to error detection and recovery. When looking at the error detection and recovery of the POS, there are multiple error handling situation described in this chapter. When the POS tries to setup a contactless connection with a device at the same moment a protocol or transmission error can occur. This error leads to unavailability with the risk not informing the user correctly about the exact error. Not informing the user can lead to incorrect recovery options. The following errors should be detected by the POS: 1. Transmission error. The POS should attempt error recovery by trying the following techniques in the order shown: Re-transmission of blocks (optional) Use of DESELECT request Ignore the phone 2. Protocol error (infringement of protocol control byte coding or protocol rules). The POS should attempt error recovery by trying the following techniques: Use of DESELECT request Ignore the phone The following errors should be detected by the phone: Transmission error Protocol error (infringement of the protocol rules) 51

52 The phone should attempt no error recovery. The phone should always return to receive mode when a transmission error or a protocol error occurs and it should accept a DESELECT request at any time. Several options to react on errors and several options for recovery results in risk not choosing the best options. See appendix [16 Appendix E: Error detection] for the simple UPPAAL MBT sequence diagram regarding the activation sequence of the POS as part of ISO/IEC / Case 2: ISO/IEC 14443: Phone and card contacting POS What happens when there is a phone and card (at the same time) in the reader s field trying to do a contactless payment? For example when the card is in the flip over of the phone. The ISO/IEC protocol should recognize a collision and send an error back that the payment is not executed. Possible weakness is the inconsistency in behaviour which can lead to different results of payment processing and in most cases to unavailability. In this case also transaction data can be retrieved from the POS, which includes information about the payment. This situation is described at the end of this chapter. What do the standards EMV and ISO/IEC specify in this case? EMV, the primary standard for contactless card payments: To ensure that there is only one card in the Field. The POS will not initiate a transaction when there is more than one PICC (card or phone) and it will reset (Figure 22). Figure 22: POS main loop EMV book D, reset PICC ISO/IEC 14443: the main standard for proximity card regarding collision [1]: Unlike EMV, ISO/IEC specifies no termination in the case of a collision. Instead, a race condition is created in which depending on the implementation of the POS and the UIDs of the cards available in the field one card will be selected 52

53 Conform the ISO/IEC, if the UID of a PICC (card of phone) is complete and known by the PCD (POS) the PCD can select the PICC without performing the anti-collision loop. This situation is displayed in Figure 23. Figure 23: Anti-collision loop If the UID is recognized step 2 till 10 can be skipped. So there looks an inconsistency in the behaviour. Several results can be archived: Transaction will be processed by either card or phone Error occurs, only present one card or card read failed Possible weakness is the inconsistency in behaviour which can lead to different results and in most cases to unavailability. When doing a payment and putting both card and mobile to POS. This case is not detailed in a model. Aad van Moorsel et al. [1] describes an attack on this collision procedure specified in the ISO/IEC protocol. In a contactless transaction, when more than one card is presented to the payment terminal's, the POS does not know which ICC to choose to complete the transaction. EMV specifies that the POS should not proceed when it detects a card collision, instead it should inform the user. In comparison, the ISO/IEC standard specifies that the POS should choose one card based on comparing the UIDs of the cards detected in the field. Van Moorsel et al. states that the implementation of contactless NFC readers in practice does not follow EMV's card collision algorithm, nor does it match the card collision procedure specified in ISO. He designed and implemented a malicious APP, which simulated an NFC card which the user needs to install on her phone. When trying to pay contactless by placing the card close to the phone, the APP was recognized by the POS before the card. Although the POS detects a card collision, it proceeds with the EMV protocol. This setup proofs that the APP can retrieve transaction data from the POS, which includes information about the payment. 53

54 4.3.3 Case 3: ISO/IEC : Phone with multiple payment APP s When a phone has a single APP for NFC payment processing the selection process is straightforward: Android settings features a dedicated view to the available option, that setting controls routing for a specific AID: the one reserved for PPSE. An example is A for MasterCard, which is the same AID for an NFC enabled phone. While the scenario for a single NFC payment APP is handled fine, the same approach does not work for combining multiple APP s related to different wallets. The problem is the directory view presented by PPSE. Because PPSE is routed to one specific APP, at any point only the payment options associated with that application are available for NFC payments. Each APP application maintains its own directory of cards unaware of other wallets installed on the same device. Using another card associated with a different mobile payment application requires changing the PPSE routing. The availability of the payment application relies on the capability to route the APDU s to the correct APP. The correct payment APP might become unavailable in case this routing is impacted. When an APP is installed on the phone, the corresponding AID is registered in the routing table of the NFC controller. See Figure 24 for the routing details. Figure 24: APP choice architecture [53] There are two identified risks in this situation: 1. Default APP (with an AID) changed to a different APP 2. Routing changed in not existing (or corrupt) APP Situation 1: When multiple APP s are installed on the phone EMV states it should take the default payment APP or give priority to the application which is running and visible in the phone s screen. The NFC protocol does not have additional checks to guarantee this selection. The possible weakness is the NFC protocol can execute a payment with an unwanted or even malicious APP or if the routing table is corrupted, in both cases the payment will fail. The EMV protocol is selecting the APP with the highest priority which is used in the NFC protocol for APDU interchange. 54

55 Situation 2: It can be possible with root privileges to change this routing table and delete or corrupt the entries in the routing table. In this case the preferred APP cannot be determined by the NFC controller. When the NFC controller receives the SELECT AID command there will be an AID conflict. This will cause unavailability of the APP to the POS. How NFC protocol operates: Bring phone into the induction field of the POS The POS detects the presence of an NFC contactless type-4 tag (Android calls this an ISO-Dep type [76]) Connection is set-up for exchanging APDU s, POS activates the PPSE application by sending an APDU containing a SELECT command with the AID for PPSE POS interacts with PPSE to get a list of payment APP s available on the phone operating in NFC card-emulation mode. Each app is represented by a unique AID, in order of user preference Based on user preferences one of these options is chosen by the POS The POS selects the chosen payment APP by AID and executes the protocol The HCE architecture in Android is based around service components (called HCE Services), that function as applications installed on the emulated card. Each service is identified by an AID, defined by the ISO/IEC 7816/4 standard. When the user taps his device to an NFC reader, a proper application is selected based on the requested AID. Setting in the phone: In the phone payment services, the default NFC payment APP can be set Also there is a setting for giving priority to the application which is active and running in the front screen The process of initialization of a contactless transaction is displayed in the Figure 25. The commands displayed are part of the EMV protocol using the commands for interchange described in ISO/IEX Figure 25: Initialization of a contactless transaction 55

56 The contactless transaction starts with the mobile sending the ATR. The POS then requests the list of APP s with priority indicators from the phone. The phone responds with this list consisting of an AID with a priority indicator per supported application. The POS selects the supported application with the highest priority and the phone responds whether the AID was selected correctly (message I.5). The terminal requests the processing options (message I.6) and the phone responds with the AIP and AFL. The terminal requests the record indicated by the AFL and the card returns these records. Service selection [74]: when the user taps a device to an NFC reader, the Android system needs to know which service the NFC reader actually wants to talk to. This is where the ISO/IEC specification comes in: it defines a way to select applications using an AID. An AID consists of up to 16 bytes. If you are emulating phone for an existing NFC reader infrastructure, the AIDs that those readers are looking for are typically well-known and publicly registered (example: AIDs of payment networks such as Visa and MasterCard). The ISO/IEC specification also defines the concept of multiple logical channels, where you can have multiple parallel APDU exchanges on separate logical channels. Android s HCE implementation however only supports a single logical channel, so there s only a single-threaded exchange of APDU s. Android uses the AID to determine which HCE service the reader wants to talk to. Typically, the first APDU an NFC reader sends to your device is a SELECT AID APDU; this APDU contains the AID that the reader wants to talk to. Android extracts that AID from the APDU, resolves it to an HCE service, then forwards that APDU to the resolved service. Android will keep forwarding new APDU s from the POS to the phone, until either: 1. POS sends another SELECT AID APDU, which the OS resolves to a different service 2. NFC link between the POS and phone is gone 4.4 Security evaluation Based on the identified weaknesses discussed in chapter [4.3 Identified weaknesses] one weakness will be checked against a model. Only one case will be handled because of the time-consuming activities of creating and validating a model and also setting up a POS simulator, which can interact with the model. Case three discussed in [4.3.3 Case 3: ISO/IEC : Phone with multiple payment APP s] will be taken for the security evaluation. Only a small part of the validation will be put in the model. Future research can extend this model or can look into the other possible cases. This simple use case describes a scenario where the user makes a NFC payment with a phone on which multiple payment APP s installed and only one is active. The user indicates that he wants to use that payment APP to make the contactless payment. 56

57 Once the user has completed this action he presents his phone to the POS to process the payment transaction. In this case the AID with the highest priority should be selected and used in the payment transaction flow. Figure 26: Select AID The AID is set after the SELECT AID which is part of the selection process (Figure 26). An invalid AID in the routing table also can lead to an AID conflict during payment processing. To validate if a POS system handles this AID conflict correctly a simple model can be used which will be explained in [6.3 Simple UPPAAL model]. The input of this model should be the correct routing table with valid AID values so the model knows the possible AID s. In the simple model I used only the values valid and invalid AID as an example. 57

58 5 Security modelling In this chapter the high-level model related to multiple APP s on a phone will be detailed. The process flow and steps will be explained in more detail. This high-level model will not be used for validation, a small part will be taken from this model to validate the security case. The main validation in this case is the check if the AID used for the payment is unique during payment processing. This check will be put into the simple model explained in chapter [5.2 Simple validation model]. The validation will be on the correct AID which is executed by the POS. The POS will be a black box and in the simulation a signal is sent to the POS to validate if the response is expected. The model can be used to recognize a malicious implementation of a POS. 5.1 Detailed model In the high-level model there two main parts, the phone and the POS. The phone interacts with the POS and has payment APP s available. The POS has the function of checking the PSE and selecting one unique APP, based on priority given by the user. The following main items in the payment flow will be discussed: 1. Activating the APP on the phone 2. Initialization process 3. Select APP by the POS 4. GET PROCESSING OPTIONS 5. Verification 6. Transaction result These parts of the process should be put into the detailed model to evaluate the protocol behaviour. There is an interaction between the phone and the POS, see Figure 27, so between POS and phone communication channels should be defined to validate the behaviour of the POS and protocol against the model. In this research those channels are not defined for the detailed model. Only for the simple model in described in chapter [5.2 Simple validation model] the input and output channels are described. Figure 27: Interaction POS and phone 58

59 5.1.1 Start APP Starting a selected APP on the phone is done by the user. The user does not need to start the APP if the phone is in sleep mode. Based on the preferences in the setup configuration of the phone the selected APP will start or the user already started the APP he wants to use. This part is not described in the protocol. Regarding entering a PIN while executing NFC-payments: with maximum amount of 25 euro can be paid without entering a pin code. This can be configured in the setting of the APP in the phone. See Figure 28 for the process to start the APP on the phone. This input of this process is: Start initiate payment by selecting and starting APP. The output is: POS contacted to execute the NFC payment. Figure 28: Start APP on phone process 59

60 5.1.2 Initialisation In the initialization the POS sets up a NFC interface between the phone (ICC) and POS. This consist of steps in pre-processing and protocol activation. Pre-processing can set the Entry Point Pre-Processing Indicators per reader Combination {AID - Kernel ID}. Examples are: Status Check Requested Contactless Application Not Allowed Zero Amount Reader CVM Required Limit Exceeded Reader Contactless Floor Limit Exceeded. During protocol activation, polling is started for card/phone discovery. The process consists of two steps: pre-processing and protocol activation, see Figure 29. The input is: POS starts pre-processing and the output is: ICC found and ready for the POS to select the APP. Figure 29: Initialization phase process Select APP To select the APP the POS uses the PSE method, which means the PSE environment is available. The POS performs the following steps during APP selection: Step 1, POS selects PPSE: The POS begins by selecting the PPSE using a SELECT command using a file name 2PAY.SYS.DDF01. The SELECT command is used to perform application selection. This command is wrapped in a C-APDU protocol to send from POS to phone. The phone will respond with R-APDU containing FCI with all information about selected application. This establishes the PPSE and makes the Payment System Directory accessible If the ICC is blocked or the SELECT command is not supported (return of SW1 SW2 = '6A81') and the POS terminates the session 60

61 If there is no PSE in the ICC, the ICC returns '6A82' ( File not found ) in response to the SELECT command for the PSE If the PSE is blocked, the ICC returns '6283' If the ICC returns SW1 SW2 = '9000', the POS proceeds to the next step If the card returns any other value in SW1 SW2, the POS uses the List of AIDs method If any error, including a SW1 SW2 different from '90 00' or '6A 83' the POS clears the candidate list and restart the application selection process using the List of AIDs method find the matching applications Step 2, POS reads FCI: The POS uses the directory SFI from the FCI returned and reads all the records in the Payment System directory beginning with record number 1 and continuing with successive records until the ICC returns SW1 SW2 = '6A83', which indicates that the record number requested does not exist. The ICC returns '6A83' if the record number in the READ RECORD command is greater than the number of the last record in the file. If the card returns SW1 SW2 = '6A83' in response to a READ RECORD for record number 1 for the Payment System Directory For each record in the Payment System Directory, the POS begins with the first directory entry and processes each directory entry in turn. If there are no directory entries in the record, the POS proceeds to the next directory record Step 3, POS gets AID s: If the ADF name in the directory entry matches one of the APP s supported by the POS, the application joins the candidate list for final APP selection under control of the ASI maintained in the POS for that AID. The ASI indicates whether the AID in the POS match exactly (both in length and name) or need only partially match the associated ADF Name in the directory entry (tag '4F') The application is added to the candidate list in either of the following cases: The ADF Name in the directory entry retrieved is an exact match, or the ASI for the AID in the POS indicates that a partial match is allowed. The application is not added to the candidate list if the ADF name in the directory entry retrieved is not an exact match and the ASI for the AID in the POS indicates that an exact match is required Step 4, POS should get at least one matching ADF name: When the POS finishes processing all entries in the last record of the Payment System Directory, all ADF s that can be found by this procedure have been determined. The search and the candidate list are complete. If at least one matching ADF Name was found, the POS continues processing as described in step 6, final selection Step 5, POS generates an error if no match: If previous steps have no match for applications supported by the POS, the POS uses a different selection of AID s method. This occurs when PSE is not supported which is not the case in our setup. Another possibility is the AID is not matched. This will generate an error in our case. So, the process stops here 61

62 Step 6, final AID selection: The POS should support the ability to allow the cardholder to select an APP or to confirm the APP proposed by the POS. This is not the case in a PSE environment When the POS displays an APP to the cardholder, it should display (not in our PSE environment): 1. The Application Preferred Name, if present and if the Issuer Code Table Index indicating the part of ISO/IEC 8859 to use is present and supported by the POS 2. Otherwise the Application Label, if present, by using the common character set of ISO/IEC 8859 Once the POS determines the list of supported APP s, it proceeds as follows: 1. If there are no supported APP s, the transaction is terminated 2. If there is only one supported application, the POS checks bit 8 of the card s Application Priority Indicator for that application if present If b8 = '0', the POS selects the APP If b8 = '1' and the POS provides for confirmation by the cardholder, the POS requests confirmation and selects the application if the cardholder approves. If the POS does not provide for confirmation by the cardholder, or if the POS requests confirmation and the cardholder does not approve, the POS terminates the session In our case there is a PSE available and so the POS does not support the ability to allow the cardholder to select an application. In this case the POS makes the selection itself. The POS selects the highest priority application that does not require cardholder confirmation (that is, the card s Application Priority Indicator b8 = '0') from the list of supported applications. Once the APP is determined by the POS, the APP is selected. A SELECT command is done by the POS for the application using the ADF name field or the DF Name field from the FCI found during the building of the candidate list. On successful selection of the APP to be used: When SW1 SW2 = '9000' returned in response to the final SELECT command the POS sets the value of the POS data element Application Identifier (AID) POS (tag '9F06') to the same value as the DF Name (tag '84') returned in the FCI. In this case the response contains no format errors and the AID used in the final SELECT command exactly matches the DF Name (tag '84') returned by the ICC in the FCI. The FCI also contains application details. More specific, it contains the PDOL with certain fields, for example amount, terminal country code, terminal verification results and transaction date, needed by the POS for the next step GET PROCESSING OPTIONS. So, the transaction processing will continue with the command GET PROCESSING OPTIONS. If the command returns other than '9000' in SW1 SW2 or the SELECT response contains format errors processing will terminate. Below the process is displayed in Figure

63 Figure 30: Select APP by POS process The input of this process: Start AID selection by POS. The output: AID selected and GPO initiated. Begin initiate application processing GET PROCESSING OPTIONS The GET PROCESSING OPTIONS command initiated by the POS starts the transaction within the ICC and provides to the card a PDOL which contains necessary data. The PDOL is stored in the FCI of the ADF and has the tag '9F38'. The ICC returns the AIP and the AFL. The AFL is used by the POS to read the data records from the PICC. These records contain a variety of information, for example the Primary Account Number (PAN), the expiry date and some more. The AFL also indicates if any of the data will be provided for the authentication process. As a result, the ICC is in control what files can be read. The POS responds with the PDOL related data encoded according to the ICC s previous PDOL received in the previous message. The purpose of the GPO options is to see if the phone/card should be used. 63

64 Three data elements read in the previous step are checked: 1. Application version number 2. Application usage control 3. Application effective/expiration dates checking The data, which the terminal should send to the card is given in the PDOL. The PDOL only contains the expected tag name and length. During Read Application Data, the POS uses the READ RECORD command to retrieve the ICC data necessary to process the transaction. The READ RECORD command reads a file record in a linear file. The response from the ICC consists of returning the record, '9000' indicates a successful execution of the command. The POS requests the records according to the AFL and the ICC follows these requests with the according responses. Figure 31: GPO process Verification Optional: The verification ( VERIFY ) command initiates in the ICC the comparison of the Transaction PIN Data sent in the data field of the command with the reference PIN data associated with the application. The manner in which the comparison is performed is proprietary to the application in the ICC. The VERIFY command applies when the Cardholder Verification Method (CVM) chosen from the CVM List is an offline PIN. Figure 32: Verify process 64

65 5.1.6 Transaction result Transaction completed can be transaction successful or transaction aborted. Figure 33: Transaction result 5.2 Simple validation model To validate a security characteristic using model-based testing the model will be simplified. To ensure the steps to validate are clear and the model used is simple it will not take long time to evaluate. If the model is complex and not easy to understand is much more difficult to validate. The simple model validates the AID which should be existing for the POS, unique and having the same value during the payment processing. Based on these values the transaction will be successful or will abort. Only this AID item will be validated so all others steps in the process will not be taken into account. See Figure 34 for the steps which will be part of the simple model. Figure 34: Validation steps The steps four and five in the above Figure 34 results in the simple model displayed in Figure

66 The simple validation model has five statuses: 1. Idle; in which the POS is waiting for the RF signal of the phone 2. Start transaction; here the phone is put into the RF field of the POS 3. Wait; POS is evaluating the AID 4. Success transaction; based on AID ok (in this case all other dependencies of to get a successful transaction are excluded 5. Failed transaction; if the AID is not valid Figure 35: POS selects AID parameter In the simple model a parameter is used to simulate the AID value. This parameter is selected by the POS during the transaction processing. When this AID value is recognized and correct the transaction will result in successful, otherwise this will fail (see Figure 35). In the model this process can be executed multiple times. 5.3 Simple POS simulator To validate the AID testcase against a POS simulator a simple test POS can be used which is implemented in JAVA code and simulating the protocol steps. The POS simulates the AID select and in the simulation setup the similar states (AID valid, AID invalid and idle) are defined. Whenever the simulator POS gets an expected request it will validate the outcome and will give the response. This POS simulator will only validate the AID parameter to show how this validation can be executed. When other security characteristics needs to be validated the POS simulator needs to be extended. During simulation the POS states are synchronized with the model to show the correct behaviour of the handling of an NFC payment. In case of a valid AID the transaction will be successful and in case of invalid AID the transaction will fail. So, whenever a state is entered where a response should be given to the model checker this will be done. Also, whenever a request is done in a certain state by the model checker the code expects the same. The POS simulator contains a NFCpayment.java which is doing the select of the AID and an interface to the model checker. 66

67 6 Security evaluation using Model Based Testing For modelling the simple model UPPAAL is used. Examples of modelling tools are UPPAAL [65][66] and JTorX [23][67].The Model Based test tool used for this research is UPPAAL. Reason for this usage is because the OU course Software Validation and Verification was using UPPAAL and I got familiar with the tool which was sufficient for my research. 6.1 Test environment The model-based testing setup will be using timer properties. Time is considered continuous, deadlines are constrained by integers. In the model and IUT these timer properties will be translated to functional properties. If for example if a timer is executed in five seconds the functionality is assumed to be ok, in our case the AID validation is ok whenever the timer is within the five and ten seconds. So, in the model and IUT the validations are on timers because the setup used for validation currently only setup for timers. For the real testing this should be extended to the real functionality. The tests are generated directly from the model, executed and the system responses checked at the same time, online by the TRON while connected to the IUT, avoiding intermediate test suites. TRON has a build-in socket adapter to communicate with remote IUTs via TCP/IP sockets. The adapter expects a port (host) number as a parameter to create a server socket and listen for incoming connections of the remote listening socket. TRON generates randomized input sequences based on environment assumptions, executes them via the adapter and monitors the incoming outputs and checks these against IUT requirements at the same time. For test setup I consider a closed system, where implementation together with its environment can be isolated from the rest of the world. The test setup is using eclipse as the Java environment where the TRON, adapter and NFC payment simulator is implemented. The test setup uses TCP/IP socket for interaction between TRON socket adapter and IUT (similar setup as used in [21]). In real world the communication is based on RF but in this case the data which is transferred is validated to this test setup can be used. 67

68 The test setup is displayed in Figure 36. Figure 36: Test setup The NFCPaymentIOHandler the adapter between the POS and the TRON. This NFCPaymentIOHandler contains the following functionality: Input and output; configure function contains StartTransaction, Failed Transaction and SuccesTransaction, analogue to the transitions of the model When the function run receives a value equal to the value of the StartTransaction this means TRON sent a StartTransaction which can be forwarded to the NFCPayment model If the NFCPayment model needs to send a message back, this will be one of the output values (part of the OutcomeTransaction ) In the NFCPaymentIOHandler configure function the time out and time unit is described The complete test will be executed on Windows machine including UPPAAL end Eclipse environment. On windows directory in the NFCPayment folder there are three batch files for executing the tests: 1. start-nfcpayment.bat: starting the NFC Payment automate (model): java -cp dist/nfcpayment.jar com.uppaal.nfcpayment.main -M 2. start-tron.bat: starting the tests with the TRON:..\tron -P 10,100 -F 300 -I SocketAdapter -v 9 NFCPayment.xml -- localhost 68

69 3. start-test.bat: starting both points above: start java -cp dist/nfcpayment.jar com.uppaal.nfcpayment.main -M 0..\tron -P 10,100 -F 300 -I SocketAdapter -v 9 NFCPayment.xml -- localhost The NFCPayment xml file (output file of the model) should be available in the TRON folder as input for the JAVA code which is also holding the TRON and adapter software. Also the NFCPayment.jar file (exported via Eclipse) should be available in the windows \dist folder. During the test the model can be changed to check the response of the POS simulator. Also, the POS can be changed and after exporting the new.jar file the test can be repeated. For testing I validated several ok situations in the model and also changed some timer values in the model to see how the TRON is responding. 6.2 UPPAAL UPPAAL tool UPPAAL is a toolbox for verification of real-time systems developed by Uppsala University and Aalborg University. UPPAAL is an integrated tool environment for modelling, simulation and, verification of real-time embedded systems[22]. Typical application areas of UPPAAL includes real-time controllers and communication protocols in particular, those where timing aspects are critical. This means also that UPPAAL can be used as a tool for modelling a part of the NFC communication protocol and also for verification of security related test cases of the NFC payment protocol. UPPAAL makes use of Labelled Transition Systems (LTS). The main usage of LTS s is to describe the visible behaviour of a system. Labels are used to identify which state actions can be performed. UPPAAL consists of a timed automata, which means a finite automata, clock constraints and the reset possibility of a clock. A clock constraint is associated with each location of the automaton. This constraint is called the invariant of the location. Along the transitions of the automaton, clock values can be compared to integers. These comparisons form guards that can enable or disable transitions and by doing so constrain the possible behaviours of the automaton. In the Figure 37 below a lamp example is given, y is an example of a clock variable, which also can be a guard or a location invariant. 69

70 Figure 37: Timed automata, lamp example Timing is important while doing a contactless payment but also functionality can be checked by UPPAAL. For this reason, timed automata can be used for modelling. The definition of a timed automaton is a six tuple: 1. Finite set of actions called the alphabet 2. Finite set of locations S 3. S0 part of S is a starting location 4. Finite set of X is a set of clocks 5. Function I that gives the invariant of each location. Location L is mapping from locations to clock constraint called the location invariant 6. Finite set of T is a set of transitions See appendix [19 Appendix H: UPPAAL] for more details about UPPAAL. UPPAAL uses a simplified version of Computational Tree Logic (CTL) as its query language. The query language consists of path formula and state formula. The state formula describes individual states and the path formula quantify over paths of the model. A state formula is an expression that can be evaluated for a state, example: x>1, i==2, x<=3. Path formulas can be classified into reachability (EF), safety (AG/EG) and liveness properties (AF/ --->). Explanation of A;F;E;G: A: for all paths from the given state E: for an existing path from the given state F: for a state along the path ("future") G: for all states along the path ("globally") For the research on security properties of the contactless payment protocol a safety and liveness property will be executed on the simple NFC payment model as a part of the evaluation. Example of safety related questions: Selection of the correct protocol is always the case when doing a successful contactless payment. Example of liveness related questions: If the AID is valid the transaction will be successful. 70

71 6.2.2 UPPAAL simulator Before generating tests from the simple NFC Payment model, it is helpful to use an analyser to validate the model program. Also it is helpful to visualize the behaviour and perform safety and liveness checks. An offline test generator (see chapter Offline testing) generates test cases and expected test results from the model program, which can later be executed and checked by a test runner connected to the IUT. The simulation tool in UPPAAL can be used for a step-by-step simulation where variable values at each step can be verified. Good for observing of the overall system behaviour. More information about the UPPAAL simulator can be found in appendix [19.1 Features of UPPAAL] Online testing For the model-based testing tool UPPAAL-TRON (testing real-time system online) will be used. This combines test generation and execution. Here the test generator interactively interprets the model and interacts with the IUT. Only a single test input is generated from the model which is then immediately executed on the IUT. The produced output by the IUT and time of occurrence are checked against the specification, a new input is produced and so forth until it is decided to end the test, or an error is detected. Inputs are chosen randomly. UPPAAL-TRON is a tool for black-box (Figure 38) conformance testing of real-time systems [20] at a system level against timed automata models using observable timed I/O relation as correctness criterion. Figure 38: UPPAAL-TRON online testing for real time systems For this research UPPAAL-TRON is used to validate one security property against the IUT. An adapter is used between the IUT and TRON, which translates inputs from a model to physical inputs to the IUT and recognizes physical outputs to outputs in the model. 71

72 Advantage of this online testing is completeness of the testing and also possibility of stressful testing. Once the connection is established the adapter consists of two threads, one for outputs and the other for inputs. The listening thread responds to the packet-commands. TRON is sending one packet per command. In appendix [19.2 Coffee Machine] an example of a coffee machine is given and shows how UPPAAL-TRON can be used Offline testing UPPAAL-Yggdrasil is an offline test case generator. The tool takes models created in UPPAAL and creates a suite of test cases that cover all required test purposes and all transitions in the model. Yggdrasil expects a deterministic model with no deadlocks and will generate traces for edge coverage. See appendix [19.1 Features of UPPAAL] for more information about UPPAAL-Yggdrasil. In this research the test setup used is online testing see chapter [6.1 Test environment] for the details. The validation of the model can first be done off-line by checking for example if there are no deadlocks in the model. This off-line testing, I executed first on the simple model to check the behaviour. 6.3 Simple UPPAAL model Based on the starting point of using simple steps and the coffee machine example described in appendix [19.2 Coffee Machine] I created first a simple AID validation model. This model can be extended to increase the functionality of the AID processing and similar the testing can be extended. The model is based on interaction between a phone and a simulator POS (IUT). The NFCPayment model contains two systems, the NFCPayment which is the execution of a transaction and a POS which results in the transaction status and outcome of the transaction. The interaction of the model only describes the AID selection and based on an integer value the outcome is ok or not ok. The simple NFCPayment model has one state for the POS which defines the transaction status. This status can have three values: start_transaction failed_transaction: whenever there is not a valid AID during the payment processing or the AID is not filled correctly succesfull_transaction: whenever there is an exact match on AID and all other checks are positive 72

73 In UPPAAL this POS part is displayed in the Figure 39 below: Figure 39: UPPAAL transaction statuses The simple model NFCPayment which is has four states: 1. Idle: which is the initial state when there is no transaction started 2. Wait: which is the state when a transaction is about to start (user taps the phone to the POS) 3. AID_VALID: whenever there is one AID used in the flow which is correct validated by the POS and the same during transaction processing 4. AID_INVALID: whenever there is not one AID used in the flow In this model the AID_VALID check is based on the value of x, which is a timer and set as (an example) x > 5 and x < 10. The values of x >= 10 results in the AID_INVALID state which results finally in a failed transaction. See the Figure 40 below for the model. Figure 40: NFC payment process The next screen-print of the UPPAAL model displayed in Figure 41 shows the simulator working. Whenever this simulator is running the values of the timer x will be varying, so both states of AID_VALID and AID_INVALID will be simulated in the model. 73

74 Figure 41: Concrete simulator in UPPAAL In this example the AID value is invalid which leads to a failed transaction in the model. Next to the model an adapter is needed to communicate with the POS. This is also part of the model for defining the input and the output channel. The adapter has two states with the channels input and output, see the Figure 42. Figure 42: Adapter in UPPAAL For transferring data between the model and the POS in this simple model an IntAdapter is defined. The IntAdapter has the same purpose as Adapter, but in addition it can also transfer (and delay) an integer data value (in the test setup we use an integer value to validate the AID instead of a string). In this model the AID string is defined as an integer which is again an example. In real this is a string value. This can be changed in a future model but will not be part of this research. For the IntAdapter the Figure 43 shows the flow. In this IntAdapter the data must be ready in the inpdata variable during inp. 74

75 Figure 43: IntAdapter in UPPAAL The UPPAAL NFCPayment model is saved into a xml document and added in appendix [19.4 Simple model in UPPAAL]. In this simple model the integer value can be changed to validate the response of the POS simulator. 6.4 Validate the security related test case As discussed, the test cases for security testing and evaluation will be set up for validating the availability and integrity of a small part of the NFC payment flow. Is it possible to validate those cases and what are the steps? This chapter describes the security related test cases related to the simple model. The checks first will be executed on simple the model. The safety and liveness property will be used as a part of the evaluation and executed on the validation of the simple model Validation of the simple model The validation of the simple model will be done by executing safety and liveness properties. The simple safety related questions, which are executed on the model: There is no deadlock in the simple model (as a small part of the protocol) Selection of a correct AID is the case when doing a successful contactless payment When using an incorrect AID, the payment will be unsuccessful The queries executed on the simple model are: A[] not deadlock A[] (NFCPayment.AID_VALID) imply not deadlock A[] (NFCPayment.AID_VALID) imply AID==1 A[] (NFCPayment.AID_INVALID) imply AID==0 75

76 Where: NFCPayment = system AID_VALID and AID_INVALID = state AID = parameter The liveness related questions: IF the POS validates the AID and this is valid (equals to 1) the state should be AID_VALID IF the POS validates the AID and this is invalid (not equals to 1) the state should be AID_INVALID E<> (NFCPayment.AID_VALID && AID==1) E<> (NFCPayment.AID_INVALID && AID==0) Where: NFCPayment = system AID_VALID and AID_INVALID = state AID = parameter The UPPAAL results after executing the validation cases are displayed in Figure 44. Figure 44: Results of safety and liveness checks 76

77 The executed validations on the model gave for all the properties the values satisfied. There can be more validations executed on the model but the executed validations are sufficient to conclude this simple model will be fine to validate the simple POS simulator POS validations against the simple model When validating the model against the POS simulator three situations are tested: 1. Checking the POS IUT with the expected outcome for valid transaction (AID_VALID) 2. Checking the POS IUT with the expected outcome for invalid transaction (AID_INVALID) 3. Checking the POS IUT with the unexpected outcome Situation 1: The TRON is validating the simple POS simulator against the model for the valid AID case, which means in our testcase: the transaction will be successful. The output of the validation is displayed in Figure 45. Conclusion: The output of the POS system is as expected and meets the model. So, with this model the expected behaviour can be validated. Figure 45: Validation of the IUT, happy flow Similar situation is the second case where the AID is invalid. In this situation also the TRON is validating the behaviour of the POS system based on the model. The result is the transaction is not successful because the AID is not valid, this is also expected. 77

78 In the last situation, number three, I changed the POS simulator and checked if the TRON will recognize the change and will see the wrong POS implementation. The POS simulator is changed and the integer based on which the AID_VALID is chosen is switched. In the new situation (as an example) the integer with a value more than 10 will result in AID_VALID instead of AID_INVALID, which is set in the model. See Figure 46 for the output of UPPAAL-TRON validating the wrong implementation of the POS. UPPAAL-TRON give an error: got unacceptable output, conform the model the output should be successful whilst the output of the implementation failed. Figure 46: UPPAAL-TRON validates the POS simulator Conclusion: Based on a simple security model as input, the TRON can recognize a wrong implementation. 78

79 7 Conclusions and future work In this paragraph the research results are given by summarizing the answers on the main and sub questions. Also a short explanation of noticed future work will be given. 7.1 Conclusions As discussed in the introduction the next three parts are input for the evaluation of the main question, What are possible security related weaknesses in the NFC protocol and how can Model Based Testing be used to validate these identified weaknesses? 1 Research of security related work and investigation of NFC security weaknesses 2 Outcome of comparison of behaviour of the security related test cases executed via the model against the expected behaviour 3 Execution of one of the test cases in a simulation environment First of all, when using a phone payment APP consumers, merchants and banks want to ensure the payment is executed successfully and private data is safe. The more secure the transaction data is, the better it is for all parties involved. However, the NFC protocol has been shown vulnerable in certain attacks, such as eavesdropping, data modification, or relay attacks. Regarding part 1 of the main question: Research of security related work and investigation of NFC security weaknesses. In this research some security related weaknesses in the NFC payment protocol are identified. Based on investigation of the protocol I found one of the weaknesses related to the error handling in the activation sequence of the POS. When the POS tries to setup a contactless connection with a phone or card a protocol or transmission error can occur. This can result in the risk not informing the user correctly of the exact error. Not informing the user can lead to incorrect user recovery options. Another weakness, based on related work, is the case were the phone and card are contacting the POS at the same time. In case multiple cards (or phones) brought into the RF field the ISO/IEC standard specifies that the POS should choose one card (or phone). EMV specifies that the POS should not proceed when it detects a collision. The payment should be terminated and the customer should be informed. The identified weakness is an inconsistent behaviour related to availability. In this situation the outcome can be multiple, the transaction will be processed by either card or phone or even the transaction will fail. Another risk is the retrieval of transaction data, which includes payment information. 79

80 My contribution for part one of the main question is the identification of the weakness, were the phone supports multiple NFC payment APP s from multiple financial issuers. This situation can introduce the risk of improper APP separation. The APP identifications are stored in a routing table on the phone. With root access this routing table can be changed. Issues in this routing table can result in unexpected behaviour. The AID used during payment processing is picked from this routing table. When this table is corrupted, the payment processing even will fail. Result is unavailability of the payment system and impact on the integrity of the payments flow. To validate if a POS system handles this AID conflict (security property related to availability) correctly a simple model can be used which I explained in [6.3 Simple UPPAAL model]. The input of this model should be a correct routing table with valid AID values so the model knows the set of valid AID s. In my simple model I used only the values valid and invalid AID as an example. In case of a valid AID the payment is successful. Regarding part 2 of the main question: Outcome of comparison of behaviour of the security related test cases executed via the model against the expected behaviour. First a detailed model is created of the security related case were multiple APP s are available on one single phone. Because of the complexity of the modelling this is simplified only by taking the SELECT AID step as part of a simple model. This simple model is validated with an AID which is correct and results in transaction successful. This behaviour is also the expected behaviour. Also the case were the AID conflicts is validated and results into an unsuccessful transaction. My contribution for part two of the main question is the design and creation of a simple security model which can be used to validate a certain property of a POS system. Regarding part 3 of the main question: Execution of one of the test cases in a simulation environment. The simple AID validation model is implemented in UPPAAL and used in a test environment by the model-based testing tool UPPAAL-TRON to validate the behaviour against the simple POS. Several test cases are executed and results were as expected. When changing the POS IUT this is recognized by the model. So, a POS can be validated by the model by executing the UPPAAL-TRON generated test cases. Also the simple model can be used to recognize a malicious POS. My contribution to part three of the main question is setting up a test environment to validate the security property related to availability and recognize a wrong implementation of the system. Overall evaluation: The NFC payment protocol contains security weaknesses. These weaknesses can be validated against a security model, which contains the expected behaviour. To create a detailed model of the NFC payment protocol is very difficult because of the complexity of the system. Creation of a valid detailed model will take a lot of time or even is impossible. It is like coding the complete system again. You should know the protocol in detail to create a valid model. Who validates the model if there are no errors? 80

81 In this research a small part of NFC payment processing is put into a model and MBT is used for validation. To validate a small part of the model can have advantage, just check the specific property against the model. In this case a check can be executed if a specific POS implementation is working fine against a certain property. A wrong POS implementation can be recognized. Be aware that the functionality, even if this is a small part, should be put correctly into the model to draw the correct conclusions. Furthermore, the UPPAAL test generation is randomized which means that satisfaction of coverage criteria is not very clear. Also, the problem with considering all cases is that their number can grow very large. Advantage of using MBT for this case is the test are generated directly from the model, executed and the system responses checked at the same time, online while connected (real time) to the IUT, thus avoiding huge test suites. In this research several sub questions were discussed and in the following part summarized. Sub questions: 1. What are the security requirements for evaluation? The security requirements I validated were based on availability and integrity, see chapter [3.2 Security requirements] for the details. Using NFC should be integer and available for the user, which means if multiple APP s are on the mobile those APP s should not interfere with each other and not result in AID conflicts. The payment should be executed with the correct AID and this AID should be the same during payment processing. 2. How does NFC work and how is the interaction implemented between the NFC enabled phone and POS when doing a payment? In this research in chapter [2 Research context: NFC payment architecture] the high-level NFC architecture is explained. The transaction flow is discussed and how the APP selection is done by the POS. For the validation of a simple simulator POS (IUT) a small part of the functionality is put into a simple model. 3. What (possible) security issues are known on the RF interface and data interaction between the NFC enabled phone and POS and what are the identified weaknesses? Possible security issues on RF and data interaction are data modification, relay and privacy attacks. Changing data during payment processing should not be possible. Other attacks are eavesdropping and replay discussed in chapter [3.1 NFC security threats]. Also, I investigated the possible weaknesses in the protocol. Three weaknesses were discussed in chapter [4 NFC protocol stack: Identified weaknesses]. The weakness which is selected for creating a simple model is related to multiple payment APP s on a phone. This situation can lead to a conflict in the routing table and unavailability of the payment application. A small part of the protocol is put into a model and used for validating the IUT. 81

82 4. What are details of the model? 5. How can the model be described and used as input for the MBT tool? 6. What MBT tool can be used? In this research first a detailed process model is given of the selection of the APP process, see chapter [5.1 Detailed model]. A simple model is extracted and discussed in chapter [5.2 Simple validation model]. Reason for this simple model is two ways, first place is with this simple model I can validate a simple implementation IUT, second the development of the detailed model costs lot of time because of the complexity and also the validation will take lot of time. The MBT tool used is UPPAAL. The model is created in UPPAAL. Online testing of the model is executed with UPPAAL-TRON. UPPAAL is explained in Chapter [6.2 UPPAAL]. Using UPPAAL makes it possible to simulate, debug and verify the security related items in a real time setting. 7. What security related test cases can be generated? The security related test cases generated from the simple model are summarized in chapter [6.4 Validate the security related test case]. The test cases are related to availability and integrity. Safety and liveness properties are successfully checked in the model. Example of a security related test case is: When using an incorrect AID, the payment will be unsuccessful. 8. What is the expected behaviour of the test cases and does this differ from the execution result within the model? The simple model is validated against an IUT and when changing the IUT the model can recognize the wrong implementation. The behaviour of the model when executing the test cases is as expected. The happy flow is resulting in a successful transaction and when the AID is invalid the payment will fail. Details of the results are summarized in chapter [6.4 Validate the security related test case]. 9. How can a proof of concept be executed in a simulation environment? The simulation environment using a simple model and simple POS simulator is discussed in chapter [6.1 Test ]. The test setup is using UPPAAL-TRON with input the simple NFCPayment xml model, Eclipse as the Java environment where the TRON, adapter and NFC payment simulator is implemented. The test setup uses TCP/IP socket for interaction between TRON socket adapter and IUT. In the real NFC world the communication is based on RF but in this simple test case the TCP/IP socket can be used as an interface between the TRON and IUT. 82

83 7.2 Future research In future research the simple model can be extended to a more detailed model. It should be clear what part of the model needs to be validated because a making complete model of an IUT will be difficult. To create and validate a model to be in sync with the NFC protocol functionality is very difficult and time consuming. Another item which can be picked is extend the simple model with other variables then integers. In the simple model the validation is only implemented based on usage of integers, this should be extended by characters and Booleans to validate more functionality. In this research a simple POS simulator is used. This simple POS and adapter in between should be extended similar to the model. The simple model is only worked out for one case because case one and two are not feasible for to validate with the available software. Modelling and validating these cases can also be part of a future research. Also the same is valid for those cases: start simple and extend functionality of the model with small steps. 83

84 8 References [1] Maryam Mehrnezhad, Mohammed Aamir Ali, Feng Hao, and Aad van Moorsel, NFC Payment Spy: A Privacy Attack on Contactless Payments, International Conference on Security Standardisation Research (SSR '16), Gaithersburg, Maryland, USA, 5-6 December, , [2] Kyoil Kim, Jacob A. Abraham, and Jayanta Bhadra, Model Checking of Security Protocols with Pre-configuration, International Workshop on Information Security Applications WISA 2003: Information Security Applications 1-15, Springer, Berlin, Heidelberg, [3] R. Corin, S. Etalle, P.H. Hartel and A. Mader, Timed Model Checking of Security Protocols, Faculty of Computer Science, University of Twente, The Netherlands, Proceedings of the 2004 ACM workshop on formal methods in security engineering Washington DC, USA, October 29, [4] D. Dzemydiene, R. Naujikiene, M. Kalinauskan, E. Jasiunas, Evaluation of security disturbance risks in electronic financial payment systems, Department of Informatics and Software Systems, Faculty of Social Informatics, Mykolas Romeris University, Ateities 20, LT Vilnius, Lithuania, ISSN (online), [5] Jordi van den Breekel, A security evaluation and proof-of-concept relay attack on EMV contactless, Master s thesis, TU Eindhoven, [6] Michael Roland, Security Issues in Mobile NFC Devices, Springer, University of Applied Sciences, 13-67, Hagenberg, Austria, [7] Syed A. Ahson, Mohammad Ilyas, Near Field Communications Handbook, ISBN: , [8] Christian Killer, Christos Tsiaras, Burkhard Stiller, An Off-the-shelf Relay Attack in a Contactless Payment Solution, University of Zürich, Communication Systems Group, Binzmühlestrasse 14, 8050 Zürich,, Switzerland, [9] Martijn Bolhuis, Using an NFC-equipped phone as a token in physical access control, , University of Twente, July [10] Vedat Coskun, Busra Ozdenizci, Kerem Ok, A Survey on Near Field Communication (NFC) Technology, Published online Springer Science Business Media New York, Wireless Personal Communications Volume 71, Issue 3, , August [11] Ernst Haselsteiner, Klemens Breitfuß, Security in Near Field Communication (NFC), Strengths and Weaknesses, pp 4-8, Philips Semiconductors Mikronweg 1, 8101 Gratkorn, Austria,

85 [12] Diego A. Ortiz-Yepes, A Review of Technical Approaches to Realizing Near-Field Communication Mobile Payments, Published by the IEEE Computer and Reliability Societies, Volume: 14, Issue: 4, pp 54-62, IBM Research, Zurich, July/August [13] Martin Emms, Budi Arief, Nicholas Little and Aad van Moorsel, Risks of Offline Verify PIN on Contactless Cards, International Conference on Financial Cryptography and Data Security: Financial Cryptography and Data Security pp , UK, [14] Lishoy Francis, Gerhard Hancke, Keith Mayes, Konstantinos Markantonakis, Practical Relay Attack on Contactless Transactions by Using NFC Phones, Cryptology eprint Archive, Report 2011/618, 2011, [15] M. Mostafa and A. Allah, Strengths and Weaknesses of Near Field Communication (NFC) Technology, Global Journals Inc. (USA), Online ISSN: & Print ISSN: , [16] Tom Igoe, Don Coleman, Brian Jepson, Beginning NFC, Published by O Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472, USA, [17] K. Linck, K. Pousttchi and D.G. Wiedemann, Security Issues in Mobile Payment from the Customer Viewpoint, University of Augsburg, MPRA Paper No. 2923, posted 14. May [18] Smart Card Alliance, Security of Proximity Mobile Payments, A Smart Card Alliance Contactless and Mobile Payments, Council White Paper, May [19] Gerhard Hancke, A Practical Relay Attack on ISO Proximity Cards, pp 1-13, University of Cambridge, Computer Laboratory JJ Thomson Avenue, [20] Kim G. Larsen, Marius Mikucionis, Brian Nielsen, Arne Skou, Testing Real-Time Embedded Software using UPPAAL-TRON, An Industrial Case Study, Center of Embedded Software Systems, CISS Aalborg University Fredrik Bajersvej 7B, DK-9220 Aalborg, Denmark, [21] Kim G. Larsen, Marius Mikucionis, Brian Nielsen, UPPAAL-TRON User Manual, CISS, BRICS, Aalborg University, Aalborg, Denmark, [22] Hessel, A., Larsen, K., Nielsen, B., Pettersson, P., Skou, A., Time-optimal Real-Time Test Case Generation using UPPAAL, Proceedings of the 5th ACM international conference on Embedded software, pp , Jersey City, NJ, USA, September 18-22, [23] Axel Belinfante, JTorX: A Tool for On-Line Model-Driven Test Derivation and Execution, In TACAS, vol of LNCS, pp , Springer, [24] Jordi van den Breekel, Diego A. Ortiz-Yepes, Erik Poll, Joeri de Ruiter, EMV in a nutshell, Radboud University Nijmegen, June 29, [25] Aarts, F., Ruiter, J.de, Poll, E., Formal models of bank cards for free, Institute for Computing and Information Sciences Radboud University Nijmegen, Springer [26] Michael Roland, Software Card Emulation in NFC-enabled Phones: Great Advantage or Security Nightmare? NFC Research Lab Hagenberg University of Applied Sciences Upper Austria Software park 11, 4232 Hagenberg/Austria michael.roland@fh-agenberg.at,

86 [27] Anusha Rahul, Gokul Krishnan, Unni Krishnan, Sethuraman Rao, 'Near field communication (NFC) technology: A survey', International Journal on Cybernetics & Informatics (IJCI) Vol. 4, No. 2, India, April [28] Dakota Nelson, Security of the near field communication protocol: an overview, Journal of Computing Sciences in Colleges Archive Volume 29 Issue 2, pp Consortium for Computing Sciences in Colleges, USA, [29] Diego A. Ortiz-Yepes, A Review of Technical Approaches to Realizing Near-Field Communication Mobile Payments, Published by the IEEE Computer and Reliability Societies, IBM Research, Zurich, July/August [30] Emms, M., Arief, B., Freitas, L., Hannon, J., Moorsel, A. van, Harvesting High Value Foreign Currency Transactions from EMV Contactless Cards without the PIN, Newcastle University, No. CS-TR-1421, May [31] Halevi, T., Ma, D., Saxena, N., Xiang, T., Secure Proximity Detection for NFC Devices Based on Ambient Sensor Data, 7459, , [32] Larry Apfelbaum, John Doyle, Model Based Testing, Software Quality Week Conference, Teradyne Software & Systems Test, 44 Simon Street Nashua, NH 03060, [33] Muhammad Qa Saeed, Colin D. Walter, Off-line NFC Tag Authentication, the 7th International Conference for Internet Technology and Secured Transactions, ICITST, [34] Hoepman, Siljee, Beyond RFID: the NFC Security Landscape, TNO Information and Communication Technology, pp 3-15, Groningen, 23 October

87 9 Other references [35] Michael Roland, Security Issues in Mobile NFC Devices, Springer, University of Applied Sciences, Hagenberg, Austria, [36] ISO/IEC , Identification cards, Contactless integrated circuit(s) cards, Proximity cards, Part 3: Initialization and anti-collision. [37] EMV Co. EMV Contactless Specifications for Payment Systems. Book A: Architecture and General Requirements v2.5. EMV Co, [38] EMV Co. EMV Contactless Specifications for Payment Systems. Book B: Entry Point Specifications v2.5. EMV Co, [39] EMV Co. EMV Contactless Specifications for Payment Systems. Book D: Contactless Communication Protocol v2.5. EMV Co, [40] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-1 Kernel 1 Specification v2.5. EMV Co, [41] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-2 Kernel 2 Specification v2.5. EMV Co, [42] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-3 Kernel 3 Specification v2.5. EMV Co, [43] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-4 Kernel 4 Specification v2.5. EMV Co, [44] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-5 Kernel 5 Specification v2.5. EMV Co, [45] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-6 Kernel 6 Specification v2.5. EMV Co, [46] EMV Co. EMV Contactless Specifications for Payment Systems. Book C-7 Kernel 7 Specification v2.5. EMV Co, [47] EMV Co. EMV Integrated Circuit Card Specifications for Payment Systems. Book 1 Application Independent ICC to POS Interface Requirements v4.3. EMV Co, [48] EMV Co. EMV Contact Specifications for Payment Systems. Book 2: Security and Key Management v4.3. EMV Co, [49] EMV Co. EMV Integrated Circuit Card Specifications for Payment Systems. Book 3 Application Specification v4.3. EMV Co, [50] EMV Co. EMV Contact Specifications for Payment Systems. Book 4: Cardholder, Attendant, and Acquirer Interface Requirements v4.3. EMV Co, [51] MasterCard, Transaction Optimization for Pay Pass, M/Chip POSs, 07 July [52] EMV Co. EMV Mobile Contactless Payment, Technical Issues and Position Paper v1.0. EMV Co, [53] EMV Co. EMV Contactless Mobile Payment, Contactless Mobile Payment Architecture Overview version 1.0, EMV Co, [54] EMV Co. White Paper on Contactless Mobile Payment, version 2.0,

88 [55] Klaus Finkenzeller, RFID Handbuch, Giesecke & Devrient GmbH, Munich, Germany, [56] MasterCard, Transaction Optimization for Pay Pass, M/Chip POSs, 07 July [57] EMV Co, Application Activation User Interface Overview, Usage Guidelines, and PPSE Requirements, Version 1.0,

89 10 Internet links [58] [59] [60] mobilepaymentsdraftpc201311en.pdf [61] [62] Architecture-Overview [63] Co.com/specifications.aspx?id=22 [64] [65] [66] [67] [68] [69] [70] Co-A-Guide-to-EMV.pdf [71] [72] Co.com/specifications.aspx?id=21 [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] %202016_tcm pdf [85] [86] 89

90 11 Abbreviations 11.1 NFC related terms AAUI GSMA IC MNO NFC Device NFC PCD PICC RFID SIM Application Activation User Interface - The user interface application on the mobile device enabling the user to set a contactless mobile payment application to be active, and which configures the mobile device to enable this GSM Association: Association (currently) of about 700 mobile network operators (MNOs) in 218 countries around the world Integrated Circuit Mobile Network Operator: The mobile network operator provides a platform for secure NFC applications if having the UICC as the SE A device featuring different operating modes based on RF technology. There are three modes: tag emulation (PICC), NFC peer to peer (NFC) and reader/writer mode (PCD). NFC Devices must implement at least mandatory parts of the NFC Protocol Stack. The NFC Devices' operating modes are defined by the NFC Forum Near Field Communication: A communication technology standardized in ISO and ETSI allowing bidirectional communication between two devices based on RF technology. This is also refereed as the peer to peer (P2P) mode of NFC device Proximity coupling device: (reader / terminal / POS) a transmitter that can read tags based on ISO14443 (PICC). The reader emits an electromagnetic field that powers a tag/transmitter by inductivity. Communicates with PICC using load modulation scheme Proximity Inductive Coupling Card (can also be the NFC chip in a phone): a transponder that can be read or written by a proximity reader. Theses tags are based on the ISO14443 standard. Such tags do not have a power supply like a battery, but are powered by the electromagnetic field of the reader (PCD) Radio Frequency Identification: technology used to identify objects carrying RF transponders. NFC and RFID technology have overlapping standards and terminology Subscriber Identity Module: A smart card in a special form factor used in a phone to authenticate the user against the network 90

91 UICC UMTS integrated circuit card: SIM card for UTMS networks; USIM UMTS SIM; see UICC 11.2 Secure elements and platform management CA OTA PKI SE SP TTP TSM Certificate Authority Over the Air: The possibility to send and receive data to/from a device in distributed environment. In GSM networks data connection or SMS could be used to do so Public Key Infrastructure Secure Element: a trusted environment for storing sensitive data or applications Service Provider: an entity in the NFC ecosystem providing application. These applications do not need to be based on a SE Trusted Third Party: A trusted entity in a distributed environment. The TTP is the Certificate Authority of a Public Key Infrastructure. The TTP is able to issue self-signed certificates Trusted Service Manager: Trusted entity in an NFC ecosystem managing the SE and acting as a moderator and resolving the m-to-n between MNOs and SPs 11.3 Protocols and data formats APDU NDEF RTD Application Protocol Data Units: Data Exchange format specified in ISO/IEC 7896 to exchange data between a reader and smartcard chips NFC Data Exchange Format: A data format to store information like URL, SMS or plain text in a data container that could be stored on an NFC tag or exchanged over NFC (peer to peer mode). One NDEF can contain multiple Record Type Definition (RTD) and therefore is also referred as NDEF data container Record Type Definition: Specification on how information like URI, SMS or plain text are encoded to fit into NDEF data container 91

92 T=CL Transport Protocol for contactless communication in the field of smartcards (related to bit/encoding level on RF layer) T=1 or T=0 Transport Protocol for contacted communication in the field of smartcards (related to bit/encoding level on physical layer) 11.4 Card management ID GP SD Issuer Domain: the security domain of the card issuer Global Platform: An industry standard defining the APIs, interfaces and commands for security managing applications on a smartcard Security Domain: Part of a Global Platform (GP) compliant smartcard to hold the application of one Service Provider (SP) 11.5 ISO/IEC abbreviations ACK positive Acknowledgement ATS Answer To Select ATQA Answer To request, Type A ATQB Answer To request, Type B CID Card Identifier CRC Cyclic Redundancy Check, as defined for each PICC Type in ISO/IEC EDC Error Detection Code ETU elementary time unit HLTA HALT Command, Type A INF Information Field OSI Open Systems Interconnection PCB Protocol Control Byte PCD Proximity Coupling Device PICC Proximity Integrated Circuit Card PPS Protocol and Parameter Selection PPSS Protocol and Parameter Selection Start PPS0 Protocol and Parameter Selection parameter 0 PPS1 Protocol and Parameter Selection parameter 1 RATS Request for Answer to Select REQA Request Command, Type A RFU Reserved for Future Use SAK Select Acknowledge WUPA Wake-Up Command, Type A 92

93 11.6 ISO/IEC abbreviations AID ASI SFI FCI Application Identifier Application Selection Indicator Short File Identifier File Control Information 93

94 12 Appendix A: HCE versus SE During the research I made use of the environments below: 1. Rabobank Mobile Wallet Based on NFC [16] using SE 2. ING Mobile Payment App, based on HCE For both of the environments I investigated the architecture and the differences between traditional NFC based on SE and HCE are displayed in the Figure 47 below. Figure 47: Secure element and HCE architecture In both solutions the NFC controller is the main component of the NFC related functionality. It controls the radio interface and does processing on the data. HCE is similar to card emulation. However, no SE is used. The behaviour of the SE is emulated in software on the main CPU. The HCE account data is hosted in the cloud and regarding SE the data is physically hosted on the SE. Storing of the credentials is different for both of the architectures: SE: Tamper resistant module Cryptographic Keys Secure channel Protocols HCE: Cloud OS Memory Everything at software The difference in architecture is not part of the model which is investigated in this research. For this reason, no further details are given on this topic. 94

95 13 Appendix B: POS architecture The research area is investigating the data flow between the POS (Contactless Payment Terminal) and payment APP installed on the phone. In this appendix the POS architecture is explained. See the Figure 48 below of the high-level POS architecture and a contactless device (i.e. a phone). The POS system combines the terminal and reader functionality. Figure 48: High-level architecture In the EMV kernel 2 documentation [87] the simple payment transaction is given in the below Figure 49. The ACT Signal is used to activate the Reader and contains parameters such as the transaction amount and the transaction type. In some cases, the ACT Signal may not be needed and the Reader may be configured such that a contactless transaction starts automatically after the previous transaction has completed. The OUT Signal indicates the outcome of the transaction. It contains a subset of the Outcome from the Kernel. The notions of Outcome and the Outcome Parameter Set are described in EMV Book A [37]. Figure 49: Payment transaction flow 95

96 The reader process is set of modules which run independently from each other. See the Figure 50 below for the set of modules. Figure 50: Reader set of modules Process P (PCD) does management of the contactless interface. Process D (Display) does management of the use interface. Process S (Selection) does the phone APP and kernel selection (EMV book B [38]). Process K (Kernel) does interaction with the card once the application has been selected. Process M (Main) does overall control and sequencing of the different processes. Process P does the next high-level steps: Generates a reset, activate the field and start the polling loop as described in EMV Book D [39] until one or more Cards / NFC enabled phones are found Send a C-APDU to the Card or phone and return either an R-APDU or an error indication Manage the card removal, either by removing the field immediately or going through the removal sequence with or without a message prompt to the customer Process D does the next high-level steps: Process D manages the User Interface Requests as defined in EMV Book A [37] and displays a message and/or a status The User Interface Request Data can include a message identifier, a status, a hold time, a language preference, and a balance or amount to be displayed Information on the User Interface Request Data is given in [37] Process S provides the next services: Build the AID list by sending a SELECT PPSE, sort the entries by priority, and select the application with the highest priority from this list by sending a SELECT AID For each transaction, Process S is initialized by Process M with a list of Combinations AID Kernel ID The POS System has the following functions [37]: Non-interference with Contact Chip Interface. If the cardholder chooses the contact interface, to prevent interference between the contact chip and contactless interfaces, the POS System must power down the contactless interface prior to initiating a contact chip transaction and keep it powered down for the duration of the transaction 96

97 The POS System is responsible for ensuring that a new transaction is not started until the completion of the previous transaction Cancellation. Once a transaction has been started, there must be a means to cancel the transaction in case the user is unable to present a contactless card in time Field Management Displaying Amount. In environments where the Transaction Type and the exact amount are known before the start, the amount must be indicated to the cardholder, preferably by means of a terminal/reader display. In some circumstances the amount may be displayed by labels, such as posted prices on a vending machine Transaction Disposition, the POS System is responsible for indicating the transaction disposition to the cardholder Receipts Cardholder Verification, under certain circumstances when performing a contactless transaction, the POS System may be required to request Cardholder Verification to ensure that the person presenting the card is the person to whom the application in the card was issued. The kernel should be aware of the cardholder verification methods (CVM) capabilities of the POS System (e.g. the capability to print a Signature, or for Online PIN CVM the presence of a PIN entry device and acquirer online message capabilities) See below Figure 51 of SELECT response message data of a phone APP. Figure 51: SELECT response message data 97

98 The expected Status Words returned by the phone APP for the SELECT command are listed in the below Figure 52. Figure 52: Status Words The Reader supports multiple Kernels but only one Kernel will execute at a time. The Kernel that is activated depends on the information returned by Process S, which may in turn depend on data retrieved from the card/phone. As part of its interaction with the phone (Kernel 2): Checks the compatibility between the Kernel settings and the phone settings, these checks include both business (for example transaction type, domestic or international acceptance) and technical (for example versioning) checks Reads and writes the necessary payment and non-payment related data Determines the need for cardholder verification and the method to be used Performs risk management, resulting in the decision to approve/decline the transaction offline or seek online authorization Requests messages to be displayed depending on the details of the transaction Authenticates data, if and when relevant Informs Process M of the transaction outcome 98

99 14 Appendix C: EMV Smart card technology offers a number of features that can be used to provide or enhance privacy protection in systems. Below are examples of the security support of contactless smart card technology: Information security. For applications requiring complete data protection, information stored on cards or documents using contactless smart card technology can be encrypted and communication between the contactless smart card-based device and the reader can be encrypted to prevent eavesdropping. Hashes and/or digital signatures can be used to ensure data integrity and to authenticate the card and the credentials it contains. Cryptographically strong random number generators can be used to enable dynamic cryptographic keys, preventing replay attack Authenticated and authorized information access. The NFC device allows authenticated information access and protects the privacy of personal information. The NFC device can verify the authority of the information requestor and then allow access only to the information required. Access to stored information can also be further protected by a personal identification number (PIN) or biometric to protect privacy and counter unauthorized access EMV Co Relationship with other standard organizations: 1. The EMV specifications are based on underlying ISO standards as follows ISO/IEC 7816: Identification Cards Integrated Circuit(s) Cards ISO/IEC 14443: Identification Cards Contactless Integrated Circuit(s) Cards Proximity Cards 2. Payment Card Industry Security Standards Council (PCI) is primarily concerned with the protection of sensitive payment information such as account information and PIN. EMV and PCI are complementary in enhancing payment security and reducing fraud due to counterfeit and lost and stolen cards 3. The Near Field Communication (NFC) Forum. EMV is working to extend EMV payments to the contactless and mobile channels. This requires alignment with the NFC Forum which is responsible for developing the specifications for communication between NFC devices and services 4. Global Platform. Part of EMV Co. s activities is to review the functionality and security of platforms on which an EMV payment application will reside. Alignment with standards bodies such as Global Platform are important as EMV payment applications are increasingly implemented on shared chip platforms that support multiple applications, each from a different application owner 99

100 15 Appendix D: ISO/IEC and ISO/IEC : Physical characteristics Part 1 of ISO/IEC defines the physical dimensions for a Proximity Integrated Circuit Card (PICC). The card is the ID-1 size (85.6 mm 54.0 mm 0.76 mm). This is the same size as a bank credit card. Two important terms are defined: PICC - Proximity Integrated Circuit(s) Card, the contactless card PCD - Proximity Coupling Device, the reader/writer The dimension of the card is required to meet the specifications of the ID-1 card, specified in ISO/IEC 7810, the same as contact smart cards. The card has to meet certain criteria regarding robustness and numerous physical stresses the card has to withstand are listed. A PICC is a contactless integrated circuit card or other object with which communication and power transfer are done by inductive coupling in proximity of a coupling device Part 1 lists several environmental stresses that the card must be capable of withstanding without permanent damage to the functionality. These tests are intended to be performed at the card level and are dependent on the construction of the card and on the antenna design. For example, the operating temperature range of the card is specified in Part 1 as an ambient temperature range of 0 C to 50 C. Also is mentioned that the PICC shall continue to function normally after exposure to a static 640 ka/m magnetic field ISO/IEC : RF power and signal interface Part 2 of the ISO/IEC protocol defines the key technical characteristics of the contactless IC chips, including items such as frequency, data rate, modulation, and bit coding procedures. Two variations are detailed in part 2, the Type A interface and the Type B interface. Both operate at the same frequency and use the same data rate, but they differ from one another in the areas of modulation and bit coding. Initial dialogue for proximity cards is also described in this part. The initial dialogue between the Proximity Coupling Device (PCD/POS) and the PICC are conducted through the following operations (using RF): Activation of the PICC by the RF operating field of the PCD / POS The PICC waits silently for a command from the PCD / POS Transmission of a command by the PCD / POS Transmission of a response by the PICC 100

101 15.3 ISO/IEC : Initialization and anti-collision Initialization describes the requirements for proximity coupling device (PCD) (i.e., the reader) and the card to establish communication when the card is brought into the reader's radio frequency (RF) field. Anti-collision defines what happens when multiple cards enter the magnetic field at the same time, identifying how the system determines which card to use in the transaction and ensuring that all cards presented are inventoried and processed. PICC polling cycle has 3 parts (Figure 53): Single PICC selection (ISO/IEC ) or PICC activation Selection of the correct APP in the selected PICC, Applications are sometimes referred as cards Perform transaction with application on PICC Figure 53: PICC polling cycle ISO Type A Command Set (see also Figure 54): REQA (0x26) and WUPA (0x52) These two commands are issued as broken byte (7 bits) command with no CRC Used for activation of the card REQA is activation command, WUPA is used after a HALTA HLTA (0x50, 0x00, CRC_A): Used to stop communication with the card while still in the PCD field (i.e. put it to sleep). 101

102 Figure 54: ISO Activation and Selection Logic Loop 15.4 ISO/IEC : Transmission protocol Part 4 of the ISO/IEC defines the data format and data elements that enable communication during a transaction. A half-duplex block transmission protocol is specified in this part. The protocols described in Part 4 are optional elements of the ISO/IEC standard; proximity cards may be designed with or without support for part 4 protocols. The PICC reports to the reader if it supports the Part 4 commands in the response to the polling command (as defined in Part 3). The protocol defined in part 4 is also capable of transferring application protocol data units as defined in ISO/IEC and of application selection as defined in ISO/IEC Note that ISO/IEC 7816 is a Contacted Integrated Circuit Card standard. The Figure 55 below shows the PICC activation process of the ISO/IEC protocol. Figure 55: PICC activation 102

103 Figure 56 describes the flow of going from ISO / IEC part 3 to part 4. Figure 56: From to ISO/IEC : Organization, security and commands for interchange ISO/IEC 7816 is a series of standards created for contact smart cards and later also used for contactless smart cards. ISO/IEC is intended to be used in any sector of activity. Part four of ISO/IEC specifies an application layer protocol. ISO/IEC enables a multi-application environment where applications can be installed onto one card. ISO/IEC specifies organization, security and commands [64] interchange: Contents of command-response pairs exchanged at the interface Means of retrieval of data elements and data objects in the card Structures and contents of historical bytes to describe card operating characteristics Structures for applications and data in the card, as seen at the interface when processing commands Access methods to files and data in the card Security architecture defining access rights to files and data in the card Means and mechanisms for identifying and addressing applications in the card Methods for secure messaging Access methods to the algorithms processed by the card. It does not describe these algorithms 103

104 ISO/IEC 7816 consists of the following parts, under the general title Identification cards Integrated circuit cards: Part 1: Cards with contacts: Physical characteristics Part 2: Cards with contacts: Dimensions and location of the contacts Part 3: Cards with contacts: Electrical interface and transmission protocols Part 4: Organization, security and commands for interchange Part 5: Registration of application providers Part 6: Interindustry data elements for interchange Part 7: Interindustry commands for Structured Card Query Language (SCQL) Part 8: Commands for security operations Part 9: Commands for card management Part 10: Cards with contacts: Electrical interface for synchronous cards Part 11: Personal verification through biometric methods Part 12: Cards with contacts: USB electrical interface and operating procedures Part 15: Cryptographic information The security architecture stated in ISO/IEC : The security status represents the current state possibly achieved after completion of the ATR and a possible protocol and parameter selection and / or a single command or a sequence of commands possibly performing authentication procedures. The security status may also result from completion of a security procedure related to the identification of the involved entities, if any, e.g., by proving knowledge of a password (e.g., using a VERIFY command) or knowledge of a key (e.g., using a GET CHALLENGE command followed by an EXTERNAL AUTHENTICATE command, or using a sequence of GENERAL AUTHENTICATE commands), or by secure messaging (e.g., message authentication). Four security statuses are considered: 1. Global security status. In a card using a hierarchy of Dedicated Files (DFs), it may be modified by completion of a Master File (MF) related authentication procedure (e.g., entity authentication by a password or a key attached to the MF) 2. Application-specific security status. It may be modified by completion of an application-related authentication procedure (e.g., entity authentication by a password or a key attached to the application); it may be maintained, recovered or lost by application selection; this modification may be relevant only for the application to which the authentication procedure belongs. If logical channels apply, then the application-specific security status may depend on the logical channel 3. File-specific security status. It may be modified by completion of a DF-related authentication procedure (e.g., entity authentication by a password or by a key attached to the specific DF); it may be maintained, recovered or lost by file selection; this modification may be relevant only for the application to which the authentication procedure belongs. If logical channels apply, then the file-specific security status may depend on the logical channel 104

105 4. Command-specific security status. It only exists while processing a command using secure messaging and involving authentication; such a command may leave the other security status unchanged Security mechanisms: Entity authentication with password The card compares data received from the outside world with secret internal data. This mechanism may be used for protecting the rights of the user Entity authentication with key The entity to authenticate has to prove the knowledge of the relevant secret or private key in an authentication procedure (e.g., a GET CHALLENGE command followed by an EXTERNAL AUTHENTICATE command, a sequence of GENERAL AUTHENTICATE commands) Data authentication Using internal data, either a secret key or a public key, the card checks redundant data received from the outside world. Alternately, using secret internal data (secret or private key) the card computes a data element (cryptographic checksum or digital signature) and inserts it in the data sent to the outside world. This mechanism may be used for protecting the rights of a provider Data encipherment Using secret internal data (secret or private key) the card deciphers a cryptogram received in a data field. Alternately, using internal data (secret or public key) the card computes a cryptogram and inserts it in a data field, possibly together with other data. This mechanism may be used to provide a confidentiality service, e.g., key management and conditional access. In addition to the cryptogram mechanism, data confidentiality can be achieved by data concealment. In this case, the card computes a string of concealing bytes and adds it by exclusive-or to bytes received from or sent to the outside world. This mechanism may be used for protecting privacy and for reducing possibilities of message filtering Secure messaging (SM) protects all or part of a command-response pair, or a concatenation of consecutive data fields by ensuring two basic security functions: data confidentiality and data authentication. Secure messaging is achieved by applying one or more security mechanisms. Possibly explicitly identified by a cryptographic mechanism identifier template in the control parameters of any DF, each security mechanism involves a cryptographic algorithm, a mode of operation, a key, an argument (input data) and often, initial data. It does not cover the internal implementation within the card/ PICC or the outside world. The protocol consists of a file system and commands for access to the file system, management of logical communication channels, and securing the communication. The file system consists of a MF, dedicated files DFs and elementary files (EFs). DFs can be seen as directories. They may host complete applications, group files or store data objects. EFs are the leaf nodes of the file system and contain the actual data. 105

106 The application level communication protocol is mapped on top of the lower layer transport protocol. Command-response pairs are the APDU s. Commands are always sent from the reader to the card while responses are always sent from the card to the reader. For the contactless card part 4 is compatible with the contact card. ISO/IEC is independent from the physical interface technology. It applies to cards accessed by one or more of the following methods: contacts, close coupling and radio frequency. If the card/ PICC supports simultaneous use of more than one physical interface, the relationship between what happens on different physical interfaces is out of the scope of ISO/IEC For organizing interchange, the ISO/IEC 7816:4 part specifies the following basic features: Command-response pairs Data objects Structures for applications and data Security architecture In ISO/IEC the APDU communication is described. The terminal sends command APDU and the card replies with response APDU. The conventions for CLA, INS, SW1 and SW2 (part of the APDU) are given in ISO/IEC For example: conventions for status word SW1 SW2 for normal processing is: 61xx, 9000 and for coding error is 67xx, 6Fxx. The below Figure 57 shows the structures for applications and data, as seen at the interface when processing commands in the interindustry class. The actual storage location of data and structural information beyond what is described in this clause is outside the scope of ISO/IEC Figure 57: File system structure According to IS the file system exists of a real filesystem with a root directory (MF), folders (DF) and files (EF) identified by 2 bytes. The DFs host applications and / or group files and / or store data objects. An application DF is a DF hosting an application. A DF may be the parent of other files. These other files are said to be immediately under the DF. DF can be seen as a folder. It stores one or more EFs or even other sub-dfs. Access Control can be implemented onto DF to prevent access to inside applications. 106

107 The EFs store data. An EF cannot be the parent of another file. Two categories of EFs are specified. An internal EF stores data interpreted by the card, i.e., data used by the card for management and control purposes. A working EF stores data not interpreted by the card, i.e., data used by the outside world exclusively. Selecting a structure allows access to its data and, if the structure is a DF, its sub-structure. The file formats can be binary, linear fixed sized records, linear variable sized records or cyclic fixed sized records. There are two ways for a terminal to access a DF: 1. Using a File Identifier: The POS must know the file system structure of the card beforehand 2. Using an AID (16 bytes Application ID): POS does not need to know whole file system structure of ICC in advance 107

108 16 Appendix E: Error detection Activate sequence (Figure 58) for a phone (PICC) compatible with type A is displayed in the scheme below. Figure 58: Activate sequence In order to detect phones which are in the RF field the POS sends repeated Request commands. The POS REQA and REQB described in the figure in any sequence. 108

109 See the Figure 59 to how this is processed: Figure 59: PICC type A or B Based on the sequence diagram a model can be created using UPPAAL for activation of type A [77] containing states: {IDLE, POLL, CHECK_PICC, TYPE_A, TYPE_B, PROCESS_A, PROCESS_B, RESET_PICC, REMOVE_A, REMOVE_B} Card states: {MOVE_IN_AREA, PROCESS, REMOVE} In UPPAAL I created the below model, see Figure 60, Figure 61, Figure 62: POS: Figure 60: POS model 109

110 Phone: Figure 61:phone model And the simulation model: Figure 62: Simulation model This model is not worked out further but can be used in a future research. 110

111 17 Appendix F: APDU Example of an APP with AID = in the phone. The POS is sending APDU SELECT command: 00 A and gets response in 61 XX in SW1, SW2 which means successful. Example of a command APDU, SELECT FILE: CLA = 0X ; INS = A4 ; P1 = 00 SELECT EF, DF or MF by file identifier; P2 = 00 File Control Information returned in response; Data according the P1 field; maximum length of data expected in the response. Example of a response APDU, SELECT FILE: Data, the file control information, SW1-SW2, 9000 is OK, 6A82 is FILE not found. In the Figure 63 below the values of SW1-SW2 are given (a complete list can be found on [81]. Figure 63: Status word description In the command APDU the CLA and INS define an application class and instruction group as described in ISO/IEC The content of the CLA is giving information of the format of secure messaging and the logical channel number used. The ISO/IEC gives a list of CLA values. 111

112 The two low-order bits of the CLA byte can be used to designate a logical communication channel between the reader-side application and the mobile device. The next two higher order bits of the CLA byte can be used to indicate that secure messaging is to be used between the reader-side application and the mobile device. The body of the command APDU can have four different forms: 1. No data is transferred to or from the mobile device, APDU includes only the header 2. No data is transferred to the mobile device but data is returned from the mobile device, so the body of the APDU includes only a non-null Le field 3. Data is transferred to the mobile device but no data is returned from the mobile device as a result of the command, so the body of the APDU includes the Lc field and the data field 4. Data is transferred to the mobile device and data is returned from the mobile device as a result of the command, so the body of the APDU includes the Lc field, the data field, and the Le field The below Figure 64 and Figure 65 show the instruction list as part of the command APDU. Figure 64: APDU instructions Figure 65: Allocation of status bytes [49] 112

113 18 Appendix G: NFC transaction flow 18.1 ATR ATR is the response a card returns when the proper power sequence is applied. ATR fields cover: The initial byte The format byte The interface bytes The historical bytes The check byte Example of an ATR is displayed in Figure 66. Figure 66: Example ATR The ATR byte string returns information about the communication protocol, the card/phone and APP type, the life cycle status and is the first step in the PPS protocol. While some of the bytes are defined by ISO, as they are used by the communication protocol, there is the possibility to define the value of other bytes, called Historical Bytes. To avoid possible interoperability problems, only the historical bytes are mandated, while the value (and, if applicable, the presence) of all the interface characters is not fixed in this specification. The historical bytes are in proprietary format, and convey information about the APP. All APP parameters are defined in this specification, and are therefore implicitly known, and do not need to be given in the ATR. The files on a card are organized in a tree structure. The topmost file is the Master File (MF) which has one or more ADF. Inside of an ADF are Application Elementary Files (AEF) containing data. The AID can be selected as part of the ADF. Within an ADF you can select AEFs with the Short File Identifier (SFI). 113

114 The tree structure of ADF s: Enables the attachment of data files to an APP Ensures APP separation Allows access to the logical structure of an APP by its selection An ADF is seen from the terminal as a file containing data objects as part of the FCI [47]. The MF is the root of the file system and is always the initial entry point to the file system. After a reset of the card, the MF is selected. The Dedicated Files (DF s) are similar to Directories in traditional file systems. DF s can contain Elementary Files (EF s), and/or other DF s. The MF can be considered to be a special DF that contains all the files. The Elementary File (EF) is used for data storage. For this reason, EFs are also referred to as data files. File access is similar to traditional file systems. To access a file (for reading, writing, or any other operation), it has to be selected. When the Payment System Environment (PSE) is present, the ICC maintains a directory structure for the list of applications within the PSE that the issuer wants to be selected by a directory. In that case, the applications are listed in a Payment System Directory (PSD) file (DIR file), the location of which is indicated in the FCI of the PSE DDF. The location of the DIR file is in the response message to the selection of the PSE ( SELECT command). The DIR file is an AEF with a record structure according to this specification. Each record in the PSD is a constructed data object, and the value field is comprised of one or more directory entries as displayed in the below Figure 67. Figure 67: Data object PSD record 18.2 GET PROCESSING OPTIONS The GET PROCESSING OPTIONS command and response message is displayed in Figure 68 and Figure 69. In this figure RFU means Reserved for Future Usage. 114

115 Figure 68: GET PROCESSING OPTIONS command message [42] Figure 69: GET PROCESSING OPTIONS response message The AIP specifies the application functions that are supported by the application in the ICC. If any mandatory data elements are missing, the POS terminates the transaction. See the below Figure 70 as an example of an AIP. Figure 70: AIP [59] The AFL is a list that consists of the files and related records for the currently selected application that should be read by the terminal. The AFL will also indicate which, if any, of the data records should be used by the terminal as part of the input to the data authentication process. The terminal requests these records and the ICC sends them to the terminal. 115

116 These records contain information about: Application Expiration Date Application Primary Account number Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Certification Authority Public Key Index Issuer Public Key, Remainder and Exponent The POS indicates to the cardholder that phone read is complete and the cardholder should remove the phone from the reader s RF field. The contactless transaction has not yet completed. The reason the phone is removed before the further processes is to keep the amount of time the phone is in the RF field to a minimum, this helps to improve the customer experience and reduce the potential for phone errors if it waivers from the RF field whilst in the customers hand. The POS checks the application data returned by the phone to ensure it complies with the requirements for the chosen contactless path. The POS examines the Cryptogram Information Data (CID) to determine the cryptogram type. Commonly used cryptograms are ARQC, Authorization Response Cryptogram (ARPC), Transaction Certificate (TC) and AAC. ARQC: A cryptogram used for a process called online card Authentication. This cryptogram is generated by the card for transactions requiring online authorization. It is the result of card, terminal, and transaction data encrypted by a DES key. It is sent to the issuer in the authorization or full financial request. The issuer validates the ARQC to ensure that the card is authentic and card data was not copied from a skimmed card. This indicates if the card expects the reader to decline offline, attempt online authorization or approve offline. However, this result is not the final outcome. The final outcome will be determined during the outcome processing step [82][83]. 116

117 19 Appendix H: UPPAAL 19.1 Features of UPPAAL Features of the UPPAAL modelling language are the following: Usage of bounded integer variables are declared as int[min, max] name, where min and max are the lower and upper bound. Violating a bound results in an invalid state that is discarded at run time Usage of arrays Usage of broadcast channels. A sender s! can synchronise with a number of receivers s?. Any available receiver must synchronise. Broadcast sending is never blocking Urgent locations Time is not allowed to pass when the system is an urgent location Committed locations. This is similar as an urgent location but the next transition must involve an outgoing edge of at least one of the committed locations of the network Details of reachability, safety and liveness properties: Reachability: a specific condition holds in some state of the model s potential behaviours. Reachability properties are often used while designing a model to perform sanity checks (e.g. is it possible for a sender to send a message?) Safety: specific condition holds in all the states of an execution path (A []). Something bad will possibly never happen. In UPPAAL these properties are formulated positively (something good is invariantly true) and they are expressed by the path formulae A φ and E φ Liveness: a specific condition is guaranteed to hold eventually (is at some moment) (A<>). Liveness analysis checks whether something good will happen. You specify liveness requirements by defining an accepting state condition, a Boolean function on state variables that is supposed to be satisfied Path formulae have the syntax as show in the Figure 71 below. Figure 71: Path formulas 117

118 In the Figure 72 below the path formulas are displayed. The result set of the formulae is marked grey. Figure 72: Result sets of the different path formulas Simulation testing in UPPAAL: How to use simulation in UPPAAL is displayed in the Figure 73 below. Step by step the model can be executed. Also a trace is available to check the logging. Furthermore, the values of variables can be validated during simulation testing. Figure 73: Simulation in UPPAAL Using UPPAAL- Yggdrasil: Pressing Generate in the Yggdrasil tab will generate traces based on the options selected. These will be shown in the traces window. Selecting a trace will open statistics for this trace in the Trace statistics window. Selecting the total coverage field will show combined statistics for all traces. Double clicking a trace will load that trace in the Simulator tab, where it can be examined. By selecting Mark Visited under the View menu, while in the Simulator, the coverage can be visualized. 118

119 Traces are generated in three phases: query file, depth search and single step. These are executed in order, and each phase tries to add to the coverage achieved by previous phases. The first phase looks through the currently loaded query file in the verifier for reachability queries. Each reachability query is executed and the resulting trace is used as a test case. The second phase does a random depth first search of the specified number of steps, the resulting trace is used as a test case. This process is repeated until the newly generated trace does not add new coverage over the previous traces. In order to use this method a global integer variable named reach must be initialized to zero, and must not be used throughout the model. The third phase tries to cover any remaining edges not covered by the previous phases. This is done by making a reachability query for each uncovered edge. In large systems this can be many edges, and the query for reaching specific edges can take a long time to execute. In order to use this method a global integer variable named single must be initialized to zero, and must not be used throughout the model. By using a special syntax within UPPAAL, the test suite that is the output of the tool can take the format of a test script, in principle in any desired language that can be used as input to test execution engines such as e.g. Selenium [69]. For deriving test cases from the model UPPAAL can be used. UPPAAL contains a graphical editor and animator/simulator, and an efficient model checker. UPPAAL can handle both online and offline test generation. Regarding paper [21] the functionality of UPPAAL is the following: Performs conformance testing: the tool checks whether the timed runs of the system under test (SUT) are specified in the system model (similar to timed trace inclusion) and no illegal (unexpected, unspecified) timed behaviour is observed The emphasis is on testing the timed and functional properties. Time is considered continuous, (input/output) events can happen at any real valued moment in time, but deadlines are constrained by integers. Test data generation is also possible, but (today) data types and value selection are limited by modelling language The specification is an UPPAAL timed automata network partitioned into a model of the system and a model of system s environment assumptions. The model can be non-deterministic Test primitives are generated directly from the model, executed and the system responses checked at the same time, online (on-the-fly) while connected to the SUT, thus avoiding huge intermediate test suites 119

120 19.2 Coffee Machine This coffee machine is described in [89]. The java code of this simulator I received while doing the course Software Validation and Verification. I used the code as an example for my own NFCPayment setup. The coffee machine model exists of 2 sub processes: automaat and user. See the Figure 74 below. Figure 74: Coffee machine The UPPAAL model is save in the file KoffieAutomaat.xml. The model tells after pressing a button, between 5 and 10 seconds coffee will be produced or between 10 and 15 seconds thee will be produced. In the Automaat class the behaviour of the coffee machine can be changed. The current setting is: wait randomly between 5 and 10 seconds before an output is generated. After this pause thee or coffee gets produced. In Eclipse start the Automaat, Figure 75. Figure 75: Eclipse Java output 120

121 Start in Windows the testing with TRON (start-tron.bat), Figure 76: Figure 76: Start TRON The TestIOHandler is the adapter between the simulator and the TRON. This TestIOHandler contains the following functionality: Input and output; configure function contains inputbutton = reporter.addinput("button"); outputcoffee = reporter.addoutput("coffee"); outputtea = reporter.addoutput("tea") When the function run a value receives equal to the value of the inputbutton this means TRON sent a button which can be forwarded to the coffee machine If the coffee machine needs to send a message back, this will be one of the output values (see ServeDrink) In the configure function the timeout and time unit is described In the Main class the socket port is passed to the Reporter class (Port 9995). This port is also used in the batch files 19.3 Detailed model in UPPAAL The detailed model In UPPAAL of the complete process is modelled based on the steps defined in chapter 6.1. See Figure 77, Figure 78, Figure 79, Figure 80 and Figure 81 for the UPPAAL model. 121