PCI Watch

Tracking changes across the Payment Card Industry

EMV® Mobile Payment: Consumer Device Cardholder Verification Method Security Requirements

v1.0
Mobile NFC Consumer Device

EMV<sup>®</sup> Mobile Payment Consumer Device Cardholder Verification Method Security Requirements Version 1.0 September 2018

Requirements v1.0 Legal Notice

/ 37 The EMV<sup>®</sup> Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV<sup>®</sup> Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV<sup>®</sup> Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV<sup>®</sup> Specifications.

Requirements v1.0 Revision Log – Version 1.0 Date September 2018 Version 1.0

Description

Initial release of the security requirements.

/ 37

Requirements v1.0

Revision Log – Version 1.0. 1. 1. 1. 1. 1.5. 1.5. 1. 2. 2.1.1 2.1.2 2.1. 2. 2. 2. 3. 3. 3. 3.3. 3.3. 3. 3.4.1 3.4.2 3.4. 3.

Requirements v1.0

/ 37 3. 3.6.1 3.6.2 3.6.3 3.6. 3. 3. 3. 3.9. 3. 4. 4. 4. 4. 4. 4. 4. 4.

Requirements v1.0

/ 37 Tables Table 1.1: Table 1.2: Table 1.3: Table 3.1: Table 3.2: Table 3.3: Table 3.4: Table 3. Attacks on CDCVM (Ref. Figure 3.1) Requirements v1.0

/ 37 Figures Figure 2. Figure 3.

Requirements v1.0

/ 37 Requirements 4. 4. 4. 4. 4. 4. 4. 4.

Requirements v1.0

/ 37 1

Scope

This document describes the EMVCo security requirements for a CDCVM Solution.

1.1 Audience This document is intended for:

  • Product, component, and solution providers – To enable them to gain security certification of their CDCVM product components and/or solutions.
  • Laboratories – To give them a better understanding of the process followed by product providers, and to provide them with details on their role in the security evaluation process.
  • Issuers – To provide them with valuable, practical information relating to the general security performance characteristics and the ‘suitability of use’ of CDCVM Solutions.

1.2 Overview This document includes the following chapters: Chapter 1 – Scope provides an introduction to the document, including terminology and references to related information. Chapter 2 – Overview provides a high-level description of CDCVM. Chapter 3 – Security Model for Shared CDCVM provides a description of components that may participate in a CDCVM Solution. Chapter 4 – Security Requirements provides the requirements for a secured CDCVM implementation.

Requirements v1.0

/ 37 1.3

References

Throughout this document, the following references have been used. These references include the most current versions at the time of this document’s writing. For future use, the most current versions should be referenced. Reference [SBMP Rqmts] [Lab Rqmts] [SBMP Process] [Pmt Card Mgmt] Table 1.1: References Document Title EMVCo Software-Based Mobile Payment Security Requirements EMVCo Security Evaluation Laboratory Requirements for SBMP EMVCo SBMP Security Evaluation Process Payment Card Management Whitepaper Version 1.1 – Sep 2018 1.0 – Jan 2018 1.1 – Feb 2018 1.0 – May 2017 1.4

Definitions

The following terms are used in this document: Table 1.2: Definitions Term Application Program Interface (API) Description A set of routines, protocols, and tools for building software applications. Attestation Verifying the integrity of a configuration of software and hardware components. Attestation System The set of components of the SBMP System that performs Mobile Application attestation. Authentication The presentation of credentials as proof that the User is who (s)he claims to be. Authenticator API A set of routines, protocols, and tools used by a Relying Application to facilitate consumer authentication. Biometric Reference One or more stored biometric samples, templates, or models used for biometric comparison.

Requirements v1.0

/ 37 Term Biometric Template Description A biometric reference that is stored by the CDCVM system as a result of the enrolment process and used as a reference in the matching process. Cardholder Verification Method (CVM) The method used to check that the valid cardholder is using the card. Examples of CVM include signature, online PIN, and offline PIN. CDCVM Processing Environment The abstraction of firmware and components required to support a secure Cardholder Verification process from capturing the data to determining the Cardholder Authentication Result. CDCVM Solution The CDCVM Processing Environments together with the Authenticator API and its secure storage that provide shared CDCVM on the consumer device. Consumer The user of the consumer device. Consumer Device The device, typically a mobile phone or a tablet, which hosts the Mobile Application used for payment by the consumer. Consumer Device Cardholder Verification Method (CDCVM) A form of consumer authentication performed on a Consumer Device. Verification of the CDCVM serves to verify whether the person presenting the Consumer Device is a legitimate user of the device. Examples of CDCVM include numeric passcode, a pattern (e.g. used for Android device unlock), or a biometric authentication (e.g. fingerprint, iris, facial). Device Attestation A mechanism that allows a Consumer Device to present evidence to the requesting party about the integrity of its security model. Enrolment The registration of a reference for a specific CDCVM; when subsequent authentication is done, the captured credentials are compared against this reference. Mobile Application A software-based application that may be downloaded from an application store or may come pre-loaded in the Consumer Device. In the context of mobile payment and in its most complex form, it may store several sets of Card Credentials linked to various Issuers and Payment Systems, and enables the Consumer to manage and transact with them. For example, a Payment Card Manager as described in [Pmt Card Mgmt].

