Document Diff - PCI Watch

Added p. 7

Deterministic Random Number Generator (DRNG) A deterministic algorithm that generates a sequence of numbers with little or no discernible pattern in the numbers, except for broad statistical properties, which uses a seed value provided by a non-deterministic random number generator.

Added p. 11

OS store A digital distribution service operated by the COTS OS vendor or by the COTS device manufacturer.

Added p. 18

Solutions may optionally include magnetic-stripe readers that meet the security and testing requirements detailed in Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex. Software-based PIN entry is not permitted for magnetic stripe read transactions.

Added p. 26

The requirements defined in this standard have been grouped into modules (see table below) to align with major components that support the security of the overall solution and to support security evaluations if components are the responsibility of different organizations.

All components of the solution must meet the requirements in Core Requirements module.

Added p. 39

Areas of the PIN CVM application that are not directly involved in the processing or handling of the PIN data or providing security services and interface to the monitoring system, will be able to be updated without affecting the security code. This isolation may be achieved in many ways, but simply having different functions within the same body of code for security and non- security functions is not considered sufficient isolation.

The PIN CVM application might collect other data that can be used to correlate the PIN to the user and PAN at other places. The application should be designed in a manner that there is not unexpected leakage of PIN and other correlatable data that can potentially be compromised and misused.

Added p. 60

• SCRP provides a unique, verifiable identifier

Added p. 65

As the security landscape changes, platforms or OSs that may be acceptable under the system baseline may become vulnerable. A documented policy and procedure for assessing these changes should exist and provide details on how decisions are made to remove previously acceptable platforms from the system baseline. Such changes will affect the parties using these platforms, so the documentation should also include how communication is handled in these cases.

Added p. 69

Note: If an optional MSR is implemented in accordance to Software-based PIN Entry on COTS™ Magnetic Stripe Readers Annex, then magnetic-stripe read transactions may continue to be accepted for non-PIN based transactions even in situations where the SCRP is unavailable subject to the controls described in the SPoC Annex.

Added p. 73

As the security landscape changes, platforms or OSs that may have been acceptable under the system baseline may become vulnerable. A documented policy and procedure for assessing these changes should exist and provide details on how decisions are made to remove previously acceptable platforms from the system baseline. The policy should also define how affected merchants using these platforms are notified and the plan to migrate them to the supported platform.

Added p. 77

Optionally, in accordance to Software-based PIN Entry on COTS™ Magnetic Stripe Readers Annex, the SCRP may provide the physical interface necessary for reading magnetic stripe cards. Software PIN entry is not permitted for magnetic stripe read transactions.

Modified p. 5

The security requirements described in this document provide a security risk framework to protect the confidentiality and integrity of sensitive payment information captured and processed on a PIN CVM ~~Solution~~ operating in a production environment.

The security requirements described in this document provide a security risk framework to protect the confidentiality and integrity of sensitive payment information captured and processed on an PIN CVM solution “the solution” operating in a production environment.

Modified p. 5

The security requirements outlined in this document apply to entities developing PIN CVM ~~Applications,~~ evaluator labs, assessors and organizations managing and deploying ~~PIN CVM Solutions.~~

The security requirements outlined in this document apply to entities developing PIN CVM applications, evaluator labs, assessors and organizations managing and deploying the solutions.

Modified p. 5

A separate document, Software-based PIN Entry on COTS Test Requirements, is available to provide more granularity and visibility into the testing processes performed by software-based PIN Entry on COTS evaluation laboratories. The security requirements and testing requirements have been developed for specific ~~audiences, therefore~~ it should be noted that there is not a one-to-one mapping between the documents. The two should be read in combination to fully understand the requirements and the methods for evaluation.

A separate document, Software-based PIN Entry on COTS Test Requirements, is available to provide more granularity and visibility into the testing processes performed by software-based PIN Entry on COTS evaluation laboratories. The security requirements and testing requirements have been developed for specific audiences; therefore, it should be noted that there is not a one-to-one mapping between the documents. The two should be read in combination to fully understand the requirements and the methods for evaluation.

Modified p. 5

 MUST: Defines a mandatory requirement.

• MUST: Defines a mandatory requirement.

Modified p. 5

 SHOULD: Defines a recommendation.

• SHOULD: Defines a recommendation.

Modified p. 6

Asymmetric ~~Encryption~~ Also known as public key cryptography. A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is not computationally feasible to derive the private transformation.

Asymmetric encryption Also known as public key cryptography. A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is not computationally feasible to derive the private transformation.

Modified p. 6

Attestation ~~System~~ The set of components that perform attestation processing for the PIN CVM ~~Solution.~~ Its components include the PIN CVM ~~Application~~ attestation component and the back-end attestation component•the latter works in close association with the back-end monitoring system.

Attestation system The set of components that perform attestation processing for the PIN CVM solution. Its components include the PIN CVM application attestation component and the back-end attestation component•the latter works in close association with the back-end monitoring system.

Modified p. 6

Attestation component An element of the PIN CVM ~~Solution~~ that performs attestation processing.

Attestation component An element of the PIN CVM solution that performs attestation processing.

Modified p. 6

Authentication The process for unambiguously establishing the identity of an entity, process, organization or ~~person Account data Account data consists of cardholder data and/or sensitive authentication data.~~

Authentication The process for unambiguously establishing the identity of an entity, process, organization or person.

Removed p. 7

Deterministic Random Number Generator (DRNG) See Pseudo Random Number Generator (PRNG).

Modified p. 7

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.

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.

Modified p. 7

See ~~Sensitive Authentication Data~~ for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.

See sensitive authentication data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.

Modified p. 7

CDE Acronym for “cardholder data environment.” The people, processes and technology that store, process or transmit cardholder data or sensitive authentication ~~data.~~

CDE Acronym for “cardholder data environment.” The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data .

Modified p. 7

Commercial ~~off-the-shelf~~ (COTS) ~~Device~~ A mobile device (e.g., smartphone or tablet) that is designed for mass-market ~~distribution, and is not designed specifically for payment processing.~~

Commercial Off-The-Shelf (COTS) device A mobile device (e.g., smartphone or tablet) that is designed for mass-market distribution.

Modified p. 7

Correlatable ~~Data~~ In the context of this standard, this is data that would facilitate the correlation of a PIN with a separate transaction or database that contains cardholder data such that interception of this data and the entered PIN could reasonably lead to the association of the PIN with its PAN.

Correlatable data In the context of this standard, this is data that would facilitate the correlation of a PIN with a separate transaction or database that contains cardholder data such that interception of this data and the entered PIN could reasonably lead to the association of the PIN with its PAN.

Modified p. 7

COTS ~~Platform~~ The hardware of the COTS device.

COTS platform The hardware of the COTS device.

Modified p. 8

Environment The IT environment supporting one or more functionalities of the PIN CVM ~~Solution•such~~ as the IT environment hosting the back-end monitoring system.

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

Modified p. 8

Full screen mode Where the PIN CVM application that is currently executing is in control of the primary display and input mechanism(s) of the COTS device. A full screen mode may still include display features that are controlled and/or managed by the COTS ~~Operating System,~~ but may not include any display from other applications. It is assumed by this standard that full screen mode mitigates the use of any separately controlled or managed displays or input mechanisms to display prompts …

Full screen mode Where the PIN CVM application that is currently executing is in control of the primary display and input mechanism(s) of the COTS device. A full screen mode may still include display features that are controlled and/or managed by the COTS OS, but may not include any display from other applications. It is assumed by this standard that full screen mode mitigates the use of any separately controlled or managed displays or input mechanisms to display prompts for …

Modified p. 8

Graphical ~~user interface~~ (GUI) A user interface that is provided through images and text.

Graphical User Interface (GUI) A user interface that is provided through images and text.

Modified p. 9

Hash-based ~~message authentication code~~ (HMAC) A message authentication code that is produced using hash algorithms rather than a symmetric cryptographic algorithm. Defined in FIPS 198-1.

Hash-based Message Authentication Code (HMAC) A message authentication code that is produced using hash algorithms rather than a symmetric cryptographic algorithm. Defined in FIPS 198-1.

Modified p. 9

~~Just-in-time~~ (JIT) compilation Compiling of code immediately prior to the execution of that code.

Just-In-Time (JIT) compilation Compiling of code immediately prior to the execution of that code.

Modified p. 10

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

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

Modified p. 10

Mobile device In the context of this standard, see ~~COTS.~~

Mobile device In the context of this standard, see COTS device.

Modified p. 10

Monitor In this standard, the “monitor” is an implementation that may be shared across different execution environments, which provides a level of validation and assurance of the execution environment in which the PIN CVM ~~Application~~ executes, providing a level of software-based tamper detection and response. The monitor must be capable of being regularly updated to detect and respond to new threats.

Monitor In this standard, the “monitor” is an implementation that may be shared across different execution environments, which provides a level of validation and assurance of the execution environment in which the PIN CVM application executes, providing a level of software-based tamper detection and response. The monitor must be capable of being regularly updated to detect and respond to new threats.

Modified p. 11

Offline ~~Payment Transaction~~ In an offline EMV transaction, the card and terminal communicate and use issuer-defined risk parameters that are set in the card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online connectivity

•e.g., at a ticket kiosk

•or in countries where telecommunications costs are high.

Offline payment transaction In an offline EMV transaction, the card and terminal communicate and use issuer-defined risk parameters that are set in the card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online connectivity

•e.g., at a ticket kiosk

•or in countries where telecommunications costs are high.

Modified p. 11

Operating ~~system~~ (OS) System software that manages the underlying hardware and software resources and provides common services for programs. Common operating systems in a COTS environment include, but are not limited to, Android and iOS.

Operating System (OS) System software that manages the underlying hardware and software resources and provides common services for programs. Common operating systems in a COTS environment include, but are not limited to, Android and iOS.

Modified p. 11

PCI PIN A PCI standard that contains a complete set of requirements for the secure management, processing and transmission of ~~personal identification number (PIN)~~ data during online and offline payment card transaction processing at ATMs and attended and unattended point-of-sale (POS) terminals.

PCI PIN A PCI standard that contains a complete set of requirements for the secure management, processing and transmission of Personal Identification Number data during online and offline payment card transaction processing at ATMs and attended and unattended point-of-sale (POS) terminals.

Modified p. 11

Personal ~~identification number~~ (PIN) A numeric personal identification code that authenticates a cardholder. A PIN consists only of decimal digits.

Personal Identification Number (PIN) A numeric personal identification code that authenticates a cardholder. A PIN consists only of decimal digits.

Modified p. 11

PIN CVM ~~Application~~ All parts of the code, regardless of execution environment, that are installed and executed on the merchant COTS device for the purposes of accepting and processing the cardholder’s PIN The client-side monitor and/or a payment application may be incorporated into the PIN CVM ~~Application~~ or may be a separate application.

PIN CVM application All parts of the code, regardless of execution environment, that are installed and executed on the merchant COTS device for the purposes of accepting and processing the cardholder’s PIN The client-side monitor and/or a payment application may be incorporated into the PIN CVM application or may be a separate application.

Removed p. 12

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

Modified p. 12

Public key cryptography See ~~Asymmetric Encryption.~~

Public key cryptography See asymmetric encryption.

Modified p. 12

RSA An asymmetric encryption algorithm that was defined by the cryptographers Rivest, ~~Shamir~~ and Aldeman.

RSA An asymmetric encryption algorithm that was defined by the cryptographers Rivest, Shamir, and Aldeman.

Modified p. 12

Secure ~~Boot~~ See ~~Trusted Boot.~~

Secure boot See trusted boot.

Modified p. 12

Secure ~~card reader~~

• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website.

Secure Card Reader

• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website.

Modified p. 13

Secure ~~reading~~ and ~~exchange~~ of ~~data~~ (SRED) ~~Module 4 of~~ the PCI PTS POI Standard, detailing the ~~requirements~~ for devices that protect account data.

Secure Reading and Exchange of Data (SRED) Requirements contained in the PCI PTS POI Standard, detailing the security controls for devices that protect account data.

Modified p. 13

Sensitive ~~Authentication Data~~ Security-related information

•including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs and PIN blocks

•used to authenticate cardholders and/or authorize payment card transactions.

Sensitive authentication data Security-related information

•including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs and PIN blocks

•used to authenticate cardholders and/or authorize payment card transactions.

Modified p. 13

Sensitive ~~Data~~ For the purposes of this standard, sensitive data is cryptographic materials•e.g., keys, certificates, cardholder PINs or cardholder data.

Sensitive data For the purposes of this standard, sensitive data is cryptographic materials•e.g., keys, certificates, cardholder PINs or cardholder data.

Modified p. 13

Sensitive ~~Services~~ Those functions that affect underlying processes that support the protection of sensitive data•e.g., cryptographic keys, PINs and cardholder data.

Sensitive services Those functions that affect underlying processes that support the protection of sensitive data•e.g., cryptographic keys, PINs and cardholder data.

Modified p. 13

Split ~~Knowledge~~ A condition under which two or more entities separately have key components or key shares that individually convey no knowledge of the resultant cryptographic key. The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed.

Split knowledge A condition under which two or more entities separately have key components or key shares that individually convey no knowledge of the resultant cryptographic key. The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed.

Modified p. 13

Software ~~Protection Mechanisms~~ Methods and implementations used to prevent the reverse engineering and modification of software. See ~~Obfuscation~~ and ~~White-box~~ cryptography as examples of commonly used software protection mechanisms.

Software protection mechanisms Methods and implementations used to prevent the reverse engineering and modification of software. See obfuscation and white-box cryptography as examples of commonly used software protection mechanisms.

Modified p. 13

Solution ~~Provider~~ An entity that develops, manages and/or deploys PIN CVM ~~Solutions.~~

Solution provider An entity that develops, manages and/or deploys PIN CVM solutions.

Modified p. 13

Supported ~~Platform~~ The ~~most~~ current operating system supported by the operating system vendor.

Supported platform The current operating system supported by the operating system vendor.

