Document Diff - PCI Watch

Added p. 1

Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC)™ Technical FAQs for use with SPoC 1.1 Version 1.8

Added p. 3

December 2021 1.8 Added Q15 to clarify the term “assessed RNG”. Added Q16 to clarify when the usages of TDES is allowed. Updated Q19 to clarify the scope of WBC keys. Added Q28 to clarify the expected logical and physical testing of COTS devices. Added Q29 to clarify a use-case where back-end attestation and monitoring systems are hosted in multiple environments or hosted by multiple entities. Added Q30 to clarify the onsite assessment requirements. Added Q46 to describe the process to delay SPoC solution listing.

Added p. 8

SPoC Security Requirement 1.2

Q 15 [December 2021] What is an assessed or validated RNG, and what is expected from a SPoC lab when evaluating a SPoC solution? A There are two types of RNGs: Deterministic Random Number Generator (DRNG) and Non-deterministic Random Number Generator (NRNG). Typically, DRNG uses an initial seed value from an NRNG to generate deterministic random values.

The entropy used for an NRNG must meet the requirements in NIST SP 800-90B or §8 of ISO/IEC 18031 Information technology

• Security techniques

• Security techniques

• Random bit generation.

• Random bit generation.

Many COTS platforms implement their own RNG functions, however not all meet the security requirements as noted in SPoC standard. The implementation of DRNG for security services must meet the following criteria:

• Implements a well-known standard, such as those specified in NIST SP800-90a or §9 of ISO/IEC 18031 Information technology

SPoC Security Requirement 1.3