Requirements v1.0

/ 37 Term Obfuscation Description Hiding information about program state, execution flow, and data streams to make it hard to understand the meaning and functionality. Includes obfuscation of:

  • Data
  • Key(s)
  • Code / program The objective of obfuscated code is to conceal its purpose (security through obscurity), its logic, or implicit values embedded in it, in order to prevent tampering, deter reverse engineering, or even as a puzzle or recreational challenge for someone reading the source code. Open Web Application Security Project (OWASP) A worldwide not-for-profit charitable organization focused on improving the security of software. http://www.owasp.org Oracle Unlimited interaction with a system to extract hidden data. Payment System An entity that has a commercial relationship with the Issuer and with the Acquirer. The Payment System specifies the payment related Card Credentials and the behaviour of Mobile Application(s). Persistent Authentication The CDCVM Processing Environment continuously authenticates the Consumer (e.g. through measuring the heartbeat). Prolonged Authentication The result of an Authentication remains valid for a period of time after its occurrence, and during this period no further authentication is requested or required in order for the Consumer to perform a payment transaction. Relying Application A Mobile Application on the device that requires knowledge of consumer authentication. Rich Execution Environment (REE) The Rich Execution Environment, also called Normal World (as opposed to the Secure World) is the non-secure operating system running alongside the TEE. It consists in the non-secure kernel and the user applications. Requirements v1.0 / 37 Term Rooting Description The process by which a Consumer Device user attains privileged control or root access to run privileged commands. Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices. Trusted Application (TA) Authorized software that can be securely executed inside the Trusted Execution Environment (TEE) and that exports results of security related functionality to Mobile Applications outside of the TEE. Trusted Execution Environment (TEE) A secure area of a main processor – also called Secure World – which provides security features such as an isolated execution environment for Trusted Applications. It protects security assets from general software attacks, defines safeguards as to data and functions that an application can access, and resists a set of defined threats. Verification Caching The caching of information related to a verification state e.g. how long a verification result is valid for. Requirements v1.0 / 37 1.5 Notational Conventions 1.5.1 Abbreviations The following abbreviations are used in this document. Abbreviation API C CDCVM CVM I I+ OEM OS OWASP PIN REE SBMP SE TEE TPM UI Table 1.3: Abbreviations Description Application Programming Interface Confidentiality Consumer Device Cardholder Verification Method Cardholder Verification Method Integrity Integrity with the addition of accountability/authentication Original Equipment Manufacturer Operating System Open Web Application Security Project Personal Identification Number Rich Execution Environment Software Based Mobile Payments Secure Element Trusted Execution Environment Trusted Platform Module User interface Requirements v1.0 / 37 1.5.2 Terminology and Conventions The following words are used often in this specification and have a specific meaning: Shall Defines a product or system capability which is mandatory. May Defines a product or system capability which is optional or a statement which is informative only and is out of scope of this specification. Should Defines a product or system capability which is recommended. The following conventions apply:

Requirement

Numbering Requirements in this document are uniquely numbered with the number appearing next to each requirement: For example:

3.1 The CDCVM Solution must be installed and implemented securely

A requirement may have different numbers in different versions of the document. Hence, all references to a requirement should include the version of the document as well as the requirement’s number. Requirements may include informative statements. In this case the statement is written in the italic font and the verb ‘may’ instead of ‘shall’ is used.

1.6 Support For help and support about this document, contact the EMVCo Security Evaluation Secretariat at sbmpsecurity@emvco.com.

Requirements v1.0

/ 37 2 Overview The initial version of these security requirements is focused on platform authentication mechanisms. Platform Authenticators are the mechanisms provided by the underlying device platform and used by the consumer to unlock the device. The mechanisms that are in scope include but are not limited to: passcodes (digits), passwords (alphanumeric characters), screen patterns, facial recognition, iris recognition, fingerprint, voice and similar mechanisms that use the hardware provided by the device (for example, screen, cameras, sensors, microphones, etc.) and are incorporated into, and managed by, the underlying platform (that is, accessible to the consumer under a device settings menu). In addition to unlocking a device, these same mechanisms are generally shared and accessible to Relying Applications on the device through platform Authenticator APIs. Figure 2.1: Overview of Shared Platform Authentication 2.1 Types of CDCVM Solutions A CDCVM Solution may be evaluated at the device level, OS level, or at an application level, depending upon the vendor of the solution.

  • A CDCVM Solution provided at a device level or OS level is a platform authentication mechanism intended for use by applications on the device.
  • A CDCVM Solution provided at an application level may only be available to the Mobile Application. Requirements v1.0 / 37 2.1.1 Device Level Evaluation of a Platform Authentication Mechanism An OEM vendor may request such an evaluation. This is the case when the solution provider and the system integrator is the OEM. A platform authentication mechanism is a fully integrated OEM solution – from capture of the authentication data to delivery of the authentication result to the Relying Application – which exposes access to CDCVM functionality to specified Relying Applications or applications.

