# Forensic Analysis of the iOS Apple Pay Mobile Payment System

Trevor Nicholson, Darren Hayes, Nhien-An Le-Khac

► To cite this version:

Trevor Nicholson, Darren Hayes, Nhien-An Le-Khac. Forensic Analysis of the iOS Apple Pay Mobile Payment System. 19th IFIP International Conference on Digital Forensics (DigitalForensics), Jan 2023, Arlington, VA, United States. pp.3-19, 10.1007/978-3-031-42991-0_1 . hal-05517479

HAL Id: hal-05517479

https://inria.hal.science/hal-05517479v1

Submitted on 18 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Forensic Analysis of the iOS Apple Pay Mobile Payment System

Trevor Nicholson¹, Darren Hayes², and Nhien-An Le-Khac³

¹ Royal Canadian Mounted Police, Surrey, Canada

² Pace University, New York, New York, USA

³ University College Dublin, Dublin, Ireland

an.lekhac@ucd.ie

**Abstract.** Mobile payment systems enable users to complete financial transactions with their smartphones, including contactless payments at retail stores. Because the financial transactions of individuals are indicators of their lifestyles, they are potential sources of data in criminal investigations. The items purchased and even the locations of transactions can constitute valuable evidence. However, mobile payment system data is intended to be interpreted by computer software not human investigators. As a result, a barrier exists between raw application data and their clear interpretations for evidentiary purposes.

This chapter describes research focused on Apple Pay, the leading mobile payment system for mobile debit wallet transactions in the United States. The research has sought to examine the Apple Pay mobile payment system and identify specific sources of forensic artifacts. This includes determining and interpreting the payment card and transaction data residing in the Apple Pay application and syncing across user devices, as well as the implications of deleting Apple Pay application data.

**Keywords:** Mobile Payment Forensics · Apple Pay · iCloud Backup Analysis

## 1 Introduction

Smartphones have replaced small devices from cameras and calculators to GPS navigation units and door keys. Just as cash has been largely replaced by payment cards in recent decades, trends suggest that smartphones are slated to replace payment cards. This is made possible by enabling users to store digital versions of payment cards in digital wallets and employ them to make contactless mobile payments.

Mobile payments employ mobile devices to initiate, authorize and confirm exchanges of financial value in return for goods or services [6]. One of the most widely used mobile payment systems is Apple Pay, which is included in current versions of iOS. First introduced in 2014 in the United States, the global adoption of Apple Pay continues to grow [7]. In 2020, the Apple Pay user base grew by 66 million, accounting for 92% of U.S. mobile debit wallet transactions [7].
Apple Pay combines the functionality of Apple Wallet that digitally stores payment and loyalty program cards with mobile payment functionality to use the cards at a growing number of merchants. Apple Wallet and Apple Pay are part of the same application, with Apple Wallet providing card storage and Apple Pay handling transactions. Apple Pay enables users to make online purchases as well as purchases at brick-and-mortar businesses via contactless payment at point-of-sale (PoS) terminals using near-field communications (NFC) technology, just like credit cards [11]. Apple Pay executes on Apple devices that run various versions of iOS, macOS and watchOS. The services include the syncing of Apple devices via iCloud [17], which enables users to add credit cards, debit cards and loyalty program cards, as well as drivers licenses, boarding passes, etc. to their Apple Wallets. Once a payment card is added, it can be selected within the Apple Pay application to complete transactions [2]. Information related to payment cards and transactions is protected in a secure encrypted environment on Apple devices [15].

Forensic artifacts related to mobile payment applications on smartphones can advance investigations because user transactions are consolidated on the devices. While transaction records have been available to investigators prior to mobile payment systems, services such as Apple Pay make the records readily available. Digital card usage information includes location- and time-related evidence that was not available previously. Transaction records provide evidence pertaining to where the phone has been and when specific items were purchased. The presence of digital payment cards on a smartphone also provides strong indications about the device user, which can be important in an investigation.

Mobile payment application data has evidentiary value. However, in the case of Apple Pay, forensic practitioners are presented with some challenges. First, Apple has employed industry-leading security measures on its devices that limit data access. Second, Apple Pay is not designed to present its information for analysis. Consequently, forensic practitioners must determine how to access the data and how to make logical sense of it. Meanwhile, other challenges persist. One is the lack of clarity about what happens to transactions when the associated payment cards are removed from Apple Pay. Another is the lack of understanding about the available data.

This research has focused on the underlying data in Apple Pay applications running on iOS devices. Experimentation was conducted to determine how data is presented in different circumstances. This was accomplished using iPhone test devices in practice to develop actual datasets and extracting the resulting data for analysis. The experiments provide insights into the available forensic artifacts as well as the limitations.

