Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Version 1.4 November 11, 2022 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision Apple One Apple Park Way Cupertino, CA 95014 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Table of Contents 1. Introduction .........................................................................................................4 1.1. Purpose............................................................................................................................4 1.2. Abbreviations...................................................................................................................5 2.ST Introduction.....................................................................................................6 2.1. Target of Evaluation Reference ........................................................................................6 2.2. TOE Guidance...................................................................................................................7 2.3. TOE Overview...................................................................................................................8 2.4. Description of the Apple Pay Service...............................................................................9 2.5. TOE Use Cases ...............................................................................................................18 2.6. TOE Architecture............................................................................................................19 3.Evaluation Assurance..........................................................................................23 3.1. Common Criteria Reference...........................................................................................23 3.2. CC Conformance claim ..................................................................................................23 3.3. Protection Profile Conformance claim...........................................................................23 3.4. Assurance Level.............................................................................................................23 4.Security Problem Definition ................................................................................25 4.1. Assets............................................................................................................................25 4.2. Subjects .........................................................................................................................27 4.3. Assumptions ..................................................................................................................27 4.4. Threat Agents ................................................................................................................28 4.5. Threats...........................................................................................................................28 4.6. Organizational Security Policies ....................................................................................31 5.Security Objectives ............................................................................................33 5.1. Security Objectives for the TOE.....................................................................................33 5.2. Security Objectives for the environment .......................................................................35 5.3. Rationale of the Security objectives for the security problem definition .......................37 6.Security Functional Requirements.......................................................................41 6.1. SFR supporting definitions.............................................................................................41 6.2. Identification and authentication ..................................................................................43 6.3. Access/Flow Control SFRs.............................................................................................46 6.4. Secure Enclave/Secure Element Trusted Channel.........................................................50 6.5. Secure Enclave/Apple Watch Trusted Channel..............................................................50 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 2 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.6. Local data protection......................................................................................................51 6.7. TSF management ...........................................................................................................51 6.8. Security Requirements Rationale ..................................................................................53 7. TOE Summary Specification................................................................................60 7.1. SF User authentication and management......................................................................60 7.2. SF Biometric/Secure Enclave secure channel................................................................63 7.3. SF Secure Enclave/Secure Element secure channel ......................................................63 7.4. SF Secure Enclave/Watch secure channel .....................................................................64 7.5. SF Card Data management ............................................................................................64 7.6. SF Payment management ..............................................................................................65 7.7. SF OS Update.................................................................................................................66 7.8. SF iCloud logout & Device reset.....................................................................................66 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 3 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 1. Introduction 1.1. Purpose The purpose of this document is to define the Target of Evaluation (TOE) for meeting the requirements of Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market (PSD2) and the Commission Delegated Regulation (EU) 2018/389 of 27 November 2017, focusing on the Strong Customer Authentication and Dynamic Linking for Apple Pay. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 4 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 1.2. Abbreviations * refers to the Apple Pay user. Abbreviation Meaning AP Application Processor API Application Programming Interface AR Authorization Random CDCVM Consumer Device Cardholder* Verification Method CL Contactless CRS Contactless Registry Service CVV Card Verification Value HSM Hardware Security Module I/O Input / Output MAC Message Authentication Code NFC Near Field Communication OS Operating System PNO Payment Network Operator PSD2 Directive (EU) 2015/2366 of the European Parliament and of the Coun- cil of 25 November 2015 SCA Strong Customer Authentication SIP System Integrity Protection SKS Secure Key Store SSE An application in the Secure Enclave managing the pairing between the Secure Enclave and the Secure Element TSM Trusted Service Manager TSP Token Service Provider UID Unique Identifier Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 5 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 2.ST Introduction 2.1. Target of Evaluation Reference This Security Target is identified with the following information: The TOE platform is an iPhone 13 with A15 Bionic running iOS version 15.4.1, with the following platform identifiers: The TOE consists of a range of hardware and software components as listed below. Note that all com- ponents are developed by Apple. Security Target identifiers Title Strong Customer Authentication for Apple Pay, on iPhone 13 with A15 Bionic running iOS 15.4.1, Security Target Version 1.4 Date November 11, 2022 Developer Apple Inc. Platform identifiers TOE iPhone 13 with A15 Bionic running iOS 15.4.1 Device Models: iPhone 13 Operating System iOS 15.4.1 (Build 19E258) Developer Apple Inc. TOE Component Version Description Apple Pay App (Wallet) App part of iOS 15.4.1 Authentication policy on data and services In-app transaction data management Application Processor (AP) A15 Bionic Authentication policy on data and services In-app transaction data management Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 6 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target The Secure Element of the device is separately certified according to the Common Criteria and is therefore out of scope of this evaluation. Note: In the evaluated configuration the cryptographic modules are supplied by Apple as part of iOS and sepOS. Readers may draw some assurance from the conformance to FIPS 140-3 certified by the Cryptographic Module Validation Program for corecrypto for each major release (Apple corecrypto User Space Module, Apple corecrypto Kernel Space Module and the Apple Secure Key Store Crypto- graphic Module). Additionally, readers should note that the browser, Safari, is evaluated for each major iOS release us- ing the collaborative PP (cPP), Protection Profile for Application Software Version 1.3. 2.2. TOE Guidance References to the TOE guidance document: Biometric Sensor (Face ID) Gen 4 Sensor for face capture Boot Loader iOS 15.4.1 Allows the device to start and boot the operating system Secure Enclave sepOS part of iOS 15.4.1 Authentication Setup: • Enrollment of the authentication material • User authentication verification Authentication Prover: • Passcode verification • Biometrics matching • Authentication policy on data iOS Platform Device operating system platform (iOS 15.4.1) with the following Apple Pay ser- vices that are included in the TOE: • Console iOS 15.4 .1 Provides the functionality for input/output (I/O) • Logind iOS 15.4.1 Provides functionality for managing user logins and ses- sions • NFCd iOS 15.4.1 Provides functionality for near field communication • Safari iOS 15.4.1 Browser • Settings iOS 15.4.1 Allows the user to indicate their preferred settings for the device, operating system and applications. TOE Component Version Description Apple Pay Guidance Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1: Guidance [AGD] Guidance, version 1.3 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 7 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 2.3. TOE Overview The TOE includes the components implementing Strong Customer Authentication and Dynamic Linking in Apple Pay. The TOE is the iPhone 13 with A15 Bionic running iOS 15.4.1 operating system. The operating system manages the device hardware, provides Apple Pay and Apple Cash functionali- ties, and provides the technologies required to enforce Strong Customer Authentication (SCA) and Dy- namic Linking for Apple Pay and Apple Cash e-commerce payments. Dynamic Linking for a transaction is the link between the authentication code generated upon successful SCA, with both the transaction’s original specific amount and the identity of the payee. The operating system provides a consistent set of capabilities allowing the supervision of enrolled de- vices. This includes the preparation of devices for deployment, the subsequent management of the de- vices, and the termination of management. The TOE platform protects itself by having its own code and data protected from unauthorized access (using hardware provided memory protection features), by securing user and TOE Security Functionali- ty (TSF) data, by ensuring the integrity and authenticity of TSF updates and downloaded applications, and by locking the TOE upon user request or after a defined time of user inactivity. The TOE provides protection of data at rest, and access control mechanisms for use by applications. Access control for data and services, including Apple Pay and Apple Cash, rely on the enforcement of user authentication. To use Apple Pay, a user must have a passcode set on the device and, optionally, biometrics (Face ID). User authentication to authorize an Apple Pay transaction on an enrolled device is provided by a user- defined passcode and user enrolled biometrics. The minimum length of the passcode, passcode rules, and the maximum number of consecutive failed authentication attempts is statically set by Apple for each iOS release. Biometrics are enrolled and managed by the user. Face ID is designed to confirm user attention, provide authentication and mitigate digital and physical spoofing. Face ID can recognize an alternative appearance (by setting the option “Set Up an Alternative Appearance”). Face ID also sup- ports unlocking with a mask on iPhone devices (by setting the option “Face ID with a Mask”) starting with iPhone 12 and iOS 15.4 or later. Alternatively, from iOS 14.5, when the user is wearing a face mask and their paired Apple Watch, they can unlock their iPhone without relying on Face ID if the feature “Unlock with Apple Watch” is enabled; however this feature cannot be used for Apple Pay authorization. The Secure Enclave is responsible for ensuring user authorization (the combination of user authentica- tion and user intent) before a payment is authorized from the device. The TOE relies on its environment to facilitate Apple Pay payments (Apple Pay transactions and Apple Cash transfers): the transaction data is always processed by the Secure Element, which is outside the TOE boundary. The Secure Element only allows a payment to be made after it receives authorization from the Secure Enclave. For each transaction, the payment applets hosted on the Secure Element generate a payment cryptogram. This cryptogram and the Device Account Number form a transaction- specific dynamic security code, which is provided to the payment network and the card issuer, allowing them to verify each transaction. When interacting with Near Field Communication (NFC) enabled payment terminals, the TOE uses the device’s out-of-the-TOE NFC antenna for the communication. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 8 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 2.4. Description of the Apple Pay Service 2.4.1.Card provisioning When a user adds a credit, debit, or prepaid card (including store cards) to Apple Wallet, the device en- crypts the card information and securely sends it, along with other information about the user’s account and device, through Apple Pay servers to the card issuer or the card issuer’s authorized service provider. Using this information, the card issuer (or their service provider) will determine whether to ap- prove adding the card to Apple Wallet. Apple Pay uses three server-side calls to send and receive communication with the card issuer or net- work as part of the card provisioning process: Required Fields, Check Card, and Link and Provision. The card issuer or network uses these calls to verify, approve, and add cards to Apple Wallet. These client server sessions are protected for confidentiality and integrity using TLS protocol. The full card numbers are never stored on the device or on Apple servers. Instead, a unique Device Ac- count Number is created, encrypted, and then stored in the Secure Element. This unique Device Ac- count Number is encrypted in such a way that Apple cannot access it. The Device Account Number is unique and different from usual credit or debit card numbers, the card issuer can prevent its use on a magnetic stripe card, over the phone, or on websites. The Device Account Number located in the Se- cure Element is isolated from the TOE, never stored on Apple servers, and never backed up to iCloud. 2.4.1.1.Adding a credit or debit card manually To add a card manually, the name, card number, expiration date, and card verification value (CVV) are used to facilitate the provisioning process. From within Settings, Apple Wallet, or the Apple Watch app, users can enter that information either by typing or using the device’s camera. When the camera cap- tures the card information, Apple Wallet attempts to populate the name, card number, and expiration date. The photo is never saved to the device or stored in the photo library. After all the fields are filled in, the Check Card process verifies the fields other than the CVV. They are then encrypted and sent to the Apple Pay Server. If a terms and conditions ID is returned with the Check Card process, Apple downloads and displays the terms and conditions of the card issuer to the user. If the user accepts the terms and conditions, Apple sends the ID of the terms that were accepted as well as the CVV to the Link and Provision process. 2.4.1.2.Adding credit or debit cards from an iTunes Store account For a credit or debit card on file with iTunes, the user may be required to reenter their Apple ID pass- word. The card number is retrieved from iTunes and the Check Card process is initiated. If the card is eligible for Apple Pay, the Apple Wallet application will download and display terms and conditions, then send along the term’s ID and the card security code to the Link and Provision process. Additional verifi- cation may occur for iTunes account cards on file. 2.4.1.3.Adding credit or debit cards from a card issuer’s app When the app is registered for use with Apple Pay, keys are established for the app and the card is- suer’s server. These keys are used to encrypt the card information that’s sent to the card issuer. This is designed to prevent the information from being read by the Apple device. The provisioning flow is simi- Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 9 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target lar to that used for manually added cards, as described previously, except one-time passwords are used in lieu of the CVV. 2.4.1.4.Adding credit or debit cards from a card issuer’s website Some card issuers provide the ability to initiate the card provisioning process for Apple Wallet directly from their websites. In this case, the user initiates the task by selecting a card to provision on the card issuer’s website. The user is then directed to a self-contained Apple sign-in experience (contained within Apple’s domain) and is asked to sign in with their Apple ID. Upon successfully signing in, the user then chooses one or more devices to provision the card to and is required to confirm the provisioning result on each respective target device. 2.4.1.5.Additional verification A card issuer can decide whether a credit or debit card requires additional verification. Depending on what’s offered by the card issuer, the user may be able to choose between different options for addi- tional verification, such as a text message, email, or customer service call to complete the verification. For text messages or email, the user selects from contact information the issuer has on file. A code is sent, which must be entered into Apple Wallet, Settings, or the Apple Watch app. For customer service or verification using an app, the issuer performs their own communication process. 2.4.2.Payment authorization For devices having a Secure Enclave, a payment can be made only after it receives authorization from the Secure Enclave. This involves confirming that the user has authenticated with Face ID or the device passcode. Face ID, if available, is the default method, but the passcode can be used at any time. A passcode is automatically offered after two unsuccessful attempts to match a face; after five unsuc- cessful attempts, the passcode is required. A passcode is also required when Face ID is not configured or not enabled for Apple Pay. 2.4.2.1.Using a shared pairing key Communication between the Secure Enclave and the Secure Element takes place over a serial inter- face, with the Secure Element connected to the Near Field Communication (NFC) controller, which in turn is connected to the Application Processor. Though not directly connected, the Secure Enclave and the Secure Element can communicate securely using a shared pairing key that’s provisioned during the manufacturing process. The encryption and authentication of the communication are based on AES, with cryptographic nonces used by both sides to protect against replay attacks. The pairing key is gen- erated inside the Secure Enclave from its UID key and the Secure Element unique identifier. The pairing key is then securely transferred from the Secure Enclave to a hardware security module (HSM) in the factory, which has the key material required to then inject the pairing key into the Secure Element. 2.4.2.2.Authorizing a secure transaction When the user authorizes a transaction, which includes a physical gesture communicated directly to the Secure Enclave, the Secure Enclave sends signed data about the type of authentication and details about the type of transaction (contactless or e-Commerce) to the Secure Element, tied to an Autho- rization Random (AR) value. The AR is generated in the Secure Enclave when a user first provisions a credit card and persists while Apple Pay is enabled, protected by the Secure Enclave encryption and anti-rollback mechanism. It’s securely delivered to the Secure Element through the pairing key. On re- ceipt of a new AR value, the Secure Element marks any previously added cards as deleted. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 10 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 2.4.2.3.Using a payment cryptogram for dynamic security Payment transactions originating from the payment applets include a payment cryptogram along with a Device Account Number. This cryptogram, a one-time code, is computed using a transaction counter and a key. The transaction counter is incremented for each new transaction. The key is provisioned in the payment applet during personalization and is known by the payment network or the card issuer or both. Depending on the payment scheme, other data may also be used in the calculation, including: • A Terminal Unpredictable Number, for near-field-communication (NFC) transactions • An Apple Pay server nonce, for transactions within apps These security codes are provided to the payment network and to the card issuer, which allows the is- suer to verify each transaction. The length of these security codes may vary based on the type of transaction. 2.4.3.Paying with cards using Apple Pay 2.4.3.1.Paying with cards in stores If the device is on and detects an NFC field, it presents the user with the requested card (if automatic selection is turned on for that card) or the default card, which is managed in Settings. The user can also go to Apple Wallet and choose a card, or when the device is locked, double-click the side button on a device with Face ID. Next, before information is transmitted, the user must authenticate using Face ID, or their passcode, before payment information is transmitted. No payment information is sent without user authentication. After the user authenticates, the Device Account Number and a transaction-specific dynamic security code are used when processing the payment. Neither Apple nor a users device sends the full actual credit or debit card numbers to merchants. Apple may receive anonymous transaction information such as the approximate time and location of the transaction, which helps improve Apple Pay and other Apple products and services. 2.4.3.2.Paying with cards within apps Apple Pay can also be used to make payments within iOS apps. When users pay within apps using Apple Pay, Apple receives the encrypted transaction information. Before that information is sent to the developer or merchant, Apple re-encrypts it with a developer-specific key. Apple Pay retains anony- mous transaction information, such as approximate purchase amount. This information can’t be tied to the user and never includes what the user is buying. When an app initiates an Apple Pay payment transaction, the Apple Pay servers receive the encrypted transaction from the device prior to the merchant receiving it. The Apple Pay servers then re-encrypt the transaction with a merchant-specific key before relaying it to the merchant. When an app requests a payment, it calls an API to determine whether the device supports Apple Pay and whether the user has credit or debit cards that can make payments on a payment network accept- ed by the merchant. The app requests any pieces of information it needs to process and fulfill the transaction, such as the billing and shipping address, and contact information. The app then asks iOS Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 11 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target to present the Apple Pay sheet, which requests information for the app as well as other necessary in- formation, such as the card to use. At this time, the app is presented with city, state, and zip code information to calculate the final ship- ping cost. The full set of requested information isn’t provided to the app until the user authorizes the payment with Face ID or the device passcode. After the payment is authorized, the information pre- sented in the Apple Pay sheet will be transferred to the merchant. 2.4.3.3.App payment authorization When the user authorizes the payment, a call is made to the Apple Pay Servers to obtain a crypto- graphic nonce, which is similar to the value returned by the NFC terminal used for in-store transactions. The nonce, along with other transaction data, is passed to the Secure Element to compute a payment credential that’s encrypted with an Apple key. The encrypted payment credential is returned to the Apple Pay servers, which decrypt the credential, verify the nonce in the credential against the nonce originally sent by the Apple Pay Servers, and re-encrypt the payment credential with the merchant key associated with the Merchant ID. The payment is then returned to the device, which hands it back to the app through the API. The app then passes it along to the merchant system for processing. The mer- chant can then decrypt the payment credential with its private key for processing. This, together with the signature from Apple’s servers, allows the merchant to verify that the transaction was intended for this particular merchant, and ensures dynamic linking of the transaction with its amount and the payee. The APIs require an entitlement that specifies the supported Merchant IDs. An app can also include ad- ditional data (such as an order number or customer identity) to send to the Secure Element to be signed, such as an order number or customer identity, ensuring the transaction cant be diverted to a different customer. This is accomplished by the app developer, who can specify applicationData on the PKPaymentRequest. A hash of this data is included in the encrypted payment data. The merchant is then responsible for verifying that their applicationData hash matches whats included in the payment data. In order to process payments, the merchant takes the following steps: - Send the payment information to their server, along with the other information needed to process the order - Verify the hashes and signature of the payment data - Decrypt the encrypted payment data, and confirm the validity of the transactionId, currency- Code, transactionAmount, and applicationData fields - Submit the payment data to the payment processing network and the order to their order-track- ing system 2.4.3.4.Paying with cards at websites Apple Pay can be used to make payments at websites on iPhone. Apple Pay on the web requires all par- ticipating websites to register with Apple. The Apple servers perform domain name validation and issue a TLS client certificate. Websites supporting Apple Pay are required to serve their content over HTTPS. For each payment transaction, websites need to obtain a secure and unique merchant session with an Apple server using the Apple-issued TLS client certificate. Merchant session data is signed by Apple. After a merchant session signature is verified, a website may query whether the user has an Apple Pay- capable device and whether they have a credit, debit, or prepaid card activated on the device. No other Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 12 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target details are shared. If the user doesn’t want to share this information, they can disable Apple Pay queries in Safari privacy settings on iPhone. After a merchant session is validated, all security and privacy measures are the same as when a user pays within an app. 2.4.4.Rendering cards unusable with Apple Pay Credit, debit, and prepaid cards added to the Secure Element can only be used if the Secure Element is presented with authorization using the same pairing key and Authorization Random (AR) value from when the card was added. On receipt of a new AR value, the Secure Element marks any previously added cards as deleted. This allows the operating system to instruct the Secure Enclave to render cards unusable by marking its copy of the AR as invalid under the following scenarios: • The passcode is disabled • The user signs out of iCloud • The user selects Erase All Content and Settings • The device is restored from Recovery Mode 2.4.4.1.Suspending, removing, and erasing cards Users can suspend Apple Pay on the device by placing their devices in Lost Mode using Find My iPhone. Users also have the ability to remove and erase their cards from Apple Pay using Find My iPhone, iCloud.com, or directly on their devices using Apple Wallet. The ability to make payments using cards on the device will be suspended or removed from Apple Pay by the card issuer or respective payment network, even if the device is offline and not connected to a cellular or Wi-Fi network. Users can also call their card issuer to suspend or remove cards from Apple Pay. When a user erases the entire device—using Erase All Content and Settings, using Find My iPhone, or restoring their device—iPhone instructs the Secure Element to mark all cards as deleted. This has the effect of immediately changing the cards to an unusable state until the Apple Pay servers can be con- tacted to fully erase the cards from the Secure Element. Independently, the Secure Enclave marks the Authorization Random as invalid so that further payment authorizations for previously enrolled cards aren’t possible. When the device is online, it attempts to contact the Apple Pay servers to ensure that all cards in the Secure Element are erased. 2.4.5.Apple Cash In iOS 11.2 or later, Apple Pay can be used on an iPhone to send, receive, and request money from other users. When a user receives money, its added to an Apple Cash account that can be accessed in Apple Wallet or within Settings > Wallet & Apple Pay across any of the eligible devices the user has signed in with their Apple ID. In iOS 14, the organizer of an iCloud family who has verified their identity with Apple Cash can enable Apple Cash for their family members under the age of 18. Optionally, the organizer can restrict the money sending capabilities of these users to family members only or contacts only. If the family mem- Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 13 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target ber under the age of 18 goes through an Apple ID account recovery, the organizer of the family must manually reenable the Apple Cash card for that user. If the family member under the age of 18 is no longer part of the iCloud family, their Apple Cash balance is automatically transferred to the organizer’s account. When the user sets up Apple Cash, the same information as when the user adds a credit or debit card may be shared with our partner bank Green Dot Bank and with Apple Payments Inc., a wholly owned subsidiary created to protect your privacy by storing and processing information separately from the rest of Apple, and in a way that the rest of Apple doesn’t know. This information is used only for trou- bleshooting, fraud prevention, and regulatory purposes. 2.4.5.1.Using Apple Cash in iMessage To use person-to-person payments and Apple Cash, a user must be signed in to their iCloud account on an Apple Cash compatible device and have two-factor authentication set up on the iCloud account. Money requests and transfers between users are initiated from within the Messages app or by asking Siri. When a user attempts to send money, Messages will display the Apple Pay sheet. The Apple Cash balance is always used first. If necessary, additional funds are drawn from a second credit or debit card the user has added to Apple Wallet. 2.4.5.2.Using Apple Cash in stores, apps, and on the web The Apple Cash card in Apple Wallet can be used with Apple Pay to make payments in stores, in apps, and on the web. Money in the Apple Cash account can also be transferred to a bank account. In addi- tion to money being received from another user, money can be added to the Apple Cash account from a debit or prepaid card in Apple Wallet. Apple Payments Inc. stores, and may use, the user’s transaction data for troubleshooting, fraud preven- tion, and regulatory purposes once a transaction is completed. The rest of Apple doesn’t know who the user sent money to, received money from, or where the user made a purchase with their Apple Cash card. When the user sends money with Apple Pay, adds money to an Apple Cash account, or transfers money to a bank account, a call is made to the Apple Pay servers to obtain a cryptographic nonce, which is similar to the value returned for Apple Pay within apps. The nonce, along with other transaction data, is passed to the Secure Element to generate a payment signature. The signature is returned to the Apple Pay servers. The authentication, integrity, and correctness of the transaction is verified through the payment signature and the nonce by Apple Pay servers. Money transfer is then initiated, and the user is notified of a completed transaction. If the transaction involves: • A debit card for adding money to Apple Cash • Providing supplemental money if the Apple Cash balance is insufficient An encrypted payment credential is also produced and sent to Apple Pay servers, similar to how Apple Pay works within apps and websites. After the balance of the Apple Cash account exceeds a certain amount or if unusual activity is detect- ed, the user is prompted to verify their identity. Information provided to verify the user’s identity - such as social security number or answers to questions (for example, to confirm a street name the user lived on previously) - is securely transmitted to the Apple partner and encrypted using their key. Apple can’t Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 14 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target decrypt this data. The user is prompted to verify their identity again if they perform an Apple ID account recovery, before regaining access to their Apple Cash balance. 2.4.6.Device unlock when the user is wearing a face mask An iPhone that uses Face ID running iOS 14.5 or later can be unlocked using a paired Apple Watch Se- ries 3 or later running watchOS 7.4 or later when the user is wearing a mask. Unlock with Apple Watch when the user is wearing a mask works only for unlocking the iPhone. It doesn't authenticate a user for use with Apple Pay. From iOS 15.4, when “Face ID with a Mask” is enabled on an iPhone, the user can use Face ID authenti- cation while wearing a mask. In this case, “Face ID with a mask” can be used not only for device unlock but also for payment authorization. When “Face ID with a Mask” is enabled, it is available for the next 6.5 hours after one of the following user actions: • Successful Face ID match attempt (with or without a mask) • Device passcode validation • Device unlock with Apple Watch Performing any of these actions extends the period that “Face ID with a Mask” authentication can be used for an additional 6.5 hours. When Face ID is enabled on an iPhone, the device immediately locks when the Sleep/Wake button is pressed, and the device locks every time it goes to sleep. Face ID requires a successful match - or op- tionally use of the passcode- at every wake. The probability that a random person in the population could unlock a user’s iPhone or iPad is less than 1 in 1,000,000 with Face ID—including when Face ID with a mask is turned on. This probability in- creases with multiple appearances (up to 1 in 500,000 with two appearances). For additional protec- tion, Face ID allows only five unsuccessful match attempts before a passcode or password is required to obtain access to the user’s device or account. With Face ID, the probability of a false match is higher for: • Twins and siblings who look like the user • Children under the age of 13 (because their distinct facial features may not have fully de- veloped) The probability is further increased in these two cases when Face ID with a mask is used. If a user is concerned about a false match, Apple recommends using a passcode to authenticate. If the user wears glasses, they can improve the accuracy of Face ID with a mask by setting it up with their glasses on. 2.4.7.Apple Card 2.4.7.1.Apple Card application On supported models of iPhone and Mac, a user can securely apply for an Apple Card. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 15 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target In iOS 12.4 or later, mac OS 10.14.6 or later, and watchOS 5.3 or later, Apple Card can be used with Apple Pay to make payments in stores, in apps, and on the web. Apple Card is currently only available for qualifying applicants in the United States. To apply for Apple Card, the user must be signed into their iCloud account on an Apple Pay–compatible iOS or iPadOS device and have two-factor authentication set up on the iCloud account. When the ap- plication is approved, Apple Card is available in Apple Wallet or within Settings > Wallet & Apple Pay across any of the eligible devices the user has signed in with their Apple ID. When a user applies for Apple Card, user identity information is securely verified by Apple’s identity provider partners and then shared with Goldman Sachs Bank USA for the purposes of identity and credit evaluation. Information such as the social security number or ID document image provided during the application is securely transmitted to Apple’s identity provider partners and/or Goldman Sachs Bank USA encrypted with their respective keys. Apple can’t decrypt this data. The income information provided during the application, and the bank account information used for bill payments, are securely transmitted to Goldman Sachs Bank USA encrypted with their key. The bank account information is saved in Keychain. Apple can’t decrypt this data. When adding Apple Card to Apple Wallet, the same information as when a user adds a credit or debit card may be shared with the Apple partner bank Goldman Sachs Bank USA and with Apple Payments Inc. This information is used only for troubleshooting, fraud prevention, and regulatory purposes. In iOS 14.6 or later, iPadOS 14.6 or later, and watchOS 7.5 or later, the organizer of an iCloud family with an Apple Card can share their card with their iCloud Family members over the age of 13. User authenti- cation is required to confirm the invitation. Apple Wallet uses a key in the Secure Enclave to compute a signature that binds the owner and the invitee. That signature is validated on Apple servers. Optionally, the organizer can set a transaction limit to the participants. Participant cards can also be locked to pause their spending at any time through Apple Wallet. When a co-owner or participant over the age of 18 accepts the invitation and applies, they go through the same application process as de- fined in the Apple Card application section in Apple Wallet. A physical card can be ordered from Apple Card in Apple Wallet. After the user receives the physical card, it’s activated using the NFC tag that’s in the bifold envelope of the physical card. The tag is unique per card and can’t be used to activate another user’s card. Alternatively, the card can be manually acti- vated in Apple Wallet settings. Additionally, the user can also choose to lock or unlock the physical card at any time from Apple Wallet. 2.4.7.2.Apple Card payments and Apple Wallet pass details Payments due on the Apple Card account can be made from Apple Wallet in iOS with Apple Cash and a bank account. Bill payments can be scheduled as recurring or as a one-time payment at a specific date with Apple Cash and a bank account. When a user makes a payment, a call is made to the Apple Pay servers to obtain a cryptographic nonce similar to Apple Cash. The nonce, along with the payment set- up details, is passed to the Secure Element to generate a signature. The signature is then returned to the Apple Pay servers. The authentication, integrity, and correctness of the payment are verified through the signature and the nonce by Apple Pay servers, and the order is passed on to Goldman Sachs Bank USA for processing. The Apple Card number is retrieved by Apple Wallet by presenting a certificate. The Apple Pay Server validates the certificate to confirm the key was generated in the Secure Enclave. It then uses this key to encrypt the Apple Card number before returning it to Apple Wallet, so that only the iPhone that re- Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 16 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target quested the Apple Card number can decrypt it. After decryption, the Apple Card number is saved in iCloud Keychain. Displaying the Apple Card number details in the pass using Apple Wallet requires user authentication with Face ID, Touch ID, or a passcode. It can be replaced by the user in the card information section and disables the previous one. 2.4.7.3.Advanced Fraud Protection In iOS 15 or later and iPadOS 15 or later, the Apple Card user can enable Advanced Fraud Protection in Apple Wallet. When enabled, the Card Security Code refreshes every few days. 2.4.8.Credit and debit cards for transit In some cities, transit readers accept EMV (smart) cards to pay for transit rides. When users present an EMV credit or debit card to those readers, user authentication is required just as with “Paying with cards in stores.” In iOS 12.3 or later, some existing EMV credit/debit cards in Apple Wallet can be enabled for Express Transit. Express Transit lets the user to pay for a trip at supported transit operators without requiring Face ID, or a passcode. When a user provisions an EMV credit or debit card, the first card provisioned to Apple Wallet is enabled for Express Transit. The user can tap the More button on the front of the card in Apple Wallet and disable Express Transit for that card by setting Express Transit Settings to None. The user can also select a different credit or debit card as their Express Transit card using Apple Wallet. Face ID, Touch ID, or a passcode is required to reenable or select a different card for Express Transit. Apple Card and Apple Cash are eligible for Express Transit. Payments with credit and debit cards for Express Transit (without requiring Face ID or a passcode) are not in the scope of this Security Target. 2.4.9.Express Cards with power reserve If iOS isn’t running because iPhone needs to be charged, there may still be enough power in the battery to support Express Card transactions. Supported iPhone devices automatically support this feature with: • A payment or transit card designated as the Express Transit card • Student ID cards with Express Mode turned on • Car keys with Express Mode turned on • Home keys with Express Mode turned on • Hospitality or Corporate access cards with Express Mode turned on Pressing the side button (or on iPhone SE 2nd generation, the Home button) displays the low-battery icon as well as text indicating that Express Cards are available to use. The NFC controller performs Ex- press Card transactions under the same conditions as when iOS is running, except that transactions are indicated only with haptic notification (no visible notification is shown). On iPhone SE 2nd genera- Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 17 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target tion, completed transactions may take a few seconds to appear on screen. This feature isn’t available when a standard user-initiated shutdown is performed. Payments using Express Cards with power reserve mode are not in the scope of this Security Target. 2.4.10.Contactless passes in Apple Pay To transmit data from supported passes to compatible NFC terminals, Apple uses the Apple Value Added Services (Apple VAS) protocol. The VAS protocol can be implemented on contactless terminals or in iPhone apps and uses NFC to communicate with supported Apple devices. The VAS protocol works over a short distance and can be used to present contactless passes independently or as part of an Apple Pay transaction. When the device is held near the NFC terminal, the terminal initiates receiving the pass information by sending a request for a pass. If the user has a pass with the pass provider’s identifier, the user is asked to authorize its use using Face ID, Touch ID, or a passcode. The pass information, a timestamp, and a single-use random ECDH P-256 key are used with the pass provider’s public key to derive an encryp- tion key for the pass data, which is sent to the terminal. Contactless passes in Apple Pay are not in the scope of this Security Target. 2.5. TOE Use Cases The TOE covers the following use cases: Use Case Description UC.Device_Usage Device usage The User can manage the device’s authentication credentials, including enrolling new biometric templates, updating biometric templates, deleting biometric tem- plates and changing the passcode. UC.OS_Update Device Software Update The User can perform an update of the software in the device to a new version. This use case requires that the User verifies the device’s passcode. This use case ensures preservation of the User settings on the device: - No change to the User’s authentication credentials (passcode or any bio- metrics) - No change to the User’s data within the Secure Element unless specified by the data’s issuer UC.Apple_Pay_In- stall_Init Apple Pay installation and initialization The User can provision a new card in Apple Wallet UC.Apple_Pay_Usage Apple Pay usage The User can perform Apple Pay transactions. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 18 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 2.6. TOE Architecture The TOE platform includes some hardware elements of the device and all the components of the device Platform that are relevant to strong customer authentication (SCA) and Apple Pay; The Secure Enclave within the System on a Chip (SoC) of the device, and the Application Processor (AP) with the OS are the main components of this TOE. The Secure Element is outside of the TOE boundaries. User authentication is managed by the Secure Enclave, which defines and enforces the user access policy to data and services. The AP allows the OS to process and the OS allows the Secure Enclave to get authentication material from various sources (biometric sensors and the console). iOS also allows the Apple Pay services to operate; it holds Apple Wallet and relays data between the Secure Enclave and the Secure Element. The Secure Element is the secure component holding the Apple Pay secrets and processes the Apple Pay transactions. UC.End_Of_Service Termination by User The User can end the Apple Pay mode of operation by performing a card removal in Apple Wallet. The User can also end all current Apple Pay services by un-registering their iCloud account. Termination by Issuer The Issuer can perform a de-registration of an Apple Pay card that was provisioned on the User’s device, following a card revocation or a user account termination. UC.End_Of_Life Termination of device The User can clear a device from all their settings and data by performing a device full reset. The User could also end the life of their device by physically destroying it. Use Case Description Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 19 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target This is highlighted in the following figure: Figure 1: TOE Components and subsystems 2.6.1.TOE Environment In this evaluation, the TOE environment includes the Secure Element (Hardware, Operating System, CRS applet and payment applets found in the Secure Element) and the NFC communication layer. The Secure Element, included in the device, is already evaluated to Common Criteria. The Secure Ele- ment is contained in the same package as the NFCC. Payment Applets in the Secure Element process Apple Pay transactions. All other components and subsystems of iOS including user space and kernel software, hardware and subsystems included in the device including the camera, networking subsystems, and Apple Watch are considered part of the TOE environment. The camera is used as an input device for card data. The net- Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 20 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target working subsystem provides connectivity to the Apple Servers responsible for managing Apple Pay transactions and to the Apple Watch. 2.6.2.Subsystems and Modules of the TOE This section further breaks down the TOE components, providing more detail on the subsystems of the TOE and the modules that comprise them. The subsystems of the TOE consist of: - Secure Enclave: The software components of the TOE residing in the Secure Enclave. This subsystem includes several applications executing on the Secure Enclave operating system: - BioApp which provides functionality for processing biometric data and generating biometric templates - The SKS (Secure Key Store) is a hardware cryptographic module. The module is em- bedded inside the Secure Enclave and packaged within the Application Processor - The SSE (Secure Enclave-Secure Element) manages the pairing between the Secure Enclave and the Secure Element, allowing the Secure Element to process only gen- uine and authorized Apple Pay transactions. The SSE application maintains sensitive pairing material, allowing Secure Element and Secure Enclave to perform a mutual authentication before exchanging data - Apple Wallet: The subsystem handles the enrollment of applications and governs the pay- ment operation. - iOS components: - Springboard: Provides the functionality for the iOS user interface - NFCd: This daemon facilitates the communication between Apple Wallet and the Se- cure Element - Safari browser: Provides the user interface to conduct payment transactions - Security Framework: Provides cryptographic support - Settings application - Device components: - Face ID sensor: The hardware component and associated drivers that allow face data to be captured and passed to BioApp to allow for enrollment and matching - Boot-loader: The subsystem responsible for ensuring that the device boots using software with assured integrity - Console: Hardware and associated drivers that handles user input via the keyboard, and displays output via the screen All other iOS parts are outside of the TOE, including the Secure Element together with the NFCC hard- ware, and the XNU iOS kernel. The iOS subsystem components are individual applications. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 21 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 2.6.3.TOE Lifecycle The TOE lifecycle phases are as follows: The Design, Fabrication, and Integration phases are entirely within the control of Apple Inc. The Issuance phase is the physical delivery of the device to the User. This can be directly, in the case of an individual, or through a third party or an organization that is responsible for providing the device to the User. Apple’s model of the Initialization phase requires that the device is claimed by the User by associating it with the User’s iCloud account and Apple ID. Before that point, Strong User Authentication and associ- ated TSFs are not relevant, and Apple Pay is not accessible. Apple Pay and Apple Cash services require that an iCloud account and user authentication credentials are set up (Passcode and optionally biomet- rics). The Usage phase describes the period when the Apple Pay service is activated and used by the asso- ciated User. The Termination phase describes deactivation of the Apple Pay service to the User and may involve physical destruction of the device as well as a complete reset of iOS or Apple Pay service termination by the User. When the mobile device is received, the model of the device should be verified to verify that the model number is one of those listed in Section 2.1. This can be accomplished using any of the following meth- ods: - Removing the SIM tray and physically checking the upper side of the SIM tray slot - Once authenticated to the mobile device the information is available to mobile device Users in Settings " General " About, and clicking on the number displayed next to “Model” Lifecycle Phases Design HW/FW design SW design Secure Element Applet design Fabrication HW fabrication SW implementation Applet development Integration iPhone integration Assembly, Trust provisioning, FW integration, SW and applet loading Issuance iPhone delivery to User Initialization User account creation Account setup: iCloud, Apple ID Enrollment/ Provisioning User Authentication setup Passcode setup, biometrics enrollment Apple Pay provisioning Usage Device Usage Device unlock, User Authentication, iOS use, (optional) iOS update Apple Pay transaction Termination Physical destruction iOS reset Apple Pay termination Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 22 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 3.Evaluation Assurance 3.1. Common Criteria Reference This Security Target is based on the following Common CriteriaTM (CC) publications: 3.2. CC Conformance claim This Security Target is conformant to CC Part 2 and CC Part 3. 3.3. Protection Profile Conformance claim This Security Target does not claim any conformance to an existing Protection Profile. 3.4. Assurance Level The evaluation assurance level (EAL) for this work is EAL 2 augmented with ADV_FSP.3 and ALC_FLR.3: Common Criteria CC Version Revision Date Part 1: Introduction and general model V3.1 R5 April 2017 Part 2: Security functional requirements V3.1 R5 April 2017 Part 3: Security assurance requirements V3.1 R5 April 2017 Assurance Class ADV: Development ADV_ARC.1 Security architecture description ADV_FSP.3 Functional specification with complete summary ADV_TDS.1 Basic design AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC: Life-cycle support ALC_CMC.2 Use of a CM system ALC_CMS.2 Parts of the TOE CM coverage ALC_DEL.1 Delivery procedures ALC_FLR.3 Systematic flaw remediation ASE: Security Target evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 23 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE: Tests ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis Assurance Class Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 24 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 4.Security Problem Definition 4.1. Assets The assets of this security target are: Asset Sensit- ivity* Type Definition D.User_Passcode I, C User Passcode value setup by the User and used to wake up device after power loss, unlock the device, and also allows the User to authorize payments (Apple Pay transactions or Apple Cash trans- fers). D.User_Bio I, C User Biometric data for the enrolled User’s biometrics, used to unlock the device and to authorize payments (Apple Pay transactions or Apple Cash transfers). D.Card_Data I, C User, TSF Apple Pay card data, including credit/debit card number, User’s name, expiration date, CVV, and transaction data (e.g. transaction history). Apple Cash card data, including Apple Cash card information and transfer data (e.g. transfer history). Note: The card data is used as TSF data when the TOE sends it encrypted to the issuer, via Apple servers, in order to generate the Device Account Number stored in the Secure Element. D.User_Intent I User State of the device resulting from a physical interaction of the User with the TOE, characterizing the intent of the User to perform payments (Apple Pay transactions or Apple Cash transfers) D.Payment_Data I User Apple Pay/Apple Cash payment data being authorized by the User. For Apple Pay, critical elements are the amount (including the currency), the emitter, and the recipient (S.Merchant) which con- stitute the core of the Dynamic Linking. For Apple Cash, critical elements of transfers are the amount (including the currency), the emitter, and the recipient. Additional critical elements can be defined by Apple and the Card Issuer. D.OS I TSF OS version currently installed on the device. This asset is not the OS code itself or the version number of that code. This asset is the set of elements that compose an OS version as prepared for that device, including elements verifiable by that device during boot (for instance the sepOS), and by the User through an identified version number. D.User_Configura- tion I TSF User configuration is a representation of the user personal config- uration including Apple Pay, Apple Cash, and Face ID settings. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 25 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target *: I = Integrity, C = Confidentiality D.SEP_Configuration I TSF Secure Enclave configuration is a representation of the state of the Secure Enclave in the device. It comprises (but is not limited to) the Secure Enclave OS version and the state of the user authentic- ation functions (Passcode, enrolled biometrics, authenticated cre- dentials, retry counters, and authentication based access control settings). D.SEP_SE I, C TSF Secret data that allows secure communication between the Secure Enclave and the Secure Element during processing of an Apple Pay transaction or Apple Cash transfer. D.SEP_Bio I, C TSF Secret data that allows secure communication between the Secure Enclave and the biometric sensor during processing of biometric authentication. D.SEP_Watch I, C TSF Secret data that allows secure communication between the Secure Enclave on the TOE and the Secure Enclave on the Paired Watch, in the case the Paired Watch is used to unlock the TOE. The pair- ing secret allows the TOE and the Paired Watch to exchange sens- itive data like the unlock secret. D.Unlock_Secret I,C TSF Secret data that is shared by the Secure Enclave on the TOE with the Paired Watch Secure Enclave to unlock the TOE. It is released by the Paired Watch to facilitate the TOE unlock if Face ID detects the User is wearing a mask. This asset is created by the TOE when the Unlock with Apple Watch feature is enabled by the User, and does not exist if there is no Paired Watch or if this feature is dis- abled. Asset Sensit- ivity* Type Definition Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 26 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 4.2. Subjects The subjects of this Security Target are: 4.3. Assumptions The assumptions for this Security Target are the following: Subject Definition S.User User of Apple Pay/Apple Cash on the device, able to: - Authenticate on the device (biometrics or passcode) - Manage authentication credentials (biometrics or passcode) - Manage device configuration (OS version, iCloud account) - Provision/enroll cards - Authorize Apple Pay transactions/Apple Cash transfers by providing consent for the transaction to proceed (biometrics/passcode and user intent) - Cancel the Apple Pay/Apple Cash service S.Apple_Servers Apple servers in charge of: - Management of S.User iCloud account - Management of S.User provisioning/enrollment in Apple Pay/Apple Cash - Management of OS releases, including Apple Wallet - Device’s interface for processing Apple Pay transactions/ Apple Cash transfers (contact S.Issuer) S.Issuers The Issuer (or its service provider) is the third party in charge of: - Management of S.User data for Apple Pay/Apple Cash services - Processing Apple Pay transactions/Apple Cash transfers S.Merchant The merchant is the third party accepting payment through an Apple Pay transaction or Apple Cash transfer. S.SE Certified Secure Element of the device including the TOE. S.Apple_Watch Apple Watch of S.User paired with the TOE (if applicable). Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 27 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 4.4. Threat Agents The threat agents of this TOE are the following: 4.5. Threats The threats to assets of this TOE are the following: Assumption Definition A.DEVICE_AUTH The User of the device owns all the Apple Pay and Apple Cash activities that are per- formed on a device. All authentication credentials (Biometrics or Passcode) for the device that are enabled for use with Apple Pay/Apple Cash are owned and protected by the User of the device. A.PERSO The Apple Pay and Apple Cash Issuers guarantee the correctness of the card data input in the device during provisioning/enrollment: Data shall uniquely identify a financial payment means and be linked to the account owned by the identified user. A.CDCVM The Secure Element and applets hosted on the Secure Element manage the CDCVM re- quirement for NFC payment transactions and require the TOE to provide user authentica- tion and intent to pay each time CDCVM is needed. By default, applets configured for ex- press mode do not require user authorization for transit use. A.WATCH_USER If the User optionally pairs an Apple Watch to their iPhone, they own it and ensure the con- fidentiality of its authentication credentials. Threat Agent Definition S.Attacker A threat agent trying to interact with the Apple Pay and Apple Cash system fraudulently, trying to modify the configuration and data of genuine Users’ devices or forging data on their own device. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 28 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Threat Name Definition Assets T.CORRUPT Corrupted Transaction or Transfer An attacker attempts to corrupt an Apple Pay trans- action or an Apple Cash transfer. To gain from the attack, the attacker could be the emitter of the transaction or transfer, and attempt to reduce what it intends to pay (debit amount from attacker’s ac- count) from what it was supposed to pay (credit amount request or transfer amount agreed between attacker and victim). The attacker could also at- tempt to corrupt a payment when it is the recipient, and increase what it supposed to receive (credit transaction amount) from what it was supposed to receive (debit amount agreed). The attacker could also attempt to modify the recipient of a credit transaction by changing the payee in an Apple Pay transaction or changing the recipient of an Apple Cash transfer. D.Payment_Data D.User_Configuration D.OS T.PHYSICAL Physical The loss or theft of the device may give rise to loss of confidentiality of User data including credentials and TSF data. These physical access threats may involve attacks which attempt to access the device through external hardware ports, through its user interface, and also through direct and possibly de- structive access to its storage media. The goal of such attacks is to access Apple Pay or Apple Cash data from a lost or stolen device which is not expec- ted to return to its User. Note: Defending against device re-use after phys- ical compromise is out of scope. D.User_Passcode D.User_Bio D.Card_Data D.Unlock_Secret* D.SEP_Watch* T.RECOVER Card Re- covery An attacker attempts to recover Apple Pay or Apple Cash card data from an erased or blocked device and use it to perform a financial transaction or transfer. The attacker will target potential breaches in the process of Apple Pay cancellation, Apple Pay card revocation, Apple Cash disenrollment, Apple Cash card revocation, or iOS erase all content and settings. D.User_Configuration D.Card_Data D.OS T.REPLAY Replay An attacker attempts to replay an Apple Pay trans- action or Apple Cash transfer. D.Payment_Data T.SILENT Silent Transaction An attacker attempts to modify the behavior of the device, in order to perform silent Apple Pay transac- tions or Apple Cash transfers for some benefit. The attacker would have to perform the attack without knowledge of the device’s rightful owner who will be the victim of the attack. D.User_Intent D.User_Configuration D.SEP_Configuration D.SEP_SE D.OS Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 29 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target * Partial threat: By unlocking the device, the attacker could have a higher chance to access Apple Pay data. **Partial threat: the device can be unlocked using the paired watch but it does not allow the User to use provisioned cards. T.SKIMMING Authentica- tion Bypass An attacker attempts to perform a payment with Apple Pay or Apple Cash, bypassing the required authentication step (biometrics data verification or passcode verification). D.User_Intent D.Payment_Data D.SEP_Configuration D.User_Configuration D.OS T.USURP Card Own- ership Usurpation An attacker could attempt to authenticate on a device, with a goal of using any provisioned cards on that device. The attacker could focus on the card data during Apple Pay provisioning or Apple Cash enrollment. D.User_Bio D.User_Passcode D.User_Configuration D.SEP_Bio D.Card_Data D.OS D.Unlock_Secret* D.SEP_Watch* Threat Name Definition Assets Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 30 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Assets & Threats mapping table: 4.6. Organizational Security Policies The organizations associated with the Apple Pay service shall comply with the following Organizational Security Policies as security rules, procedures, practices, or guidelines imposed by an organization upon its operations: Asset - Property - I = Integrity C = Confidentiality T. C O R R U P T T. P H Y S I C A L T. R E C O V E R T. R E P L A Y T. S K I M M I N G T. S I L E N T T. U S U R P D.Unlock_Secret I,C X X D.User_Bio I,C X X D.User_Passcode I,C X X D.User_Intent I X X D.Payment_Data I X X X D.Card_Data I,C X X X D.OS I X X X X X D.User_Configuration I X X X X X D.SEP_Configuration I X X D.SEP_Watch I,C X X D.SEP_SE I,C X D.SEP_Bio I,C X OSP Definition P.UPDATE Apple ensures that only an authenticated User can update their device’s operating system to a newly released iOS. Apple also informs the Apple Pay and Apple Cash Issuers and PNOs of new applicable features of new releases. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 31 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target P.DYN_LINK Apple enables the enforcement of Dynamic Linking for e-Commerce payments using Apple Pay or Apple Cash cards, on device side and server side. This Organizational Security Policy guar- antees that Apple preserves the following properties from design to feature release for Apple Pay and Apple Cash e-Commerce payments: (a)The payer is made aware of the amount of the payment transaction and of the payee. (b)The authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction. (c)The authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer. (d)Any change to the amount or the payee results in the invalidation of the authentication code. P.WATCH The TOE allows the User to enable unlock with Apple Watch through a secure channel when an optional Apple Watch is paired with the device. When this feature is enabled, wrist detection is turned on, and Face ID detects the User is wearing a mask, the TOE can be unlocked by the paired Apple Watch if it is unlocked and on the wrist of the User. OSP Definition Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 32 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 5.Security Objectives 5.1. Security Objectives for the TOE Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 33 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Security Object- ives Definition OT.User_auth The TOE enforces the following authentication policy: • Passcode only: o Add, update, or delete Biometrics o Update passcode o Modify authentication policy (except for disabling the express mode) o Update the OS to a new version signed by Apple • Passcode or biometric (if enrolled) o Unlock of the device o Payments confirmation • Paired Apple Watch (optional): o Unlock of the device if Face ID has detected the User is wearing a mask OT.Card_Data The TOE enforces that sensitive card data: • Is encrypted before being sent to the Apple server • Is not accessible after sent to the Apple Server OT.Passcode_De- lete The TOE enforces that removing the passcode: • Disables biometric authentication • Disables Apple Pay/Cash OT.Card_Delete The TOE securely triggers the deletion of each individual Apple Pay/Apple Cash card when: • A card is removed from Apple Wallet • The TOE handles the revocation of a card by its Issuer • The use of Apple Pay is canceled (from iCloud, the Settings or passcode remov- al) • The iCloud account is no longer associated with the device When a card is removed, the TOE also instructs the Secure Element to mark it as de- leted. OT.Auth_SE The TOE provides the Secure Element with passcode/biometric user authentication features for Apple Pay/Apple Cash payment/transfer approval. OT.Payment For eCommerce transactions and Apple Cash transfers, the TOE enforces that transac- tion details are displayed to the User (including the card to be used from Apple Wallet, the amount, and the payee) before the User shows their intent to pay and authenticates for payment validation. The TOE ensures that these details cannot be corrupted between the payment validation and the moment when details are sent to the Secure Element. For NFC transactions, if the device is on and detects an NFC field, it will present the User with the requested card (if automatic selection is turned on for that card) or the default card, which is managed in Settings. The User can also manually select a card in Apple Wallet. The TOE also requests explicit intent from the User for Apple Pay transactions and Apple Cash transfers. OT.Bio_Delete TOE Biometrics delete is a secure erase of the enrolled biometric data. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 34 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 5.2. Security Objectives for the environment OT.Device_Reset TOE securely deletes all User data when the User launches an “Erase All Content and Settings” on the OS or a device erase from iCloud. This also initiates the disabling of Apple Pay/Apple Cash and plans the destruction of Apple Pay/Apple Cash cards that will be effective when the device is restored. OT.Anti_Replay The TOE ensures that each payment processed by an Apple Pay/Apple Cash card holds the unique identifier. OT.OS_Update TOE enforces security measures ensuring preservation of User data when an OS update is installed in the TOE. This objective protects the user authentication credentials (Bio- metrics and Passcode), the Apple Pay card data, the Apple Cash card, and more. OT.Watch The TOE can enforce secured communication with an optional paired Apple Watch. Security Object- ives Definition Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 35 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Environment Security Objectives Definition OE.Card_Data The Issuer is responsible for using the appropriate security measures to protect the confidentiality and the integrity of the sensitive card data and guaranteeing the authen- ticity of the card during enrolment. The Secure Element is responsible for securing the card validation exchanges with the Issuer’s TSM and for ensuring confidentiality and integrity of each card’s sensitive data during storage and use. OE.Perso The Issuer is responsible for verifying that the User is authorized to perform a transac- tion on the account of the card used as a reference, before allowing the card personal- ization. The Issuer also ensures the robustness of the personalization data, to prevent attacks like forgery, counterfeit, or corruption. OE.Card_Delete The Issuers of all payment cards provisioned on a device are informed after the User removes a card from that device, removes that device from the iCloud account, or per- forms a device Erase All Content and Settings. The Issuers ensure these cards are re- moved from the User's account (i.e. the unlinking process of the DPAN from the FPAN, which is done by the Issuer or the corresponding TSP). The Secure Element is responsible for securely deleting the stored card sensitive data (private/secret). OE.Anti_Replay The Apple Pay server verifies that each payment (e-Commerce Apple Pay transaction or Apple Cash transfer) is not replayed. The payment is invalidated if this verification fails. For in-store transactions (i.e. NFC transactions), a similar anti-replay mechanism is used with the participation of the NFC terminal. OE.Transac- tion_Verification For Apple Pay, the cryptogram released by the Secure Element for an Apple Pay trans- action is verified by the Issuer (or its service provider). The cryptogram validation result allows the Issuer to approve or reject the transaction. The payment is invalidated if this verification fails. For Apple Cash, the Apple Cash server ensures that no Apple Cash transfer can be ex- ecuted if the submitted quote (received by the server before the User approves) does not match the transaction data (received by the server once device completes transfer processing). The modifications that the server is able to detect cover, but are not lim- ited to, the amount and the recipient. OE.Dynamic_Link- ing For eCommerce transactions, the Apple Pay server preserves and Issuer server verifies the cryptographic based dynamic linking of the transaction data (including amount and payee). The payment is invalidated if this verification fails. OE.Statement For Apple Pay, the payment card Issuers ensure that the statement associated to the card (list of transactions) is fully accurate and includes, but is not restricted to, the amount and recipient of each transaction. For Apple Cash, the payment card Issuer ensures that the ledger associated to an Apple Cash account (list of transfers including completed, canceled, and pending) is fully accurate. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 36 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 5.3. Rationale of the Security objectives for the security problem definition The following table details the rationale for each element of the security problem definition. For all the objectives for the TOE, OT.OS_Update also ensures the authentication configuration is preserved during the OS update. OE.Genuine_Wallet The Apple Wallet application is provided and signed by Apple. OE.CDCVM Express mode compatible applets hosted on the Secure Element are responsible for checking the CDCVM state, including it within transaction data where required, and allowing normal or Express transit transactions as applicable. Payment networks or issuers are responsible for ensuring that Express transactions can only be accepted for transit-specific use by requiring that non-transit Apple Pay pay- ment transactions have a successful CDCVM. OE.Watch The S.Apple_Watch is responsible for ensuring the confidentiality of the unlock secret provided by the iPhone during all its lifetime: from inception at enabling of the “Unlock with Apple Watch” feature, during its storage, during its release for unlocking the iPhone, and when it is deleted when the feature is disabled. The S.Apple_Watch is responsible for ensuring that it is protected by a passcode and the wrist detection feature is turned on in order to enable the feature “Unlock iPhone with Apple Watch”. OE.User The User is responsible for ensuring that: • They own all the Apple Pay/Cash activities that are performed on a device • The passcode is robust and protected • Only their own biometrics credentials are enrolled (they do not enroll biomet- rics of someone else) • Only their own Apple Watch is paired with the TOE and the paired Apple Watch is protected. This includes abiding by the watchOS Software License Agree- ment and protecting the confidentiality of the paired Apple Watch’s passcode Environment Security Objectives Definition Element Rationale A.DEVICE_AUTH OE.User and OE.Watch cover A.DEVICE_AUTH ensuring the User owns and protects all the authentication credentials. A.PERSO OE.Perso covers A.PERSO ensuring the provisioning process verifies the ownership of the provisioned cards. A.CDCVM OE.CDCVM covers A.CDCVM ensuring the Secure Element uses the TSF features when required. A.WATCH_USER OE.User and OE.Watch cover A.WATCH_USER ensuring the User of the device owns and protects their Apple Watch and related credentials. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 37 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target T.SKIMMING OT.User_Auth, OT.Auth_SE and OT.Payment ensure that an Apple Pay transaction or an Apple Cash transfer is always authenticated and authorized by the User. OT.User_Auth and OE.Genuine_Wallet ensure that the Apple release of a new OS or Apple Wallet imple- menting the authentication functions and payment functions are controlled, and that it preserves the confidentiality and integrity of the authentication and payment data. OT.- Passcode_Delete ensures that if the passcode is turned off, the Apple Pay and Biometric authentication are not available anymore. T.USURP OT.OS_Update and OE.Card_Data ensure that the Apple Pay/Apple Cash card data is kept confidential and not altered from an attacker during storage and use in the Secure Ele- ment. OT.User_Auth, OT.Auth_SE and OT.Payment prevent the attacker from attempting to per- form Apple Pay transactions or Apple Cash transfers, enforcing user authentication with set credentials (which are not known or owned by the attacker according to OE_User), and preventing the attacker from replacing a User’s Passcode or biometrics with their own. OT.User_Auth and OE.Genuine_Wallet additionally ensure that the installation of a new Apple released OS or Apple Wallet a preserves the confidentiality and integrity of the pay- ment data. OT.Passcode_Delete ensures that if passcode login is disabled, the Apple Pay and Biomet- ric authentication are not available anymore. T.RECOVER OT.Bio_Delete ensures that a removed passcode or biometric credential cannot be re- covered. OT.Card_Data, OT.OS_Update and OE.Card_Data ensure that the confidential card data is only stored by the Secure Element which protects them from disclosure. OT.Device_Reset covers the physical erase of the content and settings of the device where the TOE will trigger secure erase all provisioned card data. OE.Card_Delete ensures that the Issuers of provisioned cards are securely removing the deleted cards from the User’s account so that no transaction can further proceed. T.REPLAY OE.Anti_Replay ensures that each Apple Pay transaction or Apple Cash transfer is not re- played. OE.Anti_Replay and OT.Anti_Replay ensures that each Apple Pay transaction or Apple Cash transfer cannot be replayed. T.CORRUPT OT.Payment enforces the dynamic linking of the Apple Pay transaction data, ensuring that the critical content (such as emitter, recipient, amount) cannot be changed after the trans- action was processed using a provisioned card. OE.Dynamic_Linking ensures that the Apple Pay server is verifying the integrity of the Apple Pay transaction data Dynamic Link- ing. OE.Statement provides an additional verification point for the account holder as the Issuer ensures that all processed Apple Pay transactions appear on the statement of the account associated to the card. OT.User_Auth and OE_Genuine_Wallet ensure that the Apple release of a new OS or Apple Wallet implementing the payment functions are controlled. Element Rationale Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 38 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target T.SILENT OT.User_Auth and OT.Payment ensure that an Apple Pay transaction or Apple Cash trans- fer is always authorized by the User. OE.Statement ensures that the Apple Pay card Issuers provide account holder verification material (in the form of transaction statements) allowing them to identify any fraudulent activity on their account. The Apple Cash card Issuer ensures that the ledger associated to an Apple Cash account (list of transfers including completed/canceled/pending) is fully accurate. OT.User_Auth and OE.Genuine_Wallet ensure that the Apple release of a new OS or Apple Wallet implementing the authentication functions and payment functions is controlled. OT.Passcode_Delete ensures that if passcode is turned off, the Apple Pay and Biometric authentication are not available anymore. T.PHYSICAL The User credentials maintained by the TOE are secured by OT.User_Auth enforcing the secure verification process of Biometrics or Passcode. The TOE lifecycle is secure through the management of the device within the Apple iCloud environment where the User is able to remove the device from its account (OT.Card_De- lete) and reset the device’s content (OT.Device_Reset). This binding ensures that the User’s critical data is safe in case device is lost or stolen. OT.Card_Data, OT.OS_Update and OE.Card_Data ensure that the provisioned card data is kept confidential in the Secure Element and cannot be extracted. P.UPDATE OT.User_Auth and OE.Genuine_Wallet ensure that the Apple release of a new OS or Apple Wallet implementing the authentication functions and payment functions are controlled, and that it preserves the confidentiality and integrity of the authentication and payment data. P.DYN_LINK (Dynamic Link- ing) P.DYN_LINK is covered by OT.Payment, OT.User_Auth, OT.Anti_Replay, OE.Anti_Replay, OE.Transaction_Verification, and OE.Dynamic_Linking, which all participate in the en- forcement of the Dynamic Linking requirements on e-Commerce payments. The mapping is as follows: (a) OT.Payment ensures that there is a step, part of the user intent confirmation phase, when the User (payer) is made aware of the amount of the payment transaction and payee. (b) OT.User_Auth ensures that the user authentication was performed to ensure agree- ment by the payer to authorize the Apple Pay transaction data (specific to the payer, amount and payee), OE.Anti_Replay ensures that each payment is uniquely identified, and OT.Payment ensures that the payment data is integrity protected. (c) OE.Anti_Replay, OE.Transaction_Verification and OE.Dynamic_Linking ensure that the received Apple Pay transaction data correspond to what was agreed to by the payer: The unique identifier to prevent replay is verified, the cryptogram for the data is veri- fied, and the dynamic linking of the user authentication and the payment data integrity is verified. (d) OE.Anti_Replay, OE_Transaction_Verification and OE.Dynamic_Linking ensure that any change to the amount or the payee results in the invalidation of the payment and its unique identifier so no replay is attempted. P.WATCH P.WATCH is covered by OT_User_Auth and OT.Watch, which allow the Apple Watch dedic- ated features. Element Rationale Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 39 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Security Objectives mapping table: T. C O R R U P T T. P H Y S I C A L T. R E C O V E R T. R E P L A Y T. S I L E N T T. S K I M M I N G T. U S U R P P. D Y N _ L I N K P. U P D A T E P. W A T C H A. P E R S O A. D E V I C E _ A U T H A. C D C V M A. W A T C H _ U S E R OT.Anti_Replay x x OT.Card_Data x x x OT.Payment x x x x x OT.Card_Delete x OT.OS_Update x x x OT.Auth_SE x x OT.User_Auth x x x x x x x x OT.Watch x OT.Passcode_Delete x OT.Bio_Delete x OT.Device_Reset x x OE_Anti_Replay x x OE.Card_Data x x x OE.Perso x OE.Dynamic_Linking x x OE.Statement x x OE.Transaction_Verification x OE.CDCVM x OE.Watch x x x OE.User x x x x OE.Genuine_Wallet x x x x OE.Card_Delete x Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 40 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.Security Functional Requirements 6.1. SFR supporting definitions 6.1.1.Security Functional Policies (SFP) Access Control SFPs are given in the table below: 6.1.2.Subjects and Objects Objects are the Assets identified in Section 4.1. Subjects are listed in Sections 4.2 and 4.4 Authentication_SFP Authentication policy enforcing authentication, re-authentication and authorization rules as defined by OT.User_Auth. This SFP includes information flows between the Secure Enclave and the biometric sensor (for biometric authentication) and between the TOE and S.Apple_Watch (for device unlock). Payment_SFP Security policy enforcing that processing a payment requires the User to confirm the in- tent to pay and being re-authenticated (Passcode, or, if configured, Biometrics) to allow processing of the related data and its exportation. Card_Perso_SFP Security policy enforcing that: - Importing D.Card_Data is only allowed if a passcode is configured - Confidential parts of the card data are protected before being sent to the Apple Servers - Confidential parts of the card data are not imported in Apple Wallet Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 41 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.1.3.Security Attributes 6.1.4.Writing conventions for the SFR operations Security Attribute Card Data Confidential parts Parts of the Card Data that should stay confidential and not been stored in Apple Wallet - Secret parts of the card number - CVV - … User Authorization Part of D.Payment_Data specify- ing the explicit authorization of the S.User - “yes” - “no” Erase Data Part of D.User_Configuration which, when enabled, erases the data on the device after 10 con- secutive attempts to unlock it us- ing the wrong passcode. - “enabled” - “disabled” (default) BioAuth Unlock Part of D.User_Configuration, au- thorization to use biometric au- thentication for unlocking a device, “selected” or “not selec- ted” by the User. - “selected” - “not selected” (default) BioAuth AP Part of D.User_Configuration, au- thorization to use biometric au- thentication for Apple Pay opera- tions, “selected” or “not selected” by the User. - “selected” (default) - “not selected” Watch Unlock Authorization to use the paired Apple Watch to unlock the TOE if Face ID has detected S.User is wearing a mask - “enabled” - “disabled” (default) Face ID with Mask Part of D.User_Configuration which, when enabled, allows the User to unlock the iPhone while wearing a face mask. - “enabled” - “disabled” (default) Apple OS public key The public key used to check the authenticity of a new version of D.OS. - Part of installed D.OS OS_signature Part of the OS file that is checked by the TOE before updating D.OS - Part of the update file Passcode_off Part of D.SEP_Configuration, con- figuration of the OS allowing to use the device without any au- thentication. When enabled, the TSF should disable biometric au- thentication and Apple Pay. - “disabled” (default) - “enable” Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 42 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Iterations are identified by a slash character “/” followed by the name of the iteration. Assignments and selections are done with italicized text. Refinements are identified with the prefix “Refinement:”. 6.2. Identification and authentication 6.2.1.User authentication FIA_UID.2 User identification before any action FIA_UAU.2 User authentication before any action Note: this gives S.User the role of “Authenticated User”. According to this requirement, S.User is au- thenticated by the TSF before performing any of the operations listed in the following requirements. FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-medi- ated actions on behalf of that user. FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF- mediated actions on behalf of that user. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 43 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target FIA_UAU.5 Multiple authentication mechanisms FIA_AFL.1/Biometric Authentication failure handling FIA_AFL.1/Erase Authentication failure handling FIA_AFL.1/Delay Authentication failure handling FIA_UAU.6 Re-authenticating FIA_UAU.5.1 The TSF shall provide passcode authentication, biometric authentication (face appearance), Watch unlock (paired Apple Watch) to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the: • Passcode authentication as default authentication • Biometric authentication for: - Unlock the device if selected in the “Face ID & Passcode” configuration (BioAuth Un- lock = selected) - Unlock the device if (Face ID with Mask = enabled and Face ID has detected the S.User is wearing a mask) - Transaction authorization if selected in the “Face ID & Passcode” configuration (BioAu- th AP = selected) - Transaction authorization if (Face ID with Mask = enabled and Face ID has detected the S.User is wearing a mask) • Unlock with a paired Apple Watch if (Watch Unlock = enabled and Face ID has detected the S.User is wearing a mask) • Rules defined in FIA_UAU.6 Re-authenticating and FIA_AFL.1 (Biometric/Erase/Delay) Authentication failure handling. FIA_AFL.1.1 /Biometric The TSF shall detect when 5 (five) unsuccessful authentication attempts occur related to Bio- metric validation. FIA_AFL.1.2 /Biometric When the defined number of unsuccessful authentication attempts has been met, the TSF shall require Passcode validation, blocking further Biometric validation attempts. FIA_AFL.1.1 /Erase The TSF shall detect when 10 (ten) unsuccessful authentication attempts occur related to passcode validation. FIA_AFL.1.2 /Erase When the defined number of unsuccessful authentication attempts has been met, the TSF shall erase data on iPhone if “Erase Data” = enable. FIA_AFL.1.1 /Delay The TSF shall detect when 5 (five) unsuccessful authentication attempts occur related to passcode validation. FIA_AFL.1.2 /Delay When the defined number of unsuccessful authentication attempts has been met, the TSF shall start delaying further passcode validation attempts and require passcode validation. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 44 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.2.2.Data Authentication FDP_DAU.1 Basic Data Authentication 6.2.3.User attribute definition FIA_ATD.1 User attribute definition 6.2.4.Specification of secrets FIA_SOS.2 TSF Generation of secrets FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions that the user requests: • OS update (change of D.OS) • “Face ID & Passcode” configuration change (once for all “Face ID & Passcode” para- meters until “Face ID & Passcode” interface is closed), including “BioAuth Unlock”, “BioAuth AP”, “Face ID With a Mask”, passcode and Biometric patterns • Transaction validation (export of D.Transaction_Data), the re-authentication should be done during the 60 seconds after the transaction validation request. FDP_DAU.1.1 The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of D.Payment_Data (including S.Merchant and S.User data). FDP_DAU.1.2 The TSF shall provide S.SE with the ability to verify evidence of the validity of the indicated in- formation. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: D.User_Passcode, D.User_Bio, D.Card_Data, BioAuth Unlock, BioAuth AP, Watch Unlock, Face ID with Mask. Refinement: The update of D.OS shall not modify these user attributes. FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet FIPS 140-2 validated cryptographic module. FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for creation of the D.Unlock- _Secret during the Unlock with Apple Watch Setup. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 45 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.3. Access/Flow Control SFRs 6.3.1.Authentication _SFP FDP_ACC.2/Authentication_SFP Complete access control FDP_ACF.1/Authentication_SFP Security attribute-based access control FDP_ITT.1 Basic internal transfer protection Note: This requirement concerns the protection of biometric data sent by the biometric sensor to the Secure Enclave. Protection against modification includes also protection against replay. FDP_ACC.2.1/ Authentication_SFP The TSF shall enforce the Authentication_SFP on: Subjects: S.User, S.Apple_Watch Objects: the TSF and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2/ Authentication_SFP The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACF.1.1/ Authentication_SFP The TSF shall enforce the Authentication_SFP to objects based on the following: Subjects: S.User, S.Apple_Watch Objects: the TSF Security attributes: “Watch Unlock”, “Face ID with Mask” FDP_ACF.1.2/ Authentication_SFP The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: S.User is authenticated according to FIA_UAU.5 FDP_ACF.1.3/ Authentication_SFP The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: - If “Watch Unlock” set to “enabled” and Face ID has detected S.User is wearing a mask, S.Apple_Watch is allowed to unlock the TOE (however, this does not authorize Apple Pay transactions). - If “Face ID with Mask” set to “enabled” and Face ID has detected S.User is wearing a mask, S.User is allowed to unlock the TOE and authorize Apple Pay transactions. FDP_ACF.1.4/ Authentication_SFP The TSF shall explicitly deny access of subjects to objects based on the following addi- tional rules: “Passcode_off” is enabled. FDP_ITT.1.1 The TSF shall enforce the Authentication_SFP to prevent the modification of user data when it is transmitted between physically-separated parts of the TOE. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 46 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.3.2.Payment_SFP FDP_ETC.2/Transaction Export of user data with security attributes FDP_ACC.2/Payment_SFP Complete access control Note: the only possible operation on D.Payment_Data is to export it as a transaction order to the Secure Element. FDP_ETC.2.1 /Transaction The TSF shall enforce the Payment_SFP when exporting user data, controlled under the SFP(s), outside of the TOE. FDP_ETC.2.2 /Transaction The TSF shall export the user data with the user data's associated security attributes. FDP_ETC.2.3 /Transaction The TSF shall ensure that the security attributes, when exported outside the TOE, are unam- biguously associated with the exported user data. FDP_ETC.2.4 /Transaction The TSF shall enforce the following rules when user data is exported from the TOE: - exported Payment_SFP details (the card to be used from Apple Wallet, the amount and the payee in the case of e-commerce payments) are those displayed to S.User during re-authentication request (FIA_UAU.6 Re-authenticating) - D.Payment_Data includes a unique identifier, which can be either: - A Terminal Unpredictable Number, for near-field-communication (NFC) transactions, or - An Apple Pay server nonce, for transactions within apps or Apple Cash transfers. FDP_ACC.2.1/ Payment_SFP The TSF shall enforce the Payment_SFP on: Subjects: S.User Objects: D.Payment_Data (including S.User and S.Merchant Data) and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2/ Payment_SFP The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 47 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target FDP_ACF.1/Payment_SFP Security attribute based access control 6.3.3.Card_Perso_SFP FDP_ACC.2/Card_Perso_SFP Complete access control FDP_ACF.1/Card_Perso_SFP Security attribute-based access control FDP_ETC.2/Card_Perso_SFP Export of user data with security attributes FDP_ACF.1.1/ Payment_SFP The TSF shall enforce the Payment_SFP to objects based on the following: Subjects: S.User Objects: D.Payment_Data (including S.User and S.Merchant Data), the Secure Element (through a trusted channel) Security attributes: “User Authorization”, “BioAuth AP”, “Passcode_off” FDP_ACF.1.2/ Payment_SFP The TSF shall enforce the following rules to determine if an operation among controlled sub- jects and controlled objects is allowed: - Export of D.Payment_Data with “User Authorization” set to “yes” to the Secure Ele- ment is allowed if: - S.User shows their intent to pay (double clicking the side button) - S.User had been successfully re-authenticated for transaction validation (FIA_UAU.6). FDP_ACF.1.3/ Payment_SFP The TSF shall explicitly authorise access of subjects to objects based on the following addi- tional rules: none. FDP_ACF.1.4/ Payment_SFP The TSF shall explicitly deny access of subjects to objects based on the following additional rules: “Passcode_off” is “enabled”. FDP_ACC.2.1 / Card_Perso_SFP The TSF shall enforce the Card_Perso_SFP on Subjects: S.User, S.Apple_Servers Objects: D.Card_Data and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2 / Card_Perso_SFP The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACF.1.1 / Card_Perso_SFP The TSF shall enforce the Card_Perso_SFP to objects based on the following: Subjects: S.User, S.Apple_Servers Objects: D.Card_Data Security attributes: Passcode_off FDP_ACF.1.2 / Card_Perso_SFP The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: - S.User is connected to its iCloud account, and is authenticated on the TOE. FDP_ACF.1.3 / Card_Perso_SFP The TSF shall explicitly authorise access of subjects to objects based on the following ad- ditional rules: none. FDP_ACF.1.4 / Card_Perso_SFP The TSF shall explicitly deny access of subjects to objects based on the following addition- al rules: “Passcode_off” is enabled. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 48 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target FPT_ITC.1 Inter-TSF confidentiality during transmission FDP_ITC.1/Card_Perso_SFP Import of user data without security attributes Note: security attributes of the Card Data are “Card Data Confidential parts” in section 6.1.3. These requirements specify that the confidential part of the cards data is used for card enrollment (FDP_ETC.2/Card_Perso_SFP) but are not stored on the TOE. FDP_ETC.2.1 /Card_Perso_SFP The TSF shall enforce the Card_Perso_SFP when exporting user data, controlled under the SFP(s), outside of the TOE. FDP_ETC.2.2 /Card_Perso_SFP The TSF shall export the user data with the user data's associated security attributes. FDP_ETC.2.3 /Card_Perso_SFP The TSF shall ensure that the security attributes, when exported outside the TOE, are un- ambiguously associated with the exported user data. FDP_ETC.2.4 /Card_Perso_SFP The TSF shall enforce the following rules when user data is exported from the TOE: - D.Card_Data is encrypted before being exported to S.Apple_Server - “Card Data Confidential parts” are not kept on the TOE after being exported. FPT_ITC.1.1 The TSF shall protect all TSF data transmitted from the TSF to another trusted IT product from unauthorised disclosure during transmission. FDP_ITC.1.1 / Card_Perso_SFP The TSF shall enforce the Card_Perso_SFP when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.1.2 / Card_Perso_SFP The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3 / Card_Perso_SFP The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: None. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 49 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.4. Secure Enclave/Secure Element Trusted Channel FTP_ITC.1/SE Inter-TSF trusted channel FDP_UCT.1/SE Basic data exchange confidentiality FDP_UIT.1/SE Data exchange integrity FPT_RPL.1/SE Replay detection 6.5. Secure Enclave/Apple Watch Trusted Channel FTP_ITC.1/Watch Inter-TSF trusted channel FDP_UCT.1/Watch Basic data exchange confidentiality FTP_ITC.1.1/SE The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or dis- closure. FTP_ITC.1.2/SE The TSF shall permit the TSF to initiate communication via the trusted channel. FTP_ITC.1.3/SE The TSF shall initiate communication via the trusted channel for Payment initiation and transmission of D.Payment_Data. FDP_UCT.1.1/SE The TSF shall enforce the Payment_SFP, to transmit user data in a manner protected from unauthorised disclosure. FDP_UIT.1.1/SE The TSF shall enforce the Payment_SFP, to transmit and receive user data in a manner pro- tected from modification, insertion and replay errors. FDP_UIT.1.2/SE The TSF shall be able to determine on receipt of user data, whether modification, insertion or replay has occurred. FPT_RPL.1.1/SE The TSF shall detect replay for the following entities: S.SE. FPT_RPL.1.2/SE The TSF shall perform reject data when replay is detected. FTP_ITC.1.1 / Watch The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2 / Watch The TSF shall permit the TSF to initiate communication via the trusted channel. FTP_ITC.1.3 / Watch The TSF shall initiate communication via the trusted channel for: unlock the TOE. FDP_UCT.1.1 / Watch The TSF shall enforce the Authentication_SFP, to transmit and receive user data in a manner protected from unauthorised disclosure. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 50 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target FDP_UIT.1/Watch Data exchange integrity FPT_RPL.1/Watch Replay detection 6.6. Local data protection FPR_UNO.1 Unobservability FDP_RIP.1 Subset residual information protection FDP_SDI.1 Stored data integrity monitoring 6.7. TSF management 6.7.1.Roles and Management Functions FDP_UIT.1.1 / Watch The TSF shall enforce the Authentication_SFP to transmit and receive user data in a manner protected from modification, insertion and replay errors. FDP_UIT.1.2 / Watch The TSF shall be able to determine on receipt of user data, whether modification, insertion or replay has occurred. FPT_RPL.1.1/Watch The TSF shall detect replay for the following entities: S.Apple_Watch. FPT_RPL.1.2/Watch The TSF shall perform reject data when replay is detected. FPR_UNO.1.1 The TSF shall ensure that S.Attacker are unable to observe the operation Passcode set, Passcode check, Passcode Update, Passcode removal, Biometrics set, Biometrics check, Bio- metrics update, Biometrics delete, Apple Pay/Cash Card provisioning, Apple Watch Unlock activation, on D.User_Bio, D.User_Passcode, D.Card_Data, D.SEP_Watch, D.Unlock_Secret by S.User. FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects: D.User_Bio, D.User_Passcode, “Card Data Confidential parts” and iCloud Account (in D.User_Configuration). Refinement: • The removal of the iCloud Account by S.User triggers the deallocation of all the Apple Pay data/config- uration • The revocation of individual card by its issuer triggers the deallocation of the related card data • The procedure of Reset on the device triggers the deallocation of all security attributes except the D.OS • The removal of “Card Data Confidential parts” is done by instructing the Secure Element to mark the card as deleted • The removal of the Passcode by S.User disables the actual Passcode; and triggers the deallocation of the iCloud Account information and all the Apple Pay data FDP_SDI.1.1 The TSF shall monitor user data stored in containers controlled by the TSF for integrity errors on all objects, based on the following attributes: D.User_Bio, D.Card_Data, D.OS. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 51 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_SMR.1.1 The TSF shall maintain the roles Authenticated User. FMT_SMR.1.2 The TSF shall be able to associate users with roles. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: management of security attributes (see FMT_MSA.1). Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 52 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.7.2.Management of security attributes FMT_MSA.3 Static attribute initialization FMT_MSA.1 Management of security attributes 6.7.3.Management of TSF_Data FMT_MTD.1 Management of TSF data FMT_MTD.3 Secure TSF data 6.8. Security Requirements Rationale 6.8.1.Security Functional Requirements (SFR) Dependencies FMT_MSA.3.1 The TSF shall enforce the Payment_SFP, Card_Perso_SFP to provide “BioAuth Unlock” restrictive (disabled) “BioAuth AP” permissive (selected) “Passcode_off” restrictive (disabled) “Watch Unlock”restrictive (disabled) “Face ID with Mask” restrictive (disabled) “Erase Data” permissive (disabled) default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow nobody to specify alternative initial values to override the default values when an object or information is created. FMT_MSA.1.1 The TSF shall enforce the Authentication_SFP, Card_Perso_SFP to restrict the ability to modify the security attributes “, “BioAuth Unlock”, “BioAuth AP”, “Passcode_off”, “Erase Data”, “Watch Unlock”, “Face ID with Mask” to “Authenticated User” Refinement: • When “Passcode_off” is enabled, the TSF removes the D.Card_Data according to FDP_RIP.1. FMT_MTD.1.1 The TSF shall restrict the ability to update the D.OS to “Authenticated user”. FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for D.OS. Refinement: secure value is defined by “OS_signature” is valid and signed by “Apple OS public key”. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 53 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target TOE SFR Required dependencies Covered by FIA_UAU.2 FIA_UID.1 FIA_UID.2 FIA_AFL.1 (Biometric/Erase/ Delay) FIA_UAU.1 FIA_UAU.2 FDP_ACC.2/Authentication_SFP FDP_ACF.1 FDP_ACF.1/Authentication_SFP FDP_ACF.1/Authentication_SFP FDP_ACC.1 FMT_MSA.3 FDP_ACC.2/Authentication_SFP FMT_MSA.3 FDP_ACC.2/Payment_SFP FDP_ACF.1 FDP_ACF.1/Payment_SFP FDP_ACF.1/Payment_SFP FDP_ACC.1 FMT_MSA.3 FDP_ACC.2/Payment_SFP FMT_MSA.3 FDP_ITT.1 FDP_ACC.1, or FDP_IFC.1 FDP_ACC.2/Authentication_SFP FDP_ETC.2/Transaction FDP_ACC.1, or FDP_IFC.1 FDP_ACC.2/Payment_SFP FDP_ACC.2/Card_Perso_SFP FDP_ACF.1 FDP_ACF.1/Card_Perso_SFP FDP_ACF.1/Card_Perso_SFP FDP_ACC.1 FMT_MSA.3 FDP_ACC.2/Card_Perso_SFP FMT_MSA.3 FDP_ITC.1/Card_Perso_SFP FDP_ACC.1, or FDP_IFC.1 FMT_MSA.3 FDP_ACC.2/Card_Perso_SFP FMT_MSA.3 FDP_ETC.2/Card_Perso_SFP FDP_ACC.1, or FDP_IFC.1 FDP_ACC.2/Card_Perso_SFP FDP_UCT.1/SE FDP_ACC.1, or FDP_IFC.1 FTP_ITC.1, or FTP_TRP.1 FDP_ACF.1/Payment_SFP, and FD- P_ACF.1/Card_Perso_SFP FTP_ITC.1/SE FDP_UIT.1/SE FDP_ACC.1, or FDP_IFC.1 FTP_ITC.1, or FTP_TRP.1 FDP_ACF.1/Payment_SFP, and FD- P_ACF.1/Card_Perso_SFP FTP_ITC.1/SE FDP_UCT.1/Watch FDP_ACC.1, or FDP_IFC.1 FTP_ITC.1, or FTP_TRP.1 FDP_ACF.1/Authentication_SFP FTP_ITC.1/Watch FDP_UIT.1/Watch FDP_ACC.1, or FDP_IFC.1 FTP_ITC.1, or FTP_TRP.1 FDP_ACF.1/Authentication_SFP FTP_ITC.1/Watch FMT_SMR.1 FIA_UID.1 FIA_UID.2 FMT_MSA.3 FMT_MSA.1, FMT_SMR.1 FMT_MSA.1, FMT_SMR.1 FMT_MSA.1 FDP_ACC.1, or FDP_IFC.1 FMT_SMR.1, SMT_SMF.1 FDP_ACC.2/Authentication_SFP, FD- P_ACC.2/Authentication_SFP, and FDP_ACC.2/Card_Perso_SFP FMT_SMR.1, FMT_SMF.1 FMT_MTD.1 FMT_SMR.1, SMT_SMF.1 FMT_SMR.1, SMT_SMF.1 FMT_MTD.3 FMT_MTD.1 FMT_MTD.1 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 54 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Requirements without dependency: FIA_UID.2, FIA_SOS.2, FIA_UAU.6, FIA_UAU.5, FDP_DAU.1, FIA_ATD.1, FPT_ITC.1, FTP_ITC.1/SE, FPT_RPL.1/SE, FTP_ITC.1/Watch, FPT_RPL.1/Watch, FPR_UNO.1, FDP_RIP.1, FMT_SMF.1 and FDP_SDI.1 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 55 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.8.2.Rationale SFR/Security Objectives for the TOE Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 56 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Objective refer- ence Rationale OT.User_Auth FIA_UID.2 and FIA_UAU.2 enforce each User of the device is authenticated before being able to do any action in the user interface. FIA_UAU.5 specifies different authentication methods. FIA_UAU.6 enforces a re-authentication for the OS update, for changing the authentica- tion configuration, including biometric data management and biometric authentication policy or for a transaction validation. FMT_SMR.1 and FMT_SMF.1 SF ensure that the TSF shall maintain the roles Authentic- ated User and be capable of performing the management functions. FIA_ATD.1, FMT_MSA.3, FMT_MSA.1 and FMT_MTD.1 specify the management of related information. FMT_MTD.3 specifies the signature verification on the OS update. FIA_AFL.1 (Biometric/Erase/Delay) specify the failure handling in case of wrong biometric or passcode authentication. FPR_UNO.1 ensures the non-observability of the passcode. FDP_ITT.1 also support this objective ensuring the biometric data is not modified during internal transfer. OT.Card_Data The SFP Card_Perso_SFP and the associated SFRs (FDP_ACC.2/Card_Perso_SFP, FD- P_ACF.1/Card_Perso_SFP, FDP_ITC.1/Card_Perso_SFP and FDP_ETC.2/Card_Perso_SFP, FPT_ITC.1) enforce card data stored in Apple Wallet does not include sensitive card data as this one is only sent to the Secure Element. FTP_ITC.1/SE, FDP_UCT.1/SE and FDP_UIT.1/SE enforce that all the data exchanged between the TSF and S.SE is protected (with their corresponding security property) by a trusted channel. FPR_UNO.1 ensures the non-observability of secret card data. FDP_SDI.1 ensures card data stored in containers controlled by the TSF are monitored for integrity errors. OT.Passcode_De- lete FDP_ACC.2/Card_Perso_SFP and FDP_ACF.1.4/Card_Perso_SFP enforce the card en- rollment is not possible if Passcode_off is enabled. FIA_UAU.6 enforces a re-authentication for changing the Passcode_off configuration. FPR_UNO.1 ensures the non-observability of the passcode. OT.Card_Delete FDP_RIP.1 ensures the confidential parts of the card data are securely removed by the Secure Element. Refinement of FMT_MSA.1.1 ensures the secure delete in case of passcode turning off. FPR_UNO.1 ensures the non-observability of sensitive card data. OT.Auth_SE FIA_UID.2, FIA_UAU.2, FIA_UAU.5 specify the base of the authentication feature. FIA_AFL.1/Biometric enhance the biometric security limiting the authentication attempts before requiring passcode authentication. Other FIA_AFL.1 protect the TSF and the user data against brute force attacks. FIA_UAU.6 specifies the re-authentication for some functions of the TOE. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 57 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 6.8.3.SAR Dependencies OT.Payment FDP_ETC.2.4/Transaction ensures the transaction details are displayed before a transac- tion is validated by the User. FIA_UAU.6 ensures each transaction is validated by a re-authentication. FDP_DAU.1 provides evidences of the validity of Apple Pay Transaction Data, verifiable by the Issuer. FDP_ACC.2/Payment_SFP and FDP_ACF.2/Payment_SFP ensure user authorization is done before each transaction. FPT_RPL.1/SE ensures transaction replay detection. OT.Bio_Delete FDP_RIP.1 ensures biometric data delete is a secure erase. OT.Device_Reset FDP_RIP.1 ensures all sensitive data is securely removed during a device reset OT.Anti_Replay FDP_ETC.2.4/Transaction ensures a unique identifier provided by the NFC terminal or Apple server is included in the transaction data, avoiding any replay attack. OT.OS_Update FIA_UAU.6.1 ensures S.User is re-authenticated before the OS update proceeds. The refinement of FIA_ATD.1.1 ensures that all the user data with impact on the TSF be- havior are not modified during the OS update process. FDP_SDI.1 ensures D.OS stored in containers controlled by the TSF is monitored for in- tegrity errors. OT.Watch FTP_ITC.1/Watch, FDP_UCT.1/Watch, FDP_UIT.1/Watch, FIA_SOS.2, FPR_UNO.1 and FPT_RPL.1/Watch enforce that all the data exchanged between the TSF and S.Ap- ple_Watch is protected by a trusted channel regarding the confidentiality and the integ- rity. The protected operations are specified by FDP_ACC.2/Authentication_SFP and FD- P_ACF.1/Authentication_SFP. Objective refer- ence Rationale Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 58 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target All the dependencies are covered. 6.8.4. SAR Rationale For this evaluation, the SARs of EAL2 have been chosen as they provide assurance by a full security target and an analysis of the SFRs in that ST, using a functional and interface specification, guidance documentation and a basic description of the architecture of the TOE, to understand the security be- havior. It was established that this level is appropriate for the model of attack of Apple Pay. ADV_FSP.3 augmentation has been chosen to enhance the level of information provided related to SFR-enforcing TSFIs and provide a complete summary of the TOE. ALC_FLR.3 augmentation has been chosen to guarantee the security of the security functions in the scope of this security target during the maintenance of the TOE. TOE SAR Dependencies ADV_ARC.1 ADV_FSP.1, ADV_TDS.1 ADV_FSP.3 ADV_TDS.1 ADV_TDS.1 ADV_FSP.2 AGD_OPE.1 ADV_FSP.1 AGD_PRE.1 No dependencies ALC_CMC.2 ALC_CMS.1 ALC_CMS.2 No dependencies ALC_DEL.1 No dependencies ALC_FLR.3 No dependencies ASE_CCL.1 ASE_INT.1, ASE_ECD.1, ASE_REQ.1 ASE_ECD.1 No dependencies ASE_INT.1 No dependencies ASE_OBJ.2 ASE_SPD.1 ASE_REQ.2 ASE_OBJ.2, ASE_ECD.1 ASE_SPD.1 No dependencies ASE_TSS.1 ASE_INT.1, ASE_REQ.1, ADV_FSP.1 ATE_COV.1 ADV_FSP.2, ATE_FUN.1 ATE_FUN.1 ATE_COV.1 ATE_IND.2 ADV_FSP.2, AGD_OPE.1, AGD_PRE.1, ATE_COV.1, ATE_FUN.1 AVA_VAN.2 ADV_ARC.1, ADV_FSP.2, ADV_TDS.1, AGD_OPE.1, AGD_PRE.1 Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 59 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 7. TOE Summary Specification This section describes the security functions of the TOE covering the SFR of the previous chapter. 7.1. SF User authentication and management When using the TOE, before being able to use Face ID as a Biometric authentication method, the device must be set up so that a passcode is required to unlock it. Face ID is Apple’s face authentication system that enables the secure access to an iPhone equipped with the Face ID sensor (TrueDepth camera). This technology is based on the Face ID sensor and the Secure Enclave. When the Secure Enclave detects a successful match, the device unlocks without asking for the device passcode. Face ID does not replace the passcode but provides easy access to the device within de- fined boundaries and time constraints. To use Face ID, the device must be set up so that a passcode is required to unlock it. The passcode can always be used instead of Biometrics, and the passcode is required under the fol- lowing circumstances: • The device has just been turned on or restarted • The User has not unlocked their device for more than 48 hours • The User has not used their passcode to unlock their device for 156 hours (six and a half days) and the User has not used a biometric to unlock their device in 4 hours • The device has received a remote lock command • The User exited power off/Emergency SOS by pressing and holding either volume button and the Sleep/Wake button simultaneously for 2 seconds and then pressing Cancel • There were five unsuccessful biometric match attempts (though for usability, the device might offer entering a passcode instead of using biometrics after a smaller number of failures) From iOS 15.4, when “Face ID with a Mask” is enabled on an iPhone, it’s available for the next 6.5 hours after one of the following user actions: • Successful Face ID match attempt (with or without a mask) • Device passcode validation • Device unlock with Apple Watch These features implement the requirements listed in §6.2 and in §6.3.1 for the authentication, in §6.6 for local data protection and in FMT_SMF.1 and FMT_MSA.1 for management. Unlock with a paired Apple Watch is also possible if Face ID has detected the User is wearing a mask (see requirements in §6.5 for secure communication with Apple Watch). However, this method does not grant equivalent privileges for Apple Pay/Apple Cash or any administration feature. The following table summarizes the functions supporting User authentication. Function Description Passcode authentication Passcode_Setup: Setup of the device’s Passcode. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 60 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 7.1.1.Passcode_Setup The TOE offers a configuration setting where the User can set up a Passcode that will be used to per- form authentication in order to access restricted services on the device: first unlock after power-on or reboot, Apple Pay transactions, Apple Pay Transfers, and more. The TOE enforces strong access control in order to prevent access to these restricted services without authentication (FIA_UID.2). Note: The User has the possibility to use Passcode or any other activated (with enrolled templates) authentication method to perform unlock (beyond first unlock), Apple Pay transactions and Apple Cash transfers. The TOE ensures the non-observability of the Passcode during the setting process within the Secure Enclave (FPR_UNO.1). 7.1.2.Passcode_Verify The TOE offers Passcode entry to the User as part of the device unlock procedure, or during the User authorization step of an Apple Pay transaction or Apple Cash transfer. The User might have selected the default method as being Biometrics, but Passcode verification is always possible (as a fallback or by User choice). The TSFs ensure that Passcode verification preserves the secrecy of the Passcode value set by the User, which is expected in order to prevent an attacker from guessing the code by ob- serving the verification process (FPR_UNO.1). The TOE ensures that the verification process would not validate a code that does not match the Passcode set by the User and detect alterations to the config- ured value (FDP_SDI.1), preventing use of the User account (and related data) and forcing a device panic. To discourage brute-force passcode attacks, the TOE authentication failure policy is escalating time delays after the entry of an invalid passcode (FIA_AFL.1/Delay) or to erase data after 10 attempts if the feature #Erase data " is enabled (FIA_AFL.1/Erase). 7.1.3.Passcode_Update The User can update the Passcode value through the devices settings menu. This functions as a verify operation, as knowledge of the previous Passcode value is required to proceed to the setup step where the User types a new value and effectively updates the value in the Secure Enclave (FIA_UAU.2, FD- Passcode_Update: Update of the device’s Passcode. Passcode_Verify: Authentication of the User using Passcode. Passcode_Delete: Removal of the Passcode Biometric authentication Bio_Enroll: Enrollment of biometrics credential (first, or additional). Bio_Update: Update of Biometrics. Bio_Verify: Authentication of the User using Biometrics. Bio_Delete: Delete an enrolled Biometrics credential (one, or all). Unlock with Apple Watch Unlock_With_Watch_Setup: Enable the feature # Unlock with Apple Watch ". Unlock_With_Watch_Check: Secure process to import the Unlock Secret to the TOE’s Secure Enclave for unlocking the device. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 61 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target P_ACC.2/Authentication_SFP and FDP_ACF.1/Authentication_SFP). The TOE ensures the non-observ- ability of the old Passcode during the verification as well as of the new Passcode during the setting process (FPR_UNO.1). The TOE also enforces Passcode alteration detection, preventing a corrupted Passcode from being used to reset the authentication function (FDP_SDI.1). 7.1.4.Passcode_Delete If the User wants to fully remove the use of the Passcode on the device, because this would not allow an adequate security level for the processing of the TSF, the actual Passcode is disabled; and the iCloud Account information and all the Apple Pay data is deallocated. (FDP_RIP.1). To prevent misuse of the Passcode deletion function, the User is required to first verify the current Passcode before pro- ceeding (FIA_UAU.2, FDP_ACC.2/Authentication_SFP and FDP_ACF.1/Authentication_SFP), and the TOE protects the Passcode secrecy during the verification process in case an attacker were to use this path for attempting an observation-based attack (FPR_UNO.1). The Secure Element, in the TOE Environment, is responsible for securely deleting the Apple Pay card data and Apple Cash card data during this process. 7.1.5.Bio_Enroll The TOE offers Biometric authentication through the Face ID service. To use Face ID, the User must set up the device so that a passcode is required to unlock it, and Passcode verification is required to be able to perform any modifications to the Biometrics setting. Access to the face enrollment and the set- ting for enabling Biometrics for Apple Pay (and Apple Cash), is gated by this Passcode verification (FI- A_UAU.2, FDP_ACC.2/Authentication_SFP and FDP_ACF.1/Authentication_SFP). A User can enroll an alternate appearance for Face ID, for a total of two enrollments. From iOS 15.4, when “Face ID with a Mask” is enabled on an iPhone. If the user wears glasses, they can improve the accuracy of “Face ID with a Mask” by setting it up with their glasses on. 7.1.6.Bio_Update Once a face is enrolled on a device, the User can update it within the settings of the Face ID feature, for which access is gated by the Passcode (FIA_UAU.2, FDP_ACC.2/ Authentication_SFP and FDP_ACF.1/ Authentication_SFP). After a successful Passcode verification, the User can reset Face ID, deleting the associated templates (first face enrolled and alternate face enrolled if used), and re-enroll their face later. This procedure is effectively enforcing the same security principles as a deletion (Bio_Delete), and an enrollment (Bio_Enroll): the Secure Enclave ensures that Biometric data integrity is preserved and the deallocation prevents attackers from finding any residual information (FPR_UNO.1, FDP_SDI.1, and FDP_RIP.1). 7.1.7.SF.Bio_Verify After the device is reset and Passcode is entered to allow the device’s normal mode of operation, the Biometric authentication function is offered to the User as the default means for authentication, if it is enabled, for device unlock, Apple Pay transactions, and Apple Cash transfers. The User will present their biometric features to the device’s biometric sensor, and the Secure Enclave will securely perform the verification of the submitted template to the enrolled biometric template(s). The Secure Enclave ensures the integrity monitoring of the biometric templates during the verification process (FDP_SDI.1). In case of verification failure, which means the TOE was not able to find a successful match, an authen- Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 62 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target tication failure policy is enforced and Passcode verification is required before the Biometric authentica- tion function is enabled again (FIA_AFL.1/Biometric). 7.1.8.Bio_Delete The User has the capability to delete all enrolled Biometrics from the Face ID settings on the device us- ing the Reset Face ID option. This function deletes the associated template of the first face enrolled and, if used, of other faces enrolled. This function, like the others, is gated by the Passcode (FIA_UAU.2, FDP_ACC.2/ Authentication_SFP and FDP_ACF.1/ Authentication SFP). The deletion process ensures that no residual information of the deallocated data is left behind or leaked to a poten- tial observer (FDP_RIP.1, and FPR_UNO.1). 7.1.9.Unlock_With_Watch_Setup Optionally, the User can decide to enable a feature called “Unlock with Apple Watch”: the iPhone can be unlocked by the Watch if the User attempts to unlock their iPhone using Face ID while wearing a mask. Enabling this feature requires the User to enter the Passcode on the iPhone (FDP_ACC.2/Authen- tication_SFP, FDP_ACF.1/ Authentication _SFP and FMT_MSA.1) before the setup process is started. During this process, the TOE Secure Enclave creates a non-predictable Unlock Secret (FIA_SOS.2 and FPR_UNO.1). The TOE’s Secure Enclave securely exports the Unlock Secret to the paired Watch’s Secure Enclave applying security measures to the sensitive asset with Secure Enclave Watch Pairing Secret (FTP_ITC.1/ Watch, FDP_UCT.1/Watch, FDP_UIT.1/Watch, FPT_RPL.1). Until the feature is disabled, the TOE maintains the security attributes and assets of the Unlock with Apple Watch process, including the Unlock Secret (FIA_ATD.1). 7.1.10.Unlock_With_Watch_Check Optionally, if the User enabled the feature called “Unlock with Apple Watch”, the iPhone can be un- locked by the Watch if the User attempts to unlock their iPhone using Face ID while wearing a mask. During this process, the paired Watch’s Secure Enclave securely imports the Unlock Secret to the TOE’s Secure Enclave, applying security measures to the sensitive asset with Secure Enclave Watch Pairing Secret (FTP_ITC.1/Watch, FDP_UCT.1/Watch, FDP_UIT.1/Watch, FPT_RPL.1). 7.2. SF Biometric/Secure Enclave secure channel The TSF protects the data exchanged between the biometric sensor and the Secure Enclave against modification (FDP_ITT.1) 7.3. SF Secure Enclave/Secure Element secure channel The TSF is able to initialize a secure channel with the Secure Element (FTP_ITC.1/SE). This secure channel protects the exchanged data with its corresponding security property: against disclosure (FD- P_UCT.1/SE), modification (FDP_UIT.1/SE) and replay (FPT_RPL.1/SE). Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 63 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 7.4. SF Secure Enclave/Watch secure channel The TSF is able to initialize a secure channel to S.Watch (FTP_ITC.1/Watch). This secure channel pro- tects the exchanged data against disclosure (FDP_UCT.1/Watch), modification (FDP_UIT.1/Watch) and replay (FPT_RPL.1/Watch). 7.5. SF Card Data management The following table summarizes the functions supporting Card Data management. 7.5.1.AP_Card_Provisioning On the TOE, there are different ways to add a card into Apple Wallet: • Adding a card manually • Adding cards on file from an iTunes Store account to Apple Pay • Adding cards from a card issuer’s app • Adding cards from a card issuer’s website (only for Apple Pay, not available for Apple Cash) The first three modes are only available to an authenticated User on the device, with the passcode en- abled (FIA_UAU.2, FDP_ACC.2/Card_Perso_SFP, and FDP_ACF.1/Card_Perso_SFP). When a User adds a card to Apple Wallet, the TSF encrypts card data (FPT_ITC.1) and sends it to Apple servers (FDP_ETC.2/Card_Perso_SFP). Full card numbers are not stored on the device (FDP_ITC.1/ Card_Perso_SFP) or on Apple servers. Integrity protections are in place to prevent alteration of the enrolled Apple Pay card data (FDP_SDI.1). 7.5.2.AP_Cancellation When the User decides to remove an Apple Pay card from Apple Wallet, the TSF order the Secure Ele- ment to securely invalidate and remove the Device Account Number (FDP_RIP.1). Function Description Apple Pay card data management AP_Card_Provisioning: Provisioning of a new card for Apple Pay. AP_Cancellation: User removes a card from Apple Wallet. AP_Revocation: Issuer initiated suspend/unlink of a payment card in Apple Wallet. Apple Cash card data management APC_Enroll: Enroll in Apple Cash services. APC_Disenroll: User cancels their enrollment in Apple Cash services. APC_Revocation: Issuer initiated suspend/unlink of user’s Apple Cash services. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 64 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target 7.5.3.AP_Revocation When the Issuer decides to suspend or unlink an Apple Pay card from Apple Wallet of a TOE User, the TSF order the Secure Element to securely invalidate and remove the Device Account Number (FDP_RIP.1). 7.5.4.APC_Card_Enroll To use person-to-person payments and Apple Cash, a User must be signed into their iCloud account on an Apple Cash compatible device. The User can add the Apple Cash card from Wallet or Settings. This capability is only available to an authenticated User on a device with Passcode enabled. Full card numbers are not stored on the device (FDP_ITC.1/Card_Perso_SFP) or on Apple servers. Integrity protections are in place in the TOE to pre- vent alteration of the enrolled Apple Cash card data (FDP_SDI.1) 7.5.5.APC_Disenroll When the User decides to remove an Apple Cash card from Apple Wallet, the TSF order the Secure Element to securely invalidate and remove the Device Account Number (FDP_RIP.1). 7.5.6.APC_Revocation When the Issuer decides to suspend or unlink an Apple Cash card from Apple Wallet of a TOE User, the TSF order the Secure Element to securely invalidate and remove the Device Account Number (FDP_RIP.1). 7.6. SF Payment management When a device initiates an Apple Pay transaction, the Secure Element, in the TOE Environment, only al- lows a payment to be made after it receives authorization from the Secure Enclave. This involves con- firming the User has provided intent and has authenticated with Biometric authentication, or using the device passcode (FDP_ACC.2/Payment_SFP, FDP_ACF.1/Payment_SFP, and FMT_SMR.1). Biometric authentication is the default method if available, but the passcode can be used at any time. A passcode is automatically offered after three unsuccessful attempts to match biometrics; after five unsuccessful attempts, the passcode is required. A passcode is also required when biometric authentication is not configured or not enabled for Apple Pay (FMT_SMF.1, FMT_MSA.1). Apple Pay includes an anti-replay mechanism that prevents transactions to be repeated by including in D.Payment_Data: • A Terminal Unpredictable Number, for near-field-communication (NFC) transactions, or • An Apple Pay server nonce, for transactions within apps or on the web. The processing of the Apple Pay transaction happens in the TOE Environment, on the Secure Element, using the secret card data, the Transaction Token and producing a payment cryptogram. The TOE en- sures that the payment evidence transmitted back to the Issuer for processing (through a Terminal or network) was authorized by the User (FIA_UAU.6 Re-authenticating). In the case of Apple Pay online transactions, which are processed through the Apple Pay server, this integrity protection ensures the Dynamic Linking of the transaction data by a cryptographic based Authentication Code as exposed in the PSD2 regulation. The Apple Pay server ensures the integrity of the Dynamic Linking, and the Issuer Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 65 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target verifies that it corresponds to a valid transaction, containing the right Transaction Token and produced by a genuine Apple Pay card (FDP_DAU.1). The exported user data (transaction data displayed to S.User) is controlled by FDP_ETC.2/Transaction. The Secure Element, in the TOE Environment, is responsible for ensuring the confidentiality of the Apple Pay Card data during the transaction processing. The following table summarizes the functions supporting Payment management. 7.7. SF OS Update An OS update can be offered at any time by Apple to the User. The User is required to authenticate through a Passcode verification, or the update cannot be installed (FIA_UAU.6, FIA_UAU.2, FMT_MTD.3). The OS update preserves the user attributes, especially the card data, the passcode, the enrolled bio- metric patterns, and other authentication parameters (FIA_ATD.1). The ability to update the D.OS is restricted to Authenticated User (FMT_MTD.1). 7.8. SF iCloud logout & Device reset An iCloud logout is performed when the User unlinks a device from an iCloud account. When this hap- pens, the TOE ensures that the iCloud Account related data is securely deallocated, and that no resid- ual information is left behind (FDP_RIP.1). The most destructive security function available to the User on an iOS device is the device reset, as it erases of all the User data. When this is performed, the TOE ensures that all the sensitive data de- allocated as part of a Device Reset is protected from leaving residual information. This covers the iCloud Account information, all the Apple Pay Card Data, and the User authentication data like pass- code and Biometrics (FDP_RIP.1). TSF Description AP_Transaction Processing of an Apple Pay transaction. APC_Transaction Processing of an Apple Cash peer-to-peer transfer. Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 66 Strong Customer Authentication for Apple Pay on iPhone 13 with A15 Bionic running iOS 15.4.1 Security Target Change History Date Version Author Comments 2022-02-18 1.0 Apple Initialization of the Security Target 2022-05-30 1.1 Apple Minor updates 2022-09-20 1.2 Apple Minor fix 2022-09-26 1.3 Apple Minor updates 2022-11-11 1.4 Apple Minor updates Copyright © 2022 Apple Inc. All rights reserved. This document may be reproduced and distributed only in its original entirety without revision. Page 67