2.1.2 OS Level Evaluation of a Platform Authentication Mechanism The OS vendor may request such an evaluation. This is the case when the solution provider is an OEM and the system integrator is the OS vendor. An OS level platform authentication mechanism is implemented on Authenticator APIs exposed by the OS vendor. These Authenticator APIs provide access to functionality such as fingerprint authentication. The OS vendor will provide guidance to Relying Applications about how to integrate available authentication mechanisms. Every OEM that integrates the authentication components to support the OS level solution is only required to provide firmware and hardware to support the Authenticator APIs, rather than a specific authentication component architecture. Therefore, the integration of the authenticator components will vary between OEMs. Examples of such variation, which is transparent at the OS level, include use of different TEEs, biometric sensors, and matching libraries.

2.1.3 Application Level Evaluation of CDCVM An application level CDCVM Solution will typically be based in the REE of a device and rely on security functionality provided by the device and the Mobile Application. Such a solution may arise, for example, if the Issuer of a Mobile Application has a security policy which does not permit use of an unevaluated, device level, CDCVM mechanism but instead requires an Issuer developed solution. An example could be passcode entry into an Issuer UI or Relying Application access to the on-device camera to perform facial recognition prior to a transaction. The CDCVM Solution may be included in the Mobile Application or possibly even a standalone application on the device, accessed by agreement with the Issuer. In this case, the application level CDCVM may co-exist on the device with a device level or OS level CDCVM Solution. While not the focus of this document, the security requirements presented in section 4 can be applied to any CDCVM Solution.

2.2 Relying Applications Relying Applications are the Mobile Applications that make use of the CDCVM Solutions on the device; how a CDCVM is used by the Relying Application will depend upon policies for those applications.

Requirements v1.0

/ 37 For example, a Relying Application may require a CDCVM for every transaction or require only the most recent result of a "device unlock". There are many potential ways in which a CDCVM Solution may be integrated with a Relying Application; for example, the Relying Application may be a:

  • Mobile Application that requires its own bespoke CDCVM
  • Mobile Application that requires device level CDCVM for all transactions
  • Mobile Application that will share the verification results with a payment application on a Secure Element or a Trusted Execution Environment for a period of time (depending on the mobile application’s CDCVM policy) The evaluation of an SBMP Mobile Application that uses a CDCVM Solution will include the integration of the CDCVM Solution with the Mobile Application in addition to evaluation of the CDCVM Solution and the Mobile Application. Note: A Relying Application that is an EMV payment application may also need to be assessed as part of an evaluation, for example SE based or SBMP.

2.3 Integration of CDCVM with a Relying Application The integration of a CDCVM Solution with a Relying Application will typically involve the scrutiny of Authenticator APIs, functionality, and user guidance provided to the Relying Application in order to be able to make use of the required functionality provided by the CDCVM Solution (see [SBMP Rqmts]). The security evaluation will verify that the integration follows the provided user guidance and does not introduce any new vulnerabilities to the Relying Application assets and processing as well as the CDCVM Solution assets and processing.

2.4 CDCVM and Consumer Wearable Devices Consumer wearable devices, such as smartwatches, that provide CDCVM to Relying Applications may be standalone or paired with an existing consumer device as an accessory. There is no standardized approach for implementing CDCVM on a consumer wearable device. The consumer wearable may have its own independent CDCVM Solution or it may be linked to a CDCVM Solution on the consumer device or some configuration of both, depending upon the policy applied to the device. The evaluation of such a CDCVM will be bespoke at a low level, but the methodology of this document also applies to the processing and flow of data between the consumer wearable and the consumer device.

Requirements v1.0

/ 37 3 Security Model for a Platform Authentication Mechanism No security is absolute. The aim of the CDCVM Solution is to make successful technology attacks unrewarding to criminals by presenting an attack surface that is uneconomic for fraudsters to penetrate.

3.1 Overview The solution provider of a Relying Application may wish to associate a risk with a CDCVM Solution or a specific modality of the CDCVM Solution. This will depend upon the assurance that all the components relevant to CDCVM processing are under the control of the consumer1. A Relying Application uses available Authenticator APIs to interact with the overall or specific modality of a CDCVM Solution. The interaction includes a sequence of processing steps and the transmission of data between components used during CDCVM processing, from the point of the capture (biometric or secret) to the response transmitted to the Relying Application. Each step of this processing sequence chain relies on the authenticity and integrity of the previous step — on the integrity of transmitted data and the component processing the data and all preceding components that processed the data. Each delegation to a new process or component in the sequence must be trusted.

