Cashless Payment with Mobile Wallets: LINDDUN Privacy Threat Model

Cashless Payment with Mobile Wallets: LINDDUN Privacy Threat Model Dimitri Van Landuyt October 22,2025 Cashless payment is becoming increasingly ubiquitous and with this overall trend, also the adoption of non-bank-led payment solutions keeps increasing. In this document, we provide the standalone application description of an abstracted mobile wallet based system, of which the most prevalent examples are Google Wallet or Apple Pay. These payment systems are integrated within the operating systems of mobile platforms, and tightly integrated in their overall ecosystems. The technology itself relies on hardware capabilities such as Trusted Execution Environments. The abstracted payment system described in this document is based on technical document pertaining the Apple Pay system. We first present the overall case description, consisting of two distinct Data Flow Diagrams (dfds) and a step-by-step explanation of the main functioning of this system. Then, we present the linddun privacy threat model for this case, which lists and describes the most prevalent privacy threats. 1Introduction This report presents a case study application of the linddun privacy threat modeling framework. It is comprised of two parts: (i) an indepth case description, and (ii) detailed threat descriptions. Part I of this report is based on the work conducted within the context and scope of the master’s thesis entitled ‘LINDDUN Privacy Threat Analysis of a Mobile Payment System’ by Morganne Verhaeren,1113. supervised by Dimitri Van Landuyt, Qianying Liao and Wouter Joosen2First, a number of scoping decisions are introduced and mo2The content presented in this report mainly corresponds to Chapter 6of the master’s thesis. tivated, based on the availability of technical information, popularity, etc. More concretely, a representation of a mobile payment system is chosen in Section 2. Then, Section 3introduces the main dfd models of the application, and discusses their elements and main flows. Section 3shows the DFDs of the system and explains these in more detail. Part II is based on the combined threat model outputs of four distinct threat modelers: Nicolas Boltz, Ayesha Iftikhar, Alexander Vogt, and Manuel Córcoles. It consists of Section 4which presents the resulting linddun threat model for this application case. cashless payment with mobile wallets 2 Part I Case description 2Scope and inputs In this application case, the focus is on a payment solution integrated in a mobile wallet system. In comparison with bank-led mobile payment systems (e.g. through banking apps) mobile wallets bring involvement of additional third-party organizations, typically the mobile platform providers that offer these apps and services. Some examples of such third-party organizations involved in the mobile payment system are the wallet providers and the TSP3. The TSP gen3Token service provider erates and manages unique tokens, that are used to replace sensitive information in the mobile payment system.4This in turn implies that 49,11. they will also have access to information linked to data subjects. To ensure realism of the mobile payment system model, the model is based on a representative real-world system, in this case, Apple Pay. We select a concrete solution with the predominant aim to create a representative abstraction of generic mobile wallet-based payment system. Architectural abstraction is made of vendorand technologyspecific elements where applicable, and as such the threat analysis itself does not target a specific vendor or technology. Regardless, Apple Pay was crowned the most used mobile wallet in the U.S.5in 55. 2022. In Belgium, it was stated that in 2019 Apple Pay was also used more extensively than Google Pay.666. Fehr et al.7created a model of this mobile payment system in their 79. work, which serves as an input to this modeling effort. Furthermore, extensive documentation of Apple, the Apple Security guide8and 82. Apple’s Documentation Archive,9can be found and was consulted in 91. preparation of the system model. Furthermore, Apple Pay is architecturally similar to other mobile payment systems (e.g. Google Wallet), so it is a good representation of a mobile payment system. 3Modeling of Data Flow Diagrams The first step in the LINDDUN PRO approach involves modeling the system. In this step, a DFD is created that represents the Apple Pay mobile payment system. cashless payment with mobile wallets 3 3.1Data Flow Diagrams Two distinct dfds are created to describe the main functionalities of the Apple Pay system. The first dfd, Figure 1, presents the enrollment process of a credit or debit card in Apple Pay as conducted by the Cardholder. The enrollment phase of Apple Pay is relevant because this is the only stage of the process where the actual debitor credit-card number of the cardholder is used. A cardholder’s identity can be linked to the card number, which might bring forth problems such as third parties using this for analyzing spending habits. In every other stage, a device account number (DAN) is used as a pseudonym. A DAN is a unique number linked to every card available in the Apple Wallet. A cardholder can add the same card to multiple devices, but the DAN will be different for each device. The DAN ensures that a cardholder’s card information is not stored on the device directly.10 10 2. Understanding how the card information is captured, transmitted, and stored in this first stage is important to assess privacy risks. The other diagram, Figure 2, illustrates the process when a Cardholder uses their device for contactless payment in a store. The creation of these dfds is based on the prior work of Fehr11 11 9. was used as a guide, and every interaction between dfd elements was cross-verified in both the Apple Security guide12 and Apple’s 12 2. Documentation Archive.13 13 1. trust boundary external entity process data store data flow DFD LEGEND R4. registerCard (name,cardNb,expiration,CVV, deviceContext):cardID R2. validateAndRegister(name,cardNb,expiration,CVV) Apple Wallet app Cardholder R1. registerCard(name,cardNb,expiration,CCV) Mobile Device R7. registerCard(name,cardNb,exp,CVV,DAN):passFile R5. verifyCVV(Name.Email.AttendeeID) R6. checkFraud(deviceContext): bool R8. sendPassFile(PassFile) Apple Server Apple back-end Apple Account DB R3. getContext(): deviceContext Card Validation Issuer Bank Link and Provision Fraud Detection Figure 1: DFD of the card enrolment procedur. cashless payment with mobile wallets 4 trust boundary external entity process data store data flow DFD LEGEND 5.1. store(OTPT) Apple Wallet app Cardholder Mobile Device 5.1.1. store(OTPT) Apple Server Apple back-end Apple Account DB 11. authorizationResponse Issuer Bank 8. verifyOTPT(OTPT) 10. authorizationRequest(paymentInfo) Payment processor Payment Terminal Point of Sale 1. requestPayment (amount,paymentToken,beneficiary,location) 3. getCardDetails(CardID) : cardDetails 2. confirmation and card selection Apple Pay app 4. generateOTPT (cardDetails,transactionDetails):OTPT Secure Element 6. sendOTPT(OTPT) 7. submitOTPT(OTPT) 9. verification response Token Service 5. store(OTPT) Payment processor 12. authorizationResponse Figure 2: DFD of the general payment flow. 3.2Data Flows: Step by step A separate data flow diagram (dfd) is provided for the process to add cards to a mobile wallet (Figure 1), and the payment process itself (Figure 2). The numbers below correspond with the flow numbers in the figures displaying the dfds. Card registration. The flow to register and add a payment card to the mobile wallet is shown in Figure 114. Step by step, the following 14 Before the card registration process can start, the Cardholder must be authenticated and have the right authorization, which not depicted and considered a precondition. activities and data flows take place: R1. The Cardholder sends the necessary information to the Apple Wallet app to register a new card. This information includes their full name (as printed on the card), the card number, the expiration date and the CVV code15 of the card. 15 Card verification value. Sometimes, a CVC (Card Verification Code) is used for identical purposes. R2. This information is sent to the Card Validation process where the information is first examined and verified, then sent to the back-end (Apple Server). R3. The Card Validation process fetches additional local context information from the Link and Provision process, which is shared to the back-end and later used for fraud detection. This deviceContext information includes the device model, the cashless payment with mobile wallets 5 Cardholder’s phone number, and their approximate location, and is used on the one hand to verify against fraud or anomaly and also to construct a valid dan16.16 Device Account Number R4. Once the initial validity checks of the card have been performed locally (e.g., the correct formatting of card number, its checksum, validity date must be in the future, etc), the information (as well as the Cardholder’s explicit consent on the overall terms and conditions17) are sent to the Apple Server which is part of the Apple 17 Not modeled in the dfd. back-end. R5. Via the Issuer Bank, the CVV code is verified18.18 This verification logic is specific and proprietary to the Issuer Bank. R6. The Apple Server performs additional verification, anomaly and fraud detection, by submitting the deviceContext data to the Fraud detection process. This emits a risk score, here simplified as a boolean. R7. The Apple Server constructs a dan and records the card in the Apple Account DB in the back-end which yields an Apple Wallet Pass File (passFile). R8Finally, Apple Server submits this Apple Wallet Pass File to the Apple Wallet app. Mobile payment. The payment process, i.e. the process of a Cardholder using a mobile wallet to pay for goods or services in a physical store –as depicted in Figure 2– happens as follows: 1. The Payment Terminal (which resides on point-of-sale (POS) terminal) of the vendor sends the payment request data, consisting of the amount to be paid, a payment token, the beneficiary, and possibly the location, to the Apple Pay app19.19 This happens over an NFC communication channel, and thus is only viable when the mobile device is kept close to the payment terminal. This is abstracted in this dfd. 2. The Apple Pay app presents the transaction information to the Cardholder and obtains both payment confirmation and card selection information. 3. Card details are fetched from the Apple Wallet app, including the dan to be used in this transaction. 4. Based on these inputs, a One-time Payment Token (OTPT) is generated. 5. The One-time Payment Token (OTPT) is stored in the Apple Wallet app, and this state update is synchronized with and persisted by the Apple Server (steps 5.1 and 5.1.1). cashless payment with mobile wallets 6 6. The Apple Pay App sends the One-Time Payment Token back to the Payment Terminal, in response to the original payment request. 7. The One-Time Payment Token (OTPT) is forwarded from the external Payment Processor. 8. The Payment Processor forwards the OTPT to the Token Service which extracts the PAN20.20 Primary account number. 9. The Token Service returns the extracted PAN to the Payment Processor. 10. The Payment Processor forwards the PAN, along with the transaction details over the payment network21 to the Issuer Bank to the 21 The payment network itself is not depicted. It is the communication channel that supports flows 10 and 11 in Figure 2. Issuer Bank in an authorization request. 11. The Issuer Bank uses the received information to authorize the payment and sends back the response to the Payment Processor. 12. The Payment Processor forwards the positive response to Payment Terminal which confirms payment success (e.g., through sound or in a display). 3.3Glossary This glossary provides additional explanation of the different architectural elements depicted in dfds, i.e. in Figure 1and Figure 2. Cardholder The Apple Pay user that is in possession of the physical debit or credit card. Apple Wallet app A mobile application that allows Cardholders to add, manage, and store, debit and credit cards.22 (Although 22 2. Cardholders can also use the app to make payments with Apple Pay online, this is not shown on the diagrams as the focus is on NFC payments). Apple Pay App A mobile application designed to manage Apple Pay hosted by the Secure Element.23 This application implements 23 2. payment logic and uses NFC communication to communicate with aPayment Terminal. Apple Server This process manages the setup and provisioning of cards in Apple Wallet as well as the access to the cards from the back-end side of the payment solution. The servers are responsible for creating and managing the dans in the Apple Account DB24 24 2. and sending corresponding Apple Wallet Pass files (PassFile) to the Apple Wallet app of the Cardholder. cashless payment with mobile wallets 7 Card Validation This process receives the name, the card number, expiration date and CVV code of the credit or debit card, verifies at the level of the Mobile device if these are correct and if so, relays this information in encrypted format to the Apple Server. CVV Stands for card verification value. This is a threeor four-digit number printed on the back of a credit card to ensure that the Cardholder is in possession of the physical card.25 25 7. DeviceContext Collected by the Link and Provision process on the Mobile device. This data element groups information about the Cardholder’s device (hardware/software versions), but also includes iTunes and App Store activity, other information about the Cardholder such as the phone number, and the approximate location of the Cardholder.26 26 2. Issuer Bank The bank that issues the debit or credit card linked to Apple Pay, must be part of the Apple Pay network if the Cardholder wants to add a card to Apple Pay. Examples of operational Issuer Banks in Belgium are KBC Bank and Revolut. Link And Provision DeviceContext information is collected on the mobile device of the Cardholder through this process. This information pertains the device (hardware platform), software versions, and includes the Cardholder’s location and phone number. Such DeviceContext information is shared to increase trust of the Cardholder and to detect potentially fraudulent or anomalous activity. If a payment request occurs in for example a suspicious location, the transaction might be denied for fear of fraudulent activity. One-Time Payment Token (OTPT) Is a token specifically encrypted and created for a specific payment transaction. The OTPT includes the dan, a token expiration date, the currency of the transaction, the payment amount, and (optionally), the name of the cardholder.27 There is also a one-time-use cryptogram —data that has 27 3. been encrypted—incorporated in the OTPT,28 which prohibits 28 4. multiple use of the same token (hence the ‘one-time’ adjective). PassFile . Represents the credit or debit card in the Apple Wallet. APassFile is a package containing a json-file that defines the pass, contains the card art, metadata about the card, and supported features. The Pass File also keeps track of the pass state. The pass state keeps track of if the card is currently suspended or if additional information is needed before any payment can be made with Apple Pay.29 29 2. cashless payment with mobile wallets 8 PaymentInfo Represent a payment transaction, and consists of the amount and the currency code of the transaction, the source and destination addresses and cryptographic signatures. Payment Processor A third-party institution or service provider that processes electronic payment transactions between a customer’s bank account and a merchant’s bank account. It is connected to the payment network. Secure Element (SE) A secure hardware component that host the Apple Pay App and other applets authorized by payment networks or issuer banks.30 Application executed over the Secure Element 30 2. are protected by the security features of the Secure Element. Some of these features of the Secure Element are: cryptographically secure random number generation, cryptographic services, secure execution of software modules, and secure time measurements.31 31 12. Payment Terminal An application that runs on the point-of-sales device and facilitates mobile payments via Near-Field Communication (NFC), and other business operations. Token Service This process is responsible for verifying the One-Time Payment Tokens (OTPT). This process is offered by the Token service provider (TSP). 3.4Card Number Representations There are different numbers and identifiers which represent the card of a cardholder during the mobile payment process: the PAN, the DAN, and the OTPT. The PAN (primary account number) of a debit or credit card is issued by the Issuer Bank. This number consists of maximum 19 digits and follows the ISO/IEC 7812-1:201732 standard. There are 32 10. three main components to the PAN:33 33 9. 1.Issuer Identification Number (IIN): This is a six-digit number identifying the issuer bank. This number is used for routing a transaction to the correct issuer for authorization. For the routing purpose this number is not encrypted. 2.Individual Account Number: This number can range from seven to twelve digits in length. It is the unique identifier of a client’s account within the issuer bank. 3.Check Digit: One digit used for error detection. It is calculated using the Luhn algorithm.34 This digit helps to detect errors in 34 8. data entry, such as typing mistakes. cashless payment with mobile wallets 9 The DAN (device account number) is a unique number linked to a specific device for a particular card by Apple. The DAN is created during the card registration phase. It is encrypted and stored in the back-end, such that Apple itself cannot directly access this number.35 35 2. This DAN is used within the Apple Pay ecosystem as a replacement of the PAN. The OTPT (one-time payment token) is a unique, single-use token that is generated for each transaction. The OTPT is sent to a merchant instead of the PAN or the DAN.36 The tokenization process ensures 36 11. that the actual card details are never shared with the merchant or transmitted over the network. During the enrolment phase, the PAN is provided to Apple’s servers, and a corresponding DAN is created and stored on the device. When a payment is made using Apple Pay, the OTPT is generated such that the DAN can be obtained or extracted through detokenization.37 The token is sent to the merchant and used to process 37 4. the payment with the payment network. The token is translated back into the corresponding PAN and processed via the payment network with the Issuer Bank.