Modified p. 14

The ~~Solution~~ See PIN CVM ~~Solution.~~

The solution See PIN CVM solution.

Modified p. 14

~~Third Party App Stores~~ App stores that are not supported by the COTS OS vendor and are not pre-installed by the device manufacturer.

Third-party app stores App stores that are not supported by the COTS OS vendor and are not pre-installed by the device manufacturer.

Modified p. 14

True Random Number Generator (TRNG) A device that generates random numbers from a physical process, such as a ~~Physical Unclonable Function,~~ rather than a deterministic algorithm.

True Random Number Generator (TRNG) A device that generates random numbers from a physical process, such as a PUF, rather than a deterministic algorithm.

Modified p. 14

Trusted Execution Environment (TEE) A Trusted Execution Environment provides security features such as isolated execution environment for ~~Trusted Applications~~ (“Trustlets”). It protects security assets from general software attacks, defines safeguards as to data and functions that a program can access and resists a set of defined threats.

Trusted Execution Environment (TEE) A Trusted Execution Environment provides security features such as isolated execution environment for trusted applications (“Trustlets”). It protects security assets from general software attacks, defines safeguards as to data and functions that a program can access and resists a set of defined threats.

Modified p. 14

User ~~interface~~ (UI) The set of the human-machine interfaces that allows for interaction between a person and a computerized system.

User Interface (UI) The set of the human-machine interfaces that allows for interaction between a person and a computerized system.

Modified p. 18

~~In recent years, there has been a substantial increase in mobile payments.~~ 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. Software-based PIN entry solutions allow for the processing of mobile payment-acceptance transactions with a cardholder’s PIN.

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. Software-based PIN entry solutions allow for the processing of mobile payment-acceptance transactions with a cardholder’s PIN.

Removed p. 19

Figure 1: Hardware- and Software-based PIN Entry

Modified p. 19

There are, however, individual components of a software solution where there is limited control•for example, the underlying mobile device hardware platform and ~~operating system.~~ Given that these are COTS devices, there is an assumption that these components (e.g., COTS ~~operating system,~~ configuration of hardware components of a phone, etc.) are unknown or untrusted.

There are, however, individual components of a software solution where there is limited control•for example, the underlying mobile device hardware platform and OS. Given that these are COTS devices, there is an assumption that these components (e.g., COTS OS, configuration of hardware components of a phone, etc.) are unknown or untrusted.

Modified p. 20

1. An SCRP device that supports ~~The Solution.~~ The SCRP is SRED-enabled and connected to the COTS device. The SCRP provides: a. Protection of cardholder data sourced from the payment instrument b. Decryption of encrypted PIN data received from the PIN CVM ~~Application~~ c. Translation of PIN data into required PIN-block format (This would only apply to online PIN verification processing.) d. Re-encryption of PIN data

1. An SCRP device that supports the solution. The SCRP is SRED-enabled and connected to the COTS device. The SCRP provides: a. Protection of cardholder data sourced from the payment instrument b. Decryption of encrypted PIN data received from the PIN CVM application c. Translation of PIN data into required PIN-block format (This would only apply to online PIN verification processing.) d. Re-encryption of PIN data

Modified p. 20

2. A PIN CVM ~~Application~~ that resides on the COTS device and: a. Provides a secure ~~user interface~~ for PIN entry b. Performs initial encryption of the PIN c. Passes attestation health-check data about the SCRP, COTS ~~platform~~ and PIN CVM ~~Application~~ to the monitoring environment d. Contains software protection mechanisms to maintain its own integrity against attack e. Delivers the encrypted PIN to the SCRP to be decrypted/re-encrypted in order for it to be passed to the back-end monitoring …

2. A PIN CVM application that resides on the COTS device and: a. Provides a secure UI for PIN entry b. Performs initial encryption of the PIN c. Passes attestation health-check data about the SCRP, COTS platform, and PIN CVM application to the monitoring environment d. Contains software protection mechanisms to maintain its own integrity against attack e. Delivers the encrypted PIN to the SCRP to be decrypted/re-encrypted in order for it to be passed to the back-end monitoring and …

Modified p. 20

3. A ~~commercial off-the-shelf (COTS)~~ device that is operated by the merchant to run the PIN CVM ~~Application~~ as well as the SCRP. The COTS may have a ~~Trusted Execution Environment (TEE)~~ built in but it is not a requirement.

3. A COTS device that is operated by the merchant to run the PIN CVM application as well as the SCRP. The COTS may have a TEE built in but it is not a requirement.

Modified p. 20

4. A set of back-end systems that perform functions for the ~~PIN CVM Solution~~ such as:

4. A set of back-end systems that perform functions for the The solution such as:

Modified p. 20

• Attestation Processes attestation health-check data from the PIN CVM ~~Application~~ and enforces pre-established security policies

• Attestation Processes attestation health-check data from the PIN CVM application and enforces pre-established security policies

Modified p. 20

• Monitoring Monitors and provisions security controls to detect, alert and mitigate suspected or actual threats and attacks against the SCRP, PIN CVM ~~Application~~ and the COTS device

• Monitoring Monitors and provisions security controls to detect, alert and mitigate suspected or actual threats and attacks against the SCRP, PIN CVM application, and the COTS device

Modified p. 23

1. PIN CVM ~~Application~~ and SCRP are initialized with their financial keys (this may be asynchronous with the transaction).

1. PIN CVM application and SCRP are initialized with their financial keys (this may be asynchronous with the transaction).

Modified p. 23

2. A secure communication channel between the PIN CVM ~~Application~~ and the back-end monitoring system is established.

2. A secure communication channel between the PIN CVM application and the back-end monitoring system is established.

Modified p. 23

3. The back-end monitoring system determines the security status of the mobile payment-acceptance platform (SCRP, COTS ~~platform~~ and PIN CVM ~~Application)~~ using the attestation component.

3. The back-end monitoring system determines the security status of the mobile payment-acceptance platform (SCRP, COTS platform, and PIN CVM application) using the attestation component.

Modified p. 23

5. The PIN CVM ~~Application~~ PIN entry component renders a PIN entry screen on the COTS platform and the cardholder enters their PIN using the rendered PIN pad from the PIN CVM ~~Application.~~ The resulting information is enciphered and sent to the SCRP by the PIN CVM ~~Application.~~

5. The PIN CVM application PIN entry component renders a PIN entry screen on the COTS platform and the cardholder enters their PIN using the rendered PIN pad from the PIN CVM application. The resulting information is enciphered and sent to the SCRP by the PIN CVM application.

Removed p. 25

• Attestation data (C and I+)

• PIN CVM Application (C and I+)

• Account Data (C and I)

Modified p. 25

Security Assets There are a number of assets to be protected within the payment ecosystem

•for example PIN, ~~PAN~~ and full-track-equivalent data. The Payment Card Industry Security Standards Council (PCI SSC) defines security requirements for the protection of this data as well as the protection of other sensitive assets, such as cryptographic keys used to protect cardholder data and PIN data. There may be additional assets that require protection as determined by national or regional regulations

•e.g., personally identifiable information (PII). Protection …

Security Assets There are a number of assets to be protected within the payment ecosystem

•for example PIN, PAN, and full-track-equivalent data. The Payment Card Industry Security Standards Council (PCI SSC) defines security requirements for the protection of this data as well as the protection of other sensitive assets, such as cryptographic keys used to protect cardholder data and PIN data. There may be additional assets that require protection as determined by national or regional regulations

•e.g., personally identifiable information (PII). Protection …

Modified p. 25

Assets are categorized as requiring one or more security services: ~~Confidentiality~~ (C), ~~Integrity (I)~~ and ~~Integrity~~ with the addition of auditability/authentication (I+). The ~~Solution Provider~~ may identify other security services, for example confidentiality of binaries.

Assets are categorized as requiring one or more security services: confidentiality (C), integrity (I), and integrity with the addition of auditability/authentication (I+). The solution provider may identify other security services, for example confidentiality of binaries. The following are assets to be protected by the solution. The solution provider may implement additional controls for other assets not referenced in this list.

Modified p. 25

• Private and secret keys or session keys and related parameters (static and ephemeral) used during PIN processing and cardholder data encryption. ~~(C and I)~~

PIN CVM application C and I+ PIN data C and I Private and secret keys or session keys and related parameters (static and ephemeral) used during PIN processing and cardholder data encryption.

Modified p. 25

• Cryptographic keys and related parameters (static and ephemeral) used for communications processing and to secure transport to/from the COTS device. ~~(C and I+)~~

Security Assets Security Services Account data C and I Attestation data C and I+ Cryptographic keys and related parameters (static and ephemeral) used for communications processing and to secure transport to/from the COTS device.

Removed p. 26

The requirements defined in this standard have been categorized to align with major components that support the security of the overall solution and to support security evaluations if components are the responsibility of different organizations.

Modified p. 26

As detailed in the requirements, ~~Solution Providers~~ have ongoing responsibility to proactively perform risk assessments to identify potential flaws or gaps that may be introduced into software-based PIN entry scenarios that may be associated with changes in technology or identification of new threats and vulnerabilities.

As detailed in the requirements, solution providers have ongoing responsibility to proactively perform risk assessments to identify potential flaws or gaps that may be introduced into software-based PIN entry scenarios that may be associated with changes in technology or identification of new threats and vulnerabilities.

Modified p. 26

1. Core Requirements General requirements that define security controls applicable to the overall solution. The ~~Solution Provider~~ is responsible to ensure these requirements are in place.

1. Core Requirements General requirements that define security controls applicable to the overall solution. The solution provider is responsible to ensure these requirements are in place.

Modified p. 26

2. PIN ~~Cardholder Verification Method (CVM)~~ Application The PIN CVM ~~Application~~ requirements apply to the software application(s) that reside on the COTS device and communicate with the SCRP and the back-end attestation component and back-end monitoring systems. The PIN CVM ~~Application~~ is responsible for displaying the PIN entry screen, masking entered PIN values in the display, initial encryption of the entered PIN, collecting and reporting attestation information.

2. PIN CVM Application The PIN CVM application requirements apply to the software application(s) that reside on the COTS device and communicate with the SCRP and the back-end attestation component and back-end monitoring systems. The PIN CVM application is responsible for displaying the PIN entry screen, masking entered PIN values in the display, initial encryption of the entered PIN, collecting and reporting attestation information.

Modified p. 26

3. Back-end Systems

• Monitoring/Attestation The back-end monitoring system supports the management of ~~The Solution.~~ It interacts with the PIN CVM ~~Application~~ on the COTS device and facilitates detecting anomalous and potentially fraudulent activity, including suspicious transactions.

3. Back-end Systems

• Monitoring/Attestation The back-end monitoring system supports the management of the solution. It interacts with the PIN CVM application on the COTS device and facilitates detecting anomalous and potentially fraudulent activity, including suspicious transactions.

Modified p. 26

The back-end attestation ensures that the required security controls and mitigation mechanisms on the COTS device, ~~SCRP~~ and functions within the PIN CVM ~~Application~~ that are necessary to protect cardholder and PIN data are intact and functioning as intended. The back-end attestation component requires integration with the PIN CVM ~~Application~~ to send the attestation data to it.

The back-end attestation ensures that the required security controls and mitigation mechanisms on the COTS device, SCRP, and functions within the PIN CVM application that are necessary to protect cardholder and PIN data are intact and functioning as intended. The back-end attestation component requires integration with the PIN CVM application to send the attestation data to it.

Modified p. 26

4. Solution Integration Requirements Overall oversight, governance and responsibility of ~~The Solution~~ is necessary to ensure all security controls are in place and functioning as intended.

4. Solution Integration Requirements Overall oversight, governance and responsibility of the solution is necessary to ensure all security controls are in place and functioning as intended.

Removed p. 27

The Solution in its entirety must be assessed against these Core Requirements.

Modified p. 27

Proper identification of processes and functions that are fundamental to the security of ~~The Solution~~ is necessary to ensure common understanding and assist with identifying roles and responsibilities for proper management and security of these processes and/or functions. Without this information, implementation of security controls may be overlooked which could lead to unauthorized disclosure or compromise of ~~The Solution.~~

Proper identification of processes and functions that are fundamental to the security of the solution is necessary to ensure common understanding and assist with identifying roles and responsibilities for proper management and security of these processes and/or functions. Without this information, implementation of security controls may be overlooked which could lead to unauthorized disclosure or compromise of the solution.

Modified p. 27

Use of COTS devices introduces additional risks as it relates to privacy, unauthorized disclosure and exposure to vulnerabilities. Therefore, it is imperative that trust is established through the use of digital signatures to ensure ~~The Solution~~ components know which other components are authentic and the data exchange to and from components is intact and has not been altered. Use of dual control and cryptographic keys further enhances the trust of digital signatures by ensuring the processes to create the digital …

Use of COTS devices introduces additional risks as it relates to privacy, unauthorized disclosure and exposure to vulnerabilities. Therefore, it is imperative that trust is established through the use of digital signatures to ensure the solution components know which other components are authentic and the data exchange to and from components is intact and has not been altered. Use of dual control and cryptographic keys further enhances the trust of digital signatures by ensuring the processes to create the digital …

Modified p. 28

This applies to all components and parts of ~~The Solution~~ where random numbers are generated for security functions.

This applies to all components and parts of the solution where random numbers are generated for security functions.

Modified p. 28

1. Documentation to identify all random number generation functions and reliance on random data used in ~~The Solution~~ must exist and be maintained.

1. Documentation to identify all random number generation functions and reliance on random data used in the solution must exist and be maintained.

Modified p. 28

Identification of all security functions implemented within ~~The Solution~~ that require or rely upon the use of random data is necessary to ensure the process used is sound and cannot be circumvented since cryptography depends on the creation of secret data that is known to only those that have a need to know and unknown and unpredictable to others. ~~Random~~ number generation sets the security baseline that other security controls rely upon. This may include the generation of padding data …