3.2 Security Objective The high-level objectives of this security model are to ensure that:

  • CDCVM Solution assets are adequately protected.
  • None of the processing steps or flows from the request for cardholder verification by a Relying Application to delivery of the result back to the Relying Application can be manipulated to falsify or exploit the result.
  • The CDCVM Solution cannot be maliciously abused, disabled or bypassed. 1 Rather than under the logical control of a remote attacker. Requirements v1.0 / 37 3.3 Prerequisites for the Security Objective 3.3.1 External Dependencies The integrity of the CDCVM Solution may rely on external processes which are critical for the assurance provided to the CDCVM decision. This includes personalisation of components within the consumer device at some point during manufacture with cryptographic keys or other parameters to support communications and template storage within the device. This implies a level of cryptographic processing capability for some CDCVM components and the ability to inject keys into those components during some stage of the device lifecycle. This in turn may depend upon commercial agreements with component suppliers.

3.3.2 User Enrolment The integrity of the CDCVM Solution also relies on the processes used to enrol the consumer into the CDCVM Solution on the device and subsequent storage of CDCVM assets. Ideally, it should not be possible for an attacker to enrol without performing a CDCVM that offers assurance that is the same as or higher than the assurance provided by the normal user enrolment process. This may not be possible for CDCVM Solutions that vary in the security support provided; e.g. PIN entry using non-Trusted UI versus Trusted UI.

3.4 Security Goals of CDCVM Processing Steps This section outlines key security goals and objectives for the steps involved in CDCVM processing. Starting with the consumer’s verification data capture, through to communicating the final results to the Relying Application, there are several intermediate steps that must be completed to protect the data from unauthorised manipulation and modification.

3.4.1 Capture Biometric CVM Passcode/Password CVM Biometric data capture by sensor Secure processing of raw biometric data for feature extraction Secure channel for transfer of biometric data Passcode/Password entry into UI Secure processing of Passcode/Password entry Secure channel for transfer of Password/Passcode data Pattern CVM Pattern entry into UI Secure processing of pattern entry into a format for matching with a reference Secure channel for transfer of pattern data

Requirements v1.0

/ 37 3.4.2 Feature Extraction Biometric CVM Passcode/Password CVM Pattern CVM Secure feature extraction process to create biometric sample Conversion of input into a format suitable for matching with a reference Conversion of input into a format suitable for matching with a reference Secure channel for transfer of biometric sample (if applicable) Secure channel for transfer of sample (if applicable). Secure channel for transfer of sample (if applicable) 3.4.3 Match Biometric CVM Passcode/Password CVM Secure channel for transfer of biometric templates from storage Secure channel for transfer of stored passcode/password reference data from storage Secure biometric matching process Secure matching process Secure channel for transfer of the result of the biometric matching process through the Authenticator APIs Secure channel for transfer of the result of the matching process through the Authenticator APIs Pattern CVM Secure channel for transfer of stored pattern reference data from storage Secure matching process Secure channel for transfer of the result of the matching process through the Authenticator APIs 3.5 Attack Model Two scenarios are considered where the attacker tries to retrieve sensitive biometric data, or identify and exploit vulnerabilities: 1. The attacker gains remote access to the mobile device through manipulation of one or more available logical interfaces. In this scenario the security objective is to reduce the risk of scalable logical attacks on the CDCVM through spoofing a genuine verification result which can then be presented to the Relying Application. 2. The attacker gains physical access to the device through manipulation of available logical interfaces or by physical tampering. Physical attacks are typically not scalable, but if it is possible to circumvent the CDCVM by straightforward physical means then any ‘lost and stolen’ mechanism provided by the CDCVM is no longer effective. Collusive attacks are not included in the model. For example, an attack path due to an attacker who has already enrolled into a consumer device with the authorisation of the consumer.

Requirements v1.0

/ 37 3.6 Attacks on Consumer Device Cardholder Verification Any ‘undesired situation’ – such as the unauthorized disclosure of confidential information – represents a threat. A threat refers to a situation that exists after an attack, e.g. disclosure of information from nonvolatile memory. An attack is described in terms of the amount of effort required, the use of specific methods or techniques, and a number of different steps. There are, therefore, a variety of attacks related to a given threat that can compromise the confidentiality of data or the integrity of the platform. For CDCVM, two general threats are considered regardless of the authenticator used:

  • The confidentiality of secret data is compromised.
  • The integrity of CDCVM processing is compromised. From these threats, it follows that the goal of an attacker will be to compromise secret data on the physical device or to create an artefact as part of a presentation attack. Attacks on each of the different authenticators in scope of this document are considered below. However, note that the high-level strategies for attacking a CDCVM are similar for each authenticator regardless of the type; attack path differences are introduced due to specificities in CDCVM processing.