## 2 Related Work

Little, if any, research has been conducted on Apple Pay that could be used by forensic practitioners in investigations involving Apply Pay or other mobile payment services. While the literature discusses forensic analyses of Apple iOS
operating systems, no research has focused on Apple Pay. Potential reasons are that mobile payment solutions are relatively new and the diverse technologies in the market are spreading research efforts too thin. However, Apple Pay has been the subject of research directed at assessing the security methods employed by its operating system.

Understanding the iOS operating system is beneficial when conducting forensics analysis of Apple Pay. Liao et al. [9] describe the iOS system architecture as having three levels, interface layer, business logic layer and data access layer. The interface layer is the software interface for user interactions, the business logic layer implements specific functions and the data access layer parses data for databases. In order to conduct experiments with Apple Pay, it is necessary to understand that an application presents an interface to a user, but a layer of data exists that is not visible, or even accessible, to the user; this layer is likely to contain much more information than what is displayed by the user interface.

Oesteicher [12] noted the relevance of iCloud data in investigations involving Apple devices. He identified that the primary purpose of iCloud is to function as a service that syncs data between a user's Apple devices. Cloud services offered by Apple are expanding in their capabilities and have millions of users. Indeed, the importance of cloud data in digital forensic investigations is more important than ever [8, 12, 13]. Clarity is needed about the presence of Apple Pay data in iCloud and its utility in mobile payment investigations.

Apple Pay is a leading mobile payment system, but it has not been studied by researchers. Therefore, it is understandable that little research has focused on alternative mobile payment systems. Bosamia and Patel [3] have examined security issues in Apple Pay, Google Pay and other mobile payment systems. They note that all the mobile payment systems function similarly as point-of-sale terminals and ultimately have similar vulnerabilities. However, they did not study the forensic artifacts existing in the mobile payment systems.

Sun et al. [14] focused specifically on security issues related to Samsung Pay. They proposed a method for securing transactions using encryption based on user fingerprints. While they did not conduct a forensic analysis of Samsung Pay, they note parenthetically that the security of Apple Pay is enhanced via the use of a Secure Element (SE) chip.

Every mobile payment application is expected to produce artifacts, some of them different, and store them in a unique manner that depends on the operating system. In the case of Apple Pay, the complexity is exacerbated by syncing a smartwatch with a smartphone and using the smartwatch to complete a transaction. Hence, the goal of this research is to obtain clarity about the payment-related data that can be recovered in devices running Apple Pay and interpreting the data for presentation in forensic reports.

## 3 Experimental Methodology

The experimental methodology involved setting up test devices with an Apple ID and generating Apple Pay data on them in a natural, real-world manner by
<figure><img src="image_3.png" /><figcaption>Fig. 1. Apple Pay experimental methodology.</figcaption></figure>

adding payment cards and completing transactions. The test data was forensically acquired from the devices at different stages to identify changes. Forensic tools, including Cellebrite Physical Analyzer [4] and Magnet AXIOM [10], were used to analyze the data while maintaining its integrity. Data related to the payment cards and transactions was sought as well as evidence of syncing between devices. This included files related to the Apple Pay application and files that monitor device activity. Figure 1 shows the experimental methodology used in the Apple Pay research.

The datasets used in the experiments were created to closely resemble the datasets likely to be encountered in real investigations. During the testing process, records of events were maintained in an external log. The log helped track device setup, additions of payment cards, details of transactions and the stages when device data extractions were made. Recording the timestamps associated with device actions and events were critical to the task of identifying artifacts – connections between artifacts can be made using the timestamps. The record of timestamps also enabled artifacts to be assessed for their meaning, value and potential locations. The sources of forensic artifacts include the device as well as its connected cloud services.

# 4 Experiments and Findings

This section describes the experiments and findings.
<table><caption>**Table 1.** Experimental devices.</caption><thead><tr><td>Device</td><td>Version</td><td>Apple Pay Application ID</td></tr></thead><tbody><tr><td>Device 1:</td><td>iPhone 12 iOS 15.1.1</td><td>03427D91-3263-4695-A79A-57F4DC342F5B</td></tr><tr><td>Device 2:</td><td>iPhone 11 iOS 15.5</td><td>665A3775-52A9-48C1-8EF7-0D841730D56E</td></tr></tbody></table>

## 4.1 Experimental Devices