Identification of all security functions implemented within the solution that require or rely upon the use of random data is necessary to ensure the process used is sound and cannot be circumvented since cryptography depends on the creation of secret data that is known to only those that have a need to know and unknown and unpredictable to others. random number generation sets the security baseline that other security controls rely upon. This may include the generation of padding data …

Modified p. 28

Note: This excludes the establishment of secure communication protocols where the use of the native OS RNG is out of the control of the PIN CVM ~~Application.~~

Note: This excludes the establishment of secure communication protocols where the use of the native OS RNG is out of the control of the PIN CVM application.

Modified p. 28

Sufficient entropy is not assured in COTS devices (e.g., NIST ~~SP800-22),~~ therefore confirmation that the secret value, e.g., seeded value, is from a trusted and tested source such as the SCRP is necessary and the seed length is at least 256-bits. A PCI PTS SCRP is a hardware security component that has been independently tested to ensure it meets the most stringent of requirements. Combination of the seeds should ensure that entropy of the seeds is maintained. An example of …

Sufficient entropy is not assured in COTS devices (e.g., NIST SP800-90b), therefore confirmation that the secret value, e.g., seeded value, is from a trusted and tested source such as the SCRP is necessary and the seed length is at least 256-bits. A PCI PTS SCRP is a hardware security component that has been independently tested to ensure it meets the most stringent of requirements. Combination of the seeds should ensure that entropy of the seeds is maintained. An example of …

Modified p. 28

The random number seed obtained from the SCRP may be used by the white-box ~~deterministic random number generator~~ to generate any cryptographic keys or random numbers required by the PIN CVM ~~Application.~~ However, each time the PIN CVM ~~Application~~ is started, it should be ~~re- seeded~~ from the SCRP. The seed value should never be stored in non-volatile memory.

The random number seed obtained from the SCRP may be used by the white-box DRNG to generate any cryptographic keys or random numbers required by the PIN CVM application. However, each time the PIN CVM application is started, it should be re-seeded from the SCRP. The seed value should never be stored in non-volatile memory.

Modified p. 28

3. Random number generation used by the PIN CVM ~~Application~~ must utilize a PRNG that was originally seeded by a random seed provided by the SCRP. It must not be possible to replay or reuse the same seed except by chance.

3. Random number generation used by the PIN CVM application must utilize a PRNG that was originally seeded by a random seed provided by the SCRP. It must not be possible to replay or reuse the same seed except by chance.

Modified p. 28

The secret value (e.g., random seed) used by the PIN CVM ~~Application~~ random number generation process is critical to ensure appropriate entropy for the process as well as protect against the ability to obtain the key itself. The PIN CVM ~~Application~~ may have limited controls due to the nature of software; therefore, the PIN CVM ~~Application~~ relies on obtaining the initial random seed from a ~~secure cryptographic device~~ that has had trust established. An SCRP provides the required high confidence …

The secret value (e.g., random seed) used by the PIN CVM application random number generation process is critical to ensure appropriate entropy for the process as well as protect against the ability to obtain the key itself. The PIN CVM application may have limited controls due to the nature of software; therefore, the PIN CVM application relies on obtaining the initial random seed from a SCD that has had trust established. An SCRP provides the required high confidence and trust.

Modified p. 29

4. The PIN CVM ~~Application~~ must use an assessed ~~random number generator (RNG)~~ where cryptographic algorithms require the use of random numbers.

4. The PIN CVM application must use an assessed RNG where cryptographic algorithms require the use of random numbers.

Modified p. 29

~~Random number generators~~ come in two types: ~~Deterministic RNG (DRNG)~~ and ~~Non- deterministic RNG (NRNG).~~ A DRNG depends on an initial seed value, provided by an NRNG, from which it generates pseudo random numbers. In this case, the seed value comes from the SCRP.

RNGs come in two types: DRNG and NRNG. A DRNG depends on an initial seed value, provided by an NRNG, from which it generates pseudo random numbers. In this case, the seed value comes from the SCRP.

Modified p. 29

The PIN CVM ~~Application~~ RNG should be tested for fitness of purpose against a known standard (e.g., NIST 800-22, NIST 800-90a).

The PIN CVM application RNG should be tested for fitness of purpose against a known standard (e.g., NIST 800-22, NIST 800-90a).

Modified p. 29

Note: Random numbers that are not directly relied upon for security of the customer PIN, cardholder ~~data~~ or monitoring/attestation data

•e.g., random values used in TLS sessions, where the data being transmitted is otherwise protected using application level cryptography

•do not need to meet this requirement.

Note: Random numbers that are not directly relied upon for security of the customer PIN, cardholder data, or monitoring/attestation data

•e.g., random values used in TLS sessions, where the data being transmitted is otherwise protected using application level cryptography

•do not need to meet this requirement.

Modified p. 30

This applies to all components and processes used in ~~The Solution.~~

This applies to all components and processes used in the solution.

Modified p. 30

1. Documentation must exist to identify cryptographic processes and operations used by ~~The Solution~~ for security services.

1. Documentation must exist to identify cryptographic processes and operations used by the solution for security services.

Modified p. 30

• Key-generation or key-agreement processes Information that identifies cryptographic operations used in ~~The Solution~~ assist with ensuring controls are appropriately tested as well as identify areas where cryptography may be beneficial to increase ~~The Solution’s~~ security assurance. Comprehensive documentation that includes (but is not limited to) cipher suites or other cryptographic algorithms implemented includes transport layer protocols that are used for secure channels.

• Key-generation or key-agreement processes Information that identifies cryptographic operations used in the solution assist with ensuring controls are appropriately tested as well as identify areas where cryptography may be beneficial to increase the solution’s security assurance. Comprehensive documentation that includes (but is not limited to) cipher suites or other cryptographic algorithms implemented includes transport layer protocols that are used for secure channels.

Modified p. 30

2. All security services provided by ~~The Solution~~ must adhere to Appendix C

• Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.

2. All security services provided by the solution must adhere to Appendix C

• Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.

Modified p. 30

Use of recognized cryptographic methods provides assurance that ~~The Solution~~ adheres to industry-tested and accepted algorithms, along with appropriate key lengths that provide effective key strength and proper key-management practices. Proprietary or “home-grown” algorithms do not provide this assurance and are not permitted.

Use of recognized cryptographic methods provides assurance that the solution adheres to industry-tested and accepted algorithms, along with appropriate key lengths that provide effective key strength and proper key-management practices. Proprietary or “home-grown” algorithms do not provide this assurance and are not permitted.

Modified p. 30

The ~~Solution~~ should utilize the most robust and current encryption algorithms and key sizes to withstand modern day attacks and ensure support into the future. Legacy algorithms have a shelf life and may lose some of their effectiveness over time. ~~AES, ECC and RSA are algorithms recognized as being the current industry standard.~~

The solution should utilize the most robust and current encryption algorithms and key sizes to withstand modern day attacks and ensure support into the future. Legacy algorithms have a shelf life and may lose some of their effectiveness over time.

Modified p. 31

Use of hash functions ensures the integrity of data and since hash functions are based on mathematical and cryptographic functions, use of recognized, accepted methods is necessary. This does not preclude the use of other hash types, such as MD5, where collision resistance is not required as a security ~~feature•e.g., fingerprinting or file comparison.~~

Use of hash functions ensures the integrity of data and since hash functions are based on mathematical and cryptographic functions, use of recognized, accepted methods is necessary. This does not preclude the use of other hash types, such as MD5, where collision resistance is not required as a security feature.

Modified p. 31

5. Encryption used to protect PIN data or tamper- detection data must be performed using a key that is unique per transaction/communication session and per PIN CVM ~~Application~~ instance.

5. Encryption used to protect PIN data or tamper- detection data must be performed using a key that is unique per transaction/communication session and per PIN CVM application instance.

Modified p. 31

6. All messages that are communicated between components in ~~The Solution~~ must use a unique key per session.

6. All messages that are communicated between components in the solution must use a unique key per session.

Modified p. 32

8. Public keys/certificates used by ~~The Solution~~ must be signed or MAC’d. ~~Self-signed certificates are prohibited unless the~~ integrity and authenticity of the key is ensured.

8. Public keys/certificates used by the solution must be signed or MAC’d. The integrity and authenticity of the key must be ensured.

Modified p. 32

Public keys/certificates due to the nature of their use, are public and may be sent and received in clear text. Requiring encryption to preserve the confidentiality of the public key/certificate is not required. However, it is important that the public key is protected to ensure it is genuine (authentic) and has not been substituted or altered (integrity). Digital signatures or message authentication codes, e.g., ~~MAC is a method~~ that provides this assurance.

Public keys/certificates due to the nature of their use, are public and may be sent and received in clear text. Requiring encryption to preserve the confidentiality of the public key/certificate is not required. However, it is important that the public key is protected to ensure it is genuine (authentic) and has not been substituted or altered (integrity). Digital signatures or message authentication codes, e.g., MAC, are methods that provides this assurance.

Modified p. 32

Expired certificates introduce unacceptable risk to ~~The Solution.~~ Primarily expire certificates could be an indication of a malicious user being an imposter of a legitimate organization/process which may associated with phishing for sensitive information.

Expired certificates introduce unacceptable risk to the solution. Primarily expire certificates could be an indication of a malicious user being an imposter of a legitimate organization/process which may associated with phishing for sensitive information.

Modified p. 32

Key-check values (KCVs)

•also referred to as key-verification checks ~~(KVCs)~~

•are values that are produced as a result of a key-generation process. Since encryption keys cannot be in clear text, KCVs provide a mechanism to validate the authenticity of a key without disclosing specific information about the key itself. Limiting the number of bytes for the KCV ensures that the ability to retrieve the underlying clear-text key value from the KCV is greatly reduced.

Key-check values (KCVs)

•also referred to as key-verification checks (KCVs)

•are values that are produced as a result of a key-generation process. Since encryption keys cannot be in clear text, KCVs provide a mechanism to validate the authenticity of a key without disclosing specific information about the key itself. Limiting the number of bytes for the KCV ensures that the ability to retrieve the underlying clear-text key value from the KCV is greatly reduced.

Modified p. 33

9. Accountability and audit This applies to the following components in ~~The Solution:~~ the PIN CVM ~~Application~~ and all relative back-end systems (attestation component, monitoring and processing).

9. Accountability and audit This applies to the following components in the solution: the PIN CVM application and all relative back-end systems (attestation component, monitoring and processing).

Modified p. 34

1. Documentation, including procedures, must exist to support all key lifecycle management functions used by ~~The Solution.~~

1. Documentation, including procedures, must exist to support all key lifecycle management functions used by the solution.

Modified p. 34

For example, the generation should conform to industry-recognized procedures that ensure the confidentiality of the underlying key. Keys should only be distributed in a secure manner, never in the clear and only to designated custodians or recipients. Procedures for distribution apply both within and external to the entity. Secret and private keys should be encrypted with a strong key- encrypting key that is stored separately, be stored within a ~~secure cryptographic device~~ (such as a HSM), or be stored as …

For example, the generation should conform to industry-recognized procedures that ensure the confidentiality of the underlying key. Keys should only be distributed in a secure manner, never in the clear and only to designated custodians or recipients. Procedures for distribution apply both within and external to the entity. Secret and private keys should be encrypted with a strong key- encrypting key that is stored separately, be stored within a SCD (such as a HSM), or be stored as at least …

Modified p. 36

7. Secret and/or private cryptographic keys must be maintained in one or more of the following approved forms: a. Encrypted by a key of equal or greater ~~strength~~ b. Stored within a ~~secure cryptographic device~~ c. Managed as two or more full-length components

7. Secret and/or private cryptographic keys must be maintained in one or more of the following approved forms: a. Encrypted by a key of equal or greater b. Stored within a SCD c. Managed as two or more full-length components

Modified p. 36

Note: These approved methods do not apply when storing secret and/or private cryptographic keys within the PIN CVM ~~Application.~~ For the PIN CVM ~~Application~~ (e.g., white-box cryptography) refer to Module 2.

Note: These approved methods do not apply when storing secret and/or private cryptographic keys within the PIN CVM application. For the PIN CVM application (e.g., white-box cryptography) refer to Module 2.

Modified p. 36

Security requirements for white-box cryptography can be found in Module 2: PIN ~~Cardholder Verification Method (CVM)~~ Application.

Security requirements for white-box cryptography can be found in Module 2: PIN CVM Application.

Modified p. 36

Refer to Module 2: PIN ~~Cardholder Verification Method (CVM)~~ Application for white-box cryptography requirements.

Refer to Module 2: PIN CVM Application for white-box cryptography requirements.

Modified p. 36

8. ~~Shared public keys/certificates are acceptable, but methods~~ and procedures to revoke compromised public/private key pairs must be documented and implemented.

8. Methods and procedures to revoke compromised public/private key pairs and certificates must be documented and implemented.

Removed p. 38

Also refer to Appendix D

• Application Security Requirements.

Modified p. 38

These requirements address the development of software for all aspects of ~~The Solution,~~ including the PIN CVM ~~Application,~~ and the back-end systems (processing, ~~monitoring~~ and attestation component) monitoring environment. Additional requirements specific to the PIN CVM ~~Application~~ are stated in Module 2, PIN CVM ~~Application.~~

These requirements address the development of software for all aspects of the solution, including the PIN CVM application, and the back-end systems (processing, monitoring, and attestation component) monitoring environment. Additional requirements specific to the PIN CVM application are stated in Module 2, PIN CVM application.

Removed p. 39

Areas of the PIN CVM Application that are not directly involved in the processing or handling of the PIN data, or providing security services and interface to the monitoring system, will be able to be updated without affecting the security code. This isolation may be achieved in many ways, but simply having different functions within the same body of code for security and non- security functions is not considered sufficient isolation.

Modified p. 39

These requirements apply specifically to the PIN CVM ~~Application~~ and client-side monitoring components if those components are not part of the PIN CVM ~~Application.~~

These requirements apply specifically to the PIN CVM application and client-side monitoring components if those components are not part of the PIN CVM application.