3.6.1 General Attacks on the CDCVM An attacker may attempt to compromise the CDCVM by exploiting UI vulnerabilities in enrolment or CDCVM management on the device. For example, it may be possible to replace a ‘current’ high assurance CDCVM by a lower assurance ‘activated’ CDCVM2 without any consumer authentication. These attacks are listed below. For example, a successful Attack b in Table 3.1 could be used to facilitate an Attack in Table 3.2. In general, such attacks will require privileged access to the device, either through ‘rooting’ the device or by the provision of genuine consumer credentials to gain the necessary privileges. 2 The issuer of a relying application should be aware of the presence of a lower assurance CDCVM Processing Environment if it is part of the CDCVM solution.

Requirements v1.0

/ 37 Table 3.1: Attacks on Shared CDCVM Attack Description Potential attack path a Malicious enrolment The attacker enrols his credentials into the CDCVM and is able to access the Relying Applications. Attacker is able to access the enrolment UI by bypassing or satisfying the required validation. Malicious The attacker switches the default CDCVM to an Activated Attacker has accessed the user device, has enrolled in a CDCVM replacement of CDCVM (that he has already b current CDCVM with compromised) and is able to (without the consumer’s knowledge), and is now able to a lower assurance CDCVM access the Relying Applications. access the CDCVM selection UI by bypassing or satisfying the required validation.

3.6.2 Attacks on a Biometric CDCVM Figure 3.1 illustrates an example of implementation of a biometric CDCVM. To compromise the inherent security of the ‘current’ CDCVM, e.g. fingerprint, an attacker will attempt to achieve at least one of the attacks shown in Figure 3.1 and listed in Table 3.2. Figure 3.1: Attacks on a Biometric CDCVM Table 3.2 provides a description of the attacks indicated in Figure 3.1.

Requirements v1.0

/ 37 Table 3.2: Attacks on CDCVM (Ref. Figure 3.1) Attack Description Potential attack path 1 Presentation Presentation of a fake artefact to spoof the sensor. For example, a fake fingerprint can be built from a latent print or from a photograph. 2 Processing Override Firmware for signal processing of the raw image is replaced by malware Malware performs an undesired action (regardless of the submitted biometric sample). 3 Raw Image Replay The image is used to 1) create an artefact or 2) replayed The channel is intercepted, the raw image tapped and then subsequently injected back into the channel. 4 Processed The processed image is replayed The channel is intercepted, the Image Replay processed image tapped and then subsequently injected back into the channel. 5 Feature Override Firmware for biometric processing is replaced by malware Malware performs an undesired action (for example inserts a different biometric reference). 6 Match Override Firmware for biometric processing Malware performs an undesired is replaced by malware action (regardless of the submitted biometric reference). 7 Template Manipulation The biometric template database is subject to attack Malware manipulates existing templates or inserts fake templates into the database 8 Interception Transmitted data is captured for later replay. The channel is intercepted, assets modified or tapped and then subsequently injected back into the channel. 9 Decision Manipulation Firmware for processing of the decision is replaced by malware Malware performs an undesired action (regardless of the decision). 10 Interception/Sp A spoofed result of biometric oofing of final processing is transmitted to the decision Relying Application. No biometric processing is performed, for example the entire authentication library is bypassed. Instead, a positive result is injected into the channel. 11 Glitch attacks Introduce transient faults during CDCVM processing. (One example shown in Figure 3.1 for illustration purposes only). Change the outcome of processing, for example change the result of a CDCVM failure to success.

Requirements v1.0

/ 37 Attack 1 of Table 3.2 is addressed by performance testing and is out of scope of the security evaluation. Attacks 2 to 11 of Table 3.2 must be addressed by the logical and physical protections afforded to CDCVM assets (see section 3.8) by CDCVM components and the protections applied to connectivity between CDCVM components. An attack may be facilitated by an exploitable vulnerability in the platform, for example if any CDCVM components are implemented that directly or indirectly rely on REE processing. Glitch attacks typically require physical access to the device. Note that a trivial glitch attack could be effectively scalable due to the use of social media to spread information. The design and deployment of the CDCVM Solution should mitigate anticipated threats. The work function (based upon time, skills, and resources) associated with a combination of these attacks required for a successful attack path must be sufficient to deter an attacker.

3.6.3 Attacks on Passcode or Password Based Verification Attacks on Passcode or Password CDCVM are similar to those of a biometric CDCVM. Table 3.3: Attacks on Passcode/Password Cardholder Verification Attack Description Potential attack path 12 Theft of Passcode/Password is Passcode/Password collected by malware that has access to the UI The UI is infected with malware or can be accessed by a privileged process which has been infected with malware 13 Processing Override Firmware for processing of the Malware performs an undesired passcode/password into a action (regardless of the submitted required format for matching passcode/password). with a reference is replaced by malware 14 Passcode/password The passcode/password is Replay replayed unknown to the consumer. Wherever the passcode/PIN data is communicated within the device, the channel is intercepted, the passcode/password data tapped and then subsequently injected back into the channel. 15 Passcode/password Firmware for Malware performs an undesired Override passcode/password processing action (for example inserts different is replaced by malware passcode/password data). processing 16 Match Override Firmware for matching the passcode/password with reference data is replaced by malware processing Malware performs an undesired action (regardless of the submitted passcode/password).

