Document Diff - PCI Watch

Added p. 2

Document Abbreviations Used Abbreviation Description POI A Point of Interaction device validated to the PCI PTS POI requirements.

SCRP Secure Card Reader PIN. An approval class as defined in the PTS POI Device Testing and Approval Guide.

COTS device The platform on which an MPoC Application executes. Defined in the MPoC standard.

HSM Hardware Security Module

Table 1: Change Types Change Type Definition Clarification or Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic.

Evolving requirement Changes to ensure that the standard is up to date with emerging threats and technologies, and changes in the payment industry. Examples include new or modified requirements or testing procedures, or the removal of a requirement.

Structure or Reorganization of content, including combining, separating, and renumbering of requirements to align content.

Note: The changes above do not include those that are corrections of grammar or typographical errors or …

Added p. 4

Evolving requirement SR 1A-1.7 Added new requirement to validate that all card-based payment functionality has been included in the scope of the MPoC assessment.

Evolving requirement SR 1A-1.8 Added new requirement to ensure that an MPoC SDK provides a mechanism to validate its version number.

Evolving requirement SR 1A-2.3 Changed wording to clarify applicability when use of a true RNG cannot be assured.

Clarification or SR 1A-2.5 Changed wording to clarify that at least one trusted source of entropy is required from the COTS device. Updated guidance from existing MPoC FAQ.

Clarification or SR 1A-2.6 Changed wording to clarify the intent to ensure sufficient entropy. Added guidance.

Clarification or SR 1A-3.2 Added guidance noting that RSA 2048 bit may be used to load AES keys if the COTS platform prevents the use of larger RSA keys.

Evolving requirement SR 1A-3.3 Changed wording to clarify applicability is prior to certificate being relied upon for security services.

Clarification or …

Added p. 5

Evolving requirement SR 1A-5.2 SR 1A-5.5 Changed wording requiring secure channel on connections between different logical elements.

Evolving requirement SR 1A-5.6 Changed wording to clarify applicability to Secure Channels supported by the MPoC Software.

Evolving requirement SR 1A-5.7 Added clarification that this requirement does not apply to platform-based attestation.

Evolving requirement 1B-1 Preamble Clarified applicability to MPoC code executing on COTS devices, not on backend systems or code.

Clarification or SR 1B-1.4 Clarified that this requirement does not apply to areas of memory or COTS subsystems that the COTS-based MPoC Software does not have access to (such as a COTS keystore).

Clarification or SR 1B-1.5 Clarified scope to also include any sensitive assets managed by the MPoC SDK, as well as noting any features not provided must be considered in the attack costing calculation.

Evolving requirement SR 1B-1.7 Changed wording to clarify the intent is to prevent use of compromised platforms which may impact the security …

Added p. 6

Clarification or SR 1B-2.5 Changed wording to clarify that secure key generation is only required if key generation is implemented.

Clarification or SR 1C-2.3 Changed wording to clarify intent is to ensure freshness and authenticity of A&M data.

Clarification or SR 1C-3.6 Changed wording to clarify intent is to prevent manipulation of payment cessation messages.

Clarification or SR 1C-4.2 Removed previous requirement as considered redundant with requirement 1A-5.7. Intent of requirement remains.

Structure or 1D-1 Preamble Added note to clarify that PAN truncated to relevant PCI DSS FAQs is not considered in scope for these requirements.

Clarification or SR 1D-1.2 SR 1D-1.3 Split 1D-1.2 into two requirements. Added guidance on how a PCI PTS POI that is not an SCRP device may be validated to ensure all account data is encrypted.

Evolving requirement SRs 1D-1.3

• 1D-1.6 Moved the requirements in PCI MPoC v1.0.1 to Section 1A- 4.x in the updated document as previously noted.

Structure or SR …

Added p. 7

Evolving requirement SR 1D-3.1 Changed wording to clarify that the security guidance document must include details on all external readers supported by the MPoC Software.

Clarification or SR 1D-3.3 Clarified that the validation of attached MSR devices includes the firmware and hardware versions only where these values are applicable.

Clarification or SR 1D-4.3 Clarified that this requirement applies only when presentment of the card may be captured on the COTS camera.

Clarification or SR 1D-4.4 Removed requirement for validation of contactless kernel functional approval.

Evolving requirement SR 1D-4.4 Renumbered requirement from 1D-4.5 in PCI MPoC v1.0.1. Changed wording to clarify scope includes validation of relevant sections of Domain 4 and Domain 5.

Clarification or SR 1D-5.4 Changed wording to clarify intent is when there is an event that potentially impacts the security of the manual entry process.

Clarification or 1E Preamble Added clarification items regarding use of external POIs for PIN entry, and implementation of accessibility …

Added p. 8

Clarification or SR 1E-1.5 Added guidance to note that PCI PTS POI devices which are not part of the SCRP approval class may not be used for PIN translation functions.

Clarification or SR 1E-1.7 Changed wording to clarify intent is when there is an event that potentially impacts the security of the PIN entry process and that potential overlay attacks must be communicated to the back-end A&M system.

Clarification or SR 1E-1.9 Changed wording to allow for support of PCI PTS POI devices that are not an SCRP, and to clarify that the device must be validated as supporting offline PIN entry.

Evolving requirement SR 1E-1.10 Added new requirement for testing accessible PIN entry functions.

Evolving requirement SR 1E-1.11 Added new requirement for testing PIN entry implemented through an attached PCI PTS POI.

Evolving requirement SR 1E-1.12 Added new requirement for testing PAN tokens, where implemented.

Evolving requirement SR 1F-1.2 SR 1F-1.3 Removed requirements. Structure or …

Added p. 9

Evolving requirement SR 1G-1.8 Added new requirement to cover validation of guidance for implementations where the MPoC SDK allows for the other COTS-based MPoC Software to manage or implement secure channels.

Evolving requirement SR 1G-1.9 Changed wording to include external readers into scope. Evolving requirement SR 1G-1.12 New requirement to allow for MPoC Software vendors to perform vendor verification of other COTS-based MPoC Software that integrate their the isolating SDK(s) of the MPoC SDK vendor.

Evolving requirement Module 2A Preamble Added guidance to clarify scope of this module. Clarification or SR 2A-1.3 Changed wording to clarify that all card-based payment functions must be provided by the MPoC SDK(s).

Clarification or SR 2A-1.11 Added requirement to cover testing of COTS-based MPoC Software that implements or manages its own secure channels.

Section 3B-1 Moved the majority of these requirements in PCI MPoC v1.0.1 from this module to Domain 4.

Structure or SR 3B-1.4 Requirement moved from Section …

Added p. 10

Evolving requirement 4A-3 Title and Changed to reflect new items moved from Domain 3. Structure or SR 4A-3.3

• 4A-3.4 Requirements moved from Section 3B in v1.0.1. Structure or

Section 4A-4 Requirements moved from Domain 5 in v1.0.1. Structure or SR 5A-1.3 Added clarification that this requirement may apply to entities managing merchant systems on behalf of merchants.

Evolving requirement Appendix B ‘Scalability’ Fixed errata showing ‘instance specific’ as 18 points instead of the correct value of 12 points Structure or

Modified p. 1

Payment Card Industry (PCI) Mobile Payments on COTS ~~Security and Test Requirements~~ Version 1.0.1

Payment Card Industry (PCI) Mobile Payments on COTS (MPoC) Summary of Changes from Version 1.0.1 to 1.1

Removed p. 8

Solutions that do not use COTS devices, use devices that are intended for integration into another product, or solutions that are intended for use by the cardholder themselves using their own COTS device, are not considered by this standard. Similarly, MPoC does not consider or allow for solutions that are to be deployed into an environment that is not merchant attended.

The security requirements described in this document provide a security framework to protect the confidentiality and integrity of sensitive payment information captured and processed in MPoC Solutions. The test requirements outlined in this document provide details of the testing processes performed by the evaluation laboratories as part of the validation testing of the solutions.

The MPoC standard allows for an optional modular approach to the development of a mobile payment solution. An MPoC Solution is considered a monolithic solution if the MPoC Solution does not use or integrate any other listed …

Removed p. 9

• Domain 1: MPoC Software Core Requirements: The security and test requirements that apply specifically to the MPoC Software and MPoC Software lifecycle processes. The core Module in this Domain includes security requirements such as secure software and secure software lifecycle processes, integrity protection, sensitive information protection, and secure channels. This Domain includes optional Modules and Sections that are applicable only to MPoC Software supporting the relevant payment acceptance or cardholder verification methods (such as COTS-native NFC, or COTS-native PIN entry).

• Domain 2: MPoC Application Integration: The security requirements and test procedures that apply to MPoC Applications, including those that integrate previously assessed MPoC Software. The requirements in this Domain include the secure integration and usage of the MPoC Software, and the security of the complete MPoC Application.

• Domain 3: Attestation and Monitoring: The security requirements and test procedures that apply specifically to a service provider operating the back-end attestation …

Removed p. 11

Glossary/Terminology In addition to terms defined in the PCI DSS Glossary, Abbreviations and Acronyms1, Software-based PIN Entry on COTS (SPoC) Security Requirements, the terms/acronyms listed in Table 1 are used throughout this document.

Table 1: Glossary of Terms Term Definition Account data Account data consists of cardholder data and/or sensitive authentication data. See Cardholder data and Sensitive authentication data.

AES Abbreviation for “Advanced Encryption Standard.” Block cipher used in symmetric key cryptography adopted by NIST in November 2001 as FIPS PUB 197 (or FIPS 197).

Assets Assets are elements of the MPoC Solution that are security-sensitive or are used to provide security to other security-sensitive elements. Examples of assets include sensitive assets such as account data, cardholder PINs, and cryptographic keys. Software may also be considered an asset if the correct operation of that software is required to provide security protection to other assets. See also Sensitive assets.

Asymmetric encryption Also known as public …

Removed p. 12

Attestation and monitoring system (also A&M system) The combination of the Attestation System and the Monitoring System.

Attestation & Monitoring Service provider (also A&M Service provider) An entity that has integrated the back-end attestation and monitoring component of an MPoC Software Product, and is providing the operational service of that component as part of a listed MPoC Attestation and Monitoring Service Product.

Attestation and monitoring software (also A&M software) The software used to implement the attestation and monitoring functions. Attestation and Monitoring software is a required part of any MPoC Software Product.

Back-end systems The set of systems providing the server-side functionality of the MPoC Solution. This includes monitoring, attestation and (optional) payment and PIN processing functions.

Cardholder data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code. See …

Removed p. 13

COTS platform The hardware and operating systems (OS) of the COTS device.

COTS platform baseline A measurable configuration reference point of the COTS device attributes and COTS operating systems (OS) on which the MPoC Application may be executed. The COTS platform baseline is used for periodic comparative analysis by the back-end attestation system to determine changes that would impact the overall security of the COTS device to continue to process transactions.

Cryptographic material All materials involved in the implementation of a cryptographic algorithm or process including keys, entropy seeds, nonces, and lookup tables involved in the execution of the algorithm, etc.

Deterministic Random Number Generator (DRNG) A deterministic algorithm to generate a sequence of numbers with little or no discernible pattern in the numbers, except for broad statistical properties. Also referred to as Pseudo Random Number Generator (PRNG). See Random Number Generator (RNG).