Modified p. 40

• Block diagram that indicates where all sensitive data is available in clear text on the merchant-side systems. This includes, but may not be limited to, the SCRP, the COTS ~~operating system,~~ any TEE or physically separate ~~security- processing~~ elements used. This diagram must indicate the flow of sensitive data through the various elements.

• Block diagram that indicates where all sensitive data is available in clear text on the merchant-side systems. This includes, but may not be limited to, the SCRP, the COTS OS, any TEE or physically separate security-processing elements used. This diagram must indicate the flow of sensitive data through the various elements.

Modified p. 40

The ~~Solution Provider~~ and the various parties involved will need to document various aspects of their solution sufficiently so that labs, assessors and other entities are able to understand the security around the various components individually and as a full solution.

The solution provider and the various parties involved will need to document various aspects of their solution sufficiently so that labs, assessors and other entities are able to understand the security around the various components individually and as a full solution.

Removed p. 41

The PIN CVM Application might collect other data that can be used to correlate the PIN to the user and PAN at other places. The application should be designed in a manner that there is not unexpected leakage of PIN and other correlateable data that can potentially be compromised and misused.

Modified p. 41

3. Mechanisms must exist to uniquely identify each instance of the PIN CVM ~~Application~~ to the back-end monitoring system and the back- end attestation component.

3. Mechanisms must exist to uniquely identify each instance of the PIN CVM application to the back-end monitoring system and the back- end attestation component.

Modified p. 41

The ~~Solution Provider~~ should ensure that each instance of the PIN CVM ~~Application~~ is uniquely identified to the back-end monitoring system. The ~~Solution Provider~~ should ~~periodically~~ conduct a risk assessment to ensure the adequacy of the authentication mechanisms and that controls remain in place.

The solution provider should ensure that each instance of the PIN CVM application is uniquely identified to the back-end monitoring system. The solution provider should conduct a risk assessment at least annually to ensure the adequacy of the authentication mechanisms and that controls remain in place.

Modified p. 41

4. The PIN CVM ~~Application~~ must only communicate with known and trusted PCI PTS approved SCRPs.

4. The PIN CVM application must only communicate with known and trusted PCI PTS approved SCRPs.

Modified p. 41

5. The PIN CVM ~~Application~~ must prevent against attacks designed to expose data in storage or memory and deploy appropriate controls including minimizing such storage post transaction completion or application timeout.

5. The PIN CVM application must prevent against attacks designed to expose data in storage or memory and deploy appropriate controls including minimizing such storage post transaction completion or application timeout.

Modified p. 41

6. The PIN CVM ~~Application~~ must be securely developed to prevent screen captures.

6. The PIN CVM application must be securely developed to prevent screen captures.

Modified p. 41

7. The PIN CVM ~~Application~~ must be resistant to reverse engineering. The PIN CVM ~~Application~~ should have adequate controls around the code such as code obfuscation so that the code cannot be parsed and reverse- engineered. This will prevent with tampering of the code.

7. The PIN CVM application must be resistant to reverse engineering. The PIN CVM application should have adequate controls around the code such as code obfuscation so that the code cannot be parsed and reverse- engineered. This will prevent with tampering of the code.

Modified p. 41 → 42

8. Correlatable data that may be supplied by the cardholder

•e.g., e- mail addresses and/or mobile phone numbers required for receiving virtual receipts

•must only be viewed in clear text during its initial entry for the purposes of error correction by the cardholder. Thereafter, any re-presentation of this data by the PIN CVM ~~Application~~ must be masked to prevent exposure of the information.

8. Correlatable data that may be supplied by the cardholder•e.g., e- mail addresses and/or mobile phone numbers required for receiving virtual receipts•must only be viewed in clear text during its initial entry for the purposes of error correction by the cardholder. Thereafter, any re-presentation of this data by the PIN CVM application must be masked to prevent exposure of the information.

Modified p. 41 → 42

The PIN and PAN should always be isolated per transaction. Design the application in a manner to ensure that there is no leakage of correlated data that can potentially be compromised and misused•e.g., display only the last four digits of the mobile phone, display, at ~~a minimum,~~ only the first two characters of e-mail address and the first two and last two of the domain name, jcxxxxxx@coxxxxxx.com. Additional privacy controls may be required by regional/country regulations.

The PIN and PAN should always be isolated per transaction. Design the application in a manner to ensure that there is no leakage of correlated data that can potentially be compromised and misused•e.g., display only the last four digits of the mobile phone, display, at maximum, only the first two characters of e-mail address and the first two and last two of the domain name, jcxxxxxx@coxxxxxx.com. Additional privacy controls may be required by regional/country regulations.

Modified p. 42

9. Establishing a new session or refreshing a secure session between the PIN CVM ~~Application~~ and the back-end monitoring system and back-end attestation component must require successful attestation between the PIN CVM ~~Application~~ and monitoring environment.

9. Establishing a new session or refreshing a secure session between the PIN CVM application and the back-end monitoring system and back-end attestation component must require successful attestation between the PIN CVM application and monitoring environment.

Modified p. 42

Every time the PIN CVM ~~Application~~ connects to the SCRP and authenticates to the back-end monitoring system and the back-end attestation component, it would need to successfully pass the attestation requirement to ensure that the PIN CVM ~~Application, SCRP~~ and COTS device are all in an acceptable state.

Every time the PIN CVM application connects to the SCRP and authenticates to the back-end monitoring system and the back-end attestation component, it would need to successfully pass the attestation requirement to ensure that the PIN CVM application, SCRP, and COTS device are all in an acceptable state.

Modified p. 42

10. The PIN CVM ~~Application~~ must automatically clear the internal buffers it controls when any one of the following occurs:

10. The PIN CVM application must automatically clear the internal buffers it controls when any one of the following occurs:

Modified p. 42

• The PIN CVM ~~Application~~ has timed out waiting for the response from the cardholder or merchant or

• The PIN CVM application has timed out waiting for the response from the cardholder or merchant or

Modified p. 42

• A tamper-detection event has been signaled by the back-end monitoring system, or the PIN CVM ~~Application~~ is halted, loses focus or otherwise is moved to background processing.

• A tamper-detection event has been signaled by the back-end monitoring system, or the PIN CVM application is halted, loses focus or otherwise is moved to background processing.

Modified p. 42

Sensitive data shall not be retained any longer, or used more often, than necessary. PIN data and other correlatable data should be encrypted within the PIN CVM ~~Application~~ immediately after entry is complete and has been signified as such by the cardholder•e.g., via pressing the enter button.

Sensitive data shall not be retained any longer, or used more often, than necessary. PIN data and other correlatable data should be encrypted within the PIN CVM application immediately after entry is complete and has been signified as such by the cardholder•e.g., via pressing the enter button.

Modified p. 42

The device will support the encipherment of the PIN multiple times as part of a transaction series; transferring it between the PIN CVM ~~Application~~ and SCRP, then from the SCRP to the payment back-end. Implement each merchant-side instance to clear the buffers as soon as practical after use.

The device will support the encipherment of the PIN multiple times as part of a transaction series; transferring it between the PIN CVM application and SCRP, then from the SCRP to the payment back-end. Implement each merchant-side instance to clear the buffers as soon as practical after use.

Modified p. 43

1. There must be a clear definition of all platforms

•including device types, hardware and operating systems

•on which the PIN CVM ~~Application~~ can be executed.

1. There must be a clear definition of all platforms•including device types, hardware and OSs•on which the PIN CVM application can be executed.

Modified p. 43

Although these requirements are designed to allow for the entry of a PIN on a COTS platform that has not been directly assessed for security, it is expected that the system will have criteria for which platforms are considered acceptable for PIN entry, and which are not. For example, it is expected that systems using older COTS ~~operating systems~~ that may contain unpatched vulnerabilities will not be deemed acceptable for PIN entry. The system vendor provides a clear methodology for …

Although these requirements are designed to allow for the entry of a PIN on a COTS platform that has not been directly assessed for security, it is expected that the system will have criteria for which platforms are considered acceptable for PIN entry, and which are not. For example, it is expected that systems using older COTS OSs that may contain unpatched vulnerabilities will not be deemed acceptable for PIN entry. The system vendor provides a clear methodology for determining …

Modified p. 43

There are two requirements in this standard that address the suitability of ~~devices/operating systems~~ on which the PIN CVM ~~Application~~ may be executed. This “supported platforms” requirement addresses the need for the PIN CVM ~~Application~~ to be targeted to a limited subset of all available devices, and that the developer should have undertaken some risk analysis and mitigation steps to identify which platforms are suitable and secure.

There are two requirements in this standard that address the suitability of devices/OSs on which the PIN CVM application may be executed. This “supported platforms” requirement addresses the need for the PIN CVM application to be targeted to a limited subset of all available devices, and that the developer should have undertaken some risk analysis and mitigation steps to identify which platforms are suitable and secure.

Modified p. 43

2. PIN CVM ~~Applications~~ must be developed only for supported platforms.

2. PIN CVM applications must be developed only for supported platforms.

Modified p. 43

Where ~~operating systems~~ are no longer supported, security patches might not be available to protect the system from known exploits•which poses a significant risk. Unsupported ~~operating systems~~ expose the device, applications and data on the device to unauthorized disclosure and modification.

Where OSs are no longer supported, security patches might not be available to protect the system from known exploits•which poses a significant risk. Unsupported OSs expose the device, applications and data on the device to unauthorized disclosure and modification.

Modified p. 44

3. The PIN CVM ~~Application~~ must only support platforms that, at a minimum, provide the following features:

3. The PIN CVM application must only support platforms that, at a minimum, provide the following features:

Modified p. 44

• A “trusted boot” mechanism that validates the ~~operating system’s~~ authenticity

• A “trusted boot” mechanism that validates the OS’s authenticity

Modified p. 44

• Isolation of touch-event data such that only the application currently in focus can receive or otherwise identify the location of touch events To ensure the security of ~~The Solution,~~ the PIN CVM ~~Application~~ should be enabled only on a COTS device that meets minimum acceptable criteria. The PIN CVM ~~Application~~ developer should undertake some risk analysis and mitigation steps to identify which platforms are suitable and secure.

• Isolation of touch-event data such that only the application currently in focus can receive or otherwise identify the location of touch events To ensure the security of the solution, the PIN CVM application should be enabled only on a COTS device that meets minimum acceptable criteria. The PIN CVM application developer should undertake some risk analysis and mitigation steps to identify which platforms are suitable and secure.

Modified p. 44

4. The PIN CVM ~~Application~~ must be installed and updated using methods that ensure its integrity and authenticity, using only the OS store ~~provided by the supported COTS operating-system vendor~~ implementing cryptographic validation of this store and any loaded applications.

4. The PIN CVM application must be installed and updated using methods that ensure its integrity and authenticity, using only the OS store implementing cryptographic validation of this store and any loaded applications.

Modified p. 44

The authenticity of the PIN CVM ~~Application~~ is a paramount concern in the security of PIN entry. Loading of applications from the ~~operating system~~ store provides a level of confidence that the application has not been tampered before being installed on the merchant system. Third-party app stores are not allowed.

The authenticity of the PIN CVM application is a paramount concern in the security of PIN entry. Loading of applications from the OS store provides a level of confidence that the application has not been tampered before being installed on the merchant system. Third-party app stores are not allowed.

Modified p. 44

Where the PIN CVM ~~Application~~ allows or requires download of additional data from the back-end monitoring and attestation systems, such data should also be cryptographically signed and authenticated by the PIN CVM ~~Application~~ prior to use or execution. Reliance upon the secure channel that exists between the PIN CVM ~~Application~~ and the back-end monitoring system and attestation component are not sufficient. This requirement implies that each datagram sent from the device to the back-end monitoring system and the back-end attestation …

Where the PIN CVM application allows or requires download of additional data from the back-end monitoring and attestation systems, such data should also be cryptographically signed and authenticated by the PIN CVM application prior to use or execution. Reliance upon the secure channel that exists between the PIN CVM application and the back-end monitoring system and attestation component are not sufficient. This requirement implies that each datagram sent from the device to the back-end monitoring system and the back-end attestation …

Modified p. 45

5. Any required cryptographic keys or other data necessary for first execution must be securely provided to the PIN CVM ~~Application~~ and securely stored.

5. Any required cryptographic keys or other data necessary for first execution must be securely provided to the PIN CVM application and securely stored.

Modified p. 45

• Where white-box cryptography is used white-box keys must be unique per PIN CVM ~~Application~~ instance. The reliance and use of common white-box keys must be minimized after the secure provisioning process.

• Where white-box cryptography is used white-box keys must be unique per PIN CVM application instance. The reliance and use of common white-box keys must be minimized after the secure provisioning process.

Modified p. 45

As the PIN CVM ~~Application~~ is downloaded as a single instance from an OS store, each application install is initially identical to all others. The system should have methods immediately upon first execution to ensure that instance is unique to any other and can be uniquely identified and secured through communication with the back-end monitoring system and the back-end attestation components.

As the PIN CVM application is downloaded as a single instance from an OS store, each application install is initially identical to all others. The system should have methods immediately upon first execution to ensure that instance is unique to any other and can be uniquely identified and secured through communication with the back-end monitoring system and the back-end attestation components.

Modified p. 45

6. The PIN CVM ~~Application~~ executables and scripts must be digitally signed and a signature provided to confirm the software author and guarantee that the application from the OS store (and any other updates) has not been altered or corrupted since it was last signed.

6. The PIN CVM application executables and scripts must be digitally signed and a signature provided to confirm the software author and guarantee that the application from the OS store (and any other updates) has not been altered or corrupted since it was last signed.

Modified p. 45

Where the PIN CVM ~~Application~~ allows or requires download of additional data from the back-end monitoring system and the back-end attestation components, such data should also be cryptographically signed and authenticated by the PIN CVM ~~Application~~ prior to use or execution.

Where the PIN CVM application allows or requires download of additional data from the back-end monitoring system and the back-end attestation components, such data should also be cryptographically signed and authenticated by the PIN CVM application prior to use or execution.