Requirements v1.0

/ 37 Attack 17 Reference data Manipulation Description Potential attack path The stored passcode/password reference database is subject to malware attack Malware manipulates existing templates or inserts fake passcode/password reference data into the database.

3.6.4 Attacks on Pattern Based Cardholder Verification Attacks on Pattern CDCVM are similar to those of a Passcode/Password CDCVM. Table 3.4: Attacks on Pattern Based Cardholder Verification Attack 18 Theft of Pattern 19 Processing Override 20 Pattern Replay 21 Pattern Override 22 Match Override 23 Reference data Manipulation Description Potential attack path Pattern is collected by malware that has access to the UI The UI is infected with malware or can be accessed by a privileged process which has been infected with malware Firmware for processing of the Pattern into a required format for matching with a reference is replaced by malware Malware performs an undesired action (regardless of the submitted Pattern). The Pattern is replayed unknown to the consumer. Wherever the Pattern data is communicated within the device, the channel is intercepted, the Pattern data tapped and then subsequently injected back into the channel. Firmware for Pattern processing is replaced by malware processing Malware performs an undesired action (for example inserts different Pattern data). Firmware for matching the Pattern with reference data is replaced by malware processing Malware performs an undesired action (regardless of the submitted Pattern). The stored Pattern reference database is subject to malware attack Malware manipulates existing templates or inserts fake Pattern reference data into the database.

Requirements v1.0

/ 37 3.7 Attacks Addressed by this Document For a CDCVM Solution, the security model addresses the attacks listed in Table 3.2, Table 3.3, and Table 3.4 depending upon the implemented authenticator. Attacks based on ‘shoulder surfing’ are excluded from this security model.

3.8 CDCVM Assets To Be Protected3 The following table identifies CDCVM assets that must be protected. Assets must be categorized as requiring one or more security services: Confidentiality (C), Integrity (I), and Integrity with the addition of accountability/authentication (I+). The vendor might additionally claim other security services (e.g. confidentially for binary code protection). Table 3.5: CDCVM Solution Assets Asset C/I+ Verification Result I Entered C/I Passcode/Password/ PIN Reference C/I+ Passcode/Password/ PIN Biometric Image C/I+ Biometric reference C/I Biometric Template C/I+ Intermediate C/I biometric data Intermediate C/I Password/Passcode/ Pattern data Description The result available to a Relying Application through the Authenticator APIs. Non-biometric CDCVM authenticator processed by the mobile device UI. The stored data compared with the value entered by the cardholder The data output by the sensor that will be used to create a biometric sample. The format will depend upon the sensor. For example, a touch sensor may require number of submissions of the biometric to the sensor which are required to ‘build’ a biometric sample, for example a mosaic assembly. The set of biometric features extracted from a biometric sample and compared with the Biometric Template A reference set of biometric features used for comparison Biometric data that are passed between processing components in the CDCVM Processing Environment Authentication data that are passed between processing components in the CDCVM Processing Environment. 3 Not all the assets listed may be present in a CDCVM solution. The population of assets depends upon the verification mechanisms supported by the solution.

Requirements v1.0

/ 37 Asset C/I+ Processing firmware I+ Sensor Processing I+ firmware Biometric Processing I+ firmware Cryptographic C/I+ parameters Audit Data I+ Counters for I+ Prolonged Authentication CDCVM counters I+ Description Firmware that supports CDCVM processing, for example matching data corresponding to a consumer input Password/Passcode/Pattern with a reference. Firmware and parameters that support the processing that generates the biometric sample that is used to extract biometric features. This may include parameters that are used to determine the quality of submitted biometric samples Firmware that supports biometric processing, for example matching. It may also include parameters that are used to determine the quality of submitted biometric samples including ‘liveness detection’ if not performed by the sensor. Cryptographic functionality may be used to provide integrity or confidentiality to assets. These are the parameters, for example keys, which are used to support this functionality. Stored data that can be audited to investigate historical CDCVM use. The mechanism used to enable the result of an Authentication to persist. The number of consecutive verification failures that are permitted by the CDCVM.

3.9 Assurance The security assurance provided by the CDCVM should be determined and analysed in the context of its intended deployment, rather than an assigned level for all deployments. The required assurance for deployment should be commensurate with the applied threat model.