An Apple iPhone 11 (Device 1) and Apple iPhone 12 (Device 2) were employed in the experiments. These models were selected because they were released by Apple relatively recently and were in wide use when the research was conducted. Table 1 lists the two devices. Note that Apple Pay and Apple Wallet are essentially part of the same application and, therefore, use the same Application ID. They also fall under the same application bundle identifier, `com.apple.Passbook`.

**Apple ID Setup** In order to establish the cleanest possible testing environment, free of any unintentional synced data, a new Apple ID was created for the testing process. The email account `4n6computing@gmail.com` was created on Google Gmail. Apple services were used to create a new Apple ID using the email address `4n6computing@gmail.com`.

**Device Setup** Devices 1 and 2 were set up in the same manner. The devices were factory reset to ensure that they were clear of previous data. Standard device setup procedures were followed using the newly-created Apple ID associated with the email address `4n6computing@gmail.com`. Initial data extractions were performed on Devices 1 and 2. The extractions were identified by the containing devices and testing stages during which they were acquired. The Apple Pay application was not opened on the devices prior to acquisition. These extractions provided representations of uninitialized Apple Pay data.

**Apple Pay Data Creation** Apple Pay was setup on Device 1. The Apple Pay application is a feature of current versions of iOS, so no application installation was required. Apple Pay was initialized by adding a Scotiabank Visa credit card. The process of adding a card to Apple Pay is straightforward, however, not all cards are compatible. Attempts were made to add a pre-paid Mastercard, but Apple Pay indicated that the card was not compatible. Prompts were followed to validate the successfully-added payment card using the Scotiabank application. Device 1 was used to complete several transactions involving common purchases. The times, purchase amounts and locations were maintained in an external log. Data was extracted from Device 1, which was then analyzed.

**iCloud Testing** Device 1 was backed up to iCloud. Various iCloud extraction tools were used to recover data, which was subsequently analyzed. Additional
<figure><img src="image_4.png" /><figcaption>Fig. 2. Sample FrontFace_embedded_1.png image</figcaption></figure>

iCloud testing was conducted later by returning Device 1 to the factory settings, restoring it from iCloud and then examining the results.

**Synchronization Testing** Device 2 was allowed to synchronize with iCloud and the data was extracted to determine what data was present. The same credit card was then added to Device 2 and the data was extracted again.

**Deleted Data Testing** Apple Pay data was deleted from Device 1 and the data was extracted to determine what information could be recovered.

## 4.2 Apple Pay Application Artifacts

Many of the forensic artifacts related to Apple Pay and the user interactions with it were located in the directories associated with the application. Numerous files containing forensic artifacts were located at the file paths identified in this section. Among these files were SQLite databases, PLIST files and images. The specifics of these files and the artifacts contained in them are described below. Much of the information about the card added to Apple Pay and the transactions completed by the card were duplicated across these files. Apple Pay does not store credit card numbers [6]. The experiments confirmed this as searches for the complete physical payment card did not return any results. Instead, Apple Pay uses a Device Account Number when completing transactions [6]. The Device Account Number is a unique number that Apple Pay assigns to a payment card.

**Payment Card General Information** At the path `\private/var/mobile/Library/Passes/Cards/`, images of the card, including one with the last four digits of the physical card number overlaid on it, were located. Several of the images were icons related to the card issuer that were located in the Preview subfolder. An image of the card with the name `FrontFace_embedded_1.png` was located in the FrontFace subfolder (Figure 2). Directories at this location were also named according to the unique card IDs of the cards in Apple Pay. After
<figure><img src="image_5.png" /><figcaption>Fig. 3. Screenshot of file `PaymentWebServiceContext.archive`.</figcaption></figure>

the basic card information has been collected for the card being investigated, the database files, PLIST files and JSON files can be reviewed for detailed information. These files can be exported from the device extraction data and opened in a viewer program capable of presenting the information for the file type.

**Pass.json** A JSON file `pass.json` located at `/private/var/mobile/Library/Passes/Cards/{uniquecardid}.pkpass/` was found to contain a significant amount of data for each card in Apple Wallet. Note that the file path includes the unique card ID. A viewer with a JSON formatter may be used to view the file. Some of the data was duplicated in the `passes23.sqlite` file whereas other data related to the card was only found in the JSON file. JSON files contain detailed information about the cards added to Apple Wallet, including the card issuers and relevant card numbers.

**PaymentWebServicesContext.archive** A PLIST file `PaymentWeb-ServiceContext.archive` located at `/private/var/mobile/Library/Passes/` was found to contain Apple Pay configuration and card validation information (Figure 3). The timestamps are in Coordinated Universal Time (UTC).