Modified p. 45

The PIN CVM ~~Application~~ may be authenticated through the use of multiple signatures. These may be validated by the COTS ~~operating system~~ as well as the monitoring system.

The PIN CVM application may be authenticated through the use of multiple signatures. These may be validated by the COTS OS as well as the monitoring system.

Modified p. 45

8. A security policy must exist for acceptable use of the PIN CVM ~~Application~~ and be provided to all users of the PIN CVM ~~Application,~~ and is part of the PIN CVM ~~Application~~ End User License Agreement (EULA).

8. A security policy must exist for acceptable use of the PIN CVM application and be provided to all users of the PIN CVM application, and is part of the PIN CVM application End User License Agreement (EULA).

Modified p. 45

The vendor must supply documentation to allow the merchant to understand the context of the approval of the PIN CVM ~~Application~~ and ~~The Solution~~ and to ensure that it does not deploy or use the system in a non-compliant manner. In this context, the security policy both informs the merchant how to use and maintain the system securely, and also provides information to the laboratory during the ~~PIN CVM Solution~~ evaluation.

The vendor must supply documentation to allow the merchant to understand the context of the approval of the PIN CVM application and the solution and to ensure that it does not deploy or use the system in a non-compliant manner. In this context, the security policy both informs the merchant how to use and maintain the system securely, and also provides information to the laboratory during the the solution evaluation.

Modified p. 46

1. The PIN CVM ~~Application~~ must offer tamper-resistance measures around the handling of code, application/monitor interface code and any code that is involved in the use or security of cryptographic keys (both public and private/secret keys) for all the supported platform and protection methods (such as TEE, white-box cryptography).

1. The PIN CVM application must offer tamper-resistance measures around the handling of code, application/monitor interface code and any code that is involved in the use or security of cryptographic keys (both public and private/secret keys) for all the supported platform and protection methods (such as TEE, white-box cryptography).

Modified p. 46

Obfuscation should reduce the efficacy of common tools that may be used for decompilation of the code. Obfuscation methods may include, but not be limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, API renaming, etc. ~~Where the application is provided as a number of files (e.g., libraries) note what protections are provided for the calls between the libraries.~~

Obfuscation should reduce the efficacy of common tools that may be used for decompilation of the code. Obfuscation methods may include, but not be limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, API renaming, etc.

Modified p. 46

These protections are not required across all code, but should be implemented to protect all code that provides PIN security features, such that code complexity can be demonstrated to be significantly increased, or execution can be shown to be possible only on un-modified environments•e.g., through use of a device Physically Unclonable Function to encrypt data/execution, or by implementing the PIN-acceptance code in a trustlet ~~which~~ can be executed only in a secure TEE.

These protections are not required across all code, but should be implemented to protect all code that provides PIN security features, such that code complexity can be demonstrated to be significantly increased, or execution can be shown to be possible only on un-modified environments•e.g., through use of a device Physically Unclonable Function to encrypt data/execution, or by implementing the PIN-acceptance code in a trustlet that can be executed only in a secure TEE.

Modified p. 46

• Reliance on TEE, security ~~processor~~ or other security feature of the COTS devices used The ~~Solution Provider~~ and the various parties involved will need to document how tamper resistance is achieved for each supported platform, where it leverages protections offered by the platform and how it compensates for any security gaps. This information is critical for the labs to review and validate.

• Reliance on TEE, security processor, or other security feature of the COTS devices used The solution provider and the various parties involved will need to document how tamper resistance is achieved for each supported platform, where it leverages protections offered by the platform and how it compensates for any security gaps. This information is critical for the labs to review and validate.

Modified p. 47 → 46

3. The PIN CVM ~~Application~~ must implement methods for detecting and reporting to the monitoring system if any COTS devices have been rooted or jailbroken, including but not limited to:

3. The PIN CVM application must implement methods for detecting and reporting to the monitoring system if any COTS devices have been rooted or jailbroken, including but not limited to:

Modified p. 47 → 46

• When the PIN CVM ~~Application~~ is executed

• When the PIN CVM application is executed

Modified p. 47 → 46

• Whenever white-box cryptography or obfuscation methods, implementations, or instantiations are updated The monitoring system must detect when the PIN CVM ~~Application~~ has been “side loaded” outside of normal channels and treat this as a tamper-detection event.

• Whenever white-box cryptography or obfuscation methods, implementations, or instantiations are updated The monitoring system must detect when the PIN CVM application has been “side loaded” outside of normal channels and treat this as a tamper-detection event.

Modified p. 47 → 46

Even though a supported platform may offer many security and/or tamper- protection mechanisms, rooting or jailbreaking a device could impact and weaken the overall security controls and open up avenues for a malicious user to install malware or exploit other vulnerabilities to harvest sensitive data or affect the integrity of ~~The Solution.~~

Even though a supported platform may offer many security and/or tamper- protection mechanisms, rooting or jailbreaking a device could impact and weaken the overall security controls and open up avenues for a malicious user to install malware or exploit other vulnerabilities to harvest sensitive data or affect the integrity of the solution.

Modified p. 48 → 47

1. The PIN CVM ~~Application~~ must not display the PIN entry screen if it detects that it is being run in developer or emulator mode.

1. The PIN CVM application must not display the PIN entry screen if it detects that it is being run in developer or emulator mode.

Modified p. 48 → 47

This is specific to the production level PIN CVM ~~Application.~~

This is specific to the production level PIN CVM application.

Modified p. 48 → 47

2. The following events during a PIN entry session must be detected by the PIN CVM ~~Application~~ and result in termination of the PIN entry session and deletion of all data collected during the transaction, including PIN data, and not limited to:

2. The following events during a PIN entry session must be detected by the PIN CVM application and result in termination of the PIN entry session and deletion of all data collected during the transaction, including PIN data, and not limited to:

Modified p. 48 → 47

• Switching between applications (e.g., PIN CVM ~~Application~~ and any other application on the COTS device)

• Switching between applications (e.g., PIN CVM application and any other application on the COTS device)

Modified p. 48 → 47

• Stealing focus at any other time during the foreground execution of the PIN CVM ~~Application~~ to maliciously prompt for (and thereby capture) PIN entry

• Stealing focus at any other time during the foreground execution of the PIN CVM application to maliciously prompt for (and thereby capture) PIN entry

Modified p. 49 → 48

3. The PIN CVM ~~Application~~ must not allow PIN entry to be triggered unless the transaction is EMV-based. All transactions must be processed online.

3. The PIN CVM application must not allow PIN entry to be triggered unless the transaction is EMV-based. All transactions must be processed online.

Modified p. 49 → 48

EMV-based transactions introduce dynamic data into the ecosystem, which will be encrypted within the SCRP to be sent to the back-end processing systems. Merchants may have alternate solutions to accept card transactions if the SCRP or the PIN CVM ~~Application~~ is not working. But, those solutions cannot be used to accept PIN data unless they comply with the PTS PIN Standard.

EMV-based transactions introduce dynamic data into the ecosystem, which will be encrypted within the SCRP to be sent to the back-end processing systems. Merchants may have alternate solutions to accept card transactions if the SCRP or the PIN CVM application is not working. But, those solutions cannot be used to accept PIN data unless they comply with the PTS PIN Standard.

Modified p. 49 → 48

In the context of this requirement, "online" refers to the transmission of the financial message to the remote host during the performance of the transaction. Such transactions may utilize either online or offline PIN processing. Where online connectivity is not available, the transaction processing is to be prevented. If connectivity drops during a transaction and the transaction has to be reversed, all customer data has to be erased from the system.

In the context of this requirement, "online" refers to the transmission of the financial message to the remote host during the performance of the transaction. Such transactions may utilize either online or offline PIN processing. Where online connectivity is not available, the transaction processing is to be prevented. If connectivity drops during a transaction and the transaction has to be reversed, all customer data has to be immediately erased from the system.

Modified p. 49 → 48

4. PIN display in the PIN CVM ~~Application~~ must be fully masked so as not to display any digit of the PIN value.

4. PIN display in the PIN CVM application must be fully masked so as not to display any digit of the PIN value.

Modified p. 49 → 48

5. The PIN entry keyboard must not rely on the COTS device ~~operating system~~ keyboard, and it must be securely rendered by the PIN CVM ~~Application.~~

5. The PIN entry keyboard must not rely on the COTS device OS keyboard, and it must be securely rendered by the PIN CVM application.

Modified p. 49 → 48

~~Operating system~~ keyboards could be susceptible to compromise and spoofing.

OS keyboards could be susceptible to compromise and spoofing.

Modified p. 49 → 48

7. The PIN CVM ~~Application~~ must not cache PINs. The PIN CVM ~~Application~~ should prevent storing of PINs.

7. The PIN CVM application must not cache PINs. The PIN CVM application should prevent storing of PINs.

Modified p. 50 → 49

1. PIN data must be encrypted upon entry into the PIN CVM ~~Application~~ and remain encrypted when transmitted by the PIN CVM ~~Application~~ through a trusted and secure interface to the SCRP.

1. PIN data must be encrypted upon entry into the PIN CVM application and remain encrypted when transmitted by the PIN CVM application through a trusted and secure interface to the SCRP.

Modified p. 50 → 49

Encryption of the cardholder’s PIN as it is entered into the PIN CVM ~~Application~~ and as it is transmitted to the SCRP is essential and sets the expectation of PIN protection throughout ~~The Solution.~~ Since PIN encryption is performed in software within the PIN CVM ~~Application,~~ additional measures are required to ensure the confidentiality of the encrypted PIN and the processes performing the encryption.

Encryption of the cardholder’s PIN as it is entered into the PIN CVM application and as it is transmitted to the SCRP is essential and sets the expectation of PIN protection throughout the solution. Since PIN encryption is performed in software within the PIN CVM application, additional measures are required to ensure the confidentiality of the encrypted PIN and the processes performing the encryption.

Modified p. 50 → 49

The PIN CVM ~~Application~~ should provide assurance that even encrypted PIN values are not susceptible to non-authorized disclosure.

The PIN CVM application should provide assurance that even encrypted PIN values are not susceptible to non-authorized disclosure.

Modified p. 50 → 49

3. The PIN-encryption keys and algorithms in the PIN CVM ~~Application~~ used to initially encrypt the PIN must adhere to requirements specified in Appendix C

• Minimum and Equivalent Key Sizes and Strength for Approved Algorithms.

3. The PIN-encryption keys and algorithms in the PIN CVM application used to initially encrypt the PIN must adhere to requirements specified in Appendix C

• Minimum and Equivalent Key Sizes and Strength for Approved Algorithms.

Modified p. 50 → 49

4. PIN-encryption keys must be established in the PIN CVM ~~Application~~ in a secure manner.

4. PIN-encryption keys must be established in the PIN CVM application in a secure manner.

Modified p. 50 → 49

Encryption keys are fundamental to the overall protection of assets and security of ~~The Solution.~~ Mechanisms are to be implemented to ensure the confidentiality and integrity of the secret keys used for PIN encryption. Protection mechanisms may include software obfuscation, key ~~chain~~ and ~~white- box~~ cryptography, use of secure elements or ~~trusted execution environments.~~

Encryption keys are fundamental to the overall protection of assets and security of the solution. Mechanisms are to be implemented to ensure the confidentiality and integrity of the secret keys used for PIN encryption. Protection mechanisms may include software obfuscation, key chain, and white-box cryptography, use of secure elements or TEEs.

Modified p. 50 → 49

6. Where white-box cryptography is used, the white-box ~~cryptographic~~ keys must be changed monthly, at a minimum.

6. Where white-box cryptography is used, the white-box cryptography keys must be changed monthly, at a minimum.

Modified p. 50 → 49

Frequently changing the white-box encryption keys used to protect data substantially increases the security of ~~The Solution.~~ When encryption is performed in software, it is critical to change the white-box key often to prevent unauthorized disclosure.

Frequently changing the white-box encryption keys used to protect data substantially increases the security of the solution. When encryption is performed in software, it is critical to change the white-box key often to prevent unauthorized disclosure.

Modified p. 50

For ISO format 4 PIN ~~blocks generated by~~ the ~~PIN CVM Application, the PAN value~~ is supplied by the SCRP ~~as a secure PAN token.~~

For ISO format 4 PIN blocks, to address separation of PIN and PAN, a PAN token as described in the POI Security Requirements, is supplied by the SCRP to the PIN CVM application.

Modified p. 51 → 50

1. The PIN CVM ~~Application~~ must ensure logs exist and are communicated securely to the back-end monitoring system. The logs must not contain correlatable data or PIN data.

1. The PIN CVM application must ensure logs exist and are communicated securely to the back-end monitoring system. The logs must not contain correlatable data or PIN data.

Modified p. 51 → 50

2. The audit trail generated by the PIN CVM ~~Application~~ must support reconstructing the following events:

2. The audit trail generated by the PIN CVM application must support reconstructing the following events:

Modified p. 51 → 50

• All activity that impacts security functions of the PIN CVM ~~Application~~ (e.g., changes to cryptographic functions, changes to application permissions, failure or success to establish secure channel with monitoring system, etc.)

• All activity that impacts security functions of the PIN CVM application (e.g., changes to cryptographic functions, changes to application permissions, failure or success to establish secure channel with monitoring system, etc.)

Modified p. 51 → 50

• All access to the audit trail managed by or within the PIN CVM ~~Application.~~

• All access to the audit trail managed by or within the PIN CVM application.

Modified p. 51 → 50

• Use of and changes to the PIN CVM ~~Application’s~~ identification and authentication mechanisms.

• Use of and changes to the PIN CVM application’s identification and authentication mechanisms.

Modified p. 51 → 50

• Initialization, stopping or pausing of the PIN CVM ~~Application~~ logs.

• Initialization, stopping or pausing of the PIN CVM application logs.

Modified p. 51 → 50