3.9.1 Scalability In the context of an individual consumer device, the effort to compromise a CDCVM must not be economic when compared to potential returns. Thus, any successful attack path falling into one or more of the categories listed in Table 3.2 must be qualified by an attack potential. The attack potential associated with a given attack path must be weighed against the potential overall damage associated with the attack if it is scalable.

Requirements v1.0

/ 37 3.10 CDCVM Components Implemented in the REE One of the threats for a CDCVM processing environment implemented fully or partially in the REE is a malicious mobile OS that executes it and tries to subvert it in some way. A malicious OS run time environment can monitor and manipulate the memory usage including every instruction that is provided by CDCVM application processing to the OS. Vectors for compromising a mobile device are well known and usually require some action by the consumer whether intentional or unintentional. In this scenario the processing is subject to the following threats when executing under the mobile OS:

  • Eavesdropping of code, assets, control flow, and the Authenticator API
  • Modification of code, assets, control flow, and the Authenticator API
  • Presentation of false system information to the Relying Application
  • Manipulation of available Authenticator APIs (using the Relying Application as an Oracle)
  • Denial of Service The CDCVM may also be vulnerable to malware on the consumer device with sufficient privileges to perform one or more similar attacks, for example simply spying on execution detail and assets. The CDCVM may also be a target for privilege escalation attacks where an attacker attempts to subvert the mobile OS through abuse of a vulnerable application’s privileges. Other threats to the CDCVM are due to poor software development practices or coding errors by software vendors. Finally, mobile software security is constantly evolving as new attacks on mobile OS platforms emerge; the CDCVM development cycle will need to take this into account if it is reliant on REE security. Requirements v1.0 / 37 4 Security Requirements These security requirements are intended to meet the security objective as discussed in section 3.2 when applied to CDCVM processing. It is assumed that to compromise the inherent security of a CDCVM Solution and defeat this objective, an attacker will attempt attack paths based upon a combination of one or more of the attacks listed in Table 3.2.

4.1 CDCVM-SEC-REQ-1: Security Guidance and Usage Instructions Control Objective: Document the protection of the CDCVM Solution security assets and their dependencies. Note that the "user" here is not the cardholder; it is the system integrator, Issuer and/or security evaluator. No. Requirement 1.1 The CDCVM Solution must have a user (security) guidance document defining how to use the CDCVM Solution in a secure manner.

1.2 The user guidance document must define an explicit CDCVM Solution boundary. The boundary has to include any hardware (e.g. sensor) that performs, or software that implements, biometric authentication functionality.

1.3 If applicable, the user guidance document must state how the CDCVM Solution can be securely installed and updated, including default settings.

1.4 The user guidance document must list all security assets

For each security asset it must state the required protection (C/I/I+).

1.5 The user guidance document must indicate which devices – including platform versions (e.g. OS, TEE, SE, and TPM) – are supported.

1.6 The user guidance document must define the scope, dependencies, and actors if an attestation model is used by the CDCVM Solution or if an attestation model is used to supplement the security of the CDCVM Solution.

Requirements v1.0

/ 37 4.2 CDCVM-SEC-REQ-2: Asset Protection Control Objective: Protect the CDCVM Solution security assets to meet the minimum required security objective. No. Requirement 2.1 All security assets in the CDCVM Solution must be protected (C/I/I+) commensurate with their status (ephemeral, short-lived, or long-lived) as indicated in the security objectives for the CDCVM Solution.

2.2 Sensitive data must be securely removed from the device when no longer needed.

2.3 Sensitive data while stored, processed and in transit, must be protected as necessary for its stated security requirements.

2.4 The communication of an asset between the components must maintain the C/I/I+ requirements specified for that asset.

2.5 The security mechanisms used by the CDCVM Solution to protect the assets must be evaluated. If the mechanisms rely on the security of an underlying component (such as a TEE, white-box crypto, and obfuscation) then the security of the underlying component must also be evaluated and, where appropriate, certified.

2.6 If the assurance of the CDCVM Solution relies on security functionality provided by a component, that component must provide demonstrable assurance for that security functionality based on how the component is integrated into the Consumer Device and not on an evaluation of the isolated component.

Requirements v1.0

/ 37 4.3 CDCVM-SEC-REQ-3: CDCVM Solution Protection Control Objective: Protect the CDCVM Solution against unauthorized modification and usage. Ensure that the CDCVM Solution runs the latest approved version and can be securely updated. Some of these may not be relevant to a platform authentication mechanism and may only be relevant to CDCVM Solutions that make use of the REE. No. Requirement 3.1 The CDCVM Solution must be implemented securely.

3.2 The CDCVM Solution must be installed securely.

3.3 The CDCVM Solution must be securely updated.

3.4 The CDCVM Solution must be protected against unauthorized modification and update.

3.5 There must be a secure device binding of the CDCVM Solution with the Consumer Device.

3.6 The CDCVM Solution must have the ability to check and, if required, force a secure update to its latest version.