**UserNotifications.archive** The BPLIST file `UserNotifications.archive` was found to contain the configurations for Apple Pay notifications as well as detailed information about the transactions completed by the payment cards. Notification information for each card was found under the path `PDWalletUserNotificationPass/` in the `StateChanged:{uniquecardid}` field. The notification configurations for Apple Pay included the content of the message and the timestamp (in UTC) for specific messages that were displayed.

During the experiments, it was observed that the message “X Card is ready for Apple Pay” was displayed when a card was validated successfully. Thus, the time that the message was displayed provides an indication of when the card was
validated. Additionally, the `UserNotifications.archive` file contained a substantial amount of transaction information. The transactions were listed by their Service Identifier followed by `PDPassPaymentTransactionUserNotification`. The Service Identifier was found linked to the `service_identifier` field of the payment_transaction table in the `passes23.sqlite` file. In the case of multiple transactions with a single merchant, only the most recent transaction for the merchant was included in the file.

### `passes23.sqlite`
The `SQLite` database `passes23.sqlite` was found to contain a large portion of data related to the Apple Pay application, including a significant amount of data related to payment cards, expired transactions, merchants involved in the transactions and location data. The `passes23.sqlite` file can be exported from the device data extraction and viewed in a forensic `SQLite` database viewer. Timestamps in the database were found to be in the Apple Cocoa Core Data Time (Apple Absolute Time) format. The database contained 170 tables. Not all the tables were found to have been used by Apple Pay during the experiments. It was clear what some of the data in the tables represented, while other data would require further evaluation. The experiments indicate that the database is the main location where Apple Pay stores user card information and transaction data.

Temporary journaling files and write-ahead log files can be used by databases, including `SQLite` databases, to provide data resilience. During the experiments, no journaling or write-ahead log files were located for the `passes23.sqlite` database. Since many tables exist in the database, a process has to be followed to associate the data between different tables. The process begins by identifying the unique card ID of each card in Apple Pay. The `passes23.sqlite` file was found to contain many entries directly related to the cards added to Apple Wallet. As previously noted, card and transaction information were duplicated in multiple files. Apple Pay does not store credit card numbers, but instead uses a Device Account Number when completing transactions. This number is unique to a card. The last four digits can be located in the `dpan_suffix` field of the `payment_application` table. The `passes23.sqlite` file was also found to contain entries related directly to the transactions made by the cards in Apple Wallet.

### `ScheduledActivities.archive`
The `BPLIST` file `ScheduledActivities.archi`ve located at `/private/var/mobile/Library/Passes/` was found to contain tasks related to Apple Pay. The tasks are scheduled by the system (Table 2).

### Comparison of Database States
The states of various Apple Pay related files must be considered to help identify iOS devices that were in use but did not have Apple Pay set up on them. The directory `private/var/mobile/ Library/Passes/ Cards/` existed but contained no files, so the `pass.json` file was not present. The `PaymentWebServiceContext.archive` file was present
<table><caption>**Table 2.** Relevant fields of file ScheduledActivities.archive.</caption><thead><tr><td>Field</td><td>Description</td></tr></thead><tbody><tr><td>PDPaymentWebServicesCoordinator</td><td>Sub-fields contain data for scheduled tasks to conduct checks of the verification status and consistency of payment cards added to Apple Pay</td></tr><tr><td>PDMapsBrandAndMerchant Updater</td><td>Sub-fields contain data for scheduled tasks to conduct checks for updated merchant information</td></tr><tr><td>PDMapsMerchantProcessingService</td><td>Sub-fields contain data for scheduled tasks to conduct checks for updated merchant processing data</td></tr></tbody></table>

and contained configuration data and a date in the registrationDate field. The UserNotifications.archive file did not exist. The passes23.sqlite database file existed with all 170 tables; however, the only tables containing data were cloud_store_database, cloud_store_zone, index_fetched_metadata, index_metadata, location_index_node and sqlite_master. The data in these tables was general, including version numbers and container names. The ScheduledActivities.archive file was present and its contents appeared to be very similar with the exception of card data.

## 4.3 iOS Artifacts

Upon completing the analysis of Apple Pay application files, additional artifacts related to payment cards added to Apple Pay and the use of the application may be found in files inherent to the iOS operating system or in files outside the application folders.

**knowledgeC.db** The generic database file knowledgeC.db is maintained by the iOS operating system and can be used to determine the time frames when Apple Pay was used. The file is commonly analyzed by forensic practitioners during examinations of iOS and macOS devices because it contains many artifacts related to users and their use of applications [5].