Logging of the security events enables an organization to identify and trace potentially malicious activities. While the correlation and analysis of the event could occur on the back-end monitoring system, the PIN CVM ~~Application~~ should be able to capture and securely communicate events that could be used by the back-end monitoring system.

Logging of the security events enables an organization to identify and trace potentially malicious activities. While the correlation and analysis of the event could occur on the back-end monitoring system, the PIN CVM application should be able to capture and securely communicate events that could be used by the back-end monitoring system.

Modified p. 52

~~PIN CVM Application Remote Software Attestation Components ~~ The PIN CVM ~~Application~~ software attestation component is the process on the COTS platform used by the PIN CVM ~~Application~~ to manage attestation. It may perform the role of the verifier and the prover.

• The PIN CVM application software attestation component is the process on the COTS platform used by the PIN CVM application to manage attestation. It may perform the role of the verifier and the prover.

Modified p. 52

 The back-end attestation component (a server-based attestation component) is a process that manages attestation. It performs the role of verifier.

• The back-end attestation component (a server-based attestation component) is a process that manages attestation. It performs the role of verifier.

Modified p. 52

Thus, ~~The Solution~~ may implement various types of attestation. Two verifier types are presented in the table below corresponding to possible locations of the verifier.

Thus, the solution may implement various types of attestation. Two verifier types are presented in the table below corresponding to possible locations of the verifier.

Modified p. 52

For PIN entry on COTS, the attestation health checks will be performed on varying components (provers): SCRP, COTS platform and the PIN CVM ~~Application.~~

For PIN entry on COTS, the attestation health checks will be performed on varying components (provers): SCRP, COTS platform and the PIN CVM application.

Modified p. 52

The ~~Solution~~ may use various types of attestation. Three prover types are presented in the table below indicating possible locations of the verifier.

The solution may use various types of attestation. Three prover types are presented in the table below indicating possible locations of the verifier.

Modified p. 52

Note: During attestation, the prover is assumed to be untrusted and the verifier is trusted. During Type 1 and Type 2 attestations, if the PIN CVM ~~Application~~ component has the role of the verifier, it may itself be compromised. Therefore, the security model must account for this risk when using the results of Type 1 and Type 2 attestations provided by the PIN CVM ~~Application~~ if used as part of a Type 3 attestation.

Note: During attestation, the prover is assumed to be untrusted and the verifier is trusted. During Type 1 and Type 2 attestations, if the PIN CVM application component has the role of the verifier, it may itself be compromised. Therefore, the security model must account for this risk when using the results of Type 1 and Type 2 attestations provided by the PIN CVM application if used as part of a Type 3 attestation.

Modified p. 53

1. SCRP a) PIN CVM ~~Application Attestation Component~~

1. SCRP a) PIN CVM application attestation component

Modified p. 53

b) Back-end ~~Attestation Component~~ Verifies the SCRP is valid.

b) Back-end attestation Verifies the SCRP is valid.

Modified p. 53

A PIN CVM ~~Application~~ instantiated attestation and response may be fairly limited due to limited processing availability and security afforded to local storage of measurement parameters, whereas an attestation call performed by the back-end attestation component (required) can be more robust since parameter checking is performed in close association by the monitoring system.

A PIN CVM application instantiated attestation and response may be fairly limited due to limited processing availability and security afforded to local storage of measurement parameters, whereas an attestation call performed by the back-end attestation component (required) can be more robust since parameter checking is performed in close association by the monitoring system.

Modified p. 53

2. COTS ~~Platform~~ (via various sampled measurements)

2. COTS platform (via various sampled measurements)

Modified p. 53

a) PIN CVM ~~Application Attestation Component~~

a) PIN CVM application attestation component

Modified p. 53

b) Back-end ~~Attestation Component~~ Verifies that the COTS platform security model is intact.

b) Back-end attestation Verifies that the COTS platform security model is intact.

Modified p. 53

The assurance for Type 2 ~~Attestation~~ relies on the inability of the attacker to spoof the measurements that are performed or, by the time it is possible for spoofing to be reliably performed, the presence of the attacker in the COTS device has been detected by the fraud systems and appropriate action taken.

The assurance for Type 2 attestation relies on the inability of the attacker to spoof the measurements that are performed or, by the time it is possible for spoofing to be reliably performed, the presence of the attacker in the COTS device has been detected by the fraud systems and appropriate action taken.

Modified p. 53

A PIN CVM ~~Application/SCRP~~ instantiated attestation and response may be fairly limited due to limited processing availability and security afforded to local storage of measurement parameters, whereas an attestation call performed by the back-end attestation component (required) can be more robust since parameter checking is performed in close association by the back-end monitoring system.

A PIN CVM application/SCRP instantiated attestation and response may be fairly limited due to limited processing availability and security afforded to local storage of measurement parameters, whereas an attestation call performed by the back-end attestation component (required) can be more robust since parameter checking is performed in close association by the back-end monitoring system.

Modified p. 53

3. PIN CVM ~~Application~~ (attestation component)

3. PIN CVM application (attestation component)

Modified p. 53

a) Back-end ~~Attestation Component~~ Verifies that both the security model of the PIN CVM ~~Application~~ and its COTS platform are intact.

a) Back-end attestation Verifies that both the security model of the PIN CVM application and its COTS platform are intact.

Modified p. 55

~~Monitoring~~ that the ~~COTS~~ platform is in, and remains in, the system ~~baseline is part of the attestation process.~~

The attestation process includes monitoring of the COTS platform to ensure that the platform is in, and remains in, the system baseline.

Modified p. 55

The ~~Solution Provider~~ is responsible for establishing and maintaining system baselines.

The solution provider is responsible for establishing and maintaining system baselines.

Modified p. 55

• Clear identification of roles and responsibilities for which aspects of the system baseline validation process are performed by the PIN CVM ~~Application~~ itself, and which are performed by other systems or execution environments.

• Clear identification of roles and responsibilities for which aspects of the system baseline validation process are performed by the PIN CVM application itself, and which are performed by other systems or execution environments.

Modified p. 55

The system baseline will change over time and so the process performed by the attestation system to determine the system baseline will not be a single “point in time,” but instead an on-going process that continually assesses the threat environment and allows for decisions to be made about the security of ~~The Solution~~ at a platform level.

The system baseline will change over time and so the process performed by the attestation system to determine the system baseline will not be a single “point in time,” but instead an on-going process that continually assesses the threat environment and allows for decisions to be made about the security of the solution at a platform level.

Modified p. 56

3. The system baseline must be validated by the attestation process upon provisioning of the PIN CVM ~~Application.~~

3. The system baseline must be validated by the attestation process upon provisioning of the PIN CVM application.

Modified p. 56

The ~~Solution~~ should establish a trusted status (aka, baseline) for its components at the onset (provisioning) in order to provide meaningful and relevant information to make security decisions, identify anomalies, or take actions.

The solution should establish a trusted status (aka, baseline) for its components at the onset (provisioning) in order to provide meaningful and relevant information to make security decisions, identify anomalies, or take actions.

Modified p. 56

4. The system baseline must not include ~~“rooted”~~ or ~~“jailbroken”~~ devices. To provide reasonable assurance that the system baseline reflects a secure, trusted state of the environment the baseline should be free from influences that could negatively impact or affect the integrity of the baseline, e.g., devices that have been compromised.

4. The system baseline must not include rooted or jailbroken devices. To provide reasonable assurance that the system baseline reflects a secure, trusted state of the environment the baseline should be free from influences that could negatively impact or affect the integrity of the baseline, e.g., devices that have been compromised.

Modified p. 56

6. COTS devices that ~~are already deployed and~~ use unsupported COTS platforms must be prohibited from processing transactions.

6. COTS devices that use unsupported COTS platforms must be prohibited from processing transactions.

Modified p. 57

Attestation is used to determine whether the COTS device that hosts the PIN CVM ~~Application~~ is being, or has been, maliciously altered or does not meet specified criteria. Underpinning the attestation are policies and procedures and the staff that implement them.

Attestation is used to determine whether the COTS device that hosts the PIN CVM application is being, or has been, maliciously altered or does not meet specified criteria. Underpinning the attestation are policies and procedures and the staff that implement them.

Modified p. 57

The ~~Solution Provider~~ is responsible for defining policies and procedure.

The solution provider is responsible for defining policies and procedure.

Modified p. 57

1. A documented attestation policy that defines health-check rules for the SCRP, COTS ~~platform~~ and PIN CVM ~~Application~~ attestation mechanisms must exist.

1. A documented attestation policy that defines health-check rules for the SCRP, COTS platform, and PIN CVM application attestation mechanisms must exist.

Modified p. 57

The policy should explain the security trust model, how it protects the privacy of ~~The Solution~~ users, the thresholds used, triggers and acceptable errors, categorization of attestation findings as well as response procedures and timeframes for responses.

The policy should explain the security trust model, how it protects the privacy of the solution users, the thresholds used, triggers and acceptable errors, categorization of attestation findings as well as response procedures and timeframes for responses.

Modified p. 57

If any attestation parameters or results of attestation can be maliciously ~~altered~~ then the integrity of the attestation system is impacted.

If any attestation parameters or results of attestation can be maliciously altered, then the integrity of the attestation system is impacted.

Modified p. 57

3. Attestation must be performed at a minimum: a. At initialization/initial installation of the PIN CVM ~~Application~~ initiated by the attestation system, back-end systems, or other trusted non-local execution environment. b. At least every five minutes (if not otherwise activated by one of the events above during that time). c. As indicated in following sections.

3. Attestation must be performed at a minimum: a. At initialization/initial installation of the PIN CVM application initiated by the attestation system, back-end systems, or other trusted non-local execution environment. b. At least every five minutes (if not otherwise activated by one of the events above during that time). c. As indicated in following sections.

Modified p. 58

4. For any attestation response, The ~~Solution Provider~~ must be able to ~~identify:~~ a. Where the process is implemented (in the PIN CVM ~~Application,~~ in a server-based attestation component, remotely or locally to the consumer device, etc.). b. Whether the process was developed by the attestation vendor. c. Whether the process is managed by a third-party provider that provides an API to the attestation vendor but no other privileged access.

4. For any attestation response, The solution provider must be able to a. Where the process is implemented (in the PIN CVM application, in a server-based attestation component, remotely or locally to the consumer device, etc.). b. Whether the process was developed by the attestation vendor. c. Whether the process is managed by a third-party provider that provides an API to the attestation vendor but no other privileged access.

Modified p. 58

6. Attestation code implemented in the PIN CVM ~~Application~~ must be protected by the tamper-resistance features implemented in the PIN CVM ~~Application.~~

6. Attestation code implemented in the PIN CVM application must be protected by the tamper-resistance features implemented in the PIN CVM application.

Modified p. 58

Any attestation code that is present in the PIN CVM ~~Application~~ should be protected from reverse engineering and any static or dynamic attacks that could subvert attestation processing.

Any attestation code that is present in the PIN CVM application should be protected from reverse engineering and any static or dynamic attacks that could subvert attestation processing.

Modified p. 58

Attestation results that do not have an automated response may require skilled staff to interpret specific attestation findings or to interpret them within a wider risk management framework; for ~~example~~ use of telemetry and transaction heuristics.

Attestation results that do not have an automated response may require skilled staff to interpret specific attestation findings or to interpret them within a wider risk management framework; for example, use of telemetry and transaction heuristics.

Modified p. 59

All changes to ~~The Solution~~ components require identification of changes, business justification, testing and approvals. Without following fundamental change-control principles, changes can be intentional or unintentionally omitted that would jeopardize the security and processing of ~~The Solution.~~

All changes to the solution components require identification of changes, business justification, testing and approvals. Without following fundamental change-control principles, changes can be intentional or unintentionally omitted that would jeopardize the security and processing of the solution.

Removed p. 60

• The SCRP provides a unique, verifiable identifier a. Firmware version is acceptable b. SCRP is in a secure state and supports SRED functionality c. Device has a unique serial number d. Magnetic-stripe readers must not be allowed to be paired with the PIN CVM Application

Modified p. 60

1. The PIN CVM ~~Application~~ attestation component must be able to determine that the connected SCRP is valid. At a minimum verify the following: Prior to sharing any PIN encryption key with the SCRP the PIN CVM ~~Application~~ should determine that a valid SCRP is connected.

1. The PIN CVM application attestation component must be able to determine that the connected SCRP is valid. At a minimum verify the following: a. Firmware version is acceptable b. SCRP is in a secure state and supports SRED functionality c. Correct unique identifier of the SCRP Prior to sharing any PIN encryption key with the SCRP the PIN CVM application should determine that a valid SCRP is connected.

Modified p. 60

The monitoring environment should have the ability to request attestation at any time as part of its responsibility to maintain overall security for ~~The Solution.~~

The monitoring environment should have the ability to request attestation at any time as part of its responsibility to maintain overall security for the solution.

Modified p. 61

1. An attestation baseline of the COTS platform must be performed at PIN CVM ~~Application~~ provisioning.

1. An attestation baseline of the COTS platform must be performed at PIN CVM application provisioning.

Modified p. 61

Firmware version, app version, SCRP ID, merchant ID, integrity of ~~configuration~~ or whatever data is available for verification.

Firmware version, app version, SCRP ID, merchant ID, integrity of configuration, or whatever data is available for verification.

Modified p. 61

Attestation measurements reflect the state of the platform running the PIN CVM ~~Application.~~ Any tools or methods used to obtain measurement information should not require privilege escalation on the COTS platform.

Attestation measurements reflect the state of the platform running the PIN CVM application. Any tools or methods used to obtain measurement information should not require privilege escalation on the COTS platform.

Modified p. 61

If the attestation is running when ~~The Solution~~ is ~~online~~ it should not interrupt transaction processing.

If the attestation is running when the solution is online, it should not interrupt transaction processing.

Modified p. 61

8. Attestation responses must be unclonable. Attestation responses should be unclonable, for example by cloning part of the PIN CVM ~~Application~~ configuration using an emulator and performing MITM attacks.