Dual control Process of using two or more separate entities (usually …

Removed p. 14

Environment The systems and processes supporting one or more functionalities of the solution•such as the IT environment hosting the back-end monitoring system.

Execution environment The set of hardware and software on which a program is executed. This may be provided through hardware alone, include a combination of hardware and software elements, or be virtualized and implemented in software such that the execution environment can be similarly executed on different hardware platforms. See Rich execution environment (REE), Trusted execution environment (TEE)Trusted execution environment (TEE), and Secure element (SE).

Hash A method to protect data that converts data into a fixed-length message digest. A hash is a one-way (mathematical) function in which a non-secret algorithm takes any arbitrary length message as input and produces a fixed length output (usually called a “hash code” or “message digest”). Hash functions are required to have the following properties:

• It is computationally infeasible to determine the original input …

Removed p. 15

Mandatory access control Access control by which the operating systems (OS) constrains the ability of a process or thread to access or perform an operation on objects or targets such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc., through an authorization rule enforced by the operating systems (OS) kernel.

Man-in-the-middle (MITM attack) attack An attack method where a malicious third party interposes between two other communicating parties and modifies the data sent between them.

Merchant-attended A deployment of a payment acceptance device or solution is merchant-attended where there is a merchant or merchant agent who is able to assist with, or provide oversight of, the payment process.

Message authentication code (MAC) In cryptography, a small piece of information used to authenticate a message. See Hash-based message authentication code (HMAC).

Mobile device In the context of this Standard, see Commercial off-the-shelf (COTS) device.

Mobile Device Management (MDM) A system for the administration of …

Removed p. 16

MPoC Software vendor An entity developing, distributing, and supporting the MPoC Software.

MPoC Solution provider An entity that develops, manages, and/or deploys MPoC Solutions.

MPoC Software Product The MPoC Software as validated and listed on the PCI SSC website.

Monitoring system Monitors and provisions security controls to detect, alert, and mitigate suspected or actual threats and attacks against the MPoC Solution.

Non-deterministic random number generator (NRNG) A Random Number Generator that has access to an entropy source and (when working properly) produces output numbers (or bit strings) that have full entropy. Contrast with a Deterministic Random Number Generator (DRNG).

Non-PTS approved MSR An MSR that has been validated against the requirements in Appendix F of this standard.

Obfuscation Protection applied to a process or data through increasing the complexity of interpreting that data. For the purposes of this standard, obfuscation refers to code obfuscation where computational processes have been applied to increase the complexity of a …

Modified p. 16 → 2

~~Mobile Payments on COTS (MPoC)~~ SDK ~~(also MPoC SDK)~~ The subset of MPoC Software, that implements required functionality for the payment acceptance and attestation on the COTS device, and secure communication with the back-end systems.

SDK The subset of MPoC Software, that implements required functionality for the payment acceptance and attestation on the COTS device, and secure communication with the back-end systems.

Removed p. 17

Protection types The specific form of protection required for an asset, including one or more of confidentiality, integrity, and authentication.

Private key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public. In the case of an asymmetric signature system, the private key defines the signature transformation. In the case of an asymmetric encipherment system, the private key defines the decipherment transformation.

Provisioning / personalization The process of ensuring that a specific instance of a system has the correct settings and unique data to enable its operation.

Public key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and may be made public. In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key …

Removed p. 18

Secure element (SE) A tamper-resistant platform (typically a one-chip secure microcontroller) capable of hosting applications and their confidential and cryptographic data (e.g., key management) securely.

Secure reading and exchange of data (SRED) Requirements within the PCI PTS POI Standard, detailing testing for devices that protect account data.

Security processor Within a COTS device, a security processor is a separate processor or co-processor with its own dedicated memory running separate OS, applications and data on these processors are not accessible by the COTS device’s main OS.

Sensitive authentication data Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information includes, but is not limited to, card validation verification codes/values, full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.

Sensitive assets For the purposes of this standard, security assets include assets that require protection by, or be used to provide protection to, the MPoC Solution (e.g., cryptographic …

Removed p. 19

Tamper responsive A characteristic that provides an active response to the detection of an attack, thereby preventing a successful attack.

Trusted boot Also known as Verified Boot and Secure Boot. A cryptographic process where the bootloader verifies the integrity of all components (e.g., kernel objects) loaded during the OS startup process, but prior to loading.

Trusted execution environment (TEE) A trusted execution environment provides hardware-based security features such as isolated execution environment for Trusted Applications. It isolates sensitive assets and code from the Rich Execution Environment (REE).

Unattended (also not merchant-attended) A deployment of a payment acceptance device or solution is unattended where there is no merchant or merchant agent who is able to assist with, or provide oversight of, the payment process.

User interface (UI) The set of the human-machine interfaces that allows for interaction between a person and a computerized system. vTEE A virtualized trusted execution environment (TEE) that provides logical security …

Removed p. 20

Figure 1: Traditional PIN Acceptance Solution Overview Mobile payment acceptance enables the processing of payment transactions (e.g., using a smartphone or tablet that performs the functions of an electronic point-of-sale terminal). These solutions rely on a combination of mechanisms and security controls including, but not limited to, COTS device hardware, application software, and independent management and oversight of the entire process to ensure the security of the transaction and the cardholder verification data.

Note: MPoC Solutions are intended for a merchant-attended environment only.

Removed p. 21

Figure 2 shows the functional model of the solution that uses a software MPoC Application, with the option of additional hardware in the form of PCI PTS SCRP or Magnetic Stripe Reader (non-PTS approved MSR), for protecting account data.

This standard defines the requirements for assessment to validate candidate MPoC Products prior to it being listed on the PCI SSC website. For details on compliance programs outlining the use of listed MPoC Products, please refer to the relevant payment card brands.

Figure 2: Mobile Payments on COTS Solution Showing Various CVM and Account Data Acceptance Options

Note: The solution deployment is limited to payment acceptance channels and consumer verification methods validated by the applicable PCI-recognized laboratory.

Removed p. 22

• COTS-native NFC interface

• PCI PTS SCRP devices for contact, contactless, and MSR-based transactions

• Non-PTS approved MSR devices validated through the MSR appendix of this standard

• Manually entered account data and cardholder verification methods

• COTS-native PIN entry Support for any of the payment acceptance channels and/or CVMs described above is optional

• the only requirement is that an MPoC Solution, or MPoC Software Product, must support chip-based payments and at least one COTS-native method of entry. As examples, an MPoC Solution may support COTS-native NFC and COTS-native PIN entry on the same device, it may support COTS-native NFC without PIN, or it may support account data entry through external readers only with COTS-native PIN.

However, an MPoC Solution (or MPoC Software Product) may not support only MSR or manual entry-based payments, or methods of account data entry performed exclusively through a PCI PTS SCRP, without any COTS-native account data entry methods. Individual …

Removed p. 23

The architecture of an MPoC Solution relies on the following components that combine to provide for protection, attestation, detection, and response controls:

• A COTS device that is operated by the merchant to run the MPoC Application. The COTS device may have a TEE or secure element built-in, but this is not a requirement.

• MPoC Application that resides on the COTS device and:

• Collects and passes attestation data about any attached hardware systems (such as a PCI PTS SCRP or non-PTS approved MSR), COTS platform, and MPoC Application to the attestation and monitoring back-end systems.

• Contains software protection mechanisms to maintain its own integrity against attack.

• Securely communicates account data (and other sensitive assets such as cardholder PINs, where these are supported and used) to back-end systems.

• (Optional) a secure UI for entry of account data entry methods (such as PIN, PAN, or security codes), and encryption of this data.

• (Optional) …

Removed p. 24

The MPoC Software is considered as two separate parts

• the MPoC SDK (intended for integration into an MPoC Application) or complete MPoC Application itself, and the back-end software including the MPoC Attestation and Monitoring software. The MPoC SDK or MPoC Application execute on the COTS platform, although they may include remote execution components (such as a remote kernel).

Any MPoC Application may optionally support APIs that accept non-sensitive payment initiation data, such as an amount, from another “calling” application or function. This allows for an MPoC Solution to provide for payment initiation from applications outside of the scope of MPoC validation and listing

• by providing an API through which an MPoC Application may receive non-sensitive payment initiation and response data (such as amount).

Therefore, there are three types of COTS software considered in an MPoC Solution:

1. The MPoC SDK, which is designed to be integrated into an MPoC Application.

2. The MPoC Application …

Removed p. 25

• An Isolated MPoC SDK An Isolated MPoC SDK must provide for sufficient isolation of its memory space and be validated during the laboratory assessment that cleartext sensitive assets, such as account data or cryptographic keys, are not accessible by an MPoC Application that integrates that SDK.

• A non-Isolated MPoC SDK A non-Isolated MPoC SDK is an MPoC SDK that is unable to be validated to provide sufficient isolation to the cleartext sensitive assets from the MPoC Application.

In each case, the validation of “sufficient isolation” is based on the laboratory assessment and costing framework outlined in the MPoC standard. Assets that are already sufficiently protected, e.g., through the use of cryptography or truncation (for PANs), are not considered in the determination of an Isolated or non-Isolated SDK.

In all cases, an Isolated MPoC SDK cannot allow for sensitive cleartext data to be exposed to the MPoC Application, even if that functionality …

Removed p. 26

3. MPoC Applications that correctly integrate Isolating MPoC SDKs only.

These types of MPoC Applications integrate an MPoC SDK, from a listed MPoC Software Product, that has been validated to provide memory and cleartext asset isolation. MPoC Applications that correctly integrate only Isolating MPoC SDKs may be assessed to the Section 2A requirements of Domain 2 of the MPoC standard only. If the MPoC Application does not correctly integrate an Isolating MPoC SDK, or the MPoC Application bypasses, modifies, or supplements the payment and/or security features of the Isolating MPoC SDK, then the MPoC Application must also be validated against the requirements of Section 2B of Domain 2.

An MPoC Application is permitted to integrate up to two MPoC SDKs (although this is a not a requirement, and integration of one or no MPoC SDKs is also permitted). An MPoC Application that integrates a non-Isolating MPoC SDK is always assessed against all …

Removed p. 28

The MPoC standard allows for an entity to take on more than one role in an MPoC Solution. For example, an MPoC Software vendor may choose to also take the role of an MPoC Solution provider while outsourcing the A&M operation to an MPoC Attestation and Monitoring Service provider. In this case, the MPoC Solution may consist of an MPoC Application that exposes payment APIs for other applications to call, rather than an MPoC SDK to be integrated into new MPoC Applications (although this would also be possible).

In another example, an MPoC Software vendor may take the role of an A&M Service provider themselves, operating their back-end software for different MPoC Solution providers. Other possible combinations also exist. However, in all cases, the requirements that apply to that role will apply to any entity taking on that role. Only validated MPoC Solutions are permitted to be deployed for payment acceptance

• …

Removed p. 33

• with different combinations of listed MPoC Products and MPoC Applications

Note: An MPoC Solution that relies on (one or more) Attestation and Monitoring Service(s) needs to ensure the MPoC Applications it deploys are supported by those services.

Monolithic MPoC Solution Examples A monolithic MPoC Solution is defined by the fact that it does not integrate or use any other listed MPoC Products. A monolithic MPoC Solution may include or use external card readers, such as a PCI PTS SCRP or non-PTS approved MSR. Monolithic MPoC Solutions are assessed to all Domains of the MPoC Standard, although some Modules/Sections/requirements may not apply where these are scoped solely for the integration or assessment of different MPoC Product or account data entry types. Refer to Section: MPoC Domain and Section Applicability above for details on the specific Modules and Sections that may apply.

A monolithic MPoC Solution may implement multiple MPoC Applications, each with different …

Removed p. 34

• integrating the MPoC SDK into one or more MPoC Applications

• and (in this example) also relies on the use of a listed Attestation and Monitoring Service provider who supports the same MPoC Software Product that includes the MPoC SDK that is used.

In this example, the MPoC SDK being integrated supports an external non-PTS approved MSR and COTS-native NFC (with optional PIN support for the contactless payment channel). The MPoC Solution is deploying two MPoC Applications - one of the MPoC Applications implements both payment acceptance channels supported by the SDK (COTS-native NFC and non-PTS approved MSR), and one implements only the COTS-native NFC (with optional PIN) functions of the MPoC SDK.

In this case, the MPoC Solution would not be assessed against Domain 1 or Domain 3, as it is not implementing its own software or attestation and monitoring systems as part of the core of the MPoC Solution (if …

Removed p. 35

MPoC Solution Implementing Multiple MPoC Software Products with Multiple Attestation and Monitoring Services In another example, an MPoC Solution may integrate multiple MPoC Software Products, in conjunction with one or more Attestation and Monitoring Services. In this example, the MPoC Solution integrates two MPoC Software Products; one of these supports only COTS-native NFC entry (with optional PIN for CVM) on a specific COTS OS (designed herein as OS(a)), and the other supports external reading of account data (using a PCI PTS SCRP) on two COTS OS’s (the previously designed OS(a) and another COTS OS designed OS(b)) in addition to COTS-native NFC reading on OS(b) (both with optional PIN CVM).

The example MPoC Solution deploys two MPoC Applications. The MPoC Application deployed on OS(b) integrates a single MPoC SDK. The MPoC Application deployed on OS(a) integrates two MPoC SDKs, one MPoC SDK to support COTS-native NFC (with optional PIN CVM) and the …

Removed p. 36

• COTS device, attestation, and monitoring security controls to protect the security of payment transactions on COTS devices are consistent with PCI Software-Based PIN Entry on COTS (SPoC) and PCI Contactless Payments on COTS (CPoC).

• POI devices are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements.

• HSMs in the back-end environment used for PIN and account-data decryption, and related cryptographic-key operations require validation to PCI PTS HSM or FIPS 140-2, or 140-3, Level 3 (or 4).

• Software used in the solution and software lifecycle practices are developed using best practices consistent with the PCI Software Security Framework (SSF).

• The back-end payment-processing environment is required to be PCI DSS compliant.

• The back-end PIN-processing environment is required to be PCI PIN Security compliant.

• The security requirements for back-end attestation and monitoring environment are developed from PCI DSS DESV (where the back-end attestation and monitoring systems are sufficiently isolated …

Removed p. 37

Use of PCI PTS SCRP Devices A PCI PTS SCRP used with an MPoC Solution must be an approved PCI PTS device that is listed on the PCI SSC Approved Device website with an SCRP Approval Class. This class of devices may optionally support contact magnetic stripe reading functionality. When included with an MPoC Solution, a PCI PTS SCRP may be used for any method of card data presentment that it supports, including for the acceptance of contactless payment cards. A PCI PTS SCRP may also be included when a COTS-native presentment method is used in place of one supported by the PCI PTS SCRP (e.g., a PCI PTS SCRP that supports contactless cards could be used with an MPoC Solution that uses COTS-native NFC acceptance instead).

Use of Non-PTS Approved MSR When non-PTS approved MSR is supported by the solution, the tester must validate the standalone non-PTS approved MSR device …

Removed p. 38

Relationship between This Standard and PCI SPoC Standard and PCI CPoC Standard The MPoC standard incorporates and builds upon many of the concepts and requirements founded in the PCI SPoC and PCI CPoC standards. However, the MPoC standard does not supersede or replace these other mobile standards. For details of any migration path from an existing SPoC or CPoC Solution to the listing of an MPoC Solution, refer to the MPoC Program Guide.

Removed p. 39

For an objective-based approach to be successful, entities are expected to possess a robust risk-management practice as an integral part of their “business-as-usual” operational process. While this approach provides the entities with the flexibility to implement security controls based on identified risk, the entity needs to be able to demonstrate how the implemented controls are supported by the results of its risk-identification and risk-management practices. Without a robust risk-management practice and evidence to support risk-based decision making, adherence to the requirements in this standard may be difficult to validate.

If security requirements do not define a specific level, rigor, or frequency for periodic or recurring activities (e.g., the maximum period in which an entity is required to release a security update to fix a known vulnerability), the entity may define the level of rigor or frequency that is appropriate. The rigor and frequency defined by the entity must be supported by …

Removed p. 41

• Security Objective. Identifies the high-level security objective that the entity is required to meet. Security objectives are broadly stated to enable entities flexibility in determining the best methods to achieve the stated security objective. However, it is expected that the entity produces clear and unambiguous evidence to show that the chosen methods are appropriate, sufficient, and properly implemented to satisfy the security objective. Below the security objective, additional information has been provided to help both entities and laboratories understand the intent behind the security objective.

• Security Requirements. Specific security controls or activities that must be implemented by the entity to support the overarching security objective.

• Test Requirements. Describe the expected testing activities to be performed by the laboratory to validate whether an entity has met a particular security requirement. The test requirements are intended to provide both the entity and the laboratory with a common understanding of the assessment …

Removed p. 43

Sensitive assets are a sub-set of the asset class that require confidentiality protections.

The specific assets used in a solution are expected to be unique to how that solution operates, and therefore a comprehensive list is required to be developed as part of the evaluation of any MPoC Solution.

The security controls required to protect payment information depend on the type of payment acceptance channels and cardholder verification methods supported by the MPoC Software. All MPoC Software is required to meet the security objective, requirements, and test requirements in the Core Module. The objective of these security requirements is to ensure the integrity of the COTS device, and to reasonably ensure that the solutions provide adequate security mechanisms, controls, and mitigations to protect the cardholder’s account data and other assets such as cryptographic keys. These requirements assist with protection from unauthorized disclosure, modification, or misuse by restricting the available attack surface and …

Removed p. 45

The functional requirements of the MPoC Software can be further organized into the following components assessed under this Domain:

• A software application or a library that implements payment acceptance and optional supported cardholder verification methods and/or may influence the security of payment data processing on the COTS device (the MPoC SDK or a monolithic MPoC Application). This software may be executed, in part or as a whole, on the COTS device itself or executed remotely and rendered on the COTS device through other means.

• The back-end attestation and monitoring systems that cannot be entirely (logically) accessed from the merchant environment and that must be capable of being regularly/rapidly updated to respond to new threats and to apply changes or updates to the solutions.

• An optional API provided by the MPoC SDK that allows other third-party developers to interface with the MPoC Solution.

• All contactless kernels used in the MPoC Software, …

Removed p. 46

1A-1 Secure Software Requirements Software is to be developed and maintained according to a defined software-security development and lifecycle process. Software developers require knowledge to address software vulnerabilities and emerging risks.

Development of secure software requires knowledge of common attack techniques and vulnerabilities. These vulnerabilities can change over time; therefore, a continuous process to inform software developers about these changes is vital. It is not sufficient to confirm that the developers have been provided with documentation, books, and/or training on secure software development. There needs to be auditable confirmation that developers have knowledge of common vulnerabilities in the language and environment in which they develop software.

To facilitate reliable and accurate payment transactions, the systems and software used as part of the payment-transaction flow must be designed, developed, and maintained in a way that protects the integrity of payment transactions and the confidentiality of all sensitive assets stored, processed, or transmitted in …

Removed p. 47

1A-1.2.a The tester must confirm through examination that a vulnerability-reporting program exists for the system, and there is evidence of accepting and remediating security vulnerabilities found through this program.

Penetration testing and vulnerability management processes are expected to be part of the MPoC Software vendor’s secure software lifecycle process. This requirement confirms the scope and efficacy of the penetration testing as it is applied to the MPoC Software specifically. Penetration tests need to be performed by suitably skilled resources and may be performed by resources internal to the MPoC Solution provider if such resources exist. When penetration testing is performed by internal resources, the people performing the testing need to be separate from those who have been involved in the development of the MPoC Software. Skills expected from the resources used for penetration testing include:

• An understanding of EMV protocols and payment processing.

• Skills and experience with mobile security and communications …

Removed p. 48

1A-1.4.a Where an existing validation and listing of the MPoC Software A&M component to the PCI Secure Software Standard exists, the tester must confirm through examination and observation that the assessment scope and listing are correct, complete, and current. The tester must cite the listing number and version from the PCI website listing.

Security controls to protect the integrity and the confidentiality of the sensitive assets stored, processed, or transmitted by the MPoC Software are vital for any MPoC Solution. There is no one-size-fits-all method to software security. As a result, entities need flexibility to determine the software security controls and features most appropriate to address their specific business and software risks. As such, it is required that entities possess a robust risk- management practice as an integral part of their business-as-usual operational processes and be able to demonstrate how the implemented security controls are supported by the results of their …

Removed p. 49

1A-1.5.a The tester must confirm through examination and observation that the MPoC Software implements at a minimum (both of the following):

• Payment acceptance for at least one of either contact or contactless chip (through COTS- native interfaces, or through use of an external PCI PTS SCRP).

• COTS-native interfaces for the input at least one of either contactless chip, or cardholder PIN.

The MPoC standard is intended for use with solutions that use COTS-native interfaces for the acceptance of chip- based payment transactions, or cardholder verification methods (such as a PIN). Solutions that rely entirely on non-COTS devices, such as a PCI PTS device, for the acceptance of account data, and do not provide for any COTS-native acceptance of account data or PIN data, are not intended for assessment under this standard. For example, solutions that support only magnetic stripe cards, only manual PAN entry, or only uses the COTS device as …

Removed p. 50

Any random numbers used for security purposes must be generated using a secure method, such as a DRNG seeded from a value that comes from a trusted source. A COTS device that has a TEE or SE evaluated as a random number generation source directly can be used as a source of entropy. Otherwise, a DRNG must be used, seeded from an external trusted source such as a PCI PTS SCRP or a back-end system such as an HSM, in addition to entropy from the COTS device itself. Combining these different entropy sources ensures that even if one is compromised it does not automatically invalidate the security of the random number generation process as a whole.

This applies to all components and parts of the MPoC Software where random numbers are required to be generated for security functions. Random numbers that are not relied upon directly for security of the account …

Removed p. 51

1A-2.1 Software development documentation must provide details about how the MPoC Software generates secure random numbers, as required, on all deployed platforms.

1A-2.1.a The tester must confirm through examination that the software-development processes and practices used, with respect to the generation of random numbers, include the required information and are consistent with the tester’s understanding of the MPoC Software. Information maintained for random number generation method must include at a minimum:

• The generation and origin of random numbers.

• The expected entropy of any seed values used.

• The seeding period.

• Details of any DRNG algorithms implemented.

This requirement applies to all MPoC Software regardless of where it is executed (i.e., this requirement applies to both back-end and MPoC SDK software). Random number generation often sets the security baseline upon which other security controls rely. This may include the generation of padding data for use in certificates, key bundles, and EMV flows as well …

Removed p. 52

1A-2.2.a The tester must confirm through examination that, where the security of assets requires the use of random numbers, an assessed Random Number Generator (RNG) is used.

This requirement applies to all MPoC Software regardless of where it is executed (i.e., this requirement applies to both back-end and MPoC SDK software). Examples of situations where random numbers may be required to secure account data include the generation of cryptographic keys, padding prior to encryption of account or PIN data, or security controls such as attestation functions. The EMV Unpredictable Number (UN) used by a payment kernel is not included in the scope of this requirement. However, where a payment kernel requires entropy for other security purposes, these random numbers are in scope of this requirement. It is required that account data and attestation data are protected with cryptographic controls. Such controls often depend on the quality of random numbers to maintain …

Removed p. 53

1A-2.3.a The tester must confirm through examination that, where a hardware based true Random Number Generator (RNG) is not directly used, the MPoC SDK implements its own DRNG based on well-known international and industry- standard algorithms suitable for cryptography use.

DRNG algorithms used by the MPoC SDK are required to be secure algorithms and known international standards suitable for cryptography use as specified in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. Homegrown algorithms do not provide enough assurance on the quality of the random numbers provided or the security of the algorithm. It is expected that the algorithms used by the MPoC SDK use international and industry- standard algorithms (e.g., NIST SP 800-90A).

1A-2.4 DRNGs used by the MPoC SDK must be regularly (re)seeded with unpredictable values of sufficient entropy, which are protected for confidentiality and integrity.

1A-2.4.a The tester must confirm through examination that, for each DRNG …

Removed p. 54

1A-2.5.a The tester must confirm through examination that the DRNG seeding process includes random data from a trusted external source, such as a PCI PTS SCRP or back-end HSM, in addition to one from the COTS device. Note: This requirement only applies to systems using a DRNG assessed under requirement 1A-2.3.

The DRNG used by the MPoC SDK can use different sources of entropy to obtain its seed (e.g., one HSM and the COTS platform Random Number Generator (RNG)). This increases the effort needed to compromise the DRNG used by the MPoC SDK. The back-end random data can be obtained from the back-end HSM. The random data taken from the COTS device can be obtained from one of the COTS platform Random Number Generator (RNG) sources (OS, TEE, SE) or from another method of collecting unpredictable data. By using these two sets of (re)seed data from different systems (COTS device, and …

Removed p. 55

1A-2.6.a The tester confirms through examination that the method to reseed the algorithm is secure and the entropy used to reseed does not completely determine the future states of the DRNG (i.e., entropy is added to the state of the DRNG instead of re-instantiating the DRNG).

When reseeding the DRNG, the new seed is required to add to the entropy of the DRNG and not be used to re- instantiate the DRNG to a previous or known state. This helps to mitigate the risk that a compromised future seed can be used to completely determine the output of the DRNG. Adding to the entropy of the DRNG, rather than implanting another seeding process to restart the DRNG, ensures that any attacker who has compromised the current entropy values is not able to determine the output of the DRNG unless they have captured all entropy seeding values. This mitigates attacks against externally …

Removed p. 56

Sensitive assets are required be encrypted on the COTS device for transporting to other components of the MPoC Solution using cryptographic algorithms and modes of operation known to provide suitable levels of security.

All cryptographic keys are required to be used for a single specific purpose. For example, a key used to encrypt account data is not permitted to also be used to protect the integrity of the tamper-detection data.

This requirement does not apply to cryptographic methods applied by the PCI PTS SCRP for onward processing by the payment processing environment (e.g., PIN block translation functions performed by the PCI PTS SCRP, which have been previously assessed to PCI PTS POI standard).

Security Requirements Test Requirements Guidance Objective: Industry-standard and accepted cryptography is used to protect sensitive assets.

1A-3.1 Software-development documentation must provide details about acceptable cryptographic processes and operations to be used for security services.

1A-3.1.a The tester must confirm through examination that …

Removed p. 57

1A-3.2.a The tester must confirm through examination that the cryptographic algorithms and the key sizes comply with Appendix C Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.

To withstand attacks, the solution is required to use the most robust and current encryption algorithms and key sizes. Legacy algorithms may have known weaknesses and provide security levels that are unsuitable given current and projected computing power. Use of recognized cryptographic methods ensures that the solution adheres to industry-tested and accepted algorithms and appropriate key lengths that deliver effective key strength and proper key-management practices. Proprietary or “home-grown” algorithms do not provide this assurance and are not permitted. Hash functions are used to provide integrity and support authenticity controls over data. They may be used on their own or in combination with other cryptographic controls.

1A-3.3 Public keys used by the MPoC Software must be protected for integrity and authenticity and be …

Removed p. 58

1A-3.4.a The tester must confirm through examination that the cryptographic keys used in the MPoC Software are not used for multiple purposes, specifically noting the findings for the PIN and (other) account data keys.

The MPoC Software is required to prevent the use of a single key for more than one purpose (e.g., signing and encrypting data, or using a key encrypting key to encrypt PANs). This helps to reduce the impact of the compromise of any one key. The disclosure of a secret or private key needs to be prevented from compromising data not intended to be protected by that key (e.g., so the compromise of a key that protects card data cannot expose PIN data). Keys used in industry-standard protocols, such as TLS, are not included in this requirement. A key that exists higher in the hierarchy can be used to generate or derive multiple keys, each with its …

Removed p. 59

• Distribution/conveyance

• Established cryptoperiods

• Replacement/rotation when the cryptoperiod is reached

• Key compromise and recovery

• Emergency procedures to destroy and replace keys

• Accountability and audit Secret and private cryptographic keys that are relied upon for security are required to be unique per device/application, with the exception of keys protected through software-protected cryptography means, which are used to establish an initial trust anchor prior to provisioning unique keys to the MPoC Application. Shared public keys are acceptable, but methods and procedures for revoking compromised public key/private key pairs must be implemented. For additional information about public key Infrastructure (PKI), refer to X9.79-4.

Operations that involve secret or private cryptographic keys are to be performed using split knowledge. Split knowledge requires that no one person can determine any single bit of a secret or private cryptographic key. Split knowledge can be provided in the following ways:

• Storing keys on secure cryptographic devices (SCD) approved …

Removed p. 60

1A-4.1 An inventory of all keys used by the MPoC Software must be maintained.

1A-4.1.a The tester must confirm through examination that the information provided matches their understanding of the MPoC Solution and contains the required information for all keys used in the MPoC Software. For each key, the information must be provided containing at a minimum:

• ID or name of the key

• Uniqueness (e.g., per transaction, device, solution, etc.)

• Algorithm and key size

• Cryptoperiod (key lifetime)

• Key-generation location (Name of server, application, database, device, etc.)

• Key-generation method (SCD, PCI PTS SCRP, OS, SE, TEE, software, etc.)

• Key usage location (name of server, application, database, device, etc. For symmetric keys this is at least 2 locations.)

• Key loading (where relevant, how is the key loaded?)

• Confidentiality protection during transport

• Confidentiality protection during storage

• Integrity protection during transport

• Integrity protection during storage

• Removal/destruction A good key-management process, whether manual or automated, is …

Removed p. 61

A cryptoperiod needs to be identified for each key based on a risk assessment, and keys are required to be changed when this period is reached. Additionally, keys are required to be immediately prevented from use. Compromised keys should be destroyed and replaced promptly upon confirmation of a compromise. Secure key-management practices include:

• Minimizing access to keys to the fewest number of custodians necessary.

• Enforcing split knowledge and dual control for activities involving cleartext keys or key components.

• Defining roles and responsibilities for Key Custodians and Key Managers. The key inventory must include any public keys or certificates used by the solution. Where possible, certificates should be maintained in a standard format such as X.509. When certificates are used or stored in other formats, information about the certificate use and context may need to be stored in another format. For example, a specific protocol or implementation may use public keys …

Removed p. 62

1A-4.2.a The tester must confirm through examination and observation that secret and private keys are imported or injected into the MPoC Software only in a way that protects their confidentiality and integrity. 1A-4.2.b The tester must confirm through examination and observation that the confidentiality, integrity, and authenticity protections do not solely rely on the use of a secure channel. 1A-4.2.c The tester must confirm through examination and observation that keys used to encrypt other keys for transport are not also used to secure keys during storage.

Requirement 4A-2.6 covers the operational aspects of key management, and notes that key blocks are one way of protecting the confidentiality and integrity of cryptographic keys. When the MPoC Software requires secret or private cryptographic keys to be imported, these need to be protected. It is not sufficient to send such keys protected only using secure channel protection, such as TLS. The keys are required …

Removed p. 63

1A-4.3 Secret or private keys embedded into an MPoC SDK must implement software protection methods and not be exposed in cleartext.

1A-4.3.a The tester must confirm through examination and observation that if secret and private keys are embedded in the MPoC SDK, they are in a form that is protected with software-based protection measures such as software-protected cryptography.

When secret or private keys are embedded in the MPoC Software, they need to be protected using software methods such as software-protected cryptography. Embedding of secret or private cryptographic keys in aspects of the MPoC Software other than the MPoC SDK is not permitted.

1A-4.3.b The tester must confirm through examination that any software protection measures used are compliant to the 1B-2.x requirements of this standard.

1A-4.3.c The tester must confirm through examination that secret or private cryptographic keys are not embedded in any other aspects of the MPoC Software, other than the MPoC SDK.

1A-4.4 Certificates …

Removed p. 64

1A-4.6.a The tester must confirm through examination and observation that the MPoC Software is created to support the use of HSMs for storage and operation of cryptographic keys in the back-end environments.

Operational key management controls in Domain 4 require the use of HSMs to secure cryptographic keys used in the MPoC Solution. To ensure that any separately listed MPoC Software product does not prevent compliance to later operational requirements, it is important that the software is created to support HSM use.

1A-4.7 The MPoC Software must implement methods to revoke or otherwise cease the use of compromised cryptographic keys or certificates.

1A-4.7.a The tester must confirm through examination and observation that the MPoC Software is able to revoke or otherwise cease the use of cryptographic keys or certificates that are suspected of being compromised.

The secrecy and security of cryptographic keys, including the private keys associated with public key certificates, is the primary …

Removed p. 65

• Between the MPoC SDK and external card reader(s)

• Between the MPoC SDK and back-end environments If internal systems such as a TEE or SE are used, and these provide for the use of a secure channel to protect communications between itself and the REE, then these protections must be used.

Security Requirements Test Requirements Guidance Objective: Connections between separate elements of the MPoC Solution are protected and authenticated.

1A-5.1 Secure channels established by the MPoC Software must be documented.

1A-5.1.a The tester must confirm through examination that the vendor secure channel information matches the design of the solution. The information must include at a minimum:

• The endpoints of each secure channel.

• The root of trust used for each secure channel.

• Cryptography supported by each secure channel.

• How the channel is established and how mutual authentication is guaranteed.

A secure design of the communication channels assists with protecting assets during transit. For a resilient …

Removed p. 66

1A-5.2.a The tester must confirm through examination that communication channels between different physical and logical elements are protected using secure channels where possible. The tester must document how the secure channel is established, how the root of trust is defined and implemented, and if the secure channel is sufficient to protect the confidentiality and authenticity of the connection. When security methods rely on properties of the COTS platform instead of a secure channel, the tester must document these methods and confirm that they are suitable for use and that they are present on the platforms being used.

When elements are physically separate, a secure channel is required to protect the communications between these elements. Such secure channels need to ensure data confidentiality and authenticity during the establishment and subsequent use of the channel. No secret or sensitive assets are permitted to be transferred prior to the establishment of the secure channel, …

Removed p. 67

1A-5.5.a The tester must confirm through examination and observation that the secure channels that extend outside of a physically protected boundary perform mutual authentication before any exchange of any assets.

During the installation of the MPoC SDK or integrating MPoC Application, it is normally not possible to authenticate the merchant COTS device as all the installable packages are the same for the same COTS device model. Currently, however, there are no unique assets provisioned to the MPoC Software and it cannot perform transactions. It is expected that after initial download, the MPoC SDK receives the necessary data to enable its authentication by the backend in future interactions. It is not acceptable for the MPoC SDK to “re-provision” each time it is required to re-establish a secure channel, mutual authentication is required to be implemented for all connections after the initial provisioning process. Certificate pinning may be used in part to meet …

Removed p. 68

1A-5.7.a The tester must confirm through examination and observation that assets in transit are protected using application-level encryption applied at the data level in addition to the security and encryption provided by the secure channel.

The MPoC Software assets need to be protected for confidentiality and authenticity when transmitted through a secure channel. It may be possible to strip the protocol used by the secure channel, such as TLS, or intercept the data as it passes to libraries that implement the protocols used. Therefore, encryption at the application level is needed to provide an additional layer of security that cannot be stripped easily. Assets only include the sub-set of assets that require confidentiality protection, and the MPoC Software is not required to be protected in this way.

Removed p. 69

Security Requirements Test Requirements Guidance Objective: Assets that are transmitted through APIs to third-party applications are protected.

1A-6.1 Documentation of any API exposed to third parties must exist.

1A-6.1.a The tester must confirm through examination that information provided includes the following at a minimum:

• UI display data that is communicated through third-party APIs exposed by the MPoC Software.

• Guidance for users of the API about how to securely use the API and protect the UI display data on the external application.

As part of the security design of the MPoC Software, the UI display data that is communicated to external parties, including the exposed API, need to be identified. As the handling of these UI display data involves an external third-party application, information needs to be included that guides the external application to take appropriate measures to protect the assets. This requirement does not mandate that UI display functions are provided to the …

Removed p. 70

1A-6.3.a The tester must confirm through examination that the protection type of the communicated assets is maintained in any API interface.

Refer to table 4 in the introductory parts of this standard for examples of MPoC assets. If assets, such as transaction data or A&M data, are to be communicated through an API, these assets are required to maintain the protection type that is required in the overall MPoC Solution. For example, if an identifier requires confidentiality protection, it is required to be communicated with its confidentiality protected and not in cleartext. Protection may be provided using cryptographic means if the assets is to be exposed in untrusted memory or processing spaces, or through the shared memory protections provided by an integrated MPoC Software. This requirement should be considered in conjunction with requirement 1D-1.2, which covers the encryption of account data. Non-sensitive payment initiation data, such as a payment amount, is …

Removed p. 71

1B-1 Software Security Mechanisms The security mechanisms that protect the MPoC SDK from attacks, such as reverse engineering, modification, and monitoring, also help protect the MPoC Solution assets as they are entered into, processed by, and transferred from the COTS device. The security mechanisms not only have a preventive role in the MPoC Software’s security; they also work as detection mechanisms where they are tied to the A&M.

Many types of security mechanisms exist, each with different strengths and protection goals. It is important that the security design of the MPoC Software considers the coverage of the security mechanisms and the interaction between them. Furthermore, it is important that the level of protection (strength) of the security mechanisms is evaluated.

Security Requirements Test Requirements Guidance Objective: The MPoC SDK implements security mechanisms that protect assets and resist tampering attempts.

1B-1.1 The security mechanisms implemented in the MPoC SDK must be documented.

1B-1.1.a The tester …

Removed p. 72

1B-1.2.a The tester must confirm through examination that the assets are correctly identified according to the testers understanding of the MPoC Software. The information provided must include, but not be limited to, the following:

• Assets name and description.

• Components that have access to the assets in cleartext or have enough information to recover it in cleartext (e.g., encrypted assets and encryption key).

• How the assets are protected according to their required protection type (e.g., confidentiality, integrity, authenticity) and lifecycle stages (generation, transmission, storage, process, and removal).

• Code flows involving assets.

Assets in the context of this requirement are resources or information valuable to the stakeholder or operation of the MPoC Solution, that need protection. Examples of assets include cryptographic keys, account data, information supplied or used as part of an attestation system, etc. Refer to Table 4 for examples of MPoC assets. The tester needs to use their understanding of the …

Removed p. 73

1B-1.3.a The tester must confirm through examination that where security mechanisms used by the MPoC SDK rely on previous approvals or certifications that the evidence and scope of prior evaluation/certification is sufficient to ensure security to the assets they protect.

If the security mechanisms used by the MPoC SDK depend on an underlying system such as a TEE, SE, etc., there needs to be assurance on the security of the underlying system. Any prior certifications relied upon are required to be relevant to the payment acceptance and security scope of an MPoC Solution. Examples of certifications that may be acceptable, include, but are not limited to:

• Common Criteria (at EAL4 with AVA_VAN 5)

• Common Criteria with Global Platform TEE PP

• EMVCo Chip and Global Platform

• PCI-PTS POI, PCI HSM

• FIPS 140-2/FIPS 140-3 (Level 3+) The tester needs to ensure that the scope and methods used in the prior evaluation are valid …

Removed p. 74

1B-1.5.a The tester must confirm through examination, observation, and testing that the methods used to provide resistance to reverse engineering sufficiently cover the required functionality, including the following functionality at a minimum when present:

• The contactless kernel code.

• Code handling/interfacing with cryptography functionality.

• Code that handles the sensitive assets.

• Security mechanisms and A&M code.

Obfuscation may not be required if the MPoC SDK is executed in a physically separate execution environment, such as an SE or TEE, which provides physical security controls that mitigate access to the MPoC SDK code. Obfuscation reduces the efficacy of common code decompilation tools. Obfuscation methods may include, but are not limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, and symbol renaming, or protections provided by virtualized execution environments that are specifically designed to provide software-based protections to code execution flows (such as a vTEE). If the MPoC SDK is provided …

Removed p. 75

1B-1.7.a The tester must confirm through examination and observation that the MPoC SDK implements industry best practice with regard to the detection of compromised platforms and protection of MPoC SDK assets. This must include detection of rooting, as well as other methods that may be used to compromise the integrity and security of the execution environment, including the use of emulator systems.

Some MPoC platforms provide attestation functions that can be used by applications to assess the platform integrity. These mechanisms may be stronger than the ones provided by the MPoC SDK because they have insights into the platform. However, it may be possible to bypass them under certain circumstances. Understanding the limitation of these mechanisms and their proper implementation is essential for robust software hardening. Emulators facilitate the dynamic analysis of applications. The MPoC SDK is required to implement protections to help prevent its execution on these platforms to prevent …

Removed p. 76

1B-1.8.a The tester must confirm through examination and observation that the MPoC SDK implements methods to bind itself to the COTS device upon initial execution. It must not be possible for the bound MPoC SDK to operate on a different device or emulator platform, even if:

• Data (e.g., files) can be shared from the original COTS device to the cloned device.

• The second device is under attacker control.

After the MPoC SDK is installed, it goes through a process upon first execution to uniquely bind that MPoC SDK to the specific COTS device on which it is stored. The unique (configuration) data may also hold assets related to the merchant account or other operational data. The MPoC SDK is required to implement controls to prevent the extraction of data from the MPoC SDK such that it is not possible to create a “clone” of the MPoC SDK that is indistinguishable from …

Removed p. 77

1B-1.10.a The tester must confirm through examination and observation that there is no option to turn on developer or debugger mode.

Prior to the release of a software build, it is common for applications to include debug or developer features that expose data and functions that would be an unacceptable risk in production systems. Such code or features are required to be removed from the distributed software object, not just disabled, prior to distribution. However, this requirement does not imply or enforce the need for two code streams (a test stream, and a production stream). Removal of test or debug code during a build process may be an acceptable way to meet this requirement. Telemetry and data collection features may remain in an MPoC SDK for the purposes of collecting A&M data or validating the ongoing correctness of the solution. However, any remaining software features are not permitted to bypass or …

Removed p. 78

1B-1.11.a Through examination of the MPoC SDK implemented outside the REE, the tester must confirm that the exposed interface between this code and the REE is the minimum required to perform its task.

The MPoC SDK may implement functionality external to the REE of the COTS device using TEEs, SEs, or other separate execution environments such as external devices or servers. It is required that this non-REE code is protected against tampering, either to interfere with its intended execution process or to subvert or intercept interfaces between this code and the REE. Compliance to this requirement may be achieved through demonstration of previous evaluations, such as through EMVCo SBMP, GP, or similar schemes. Documentation needs to clearly include authenticatable evidence of such evaluation (i.e., a vendor assertion of evaluation or compliance is insufficient). The tester is expected to validate the scope of any previous testing to ensure that any gaps between …

Modified p. 78 → 5

~~1B-1.11.d The tester must~~ confirm ~~through examination~~ that any parts of the MPoC ~~SDK implemented~~ outside the REE are authenticated prior to execution.

Clarification or SR 1B-1.11 Added test requirement to confirm that any parts of the COTS-based MPoC Software which are executed outside of the REE are authenticated prior to execution.

Removed p. 80

Another way to protect cryptographic operations and sensitive assets is through software protections, such as software-protected cryptography, where the cryptographic functions and storage methods used to protect the cryptographic keys are obfuscated such that extraction of the sensitive assets or tracing of the execution flow of the cryptographic process is rendered computationally expensive. This includes systems such as white-box cryptography, and implementations where cryptographic operations are executed in a software-protected execution environment, such as a vTEE.

When purely software methods are used to protect cryptographic keys, such as with software-protected cryptography, the specific instance used in the MPoC SDK is to be changed periodically, where the maximum period is less than the estimated time it would take to reverse engineer the software protections. It is acceptable to have two sets of keys during the changeover period, but all old keys are to be invalidated when the new keys are installed. The …

Removed p. 81

1B-2.1 Cryptography protected with software-only means must be documented.

1B-2.1.a The tester must confirm through examination that the provided information is complete based on the tester’s understanding of the MPoC SDK. The information must include at a minimum:

• Which keys are secured using software- protected cryptography, in whole or in part.

• What algorithms are supported or implemented by the software-protected cryptography system used.

• How many instances of software-protected cryptography are present for each algorithm.

• The security mechanisms present in the software-protected cryptography.

• The key hierarchy of the keys protected by software-protected cryptography.

Clear information is required to outline how each cryptographic key is protected so that coverage can be confirmed to be comprehensive, and flaws can be identified easily. For this requirement, it is required that the information provided covers all cryptographic keys that would otherwise be exposed in cleartext within the memory of the REE of the COTS device were it …

Removed p. 82

1B-2.3.a The tester must confirm through examination and observation that the implementation of software protected cryptography within the MPoC SDK only implements the operations required.

Usually, cryptographic implementations support at least two operations (e.g., encryption and decryption). If the MPoC SDK needs only to encrypt data before sending it to the backend, the decryption operation is not required to be present in the MPoC SDK, since it helps reverse the encryption operation and may pose an additional security risk.

1B-2.4 The software-protected cryptography implementation, where it exists, must be replaced before the estimated time needed to break the implementation. Replacement must include changing of any cryptographic keys, or other assets, within the software protected cryptographic implementation.

1B-2.4.a the tester must document an estimated exploitation time needed for an expert attacker with physical access to the COTS device to break any software-protected cryptography implementations used.

The tester may use the results from the previous attack …

Removed p. 83

1B-2.6.a The tester must confirm through examination and observation that keys deployed through the software-protected cryptographic implementation are not used to encrypt account data or other secret/private cryptographic keys during transmission.

Cryptographic keys contained within a software-protected cryptography implementation during deployment may be used to protect keys during storage on the COTS Platform, or to help secure initial provisioning. However, as the keys used in these implementations may be shared across many MPoC Applications, it is not acceptable to rely on software-protected cryptography mechanisms to secure account data or other cryptographic keys during transmission outside of the COTS Platform on which the implementation resides.

1B-2.7 The software-protected cryptography must prevent the extraction of partial or complete cryptographic material to an attack rating of 25 points using the attack-costing framework in Appendix B.

1B-2.7.a The tester must confirm through examination, observation, and testing that the software-protected cryptography implementation is protected against known attacks against …

Removed p. 84

The security of any software-protected cryptography implementation is reliant upon periodic updates, which is validated in a separate requirement. The intent of this requirement is that the security of the software protected cryptography implementation is tested directly. Therefore, this testing is to be performed without additional security controls such as A&M or anti-rooting. The vendor of the MPoC Software or Software Protected Cryptography implementation may need to provide a test artifact for the testing process. Costing of the attack must consider the difficulty of disabling these features, and any code-lifting or emulation that is required as part of the attack. Code lifting can allow for the extraction of the software-protected cryptography implementation so that it can be executed in an environment or context under the control of an attacker. Usually, this is done for analysis of the cryptographic implementation and if, successful, can permit fault injections, oracle attacks, etc. A …

Removed p. 85

The attestation data may be determined in various ways, such as through a health-check interface that can be accessed by the prover. Attestation provides necessary assurance to the verifier that established and expected security controls at the prover are in an acceptable state and have not been tampered with. Organizations developing A&M components are subject to these requirements.

There are two types of attestations in MPoC Solutions, where the goal is to assess the integrity of the MPoC SDK and MPoC Application, and where the goal is to assess the integrity of the COTS platform.

It is a requirement of this standard that the attestation system and monitoring system together form the attestation and monitoring (A&M). The attestation and monitoring (A&M) includes a back-end system that can interpret and respond to the attestation results (i.e., the attestation results are required to be monitored). The MPoC SDK can attest to the COTS platform …

Removed p. 86

Security Requirements Test Requirements Guidance Objective: The attestation and monitoring (A&M) covers all assets and processing of the MPoC SDK and MPoC Application throughout its lifecycle.

1C-1.1 Documentation on the coverage of the attestation and monitoring (A&M) must exist.

1C-1.1.a The tester must confirm through examination that the required information exists, including, but not limited to:

• What checks are included in the MPoC SDK attestation and monitoring (A&M) and, if applicable, which parts of their result are checked or verified.

• What is covered by the checks (e.g., code, data, application, OS, cryptographic, etc.).

• When, where, and under which circumstances are these checks executed and validated.

• If a security mechanism covers code (e.g., checksums), which parts of the code are covered.

The attestation and monitoring (A&M) is a vital part of the overall security of an MPoC Solution and, therefore, the coverage provided by the attestation and monitoring (A&M) parts of the MPoC Software …

Removed p. 87

1C-1.3 The attestation and monitoring (A&M) checks must cover the entire security-sensitive MPoC SDK code and execution flows that handle assets.

1C-1.3.a The tester must confirm through examination that:

• The MPoC SDK is protected by the attestation and monitoring (A&M) at run-time.

• The A&M checks provide coverage over all MPoC SDK code, execution flow, and assets.

• Some A&M validation checks are always active during execution of the MPoC SDK providing protection against rooting, and activation of developer or other COTS operating modes that may impact security.

The A&M checks are required to be implemented at different execution points and be executed at different points in time to mitigate attempts to bypass or avoid the detection features. This helps to ensure that there is not a single point of failure for the A&M checks. A&M may involve different levels of checks. Some checks may be less intensive or involve call-back checks, such as …

Removed p. 88

1C-1.4.a The tester must confirm through examination that the A&M system covers the COTS OS and is able to verify its security state. Including validating, at least, the following information:

• If the COTS device is rooted, jailbroken, or operating in developer mode.

• Modifications or tampering attempt events of the MPoC SDK, MPoC Application and COTS execution environment.

• The version of the COTS OS, MPoC Application, and MPoC SDK, including detection of any rollback attempts.

• Details on the status of any COTS-native interfaces implemented by the MPoC SDK for account data collection.

• Details on the status of any COTS-native interfaces that may be used for account data collection, which are not implemented by the MPoC SDK.

The A&M is required to provide assurance that the MPoC SDK is not running on a compromised COTS platform (e.g., rooted, jailbroken, etc.). Although the MPoC SDK can use its own checks to perform this verification, …

Removed p. 90

Security Requirements Test Requirements Guidance Objective: Sufficient information is collected to detect and mitigate threats to the MPoC Solution.

1C-2.1 The information that is collected for attestation and monitoring purposes must be documented.

1C-2.1.a The tester must confirm through examination that the data collected for A&M purposes includes sufficient information to attest the COTS platform, MPoC Application, and MPoC SDK, and identify any attached devices.

Knowledge of the signals collected from the COTS device is needed to develop the A&M service properly and assess the quality of the A&M. This requirement includes information collected on the COTS device for A&M purposes and is not related directly to security checks (e.g., COTS device model, OS version, etc.). A&M data where the COTS device or MPoC SDK is the prover may be assignable to that COTS device based on the method of collection (i.e., the signals collected can only have come from that COTS device). …

Removed p. 91

1C-2.2.a The tester must confirm through examination and observation that the A&M data sent to the A&M backend reflects the current state of the MPoC SDK, MPoC Application, COTS platform, and peripheral devices, in addition to any security relevant changes or measurements that have occurred since the last communication to the A&M backend.

The measurements sent to the A&M backend are required to reflect the current state of the solution. Stale measurements may provide a false sense of security or be used by an attacker to replace more current data. However, an attacker may attempt to perform attacks during the window of time between communications to the A&M backend, so that their attacks go undetected. Therefore, in addition to ensuring the most current data, it is important that any security relevant A&M data is also transmitted to the backend when communication is performed.

1C-2.2.b The tester must confirm through examination and observation …

Removed p. 92

Security Requirements Test Requirements Guidance Objective: The A&M must be able to provide suitable responses to mitigate potential attacks.

1C-3.1 Documentation must exist that describes the actions that can be taken if the attestation and monitoring (A&M) indicates that the MPoC SDK, MPoC Application, or COTS platform is potentially compromised.

1C-3.1.a The tester must confirm through examination that the provided information is sufficient and consistent with the tester’s understanding of the solution.

The A&M system needs to implement actions when tampering of the MPoC SDK or MPoC Application is detected. Information outlining the functions provided by the attestation and monitoring (A&M) to indications of compromise is required. It is likely that the attestation and monitoring (A&M) backend is able to be configured to act in different ways and, where this is possible, the documentation needs to reflect how such configuration is managed securely. Common responses from the attestation and monitoring (A&M) include account …

Removed p. 93

1C-3.2.a The tester must confirm through examination and observation that the MPoC SDK is able to report any potential tampering events to the A&M backend.

A tamper attempt is detected by the MPoC SDK, it is required that the MPoC SDK informs the A&M backend. This can assist with the understanding of risk for similar types of solutions, as well as helping the A&M responses to be further tuned or developed to accommodate similar types of attacks. Additionally, as the MPoC SDK is considered to execute in a potentially hostile environment, communication of potential tamper events assists in aligning back-end responses with expected responses from the MPoC SDK. For example, if an MPoC SDK instance detects an attempted compromise and performs actions to halt payment processing, further payment processing from that instance received by the back-end system should be considered suspect.

1C-3.3 It must be possible for the MPoC SDK to disable …

Removed p. 94

1C-3.4.a The tester must confirm through examination and observation that the MPoC SDK prevents further payment processing after 60 minutes of continuous operation without a passing response from the A&M back-end component when not operating in offline payment acceptance mode.

When not operating in offline payment-processing mode, the MPoC SDK is required to receive communications from the A&M back-end component at least every hour to ensure that the MPoC Solution is operating securely and that the MPoC SDK has passed all attestation checks successfully. In the context of this requirement, a “passing response” from the A&M back-end component indicates that the A&M system has performed and validated all attestation checks required by the MPoC Software attestation policy. This requirement does not supersede any other requirements for consistent A&M monitoring or checks to be performed on execution or prior to specific functions such as PIN entry. This requirement does not replace requirement …

Removed p. 95

1C-3.6.a The tester must confirm through examination and observation that any A&M results that may require the cessation of payment acceptance are not communicated from the A&M backend to the payment processing backend through the COTS device.

A&M results that indicate that the payment acceptance must be halted are likely to result from a compromised COTS device or MPoC Application. This may impact the ability for the payment backend to receive accurate and correct data from the COTS device. This requirement does not prevent or preclude operational models that provide the MPoC SDK with explicit approval to perform payments on a per- transaction basis.

Removed p. 96

Security Requirements Test Requirements Guidance Objective: The attestation and monitoring (A&M), including the collection and transmission of data on the COTS device, is protected from compromise.

1C-4.1 The protections provided to the attestation and monitoring (A&M) must be documented.

1C-4.1.a The tester must confirm through examination that the information provided sufficiently details the anti-tamper protections that have been validated through the MPoC SDK testing process.

Modification of the attestation and monitoring (A&M) data or code may, in practice, allow for the bypass of the security mechanisms. The A&M component on the MPoC SDK needs to be protected against tampering. Documentation is required to indicate what protections are provided, so that these can be confirmed as in-place during the lab validation.

1C-4.2 A secure channel must not be relied upon as the sole protection for A&M data during transmission.

1C-4.2.a The tester must confirm through examination and observation that the data transmitted between the A&M functions …

Removed p. 97

1C-4.3.a The tester must confirm through examination and observation that the local time source is protected against tampering.

The time source used to track the local time is required to be reliable and trusted. The COTS platforms and MPoC Solutions may offer different options of measuring time. The MPoC SDK is required to select the option that reflects real elapsed time to enforce the time limits properly. For example, time may be provided by a PCI PTS SCRP during each transaction. In these cases, the tester is expected to validate that interaction with the PCI PTS SCRP is required for each transaction. Timers used for this purpose need to be monotonic, and clock sources, if used, need to prevent or log alteration by applications or users. If the clock value could be affected by, or altered during, sleep events or periods when the MPoC SDK is not executing, payment processing must …

Removed p. 98

1C-4.5.a The tester must test the MPoC SDK by attempting to tamper with the attestation system and the messages sent and received from the attestation and monitoring (A&M) backend.

The A&M plays the important role of communicating the security state of the COTS and PCI PTS SCRP devices to the backend and concentrating the security information of the MPoC SDK. A compromise of the attestation and monitoring (A&M) component on the COTS device or data transmitted to the backend may be the same as effectively disabling security checks. 1C-4.5.b If security mechanisms prevent the tampering, the tester must attempt to bypass the mechanisms. If it is not possible to bypass the mechanism, the tester must describe what would be needed to bypass the mechanism successfully (the expected actions/situations needed to bypass the mechanism).

1C-4.5.c The tester must provide a costing of this attack based on the method outlined in Appendix B. Attack …

Removed p. 99

Security Requirements Test Requirements Guidance Objective: Sufficient guidance and features are provided to allow for the secure integration and operation of the attestation and monitoring (A&M).

1C-5.1 A&M back-end operation security guidance information must exist that explains how the attestation and monitoring (A&M) is securely configured and operated.

1C-5.1.a The tester must confirm through examination that the attestation and monitoring (A&M) back-end operation security guidance contains the required information and comment on its sufficiency to securely configure the attestation and monitoring (A&M) backend according to the tester’s understanding of the MPoC Software. The documentation must include the following at a minimum:

• How to configure the attestation and monitoring (A&M), including the offline policy, securely.

• A base configuration for the attestation and monitoring (A&M).

• Specific integration requirements that must be fulfilled to integrate the attestation and monitoring (A&M) component securely.

This information is required even when the attestation and monitoring (A&M) is operated by …

Removed p. 100

1C-5.2.a The tester must confirm through examination that the security guidance includes at a minimum:

• How to deploy the A&M software component in a production-ready configuration (e.g., not debugging enabled).

• How to integrate the A&M software component into the MPoC Application.

• Specific dependencies of security checks on OS versions or COTS platforms.

Integration of the A&M functionality is required for all MPoC implementations. This security guidance may be a formal document for MPoC Software components that are to be operated by third parties, or internal knowledge base solutions for vendors performing all operations required of an MPoC Solution.

1C-5.3 Security guidance information must detail what A&M features are configurable, the processes for setting or changing these configurations, and how the applicable settings may affect the security and functionality of the overall MPoC Solution.

1C-5.3.a The tester must confirm through examination that the configuration options of the A&M are documented, including their possible settings.

An …

Removed p. 101

Only account data entry systems specifically addressed by this standard may be used within an MPoC Solution. Future updates to this standard may include or support other methods of account data entry.

1D-1 Account Data Entry and Encryption This Section covers the requirements for all COTS-native account data entry methods, and how this data must be secured as it is entered and processed. These requirements do not apply to data captured through a PCI PTS SCRP or non-PTS approved MSR device.

Security Requirements Test Requirements Guidance Objective: All account data entry methods are documented and provide encryption for onward processing 1D-1.1 Documentation must exist that details how account data is entered and secured.

1D-1.1.a For each of the account data entry methods supported by the solution, the tester must confirm through examination that the required information for integration with the MPoC SDK is present. The information must provide details about:

• All methods used …

Removed p. 102

1D-1.2.a The tester must confirm through examination that for any account data entry methods implemented on the COTS device, the card data is encrypted either immediately upon entry or immediately after any required processing through associated payment kernels.

Account data is required to be encrypted at the earliest to reduce the opportunity window in which account data can be compromised in cleartext. Normally, this is done in the external card reader itself or in the MPoC SDK when a COTS native interface, such as COTS-native NFC, is used. Although it is not the scope of this requirement to assess the encryption of any external account data capture systems, such as a PCI PTS SCRP or non-PTS approved MSR, the assessor is required to confirm that there is no functionality on the COTS device that would expect this data to be provided in cleartext or allow for the decryption of the account …

Removed p. 103

1D-1.5.a The tester must confirm through examination and observation that if any cryptographic keys related to account data encryption are exposed in the rich execution environment of the COTS device, those keys are implemented using a unique key per transaction key management method. Note: This requirement applies if the keys are ever exposed in cleartext, regardless of the operations or functions being performed at that time.

Although cryptographic keys related to account data security are required to never be stored in cleartext within the rich execution environment, these keys may be exposed in the rich execution environment as cleartext during cryptographic operations. Where this occurs, it is important that the increased risk of exposure of these keys is mitigated by ensuring that the keys are unique per transaction and implement perfect forward secrecy. There should not be sufficient information left within the MPoC SDK or COTS platform to decrypt the account …

Removed p. 104

1D-1.8.a The tester must confirm through examination and observation that the following events trigger a response that maintains the security of the card data entry process:

• Another application overlays the MPoC SDK.

• The MPoC SDK pauses or stops executing.

• The MPoC SDK loses its foreground focus.

The transaction process needs to be protected against manipulation or subversion. Attempts to modify or overlay the cardholder prompts (e.g., instructions to the cardholder) or other UI features that are important for the security of the solution are required to be prevented. Pausing the application usually means that the application remains partially visible while the user interacts with a different dialog or screen (e.g., in multi-screen mode). When the user switches to a different application, the application is considered “stopped” until either the user switches back or the system destroys the instance of the application. Although account data entered through external devices like a PCI …

Removed p. 105

1D-1.9.a The tester must confirm through examination and observation that account data is not stored on persistent storage, except for the purposes of offline payment processing.

Account data is permitted to be stored on the COTS device only for the purposes of offline payments. This includes storage where the account data may be protected through means such as encryption or storage in tamper-resistant processing elements. For the purposes of this requirement, “storage” refers to any non-volatile or long-term memory, such as Flash or RAM discs. Temporary storage of data within the memory of the COTS devices is permitted; however, any such storage needs to be cleared securely as soon as possible•no later than when the transaction has been sent for processing. Support for offline processing and associated data storage is not mandatory and may be conditional or disabled as required.

Removed p. 106

Security Requirements Test Requirements Guidance Objective: Secure card readers supported by the solution provide sufficient protection to account data.

1D-2.1 Information must exist that details the secure card readers used by the solution.

1D-2.1.a For each of the PCI PTS devices used in the solution, the tester must confirm through examination that the following information is provided at a minimum:

• Hardware, firmware, and listing details for each PCI PTS device used.

• Supported functionality of each secure card reader.

• All guidance required for the correct and approved operation of the used secure card reader.

Any PCI PTS devices used with the MPoC SDK need to have been assessed for the specific use implemented in the MPoC SDK. Use of functionality that has not been assessed presents a security risk to the MPoC SDK. The documentation provided by the MPoC Software vendor needs to contain all the necessary information to integrate the PCI PTS SCRP …

Removed p. 107

1D-2.4.a The tester must confirm through examination and observation that the back-end attestation and monitoring (A&M) component of the MPoC Software provides enablement tokens to the PCI PTS SCRP only after the PCI PTS SCRP has been validated successfully through an attestation process.

PCI PTS SCRP devices require a cryptographic token to be provided by the back-end system

• without such a token provided before a predefined time limit, the PCI PTS SCRP will cease to permit the acceptance of payment cards. These tokens help to mitigate the risk of a local compromise on a COTS payment system, by providing a “cut-off” for payment acceptance using the PCI PTS SCRP if a valid token is not provided. 1D-2.4.b The tester must confirm through examination and observation that a PCI PTS SCRP ceases the acceptance of account data if an updated enablement token is not received prior to the expiry of the previous …

Removed p. 108

Security Requirements Test Requirements Guidance Objective: Data from magnetic stripe cards is secured through approved readers.

1D-3.1 Documentation must exist that details the MSRs used by the solution.

1D-3.1.a For each of the devices used to accept magnetic stripe transactions in the solution, the tester must confirm through examination that details about the following are provided at a minimum:

• The hardware, firmware, and validation details for each MSR used.

• The supported functionality of each MSR.

• All guidance required for the correct and approved operation of the used MSRs.

Any MSR devices used with the MPoC SDK need to have been assessed for the specific use implemented in the MPoC SDK. Use of functionality that has not been assessed presents a security risk to the MPoC SDK. The documentation provided by the MPoC Software needs to contain all the necessary information to integrate any devices accepting magnetic stripe-based transactions securely into an MPoC Solution. …

Removed p. 109

1D-3.3.a The tester must confirm through examination that:

• Any MSR device(s) used are uniquely identified and validated by the attestation and monitoring (A&M).

• The firmware version of any MSR device(s) is verified by the attestation and monitoring (A&M).

• The state of the MSR device is verified by the attestation and monitoring (A&M).

• The MSR devices(s) are confirmed by the attestation and monitoring (A&M) to have no known or exploitable vulnerabilities.

The attestation and monitoring (A&M) needs to ensure that all aspects of the MPoC SDK are operating as expected and are not in a state that indicates or could facilitate compromise. This includes validating the state and security posture of any attached card-reading devices. Firmware in the context of this requirement may include operational code that is executed by an underlying processor, or the version of a dedicated ASIC used in place of a general-purpose processor.

1D-3.4 MSR data captured in an …

Removed p. 110

The contactless kernel has direct access to assets. Therefore, the processing, memory, and storage used by this kernel must be protected to prevent the assets from being compromised when handled by the payment kernel.

The requirements in this Section apply to the COTS-native NFC interface only.

Security Requirements Test Requirements Guidance Objective: Account data is protected and securely processed when it is read by the COTS-native NFC interface.

1D-4.1 Information that details the implementation of the COTS-native NFC acceptance method, including the implementation for any contactless kernels, must exist.

1D-4.1.a The tester must confirm the following through examination:

• That all COTS-native NFC acceptance methods are detailed.

• If part of the kernel is executed remotely (e.g., a cloud-based kernel), where and what parts of the kernel are included in this remote execution.

• How the kernel is configured and how the configuration is protected.

• How the kernel is secured against tampering.

Contactless kernels used by the MPoC …

Removed p. 111

1D-4.3.a The tester must confirm through examination and observation that the MPoC SDK implements mechanisms to prevent, monitor, or otherwise inhibit access to the COTS device camera(s) by other applications, during a payment transaction.

The camera can be used as a side-channel source to gain access to assets such as CVC/CVV. To prevent unauthorized visual capturing of account data from a payment instrument, such as a payment card, when it is in proximity to the COTS device, the MPoC Application should attempt to prevent other applications and processes running on the COTS device from using the camera. The expectation is that other applications on the COTS device are not able to use the camera when the MPoC application prompts the cardholder to initiate a contactless payment, or that access by another application during this time is detected and the payment transaction halted.

1D-4.4 Contactless kernels used in the MPoC SDK must be …

Removed p. 112

Security Requirements Test Requirements Guidance Objective: Account data entered into the COTS device through manual entry methods is secured.

1D-5.1 Documentation must exist that details the manual entry process and protection methods.

1D-5.1.a For each of the manual account data entry methods used in the solution, the tester must confirm through examination that details about the following are provided at a minimum:

• The ways in which the manual entry method can be invoked.

• The protections applied to the manual entry method.

• The types of account data that may be manually entered.

An MPoC SDK may support manual entry of the PAN, e.g., to enable payment processing if other card presentment modes fail (due to a damaged chip or magnetic stripe). Additional account data, such as the security code for the card, may be additionally required during such payment processing. It is important that any such methods of manual entry are detailed to allow …

Removed p. 113

1D-5.3.a The tester must confirm through examination and observation the following for each of the manual account data entry methods implemented:

• The entry methods do not allow the storage of the account data. This includes by the OS for purposes such as spell-checking dictionary creation.

• The account data is entered directly into the MPoC SDK. Third party keyboard or data entry applications are not used for account data entry.

• Entry modes do not use non-manual entry modes such as optical capture, through the COTS camera.

• It is not possible to take screenshots or recordings of the MPoC SDK during PAN entry on the COTS device into which the PAN is entered.

It is common in many COTS OS for the OS-provided data entry functions to store data entered so that it can build a dictionary of commonly used terms, for the purposes of enhancing spell-check functions. In addition, some OSs allow …

Removed p. 114

1E-1 COTS-native PIN Entry This Section covers the entry of cardholder PINs on the COTS device. When the PIN is entered on the COTS device, regardless of whether the PIN entry mechanisms are backed by hardware (e.g., TEE), the MPoC SDK is required to comply with this Section.

Security Requirements Test Requirements Guidance Objective: Cardholder PINs are protected as they are entered and processed on the COTS device.

1E-1.1 Documentation must exist that describes the secure capture and processing of the cardholder PIN.

1E-1.1.a The tester must confirm through examination that the information provided contains, but is not limited to:

• How the PIN is protected during entry and prior to encryption.

• How the PIN is encrypted.

• The security mechanisms implemented to prevent the extraction of the PIN at run-time.

• Side-channel prevention mechanisms.

• The types of PIN-verification method(s) supported (offline, online, or both).

An MPoC SDK that accepts account data entry, including PINs, on COTS …

Removed p. 115

1E-1.2.a The tester must confirm through examination and observation that PIN entry is supported only for transactions with chip-based cards.

Magnetic stripe cards do not provide the same security features present in chip-based cards and can be easily “cloned” or copied. An MPoC SDK that provides for the capture of both PIN and magnetic stripe track data for the same transaction are not permitted. This is true even if the track data is sent to the COTS device encrypted, from an attached SCRP or Non-PTS approved MSR because the data may be captured through a skimmer on the peripheral reader device itself.

1E-1.3 The MPoC SDK must not leak complete or partial PIN digits. The MPoC SDK must protect against side channels that use sensors present in the COTS device (e.g., accelerometers and gyroscopes) and screen capture.

1E-1.3.a The tester must confirm through examination that:

• The threat of extracting the PIN using the …

Removed p. 116

• The PIN is encrypted into an ISO format 4-PIN block upon entry, and in all cases prior to transmission outside of the boundary of the MPoC SDK.

• If the cryptographic keys used to encrypt the PIN block are exposed in the rich execution environment of the COTS device, the PIN block is encrypted using unique keys per transaction.

Methods that capture and encrypt the PIN in ways not compliant to ISO9564 can result in unforeseen risk being introduced into the PIN-processing system. ISO 9564 Format 4 uses AES and encapsulates the PIN and PAN into the PIN block using separate encryption processes. This separation of the encryption processes within an ISO format 4-PIN block allows for the PIN and PAN to be managed as separate items during the formatting of the PIN block (on the COTS device). Maintaining separation between the PIN and PAN can help increase the overall security …

Removed p. 117

1E-1.6.a The tester must confirm through examination and observation that attestation is performed prior to each PIN entry.

PIN entry is permitted only when the MPoC SDK is running in a secure state. It is important that these attestation functions be performed before the cardholder is prompted to enter PIN data. The MPoC SDK may have multiple levels of attestation and is required to have some level that is always active. Due to power and processing constraints, it may not be possible to have all attestation functions always active, and so execution of more complete attestation prior to PIN entry is required. Validation of attestation data is expected to be performed online for any online PIN entry process.

1E-1.6.b The tester must confirm through examination and observation that attestation and monitoring (A&M) validation is performed on the COTS device immediately prior to PIN entry.

1E-1.7 The MPoC SDK must detect when another application …

Removed p. 118

Depending on the type of transaction, different types of data may need to be stored on the COTS device for eventual transaction authorization. Types of data that may need to be stored and protected during an offline transaction includes account data and transaction results (cryptograms).

Offline PIN verification (with a contact chip card presented through a PCI PTS SCRP) may be used in either online or offline approval processes.

Assets stored for offline transactions must be protected according to their security needs. This Module covers additional security requirements that are needed to provide protection to these assets when stored on the COTS device. The protection of assets during the processing of a payment is covered by separate Modules.

Support for offline payment processing is not a required feature of an MPoC Solution and may not be possible in some payment solutions due to local or payment brand specific rules.

Removed p. 119

Security Requirements Test Requirements Guidance Objective: Offline transaction results and account data are protected.

1F-1.1 Stored assets, such as account data and transaction results, needed to process offline Payment transactions must be encrypted in such a way that the cleartext values cannot be recovered on the COTS device after encryption.

1F-1.1.a The tester must confirm through examination, observation, and testing that any assets, such as account data and transaction results, stored for offline transactions cannot be decrypted or recovered on the COTS device after encryption.

To prevent the recovery of cleartext sensitive assets, such data needs to be stored so that it is not recoverable on the COTS device. The requirement is required to be enforced cryptographically through the use of keys that are securely removed from the COTS device immediately after encryption or using an approved asymmetric cryptography algorithm as described in Appendix C: Minimum and Equivalent Key Sizes and Strengths for …

Removed p. 120

1F-1.2.a The tester must confirm through examination and observation that the MPoC Software is able to detect the deletion or modification of offline transaction data.

Offline transactions are communicated to the payment backend as required. Prior to transmission, there is an opportunity window to delete or modify transaction data. This may prevent the transaction from being acknowledged by the payment backend, alter the amount or parties involved in the transaction, or change the outcome of transaction processing decisions. Detection of the deletion may occur by the MPoC SDK directly, or by some other (backend) aspect of the MPoC Software. Attempts to attack offline payment processing by deleting the MPoC Software from the COTS device is covered by a different requirement.

1F-1.2.b The tester must perform testing on the MPoC Software by performing offline transactions, deleting and modifying transaction data from the COTS device, and verifying that:

• The MPoC Software is able to …

Modified p. 120 → 5

~~1F-1.3 The offline Payment~~ transaction data ~~must be~~ deleted once it has been transmitted to the payment backend.

Evolving requirement SR 1B-1.13 Added new requirement to ensure payment transaction data is securely deleted from the COTS device once the data has been transmitted to the payment backend.

Removed p. 121

1F-1.4.a The tester must confirm through examination and observation that any further transaction processing is prevented when the MPoC Software has been operating in offline mode for more than 48 hours.

Attackers may attempt to exploit offline processing to process multiple transactions that would otherwise be rejected if processed online. To reduce this risk, offline processing systems need to prevent further processing if they are prevented from connecting to the back-end system. The back-end payment-processing systems may be different to the back-end A&M processing systems. MPoC Software implementing offline payment processing need to achieve connectivity to the A&M backend at least every 24 hours. The A&M connectivity requirement is different from this requirement and tested separately. This requirement is to halt payment processing once offline payment processing has been enabled for more than 48 hours.

1F-1.5 Data stored for offline transaction processing must not be accessible to other applications.

1F-1.5.a The tester must …

Removed p. 122

Security Requirements Test Requirements Guidance Objective: The MPoC SDK can securely operate and attest its environment during periods where connection to the A&M backend is lost.

1F-2.1 The initiation of the offline mode must not be available immediately after COTS device reboot. The MPoC SDK must work offline only after being connected to the A&M backend.

1F-2.1.a The tester must confirm through examination and observation that it is not possible to perform offline transactions if the A&M and payment-processing servers have not been contacted after a reboot of the COTS device.

The MPoC SDK cannot start in offline mode from a reboot state without first contacting the server. This helps mitigate attacks when the timer is manipulated by rebooting the COTS device or when the firmware is modified since the last contact with the A&M server. Validation of the local time as indicated by the COTS device during reconnections may be used as …

Removed p. 123

1F-2.3.a The tester must confirm through examination and observation that the A&M backend implements controls to mitigate attacks attempting to delete the MPoC SDK, or MPoC Application, during offline processing.

An attacker may attempt to delete the MPoC SDK, or MPoC Application, from a COTS device during offline processing, so that any stored transactions are lost. Although this cannot be prevented, the A&M backend is required to track offline use in attempts to identify such abuse. For example, a system may flag merchants or COTS device instances where offline processing is enabled and the next appearance of that merchant or system is a new installation.

1F-2.4 The MPoC SDK must disable payment acceptance after 24 hours without receiving a response from the A&M back-end allowing for the continued processing of transactions.

1F-2.4.a The tester must confirm through examination and observation that the MPoC SDK must disable processing after 24 hours without a response …

Removed p. 124

This Module applies in all cases to MPoC Software that is to be separately listed as an MPoC Product. This Module additionally applies to solutions that separate the MPoC functionality from other parts of an MPoC Application, including those where the MPoC Solution Provider and the MPoC Application vendor are the same organization.

Monolithic MPoC Solutions are exempt from this Module as they do not use an MPoC SDK, and do not outsource the operation of their Attestation and Monitoring services.

1G-1 Security Guidance The security guidance of a component is a document that defines the purpose and usage of the component, the security claims of the component, the component dependencies, and contains the required information to integrate and use the component in a secure manner.

Security Requirements Test Requirements Guidance Objective: The MPoC Software is provided with documentation that allows for secure integration and use within a complete MPoC Solution.

1G-1.1 The MPoC …

Removed p. 125

1G-1.4 The MPoC Software security guidance document must define an explicit MPoC SDK boundary.

1G-1.4.a The tester must confirm through examination that the security guidance document includes an explicit MPoC SDK boundary.

Clear documentation over the boundaries of the MPoC SDK is needed to scope the functionality of the MPoC Software properly and assess the evaluated components. The boundary has to include any hardware (e.g., PCI PTS SCRP, SE) that performs, or software that implements, any of the MPoC SDK-designated security functionalities. The MPoC SDK boundary needs to define how account data is input to the MPoC SDK, and how A&M and control signals pass between the MPoC SDK and other components of the Solution. Although interfaces such as the COTS-native NFC reader or touch screen are not part of the MPoC SDK boundary, it is required that they be considered part of any account data input methods into the MPoC SDK.

1G-1.4.b …

Removed p. 125

Clear documentation about how updates to the MPoC Software and its configuration can be made is vital. Because the MPoC Software is designed for integration into other components of an MPoC Solution, updates may require specific processes or prerequisites. When an MPoC Software makes assumptions about the source or protections provided to updates, this needs to be clearly detailed in the security guidance documentation. Updates covered by this guidance includes data such as configuration for EMV kernels.

Removed p. 126

1G-1.6.a The tester must confirm through examination that the MPoC Software security guidance documentation indicates how often any software-protected cryptography implementations must be updated. This time period must be no more than the minimum period included as part of the testing of the software-protected cryptography.

An important part of the security posture of any software- protected cryptography is the ability to provide regular updates. Any implementation of an MPoC SDK using a software-protected cryptography needs to ensure that it complies with this update process, which starts with providing this information in the MPoC Software security guidance documentation.

1G-1.7 The MPoC Software security guidance document must list all assets that cross the boundary of the MPoC SDK and the expected protection that the integrator of the MPoC SDK must provide to these assets.

It is important that the expectations of the MPoC SDK regarding protecting assets are understood for the integrator and the laboratory …

Removed p. 127

The MPoC SDK is permitted to be used only on platforms that have been validated to provide the necessary security and functional aspects required. The integrator needs to limit the use of the MPoC SDK only to platforms where the MPoC SDK can be used securely. Sufficient granularity should be provided so that an integrator of the MPoC Software Product is able to know which platforms to target for their MPoC Application. This information must be kept current as changes in the supported COTS platforms occur over time.

1G-1.10 If the attestation needs an interaction from the MPoC Application, the MPoC Software security guidance document must define the scope, dependencies, and actors of an attestation policy that is used by the MPoC Solution.

MPoC SDK functionality may need interactions with the MPoC Application that are not functional, but which are needed for security. These interactions are required to be documented properly such …

Removed p. 128

An MPoC Solution may have more than one MPoC Application listed as part of that MPoC Solution listing.

Further details on the different types of MPoC Applications can be found in Section: MPoC SDKs and MPoC Applications. Details on the applicability of the various Domains and requirements of this standard can be found in Section: MPoC Domain and Section Applicability. Details on the process and requirements for MPoC listings can be found in the MPoC Program Guide.

Module 2A: MPoC Software Integration This Module covers the integration of one or more MPoC SDKs, which are part of listed MPoC Software Products, into an MPoC Application. Any one MPoC Application is not permitted to integrate more than two MPoC SDKs. An MPoC Application that integrates both an Isolating and non-Isolating MPoC SDK, is assessed against requirement as they apply to the integration of a non-Isolating MPoC SDK.

Note: This Module is applicable for MPoC …

Removed p. 129

2A-1.2.a The tester must confirm through examination and observation that the MPoC Application vendor has integrated the MPoC SDK in accordance with the MPoC Software security guidance.

An MPoC SDK provides various security services and functions to assist with the overall compliance of the MPoC Solution. To ensure correct and secure operation the MPoC SDK needs to be integrated and used as intended. An MPoC SDK may rely on the MPoC Application to provide a deployment configuration to be used securely. The MPoC Application vendor needs to follow the requirements from the MPoC SDK security guidance (e.g., on the use of configuration flags, APIs, and protection mechanisms to be applied to the final integrated MPoC Application).

2A-1.3 The MPoC Application integrating the MPoC SDK must not bypass, circumvent, reimplement, or modify any of the security or operational features provided by the MPoC SDK.

2A-1.3.a The tester must confirm through examination and observation that …

Removed p. 130

2A-1.5.a The tester must confirm through examination and observation that the MPoC Application vendor has integrated the MPoC Software A&M functions as required in the MPoC Software security guidance document.

The MPoC Application is the method by which the MPoC SDK functions are delivered to the merchant. Compromise of an MPoC Application may prevent or alter the secure operation of the MPoC Solution, and so the security of the MPoC Application must be evaluated as part of the attestation and monitoring process. Attestation functions provided by the MPoC SDK may require specific integration steps or interactions with the MPoC Application. For example, specific triggers or data points to support the secure operation of the attestation functions may be required within the MPoC Application. These interactions are required to have been documented properly as part of the MPoC SDK validation. The process that this documentation outlines needs to be followed to ensure …

Removed p. 131

2A-1.7.a The tester must confirm through examination and observation that the MPoC Application does not implement or allow for the decryption of sensitive assets encrypted by the MPoC SDK.

During assessment to Domain 1, it is established that the MPoC SDK only outputs sensitive assets when that data is appropriately protected (e.g., through the use of encryption). It is important that the MPoC Application does not attempt to bypass this security, by implementing decryption functions to recover the cleartext sensitive assets.

2A-1.8 The MPoC Application does not share assets between different MPoC SDKs.

2A-1.8.a Where more than one MPoC SDK is integrated into an MPoC Application, the tester must confirm through examination and observation that assets are not shared between the different MPoC SDKs.

An MPoC Application may integrate up to two MPoC SDKs. However, in cases where this is done the MPoC SDKs must continue to operate independently of each other, even if …

Removed p. 132

The MPoC Software security guidance, and MPoC Software listing, details if an MPoC SDK is an Isolating SDK or non-Isolating SDK.

2B-1 MPoC Application Security MPoC Applications that may be able to access MPoC SDK assets must be developed in line with security best practices for COTS device applications.

Security Requirements Test Requirements Guidance Objective: MPoC Applications that could have access to assets are developed in line with security best practice.

2B-1.1 All software in the MPoC Application must be either:

• Developed by a PCI SLC Qualified Software Vendor

2B-1.1.a When the software is developed by a PCI Secure SLC-approved software vendor, the tester must confirm through examination that the entity is listed on the PCI website and is valid at the time of evaluation (i.e., the listing has not expired).

A non-Isolating SDK has not been validated to provide sufficient protection to its assets. Compromise of an MPoC Application that integrates a non-Isolated SDK …

Removed p. 133

2B-1.2.a The tester must confirm through testing that the modification (including application rollback) is detected by the MPoC Application and it is not possible to perform transactions. If the modification is detected, the tester must attempt to bypass (i.e., disable or remove) the tamper detection code.

The MPoC Application installable package needs to have its authenticity protected. This is normally a task that the MPoC Software cannot perform, as it has no visibility on the integration part of the MPoC Application. The MPoC Application binary code is required to be resistant against tampering. The MPoC Application is required to implement controls to prevent modification of the MPoC Application installed on the COTS device, including its configuration files, and binary code. The MPoC Solution needs to prevent older and possibly vulnerable versions of the MPoC Application from running. The version allowed to be used is controlled by the MPoC A&M backend, and …

Removed p. 134

Module 3A: MPoC Software Security Guidance Compliance This Module covers the deployment and configuration of a certified attestation and monitoring software into the backend.

Note: This Module is applicable for composite solutions only.

3A-1 Deployment and Configuration of Back-end Systems An MPoC Software product, when used, must be securely and correctly integrated into an overall MPoC Solution. This integration must follow the guidance provided by the MPoC Solution provider, as well as ensuring requirements of this standard are met for the integrated system.

Security Requirements Test Requirements Guidance Objective: MPoC Software back-end systems, when used, are securely and correctly deployed and configured.

3A-1.1 When an MPoC Software product is used, the MPoC Software product must be listed on the PCI SSC website.

3A-1.1.a The tester must confirm through examination and observation that the version of the MPoC Software used by the Attestation and Monitoring Service provider is PCI approved.

MPoC Solutions need to be evaluated in …

Removed p. 135

3A-1.4.a The tester must confirm through examination that the back-end A&Ms supports secure updates according to the MPoC Software security guidance document.

The MPoC Software may be developed by an entity different to that which deploys and operates the back-end attestation system and back-end monitoring system. Even where the same entity develops and operates the back- end systems, there may be separate teams or resources used for each. To ensure that back-end systems remain up to date, the attestation monitoring service provider needs to have processes in place to monitor published updates and releases. Although newly developed systems may not yet have a need to implement updates, the need to continually monitor for such need remains. It is also expected that any A&M service provider will need to implement updates frequently to maintain the currency and security posture of their systems, and therefore even newly developed systems will require updates within …

Removed p. 136

Note: This Module is applicable to all A&M service providers, and/or monolithic MPoC Solution providers.

3B-1 COTS Platform Baseline and Vulnerability Management The COTS platform baseline represents the COTS platforms (including both the physical device and the operating systems used) that are considered to provide sufficient security and features to allow for the installation and execution of the MPoC Application for the purposes of accepting payment transactions. This baseline must be managed as new security flaws, as well as updated and more secure versions of COTS platforms, are released.

Security Requirements Test Requirements Guidance Objective: The defined COTS platform baseline is kept up to date with developments and changes to COTS platforms.

3B-1.1 A COTS platform baseline must exist.

3B-1.1.a The tester must confirm through examination and observation that a COTS platform baseline exists and is validated by the A&M.

The COTS platform baseline outlines the COTS platforms on which the MPoC Application may execute …

Removed p. 137

3B-1.2.a The tester must confirm through examination that the COTS platform baseline procedure exists. The tester must examine the procedure to verify that it contains at a minimum:

• Roles and Responsibilities (e.g., who is allowed to update the COTS platform baseline).

• The acceptance process and criteria for adding COTS platforms to the COTS platform baseline (see next requirement).

• How COTS platforms are added to the COTS platform baseline.

• How decisions are made to remove previously acceptable COTS platforms from the COTS platform baseline. This must include a reference to the vulnerability management process.

• How affected entities are informed of changes to the COTS platform baseline that will affect them.

The COTS platform baseline is not static and will change over time. Therefore, a procedure is required be in place to manage the existing baseline with respect to risks to the solution. There needs to be a clear process for accepting platforms …

Removed p. 138

3B-1.2.d The tester must confirm through observation and interview that the COTS platform baseline procedure is actually executed. The required evidence is an overview of changes to the COTS platform baseline. This must include a description of the changes, related change management tickets and communication to affected merchants.

3B-1.3 The baseline COTS OS must be regularly and frequently reviewed for vulnerabilities.

3B-1.3.a The tester must confirm through examination, observation, and interview that vulnerabilities in the COTS OS are analyzed periodically and assessed known and unknown vulnerabilities.

It is intended that the vendor identifies the vulnerabilities that affect the system baseline. It is expected that not all platform vulnerabilities will result in risk to MPoC Solutions, but a process to determine if this is the case needs to be implemented. It is not sufficient for vulnerabilities to be dismissed without appropriate research and testing. Not all vulnerabilities that affect platforms within the COTS baseline …

Removed p. 139

CVE for all supported platforms (in addition to other measures to identify unknown vulnerabilities), or it may instead be implemented through a combination of focused review of known vulnerabilities and robust periodic testing. For example, use of regular and focused penetration testing by mobile security experts instead of review of each individual CVE may be sufficient if (i) the testing is able to show the efficacy of the security mechanisms, (ii) there remains a continuous monitoring of the security landscape in between penetration tests.

3B-1.4 Personnel involved in maintaining the operation of the A&M must be appropriately skilled.

3B-1.4.a The tester must confirm through examination, observation, and interview that the personnel involved with the operation of the A&M are appropriately skilled. This must include personnel skilled with the security of the COTS platforms used in the baseline.

The A&Ms are a combination of automated and manual features. Although the A&M software may be …

Removed p. 140

3C-1 Attestation and Monitoring Policy The attestation and monitoring system policy defines what data types are collected during the attestation process, and how this data is to be interpreted and managed through the attestation and monitoring components of the MPoC Software.

Security Requirements Test Requirements Guidance Objective: The COTS devices used provide a secure and trustworthy execution environment.

3C-1.1 A documented attestation policy must exist and be demonstrably in use.

3C-1.1.a The tester must confirm through examination that an attestation policy exists and includes the following topics at a minimum:

• Roles and responsibilities.

• Data collected during attestation.

• Risk rating of attestation data.

• Follow-up actions and time frames when attestation data seem to suggest a tampered component.

• References to specific procedures and/or work instructions.

The attestation policy outlines what the requirements are to ensure that any COTS device executing the MPoC Software provides a secure execution environment for the MPoC Software. The attestation policy differs …

Removed p. 141

3C-1.2.a The tester must confirm through examination that an Offline Attestation Policy exists and it includes at a minimum:

• Checks are enabled when operating in offline mode.

• The responses when a security check is triggered.

• Requirements for escalation are noted when offline transaction processing violates the requirements of Section 1F.

Attestation and monitoring functions provided to MPoC Solutions that allow for offline transactions need to account for the potential operation of those systems while they are disconnected from the A&M back-end systems. Section 1F of this standard details requirements for the MPoC Software when operating in offline mode. This includes preventing offline acceptance for more than 48 hours, requiring online attestation to be performed prior to enablement of offline mode, as well as other requirements. It is important that the offline A&M policy outlines the escalation path required if any of these functions of the MPoC Software are found to have …

Removed p. 142

Security Requirements Test Requirements Guidance Objective: Attestation data is analyzed, and signs of potential attack are consistently responded to in a way that maintains the security and integrity of the MPoC Solution.

3C-2.1 There must be an overview of the MPoC Solution being monitored.

3C-2.1.a The tester must confirm through examination that a list of all components that are included in the monitoring process exists and contains references to how these are integrated into the A&M. This is required to include at least:

• The platforms supported and operated

• MPoC Application and MPoC SDK (if used)

• Any attached card reading devices A clear and thorough understanding of the components used in the solution, and how they are being monitored, is vital. This includes the identification of both OS versions, and COTS device types, as the security posture of each individual platform may have an impact on the security of payment processing. For example, …

Removed p. 143

3C-2.2.a The tester must confirm through examination that monitoring procedures exist and that they contain the necessary information. The monitoring procedure needs to include at a minimum the following topics:

• Definition of possible events (warning alerts, errors, etc.) from the monitoring system.

• How specific events are processed.

• How undocumented, unexpected, and unknown events are handled.

• When and how events are escalated and when the incident management process is initiated.

• How it is ensured that personnel are qualified to handle events.

• References to work instructions for the actual MPoC Software used.

This requirement ensures common understanding for those involved in the monitoring of the solution. The monitoring process may include both manual and automated aspects.

3C-2.2.b The tester must confirm through observation and interview that the monitoring procedures are actually executed. The required evidence is an overview of events that have been managed. Information about events must include date, time, description, and follow …

Removed p. 144

3C-2.3.a The tester must confirm through examination and observation that the A&M provides for an indication of A&M results to the payment processing backend.

The A&M provides “health” checks of the COTS platform and MPoC Application to ensure the secure operation of the MPoC Solution. When the attestation and monitoring (A&M) checks indicate that there may be a problem with any MPoC Application or COTS platform, the A&M provides that information to the payment processing backend so that the continued operation of that specific MPoC Application can be determined. In cases where there is sufficient information indicating that the MPoC Application is at risk of compromise, the payment processing backend needs to be informed so that payment processing for that MPoC Application can be stopped. Due to the risk of compromise and interception on the COTS platform, signals that may indicate risk of compromise of the MPoC Application or COTS platform …

Removed p. 145

3D-1 Operational Management This Section covers the operational management of the A&M solution.

Security Requirements Test Requirements Guidance Objective: A&M assets processed in back-end environments are secured according to their protection types.

3D-1.1 When account data is stored, processed, and/or transmitted through the A&M back-end systems, that environment must be compliant to the requirements of PCI DSS DESV.

3D-1.1.a When account data is stored, processed, or transmitted through the A&M back-end systems, the tester must confirm through examination that the environment is compliant to the requirements of PCI DSS DESV.

All systems that store, process, and/or transmit account data need to be compliant to the requirements of PCI DSS. As attestation and monitoring systems are also used to control and manage the security of the COTS payment acceptance systems, additional controls are required for any A&M environment that is not sufficiently isolated from the cardholder data environment. These requirements apply in form of PCI …

Removed p. 146

3D-1.2.a The tester must confirm through examination, observation, and interview that account data is not stored, processed, or transmitted through the back-end A&Ms, and that the A&Ms are sufficiently isolated from any such account data processing systems.

When the back-end A&Ms are isolated sufficiently from the cardholder data environment, which is used to process account data, it is not a requirement that the A&M systems also be compliant to PCI DSS. However, security controls are still required in the attestation and monitoring (A&M) environment, so assessment must be made against the requirements provided in the Appendix A: Back-end Environment Security Requirements. Although not PCI DSS, it is expected that assessment to Appendix A is performed with appropriately skilled and experienced individuals. On-site assessment is to be included where appropriate with consideration for any remote assessment guidance that may also exist. Appropriate separation may include isolation through networking controls to prevent the …

Removed p. 147

Module 4A: Software Management This Module contains the requirements for the secure operation and management of the software used in an MPoC Solution. This includes any MPoC SDK, A&M Software, and MPoC Application(s).

4A-1 COTS Software Distribution and Updates Software that is to be installed and executed on the COTS device for an MPoC Solution needs to be compliant to this Section. This includes the MPoC Application that integrates the MPoC SDK, or the MPoC SDK itself if it is instantiated and distributed as a stand- alone MPoC Application. Unlike Domain 2 of this standard, which covers the development and software of the MPoC Application, this Section covers the operational aspects of distributing and maintaining an MPoC Application. This includes any ongoing key management requirements, as well as the requirements for the secure distribution of the MPoC Application(s).

These requirements do not dictate any specific type of distribution method for the MPoC …

Removed p. 148

4A-1.1 Information about how software is provisioned securely to the supported COTS devices must exist.

4A-1.1.a The tester must confirm through examination that the information provided includes at a minimum:

• The supported MPoC Application distribution methods.

• How the MPoC Application distribution methods supported are protected. How access to MPoC Application distribution methods is protected (for the purposes of uploading or changing security sensitive settings).

• How the data provisioned after the MPoC Application is installed and the purpose of that data. This includes executable files and configuration files.

The protection of the MPoC Application during the provisioning lifecycle stage is needed to prevent the distribution of a malicious MPoC Application. Documentation covering the MPoC Application distribution, and provisioning helps to identify vulnerabilities in this stage of the MPoC Software lifecycle. The MPoC Application distribution method may include the OS store of the COTS device, or an MDM solution. Regardless of what method is …

Removed p. 149

4A-1.2.a The tester must confirm through examination and observation that it is not possible to perform transactions on an MPoC Application loaded onto the COTS device through means other than the defined COTS application distribution methods.

The authenticity of the MPoC Application is a paramount concern in securing account data. Loading of applications from the OS store provides a level of confidence that the application has not been tampered with before being installed on the merchant COTS device. In some OSs, it is possible to perform “side-loading” of applications

• that is, install them separate to the normal application distribution methods and controls

• at any time by configuring the COTS device to allow for this process. In other OSs, it may be necessary to establish a developer account or perform some other actions on the COTS device to allow for loading of applications outside the distribution store formally supported by the MPoC …

Removed p. 150

4A-1.4.a The tester must confirm through examination and observation that all the methods supported for distribute the MPoC Application provide authenticity prior to initial execution.

Only authentic MPoC Applications are permitted to be installed and operated as part of an MPoC Solution. The authenticity at installation time needs to be provided by the MPoC application defined distribution method and/or COTS platform, before the MPoC Application is executed for the first time following installation or updating. COTS platforms that do not allow for the use of a COTS application distribution method that can provide authenticity to the MPoC Application at installation time are not suitable for use with an MPoC Solution. The minimum requirements for the COTS platform baseline

• including the need to support validation of a digital signature across MPoC Applications that are loaded onto the device

• is covered in requirement 3B-x. Some COTS platforms may support multiple signature types or …

Removed p. 151

4A-1.5.a The tester must confirm through examination and observation that the MPoC Application implements methods to permit the merchant to validate the authenticity of the MPoC Application.

The defined COTS application distribution method may not guarantee that the application that is provided is genuine, instead simply providing confirmation that it did indeed come from the COTS application distribution method used. Therefore, the merchant needs to be able to separately validate the authenticity of the MPoC Application. Some COTS Platforms may support self-signed certificates, and it is not a requirement for a signature to chain up to an authorized Certificate Authority. Because of this, it is necessary that the merchant is able to separately validate that the MPoC Application they have downloaded is not just a valid application, but is the MPoC Application they intended to download and use for payment acceptance. This requirement is intended to help secure MPoC Solutions against …

Removed p. 152

4A-1.6.a The tester must confirm through examination that the MPoC Application vendor provides secure updates of the MPoC SDK according to the MPoC Software security guidance document. Note: This requirement is concerned with the operational process of communicating and delivering updates, not with the technical process of maintaining and updating MPoC Software.

The MPoC SDK may be developed by an entity different than that which develops and maintains the MPoC Application. Even if the same entity produces both the MPoC Software and the MPoC Application, there may be separate teams or resources used for each. In such scenarios, it is possible that the MPoC SDK has an update process and timing that are dislocated from that of the MPoC Application. The MPoC Software vendor is required to keep MPoC Application vendors informed of releases and changelogs as part of their validation and listing. MPoC Application vendors are required, on their part, …

Removed p. 153

Security Requirements Test Requirements Guidance Objective: Cryptographic keys and certificates are managed securely throughout their complete lifecycle.

4A-2.1 Procedures to generate, distribute, revoke, and renew keys and certificates must follow the MPoC Software security guidance and be demonstrably in use.

4A-2.1.a The tester must confirm through examination, observation, and interview, that procedures for the generation, revocation, and renewing of keys and certificates follow the MPoC Software security guidance and are demonstrably in use. The procedures must, at a minimum, include the following topics:

• Relation to incident management processes.

• Assessment of impact of key replacement (replacement of a root CA key will have more impact than a device specific key).

• Communication to stakeholders.

• Work instructions about how to actually revoke and renew specific keys and certificates.

The MPoC Software implements cryptography for various controls, and this implementation is assessed under the requirements of Domain 1. However, to ensure the security of the MPoC Solution, …

Removed p. 154

4A-2.2.a The tester must confirm through examination and observation that cleartext secret or private cryptographic keys in the back-end environments are stored and processed only in HSMs compliant to FIPS140-2/3 level 3 (or above), or PCI HSM requirements.

Cryptographic keys need to be protected to prevent unauthorized or unnecessary access that could result in the exposure of encrypted data. Secret or private cryptographic keys need to be stored in an encrypted form or within an SCD, such as an HSM. This requirement applies to all keys used to encrypt PINs and other account data, as well as cryptographic keys used to secure attestation data. The requirement for HSM use does not apply to cryptographic keys used for the establishment and security of secure channels, such as TLS keys. Cryptographic keys used for signing MPoC Applications, or that are used for creating software protected cryptography implementations, are also out of scope of …

Removed p. 155

4A-2.4.a The tester must confirm through examination and interview that cryptographic keys are generated and managed by the Cloud HSM user, and not accessible to the Cloud HSM service provider.

Cloud service providers offer different ways to manage HSM keys. In general, three options are supported:

• Keys are generated and managed by the Cloud service provider. Depending on the HSM type, this could even mean that HSM keys are shared with other customers.

• Keys are generated and managed by the Cloud HSM user, but within the cloud environment. The keys are not shared with other customers, but security depends on the Cloud service providers’ configuration.

• Keys are generated by the Cloud HSM user in their own premises and the transferred securely to the Cloud service provider. Some Cloud HSM systems use the HSM only for storage of keys and allow for export of keys for cryptographic operations. These types of Cloud …

Removed p. 156

4A-2.6.a The tester must confirm through examination, observation, and interview that all keys in the solution have their integrity and authenticity protected.

Cryptographic keys are to be protected against unauthorized or unintentional change. For example, this can be achieved by:

• Implementing cryptographic controls such as key blocks. Key blocks may be implemented entirely in the back-end systems, or in concert with the MPoC SDK (refer requirements in 1A-x).

• Implementing key check value or key fingerprint verification processes.

• Managing public keys in certificates.

4A-2.7 Management of secret and private cryptographic keys must implement the principles of dual control and split knowledge.

4A-2.7.a The tester must confirm through examination, observation, and interview that dual control and split knowledge are implemented in the organization to manage secret and private cryptographic keys.

Split knowledge requires that no individual has any information about any part, even a single bit, of the cleartext key. Dual control requires at least two …

Removed p. 157

4A-2.8.a The tester must confirm through examination and observation that a revocation mechanism exists and is effective in preventing the use of revoked and/or certificates.

Expired certificates can introduce unacceptable risk to the solution. Payment functions are required to be halted when certificates that are relied upon have expired or are otherwise detected as no longer valid. Expired certificates may be an indication of a malicious user acting as an imposter of a legitimate organization or process who is phishing for sensitive information. Many security incidents are caused by expired or revoked certificates. While understanding of the keys used is important and collected in the key/certificate tables, it is equally important to have procedures to act upon if any key expires or is suspected of being compromised. The requirement is applicable to all components of the solution and includes only the certificates upon which the solution relies for security purpose.

Removed p. 158

Security Requirements Test Requirements Guidance Objective: Back-end environments cannot be compromised from within an authenticated MPoC Application session.

4A-3.1 A penetration test must be performed on the interfaces between the MPoC Application or MPoC SDK, and back-end environments (e.g., A&M, payment processing and/or remote kernel) prior to the validation and listing of an MPoC Solution or A&M service provider, and at least once per year thereafter.

4A-3.1.a The tester must confirm through examination that a penetration test has been performed on the interfaces between the MPoC Application, or an MPoC SDK in a suitable test application, and back-end environments prior to initial deployment, and at least annually thereafter. Penetration testing reports must be examined to confirm that the scope covers all aspects of the MPoC Solution, or A&Ms, and that any major vulnerabilities found during the penetration testing have been remediated.

Removed p. 159

4A-3.2.a The tester must confirm through examination that a vulnerability-reporting program exists for the system, and there is evidence of accepting and remediating security vulnerabilities found through this program.

Penetration testing and vulnerability management processes are expected to be part of any secure software lifecycle process. This requirement confirms the scope and efficacy of the penetration testing as it is applied to a complete MPoC Solution or an A&M service provider, as it has integrated and operates the MPoC Software. A penetration test is considered to be a clearly scoped and deliberately engaged activity performed on behalf of the MPoC Solution provider, or A&M service provider. This differs from the ad hoc testing that may be performed as part of a vulnerability management or flaw reporting program. Penetration tests need to be performed by suitably skilled resources and may be performed by resources internal to the entity if such resources exist. …

Removed p. 160

Where the payment-processing and PIN processing are not performed by the MPoC Solution Provider those aspects may be considered out of scope of the assessment. Only those aspects that are included

•e.g., a payment switch operated by the MPoC Solution provider

•are to be included in the assessment of this Domain. However, it is not possible for an MPoC Solution that allows for PIN entry on the COTS device to never include validation of a PIN processing environment. Equally, it is also expected that all MPoC Solutions will include decryption or key management environments for account data sent from the MPoC Applications that are deployed as part of the MPoC Solution.

Although it is not necessary for the MPoC Solution provider to develop, implement, or operate all of these systems, it is the responsibility of the MPoC Solution provider to ensure that the relevant requirements for each are met. This may be achieved …

Removed p. 161

5A-1 Merchant Identification and Communication MPoC Solutions are used by merchants to accept payment transactions. Initial provisioning of the MPoC Application includes providing for the unique identification of the merchant. Ensuring that the merchant is informed of changes or requirements of the MPoC Solution as the solution changes over time is vital to the security of the solution.

Security Requirements Test Requirements Guidance Objective: The merchant is onboarded securely and kept up to date with relevant information in a timely manner.

5A-1.1 The process of onboarding new merchants must be documented. At a minimum, the process must describe how merchant identification is performed.

5A-1.1.a The tester must confirm through examination that the onboarding process is documented.

Identification is an important security measure against financial fraud to verify the identity, suitability, and risks involved with maintaining a business relationship with the merchant. This requirement is not intended to cover the legal or financial process of …

Removed p. 162

5A-1.3.a The tester must confirm through examination that a merchant communication plan exists and contains the following information at a minimum:

• Changes to the system baseline.

• Changes to any user manual including at a minimum:

• How the MPoC Application must be installed and provided with unique (configuration) data.

• How to use the MPoC Application securely (e.g., privacy during the customer PIN entry process).

• Any security responsibilities that belong to the merchant when using the Solution.

• User information about peripheral such as non-PTS approved MSR or PCI PTS SCRP if used in the Solution.

• How to contact the MPoC Solution provider.

• Planned maintenance downtime.

• Provisioned credentials.

• Information about potential compromise/security incidents.

• End User License Agreement (EULA).

It is important that the merchant receives relevant information in a timely manner, and this process cannot be performed ad hoc when issues arise. A merchant communication plan ensures that the processes for how and when …

Removed p. 163

Security Requirements Test Requirements Guidance Objective: Formal processes exist to define and align the interaction and roles of the different entities in the MPoC Solution.

5A-2.1 Documentation must exist that describes how the operational processes are aligned between the different entities in the MPoC Solution.

5A-2.1.a The tester must confirm through examination that documentation on cooperation exists and that it contains the required information. Documentation must contain the following at a minimum:

• Contact information of all entities involved.

• Agreements on incident management processes.

• Agreements on escalation processes.

The Solution might be operationally managed by different entities. This often leads to problems in case of incidents covering more than one entity. Agreements on these kinds of topics help to solve potential incidents efficiently. For example, in the case where a specific COTS Platform is removed from the A&M baseline due to security concerns, it must be clear how this process of removal is to …

Removed p. 164

Security Requirements Test Requirements Guidance Objective: Back-end environment are implemented and operated securely and in ways that maintain compliance to other applicable standards.

5A-3.1 Environments that store, process, or transmit account data must comply with the requirements of PCI DSS.

5A-3.1.a The tester must confirm through examination that a valid Attestation of Compliance (AOC) outlining compliance of any environment within the MPoC Solution that stores, processes, or transmits account data with the PCI DSS requirements.

Environments that are PCI DSS compliant demonstrate that the minimum set of industry-expected security controls have been applied to that environment, which reduces risk compared to environments that do not apply security controls. This includes any payment processing backends directly implemented by the MPoC Solution, or where there is the ability for the MPoC Solution systems to have access to cleartext account data, or the cryptographic keys that can be used to decrypt any encrypted account data.

5A-3.2 Environments …

Removed p. 165

5A-3.4.a The tester must confirm either that the A&M environment complies with the requirements of Domain 3 of this standard or that the A&M service provider is listed on the PCI website as an approved A&M service provider.

The A&M environment may be operated by a service provider who already has been assessed and is listed as compliant to these requirements. Otherwise, the requirements in Domain 3: Attestation and Monitoring apply.

Removed p. 166

This appendix is referenced through test items outlined previously in the MPoC standard, where security assurance of those systems is required, but assessment to PCI DSS is not otherwise in scope. Where assessment against the requirements in this appendix is to be performed, the MPoC laboratory must confirm that all relevant systems and personnel are included. This may include subsets of all possible systems or personnel if sufficient clarity on the systems and operations of the environment can be determined. The term “all personnel” as used within these requirements refers to all personnel deemed to be in scope by the MPoC laboratory.

Assessments to Appendix A are expected to be performed by suitably qualified individuals and cannot be performed as a self-assessment. Remote assessments may be performed to Appendix A, if in line with current PCI SSC guidance on remote assessment processes.

Removed p. 167

A.1.1 Security governance A.1.1.1 Security objectives are aligned with business objectives.

Removed p. 167

The security objectives need to be defined as part of an overarching security strategy that supports and facilitates business objectives. The security strategy needs to provide the foundation for the entity’s security policies and procedures and provide a benchmark against which the health of security controls is monitored and measured.

A.1.1.2 Responsibilities and accountability for meeting security objectives are assigned formally, including responsibilities for the security of the environment.

The assignment of specific roles and responsibilities need to include monitoring and measurement of performance to ensure security objectives are met. Roles and responsibilities may be assigned to a single owner or multiple owners for different aspects. Ownership needs to be assigned to individuals with the authority to make risk-based decisions and upon whom accountability rests for the specific function. Duties are required to be defined formally, and owners must be able to demonstrate an understanding of their responsibilities and accountability.

A.1.1.3 Responsibility for …

Removed p. 168

A strong security policy, or policies, set the security tone for the entity as a whole and inform personnel what is expected of them. All personnel must be aware of the sensitivity of data and their responsibilities for protecting it. The security policy needs to be updated as needed in response to changes in the environment, results of risk assessments, implementation of new technologies, and changes in business objectives. Personnel must be aware of all policies and policy updates, including their applicable responsibilities. Methods of communicating policies need to include a mechanism for personnel to acknowledge they have received and read the policy or policy update. Personnel acknowledgment may be in writing or electronic. All security policies and policy updates must be approved by management to ensure alignment with the entity’s security strategy and business objectives. Any exception to the policies requires management sign-off to ensure the appropriate due diligence …

Removed p. 169

The risk-management strategy defines a structured approach for identifying, evaluating, managing, and monitoring risk. The strategy is required to include requirements for regularly reviewing and updating the entity’s risk-assessment processes as well as methods to monitor the effectiveness of risk-mitigation controls.

A.1.4.2 The risk-management strategy is approved by authorized personnel and updated as needed to address changing risk environment.

The risk-management strategy needs to be approved by personnel with appropriate responsibility and accountability.

A.1.5 Manage third-party relationships A.1.5.1 Policies and procedures for managing third-party relationships are maintained and implemented.

• Examine documented policies/procedures.

Policies and procedures for managing third-party relationships need to consider the risk that each relationship represents, as well as how third-party performance and behavior will be monitored. The policy needs to be kept up to date, approved by management, and communicated to applicable personnel.

A.1.5.2 Due diligence is performed prior to any engagement with a third party.

Removed p. 169

• Examine results of due diligence efforts

Due-diligence processes need to include thorough vetting and a risk analysis prior to establishing a formal relationship with the third party. Specific due-diligence processes and goals will vary for each entity and each is required to provide sufficient assurance that the third party can meet the entity’s security and operational needs.

A.1.5.3 Security responsibilities are defined clearly for each third-party engagement.

• Examine documentation

The specific approach for defining security responsibilities will depend on the type of service, as well as the particular agreement between the entity and any third parties. The entity needs to have a clear understanding of the security responsibilities to be met by the third party and those to be met by the entity.

Removed p. 170

• Examine results of periodic verification.

The specific type of evidence provided by the third party will depend on the agreement in place between the two parties. The evidence needs to provide assurance that the agreed-upon responsibilities are being met on a continual basis. The frequency of verification needs to be aligned with the entity’s risk analysis of the service being provided. PCI SSC provides from time to time guidance on best practice methods for management of third parties. The most recent guidance, including for providers of cloud- based services and guidance provided in the PCI DSS requirements, should be referenced when considering this requirement.

A.1.5.5 Written agreements are maintained.

• Examine documentation.

Agreements need to promote a consistent level of understanding between parties about their applicable responsibilities and be acknowledged by each party. The acknowledgement evidences each party’s commitment to maintaining proper security in regard to the services.

A.1.6 Educate personnel A.1.6.1 A security-awareness …

Removed p. 171

• Examine results of screening process.

The intent of screening personnel is to reduce the risk of fraud and unscrupulous behavior from an internal resource. Role descriptions need to describe the level of security or access required for the role, and the level of screening needs to be appropriate for the particular position. Positions requiring greater responsibility or that have administrative access to critical data or systems may warrant more detailed background checks than positions with less responsibility and access. The policy is required to also cover internal transfers, where personnel in lower risk positions and who have not already undergone a detailed background check are promoted or transferred to positions of greater responsibility or access. The specific roles to be screened depends on the entity’s personnel and security policies. For example, an entity may have a policy that requires detailed screening for all personnel or defines different levels of screening …

Removed p. 172

• Examine documented processes.

• Observe implemented processes.

The entity needs to be able to detect any failures in security controls and respond to them in a timely manner. Processes for responding to security control failures is required to include:

• Restoring the security control

• Identifying the cause of failure

• Identifying and addressing any security issues that arose during the failure of the security control

• Implementing mitigation, such as process or technical controls, to prevent the cause of the failure recurring

• Resuming monitoring of the security control A.2 Secure Network Connectivity Security Requirements Test Requirements Guidance Control Objective: Network-connectivity controls provide secure pathways to the entity’s systems while protecting those systems from unauthorized access and network-based threats.

A.2.1 Protect systems from untrusted systems and networks A.2.1.1 A security policy(s) and procedures for protection of the environment boundaries are maintained and implemented.

Policies for protecting the environment boundaries need to define the purpose, scope, roles, and …

Removed p. 173

• Examine documentation describing controls.

• Observe physical and/or logical controls.

Documentation illustrating authorized communications, both internal and external

•including source and destination systems, interface connections, security controls for those connections, and the type of data being sent

•will assist in meeting these requirements. Protection mechanisms may include technologies such as network gateways, routers, firewalls, encryption, API controls, and virtualization techniques. Controls may be a combination of software and hardware

•e.g., use of packet-filtering capability based on header information, advanced filtering/inspection tools, and implementation of dedicated physical network devices or channels to separate network segments. Many security devices and software provide rule sets and settings that can validate the existence and methodologies used to secure network connectivity.

A.2.1.4 Traffic to and from systems is restricted to only that which is necessary, with all other traffic specifically denied.

• Examine documentation identifying necessary traffic.

• Observe configurations of ingress and egress controls.

A.2.1.5 Network connectivity controls are monitored and/or periodically …

Removed p. 174

• Examine documented controls/configuration standards.

Removed p. 174

Controls must be implemented at the perimeter and critical systems points and include consideration of both network-based and application-based attack vectors. Methods of detection may include signature-based, behavioral, and other mechanisms that analyze traffic flows. Examples of tools include IDS/IPS, host firewalls, and real-time traffic analysis tools. All mechanisms

•such as detection engines, baselines, and signatures

•must be configured, maintained, and updated per vendor instructions to ensure optimal protection.

A.2.2.2 Suspicious traffic is blocked or generates an alert that is investigated and responded to.

• Observe implemented controls and processes.

If suspicious traffic is not automatically blocked, an alert should be generated that is actively monitored and immediately investigated. When suspicious traffic is automatically blocked, a record of the traffic needs to be generated and investigated to determine whether action is needed to prevent further attack.

Removed p. 175

A.3.1 Secure application development A.3.1.1 A security policy(s) and procedures for secure management of the Software Development Lifecycle (SDLC) is maintained and implemented.

When software is developed by the entity or bespoke or custom software is developed by a third party for the entity, the software-development process is required to employ secure coding practices to address common vulnerabilities applicable to the particular technology. The entity needs to remain up to date with vulnerability trends and update its secure coding practices and developer training as needed to address new threats. Examples of current best practices include OWASP, SANS CWE Top 25, and CERT Secure Coding. Application developers must be trained properly to identify and resolve issues related to common coding vulnerabilities. Having staff knowledgeable about secure software- development practices minimizes the number of security vulnerabilities accidentally introduced through poor coding practices. Training for developers may be provided in-house or by third parties …

Removed p. 176

The policy document needs to explain the purpose, scope, roles and responsibilities, methods of access for different account types, configuration management, monitoring methodology, and controls to address known risks.

A.3.2.2 An up-to-date inventory of all system components in the environment is maintained.

• Examine system inventory.

Maintaining a current inventory of all system components enables an organization to accurately and efficiently apply security controls to protect the assets. The inventory should be periodically confirmed by either manual or automated process

•e.g., by correlation with the results of vulnerability scans or penetration testing

•to confirm it is up to date.

A.3.2.3 Configuration standards are defined and implemented for all system types.

• Examine system configuration standards and build procedures for all system component types.

• Examine system configuration standards and build procedures for all system component types.

Removed p. 176

System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being deployed in the environment. System configuration standards and related processes needs to specifically address security settings and parameters that have known security implications for each type of system in use. Examples of industry-accepted configuration standards include, but are not limited to:

• Center for Internet Security (CIS)

• International Organization for Standardization (ISO)

• SysAdmin Audit Network Security (SANS) Institute

• National Institute of Standards Technology (NIST) The implemented controls need to provide assurance that all systems in the environment have known secure configurations.

A.3.2.4 Configuration standards address all known security vulnerabilities and are based on industry-accepted system hardening standards.

A.3.2.5 Configuration standards and build procedures include:

• Changing all vendor-supplied default accounts and system settings.

• Removing or disabling all unnecessary system or application functionality.

• Preventing functions that require different security levels from co-existing on …

Removed p. 177

• Examine documented change-control procedures.

• Examine records of changes and compare to system configurations.

Defined change-control procedures must be followed for any change that impacts systems in the environment. The impact of the change needs to be documented so that all affected parties can plan appropriately for any processing changes. Changes must be authorized by appropriate parties, as defined by the change-management policy, to verify the change is legitimate. Thorough testing is required to be performed to verify that the security of the environment is not reduced by implementing a change. Back-out procedures need to be documented in case the change fails or adversely affects the security of any system component.

A.3.3.2 All changes are authorized, and the security impact understood prior to implementing the change.

A.3.3.3 All changes are tested in a non- production environment.

A.3.3.4 Rollback procedures are prepared for all changes.

A.3.3.5 Unauthorized changes to system or application configurations are prevented and/or …

Removed p. 178

A.4.1 Protect against malicious software A.4.1.1 A security policy(s) and procedures for protecting systems against malware are maintained and implemented.

Controls must be implemented to help prevent the introduction and execution of malicious software (malware) on systems in the environment. A combination of methods, tools, and programs may be used•e.g., anti- malware software, application whitelisting, host-based and network-based intrusion-prevention tools, and system instrumentation. A combination of real-time protection and periodic scans should be considered. The implemented controls must be kept current (e.g., updated signatures, baselines, etc.) as applicable for the technology. Anti-malware controls need to remain enabled unless disablement is specifically authorized by management on a case-by-case basis for a limited time period.

A.4.1.2 Controls to prevent and/or detect and remove malicious software are implemented, active, and maintained.

• Examine documented controls/configurations.

• Examine evidence of malware prevention and/or detection and removal.

Removed p. 179

Policies and procedures define the methods used to identify and remediate vulnerabilities that could affect systems in the environment, and include:

• Monitoring vulnerability lists

• Performing vulnerability scans and penetration tests

• Establishing bug bounty programs Reputable outside sources should be used for security and vulnerability information.

A.4.2.2 Vulnerability scans, both internal and external, are performed at least quarterly to identify and address vulnerabilities.

• Examine vulnerability scanning reports

Vulnerability scans and all required remediation are to be completed as frequently as needed to ensure vulnerabilities are addressed in a timely manner. Rescans should be performed to verify vulnerabilities have been addressed. In addition to a regular scanning process, vulnerability scans need to be performed after any significant change to the environment.

A.4.2.3 Vulnerability scans are performed by qualified personnel:

• External scans are performed by a PCI SSC Approved Scanning Vendor (ASV).

• Internal scans are performed by qualified personnel.

• Examine vulnerability scanning reports.

Internal vulnerability scans can …

Removed p. 180

• Examine penetration test reports.

• Examine penetration test reports.

Penetration tests must be performed at regular intervals and after significant changes to the environment. The penetration-testing methodology should be based on industry-accepted approaches and incorporate both application-layer and network-layer testing. The scope of testing needs to cover the perimeter and critical systems in the environment and include testing from both inside and outside the network. In addition, testing needs to be performed to verify that all segmentation controls are operational and effective, and that out-of-scope systems and networks do not have access to the environment. The specific methodology, depth, and frequency of the testing should be based on the entity’s risk-assessment strategy and be updated as needed to consider new threats and vulnerabilities.

A.4.2.6 Penetration tests are performed by qualified personnel.

Penetration testing is to be performed only by qualified personnel who can demonstrate knowledge and experience, and who are organizationally independent of …

Removed p. 181

A.5.1 Access Management A.5.1.1 A security policy(s) and procedures for assigning access are maintained and implemented.

Policies and procedures need to include details of processes for role assignments, oversight processes, business justifications, and user and group privilege controls.

A.5.1.2 Roles and responsibilities are defined for groups and accounts with access to systems.

• Examine defined roles and responsibilities.

Determining who has access to what, for how long, and what level of access they have needs to be based on established roles and responsibilities. This includes the processes used to maintain, monitor, and approve administrative and user access to systems and data.

A.5.1.3 Least privileges are assigned based on individual job function and periodically reviewed.

• Observe assigned access privileges.

• Examine evidence that access privileges are periodically reviewed.

Access to systems and data needs to be restricted based on business need, while also accounting for the sensitivity of the data being stored, processed, or transmitted. Access privileges must …

Removed p. 182

Implemented controls need to protect the confidentiality and integrity of accounts for both local and remote users. The controls are required to include ensuring that account and credential information is securely transmitted and stored (e.g., using strong cryptography) at all times.

A.5.2.4 Controls are implemented to prevent misuse of accounts.

Processes to prevent misuse of accounts needs to include, at a minimum, the use of account lockouts, lockout durations, session timeouts, and reactivation processes. Inactive user accounts must be removed or disabled within a timely manner. All processes need to align with the entity’s security policies and procedures.

A.5.2.5 Access for third parties is identified, controlled, and monitored.

Configuration and connection requirements must be defined and implemented for all access by third-party personnel. For example, ensuring accounts are enabled only during the time needed and disabled when not in use, and monitoring account activity when in use.

A.5.2.6 Access privileges are monitored and/or reviewed at …

Removed p. 183

Authentication consists of one or more of:

• Something you know, such as a password or passphrase

• Something you have, such as a token device or smart card

• Something you are, such as a biometric When passwords are used, documented requirements need to include considerations for entropy (strength/complexity), password history and reuse, reset processes, and other best practices for secure password use. Passwords need to meet a minimum level of strength, as defined by the entity’s security policy, that provides reasonable assurance they are not guessable and would withstand a brute-force attack.

Removed p. 184

Multi-factor authentication (MFA) requires the completion of at least two different authentication methods (that is, something you know, something you have, and something you are) prior to access being granted. The authentication mechanisms used need to be implemented to ensure their independence such that:

• Access to one factor does not grant access to any other factor, and

• The compromise of any one factor does not affect the integrity or confidentiality of any other factor. Additionally, no prior knowledge of the success or failure of any factor can be provided to the individual until all factors have been presented. Refer to industry standards and best practices for further guidance on MFA principles. MFA can be applied at the network level, system level, or application level. For example, MFA could be applied when connecting to the secure network or network segment, or when connecting to an individual system component in the environment. …

Removed p. 185

A.6.1 Restrict physical access A.6.1.1 A security policy(s) and procedures for securing physical access to systems is maintained and implemented.

The entity needs to define the physical access controls required to prevent systems from being accessed physically by unauthorized persons. The controls need to cover all physical access points and include procedures for managing onsite employees and third parties. Specific procedures are required for managing visitors, including a visible means for identification and escorts by authorized personnel. Physical access and monitoring controls need to include use of video cameras and/or access-control mechanisms. Data from video cameras and/or access-control mechanisms needs to be logged to provide an audit trail of all physical access to the environment. Access logs must be retained in accordance with the entity’s audit log policy. (Refer to Requirement A.7.2.) Monitoring and periodic reviews of physical access controls and audit logs need to be performed to allow early identification …

Removed p. 186

A.7.1 Incident-response plan A.7.1.1 A security policy(s) and procedures for managing and responding to security incidents is maintained and implemented.

The policy needs to define plans, procedures, and technologies to detect, analyze, and promptly respond to security incidents. Defined procedures need to include response activities, escalation, and notification, and cover all assets and processes that could impact critical operations or data. Procedures must be updated in alignment with operational/business changes and the organization's risk strategy.

A.7.1.2 An incident-response plan is in place that includes:

• Roles and responsibilities

• Communication and contact strategies

• Specific incident response procedures

• Business recovery and continuity procedures

• Data back-up processes

• Analysis of legal requirements for reporting compromises

• Coverage and responses of all critical system components

• Consideration of payment brands’ response requirements

• Examine documented incident-response plans and procedures.

The incident-response plan needs to be comprehensive and include coverage of all systems in the environment. At a minimum, communication and contact strategies …

Removed p. 187

The policy needs to cover requirements for the generation, collection, management, and retention of audit logs for all system components in the environment.

A.7.2.2 Audit logs are implemented to:

• Link all access to systems to an individual user.

• Record security events.

• Observe access attempts.

• Examine audit log files.

Recording all personnel access, both physical and logical, to systems in the environment is required to help the entity identify any misuse of accounts and ensure that each individual is accountable for their actions. The determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the system. Logging of security events needs to include notifications or alerts related to suspicious or anomalous activities (e.g., as defined in Requirements A.2.2.2 and A.3.3.5). The level of detail logged is required to be sufficient to identify who, what, where, when, and how an event occurred …

Removed p. 188

• Examine controls/configurations.

• Observe attempts to modify audit logs Only individuals who have a job-related need should be able to view audit log files. Audit logs should be backed up promptly to a centralized log server or media that is difficult to alter. Physical and logical access controls must be in place to prevent unauthorized modifications to audit logs. File-integrity monitoring or change-detection software can be implemented to ensure that any changes to saved log data generate an alert.

A.7.2.6 Audit and monitoring logs are retained for least one year, with a minimum of three months immediately available for analysis.

Log-retention policies need to include storage and retrieval procedures. If stored in off-line locations, procedures need to include assurance that log data can be retrieved in a timely manner. The logs to be retained include at least those defined in Requirement A.7.2.2.

Removed p. 189

It starts with the description of differences between hardware- and software-based tamper-responsive systems, followed by guidelines that must be considered for an attack cost calculation framework. The considerations include the importance of the attack scalability factor as well as its definition, remediation and pre-remediation solutions, and their role and construction of a full attack path. The full attack path rating is constructed based on the tests conducted during the evaluation as per testing requirements.

The rating process is described by listing the steps that the laboratory performs when rating a full attack based on the information collected by partial attack tests and documentation analysis.

The relevant factors that this costing framework takes into account include attack time, attacker expertise, scalability, knowledge of A&M back- end systems, equipment required for the attack, and COTS device access. The detailed description of all the factors is followed by a discussion about ratings, with examples that …

Removed p. 190

7. Use of COTS and attack stages: The use of numerous supporting technologies in a layered security architecture leads to a full attack necessarily consisting of several stages. The following stages are considered: a. Gaining control of the COTS device (rooting). Gaining control of the platform either by using an OEM supported method or based on existing exploits is often the first stage of an attack. While it is often the first stage, it could be that the MPoC Application itself has an exploitable vulnerability and that full control of the COTS is not needed for the full attack path. Prevention of remote attacks on platforms includes regularly updating the COTS OS. b. Gaining control of the MPoC Application. Even for a COTS device under full attacker control, several security mechanisms have to be circumvented to gain control of the MPoC Application. Gaining control of the MPoC Application is usually …

Removed p. 191

• Identification and exploitation stages

• Scalability rating factor

• Remediation and pre-remediation

• Partial and full attacks Identification and Exploitation Stages For an attacker wanting to exploit a vulnerability, the vulnerability must first be identified. This may appear to be a trivial separation, but it is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert, and a simple attack method published on the Internet. Compare this to a vulnerability that is well known but requires enormous expenditure of time and resources to exploit. Of course, factors such as time need to be treated differently in these cases, and therefore the “cost” required to identify an exploit is included in the costing calculation.

Exploitation involves the actual performance of an attack (partial or full) on a live system.

Scalability Rating Factor This factor addresses the attack potential that affects large groups of merchants that …

Removed p. 192

In case of pre-remediation, the product is updated on a regular basis to implement proactive mitigations against known attack paths, or so that the learning curve for the execution of an attack is reset at every update

• thereby necessitating a new identification phase for any known attacks. Pre-remediation may resolve the attack attempts that cannot be detected by A&M back-end systems or prevent those attacks that are already known.

Remediation and pre-remediation are not rated, but they determine whether a partial attack is feasible. If an attack requires more time than the pre-remediation cycle takes, or if the attack can be detected and mitigated before the fraud is performed, the partial attack is not considered when constructing the full attack.

Approach to Attack Calculations Where the MPoC standard requires a costing be provided as evidence for a testing requirement, the costing is to be provided for the specific asset or context of …

Removed p. 193

Rating Procedure The security landscape in which MPoC systems operate dictates a risk-mitigation approach toward the dynamically developing risk landscape. In short, if the security robustness can be circumvented by a skilled attacker de-layering the security architecture, the MPoC Solution could remediate the risk-pre-remediation and remediation techniques discussed in the previous section) and keep the security level sufficiently high.

The rating approach, which takes into account the attestation and monitoring detection time as well as the remediation time before the costing for a full attack is considered, is shown in Figure 4. The laboratory needs to collect sufficient evidence that attack detection and remediation together are sufficiently strong to prevent an attack, including attacks that use knowledge from any previous attack attempts. Where the laboratory finds that a partial attack is possible, that is some part of the security controls can be bypassed, the laboratory may choose to expose this in …

Removed p. 195

The relevant factors for attack rating are shown in the following table.

Table 6: Attack Rating Table Attack Factor Identification Exploitation Attack time Attacker Expertise Scalability Knowledge back-end systems COTS device access As shown in Figure 4, partial attacks factors are assessed after the tester performs relevant tests. Partial attacks are analyzed and the tester determines whether a composition could lead to a full attack. For a possible full attack, the laboratory will calculate the rating based on the factors determined for all partial attacks with the following approach:

• Attack time: The time taken for that stage of the attack (identification or exploitation) to be completed.

• Attacker Expertise: The partial attack with the highest expertise determines the expertise of the full attack. The full attack would not be possible without all the partial attacks and expertise needed for them.

• Knowledge back-end systems: If the knowledge of the back-end systems is needed …

Removed p. 198

• Instance specific: The attack is not scalable and needs to be heavily customized for each COTS device (e.g., the attack depends on the extraction of keys from each COTS device, and that extraction process must be performed as a bespoke process for each COTS device attacked).

• Scalable with physical access: The attack can be leveraged against multiple COTS Platforms and/or MPoC Application instances, but requires that the attacker has physical access to the COTS device during the attack. Consideration for if locked or unlocked access is necessary is calculated in the “access” part of the costing.

• Remotely scalable: The attack may be leveraged against multiple COTS Platforms and/or MPoC Application instances, and does not require the attacker to have any physical access to the COTS device during the attack. Scalability of the attack is of a very high importance for the MPoC; therefore, it has a high number of …

Removed p. 199

Knowledge of A&M Identification Exploitation Public information 0 0 Restricted information Sensitive information 3 4

• Public information about the back-end monitoring system (or no information): Information is considered public if it can be easily obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer.

• Restricted information concerning the back-end monitoring system (e.g., as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered.

• Sensitive information about the back-end monitoring system

•e.g., knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse-engineering.

Removed p. 200

• Standard SW/only includes pre-existing tools which can be easily obtained, such as Frida, Magisk, or jail-breaking scripts and procedures.

• Specialized equipment includes special software that is not readily available and has to be created.

Equipment Identification Exploitation Standard SW/only 0 0 Specialized 3 3 The COTS device security, including the acceptability of any hardware used in the MPoC Solution, is the responsibility of the MPoC Solution provider and their risk management system. Hardware-based security relies on the fact that such solutions have passed high assurance security assessments. The risk management system as well as methods used to determine the acceptability of any hardware security level is assessed by the MPoC laboratory with the documentation assessment based on the relevant security certification as listed in the requirements of this document. Therefore, hardware attacks themselves and hardware equipment used for such attacks are out of scope of this rating system.

COTS Device Access …

Removed p. 201

Three types of access are identified:

• where no physical access is required.

• where physical access is required, but the device may be in a locked state.

• where physical access with the device in an unlocked state is required.

Access Identification Exploitation Remote 0 0 Local locked 0 2 Local unlocked 0 3 Attacks that are marked as “scalable with physical access” will always require local access in the costing as well.

Removed p. 203

The examples provided include the following types of MPoC Solutions:

• A relatively weak MPoC Solution with a scalable attack and one that prevents a scalable attack.

• A relatively strong MPoC Solution with a scalable attack and non-scalable attack.

• An MPoC Solution where there is the ability to use legitimate functionality provided by the COTS OS to expose account data, in both remote and non-remote attack modes.

Removed p. 204

• Weak attestation functions (bypass possible).

• Lack of obfuscation.

• Successful dynamic binary instrumentation (requiring rooted COTS device), which leads to payment assets disclosure.

• Available remote exploit for several approved platforms as well as possibility for merchant and merchant employee to root the COTS device without being detected by the backend.

The relevant parameters of this attack if it were scalable are:

Removed p. 206

• It takes an expert 2-3 weeks or more to reverse engineer the solution and circumvent the runtime security mechanisms.

• Obfuscation is very good.

• Rooting is not detected (or rooting detections can be easily circumvented).

The relevant parameters of this attack (for a scalable solution) are:

Removed p. 207

Attack Factor Identification Exploitation Attack time < 1 month 5 < 1 day 2 Attacker Expertise Expert 4 Proficient 3 Scalability N/A 0 Instance specific 12 Knowledge back-end systems Public information 0 Public information 0 Equipment Specialized 3 Standard 0 COTS device access Local unlocked 0 Remote 0 Sub total 12 17 Use and Abuse of Legitimate Functionality Provided by OS Different attacks exist that use legitimate functionality provided by the OS to gain access to MPoC assets. Examples of such attacks include TeaBot, Cloak, or Dagger using an overlay function as well as accessibility services or developer controls. This example including rating indicates how laboratories should approach such risks during the evaluation.

An example of an abuse of legitimate functionality attack has the following evaluation results:

• Merchant security-guidance documents (user guidance) do not prevent merchant, employees, or attackers from installing a malicious application to monitor touch events, turn on developer …

Removed p. 209

Attack Factor Identification Exploitation Attack time < 1 month 5 < 1 day 2 Attacker Expertise Proficient 3 Layman 0 Scalability N/A 0 Scalable with physical access 6 Knowledge back-end systems Public information 0 Public information 0 Equipment Standard 0 Standard 0 COTS device access Local unlocked 0 Local unlocked 3 Sub total 8 11 If instead the attack requires more advanced expertise and tooling to expose, and more skill to perform on each device (but still with local unlocked access), the costing would instead be:

Removed p. 210

Example of Attack on a Platform - Full Attack - Remote Attack on Platform

Note: The attack activities are out of scope for testing activities within MPoC evaluation process The first example describes the attack on the platform that cannot be identified during the MPoC Application assessment by the laboratory. Nevertheless, this attack is included to provide insight into the effort needed for such attacks and show the rating approach. The risk of the remote attacks on the platform should be addressed by the MPoC Solution provider process that manages risks.

The full attack described here could lead to payment assets disclosure by gaining full control of the platform and assuming the MPoC Application is weak and trusts the COTS platform. The attack is based on the real-world attack presented by Samuel Groß (@5aelo), Project Zero in Full remote attack based on No Clicks Required - Exploiting Memory Corruption Vulnerabilities in Messenger …

Removed p. 212

Example - Full Attack - Perform Fake Payments This attack describes what is required to perform faked payments for a specific MPoC Application with several security measures that have been shown to provide limited resistance during laboratory testing.

Attack description. An attacker with MPoC Application control can modify the MPoC Application to simulate payments when the attacker card is detected. The attacker can acquire goods at the attacked merchant and the screen of the COTS device being used will behave normally, displaying the expected information on the screen; however, it will not send the payment to the backend. A merchant with enough transactions per day will probably identify the theft as shoplifting, as it leaves no trace in the system.

The steps of the attack are:

6. Rooting the COTS device. Older Android versions can run the MPoC Application based on the policy of the MPoC Solution.

Therefore, the rooting of a COTS device …

Removed p. 212

• COTS device access: local locked

Removed p. 213

The relevant parameters of this partial attack are:

• COTS device access: local locked

• Elapsed time: <1 week

• Attacker Expertise: Proficient

8. Developing exploit. Because the obfuscation and run-time integrity are found to be weak during the evaluation, the development of an exploit that modifies the code flow could be performed.

Circumventing the obfuscation and developing the exploit would require the following parameters:

• Elapsed time: >1 week

• Attacker Expertise: Expert

• COTS device access: local locked Therefore, the full attack would have the following rating:

• The elapsed time for identification is accumulated for all the steps resulting in the attack time below a month.

• The elapsed time for exploitation considers only the activities that must be repeated for other COTS devices with the same platform <1 day.

• For all other categories, the highest necessary rating is considered because it is the minimum for the full attack to be completed. For example, if one partial …

Removed p. 215

Table 7 lists the minimum key sizes and parameters for the algorithms used with key transport, exchange, or establishment and for data protection in connection with these requirements. Approved key establishment schemes are described in NIST SP800-56A (ECC/FCC3-based key agreement), NIST SP800-56B (IFC-based key agreement) and NIST SP800-38F (AES-based key encryption/wrapping).

Other key sizes and algorithms may be supported for non-payment brand relevant transactions; otherwise, these are the only encryption algorithms designated as Approved Algorithms.

Table 7: Minimum Key Size Algorithm IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits 2048 224 2048/224 128 Equivalent Key Sizes Key-encipherment keys are to be at least of equal or greater strength than any key they protect. This applies to any key-encipherment keys used to protect secret or private keys that are stored, keys used to encrypt any secret, or private keys for loading or transport. …

Removed p. 216

Table 8: Equivalent Key Sizes Algorithm Effective Bit IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits 112 2048 224 2048/224

• Minimum key size in number of bits 128 3072 256 3072/256 128 Minimum key size in number of bits 192 7680 384 7680/384 192 Minimum key size in number of bits 256 15360 512 15360/512 256 For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):

• DH implementations entities must generate and distribute the system-wide parameters securely: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g).

• ECDH implementations entities must securely generate and distribute …

Removed p. 217

Hash Algorithms For hash algorithms used for authentication or security purposes, only the algorithms and associated bit lengths in Table 9 are permitted.

Table 9: Hash Algorithms Algorithm Length SHA2 family >255 SHA3 family >255 RNGs are either a deterministic random number generator or a Non-deterministic Random Number Generator (NRNG).

Random Number Generators All DRNG must be seeded by an NRNG that provides sufficient authenticated entropy. The entropy required must be at least as many bits as the intended key strength and should be twice as many bits. Entropy sources are discussed in NIST SP800-90B.

Table 10: Random Number Generators RNG Requirement DRNG Tested and approved under NIST SP 800-90A or ISO/IEC 18031 [§9] NRNG Tested and approved under NIST SP 800-90C or ISO/IEC 18031 [§8] Prime Number Generators For cryptographic processes that require prime numbers, use prime number generators tested to ISO/IEC 18032 Information Technology-- Security Techniques: Prime Number Generation or X9.80 …

Removed p. 218

• Evaluation per Appendix D by an approved MPoC Laboratory as part of its evaluation, or

• Through an independent assessment of software lifecycle management practices assessed by a Secure SLC Assessment performed by a Secure SLC Assessor (listed on the PCI SSC website) and confirmed by submitting a Secure SLC ROC and Secure SLC AOC.

Leveraging PCI Secure SLC Standard for Appendix D Security Requirements The SSF Secure SLC Standard defines security requirements for payment-software vendors to integrate security throughout the entire software lifecycle, resulting in software that is secure by design and better able to withstand attacks. Software vendors whose development processes have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Qualified Vendor.

It is possible to validate compliance to the security requirements in this appendix by confirming that the following are met:

• The software lifecycle management practices were assessed …

Removed p. 219

Security Requirements Test Requirements Guidance D.1.1 Security Responsibility and Resources Senior leadership team establishes formal responsibility and authority for the security of the vendor’s products and services, and resources are allocated to execute the strategy and ensure that personnel are appropriately skilled D.1.1.1 Overall responsibility for the security of the vendor’s products and services is assigned by the vendor’s senior leadership team.

D.1.1.1.a Examine vendor evidence and interview the individual or individuals assigned overall responsibility for the security of the vendor’s products and services to confirm the following:

• Accountability for ensuring the security of the vendor’s products and services is formally assigned to an individual or team by the vendor’s senior leadership.

• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the vendor’s products and services.

• Updates are provided to senior leadership at least annually on the performance of and changes to …

Removed p. 220

D.1.1.2 Software security responsibilities are assigned.

Removed p. 220

• Software security responsibilities are clearly defined and assigned to appropriate individuals or teams, including software-development personnel.

• Assignment of responsibilities for ensuring the security of the vendor’s products and services covers the entire software lifecycle.

Individuals, including third-party personnel, involved in the design, development, testing, and maintenance of the vendor’s products and services should be assigned responsibility and accountability for ensuring that software is designed and maintained in accordance with the vendor’s security strategy and all applicable security requirements, including software-specific requirements. Responsibilities can be assigned to an individual, group, or role; however, individuals assigned to a particular group or role should clearly understand how those software security responsibilities affect their individual job functions, the organization’s security expectations, and the individual’s role in fulfilling those expectations. Individuals assigned software-security responsibilities should be able to demonstrate an understanding of their responsibilities and accountability. Evidence to support this security objective might include job …

Removed p. 221

• A mature process is implemented and maintained for managing and maintaining software security skills for software- development personnel.

• The skills required for each defined role, responsibility, and job function are clearly defined.

• The criteria for maintaining individual skills are clearly defined.

• The process includes a review at least annually to ensure software-development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.

To be effective in meeting their software security responsibilities, software-development personnel must be trained or have experience in performing such responsibilities and must maintain the appropriate skills to properly carry out those responsibilities. At a minimum, all software-development personnel must have a basic understanding of general software security concepts and best practices. Individuals with specialized roles and responsibilities should additionally possess specialized skills relevant to the functions they perform. Examples of specialized skills include secure software design (software architects), secure coding techniques (software developers), …

Removed p. 222

D.1.2.1 Examine vendor evidence and interview personnel to confirm the following:

• A mature process exists to identify and monitor external regulatory and industry security and compliance requirements.

• The process includes reviewing sources of regulatory and industry security and compliance requirements for changes at least annually.

• The process results in an inventory of external regulatory and industry security and compliance requirements.

• The inventory is updated as external security and compliance requirements change.

Many organizations are subject to requirements for protecting certain types of information and data such as personally identifiable information (PII), cardholder data (CHD), and protected health information (PHI). Vendors should maintain awareness of evolving industry and regulatory requirements applicable to their operations and products. Maintaining ongoing awareness of external security and compliance obligations allows the vendor to ensure its processes adequately address those requirements at all times, including whenever those requirements are updated, or new requirements introduced. Evidence to support …

Removed p. 223

• A software security policy exists and is communicated to appropriate vendor personnel and business partners, including all software- development personnel.

• At a minimum, the policy covers all control objectives within this standard either explicitly or implicitly.

• The policy is defined in sufficient detail such that the security rules and goals are measurable.

• The vendor’s senior leadership team has approved the software security policy.

Vendors must establish a company-wide software security policy to ensure that all individuals or teams - including relevant business partners - involved in software design, development, and maintenance are aware and have a consistent understanding of how the vendor’s software products and services should be securely built and maintained, and how any critical assets should be handled. The software security policy (or policies) should be known and thoroughly understood by those with the responsibility to ensure they are met, as well as those individuals and teams who …

Removed p. 224

D.1.2.3.a Examine vendor evidence and interview responsible personnel to confirm the following:

• A strategy to ensure the security of the vendor’s products and services is defined.

• The software-security strategy clearly outlines how the software security policy is to be satisfied.

• The software-security strategy is based on or aligned with industry-accepted methodologies.

• The software-security strategy covers the entire lifecycle of the vendor’s products and services.

• The software-security strategy is communicated to appropriate personnel, including software- development personnel.

• The software-security strategy is reviewed at least annually and updated as needed, such as when business needs, external drivers, and products and services evolve.

A software-security strategy is a high-level plan, roadmap, or methodology for ensuring the secure design, development, and maintenance of the vendor’s products and services, and adherence to the vendor’s software security policy. Vendors should either adopt existing frameworks or methodologies or develop their own in accordance with industry-accepted practices for secure …

Removed p. 226

Note: The focus is on the overall management of security-assurance processes and provides the foundation for specific assurance processes defined within this document.

Removed p. 226

• Software security-assurance processes are defined, implemented, and maintained.

• An inventory of software security-assurance processes is maintained.

Software security-assurance processes are activities that are implemented to carry out the vendor’s software- security strategy and to facilitate secure software design, development, and maintenance. To ensure that security and compliance requirements are met, software security policy is satisfied, and the vendor’s products and services are secure and resistant to attack, vendors need to define such processes throughout all phases of the software lifecycle. These may include security “checkpoints,” which are distinct points within the software-development process where software is checked to make sure security requirements are met. Examples of software security- assurance processes and controls include software- design reviews, automated code reviews, security-specific functional testing, and change-management processes. For organizations that leverage Agile software- development methodologies, security checkpoints may be incorporated into the “story” acceptance criteria or the criteria for determining when work …

Removed p. 227

D.1.2.5.a Examine vendor evidence, including the inventory of software security-assurance processes, and interview personnel to confirm that evidence is generated and maintained for each security- assurance process.

To demonstrate the effectiveness of software security- assurance processes, evidence should be generated and maintained for each process to show that it directly results in or contributes to the expected security outcomes (e.g., fewer vulnerabilities or greater resistance to attacks). Evidence needs to be frequently collected and kept up to date to ensure it accurately reflects the ongoing effectiveness of security-assurance processes. Without a track record of performance for software security- assurance processes, it becomes almost impossible to effectively perform root-cause analysis when such processes fail to produce the expected results. Evidence to support this objective might include security control and evidence generation inventories, vulnerability reports, penetration testing results, or any other records and evidence that clearly and consistently shows evidence is generated for …

Removed p. 228

• A mature process exists to detect and evaluate weak or ineffective security-assurance processes.

• The criteria for determining a weak or ineffective security-assurance process are defined and justified.

• Security assurance processes are updated, augmented, or replaced when deemed weak or ineffective.

Software vendors should monitor their security-assurance processes to confirm the processes remain appropriate (i.e., fit for purpose), and effective for their intended purpose and function. For example, the use of manual code reviews may be sufficient to detect all coding errors and vulnerabilities for software with a very limited code base. However, as the code base grows, the use of manual code reviews for the same purpose becomes increasingly impractical or insufficient, and automated testing tools (such as automated static-code scanners and dynamic software-analysis tools) should be used. One method for detecting weak or ineffective security controls is to define a set of metrics or trends that can be used …

Removed p. 229

Security Requirements Test Requirements Guidance D.2.1 Threat Identification and Mitigation Continuously identifies, assesses, and manages risk to its software and services.

D.2.1.1 Critical assets are identified and classified.

• A mature process exists to identify and classify critical assets.

• The criteria for identifying critical assets and determining the confidentiality, integrity, and resiliency requirements for each critical assets are defined.

• The process accounts for all types of critical assets

•including sensitive assets, sensitive resources, and sensitive functions

•for the vendor’s software.

• The process results in an inventory of critical assets used by the vendor’s software.

Before the vendor can determine how to effectively secure and defend its software against attacks, it must first develop a thorough understanding of the software’s critical assets that could be targeted by attackers. Critical assets include any sensitive assets collected, stored, processed, or transmitted by the vendor’s software, as well as any sensitive functions and sensitive resources within or used by …

Removed p. 230

D.2.1.2.a Examine vendor evidence, including process documentation and assessment results to confirm the following:

• A mature process exists to identify, assess, and monitor software threats and design weaknesses (i.e., flaws).

• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attacker.

• The assessment accounts for the entire code base, including how the use of third-party, open-source, or shared components or libraries, APIs, services, and applications used for the delivery and operation of the software may be leveraged in an attack.

• The assessment results in a recorded inventory of threats and design flaws.

• Assessments are routinely performed to account for changes to existing or the emergence of new threats or design flaws.

Determining how to effectively secure and defend software against attacks requires a thorough understanding of the specific threats and vulnerabilities applicable to the vendor’s software. This typically involves …

Removed p. 231

• All software inputs/outputs, process/data flows, trust boundaries, and decision points were considered during the assessment.

• The entire code base, including how the use of third-party, open-source or shared components or libraries, APIs, services, and applications used for the delivery and operation of the software were considered during the assessment.

When open-source software components are used, the vendor should consider any risks associated with the use of the open-source components and the extent to which the open-source software provider manages the security of those components. Additionally, the vendor will need to confirm that support

•including up-to-date security patches

•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are evaluated and implemented. A reliable support system should be in place to identify errors or problems and evaluate and address them in a timely …

Removed p. 232

D.2.1.3.a Examine vendor evidence, including process documentation and software-specific threat and design information, to confirm the following:

• A mature process exists for defining software- specific security requirements and implementing software security controls within the software to mitigate software threats and design flaws.

• Decisions on whether and how to mitigate a specific threat or design flaw are recorded, justified, and approved by appropriate personnel.

• Any remaining residual risk is recorded, justified, and approved by appropriate personnel.

To ensure that its software is resistant to attacks, vendors must implement software-specific controls or countermeasures in their software to mitigate the specific threats and design weaknesses. Examples of such controls include the use of multi-factor authentication mechanisms to prevent unauthorized individuals gaining access to critical assets, and logging mechanisms to detect if and when authentication mechanisms might have been circumvented. Other examples include the use of input validation routines or parameterized queries to protect software …

Removed p. 233

• A mature process exists to identify weak or ineffective software security controls and to update, augment, or replace them.

• The criteria for determining a weak or ineffective security control are defined and justified.

• The process involves monitoring security control effectiveness throughout the software lifecycle.

• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection.

Vendors should monitor and/or routinely test their software to confirm that implemented software security controls remain appropriate (i.e., fit for purpose) and effective for sufficiently mitigating evolving risks or design flaws. For example, a software-specific security requirement may call for cryptography to be used to protect software communications. While the use of SSL may have been sufficient upon the initial design and release of the software, SSL is no longer sufficient to adequately protect communications as new threats and attack methods have significantly reduced its effectiveness as a security control. …

Removed p. 234

D.2.2.1 Existing and emerging software vulnerabilities are detected in a timely manner.

• A mature process exists for testing software for the existence and emergence of vulnerabilities (i.e., security testing).

• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities in the vendor’s software, and are suitable for the software architectures, and the software development languages and frameworks employed.

• Security testing is performed throughout the entire software lifecycle, including after release.

• Security testing accounts for the entire code base, including detecting vulnerabilities in any third-party, open-source, and shared components and libraries.

• Security testing is performed by authorized and objective vendor personnel or third parties.

• Security testing results in an inventory of identified vulnerabilities.

• Security-testing details including the tools used, their configurations, and the specific tests performed are recorded and retained.

Software should be monitored or routinely tested to confirm that vulnerabilities are identified and mitigated before software or code …

Removed p. 235

• Security-testing tools are configured in a way that is appropriate for the intended tests performed.

• Security testing was performed by authorized and objective vendor personnel or third parties.

D.2.2.1.c Examine vendor evidence and interview personnel to confirm that personnel responsible for testing are knowledgeable and skilled in the following areas in accordance with D1.1.3:

• Software security testing techniques

• Security testing tools settings, configurations, and recommended usage D.2.2.1.d Examine software-specific testing results to confirm that security testing is performed throughout the software lifecycle.

Removed p. 236

• A mature process exists for distributing and deploying fixes for newly discovered vulnerabilities and preventing the reintroduction of previously resolved vulnerabilities.

• The process includes methods to prevent previously resolved vulnerabilities or other similar vulnerabilities from being reintroduced into the software.

• The criteria for determining the “criticality” or “severity” of vulnerabilities and how to address vulnerabilities are defined and justified.

• Fixes to address vulnerabilities in production code are made available and deployed in accordance with defined criteria.

• Decisions not to provide fixes in accordance with defined criteria are approved and justified by appropriate personnel on a case- by-case basis.

Vulnerabilities should be addressed in a way commensurate with the risk they pose to the software or its stakeholders. The most critical or severe vulnerabilities (i.e., those with the highest exploitability and/or the greatest impact to stakeholders) should be patched immediately, followed by those with moderate-to-low exploitability and/or impact. Additionally, the discovery …

Removed p. 238

Security Requirements Test Requirements Guidance D.3.1 Change Management Identify and manage all software changes throughout the software lifecycle.

D.3.1.1 All changes to software are identified, assessed, and approved.

D.3.1.1.a Examine vendor evidence and interview personnel to confirm:

• A mature process exists to identify, assess, and approve all changes to software.

• The process includes an analysis of the security impact of all changes.

• The process results in an inventory of all changes made to software, including a record of the determined security impact.

• All change-management decisions are recorded.

• All implemented changes are authorized by responsible personnel.

• The inventory of changes identifies the individual creator of the code and individual authorizing the change, for each code change.

• All decisions to implement changes are justified.

All changes to software should be defined, documented, approved, and tracked so that any vulnerabilities attributed to such changes may be identified and resolved as quickly as possible. The harder it …

Removed p. 239

• A formal system or methodology for uniquely identifying each version of software is defined.

• The system or methodology includes arranging unique identifiers or version elements in a sequential and logical way.

• All changes to software functionality are clearly associated with a unique software version.

• All changes to software functionality are clearly associated with a unique software version.

Without a thoroughly defined versioning methodology, changes to software may not be properly identified, and customers and integrators/resellers may not understand the impact of such changes. The system or methodology adopted by the vendor should allow different release versions of a software product to be easily distinguishable. To ensure a software version accurately represents the release version, the versioning system or methodology should be integrated with applicable lifecycle functions, such as code control and change management. The versioning system or methodology should encompass all changes to all relevant software components. As several iterations …

Removed p. 240

D.3.2.1 The integrity of all software code, including third-party components, is maintained throughout the entire software lifecycle.

D.3.2.1.a Examine evidence, interview personnel, and observe tools and processes to confirm:

• A mature process, mechanism, and/or tool(s) exist to protect the integrity of the software code, including third-party components.

• The processes, mechanisms, and/or tools are reasonable and appropriate for protecting the integrity of software code.

• Processes, mechanisms, or the use of tools results in the timely detection of any unauthorized attempts to tamper with or access software code.

• Unauthorized attempts to tamper with or access software code are investigated in a timely manner.

Effective software-code control practices help ensure that all changes to code are authorized and performed only by those with a legitimate reason to change the code. Examples of these practices include code check-in and check-out procedures with strict access controls, and a comparison

•e.g., using a checksum

•immediately before updating code to confirm …

Removed p. 241

D.3.3.1 Sensitive production data is only collected and retained on vendor systems where there is a legitimate business or technical need.

• A mature process exists to record and authorize the collection and retention of any sensitive production data.

• An inventory of sensitive production data captured or stored by the vendor’s products and services is maintained.

• Decisions to use sensitive production data are approved by appropriate vendor personnel.

• Decisions to use sensitive production data are recorded and reasonably justified.

To protect the confidentiality of any sensitive production data

•that is, sensitive assets that is owned by and entity other than the vendor

• and stored on vendor systems, such data should never be used for purposes other than those for which the data was originally collected. If the vendor provides services to its customers that could result in the collection of sensitive production data (e.g., for troubleshooting or debugging purposes), the vendor should record …

Removed p. 242

Security Requirements Test Requirements Guidance D.4.1 Vendor Implementation Guidance Stakeholders are provided with clear and thorough guidance on the secure implementation, configuration, and operation of its software.

D.4.1.1 The vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its software.

• A mature process exists to produce, maintain, and make available to stakeholders’ guidance on the secure implementation, configuration, and operation of its software.

• The implementation guidance includes documentation of all configurable security- related options and parameters for the vendor’s software, and instructions for properly configuring and securing each of those options and parameters.

When followed, the vendor's implementation guidance provides assurance that the software and patches are securely installed, configured, and maintained in the customer environment, and that all desired security functionality is active and working as intended. The guidance should cover all options and functionality available to software users that could affect the security …

Removed p. 243

• The secure implementation guidance includes instructions about how to securely install or initialize, configure, and maintain the software.

• The secure implementation guidance is sufficiently detailed.

• Evidence exists or is obtained to show that following the secure implementation guidance results in a secure software configuration.

As the vendor is expected to continuously identify, assess, and manage risks to its software, the vendor’s software-change processes should include determining the impact of the change to vendor guidance. Software changes that impact a configurable feature or option should result in an update to the secure implementation guidance.

D.4.1.3 Secure implementation guidance is aligned with software updates.

• The process to produce and maintain secure implementation guidance includes generation of updated guidance when new software updates are released, or security-related options or parameters are introduced or modified.

• Secure implementation guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not …

Removed p. 244

D.4.2.1 Communication channels are defined and made available for customers, installers, integrators, and other relevant parties to report and receive information on security issues and mitigation options.

D.4.2.1.a Examine evidence and interview personnel to confirm the following:

• A mature process exists to support open, bi- directional communications with stakeholders for reporting and receiving security information regarding the vendor’s products and services.

• Communication channels provide stakeholders the ability to report security- related issues and to receive timely status updates on their queries.

• The vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.

Vendors should monitor the threat landscape to identify new vulnerabilities and security issues that impact their software on the market. Vendors should also provide open lines of communication to enable researchers or other stakeholders to report newly discovered vulnerabilities in the vendor’s products and services. Communication channels could include a publicly disclosed …

Removed p. 245

D.4.3 Software Update Information Stakeholders are provided with detailed explanations of all software changes.

D.4.3.1 Upon release of any software updates, a summary of the specific changes made to the software is provided to stakeholders.

• A mature process exists to communicate all software changes to stakeholders upon software updates.

• The process results in a clear and detailed summary of all software changes.

• The change summary information clearly outlines the specific software functionality impacted by the changes.

• Change details are easily accessible to stakeholders.

Release notes should be provided for all software updates, including details of any impact on software functionality and security controls. Informing stakeholders of the impact of a software update enables them to make informed decisions on whether and when to implement it.

D.4.3.1.b For a sample of software updates, examine publicly available information or notifications regarding the software updates to confirm the following:

• Change summary information is made available to …

Removed p. 246

Only requirements for the non-PTS approved MSR device itself are covered in this Appendix. Requirements for the integration and use of a non-PTS approved MSR device within an overall MPoC Solution are covered within the MPoC requirements listed in the body of this document.

MSR Validation and Testing Requirements Magnetic stripe data input to an MPoC Solution must be read by an approved device. This device may be a PCI PTS SCRP, tested and approved through the PCI PTS POI program, or a non-PTS approved MSR tested according to the requirements in this appendix. Regardless of validation, magnetic stripe-based transactions may not be used by an MPoC Solution with PIN acceptance.

Many of the testing requirements in this appendix are based on, and reference, the PCI PTS POI v6.x Derived Test Requirements document. However, this appendix references only a subset of the requirements that would be tested against a PCI PTS SCRP …

Modified p. 246 → 4

• these requirements ~~are not~~ to ~~be assessed.~~

• 1A-412 Moved these requirements to here from 1D-1.3

Removed p. 247

E.2.1.a The tester must confirm through examination and observation that the non-PTS approved MSR does not store account data. It must not be possible for more than one set of magnetic stripe data to be present within the memory of the non-PTS approved MSR device at any one time.

Account data should be transferred from the non-PTS approved MSR device to the MPoC Software as soon as practicable. Although there may be some delay between the read of the data and the transfer of the data to the MPoC Software, there can be only one set of data within the non-PTS approved MSR device at any one time.

Account data should be transferred from the non-PTS approved MSR device to the MPoC Software as soon as practicable. Although there may be some delay between the read of the data and the transfer of the data to the MPoC Software, there can be …

Removed p. 248

E.5.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B5 and confirm compliance to all applicable requirements.

Although PCI PTS POI v6.x B5 includes testing requirements that cover aspects of PIN security, a non- PTS approved MSR device must not allow for the entry or processing of cardholder PINs.

E.6 Sensitive Service Limits Security Requirements Test Requirements Guidance E.6.1 To minimize the risks from unauthorized use of sensitive services, limits on the number of actions that can be performed and a time limit shall be imposed, after which the device is forced to return to its normal mode.

E.6.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B6 and confirm compliance to all applicable requirements.

E.7 Key Management Security Requirements Test Requirements Guidance E.7.1 The key management techniques implemented in the device conform to ISO11568 and/or ANSI X9.24. When multiple cryptographic keys …

Removed p. 249

E.8.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B10 and confirm compliance to all applicable requirements.

Encryption algorithms used to protect account data are required to provide at least 128 bits of effective strength. TDEA encryption is not permitted to be used by a non- PTS approved MSR device for any security services. Use of AES encryption for non-PTS approved MSR devices is recommended. E.8.1.b The tester must confirm through examination and observation that the non-PTS approved MSR uses only algorithms and key lengths that provide an effective key strength of at least 128 bits.

E.9 Remote Access Security Requirements Test Requirements Guidance E.9.1 If the device can be accessed remotely for the purposes of administration, all access attempts must be cryptographically authenticated. If the authenticity of the access request cannot be confirmed, the access request is denied.

E.9.1.a The tester must evaluate the non-PTS approved …

Removed p. 250

• Input to the hash function must use a salt with minimum length of 64 bits.

• The salt is kept secret and appropriately protected.

E.11.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B24 and confirm compliance to all applicable requirements.

Support for surrogate PAN values is not required for non- PTS approved MSR devices. Non-PTS approved MSRs tested against PCI PTS POI v6.x B24 are not required to implement physical tamper detection, and the testing requirements that validate physical security need not be assessed.

E.12 Communications and Interfaces Security Requirements Test Requirements Guidance E.12.1 The device must provide for secure communications and interfaces, including data origin authentication of encrypted messages and protections against logical anomalies.

E.12.1.a The tester must evaluate the non-PTS approved MSR to Module 3 of PCI PTS POI v6.x and confirm compliance to all applicable requirements.

E.13.1.a The tester must evaluate the non-PTS approved MSR …

Removed p. 251

The tester shall use NIST's STS tool, version 2.1.2 or later, or its mathematical equivalent. The tester shall verify that the compiled instance of the STS tool is operating correctly on the testing device by testing the NIST-provided sample data and comparing the results with those found in NIST SP 800-22 Revision 1a (SP800-22r1a), Appendix B. This configuration guidance is for use with STS version 2.1.2, though it will likely continue to be applicable to future versions.

Note: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing …

Removed p. 252

Table 11: Configuration Settings Configuration Item Setting Reference in Key Below Length of bit streams (n) 1,000,000 n must be selected to be consistent with the requirements of all of the tests to be run. The Overlapping Templates, Linear Complexity, Random Excursions, and Random Excursions Variant tests all require n to be greater than or equal to 106 in order to produce meaningful results. The Discrete Fourier Transform (Spectral) test requires n to equal 106. (See SP 800-22r1a Sections 2.8.7, 2.10.7, 2.14.7, 2.15.7, and [NIST 2010].) Number of bit streams (sample size) (M) 1,073 The number of bit sequences (sample size) must be 1,000 or greater in order for the "Proportion of Sequences Passing a Test" result to be meaningful. (See SP 800-22r1a Section 4.2.1.) This value will be 1,073 for the first test, but any additional testing (e.g., further testing to resolve test failures) will necessarily include more bit …

Removed p. 253

[Kim 2004] Kim, Song-Ju, et al., "Corrections of the NIST Statistical Test Suite for Randomness." [Hill 2004] Hill, Joshua (InfoGard Labs), "ApEn Test Parameter Selection." [Hamano 2007] Hamano, K. and Kaneko, T., “Correction of Overlapping Template Matching Test Included in NIST Randomness Test Suite,” IEICE Trans. Fundamentals, vol. E90-A, no. 9, pp. 1788-1792, Sept. 2007.

[Hamano 2009] Hamano, Kenji, “Analysis and Application of the T-complexity.” Ph.D. thesis, The University of Tokyo.

[NIST 2010] STS Software Revision History. URL: http://csrc.nist.gov/groups/ST/toolkit/rng/revision_history_software.html. Internet Archive: http://web.archive.org/web/20150520193625/http://csrc.nist.gov/groups/ST/toolkit/rng/revision_history_software.html [NIST 2014] Current STS Release Notes. URL: http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html. Internet Archive: http://web.archive.org/web/20150103230340/http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html

Document Comparison

Content Changes