During the experiments, knowledgeC.db was examined for artifacts relevant to Apple Pay. The database file knowledgeC.db has an associated write-ahead log (WAL) file that should also be considered because it may contain relevant database transactions that have not yet been applied to the database. Artifacts related to the use of Apple Pay and Apple Wallet were found in knowledgeC.db under its iOS bundle name com.apple.Passbook as well as com.apple.PassbookUIService. Note that Passbook is the former name of Apple Wallet.

In the experiments, Apple Pay was used to add payment cards, complete card validation and perform transactions. Figure 4 shows the contents of ZOBJECT,
<table><caption>Fig. 4. Contents of the ZOBJECT table in database knowledgeC.db.</caption><thead><tr><td>ZVALUESTRING</td><td>ZSTARTDATE (UTC)</td><td>ZENDDATE (UTC)</td></tr></thead><tbody><tr><td>com.apple.Passbook</td><td>2022-06-16 04:44:49</td><td>2022-06-16 04:45:00</td></tr><tr><td>com.apple.PassbookUIService</td><td>2022-06-16 04:45:00</td><td>2022-06-16 04:45:29</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:44:49</td><td>2022-06-16 04:46:03</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:45:29</td><td>2022-06-16 04:46:03</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:46:30</td><td>2022-06-16 04:46:58</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:46:30</td><td>2022-06-16 04:47:07</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:46:58</td><td>2022-06-16 04:47:07</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:53:48</td><td>2022-06-16 04:53:49</td></tr><tr><td>com.apple.Passbook</td><td>2022-06-16 04:53:52</td><td>2022-06-16 04:54:05</td></tr></tbody></table>

the main knowledgeC.db table, which contains data pertaining to the use of applications. Data related to the use of Apple Pay was discovered in this table.

<table><caption>Fig. 5. Contents of the Scalars table in database ADDataStore.sqlitedb.</caption><thead><tr><td>key</td><td>daysSince1970</td><td>value</td></tr></thead><tbody><tr><td>appBackgroundActiveTime.com.apple.Passbook</td><td>19159</td><td>4</td></tr><tr><td>appActivationCount.com.apple.Passbook</td><td>19159</td><td>6</td></tr><tr><td>appLaunchCount.com.apple.PassbookUIService</td><td>19159</td><td>4</td></tr><tr><td>appActivationCount.com.apple.PassbookUIService</td><td>19159</td><td>8</td></tr><tr><td>appActiveTime.com.apple.PassbookUIService</td><td>19159</td><td>97</td></tr><tr><td>appActiveTime.com.apple.Passbook</td><td>19159</td><td>165</td></tr></tbody></table>

ADDataStore.sqlitedb Similar to knowledgeC.db, the ADDataStore.sqlite db database file holds logs of iOS operating system activities [5]. This database can be used to determine when Apple Pay was last launched and how many times it was launched and activated in the recent past. Analysis revealed that the database only retained entries for about a week. Figure 5 shows the contents of the Scalars table in the database.

com.apple.passd.plist The PLIST file com.apple.passd.plist, located in the iOS preferences folder, contains data relevant to Apple Pay. Table 3 shows the relevant fields of the file and their descriptions. The content includes the configuration and states of the Apple Pay application as well as timestamps for payment card validation and removal.
<table><caption>**Table 3.** Relevant fields of file `com.apple.passd.plist`.</caption><thead><tr><td>Field</td><td>Description</td></tr></thead><tbody><tr><td>PDLastPaymentPassInsertionOrRemovalDate</td><td>Timestamp in UTC when a card was last removed or validated in Apple Pay</td></tr><tr><td>PDDefaultPaymentPassUniqueIdentifier</td><td>Unique identifier for the payment card that is the default card</td></tr><tr><td>PDLastUnlockedTime</td><td>Last time Apple Pay was unlocked and accessed (Apple Absolute Time); analysis revealed that this need not indicate that a user launched and unlocked Apple Pay, but it may have been a consequence of unlocking the device</td></tr></tbody></table>

**Cache.db** The database file `Cache.db` located at `.../com.apple.passd/` was found to contain a small amount of data relevant to Apple Pay. The table `cfurl_cache_response` in the database contained a field `request_key` with the URL for a web resource related to Apple. In the URL was the serial number of a payment card that resided in Apple Pay. The same serial number was identified in the `serial_number` field of the pass table in the `passes23.sqlite` file. The timestamp appears to record when a key was requested for the associated card.