8. Attestation responses must be unclonable. Attestation responses should be unclonable, for example by cloning part of the PIN CVM application configuration using an emulator and performing MITM attacks.

Modified p. 61

A malicious process may interfere with attestation processing, for example to create a denial of service. The PIN CVM ~~Application~~ attestation component should notify the monitoring environment if the response timeout is exceeded.

A malicious process may interfere with attestation processing, for example to create a denial of service. The PIN CVM application attestation component should notify the monitoring environment if the response timeout is exceeded.

Modified p. 62

10. Attestation mechanisms must be provided and maintained with up- to-date information about known vulnerabilities to detect at a minimum: a. Modifications to the COTS platform OS firmware b. COTS ~~Platform~~ OS firmware tamper c. PIN CVM ~~Application~~ execution in developer mode d. PIN CVM ~~Application~~ execution in debug mode e. Emulator use f. Use of a hooking framework g. PIN CVM ~~Application~~ modification h. PIN CVM ~~Application~~ tamper

10. Attestation mechanisms must be provided and maintained with up- to-date information about known vulnerabilities to detect at a minimum: a. Modifications to the COTS platform OS firmware b. COTS platform OS firmware tamper c. PIN CVM application execution in developer mode d. PIN CVM application execution in debug mode e. Emulator use f. Use of a hooking framework g. PIN CVM application modification h. PIN CVM application tamper

Modified p. 62

i. Use of PIN CVM ~~Application~~ code, or part thereof, within another (valid and/or invalid) operational environment•e.g., through “code lifting” of the entire, or partial, application to another platform after initialization and personalization j. Asynchronous rooting and un-rooting of the COTS platform OS k. Relay attacks on PIN entry Specific data is required to ensure the security state of the COTS platform. Attestation parameters will vary depending on ~~operating systems~~ but should include basic verification and be as comprehensive as …

i. Use of PIN CVM application code, or part thereof, within another (valid and/or invalid) operational environment•e.g., through “code lifting” of the entire, or partial, application to another platform after initialization and personalization j. Asynchronous rooting and un-rooting of the COTS platform OS k. Relay attacks on PIN entry Specific data is required to ensure the security state of the COTS platform. Attestation parameters will vary depending on OSs but should include basic verification and be as comprehensive as possible.

Modified p. 62

It should not be possible to perform or enable remote screen display of the PIN CVM ~~Application~~ on another device (which is therefore not running the system attestation and monitoring).

It should not be possible to perform or enable remote screen display of the PIN CVM application on another device (which is therefore not running the system attestation and monitoring).

Modified p. 63

The attestation policy specifies when and how attestation should be performed. a. At PIN CVM ~~Application~~ startup At initialization ~~The Solution~~ should be in a trusted state, otherwise it may not be possible to trust any subsequent attestations. b. Before business processing commences (first transaction of the day) When ~~The Solution~~ is about to commence transaction processing, it should establish a trusted status for its components. c. If initiated by a monitoring environment request The monitoring environment should have the …

The attestation policy specifies when and how attestation should be performed. a. At PIN CVM application startup At initialization the solution should be in a trusted state, otherwise it may not be possible to trust any subsequent attestations. b. Before business processing commences (first transaction of the day) When the solution is about to commence transaction processing, it should establish a trusted status for its components. c. If initiated by a monitoring environment request The monitoring environment should have the …

Modified p. 64

1) The PIN CVM ~~Application~~ attestation component, with which the monitoring environment is communicating, is trusted; 2) The COTS platform is trusted; and 3) The monitoring environment is adequately prepared to take appropriate action.

1) The PIN CVM application attestation component, with which the monitoring environment is communicating, is trusted; 2) The COTS platform is trusted; and 3) The monitoring environment is adequately prepared to take appropriate action.

Modified p. 64

1. The PIN CVM ~~Application’s~~ attestation must meet requirements of Type 2 attestation.

1. The PIN CVM application’s attestation must meet requirements of Type 2 attestation.

Modified p. 64

2. The PIN CVM ~~Application~~ must support a set of attestation criteria that meet the attestation baseline.

2. The PIN CVM application must support a set of attestation criteria that meet the attestation baseline.

Modified p. 64

The ~~Solution~~ should provide mitigation again compromise of the attestation component that may result in DoS.

The solution should provide mitigation again compromise of the attestation component that may result in DoS.

Removed p. 65

As the security landscape changes, platforms or operating systems that may be acceptable under the system baseline may become vulnerable. A documented policy and procedure for assessing these changes should exist and provide details on how decisions are made to remove previously acceptable platforms from the system baseline. Such changes will affect the parties using these platforms, so the documentation should also include how communication is handled in these cases.

Modified p. 65

The attestation policy specifies when and how attestation should be performed. a. At system startup At initialization, ~~The Solution~~ should be in a trusted state; otherwise it may not be possible for the verifier to trust any subsequent attestations. b. Before business processing commences (first transaction of the day) When ~~The Solution~~ is about to commence transaction processing, it should establish a trusted status for its components. c. At unpredictable intervals, polled during an online session Re-occurring, unpredictable attestations ensure …

The attestation policy specifies when and how attestation should be performed. a. At system startup At initialization, the solution should be in a trusted state; otherwise it may not be possible for the verifier to trust any subsequent attestations. b. Before business processing commences (first transaction of the day) When the solution is about to commence transaction processing, it should establish a trusted status for its components. c. At unpredictable intervals, polled during an online session Re-occurring, unpredictable attestations ensure …

Modified p. 66

10. The ~~Solution Provider~~ must have a documented risk-assessment policy and procedures that provide details on:

10. The solution provider must have a documented risk-assessment policy and procedures that provide details on:

Modified p. 66

• The methods used to assess on-going risk of ~~The Solution;~~

• The methods used to assess on-going risk of the solution;

Modified p. 66

It is not considered acceptable for the policy to require a minimum number of PIN CVM ~~Applications~~ to be using a vulnerable platform before it is removed from the system baseline.

It is not considered acceptable for the policy to require a minimum number of PIN CVM applications to be using a vulnerable platform before it is removed from the system baseline.

Modified p. 66

It is not considered acceptable for the policy to require a minimum number of PIN CVM ~~Applications~~ to be using a vulnerable platform before it is removed from the system baseline.

It is not considered acceptable for the policy to require a minimum number of PIN CVM applications to be using a vulnerable platform before it is removed from the system baseline.

Modified p. 66

The ~~Solution Provider~~ should have a documented risk-assessment policy and procedure, which is reviewed at least annually.

The solution provider should have a documented risk-assessment policy and procedure, which is reviewed at least annually.

Modified p. 66

This policy should include the methods used to assess on-going risk of ~~The Solution,~~ how and when updates to the system baseline are performed, and how such changes are communicated to affected merchants.

This policy should include the methods used to assess on-going risk of the solution, how and when updates to the system baseline are performed, and how such changes are communicated to affected merchants.

Modified p. 66

11. Thresholds for minimum acceptable PIN CVM ~~Application~~ versions must be maintained by ~~The Solution Provider.~~

11. Thresholds for minimum acceptable PIN CVM application versions must be maintained by the solution provider.

Modified p. 66

A risk-assessment methodology must exist, be documented and followed to ensure that merchants are using the most current acceptable version of the PIN CVM ~~Application.~~

A risk-assessment methodology must exist, be documented and followed to ensure that merchants are using the most current acceptable version of the PIN CVM application.

Modified p. 66

In instances where a merchant is using an acceptable version, but it is not the current, there must be notifications sent to the merchant to require them to update it. PIN CVM ~~Applications~~ using a version that is not within the version threshold must not be permitted to accept PIN data.

In instances where a merchant is using an acceptable version, but it is not the current, there must be notifications sent to the merchant to require them to update it. PIN CVM applications using a version that is not within the version threshold must not be permitted to accept PIN data.

Modified p. 66

Installation of previous versions of the PIN CVM ~~Application~~ must not be permitted.

Installation of previous versions of the PIN CVM application must not be permitted.

Modified p. 66

The ~~Solution Provider~~ should maintain thresholds for minimum acceptable PIN CVM ~~Application~~ versions. A risk-assessment methodology should exist, documented and followed to ensure that merchants are using an acceptable version of the CVM app. For ~~example~~ in instances where a merchant is using an acceptable version, but not the current version, there should be notifications sent to the merchant to require it to update.

The solution provider should maintain thresholds for minimum acceptable PIN CVM application versions. A risk-assessment methodology should exist, documented and followed to ensure that merchants are using an acceptable version of the CVM app. For example, in instances where a merchant is using an acceptable version, but not the current version, there should be notifications sent to the merchant to require it to update.

Modified p. 66

A PIN CVM ~~Application~~ version that is not acceptable should not be permitted to accept PIN data.

A PIN CVM application version that is not acceptable should not be permitted to accept PIN data.

Modified p. 67

Implementation of industry-recognized logical and physical protections are necessary for the confidentiality, ~~integrity~~ and availability of ~~The Solution~~ back- end environments. Appropriate scoping and identification of controls assist with ensuring the back-end monitoring system and back-end attestation component environments are adequately protected.

Implementation of industry-recognized logical and physical protections are necessary for the confidentiality, integrity, and availability of the solution back- end environments. Appropriate scoping and identification of controls assist with ensuring the back-end monitoring system and back-end attestation component environments are adequately protected.

Modified p. 67

Prevents unauthorized communication and processes from the PIN CVM ~~Application~~ and SCRP to the back-end monitoring system and back-end attestation component from gaining access.

Prevents unauthorized communication and processes from the PIN CVM application and SCRP to the back-end monitoring system and back-end attestation component from gaining access.

Modified p. 67

Ensures that all traffic to/from authorized PIN CVM ~~Application~~ and SCRPs can be validated by back-end monitoring systems and back-end attestation component.

Ensures that all traffic to/from authorized PIN CVM application and SCRPs can be validated by back-end monitoring systems and back-end attestation component.

Modified p. 69

1. Mechanisms must exist to identify and validate the SCRP and PIN CVM ~~Application~~ as authorized prior to communication of any sensitive data between the SCRP and PIN CVM ~~Application.~~

1. Mechanisms must exist to identify and validate the SCRP and PIN CVM application as authorized prior to communication of any sensitive data between the SCRP and PIN CVM application.

Modified p. 69

The PIN CVM ~~Application~~ and SCRP should be uniquely identified and paired, and this pairing validated by the monitoring system at each startup of the application, as well as during any tamper- detection scans.

The PIN CVM application and SCRP should be uniquely identified and paired, and this pairing validated by the monitoring system at each startup of the application, as well as during any tamper- detection scans.

Modified p. 69

This will ensure that all communications are coming from a legitimate and authorized PIN CVM ~~Application~~ and SCRP.

This will ensure that all communications are coming from a legitimate and authorized PIN CVM application and SCRP.

Modified p. 69

If the CVM Application or SCRP fails in any way, the transaction should fail. This will ensure transactions will not be manipulated by any malicious activity. The back-end monitoring should be able to detect these failures and take appropriate action to block transactions coming from ~~COT’s,~~ CVM Applications or SCRPs where failures are occurring in real time.

If the CVM Application or SCRP fails in any way, the transaction should fail. This will ensure transactions will not be manipulated by any malicious activity. The back-end monitoring should be able to detect these failures and take appropriate action to block transactions coming from COTS, CVM Applications or SCRPs where failures are occurring in real time.

Modified p. 69

3. The back-end monitoring system must be able to accept and process attestation data from the SCRP and PIN CVM ~~Application~~ and take appropriate action based on predefined rules (for example, suspending transactions).

3. The back-end monitoring system must be able to accept and process attestation data from the SCRP and PIN CVM application and take appropriate action based on predefined rules (for example, suspending transactions).

Modified p. 69 → 70

Maintaining and using the current attestation data every time is important to ensure the integrity of the COTS, ~~SCRP~~ and PIN CVM ~~Application~~ to ensure that established controls have not been modified.

Maintaining and using the current attestation data every time is important to ensure the integrity of the COTS, SCRP, and PIN CVM application to ensure that established controls have not been modified.

Modified p. 70 → 71

The various components that make up ~~The Solution~~ exchange information between them. The secure channel used for that purpose should demonstrate data confidentiality and authenticity during the establishment and subsequent usage of the channel to ensure 1) data sent is the data received and 2) data sent is to the intended recipient. Ensure no secret or sensitive data is transferred between the devices prior to the establishment of the secure channel.

The various components that make up the solution exchange information between them. The secure channel used for that purpose should demonstrate data confidentiality and authenticity during the establishment and subsequent usage of the channel to ensure 1) data sent is the data received and 2) data sent is to the intended recipient. Ensure no secret or sensitive data is transferred between the devices prior to the establishment of the secure channel.

Modified p. 70 → 71

The ability to uniquely identify each of the channels established between the various components that make up the ~~software-based~~ PIN Entry Solution so that changes to these of components can be detected and potentially flagged as tamper events by the monitoring system.

The ability to uniquely identify each of the channels established between the various components that make up the software-based PIN Entry Solution so that changes to these of components can be detected and potentially flagged as tamper events by the monitoring system.

Modified p. 70 → 71

4. Documentation must exist and be maintained to identify logical connections between the PIN CVM ~~Application~~ and other components of the system.

4. Documentation must exist and be maintained to identify logical connections between the PIN CVM application and other components of the system.

Modified p. 70 → 71

Documentation of the connections between the various components that make up the ~~software-based~~ PIN Entry Solution will assist in the testing of ~~The Solution~~ as well as the subsequent implementation. It will help identify where each security control exists and how it has to be managed.

Documentation of the connections between the various components that make up the software-based PIN Entry Solution will assist in the testing of the solution as well as the subsequent implementation. It will help identify where each security control exists and how it has to be managed.

Modified p. 71 → 72

1. A user guide that provides information about ~~The Solution,~~ including identifying control points and security responsibilities for the merchant(s) must exist and be made available to the merchant.