3.7 The CDCVM Solution must not allow a user-initiated roll-back to an earlier version that can transact successfully, unless explicitly allowed.

3.8 The integrity of the CDCVM Solution must be verified at and/or during runtime.

3.9 The CDCVM Solution must not run on non-supported platforms and/or devices.

3.10 The CDCVM Solution must not run in audit, debug, or test mode.

3.11 The CDCVM Solution must not log sensitive data in plain (unencrypted) format.

3.12 The CDCVM Solution must have the capability to be deactivated and to securely remove all sensitive data. At a minimum, this must occur when a compromise is detected.

3.13 If a user does not want to use the CDCVM Solution any longer, the reference data must be securely deleted.

Requirements v1.0

/ 37 4.4 CDCVM-SEC-REQ-4: Authentication – Identification and Verification between Entities and Interfaces Control Objective: Provide strong access control measures. No. Requirement 4.1 The CDCVM Solution must have a defined list of entities and interfaces it is allowed to communicate with.

4.2 The CDCVM Solution must have a physically secure interface to each of the entities in the defined list. If the interface is not considered physically secure, additional security controls must be implemented between the entities in the defined list to protect the security assets.

4.3 The CDCVM Solution must be able to establish that the capture mechanism is authentic so that it may trust the credentials given to it.

4.4 The capture mechanism should be able to authenticate the CDCVM Solution in order to be certain that credentials are not given to an untrusted application.

4.5 A CDCVM Solution, or any of its components, should not disclose sensitive information when queried by an unauthorized entity.

Requirements v1.0

/ 37 4.5 CDCVM-SEC-REQ-5: Verification Result Control Objective: The CDCVM Solution must provide accurate verification results to Relying Applications. Relying Applications must be able to trust the integrity of the results. No. Requirement 5.1 The CDCVM Solution must provide secure interfaces allowing authenticated Relying Applications to obtain the verification results and Verification Caching information.

5.2 The integration of CDCVM Solution functionality with the Relying Application must ensure integrity and non-repudiation (I/I+) for the result of verification processing presented to the Relying Application.

5.3 The CDCVM Solution must be able to establish that the capture mechanism is authentic so that the Relying Party can trust the provided credentials.

5.4 A CDCVM Solution, or any of its components, should not disclose sensitive information when queried by an unauthorized entity.

Requirements v1.0

/ 37 4.6 CDCVM-SEC-REQ-6: Reporting Control Objective: If applicable, CDCVM Solution must provide reliable and secure reporting information to the control server (e.g. CDCVM Solution back-end) without revealing sensitive information to unauthorized entities. No. Requirement 6.1 Account information and authentication data used for security reporting must be protected from unauthorized disclosure and modification.

6.2 Any reporting communications, particularly error codes, must not reveal information that would aid an attacker in obtaining sensitive information.

6.3 If any compromises are detected, the CDCVM Solution must have the capability to report to a server-side and the user / owner of the mobile device.

6.4 If the CDCVM Solution relies on a server-side attestation reporting model, then the attestation reporting must ensure the integrity and source of the time-critical and actionable health check actions and responses to and from the CDCVM Solution. Evidence must be provided that the attestation reporting model is properly implemented and ensures that the health check rules are effective.

Requirements v1.0

/ 37 4.7 CDCVM-SEC-REQ-7: Cryptographic Keys, Methods, and Random Numbers Control Objective: If communicating between multiple CDCVM Solution components over insecure interfaces use secure and industry accepted cryptographic protocols and methods. No. Requirement 7.1 Industry standardized cryptographic algorithms (e.g. TDES, AES, RSA, ECC), methods, and protocols must be used and securely configured.

7.2 Cryptographic keys must be protected (C/I/I+) as indicated in the security objectives for the CDCVM Solution component.

7.3 Cryptographic keys must be used for one intended purpose.

7.4 The cryptographic key hierarchy must be defined, including the following for every key:

  • cryptographic key name
  • key size
  • key usage (e.g. encryption, decryption, MAC, key encryption)
  • key uniqueness (i.e. unique per Mobile Application or is being shared with other Mobile Applications)
  • key lifetime (e.g. ephemeral, short-lived, long-lived)
  • key generation including location
  • key protection
  • key storage location 7.5 Random numbers must have sufficient entropy for the required security level within the CDCVM Solution component. Requirements v1.0 / 37 4.8 CDCVM-SEC-REQ-8: Secure CDCVM Solution Design and Development Control Objective: Develop the CDCVM Solution at a secure site with configuration management, version control, and secure coding practices. No. Requirement 8.1 The CDCVM Solution must be developed with proper configuration and source code control.

8.2 The CDCVM Solution development site must be properly protected from a physical, logical, and organizational security perspective.

8.3 The CDCVM Solution must be developed with secure design and security coding practices.

8.4 If the CDCVM Solution relies on a server-side attestation model, then a documented attestation policy and procedures must be in place. © 2018 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.