The name of the database suggests that it is used for caching data. Experiments also revealed that the database was susceptible to garbage collection. As a result, it is difficult to specify what relevant data `Cache.db` would contain at any given time, but it is a potential source of data. `Cache.db` was found to have an associated WAL file named `Cache.db-wal` that contained the locations where Apple Pay downloaded keys associated with its payment cards.

**Apple Keychain and Safari** Apple Keychain is a feature available to Apple device users. It is not directly related to Apple Pay and Apple Pay was not found to store its card information in Apple Keychain, but it may be an alternate source of artifacts for payment cards found in Apple Pay.

Apple Keychain stores sensitive information such as passwords and tokens as well as information about cards used in a Safari browser. The benefit of using Apple Keychain is that it securely stores sensitive information and allows the information to be synced with other Apple devices belonging to a user.

The option to store credit card information in Apple Keychain is presented to a user during the setup of an Apple device. If a user opts to store credit card information in the keychain, it is a potential source of artifacts. Credit card information is added via Safari for use within the browser and a user can manage the information using the browser.
## 4.4 Artifacts from Other Applications

This section discusses Apple Pay artifacts that are related to other applications.

**Financial Institution Application Files** While applications associated with the financial institutions of a user are not part of Apple Pay, a common method for validating a card for use with Apple Pay is to employ the financial institution application. Therefore, it is recommended to examine financial institution applications for artifacts. In fact, the presence of such applications alone could provide useful leads in investigations.

**Third-Party Browsers** As mentioned above, payment card information can be added to a Safari browser. Users often install and use third-party Internet browsers such as Google Chrome, which stores card information and processes payments via Google Pay. Thus, third-party browsers are also potential sources of artifacts.

## 4.5 iCloud Backup Artifacts

There are instances where a forensic practitioner may not have access to the data residing on an Apple device. An alternate data source is an iCloud backup of the device [16]. Experiments revealed that the default setting for iCloud backups on iOS 15 is for the feature to be activated. Also, most default Apple applications, including Apple Wallet, are set to be included in the iCloud backup. Thus, Apple Pay data could be recoverable from an iCloud backup.

Of course, judicial authorization would be required to access a subject's iCloud data in an investigation. One option is to seek judicial authorization to have Apple provide iCloud data for the investigation. Another option is for a forensic practitioner to access the subject's iCloud storage with judicial authorization and proceed to extract Apple Pay artifacts. Several iCloud extractions were performed to investigate this possibility. A test device with an active Apple Pay account and several transactions was backed up to iCloud. Three cloud forensic tools were used to analyze the iCloud backup. The extractions yielded several Apple Pay artifacts.

**httpstorage.sqlite** An empty database file httpstorages.sqlite was located in the iCloud backup at the path com.apple.Passbook/Library/HTTPStorages/com.apple.Passbook/. While the extracted copy of the database file did not contain database entries, the fact that it is a database indicates that it could, under different circumstances, provide relevant information.

**Financial Institution Applications** Depending on the financial institution applications and their settings, data pertaining to validations of Apple Pay transactions made using payment cards could be included in an iCloud backup. Experiments confirmed that this is, in fact, the case, and the extracted data would be relevant in an investigation.
**com.apple.passd.plist** The PLIST file `com.apple.passd.plist` was found to be located at the path `/mobile/Library/Preferences/com`. This file contained less data than the version of the same file located on the device. However, it contained the unique card ID of the payment card added to Apple Pay.

**Summary** In order to confirm the findings listed above, experiments were conducted using a test iPhone. The iPhone was previously used to conduct Apple Pay transactions with a payment card and its Apple Wallet application was set for iCloud backup. A factory reset of the test iPhone was completed. The iPhone data on the test device was restored from the iCloud backup and the device was examined.

The experiments revealed that the original payment card appeared in Apple Pay as a suggested card, not an added and validated card. The payment card was then added to Apple Wallet again by entering its CVV number and verifying it through the card issuer. After the card was added, none of the pre-existing transaction data was present. This result is consistent with what was found in the iCloud extractions. It is also identical to what was found on an Apple device synced to the same Apple ID.

## 4.6 Investigative Scenarios

Two scenarios were examined to demonstrate the relevance of Apple Pay artifacts in real-world investigations. The scenarios led to additional experiments involving Apple device syncing and data deletion.

**Apple Pay Data Targeting** The first scenario involved a malicious entity targeting Apple Pay data in an iCloud backup of an iOS device and on the device itself. To assess the available iCloud backup data, the iCloud data of an iOS test device was extracted and analyzed. The device had previously used payment cards to conduct several Apple Pay transactions. Additionally, the Apple Wallet application on the device had the default setting for iCloud backups.