1. A user guide that provides information about the solution, including identifying control points and security responsibilities for the merchant(s) must exist and be made available to the merchant.

Modified p. 71 → 72

Documentation to support the use and management of ~~The Solution~~ provides for common knowledge and definition of procedures to ensure the security controls are in place and functioning as intended.

Documentation to support the use and management of the solution provides for common knowledge and definition of procedures to ensure the security controls are in place and functioning as intended.

Modified p. 71 → 72

User guide information should address implementation and administration tasks associated with ~~The Solution~~ as well as guidance on maintenance for technical controls and processes.

User guide information should address implementation and administration tasks associated with the solution as well as guidance on maintenance for technical controls and processes.

Modified p. 71 → 72

2. The security assets of ~~The Solution~~ must be identified and managed. At a minimum, ~~The Solution Provider~~ must ensure identification of authorized SCRPs, linking SCRPs to the PIN CVM ~~Application~~ and back- end monitoring environment and verification that firmware/application updates are current.

2. The security assets of the solution must be identified and managed. At a minimum, the solution provider must ensure identification of authorized SCRPs, linking SCRPs to the PIN CVM application and back- end monitoring environment and verification that firmware/application updates are current.

Modified p. 71 → 72

3. The ~~Solution~~ must be “online,” connected to the back- end systems (monitoring, attestation component and processing) and in an operational state before initiating any PIN entry functions.

3. The solution must be “online,” connected to the back- end systems (monitoring, attestation component and processing) and in an operational state before initiating any PIN entry functions.

Modified p. 71 → 72

As most of the security controls and mechanisms involve the ability of ~~The Solution~~ to monitor and mitigate via controls located and coordinated by the back-end environment, the ability to be connected to the back-end environment is critical. Hence, connectivity is necessary between the PIN CVM ~~Application~~ and the back-end systems to facilitate execution of various controls including but not limited to attestation functions.

As most of the security controls and mechanisms involve the ability of the solution to monitor and mitigate via controls located and coordinated by the back-end environment, the ability to be connected to the back-end environment is critical. Hence, connectivity is necessary between the PIN CVM application and the back-end systems to facilitate execution of various controls including but not limited to attestation functions.

Modified p. 71 → 72

4. The SCRP and PIN CVM ~~Application~~ (including the attestation component) must have the ability to be identified as authorized and validated to the monitoring environment, by cryptographic means, before initiating a PIN entry session.

4. The SCRP and PIN CVM application (including the attestation component) must have the ability to be identified as authorized and validated to the monitoring environment, by cryptographic means, before initiating a PIN entry session.

Removed p. 72

As the security landscape changes, platforms or operating systems that may have been acceptable under the system baseline may become vulnerable. A documented policy and procedure for assessing these changes should exist and provide details on how decisions are made to remove previously acceptable platforms from the system baseline. The policy should also define how affected merchants using these platforms are notified and the plan to migrate them to the supported platform.

Modified p. 72 → 73

5. The ~~Solution~~ must incorporate a detection system or feed other detection systems capable of detecting anomalous and potentially fraudulent activity, including suspicious transactions.

5. The solution must incorporate a detection system or feed other detection systems capable of detecting anomalous and potentially fraudulent activity, including suspicious transactions.

Modified p. 72 → 73

6. Plans and procedures must be defined to address interruptions to ~~The Solution~~ due to unplanned business disruption, major disaster or failure of services.

6. Plans and procedures must be defined to address interruptions to the solution due to unplanned business disruption, major disaster or failure of services.

Modified p. 72 → 73

Adequate preparedness is necessary for business continuity of processing and security of ~~The Solution.~~

Adequate preparedness is necessary for business continuity of processing and security of the solution.

Modified p. 72 → 73

7. The ~~Solution Provider~~ must have a documented risk- assessment policy and procedure, which is reviewed at least annually.

7. The solution provider must have a documented risk- assessment policy and procedure, which is reviewed at least annually.

Modified p. 72 → 73

This policy must include the methods used to assess on-going risk of ~~The Solution~~ as well as how and when updates to the system baseline are performed and how such changes are communicated to affected merchants.

This policy must include the methods used to assess on-going risk of the solution as well as how and when updates to the system baseline are performed and how such changes are communicated to affected merchants.

Modified p. 72 → 73

The ~~Solution Provider~~ cannot use the number of merchants using a vulnerable platform as the only criterion to ~~remove~~ a vulnerable platform ~~from~~ the approved list of system baseline.

The solution provider cannot use the number of merchants using a vulnerable platform as the only criterion to keep a vulnerable platform on the approved list of system baseline.

Modified p. 73 → 74

8. A threat-management process must be established to monitor for newly discovered vulnerabilities that may impact the security of ~~The Solution.~~

8. A threat-management process must be established to monitor for newly discovered vulnerabilities that may impact the security of the solution.

Modified p. 73 → 74

• Ensure that the vulnerability does not change the baseline integrity of ~~The Solution.~~

• Ensure that the vulnerability does not change the baseline integrity of the solution.

Modified p. 73 → 74

9. The ~~Solution~~ configuration and release management process must be integrated with the threat management process. The firmware- and software- release process must take input from the threat- management process on the development of the minimum viable product (MVP).

9. The solution configuration and release management process must be integrated with the threat management process. The firmware- and software- release process must take input from the threat- management process on the development of the minimum viable product (MVP).

Modified p. 73 → 74

Given the dynamic nature of the software risk/vulnerability discovery process, ~~The Solution Provider~~ is expected to have a tightly integrated process where the development team and the threat management team are closely collaborating to identify and mitigate any threats to their solution and environment.

Given the dynamic nature of the software risk/vulnerability discovery process, the solution provider is expected to have a tightly integrated process where the development team and the threat management team are closely collaborating to identify and mitigate any threats to their solution and environment.

Modified p. 73 → 74

10. The ~~PIN CVM Solution~~ Provider must provide the ~~PCI-approved~~ lab with a test platform to evaluate ~~The Solution.~~

10. The the solution Provider must provide the PCI- approved lab with a test platform to evaluate the solution.

Modified p. 73 → 74

This test platform must be developed in a manner that provides full accessibility and visibility into ~~The Solution.~~ The test platform must provide an interface or a report that would enable an external company to validate the detection of potential vulnerabilities present on systems used in the testing.

This test platform must be developed in a manner that provides full accessibility and visibility into the solution. The test platform must provide an interface or a report that would enable an external company to validate the detection of potential vulnerabilities present on systems used in the testing.

Modified p. 75 → 76

The ~~Solution~~ has outlined specific technical and procedural controls to protect the secrecy of PIN and cardholder data. Therefore, decryption of this information should only be performed in environments designated and authorized to perform these functions. The back-end payment and PIN-processing environments require security controls that are separate and distinct from this standard to address the risks of clear-text data in those environments.

The solution has outlined specific technical and procedural controls to protect the secrecy of PIN and cardholder data. Therefore, decryption of this information should only be performed in environments designated and authorized to perform these functions. The back-end payment and PIN-processing environments require security controls that are separate and distinct from this standard to address the risks of clear-text data in those environments.

Removed p. 76

• Should not provide the physical interface necessary for reading magnetic-stripe cards.

Modified p. 76 → 77

1. The ~~Solution~~ must require the use of a PCI PTS approved SCRP for the COTS device for EMV chip cards.

1. The solution must require the use of a PCI PTS approved SCRP for the COTS device for EMV chip cards.

Modified p. 76 → 77

SCRP is a PTS approval class that supports PIN entry on a COTS device according to these requirements. Characteristics of SCRP include:

SCRP is a PTS approval class that supports software-based PIN entry for EMV transactions on a COTS device according to these requirements. Characteristics of SCRP include:

Modified p. 76 → 77

• Has the ability to receive an encrypted PIN from the PIN CVM ~~Application.~~

• Has the ability to receive an encrypted PIN from the PIN CVM application.

Modified p. 77 → 81

• A process for performing business-impact analysis to determine potential security and compliance impacts for strategic business decisions Establishing a governance program that monitors the health of its security controls allows the organization to be proactive in the event that a control fails within ~~The Solution.~~ It supports effectively communicating activities and statuses throughout the organization.

• A process for performing business-impact analysis to determine potential security and compliance impacts for strategic business decisions Establishing a governance program that monitors the health of its security controls allows the organization to be proactive in the event that a control fails within the solution. It supports effectively communicating activities and statuses throughout the organization.

Modified p. 77 → 81

The program can be a dedicated program or incorporated into an over-arching compliance and/or governance program. It should include a well-defined methodology that demonstrates consistent and effective evaluation. Example methodologies include: Deming Circle of Plan-Do-Check-Act (PDCA), ISO 27001, COBIT, ~~DMAIC~~ and Six Sigma.

The program can be a dedicated program or incorporated into an over-arching compliance and/or governance program. It should include a well-defined methodology that demonstrates consistent and effective evaluation. Example methodologies include: Deming Circle of Plan-Do-Check-Act (PDCA), ISO 27001, COBIT, DMAIC, and Six Sigma.

Modified p. 78 → 81

An organization’s structure and management define the requirements and protocol for effective and secure operations of the monitoring environment. Changes to this structure could have negative effects to the processing and security of the environment by reallocating or removing resources that once supported ~~The Solution.~~ Therefore, it is important to revisit monitoring environment scope and controls when there are changes to ensure to management structure to ensure required controls are in place and active.

An organization’s structure and management define the requirements and protocol for effective and secure operations of the monitoring environment. Changes to this structure could have negative effects to the processing and security of the environment by reallocating or removing resources that once supported the solution. Therefore, it is important to revisit monitoring environment scope and controls when there are changes to ensure to management structure to ensure required controls are in place and active.

Modified p. 78 → 82

Organizations require processes to determine the potential impact that changes introduce to systems and networks within monitoring environment to ensure ~~the~~ do not negatively impact the security of the monitoring environment.

Organizations require processes to determine the potential impact that changes introduce to systems and networks within monitoring environment to ensure they do not negatively impact the security of the monitoring environment.

Removed p. 80

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

Modified p. 80 → 83

Controls should 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

Controls should be implemented at the perimeter and critical systems points. The controls 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 •should be configured, maintained and updated per vendor instructions to ensure optimal protection.

Modified p. 82 → 85

Internal vulnerability scans can be performed by qualified, internal staff or outsourced to a qualified third party. For scans managed by the entity, the entity should ensure that scanning engines and vulnerability fingerprints are up to ~~date~~ and the scanning engine configured in accordance with vendor guidance documentation.

Internal vulnerability scans can be performed by qualified, internal staff or outsourced to a qualified third party. For scans managed by the entity, the entity should ensure that scanning engines and vulnerability fingerprints are up to date, and that the scanning engine is configured in accordance with vendor guidance documentation.

Modified p. 82 → 85

Personnel should have sufficient knowledge to review and understand the scan results, and determine appropriate remediation. Internal personnel that interact with the ASV should also be knowledgeable in the network architecture and implemented security controls, in order to provide the ASV with information needed to complete the scan.

Personnel should have sufficient knowledge to review and understand the scan results, and to determine appropriate remediation. Internal personnel that interact with the ASV should also be knowledgeable in the network architecture and implemented security controls, in order to provide the ASV with information needed to complete the scan.

Modified p. 83 → 86

The penetration-testing methodology should be based on industry-accepted approaches and incorporate both application-layer and network-layer testing. The scope of testing should cover the monitoring environment perimeter and critical systems, and include testing from both inside and outside the network.

The penetration-testing methodology should be based on industry-accepted approaches and incorporate both application-layer and network-layer testing. The scope of testing should cover the monitoring environment perimeter and critical systems, and it should include testing from both inside and outside the network.

Modified p. 84 → 87

Implemented controls should protect the confidentiality and integrity of accounts for both local and remote ~~users~~ The controls should include ensuring that account and credential information is securely transmitted and stored at all times.

Implemented controls should protect the confidentiality and integrity of accounts for both local and remote users. The controls should include ensuring that account and credential information is securely transmitted and stored at all times.

Modified p. 90 → 93

Ongoing review ensures timely identification and response to prevent losses.

Ongoing review ensures timely identification and response to prevent losses. 5. Audit logs must be protected to prevent modification or deletion. Malicious users attempt to hide their presence and activity by changing audit log entries. It is imperative that the integrity of audit logs is preserved.

Modified p. 94 → 97

• Each private key must be statistically unique, unpredictable and created using an approved ~~random number generator~~ as described in this document.

• Each private key must be statistically unique, unpredictable and created using an approved RNG as described in this document.

Modified p. 96 → 101

Good source-code control practices help ensure that all changes to code are intended and authorized, and performed only by those with a legitimate reason to change the code. Examples of these practices include check-in and checkout procedures for code with strict access controls, and a comparison immediately before updating code to confirm that the last approved version has not been changed (for example, using a checksum).

Good source-code control practices help ensure that all changes to code are intended and authorized, and that changes are performed only by those with a legitimate reason to change the code. Examples of these practices include check-in and checkout procedures for code with strict access controls, and a comparison immediately before updating code to confirm that the last approved version has not been changed (for example, using a checksum).

Modified p. 99 → 105

10. Risk assessment techniques (for example, application ~~threat-modeling)~~ must be used to identify potential application security design flaws and vulnerabilities during the software-development process. Risk assessment processes include the following:

10. Risk assessment techniques (for example, application threat-modelling) must be used to identify potential application security design flaws and vulnerabilities during the software-development process. Risk assessment processes include the following:

Modified p. 100 → 106

Developers knowledgeable of vulnerabilities within their own applications or in underlying components should then be able to resolve those vulnerabilities prior to ~~release,~~ or implement other mechanisms to reduce the likelihood that the vulnerability may be exploited in the event a third-party security patch is not immediately available.

Developers knowledgeable of vulnerabilities within their own applications or in underlying components should then be able to resolve those vulnerabilities prior to release or implement other mechanisms to reduce the likelihood that the vulnerability may be exploited in the event a third-party security patch is not immediately available.

Document Comparison

Content Changes