• Properly seeded (per SPoC security requirement 1.2.2 and …

Added p. 13

Q 28 [December 2021] What is expected from SPoC labs regarding physical and logical testing of the COTS devices? A While there is no expectation to perform physical or logical testing of a COTS device itself, SPoC labs must confirm whether COTS platforms included in the COTS system baseline have known characteristics, such as physical test, debug, or in-circuit emulation features. For example, some Android mobile devices have an NFC logging service, which is intended to be used for debugging purposes. Other COTS devices may produce unique responses based on the COTS platform chipset when used with Android Debug Bridge (ADB), which can be exploited when physically connected to the mobile device.

The SPoC lab is expected to have the expertise and knowledge of such features. Depending on the COTS platforms that the SPoC solution supports, the SPoC lab should use its expertise and knowledge to consider what attack methods should …

Added p. 15

Q 35 What API or software library implementation options can be supported by the SPoC solution? A Whether an implementation of an API or a software library can be supported by the SPoC Program depends largely on whether an SPoC lab can validate the exposed API or a library to SPoC Security Requirements and SPoC Test Requirements.

Added p. 19

Q 46 [December 2021] Can a SPoC Solution Listing be delayed at a vendor’s request? A Yes, solution providers may choose to delay listing a newly approved SPoC solution for up to a maximum of six calendar months. Written notification to PCI SSC must be submitted by the SPoC solution provider, through the SPoC laboratory performing the evaluation, along with the completed SPoC Evaluation Report. In addition, the SPoC lab must make a notation in the applicable field of the Lab Report Portal when submitting the evaluation report, indicating the period of time the listing should be withheld. Delaying listing does not extend the solution’s validation period; annual checkpoint and solution reevaluation dates will be based on the date of the countersigned AOV, not the date on which the solution is listed. A solution is not considered to be a validated SPoC solution until it is listed on the PCI …

Modified p. 6 → 7

These elements work together to ensure the PIN, which has been accepted by a software application on the COTS device, is isolated within the COTS device from other sensitive account data. The back-end monitoring/attestation systems monitor the entire solution continuously for anomalous activity and to ensure that the solution has not deviated from the baseline due to tampering, rooting, or physical attacks. In other words, within an SPoC solution, the merchant-facing COTS device is only one element in the entire …

An SPoC solution includes a Secure Card Reader

• PIN (SCRP), a PIN CVM application, the merchant’s COTS device, and back-end monitoring/attestation systems. These elements work together to ensure the PIN, which has been accepted by a software application on the COTS device, is isolated within the COTS device from other sensitive account data. The back-end monitoring/attestation systems monitor the entire solution continuously for anomalous activity and to ensure that the solution has not deviated from the baseline due to tampering, …

Modified p. 8 → 9

Q 16 Does Security Requirement 2.2.3 include OS level or other system applications? A No. This requirement is not intended for OS level or other system applications.

Q 18 Does Security Requirement 2.2.3 include OS level or other system applications? A No. This requirement is not intended for OS level or other system applications.

Modified p. 8 → 10

Q 17 Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure-provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM application, or just those used for ~~encrypting~~ a ~~PIN?~~ A The intent of the requirement is that where white-box cryptography is ~~used,~~ …

Q 19 [December 2021] Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure-provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM application, or just those used for protecting keys associated with a PIN encryption? A The intent of the requirement is …

Modified p. 8 → 10

Q 18 Security Requirement 2.4.2 states that the PIN CVM application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use COTS platform sensors and hardware for side-channel attacks, detecting when these sensors are activated or used (i.e., polling sensor data) by untrusted applications can reduce the risk of PIN compromise.

Q 20 Security Requirement 2.4.2 states that the PIN CVM application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use COTS platform sensors and hardware for side-channel attacks, detecting when these sensors are activated or used (i.e., polling sensor data) by untrusted applications can reduce the risk of PIN compromise.

Modified p. 9 → 10

Q ~~19 [May 2021]~~ If a version of the COTS OS initially listed in the solution system baseline reaches end-of-life such that it is no longer supported by the original OS vendor, does the SPoC Standard disallow transactions on affected COTS devices until the OS on those devices is updated to a supported OS? A Yes. Security Requirement 2.2.2 mandates that PIN CVM Applications are developed only for supported COTS platforms, and Security Requirement 3.1.6 mandates that COTS devices using …

Q 21 If a version of the COTS OS initially listed in the solution system baseline reaches end-of-life such that it is no longer supported by the original OS vendor, does the SPoC Standard disallow transactions on affected COTS devices until the OS on those devices is updated to a supported OS? A Yes. Security Requirement 2.2.2 mandates that PIN CVM Applications are developed only for supported COTS platforms, and Security Requirement 3.1.6 mandates that COTS devices using unsupported OS …

Modified p. 9 → 11

Q 20 If an OS vendor issues an update to a COTS OS that was initially listed in the solution system baseline, does the SPoC Standard disallow transactions on COTS devices using the updated OS until the updated SPoC solution is evaluated? A When an OS vendor releases a minor update to the COTS OS included in the SPoC solution system baseline, the solution provider may support the additional COTS OS version as long as it does not increase the …

Q 22 If an OS vendor issues an update to a COTS OS that was initially listed in the solution system baseline, does the SPoC Standard disallow transactions on COTS devices using the updated OS until the updated SPoC solution is evaluated? A When an OS vendor releases a minor update to the COTS OS included in the SPoC solution system baseline, the solution provider may support the additional COTS OS version as long as it does not increase the …

Modified p. 10 → 11

Q 21 Security Requirement 3.2.13 states that for manual updates to the attestation system, any deployment changes to the production environment require dual control. Is dual control necessary for attestation system components associated with the PIN CVM application recognizing that such applications are signed by the OS app store and not under the control of the solution provider? A While it is acknowledged that the signing of a PIN CVM application made available from the OS app stores is not …

Q 23 Security Requirement 3.2.13 states that for manual updates to the attestation system, any deployment changes to the production environment require dual control. Is dual control necessary for attestation system components associated with the PIN CVM application recognizing that such applications are signed by the OS app store and not under the control of the solution provider? A While it is acknowledged that the signing of a PIN CVM application made available from the OS app stores is not …

Modified p. 11 → 12

Q 24 Test Requirement TB2.5 calls for the disabling of on-device sensors during PIN entry. Does this requirement apply to all COTS platforms? A The SPoC Standard does not require on-device sensors to be disabled during PIN entry. This requirement applies only if the solution provider implemented programmatic methods, manual processes (for example, prompting the end-user to disable a sensor), or a combination of both, to disable on-device sensors.

Q 26 Test Requirement TB2.5 calls for the disabling of on-device sensors during PIN entry. Does this requirement apply to all COTS platforms? A The SPoC Standard does not require on-device sensors to be disabled during PIN entry. This requirement applies only if the solution provider implemented programmatic methods, manual processes (for example, prompting the end-user to disable a sensor), or a combination of both, to disable on-device sensors.

Modified p. 11 → 12

Q 25 Can an SPoC solution be associated with and communicate with multiple SCRPs or MSRs concurrently? A Yes. An SPoC solution is permitted to support the use of multiple SCRPs or MSRs that meet the security and testing requirements described in the Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex. The use of multiple SCRPs or MSRs in the SPoC solution is optional. The back-end monitoring system must be able to interact with each …

Q 27 Can an SPoC solution be associated with and communicate with multiple SCRPs or MSRs concurrently? A Yes. An SPoC solution is permitted to support the use of multiple SCRPs or MSRs that meet the security and testing requirements described in the Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex. The use of multiple SCRPs or MSRs in the SPoC solution is optional. The back-end monitoring system must be able to interact with each …

Modified p. 11 → 14

Q ~~26 [May 2021]~~ When does the SPoC Unsupported OS Annex apply? A The security objectives outlined in the SPoC Unsupported OS Annex are optional, and the security controls are required only for solutions that include unsupported OSes in their COTS system baseline. For example, a solution provider may decide to include an unsupported COTS OS in the COTS system baseline of its initial evaluation, or to retain a previously supported COTS OS that became unsupported during the annual checkpoint.

Q 31 When does the SPoC Unsupported OS Annex apply? A The security objectives outlined in the SPoC Unsupported OS Annex are optional, and the security controls are required only for solutions that include unsupported OSes in their COTS system baseline. For example, a solution provider may decide to include an unsupported COTS OS in the COTS system baseline of its initial evaluation, or to retain a previously supported COTS OS that became unsupported during the annual checkpoint.

Modified p. 12 → 14

Q ~~27 [May 2021]~~ Can an “objective-based” approach be used for security requirements and test requirements in the SPoC Standard? A The objective-based approach is intended only for evaluating security controls and processes implemented by an SPoC solution provider, as outlined in the SPoC Unsupported OS Annex, to protect the integrity and confidentiality of a PIN entered on COTS devices running an unsupported operating system.

Q 32 Can an “objective-based” approach be used for security requirements and test requirements in the SPoC Standard? A The objective-based approach is intended only for evaluating security controls and processes implemented by an SPoC solution provider, as outlined in the SPoC Unsupported OS Annex, to protect the integrity and confidentiality of a PIN entered on COTS devices running an unsupported operating system.

Modified p. 12 → 14

Q ~~28 [May 2021]~~ Can APIs (i.e., software libraries allowing third parties to interface with the SPoC solution) be validated and listed as part of an SPoC solution? A Yes. In cases where the SPoC solution provider offers libraries or APIs to allow third parties to interface to the solution, evaluation and validation by a SPoC Lab is required as part of each SPoC solution in which such APIs are provided in order to validate that usage of the API …

Q 33 Can APIs (i.e., software libraries allowing third parties to interface with the SPoC solution) be validated and listed as part of an SPoC solution? A Yes. In cases where the SPoC solution provider offers libraries or APIs to allow third parties to interface to the solution, evaluation and validation by a SPoC Lab is required as part of each SPoC solution in which such APIs are provided in order to validate that usage of the API can be …

Modified p. 12 → 15

Q 29 What is expected from an SPoC lab when evaluating an SPoC solution that offers APIs or software libraries to allow third-party developers to interface with the SPoC solution? A The evaluation and validation of the APIs (together with the SPoC user guidance document described and defined in the SPoC Program Guide) by an SPoC lab are required as part of each SPoC solution in which such libraries or APIs are provided. It is expected the SPoC lab validates …

Q 34 What is expected from an SPoC lab when evaluating an SPoC solution that offers APIs or software libraries to allow third-party developers to interface with the SPoC solution? A The evaluation and validation of the APIs (together with the SPoC user guidance document described and defined in the SPoC Program Guide) by an SPoC lab are required as part of each SPoC solution in which such libraries or APIs are provided. It is expected the SPoC lab validates …

Removed p. 13

Q 30 [NEW] What API or software library implementation options can be supported by the SPoC solution? A Whether an implementation of an API or a software library can be supported by the SPoC Program depends largely on whether an SPoC lab can validate the exposed API or a library to SPoC Security Requirements and SPoC Test Requirements.

Modified p. 13 → 16

Moreover, when certain SPoC functionality is distributed as a software library or source code, the SPoC solution provider has little to no control over how the library is compiled into the third-party payment application, how the functionality is invoked, and how the third-party payment application is distributed to the end-users. In such cases, the API would not be fully validated for listing as part of the SPoC solution on the PCI SSC website.

A solution can include APIs or libraries that cannot be fully validated by an SPoC Lab. Therefore, some implementation options may not be supported by the SPoC Program. For example, if an API or software library is developed by the SPoC solution provider but signed by a third-party software vendor, or distributed as a library or a source code, the SPoC lab would not be able to perform several test requirements to confirm whether processes such as the signing of …

Modified p. 14 → 16

Q 31 Can an SPoC lab reference an approval from another PCI SSC standard, such as

Q 36 Can an SPoC lab reference an approval from another PCI SSC standard, such as

Modified p. 14 → 16

Q 32 Can testing results be reused from one evaluation to another of the same vendor? A Yes. Testing from one SPoC evaluation can be reused in another SPoC evaluation from the same solution provider. This situation occurs commonly when two SPoC solutions with similar characteristics are evaluated by the same laboratory in parallel or in close succession. The reused data must be current (less than 12 months old) and must have been completed under the same major version of …

Q 37 Can testing results be reused from one evaluation to another of the same vendor? A Yes. Testing from one SPoC evaluation can be reused in another SPoC evaluation from the same solution provider. This situation occurs commonly when two SPoC solutions with similar characteristics are evaluated by the same laboratory in parallel or in close succession. The reused data must be current (less than 12 months old) and must have been completed under the same major version of …

Modified p. 15 → 17

Q 35 How does a minor update to the SPoC Standard affect the expiry date of listed SPoC solutions? A Minor updates of the SPoC Standard (e.g., from version 1.0 to version 1.1) do not change the expiry dates for listed SPoC solutions; they remain as three years from the initial acceptance/listing date shown on the PCI SSC website.

Q 40 How does a minor update to the SPoC Standard affect the expiry date of listed SPoC solutions? A Minor updates of the SPoC Standard (e.g., from version 1.0 to version 1.1) do not change the expiry dates for listed SPoC solutions; they remain as three years from the initial acceptance/listing date shown on the PCI SSC website.

Modified p. 15 → 17

Q 36 Can a Delta change be submitted to update a listed SPoC solution between minor versions of the SPoC Standard? A Yes, the change is submitted to an SPoC lab and it is up to the SPoC lab to determine whether the extent of the change(s) can be validated via delta evaluation. If the changes are extensive or highly impactful to the SPoC security requirements, the SPoC lab may determine that a full evaluation is required. Note that all …

Q 41 Can a Delta change be submitted to update a listed SPoC solution between minor versions of the SPoC Standard? A Yes, the change is submitted to an SPoC lab and it is up to the SPoC lab to determine whether the extent of the change(s) can be validated via delta evaluation. If the changes are extensive or highly impactful to the SPoC security requirements, the SPoC lab may determine that a full evaluation is required. Note that all …

Modified p. 15 → 18

Q 37 Can an Administrative change be submitted to transition a listed SPoC solution from SPoC Standard? A No, Administrative changes cannot be used to transition between versions of the SPoC Standard - a full or delta change evaluation, as determined by the SPoC lab, must be performed.

Q 42 Can an Administrative change be submitted to transition a listed SPoC solution from SPoC Standard? A No, Administrative changes cannot be used to transition between versions of the SPoC Standard - a full or delta change evaluation, as determined by the SPoC lab, must be performed.

Modified p. 15 → 18

Q 38 What happened to “Designated Change” in the SPoC Program Guide? A Designated changes have been incorporated into the delta change process in SPoC Program Guide version 1.2 to help simplify the change and listing process.

Q 43 What happened to “Designated Change” in the SPoC Program Guide? A Designated changes have been incorporated into the delta change process in SPoC Program Guide version 1.2 to help simplify the change and listing process.

Modified p. 16 → 18

Q ~~39 [May 2021]~~ What testing and reporting are expected to be performed by SPoC lab as part of an annual checkpoint? A The annual checkpoint confirms that the SPoC solution continues to meet the security and test requirements of the SPoC Standard. The amount of testing that is required will vary. At a minimum, however, the SPoC lab must confirm that:

Q 44 What testing and reporting are expected to be performed by SPoC lab as part of an annual checkpoint? A The annual checkpoint confirms that the SPoC solution continues to meet the security and test requirements of the SPoC Standard. The amount of testing that is required will vary. At a minimum, however, the SPoC lab must confirm that:

Document Comparison

Content Changes