The analysis revealed that access to the iCloud backup would provide negligible information. Specifically, the malicious entity would be able to determine the number of cards in Apple Wallet, card types and their issuers, last four digits of the card numbers and the unique card IDs assigned to the cards by Apple. However, no transaction data would be available. Also, the malicious entity would be unable to further compromise the Apple Pay account or payment cards using the information obtained from the iCloud backup.

To assess the available Apple Pay data, the data residing on the iOS test devices was extracted and analyzed. When an iOS test device had not used Apple Pay but was synced to the same Apple ID as other devices that used Apple Pay, the results were identical to those obtained with the iCloud backup. Some data was available, but not enough to compromise the payment card or Apple Pay account.
However, when an iOS test device was used with Apple Pay, compromising the device would provide access to the data in the Apple Pay user interface. The data includes transaction data, location data and card data, such as its issuer and the last several digits of the Device Account Number and the payment card. However, the data would not enable the payment card to be compromised or transferred. In order to make purchases with Apple Pay, a malicious entity would have to re-authenticate the device with a passcode or alternate means such as Face ID.

**Apple Pay Data Deletion** The second scenario involved a malicious user attempting to delete transaction data by removing the payment card associated with the transactions in Apple Pay. To assess the consequences, a payment card was added to Apple Pay on a test iPhone and transactions were made. The card was then removed, the device was power cycled, following which data was extracted from the test device.

Analysis revealed that the main Apple Pay data files listed in this chapter were almost devoid of artifacts related to the payment card and transactions. However, some additional files were found to contain artifacts. These files would enable the unique card IDs of cards added to Apple Pay to be identified. The most valuable files contained the unique card IDs, card issuers and transaction information, including the merchants, merchant locations (cities) and purchase amounts. The files use timestamps as their names and would have different file names in different cases. The identified files were:

- File 677048032271198 located at /DuetExpertCenter/streams/UserNotificationEvents/local/.

- File 677048032276680 located at /Biome/streams/public/Notification/local/.

- File 677047489833466 located at /Biome/streams/restricted/UserActivityMetadata/local/.

# 5 Discussion

This research has identified a number of sources of forensic artifacts related to Apple Pay. Artifacts related to Apple Pay payment cards and transactions were forensically recovered from iOS devices. Also, insights were gained about specific Apple Pay artifacts syncing across iOS devices belonging to a user. This was assessed based on the various states of the Apple Pay applications on the synced devices. The experiments revealed that syncing does not work for Apple Pay in that transactions executed by a given iOS device reside only on the device. An exception is when an Apple Watch is used to execute transactions. Although the research did not focus on Apple Watch devices, the exception exists because an Apple Watch works in conjunction and synchronization with an iOS device to complete transactions.
This research also investigated whether users can clear their Apple Pay transaction histories and whether the details can be recovered. The experiments revealed that removing a payment card from Apple Pay removes the transactions from the main Apple Pay files. However, transaction details can potentially be recovered from other locations. Ultimately, the research results have value because they are likely to produce evidentiary artifacts that benefit real-world investigations. Using the artifacts identified in this research, a forensic practitioner could determine which physical payment cards were used within Apple Pay to make purchases as well as very specific details about the transactions completed by the cards using Apple Pay. A forensic practitioner could also use the artifacts identified in iCloud backups to determine the physical cards that users hold in their Apple Wallet applications.

The results related to deleted data would be useful in finding transactions related to previously-used payment cards on iOS devices. However, completing a factory reset of an iOS device would conceal evidence because it would eliminate the possibility of recovering the artifacts described in this chapter.

Direct comparisons of this work against other research in digital forensics would be challenging because no previous research has focused on forensic artifacts in mobile payment applications. However, comparisons can be made with some security research papers.

Margraf et al. [11] discovered that the security of Apple Pay was comparable to that of a physical credit card. This research supports the finding because it identified that Apple Pay has an additional layer of security that requires device authentication before a point-of-sale terminal transaction, which physical credit cards do not have on low-value transactions. Additionally, Oesteicher [12] identified the relevance of iCloud data in digital forensic investigations. This research also found that iCloud data is relevant to Apple Pay investigations, especially if the physical device is inaccessible because iCloud contained some payment card information. While iCloud does not currently maintain Apple Pay transaction data, future updates by Apple may change this situation.

## 6 Conclusions

The Apple Pay forensic artifacts identified in this research enable digital forensic professionals to identify payment cards used in Apple Pay and obtain details about completed transactions, including dates and times, and locations with latitude and longitude coordinates. The research has also provided clarity about Apple Pay data syncing between iOS devices connected to the same Apple ID. Additionally, insights were obtained about Apple Pay data at risk when iOS devices and iCloud accounts are compromised. The research also identified the payment card and transaction artifacts that remain after attempts have been made to delete Apple Pay data by removing payment cards from the application. Finally, sources for payment card artifacts outside of Apple Pay such as financial institution applications, Internet browsers and Apple Keychain were identified.
Future research will focus on enhancing the opportunities for forensic prac-
titioners to access iOS device data. This includes forensically-sound procedures
for handling seized iOS devices and comparing the results of different extraction
tools. Although Apple Watch forensics has been investigated [1], the forensic
implications of executing Apple Pay transactions on Apple Watch are not well
understood. Future research will also examine this issue with the goal of identify-
ing the artifacts that are synced between devices during Apple Pay transactions.

References

1. S. Alabdulsalam, K. Schaefer, T. Kechadi and N. Le-Khac, Internet of Things forensics – Challenges and a case study, in *Advances in Digital Forensics XIV*, G. Peterson and S. Shenoi (Eds.), Springer, Cham, Switzerland, pp. 35–48, 2018.

2. Apple, iPhone User Guide – Keep Cards and Passes in Wallet on iPhone, Cupertino, California (support.apple.com/en-ca/guide/iphone/iphc05dba539/ios), 2023.

3. M. Bosamia and D. Patel, Wallet payments: Recent potential threats and vulnerabilities with possible security measures, *International Journal of Computer Sciences and Engineering*, vol. 7(1), pp. 810–817, 2019.

4. Cellebrite, Cellebrite Physical Analyzer, Petah Tikva, Israel (cellebrite.com/en/physical-analyzer), 2023.

5. S. Edwards, Knowledge is power! Using the macOS/iOS knowledgeC.db database to determine precise user and application usage, *mac4n6 Blog* (*www.mac4n6.com/?offset=1536804062230&category=iOS*), August 6, 2018.

6. A. Jawale and J. Park, A security analysis of Apple Pay, *Proceedings of the European Intelligence and Security Informatics Conference*, pp. 160–163, 2016.

7. A. Julija, 10+ Apple Pay statistics that show mobile payments are the future, *Furtunly Blog Statistics* (fortunly.com/statisticsapple-pay-statistics), December 16, 2022.

8. N. Le-Khac, M. Mollema, R. Craig, S. Ryder and L. Chen, Data acquisition in the cloud, in *Security, Privacy and Digital Forensics in the Cloud*, L. Chen, H. Takabi and N. Le-Khac (Eds.), Wiley, Singapore, pp. 257–282, 2019.

9. Z. Liao, S. Wu, B. Xi, F. Wang, D. Ming and B. Chen, Digital forensic design of iOS operating system, *Proceedings of the Third High Performance Computing and Cluster Technologies Conference*, pp. 232–236, 2019.

10. Magnet Forensics, Magnet AXIOM, Waterloo, Canada (www.magnetforensics.com/products/magnet-axiom), 2023.

11. M. Margraf, S. Lange and F. Otterbein, Security evaluation of Apple Pay at point-of-sale terminals, *Proceedings of the Tenth International Conference on Next Generation Mobile Applications, Security and Technologies*, pp. 115–120, 2016.

12. K. Oesteicher, A forensically robust method for acquisition of iCloud data, *Digital Investigation*, vol. 11(S2), pp. S106–S113, 2014.

13. S. Schlepphorst, K. Choo and N. Le-Khac, Digital forensic approaches for cloud service models: A survey, in *Cyber and Digital Forensic Investigations*, N. Le-Khac and K. Choo (Eds.), Springer, Cham, Switzerland, pp. 175–199, 2020.

14. Y. Sun, R. Ruhl and H. Samuel, A Survey of Payment Token Vulnerabilities Towards Stronger Security with Fingerprint-Based Encryption on Samsung Pay, Project Report, Information Security and Assurance, Concordia University, Ed-monton, Canada, 2018.
15. P. Teufl, T. Zefferer, C. Stromberger and C. Hechenblaikner, iOS encryption systems: Deploying iOS devices in security-critical environments, *Proceedings of the International Conference on Security and Cryptography*, 2013.

16. R. Thantilage and N. Le-Khac, Retrieving e-dating application artifacts from iPhone backups, in *Advances in Digital Forensics XVI*, G. Peterson and S. Shenoi (Eds.), Springer, Cham, Switzerland, pp. 215–230, 2020.

17. A. Yadi and F. Alfi, *iCloud Standard Guide*, Packt Publishing, Birmingham, United Kingdom, 2013.