Document Comparison
PCI_PTS_POI_DTRs_v4-1b.pdf
→
PCI_PTS_PO__DTRs_v5-1.pdf
70% similar
219 → 258
Pages
85018 → 103386
Words
654
Content Changes
Content Changes
654 content changes. 303 administrative changes (dates, page numbers) hidden.
Added
p. 3
June 2016 5.x RFC version
September 2016 5.0 Public release
March 2018 5.1 Modified B4, B9, B12, D1, D4, K1, K4, K12, and K16, and added K24 for SCRP approval class. Modified A1, A4, A5, A8, B2, F1, K1.1, and K11.2. Reorganized B20 and added reference to example of Security Policy layout in Appendix H. Modified side-channel testing appendix. Errata.
September 2016 5.0 Public release
March 2018 5.1 Modified B4, B9, B12, D1, D4, K1, K4, K12, and K16, and added K24 for SCRP approval class. Modified A1, A4, A5, A8, B2, F1, K1.1, and K11.2. Reorganized B20 and added reference to example of Security Policy layout in Appendix H. Modified side-channel testing appendix. Errata.
Added
p. 7
• DTR Module 1: Core Requirements
• DTR Module 2: POS Terminal Integration Requirements
• DTR Module 3: Open Protocols Derived Test Requirements
• DTR Module 4: Secure Reading and Exchange of Data Requirements
• DTR Module 5: Device Management Security Requirements Structure of the DTRs Each PCI requirement as stated in the PCI PTS POI Security Requirements is represented by a subsection. For example, Requirement A1 is represented in this document as:
Reporting Requirements for PTS Laboratories To be acceptable for reviewing, evaluation reports must present evidence of a device’s compliance to the Security Requirements. Before releasing a new test report, a delta report, or any updated report version, the lab must perform a thorough technical and quality assurance review to ensure that:
• The report accurately provides information specified in this document, without ambiguous or inconsistent information.
• The report and device details are complete and accurate.
• The report Includes information relevant to any applicable …
• DTR Module 2: POS Terminal Integration Requirements
• DTR Module 3: Open Protocols Derived Test Requirements
• DTR Module 4: Secure Reading and Exchange of Data Requirements
• DTR Module 5: Device Management Security Requirements Structure of the DTRs Each PCI requirement as stated in the PCI PTS POI Security Requirements is represented by a subsection. For example, Requirement A1 is represented in this document as:
Reporting Requirements for PTS Laboratories To be acceptable for reviewing, evaluation reports must present evidence of a device’s compliance to the Security Requirements. Before releasing a new test report, a delta report, or any updated report version, the lab must perform a thorough technical and quality assurance review to ensure that:
• The report accurately provides information specified in this document, without ambiguous or inconsistent information.
• The report and device details are complete and accurate.
• The report Includes information relevant to any applicable …
Added
p. 9
• References to relevant information in the overview sections of the evaluation report, and to other DTRs where appropriate;
• Descriptions of the vendor’s attestations of compliance to security requirements, with
• Descriptions of information and assistance provided by the vendor to support the evaluation;
• Accurate descriptions of relevant device attributes, for example (but not restricted to): physical and logical protections, chip architecture, OS, etc.
• Detailed explanations of the scope and focus of test activities and attack hypotheses, including explanations of white-box or black-box approaches used, and why;
• Details of decisions made for performing penetration testing, the methodologies used, and the results of penetration testing;
• Justifications for any reliance on test evidence not derived directly from the evaluation activities;
• Explanations for any conclusions based on theoretical analysis instead of applied testing; The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions …
• Descriptions of the vendor’s attestations of compliance to security requirements, with
• Descriptions of information and assistance provided by the vendor to support the evaluation;
• Accurate descriptions of relevant device attributes, for example (but not restricted to): physical and logical protections, chip architecture, OS, etc.
• Detailed explanations of the scope and focus of test activities and attack hypotheses, including explanations of white-box or black-box approaches used, and why;
• Details of decisions made for performing penetration testing, the methodologies used, and the results of penetration testing;
• Justifications for any reliance on test evidence not derived directly from the evaluation activities;
• Explanations for any conclusions based on theoretical analysis instead of applied testing; The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions …
Added
p. 13
TA1.13 For each tamper switch used in the POI, the tester shall complete the details indicated in the table below, at a minimum. (See Annex A of the Vendor Questionnaire.) The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack (such as being covered by a flexible tamper grid, or having a unique construction) Switch Location Number Used in that Location Physical Implementation Size of Switch Conductive Ink Protections Additional Comments TA1.14 The tester shall describe what testing was performed to validate the protection provided by each of the tamper switches enumerated above.
See the “Attack Examples” section of Appendix B for detailed examples of appropriate presentation of attack calculations.
TA1.31 The tester shall verify that no attack was able to be determined, including those outlined above, which could be performed for less than 26 points …
See the “Attack Examples” section of Appendix B for detailed examples of appropriate presentation of attack calculations.
TA1.31 The tester shall verify that no attack was able to be determined, including those outlined above, which could be performed for less than 26 points …
Added
p. 18
TA3.8 If additional memory is implemented and is not included in the sensitive-information storage areas above, the tester shall detail what processes have been used to validate that this is the case. The tester shall detail all memory in the device and detail where sensitive data is stored and how it is protected.
TA3.13 The tester shall analyze the device’s susceptibility to glitch attacks, including, but not restricted to, voltage and EM glitching. At a minimum, the tester shall consider the core and battery input for the security processor. Where applicable, the tester shall also consider embedded memory (SRAM, EEPROM, Flash, and ROM).
Devices that use a randomized touch-screen layout
•i.e., for each PIN entry the positioning of the digits is different
•the signals should not contain any information that leads to PIN leakage.
TA4.9 Using suitable microphones, the tester shall use the microphones to monitor the acoustic signals of the POI when pressing each …
TA3.13 The tester shall analyze the device’s susceptibility to glitch attacks, including, but not restricted to, voltage and EM glitching. At a minimum, the tester shall consider the core and battery input for the security processor. Where applicable, the tester shall also consider embedded memory (SRAM, EEPROM, Flash, and ROM).
Devices that use a randomized touch-screen layout
•i.e., for each PIN entry the positioning of the digits is different
•the signals should not contain any information that leads to PIN leakage.
TA4.9 Using suitable microphones, the tester shall use the microphones to monitor the acoustic signals of the POI when pressing each …
Added
p. 24
TA5.13 Referring to the information provided in DTR A3, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the POI cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.
Added
p. 27
TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS POI Security Requirements for consistency relevant to A8. The vendor responses should clearly indicate how visual observation deterrents are provided. The tester shall summarize the responses.
Demonstrating compliance to this requirement requires the inclusion of high-resolution images and/or diagrams showing the magnetic-stripe reader and its location.
TA8.9 The tester shall identify whether the device implements any physical or logical ICCR/MSR combinations•for example, if the hybrid reader facilitates both skimming of the magnetic stripe and capture of the PIN during an ICCR “dip” read operation. In this case, the tester shall describe how there is no residual vulnerability to attacks on the combination reader intending to harvest both clear-text PINs and magnetic-stripe data.
TA8.10 The tester shall describe and provide the most feasible costing for …
Demonstrating compliance to this requirement requires the inclusion of high-resolution images and/or diagrams showing the magnetic-stripe reader and its location.
TA8.9 The tester shall identify whether the device implements any physical or logical ICCR/MSR combinations•for example, if the hybrid reader facilitates both skimming of the magnetic stripe and capture of the PIN during an ICCR “dip” read operation. In this case, the tester shall describe how there is no residual vulnerability to attacks on the combination reader intending to harvest both clear-text PINs and magnetic-stripe data.
TA8.10 The tester shall describe and provide the most feasible costing for …
Added
p. 37
TB2.6 Where a complex operating system (such as Linux, other *nix variants, and operating systems such as Android) is used, the tester shall verify that ASLR is enabled and correctly configured. For Linux, this means setting “randomize_va_space” to a value of “2,” and ensuring that all code is correctly compiled (and/or configured) to implement and enable ASLR.
The source code review should be targeted on relevant security-critical functionalities such as (but not restricted to): buffer overflows; unhandled exceptions, read-access violations, and denial-of-service conditions, etc., including factors that are specific to the POI’s OS, communications protocols, and source code software language(s).
TB2.11 For systems that are designed to execute non-firmware applications, the vendor shall provide a test application to be run into the device containing a buffer-overflow vulnerability, together with the application’s source code. The tester shall run the application and determine if the device fails securely.
TB2.12 The tester shall execute a vulnerability …
The source code review should be targeted on relevant security-critical functionalities such as (but not restricted to): buffer overflows; unhandled exceptions, read-access violations, and denial-of-service conditions, etc., including factors that are specific to the POI’s OS, communications protocols, and source code software language(s).
TB2.11 For systems that are designed to execute non-firmware applications, the vendor shall provide a test application to be run into the device containing a buffer-overflow vulnerability, together with the application’s source code. The tester shall run the application and determine if the device fails securely.
TB2.12 The tester shall execute a vulnerability …
Added
p. 45
TB4.14 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version numbers, and optionally the hardware version number during startup or on request. This includes all firmware numbers where Core, SRED and OP have different numbering.
For SCRPs and SCRs intended for use with commercial-off-the-shelf devices, the tester shall confirm that the SCRPs and SCRs respond with their model name/number, hardware version, firmware version(s), and a unique device identifier to a query from the PIN CVM application on the COTS device. A secure channel as defined in the guidance must be used where disparate components are used.
For SCRPs and SCRs intended for use with commercial-off-the-shelf devices, the tester shall confirm that the SCRPs and SCRs respond with their model name/number, hardware version, firmware version(s), and a unique device identifier to a query from the PIN CVM application on the COTS device. A secure channel as defined in the guidance must be used where disparate components are used.
Added
p. 50
• The transaction is completed, or
• Extraction of memory from a special sample device after execution of the buffer-clearing code; or
• Confirmation that any compiler flags to ensure optimization are functioning as expected.
• Extraction of memory from a special sample device after execution of the buffer-clearing code; or
• Confirmation that any compiler flags to ensure optimization are functioning as expected.
Added
p. 57
Pseudorandom number generator (PRNG) designs (also known as deterministic random bit generator, or DRBG) from NIST SP800-90A or ANSI X9.82 shall be used. Specifically, HASH_DRBG, HMAC_DRBG, or CTR_DRBG. DEA and 2-key TDEA, as well as DUAL_EC_DRBG, are not acceptable for use in a DRBG.
B9 is mandatory for the SCRP approval class in order to provide a source of entropy for the PIN CVM application. It is a requirement that any random numbers used on the COTS device for security purposes must be seeded from a value provided from the RNG on an external SCRP.
The tester shall outline the process used by the vendor to ensure that any secret values relied upon for random number generation (such as seed values, or keys used in DRBGs) are sufficiently random, and unique per POI.
• Use of a unique key per transaction technique. (Prevents the attack.)
• Preventing the entry of the PIN through other …
B9 is mandatory for the SCRP approval class in order to provide a source of entropy for the PIN CVM application. It is a requirement that any random numbers used on the COTS device for security purposes must be seeded from a value provided from the RNG on an external SCRP.
The tester shall outline the process used by the vendor to ensure that any secret values relied upon for random number generation (such as seed values, or keys used in DRBGs) are sufficiently random, and unique per POI.
• Use of a unique key per transaction technique. (Prevents the attack.)
• Preventing the entry of the PIN through other …
Added
p. 63
SCRPs shall provide for the use of cryptographic keys stored within the SCRP to provide security to the provisioning process. This process loads cryptographic keys and other data to the PIN CVM application upon initial configuration as described in DTR B8: Secure Provisioning of the PCI Software-based PIN Entry on COTS DTRs.
TB11.1 The tester shall examine the response to Section B11 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B11 of the PCI PTS POI Security Requirements for consistency relating to the method of key management in use in the device. The tester shall summarize the responses.
TB11.1 The tester shall examine the response to Section B11 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B11 of the PCI PTS POI Security Requirements for consistency relating to the method of key management in use in the device. The tester shall summarize the responses.
Added
p. 69
Note: Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for TDES. TDES may optionally use, and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a component of a TDEA key will be MAC’d using the TDEA block cipher, while a 128-bit AES key or component will be MAC’d using the AES-128 block …
Added
p. 80
• They cannot adversely affect the security features of the product that are relevant to the PCI POI approval.
• They cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.
• The application is authenticated to the POI secure controller by digital signature.
• The application can only work on the keys it alone manages and cannot affect or see any other keys. A mechanism must exist to display the application version upon request.
• They cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.
• The application is authenticated to the POI secure controller by digital signature.
• The application can only work on the keys it alone manages and cannot affect or see any other keys. A mechanism must exist to display the application version upon request.
Added
p. 83
The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals. Therefore, operating-system code is necessarily part of the firmware as defined within B1.
Vendors should provide configuration lists and software specifications to support answers.
If the OS supports multiple privilege levels or user privileges, the least privileges are assigned according to the “need to have” principle; a single supervisory mode implementation
•e.g., root or equivalent
•is not allowed. The payment application must have less privilege than the firmware.
TB18.3 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.
TB18.6 The tester shall determine whether the OS supports multiple privilege levels or user privileges.
If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the firmware.
The …
Vendors should provide configuration lists and software specifications to support answers.
If the OS supports multiple privilege levels or user privileges, the least privileges are assigned according to the “need to have” principle; a single supervisory mode implementation
•e.g., root or equivalent
•is not allowed. The payment application must have less privilege than the firmware.
TB18.3 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.
TB18.6 The tester shall determine whether the OS supports multiple privilege levels or user privileges.
If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the firmware.
The …
Added
p. 87
TB20.5 The tester shall confirm that the security policy includes any communication methods, including wireless, and any protocols, including security protocols used by the device. Use of any method not listed in the policy invalidates the device approval.
TB20.6 The tester shall confirm that if the device supports SSL, the security policy must clearly state that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan.
TB20.8 The tester shall examine the security policy to verify that it identifies all conditions (for example, voltage, humidity, and temperature) that will cause environmental failure-protection mechanisms to trigger.
TB20.14 For PIN entry devices that appear as a single device•i.e., where two physically and electronically distinct devices (e.g., a PED and a commercial off-the-shelf (COTS) device such as a mobile phone) appear as a single device through the use of the plastics to mask …
TB20.6 The tester shall confirm that if the device supports SSL, the security policy must clearly state that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan.
TB20.8 The tester shall examine the security policy to verify that it identifies all conditions (for example, voltage, humidity, and temperature) that will cause environmental failure-protection mechanisms to trigger.
TB20.14 For PIN entry devices that appear as a single device•i.e., where two physically and electronically distinct devices (e.g., a PED and a commercial off-the-shelf (COTS) device such as a mobile phone) appear as a single device through the use of the plastics to mask …
Added
p. 89
TB20.30 The tester shall confirm that the security policy contains specific details on any account data protection schemes employed
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
TB20.31 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B7 and assessed by the PTS laboratory.
TB20.32 The tester shall confirm that the security policy contains specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with B16, or any mechanisms used for authenticating application code as assessed under Requirements B4.1.
SCRPs shall require an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation.
• Contact points …
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
TB20.31 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B7 and assessed by the PTS laboratory.
TB20.32 The tester shall confirm that the security policy contains specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with B16, or any mechanisms used for authenticating application code as assessed under Requirements B4.1.
SCRPs shall require an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation.
• Contact points …
Added
p. 96
For an SCRP, this requirement is applied without consideration of the conveyance of the PIN from the PIN CVM application on the COTS device. The conveyance of the PIN from the PIN CVM application on the COTS device to the SCRP shall always use ISO format 4 for that conveyance.
SCRPs with ICCRs shall support both enciphered and plaintext PIN for offline PIN authentication.
SCRPs with ICCRs shall support both enciphered and plaintext PIN for offline PIN authentication.
Added
p. 106
• The device must be equipped with only one payment card PIN-accepting keyboard, and
• If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry, for example, it must not have numeric keys, or it must not be possible to use it otherwise for numeric entry or it is controlled in a manner consistent with A6, B16 or E3.4.
• If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry, for example, it must not have numeric keys, or it must not be possible to use it otherwise for numeric entry or it is controlled in a manner consistent with A6, B16 or E3.4.
Added
p. 111
Where the interface is supplied by an OEM module:
• If the module is under the control of the firmware and runs in the same space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for wireless technologies listed above) is provided for and that secure communication is enforced by the interface.
• If an independent OEM module is used:
• The protocol and the pairing mechanism must be assessed; and
• The security of the link between the module and the firmware must be assessed.
• If the OEM module shares resources with the rest of the device, a vulnerability assessment is required to ensure that the OEM module cannot adversely impact the function of the device.
OEM modules that are found to have unaddressed exploitable vulnerabilities may result in the removal of the entire POI device approval.
• If the module is under the control of the firmware and runs in the same space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for wireless technologies listed above) is provided for and that secure communication is enforced by the interface.
• If an independent OEM module is used:
• The protocol and the pairing mechanism must be assessed; and
• The security of the link between the module and the firmware must be assessed.
• If the OEM module shares resources with the rest of the device, a vulnerability assessment is required to ensure that the OEM module cannot adversely impact the function of the device.
OEM modules that are found to have unaddressed exploitable vulnerabilities may result in the removal of the entire POI device approval.
Added
p. 112
TF1.4 The tester shall complete a table describing all interfaces and protocols; and for each, identify which component implements the protocol, whether it is a security protocol, and the location from which the software was derived. The tester shall Include all exempted protocols and interfaces and note why they have been exempted from OP requirements. (See Annex A of the Vendor Questionnaire.) Example Protocol Table Component Handling the Source Code Security Protocol Additional Information IP (General) Security Processor Linux (3.7.1) TLS 1.2 Security Processor OpenSSL (1.0.1g) GPRS GPRS Modem Modem vendor IP (GPRS) GPRS Modem Modem vendor TF1.5 The tester shall verify whether the identified protocols and interfaces are in line with the PCI PTS POI Technical FAQs. When forbidden protocol modes or interfaces are included by a standard implementation, the vendor must provide exhaustive documentation describing how these protocol modes or interfaces are disabled by hardware and/ or software …
Added
p. 118
Note: This does not supersede any criteria in B11 or K17 but rather is required for any device implementing protocols evaluated under Open Protocols•i.e., key-related Security Protocols, such as SSL/TLS, SSH, VPN technologies.
This requirement applies to all declared Security Protocols defined in Section F1.
TH3.4 The tester shall verify whether the cipher suites used by the declared security protocol are in line with the PCI PTS POI Technical FAQs. The tester shall perform any additional tests necessary to validate the device’s documentation.
This requirement applies to all declared Security Protocols defined in Section F1.
TH3.4 The tester shall verify whether the cipher suites used by the declared security protocol are in line with the PCI PTS POI Technical FAQs. The tester shall perform any additional tests necessary to validate the device’s documentation.
Added
p. 126
• Be complete, clear, and unambiguous;
• Cover all elements of device maintenance including use, configuration and delivery of patches or updates; and
• Be complete, clear, and unambiguous,
• Via the remote update mechanism, ensure securityi.e., integrity, server authentication, and protection against replayby using an appropriate and declared security protocol;
• Cover all elements of device maintenance including terminal updates to the device configuration, firmware and software, as well statistics pulled from the device; and
• Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
• Be complete, clear, and unambiguous;
• Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
• Via the update mechanism, ensure security, i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol;
• Cover all elements of device maintenance including …
• Cover all elements of device maintenance including use, configuration and delivery of patches or updates; and
• Be complete, clear, and unambiguous,
• Via the remote update mechanism, ensure securityi.e., integrity, server authentication, and protection against replayby using an appropriate and declared security protocol;
• Cover all elements of device maintenance including terminal updates to the device configuration, firmware and software, as well statistics pulled from the device; and
• Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
• Be complete, clear, and unambiguous;
• Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
• Via the update mechanism, ensure security, i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol;
• Cover all elements of device maintenance including …
Added
p. 133
The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units) Where a device exclusively supports DUKPT or similar unique key per transaction methodology for the protection of sensitive data, such as PINs, the side-channel analysis does not need to include these keys.
SCA tests shall be performed in accordance with Appendix F.
SCA tests shall be performed in accordance with Appendix F.
Added
p. 137
Double-length TDES keys used in connection with SRED can only be used in unique-key-per- transaction implementations as defined in ISO 11568 for key derivation or transformation•e.g., DUKPT. Double-length TDES keys are not permitted for use in SRED in Master/Session or Fixed key implementations.
Added
p. 143
e) Data keys shall never be used to encrypt other keys.
• Avoiding them by design (extreme example: using a programming language, which prevents buffer overflow by definition);
• Finding them by adequate testing (for example, static-code analysis or comprehensive fuzz testing); and/or
• Avoiding them by design (extreme example: using a programming language, which prevents buffer overflow by definition);
• Finding them by adequate testing (for example, static-code analysis or comprehensive fuzz testing); and/or
Added
p. 150
The vendor must provide to the PCI PTS laboratory a guidance document that states the exact scope of the PTS evaluated firmware (down to the level, including version, of libraries and binaries). This shall include all security-relevant APIs to confirm that they are used by the application rather than the application using its own cryptographic primitives and key management.
TK11.2.4 The tester shall examine any relevant documentation to ensure that it includes guidance for use of the correct API function calls, including sample source code.
The device must have the ability to accept firmware updates from a remote host•such as a terminal management system, using polling or similar techniques.
If done between physically and logically disparate components it must use a secure channel as follows:
• Each secure channel must provide mutual authentication to uniquely identify each component prior to exchanging sensitive data, as well as protect against MITM and replay attacks.
• Mutual authentication …
TK11.2.4 The tester shall examine any relevant documentation to ensure that it includes guidance for use of the correct API function calls, including sample source code.
The device must have the ability to accept firmware updates from a remote host•such as a terminal management system, using polling or similar techniques.
If done between physically and logically disparate components it must use a secure channel as follows:
• Each secure channel must provide mutual authentication to uniquely identify each component prior to exchanging sensitive data, as well as protect against MITM and replay attacks.
• Mutual authentication …
Added
p. 153
For SCRPs and SCRs intended for use with commercial-off-the-shelf devices, the tester shall confirm that the SCRPs and SCRs respond with their model name/number, hardware version, firmware version(s), and a unique device identifier to a query from the PIN CVM application on the COTS device. A secure channel as defined in the guidance must be used where disparate components are used.
TK12.14 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version numbers, and optionally the hardware version number during startup or on request. This includes all firmware numbers where Core, SRED and OP have different numbering.
The Open Protocols Module shall be used to assess any communication method that uses a wireless, local, or wide-area network to transport data. This would include, but is not limited to: Bluetooth, Wi- Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need …
TK12.14 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version numbers, and optionally the hardware version number during startup or on request. This includes all firmware numbers where Core, SRED and OP have different numbering.
The Open Protocols Module shall be used to assess any communication method that uses a wireless, local, or wide-area network to transport data. This would include, but is not limited to: Bluetooth, Wi- Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need …
Added
p. 159
• The authorization implements the principles of dual control,
• Sensitive information required for the authorization (for example, passwords/authentication codes or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device,
• An authorized switch must provide traceability and accountability.
• How the applications are authenticated.
• The transaction is completed, or
• Extraction of memory from a special sample device after execution of the buffer-clearing code; or
• Confirmation that any compiler flags to ensure optimization are functioning as expected.
SCRPs must tokenize the PAN data to send to the PIN CVM application on the COTS device for use in formatting the ISO format 4 PIN block. An example of an acceptable PAN token is one described in ANSI X9.119-2 using a format-preserving scheme.
• Sensitive information required for the authorization (for example, passwords/authentication codes or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device,
• An authorized switch must provide traceability and accountability.
• How the applications are authenticated.
• The transaction is completed, or
• Extraction of memory from a special sample device after execution of the buffer-clearing code; or
• Confirmation that any compiler flags to ensure optimization are functioning as expected.
SCRPs must tokenize the PAN data to send to the PIN CVM application on the COTS device for use in formatting the ISO format 4 PIN block. An example of an acceptable PAN token is one described in ANSI X9.119-2 using a format-preserving scheme.
Added
p. 166
When a check value is generated for a key or key component, it shall be generated by a cryptographic process such that all portions of the key or key component are involved in generating the check value.
• Be generated randomly or pseudo-randomly;
• Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;
• Be used in the appropriate order as specified by the particular mode;
• Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and
• Cannot be unbundled for any purpose.
TR-31 support or equivalent must use a key-derivation methodology. The device may optionally support, in addition, the key-calculation methodology.
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by …
• Be generated randomly or pseudo-randomly;
• Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;
• Be used in the appropriate order as specified by the particular mode;
• Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and
• Cannot be unbundled for any purpose.
TR-31 support or equivalent must use a key-derivation methodology. The device may optionally support, in addition, the key-calculation methodology.
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by …
Added
p. 167
• Loaded using asymmetric keys of equivalent or greater strength.
• Encrypted by another AES key of equal or greater strength.
• Manually loaded using dual control techniques.
1. For devices under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s root), the PIN-acceptance device can be forced to bind to a specific transaction-processing host’s certificate, and not accept commands digitally signed by any other hosts. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted below.
2. The acquirer KDH public key can be loaded only once and requires a factory return (preceded by a zeroization of acquirer keys function) to put the device back to ready state.
3. An acquirer-specific PKI hierarchy can be implemented. For this scenario, because of the rigor of criteria for operating a Certification Authority, it is best to have the PIN-acceptance device …
• Encrypted by another AES key of equal or greater strength.
• Manually loaded using dual control techniques.
1. For devices under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s root), the PIN-acceptance device can be forced to bind to a specific transaction-processing host’s certificate, and not accept commands digitally signed by any other hosts. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted below.
2. The acquirer KDH public key can be loaded only once and requires a factory return (preceded by a zeroization of acquirer keys function) to put the device back to ready state.
3. An acquirer-specific PKI hierarchy can be implemented. For this scenario, because of the rigor of criteria for operating a Certification Authority, it is best to have the PIN-acceptance device …
Added
p. 172
Note: Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for TDES. TDES may optionally use, and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a component of a TDEA key will be MAC’d using the TDEA block cipher, while a 128-bit AES key or component will be MAC’d using the AES-128 block …
Added
p. 180
If the OS supports multiple privilege levels or user privileges, the least privileges are assigned according to the “need to have” principle; a single supervisory mode implementation
•e.g., root or equivalent
•is not allowed. The payment application must have less privilege than the firmware.
If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the firmware.
• The operating system of the device must contain only the software (components and services) necessary for the intended operation.
• The operating system must be configured securely and run with least privilege.
• The security policy enforced by the device must not allow unauthorized or unnecessary functions.
• API functionality and commands that are not required to support specific functionality must be disabled (and where possible, removed).
TK21.6 The tester shall determine whether the OS supports multiple privilege levels or user privileges.
•e.g., root or equivalent
•is not allowed. The payment application must have less privilege than the firmware.
If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the firmware.
• The operating system of the device must contain only the software (components and services) necessary for the intended operation.
• The operating system must be configured securely and run with least privilege.
• The security policy enforced by the device must not allow unauthorized or unnecessary functions.
• API functionality and commands that are not required to support specific functionality must be disabled (and where possible, removed).
TK21.6 The tester shall determine whether the OS supports multiple privilege levels or user privileges.
Added
p. 186
The SCRP must use either asymmetric or symmetric techniques to authenticate the enablement token. Any private or symmetric keys present on the SCRP for this purpose must be unique per device.
TK24.1 The tester shall examine the vendor’s response to Section K24 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K24 of the PCI PTS POI Security Requirements for consistency to verify that the SCRP requires fresh monitor tokens to continue functioning. The tester shall summarize the responses.
TK24.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
TK24.3 The tester shall confirm that without a cryptographically secure enablement token being supplied to the SCRP, the SCRP …
TK24.1 The tester shall examine the vendor’s response to Section K24 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K24 of the PCI PTS POI Security Requirements for consistency to verify that the SCRP requires fresh monitor tokens to continue functioning. The tester shall summarize the responses.
TK24.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
TK24.3 The tester shall confirm that without a cryptographically secure enablement token being supplied to the SCRP, the SCRP …
Added
p. 187
• Evidence of existence
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For L2, the lab can randomly select a few occasions and ask for the related log belonging to the dual control or standardized cryptographic authentication procedure used.
DTR L1 Change Control Change-control procedures are in place so that any intended change to the physical or functional capabilities of the POI causes a re-certification of the device under the impacted security requirements of this document. Immediate re-certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality that impacts security. …
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For L2, the lab can randomly select a few occasions and ask for the related log belonging to the dual control or standardized cryptographic authentication procedure used.
DTR L1 Change Control Change-control procedures are in place so that any intended change to the physical or functional capabilities of the POI causes a re-certification of the device under the impacted security requirements of this document. Immediate re-certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality that impacts security. …
Added
p. 188
• All changes to PCI approved devices have been submitted for re-evaluation; or
• Only changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality are deferred from submission and not submitted immediately, but are instead submitted on an aggregate basis.
• Only changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality are deferred from submission and not submitted immediately, but are instead submitted on an aggregate basis.
Added
p. 191
• including engineers, software developers, line staff, supervisory staff, technical management, etc.
•to verify that the documented procedures are known and understood by all affected parties.
• including engineers, software developers, line staff, supervisory staff, technical management, etc.
•to verify that the documented procedures are known and understood by all affected parties.
• including engineers, software developers, line staff, supervisory staff, technical management, etc.
Added
p. 193
Authentication by secret information will become mandatory in POI v6.
One example of such information is the private key of an asymmetric key pair with the public key of the device signed by a private key known only to the manufacturer.
Dual control is not required if the device generates the secret information and never outputs it, for example if it generates a public/private key pair and never outputs the private key.
TL6.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the facility of initial deployment by means of secret information placed in the device during manufacturing. The secret information is installed in the device under dual control to ensure that it is not disclosed during installation, or the device may use an authenticated public-key method.
One example of such information is the private key of an asymmetric key pair with the public key of the device signed by a private key known only to the manufacturer.
Dual control is not required if the device generates the secret information and never outputs it, for example if it generates a public/private key pair and never outputs the private key.
TL6.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the facility of initial deployment by means of secret information placed in the device during manufacturing. The secret information is installed in the device under dual control to ensure that it is not disclosed during installation, or the device may use an authenticated public-key method.
Added
p. 196
• Evidence of existence
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For M3, the lab can randomly select a few occasions and ask for the related log belonging to the received shipments proving that the packaging is validated on tamper evidence.
DTR M1 Shipping Tamper-Protection Documentation The POI should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI.
Prior to initial financial-key loading, the POI should be protected against modification. Such protection shall be a combination of the characteristics of the device (i.e., …
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For M3, the lab can randomly select a few occasions and ask for the related log belonging to the received shipments proving that the packaging is validated on tamper evidence.
DTR M1 Shipping Tamper-Protection Documentation The POI should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI.
Prior to initial financial-key loading, the POI should be protected against modification. Such protection shall be a combination of the characteristics of the device (i.e., …
Added
p. 200
The means to verify the authenticity of the device may include tools such as an SCD.
Added
p. 211
• Pop-up (temporary) privacy shield attached to the device-mounting stand. Consumer (through education and prompting) or merchant would put the shield in place during PIN entry
Added
p. 214
b) Skilled persons are able to perform more complex tasks and attack steps without direction. They have the ability and training to perform a specific task well.
c) Proficient persons are highly competent and have the necessary ability, knowledge, and skill to perform complex attacks successfully. They are familiar with the security functionalities and behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully. Proficient personnel can acquire capabilities equivalent to the skill sets of PTS lab evaluators.
d) Experts are extremely knowledgeable and skillful in one or more areas. They are very familiar with the underlying algorithms, protocols, hardware components, physical and logical architectures, etc., implemented in the device or system type and the principles and concepts of security employed. Experts are capable of quickly devising new attack paths that require specific competencies similar to those of experienced PTS …
c) Proficient persons are highly competent and have the necessary ability, knowledge, and skill to perform complex attacks successfully. They are familiar with the security functionalities and behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully. Proficient personnel can acquire capabilities equivalent to the skill sets of PTS lab evaluators.
d) Experts are extremely knowledgeable and skillful in one or more areas. They are very familiar with the underlying algorithms, protocols, hardware components, physical and logical architectures, etc., implemented in the device or system type and the principles and concepts of security employed. Experts are capable of quickly devising new attack paths that require specific competencies similar to those of experienced PTS …
Added
p. 219
1. The housing has to be opened by removing a part of the backside, and the corresponding keypad controller has to be accessed. Therefore, the security mesh must be circumvented without damaging or short-cutting this mesh at two different locations. To accomplish this, several working steps with different success rates must be performed by someone who is Proficient:
• Grinding through the GND and VCC plane;
• Bridging relevant parts of the security mesh on the first mesh layer and cutting the bridged parts;
• Grinding through the first already disabled mesh layer;
• Bridging relevant parts of the security mesh on the second mesh layer (including the rerouting on layer 1) and cutting the bridged parts;
• Grinding through the second, already disabled mesh layer to get access to the two I²C Bus lines.
2. A PIN-disclosing bug must be attached into the POI (functional sample with working keys):
Therefore, the circuit has to be placed …
• Grinding through the GND and VCC plane;
• Bridging relevant parts of the security mesh on the first mesh layer and cutting the bridged parts;
• Grinding through the first already disabled mesh layer;
• Bridging relevant parts of the security mesh on the second mesh layer (including the rerouting on layer 1) and cutting the bridged parts;
• Grinding through the second, already disabled mesh layer to get access to the two I²C Bus lines.
2. A PIN-disclosing bug must be attached into the POI (functional sample with working keys):
Therefore, the circuit has to be placed …
Added
p. 221
1. The attacker has to perform the reverse-engineering of the device to develop the attack procedure.
This step requires Expert knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The attacker has first to identify the potential way to reach the I/O PIN of the IC card reader. Therefore, one sample of the PED will be opened. The location of the I/O PIN and the protection measures have to be analyzed. The device will cause an alarm during that development phase since the case switches have to be opened. For the reverse- engineering of PED internals, only a mechanical sample is needed.
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the clear-text PIN at the I/O PIN of the IC card reader. The PIN bug must be very small to fit into a fake housing. The development of the dedicated …
This step requires Expert knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The attacker has first to identify the potential way to reach the I/O PIN of the IC card reader. Therefore, one sample of the PED will be opened. The location of the I/O PIN and the protection measures have to be analyzed. The device will cause an alarm during that development phase since the case switches have to be opened. For the reverse- engineering of PED internals, only a mechanical sample is needed.
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the clear-text PIN at the I/O PIN of the IC card reader. The PIN bug must be very small to fit into a fake housing. The development of the dedicated …
Added
p. 222
1. The housing has to be opened from one side to get access to the lateral tamper grid without damaging the housing in a way that no tamper switches are activated. Additionally, the flex-foil tamper grid has to be disabled. Therefore, the covering resin has to be removed and three signals have to be bridged with six connections and disabled behind the bridge. As the working space is highly limited, additional space for, e.g., an endoscope is needed. This can be accomplished by deactivating the tamper grid at both sides of the POI. The work can be performed by someone who is Proficient.
2. A PIN-disclosing bug has to be attached into the POI (functional sample with working keys), and the ICC reader has to be connected to the additional circuit.
3. Once the previous step is successfully achieved, in this example the attacker will now attach the fake housing and hide …
2. A PIN-disclosing bug has to be attached into the POI (functional sample with working keys), and the ICC reader has to be connected to the additional circuit.
3. Once the previous step is successfully achieved, in this example the attacker will now attach the fake housing and hide …
Added
p. 224
1. The attacker has to perform reverse-engineering of the device to develop the attack procedure.
2. The attack has to be prepared by developing of a circuit for logging the track data at the MSR that fits into a fake housing, due to the low amount of space within the dongle. Alternatively, the attacker buys an appropriate bug on the Internet.
3. The attacker must develop a replacement circuit for the anti-skimming loop.
4. The device has to be opened for insertion of a second MSR head. This can be done by removing the magnetic card slide. Additionally, the anti-skimming loop measures have to be deactivated, and an extra frequency-simulating circuit has to be installed.
5. The bug has to be attached on the back case in a fake housing, which holds the electronics and batteries for a bug. This requires professional knowledge of plastics (molding, forming etc.) and standard equipment.
6. The track data …
2. The attack has to be prepared by developing of a circuit for logging the track data at the MSR that fits into a fake housing, due to the low amount of space within the dongle. Alternatively, the attacker buys an appropriate bug on the Internet.
3. The attacker must develop a replacement circuit for the anti-skimming loop.
4. The device has to be opened for insertion of a second MSR head. This can be done by removing the magnetic card slide. Additionally, the anti-skimming loop measures have to be deactivated, and an extra frequency-simulating circuit has to be installed.
5. The bug has to be attached on the back case in a fake housing, which holds the electronics and batteries for a bug. This requires professional knowledge of plastics (molding, forming etc.) and standard equipment.
6. The track data …
Added
p. 226
2. The attacker buys an appropriate bug on the Internet.
3. The device has to be opened for manipulating the encrypting MSR head. Therefore, the magnetic card slide has to be removed. The attacker has to expose the analog pins of the MSR head.
1. The device has to be opened for manipulating the encrypting MSR head. Therefore, the magnetic card slide has to be removed. The attacker has to expose the analog pins of the MSR head.
5. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
3. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
Table used for Identification
• Attack Example 4 Step Expertise Knowledge Equipment …
3. The device has to be opened for manipulating the encrypting MSR head. Therefore, the magnetic card slide has to be removed. The attacker has to expose the analog pins of the MSR head.
1. The device has to be opened for manipulating the encrypting MSR head. Therefore, the magnetic card slide has to be removed. The attacker has to expose the analog pins of the MSR head.
5. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
3. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
Table used for Identification
• Attack Example 4 Step Expertise Knowledge Equipment …
Added
p. 228
1. The attacker has to perform reverse-engineering of the device to develop the attack procedure. This step requires expert knowledge of electronic engineering and the capability to perform the mechanical and electronic tests required. The device will cause an alarm during that development phase since the case switches have to be opened. For the reverse-engineering of PED internals, which is calculated with 32 hours’ working time
•two days’ reverse-engineering (expert) and two days’ attack development (proficient)
•only one mechanical sample is needed.
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the entered PINs directly at the keypad matrix. The development of the dedicated bug hardware and software requires less than one week and has to be performed by an Expert with specialized equipment.
3. The two opening-detection switches at the bottom side of the device have to be circumvented to open the device and reach the bottom side …
•two days’ reverse-engineering (expert) and two days’ attack development (proficient)
•only one mechanical sample is needed.
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the entered PINs directly at the keypad matrix. The development of the dedicated bug hardware and software requires less than one week and has to be performed by an Expert with specialized equipment.
3. The two opening-detection switches at the bottom side of the device have to be circumvented to open the device and reach the bottom side …
Added
p. 230
The attack aims at the determination of DES/AES and RSA keys used for various purposes (e.g., account data encryption, key download, MACing, building the TLS session layer etc.) at the device using differential power analysis (DPA).
• A function of the device (API made available in the dedicated test firmware) is used to execute the DES/AES and RSA calculation with the key under attack;
• The data used for DPA is sent to the security processor using a temporarily available (only together with dedicated test firmware) serial test interface connector of the device.
• The power consumption can be measured with help of a current probe inserted between the voltage regulator output (VCORE voltage) and the through-hole-connection, which is used to connect a PCB inner layer for supplying the security processor with the VCORE voltage. The location that has to be manipulated is directly available on the security PCB (mainboard) without opening any …
• A function of the device (API made available in the dedicated test firmware) is used to execute the DES/AES and RSA calculation with the key under attack;
• The data used for DPA is sent to the security processor using a temporarily available (only together with dedicated test firmware) serial test interface connector of the device.
• The power consumption can be measured with help of a current probe inserted between the voltage regulator output (VCORE voltage) and the through-hole-connection, which is used to connect a PCB inner layer for supplying the security processor with the VCORE voltage. The location that has to be manipulated is directly available on the security PCB (mainboard) without opening any …
Added
p. 231
In this example, the exploitation phase, only three of the five steps are necessary:
1. Carefully insert the current probe between the voltage regulators output for the VCORE voltage and the via which is used by the VCORE voltage to enter the PCB.
2. Performing the measurement.
3. Analyzing the data samples in order to retrieve the key.
Table used for Exploitation
• Attack Example 6 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard (glue, cables, solder. Measurement Probe) 1 functional with working keys and SW 2 Skilled Public Specialized None Same functional with working keys and SW 3 Expert Public Specialized None Not required 20 hours Total Expert Public Specialized Standard 1 functional with working keys and SW
1. Carefully insert the current probe between the voltage regulators output for the VCORE voltage and the via which is used by the VCORE voltage to enter the PCB.
2. Performing the measurement.
3. Analyzing the data samples in order to retrieve the key.
Table used for Exploitation
• Attack Example 6 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard (glue, cables, solder. Measurement Probe) 1 functional with working keys and SW 2 Skilled Public Specialized None Same functional with working keys and SW 3 Expert Public Specialized None Not required 20 hours Total Expert Public Specialized Standard 1 functional with working keys and SW
Added
p. 233
• Cutting blades (for example, scalpels, X-Acto knives, box cutters, axes, saws, etc.), including both conductive and non-conductive blades
• Dremel tool, attachments, extension cable, holder/mill jig, etc.
• Screwdrivers of any type
•including custom tips, as they can be cut from another type of screwdriver simply enough if not able to be purchased
• Hammers, saws, pliers, clamps (G-type, screw type, and any others)
• Oscilloscopes with two channels and external trigger inputs
•up to around 1GHz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
• Simple milling machine
• Drills and drill press, any drill bits down to 0.1mm
• Conductive and non-conductive ink
• PCB etching equipment
• PCB design software
• Simple side-channel software (capable of performing time-displacement alignment, correlation analysis, basic time-frequency conversion and filtering, etc., and having a basic functioning user interface)
• Acid of most types used for attacks, including for etching of chips
• Solvents, cleaning materials, plastic working tools
• …
• Dremel tool, attachments, extension cable, holder/mill jig, etc.
• Screwdrivers of any type
•including custom tips, as they can be cut from another type of screwdriver simply enough if not able to be purchased
• Hammers, saws, pliers, clamps (G-type, screw type, and any others)
• Oscilloscopes with two channels and external trigger inputs
•up to around 1GHz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
• Simple milling machine
• Drills and drill press, any drill bits down to 0.1mm
• Conductive and non-conductive ink
• PCB etching equipment
• PCB design software
• Simple side-channel software (capable of performing time-displacement alignment, correlation analysis, basic time-frequency conversion and filtering, etc., and having a basic functioning user interface)
• Acid of most types used for attacks, including for etching of chips
• Solvents, cleaning materials, plastic working tools
• …
Added
p. 234
• Expensive, high-resolution, high-frequency, deep-buffer oscilloscopes (> 1GS/s, 1GHz, 16-bit, etc.)
• High-resolution 3D printers
• High-resolution milling machines (for example, for chip planing)
• Complex side-channel software, able to perform complex alignment beyond linear shift techniques, and relatively advanced, noise removal, etc., in accordance with the tool capabilities described in Appendix F. It is expected that this will be run on a standard PC (Standard equipment)
• Micro-probes for attachment to die-level features such as bus lines on chips
• Glitching systems, for example EM fault injection
• High-frequency/high-bandwidth EM probes
• 16/32-bit high-speed logic analyzer for capture and analysis of bus traffic
• Dedicated electronic cards
• Specialized test benches
• Microprobe workstation
• Laser abrading/cutting Bespoke equipment “Rule of thumb” followed: If it cannot be obtained for less than US$50000 or extensive customization is required for such an attack, it falls under this category. Bespoke equipment is expected to be required only in very rare circumstances.
• Plasma etching …
• High-resolution 3D printers
• High-resolution milling machines (for example, for chip planing)
• Complex side-channel software, able to perform complex alignment beyond linear shift techniques, and relatively advanced, noise removal, etc., in accordance with the tool capabilities described in Appendix F. It is expected that this will be run on a standard PC (Standard equipment)
• Micro-probes for attachment to die-level features such as bus lines on chips
• Glitching systems, for example EM fault injection
• High-frequency/high-bandwidth EM probes
• 16/32-bit high-speed logic analyzer for capture and analysis of bus traffic
• Dedicated electronic cards
• Specialized test benches
• Microprobe workstation
• Laser abrading/cutting Bespoke equipment “Rule of thumb” followed: If it cannot be obtained for less than US$50000 or extensive customization is required for such an attack, it falls under this category. Bespoke equipment is expected to be required only in very rare circumstances.
• Plasma etching …
Added
p. 239
Note: This appendix is for use in conjunction with the Determining Keys Analysis requirements in Core and SRED.
Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, or may show how a key can be fully exposed but at an acceptable level of difficulty, or may produce a partial result. In every case, a test determining compliance will demonstrate that an attack in the field is infeasible with respect to PTS Security Requirements’ pass/fail thresholds.
This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a feasible method to …
Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, or may show how a key can be fully exposed but at an acceptable level of difficulty, or may produce a partial result. In every case, a test determining compliance will demonstrate that an attack in the field is infeasible with respect to PTS Security Requirements’ pass/fail thresholds.
This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a feasible method to …
Added
p. 240
All PCI PTS-recognized Laboratories must be capable of performing SCA with an attack potential that can distinguish compliant from non-compliant devices. This capability relies on a strong foundation of combined competencies that must be available for any test: skills, knowledge, and experience; collection and analysis equipment (both hardware equipment and software tools).
Laboratories’ SCA resources must be maintained at levels consistent with industry “state-of-the-art” capabilities, including (but not restricted to): cryptanalysis of all relevant algorithms, higher-order DPA, and template attacks. Laboratories’ resources must be improved regularly to reflect updates to the PCI PTS program, for example as version changes occur and/or as new attacks are published. Labs must have available a sufficient volume of personnel and equipment resources to be capable of performing SCA at any capacity of evaluations the lab undertakes.
The best SCA tools, even implementing advanced automation, are useless without a proficient user. PCI SSC expects laboratory personnel to …
Laboratories’ SCA resources must be maintained at levels consistent with industry “state-of-the-art” capabilities, including (but not restricted to): cryptanalysis of all relevant algorithms, higher-order DPA, and template attacks. Laboratories’ resources must be improved regularly to reflect updates to the PCI PTS program, for example as version changes occur and/or as new attacks are published. Labs must have available a sufficient volume of personnel and equipment resources to be capable of performing SCA at any capacity of evaluations the lab undertakes.
The best SCA tools, even implementing advanced automation, are useless without a proficient user. PCI SSC expects laboratory personnel to …
Added
p. 241
• SCA toolsets are updated incrementally to: improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.
Laboratory capabilities related to any of the resources outlined above must correspond closely to information expressed in current versions of PTS documents, and to information releases from PCI SSC.
Principles and methods for testing
PCI SSC expects that the overall quality and effort required for SCA testing to conclude device compliance is comparable to the criteria described here.
SCA must not be hindered by lack of basic resources PCI SSC considers to be essential.
• Notwithstanding physical protections (such as those validated by DTR A1), approved devices must not contain cryptographic implementations which, under analysis, can be straightforwardly compromised through SCA.
• Devices provided for evaluations must be adequately prepared by the vendor for efficient lab testing.
• SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary, available tools can …
Laboratory capabilities related to any of the resources outlined above must correspond closely to information expressed in current versions of PTS documents, and to information releases from PCI SSC.
Principles and methods for testing
PCI SSC expects that the overall quality and effort required for SCA testing to conclude device compliance is comparable to the criteria described here.
SCA must not be hindered by lack of basic resources PCI SSC considers to be essential.
• Notwithstanding physical protections (such as those validated by DTR A1), approved devices must not contain cryptographic implementations which, under analysis, can be straightforwardly compromised through SCA.
• Devices provided for evaluations must be adequately prepared by the vendor for efficient lab testing.
• SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary, available tools can …
Added
p. 243
• Signal analysis and processing: All side-channel recordings will contain a certain degree of noise in acquired waveforms
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA patterns, correlation leakage pinpointing sensitive operations, and key-dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual countermeasures that obscure sensitive signals can significantly delay or prevent SCA attacks. Combinations of well-implemented countermeasures therefore provide greater defense-in-depth. Nevertheless, unintentional leakage may become straightforwardly detectable when noise is removed. It is possible to utilize design information and source-code review, to some extent, to infer the likely effectiveness of obstructive noise. However, there is always a possibility that obstructions may be removed by analyzing and modifying recordings to reveal hidden …
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA patterns, correlation leakage pinpointing sensitive operations, and key-dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual countermeasures that obscure sensitive signals can significantly delay or prevent SCA attacks. Combinations of well-implemented countermeasures therefore provide greater defense-in-depth. Nevertheless, unintentional leakage may become straightforwardly detectable when noise is removed. It is possible to utilize design information and source-code review, to some extent, to infer the likely effectiveness of obstructive noise. However, there is always a possibility that obstructions may be removed by analyzing and modifying recordings to reveal hidden …
Added
p. 244
Testing rationale and reporting The outline information above defines many important aspects of testing. This should not be interpreted as an exhaustive list or as a definitive formula. PCI SSC expects SCA to be well targeted; that is, focused analysis considering the device’s characteristics and making best use of adequate evaluation resources. It is not expected that all of these examples of techniques should be applied in any particular evaluation. More exactly, evaluations should demonstrably produce results deriving from well-balanced decisions corresponding to appropriate aspects of best practices.
In some situations, it is likely that testing from one evaluation can be reused straightforwardly in another evaluation. This situation occurs commonly when two devices having similar characteristics are evaluated by the same laboratory in parallel or in close succession. Other situations exist where SCA-test reuse, or partial reuse, is appropriate, including reuse of third-party testing. PCI SSC encourages optimized reuse of SCA …
In some situations, it is likely that testing from one evaluation can be reused straightforwardly in another evaluation. This situation occurs commonly when two devices having similar characteristics are evaluated by the same laboratory in parallel or in close succession. Other situations exist where SCA-test reuse, or partial reuse, is appropriate, including reuse of third-party testing. PCI SSC encourages optimized reuse of SCA …
Added
p. 245
The evaluation should determine at least one algorithm to analyze thoroughly, based on a rigorous assessment of asset value versus feasible attacks. Reasoning for not testing any algorithm has to be explained. This reasoning should include reliable assumptions made in the vulnerability analysis based on: asset value and attack complexity•for example, limits on collections such as delay insertions or key usage counters, and any additional countermeasures.
Prerequisites To facilitate testing, the vendor has to provide “open” samples (with a wire or pin attached for triggering and, if applicable, attachments to locations agreed with the lab for power measurements). The vendor has to provide specially adapted firmware to allow cryptographic operations’ input/outputs to be collected. For both EMA and power consumption (if possible), the measurement shall be performed directly at the chip/processor. The purpose of this is to identify how to optimize testing, including data gathering
•e.g., probe placement
•of a fully functional device. …
Prerequisites To facilitate testing, the vendor has to provide “open” samples (with a wire or pin attached for triggering and, if applicable, attachments to locations agreed with the lab for power measurements). The vendor has to provide specially adapted firmware to allow cryptographic operations’ input/outputs to be collected. For both EMA and power consumption (if possible), the measurement shall be performed directly at the chip/processor. The purpose of this is to identify how to optimize testing, including data gathering
•e.g., probe placement
•of a fully functional device. …
Added
p. 246
Reusing results Since multiple devices commonly use same security processor or System on Chip for cryptographic operations, it can be useful to reuse results from other evaluations to decrease the efforts for side- channel analysis. Nevertheless, to ensure the transferability of results, the following points have to be considered:
• SCA results reused from other reports must not contain less information than required by the guidance.
• The measurement setup of the reused analysis has to be described in a way that it can be justified that this setup also applies for the device under evaluation.
• The identification and configuration of the cryptographic component has to be compared to ensure that the results also apply to the device under evaluation
•e.g., registers for enabling/disabling counter measures, etc.
• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports, respectively the SCA part of …
• SCA results reused from other reports must not contain less information than required by the guidance.
• The measurement setup of the reused analysis has to be described in a way that it can be justified that this setup also applies for the device under evaluation.
• The identification and configuration of the cryptographic component has to be compared to ensure that the results also apply to the device under evaluation
•e.g., registers for enabling/disabling counter measures, etc.
• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports, respectively the SCA part of …
Added
p. 248
Applications are any code in the device that cannot impact any of the functionality needed to comply with PCI POI requirements (with the exception of prompt control and SRED applications).
Additional considerations Separation between firmware and applications must be implemented by the firmware (B17). It must be enforced that applications cannot intentionally (or unintentionally because they have been hacked):
• Read keys from or write known keys into the key store provided by the firmware, which can be used for PIN or SRED encryption (which implies that the key store API must be sufficiently hardened so that it does not allow for typical HSM API attacks).
• Have access to a clear-text PIN, which can be used in a payment transaction facilitated by the firmware (which implies that the application must not be able supply a PIN value for encryption to the firmware).
• Have access to any secondary assets relevant for the security …
Additional considerations Separation between firmware and applications must be implemented by the firmware (B17). It must be enforced that applications cannot intentionally (or unintentionally because they have been hacked):
• Read keys from or write known keys into the key store provided by the firmware, which can be used for PIN or SRED encryption (which implies that the key store API must be sufficiently hardened so that it does not allow for typical HSM API attacks).
• Have access to a clear-text PIN, which can be used in a payment transaction facilitated by the firmware (which implies that the application must not be able supply a PIN value for encryption to the firmware).
• Have access to any secondary assets relevant for the security …
Added
p. 249
Note that only firmware and the required protection of firmware against modification are addressed. For a full PTS evaluation, more aspects need to be considered, requiring additional protection.
• 8-bit Microprocessor, no MMU (or MMU not used) All code is firmware. The device must not support applications.
Required protection (see Table G1): “Core (Keys)” for all parts.
Required protection (see Table G1): “Core (Keys)” for all parts.
• 32-bit SoC with Linux OS Minimal firmware scope:
• Root file system including all executables, libraries, scripts, and configuration files that are necessary to support all of the functionality required for PCI compliance and can potentially run with elevated privileges. Examples: binaries that are used for start-up, security-relevant daemons, cryptographic key storage, PIN-handling routines, cron tasks, binaries with suid bit set, and all shared libraries used by these programs, etc.
“Elevated privileges” means: Having immediate access to assets, secondary assets, or interfaces under control of the firmware.
Potentially out …
• 8-bit Microprocessor, no MMU (or MMU not used) All code is firmware. The device must not support applications.
Required protection (see Table G1): “Core (Keys)” for all parts.
Required protection (see Table G1): “Core (Keys)” for all parts.
• 32-bit SoC with Linux OS Minimal firmware scope:
• Root file system including all executables, libraries, scripts, and configuration files that are necessary to support all of the functionality required for PCI compliance and can potentially run with elevated privileges. Examples: binaries that are used for start-up, security-relevant daemons, cryptographic key storage, PIN-handling routines, cron tasks, binaries with suid bit set, and all shared libraries used by these programs, etc.
“Elevated privileges” means: Having immediate access to assets, secondary assets, or interfaces under control of the firmware.
Potentially out …
Added
p. 250
Figure 1: 8-bit Microprocessor + 32-bit SoC with Linux This is assuming that NFC Radio, Encrypting MSR, and GSM module have updateable code. All keys are stored and used only in the 8-bit CPU.
Code Part Scope (only highest level listed), see Table G1 8-bit CPU Core (Keys) NFC Radio SRED (Account Data processing) Encrypting MSR SRED (Keys) 32-bit SoC Core (Public Keys), OP Application(s) Application (Display)
Note: In this case, NFC Radio, Encrypting MSR, and GSM are required to support B1.
Figure 2: 32-bit SoC with Linux + 32-bit SoC with Linux This is assuming that all keys are stored in the left SoC. NFC radio code is not updateable. SRED cannot be turned off.
Code Part Scope, see Table G1 Left 32-bit SoC Core (Keys) NFC Radio SRED (Account Data Processing), no B1 Right 32-bit SoC OP Application(s) Application (other)
Figure 3: 32-bit SoC with Linux and attached COTS device It is assumed …
Code Part Scope (only highest level listed), see Table G1 8-bit CPU Core (Keys) NFC Radio SRED (Account Data processing) Encrypting MSR SRED (Keys) 32-bit SoC Core (Public Keys), OP Application(s) Application (Display)
Note: In this case, NFC Radio, Encrypting MSR, and GSM are required to support B1.
Figure 2: 32-bit SoC with Linux + 32-bit SoC with Linux This is assuming that all keys are stored in the left SoC. NFC radio code is not updateable. SRED cannot be turned off.
Code Part Scope, see Table G1 Left 32-bit SoC Core (Keys) NFC Radio SRED (Account Data Processing), no B1 Right 32-bit SoC OP Application(s) Application (other)
Figure 3: 32-bit SoC with Linux and attached COTS device It is assumed …
Added
p. 253
PCI PTS POI Security Policy (Security Policy Version Number if applicable)
Added
p. 255
• This should explain the purpose of the security policy, the PTS POI version to which the device is assessed, who should use it, and that any deviation from the approved use of the device will invalidate the PCI PTS POI approval.
General Description Product Name and Appearance:
• This should include the name of the product and where to locate the product name. This should also include a picture of the device and the label.
• This section should detail how the device is to be used
•countertop, hand-held, multi-lane, etc.
• and whether it is for attended, unattended, or both.
• Other attributes of the device should be listed here. Functions provided (MSR, ICCR, PIN entry, etc.) and the communication types (cellular, Bluetooth, Wi-Fi, etc.) on which the device is approved for use.
• For PIN entry devices that appear as a single device
•i.e., where two physically and electronically distinct devices (e.g., a PED and …
General Description Product Name and Appearance:
• This should include the name of the product and where to locate the product name. This should also include a picture of the device and the label.
• This section should detail how the device is to be used
•countertop, hand-held, multi-lane, etc.
• and whether it is for attended, unattended, or both.
• Other attributes of the device should be listed here. Functions provided (MSR, ICCR, PIN entry, etc.) and the communication types (cellular, Bluetooth, Wi-Fi, etc.) on which the device is approved for use.
• For PIN entry devices that appear as a single device
•i.e., where two physically and electronically distinct devices (e.g., a PED and …
Added
p. 256
• The guidance provides instructions for the proper use and configuration of any communication type and open protocol, including any security protocol.
• This section will provide all configuration settings necessary to meet the security requirements defined in this document.
Unattended Installation
• Guidance for unattended payment terminal designs where the ICCR slot cannot be positioned straight (horizontal) to the cardholder; the security policy stipulates the allowed installation height ensuring a sufficient view on the card-slot entry area Handheld devices
• The guidance must state that if any handheld PIN entry device does not support SRED encryption, the system cannot be implemented to connect to a tablet or mobile phone, and any such use will violate the approval of the device.
Operation and Maintenance Periodic Inspection
• Guidance and procedures are provided for continual visual and logical inspection of the product. An example would be to check the card slot for shim and look for wires, …
• This section will provide all configuration settings necessary to meet the security requirements defined in this document.
Unattended Installation
• Guidance for unattended payment terminal designs where the ICCR slot cannot be positioned straight (horizontal) to the cardholder; the security policy stipulates the allowed installation height ensuring a sufficient view on the card-slot entry area Handheld devices
• The guidance must state that if any handheld PIN entry device does not support SRED encryption, the system cannot be implemented to connect to a tablet or mobile phone, and any such use will violate the approval of the device.
Operation and Maintenance Periodic Inspection
• Guidance and procedures are provided for continual visual and logical inspection of the product. An example would be to check the card slot for shim and look for wires, …
Added
p. 257
• This section contains information on how the device will indicate a tamper event, and any requirements for the return of this device to the vendor for examination following such an event.
• This section should include pictures and screen shots as well as how the merchant is to react to a tamper event
•i.e., stop using the device, call the help desk, notify your vendor etc.
• If the device has been approved for use with a privacy shield, the guidance provides a picture of the approved privacy shield as properly installed and tested by the lab and how it is to be used.
• If the device has been approved without a privacy shield, the document must provide guidance on how to protect PIN entry.
Patching and Updating
• This section provides guidance on device update and patch procedures required for the secure operation of the device, including the ability to determine when the …
• This section should include pictures and screen shots as well as how the merchant is to react to a tamper event
•i.e., stop using the device, call the help desk, notify your vendor etc.
• If the device has been approved for use with a privacy shield, the guidance provides a picture of the approved privacy shield as properly installed and tested by the lab and how it is to be used.
• If the device has been approved without a privacy shield, the document must provide guidance on how to protect PIN entry.
Patching and Updating
• This section provides guidance on device update and patch procedures required for the secure operation of the device, including the ability to determine when the …
Added
p. 258
• This section provides guidance how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with B16, or any mechanisms used for authenticating application code as assessed under Requirements B4.1.
• This section details any account data protection schemes employed
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
• The guidance must include procedures and use cases for devices that allow the enablement (turning on) or the disablement (turning off) of SRED functionality.
• This section contains specific details on the cryptographic algorithms (TDES, SHA-2, etc.) and key-management methodologies supported by the device. It must detail the specific keys and usages of these keys for all key-management methods exposed to the device operators.
Note: Key-management operations that are only used within the device, or between integrated device components, are not required to be detailed.
• The section …
• This section details any account data protection schemes employed
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
• The guidance must include procedures and use cases for devices that allow the enablement (turning on) or the disablement (turning off) of SRED functionality.
• This section contains specific details on the cryptographic algorithms (TDES, SHA-2, etc.) and key-management methodologies supported by the device. It must detail the specific keys and usages of these keys for all key-management methods exposed to the device operators.
Note: Key-management operations that are only used within the device, or between integrated device components, are not required to be detailed.
• The section …
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 4.1b
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 5.1
Modified
p. 3
June 2015 4.1 Updates for errata and new Core Section J
June 2015 4.1 Updates for errata and new Core Section J. Added Device Management.
Removed
p. 7
Core PIN Entry Derived Test Requirements, POS Terminal Integration Derived Test Requirements, Open Protocols Derived Test Requirements, and Secure Reading and Exchange of Data Derived Test Requirements Structure of the DTRs Each PCI requirement as stated in the PCI PTS POI Security Requirements manual is represented by a subsection. For example, Requirement A1 is represented in this document as:
A device overview that summarizes the device’s design, hardware and software architectures, and functionalities; An overview of all security-relevant features, necessary to derive principal assets, threats, and attacks; A summary list of DTRs with verdicts on whether tested and whether compliant; and A summary of any assistance provided by the vendor to the lab.
A device overview that summarizes the device’s design, hardware and software architectures, and functionalities; An overview of all security-relevant features, necessary to derive principal assets, threats, and attacks; A summary list of DTRs with verdicts on whether tested and whether compliant; and A summary of any assistance provided by the vendor to the lab.
Modified
p. 7 → 8
In support of some test steps, as directed by the test laboratory, the vendor must support the laboratory in various tasks (code review, fuzzing interfacing, DPA, etc.) to avoid prohibitively lengthy test activities.
In support of some test steps, as directed by the test laboratory, the vendor must support the laboratory in various tasks (such as, but not restricted to: code review, fuzzing interfacing, DPA, etc.) to avoid prohibitively lengthy test activities.
Modified
p. 7 → 8
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents including, where applicable, the Open Protocols Module
• Protocol Declaration Form.
• Protocol Declaration Form.
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents, such as the Security Policy.
Removed
p. 8
References to relevant information in the overview sections of the evaluation report, and to other DTRs where appropriate; Descriptions of the vendor’s attestations of compliance to security requirements, with Descriptions of information and assistance provided by the vendor to support the evaluation; Accurate descriptions of relevant device attributes, for example (but not restricted to): physical and logical protections, chip architecture, OS, etc.
Explanations for the scope and focus of test activities and attack hypotheses, including explanations of white-box or black-box approaches used, and why; Details of decisions made for performing penetration testing, the methodologies used, and the results of penetration testing; Justifications for any reliance on test evidence not derived directly from the evaluation activities; Explanations for any conclusions based on theoretical analysis instead of applied testing; The tester shall detail where costing information is based on testing or assumptions and provide justification …
Explanations for the scope and focus of test activities and attack hypotheses, including explanations of white-box or black-box approaches used, and why; Details of decisions made for performing penetration testing, the methodologies used, and the results of penetration testing; Justifications for any reliance on test evidence not derived directly from the evaluation activities; Explanations for any conclusions based on theoretical analysis instead of applied testing; The tester shall detail where costing information is based on testing or assumptions and provide justification …
Modified
p. 8
• Validate the completed Vendor Questionnaire and other vendor responses by stating:
Modified
p. 8 → 9
The evaluation report document shall demonstrate compliance to Security Requirements. For all DTRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. Every DTR should be supported by sufficient evidence for the evaluation conclusions placed in the report to be understood …
The evaluation report document shall demonstrate compliance to Security Requirements. For all DTRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid against PTS Program•i.e., considering DTRs, FAQs, Program Guide, and any other related documents. Every DTR should be supported by …
Modified
p. 8 → 9
The tester shall justify any deviation from the prescribed routines as to why the deviation The tester is not limited to only presenting information specified by DTR text, and should in many cases expand upon that information as necessary to support a conclusion.
The tester shall justify any deviation from the prescribed routines. The tester is not limited to only presenting information specified by DTR text/guidance/FAQs/Program Guide. Where necessary to support a conclusion, expand upon that information.
Modified
p. 8 → 9
In most cases the DTR text is insufficient without combining photographs and/or other graphic illustrations that explain the evaluation. Images shall be of sufficient quality for relevant details to be viewed (for example, clear identification of a hardware component, relevant information clearly discernible in a graph, etc.).
In most cases the DTR text is insufficient without combining photographs and/or other graphic illustrations that explain the evaluation. Images shall be of sufficient quality for relevant details to be viewed•for example, clear identification of a hardware component, relevant information clearly discernible in a graph, images capturing displays and other outputs, source code fragments, etc.
Modified
p. 8 → 9
All DTRs must include references to documents and any other relevant sources of information upon which the evaluation relies.
All DTRs must include references to documents and any other relevant sources of information upon which the evaluation relies. References must indicate information sources sufficiently to enable PCI to identify test evidence following device approval.
Modified
p. 9 → 10
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario. All attacks shall include a minimum of ten hours’ attack time for exploitation.
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario.
Modified
p. 10
If any of these keys are not zeroized, then other mechanisms must exist to disable the device, and these keys must be protected in accordance with Requirement A6.
If any of these keys are not zeroized, then other mechanisms must exist to disable the device, and these keys must be protected in accordance with Requirement A5.
Removed
p. 11
In addition to the specified minimum attack potential values, any feasible penetration attack against the device for the purpose of determining or modifying sensitive data must entail at least ten hours of exploitation time.
TA1.5 The tester shall describe the path taken by the signals that connect the customer PIN entry mechanism(s) to the secure processor(s).
TA1.5 The tester shall describe the path taken by the signals that connect the customer PIN entry mechanism(s) to the secure processor(s).
Modified
p. 11
• Use a minimum of two layers of internal grids for protection.
Modified
p. 11
• Vias of ”upper grid” must be protected separately to vias of “lower grid” (for example, the two tamper grids must not be connected by vias that are accessible on both grid layers, or vias must be protected by other tamper mechanisms, such as switches).
Modified
p. 11
• Maximum width/separation (of active traces) of 6 mil.
Modified
p. 11
• Use “opposing” tamper-responsive traces routed side-by-side on each layer.
Modified
p. 11
TA1.1 The tester shall visually inspect the tamper-detection mechanism to verify the assertions provided by the vendor in response to Section A1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A1 of the PCI PTS POI Security Requirements manual for consistency relating to the tamper-detection mechanism. The vendor responses should clearly indicate how tamper-detection mechanisms are effective and robust. The tester shall summarize the responses.
TA1.1 The tester shall visually inspect the tamper-detection mechanism to verify the assertions provided by the vendor in response to Section A1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A1 of the PCI PTS POI Security Requirements for consistency relating to the tamper-detection mechanism. The vendor responses should clearly indicate how tamper-detection mechanisms are effective and robust. The tester shall summarize the responses.
Modified
p. 11 → 12
TA1.6 The tester shall describe the path taken by the signals that connect the customer PIN entry mechanism(s) to the secure processor(s).
Modified
p. 11 → 12
•including passive parts or segments, connectors, or other items
•that are connected to the path of the customer PIN signals.
TA1.7 The tester shall list any components
•including passive parts or segments, connectors, or other items
•that are connected to the path of the customer PIN signals.
•including passive parts or segments, connectors, or other items
•that are connected to the path of the customer PIN signals.
Modified
p. 11 → 12
TA1.8 The tester shall enumerate each of the circuit boards indicated in the POI in the table below, providing, at a minimum:
Modified
p. 12
PCB Designator PCB Version PCB Purpose Picture Reference Tamper-Detection Mechanisms TA1.8 For each PCB that carries customer PIN signals, the tester shall describe what tamper-detection mechanisms protect these signals from being accessed (such as tamper grids). The tester shall confirm that these mechanisms protect the entire path taken by the signals, as described above.
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. (See Annex A of the Vendor Questionnaire.) PCB Designator PCB Version PCB Purpose Picture Reference Tamper-Detection Mechanisms TA1.9 For each PCB that carries customer PIN signals, the tester shall describe what tamper- detection mechanisms protect these signals from being accessed (such as tamper grids). The tester shall confirm that these mechanisms protect the entire path taken by the signals, …
Modified
p. 12
TA1.10 The tester shall describe whether any of the items on the path of the keypad signals are not protected by all tamper-detection mechanism. For example, the tester shall note if a signal via terminates on the same layer as a tamper grid and if any passive components are located outside of the protected area or are connected to vias (including power vias) that terminate outside of the protected area(s).
Modified
p. 12
TA1.11 Using vendor documentation for each tamper grid that is implemented, the tester shall complete the details indicated in the table below, describing, at a minimum:
Modified
p. 12 → 13
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information.
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. (See Annex A of the Vendor Questionnaire.) Tamper Grid Physical Implementation Size of Traces and Distance between Traces, Signals, or Layers Tamper- detecting Signals Method of Connection Adjacent Signals? TA1.12 The tester shall describe what testing was performed to validate the protection provided by each of the tamper grids enumerated above.
Removed
p. 13
TA1.12 For each tamper switch used in the POI, the tester shall complete the details indicated in the table below, at a minimum.
The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack (such as being covered by a flexible tamper grid, or having a unique construction).
Switch Location Number Used in that Location Physical Implementation Size of Switch Conductive Ink Protections Additional Comments TA1.13 The tester shall describe what testing was performed to validate the protection provided by each of the tamper switches enumerated above.
The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack (such as being covered by a flexible tamper grid, or having a unique construction).
Switch Location Number Used in that Location Physical Implementation Size of Switch Conductive Ink Protections Additional Comments TA1.13 The tester shall describe what testing was performed to validate the protection provided by each of the tamper switches enumerated above.
Modified
p. 13
TA1.15 The tester shall note which tamper-detection mechanisms use active high, active low, dynamic, resistive (or other) types of sensors. The tester shall confirm that any guard rings or interspaced traces in tamper grids are at opposing voltages that will activate tamper detection if electronically shorted. The tester shall note what testing has been performed to confirm this.
Modified
p. 13
TA1.16 The tester shall describe any volume-encapsulation methods used in the device (for example, epoxy filling) that are designed to make penetration or reverse engineering more difficult.
Modified
p. 13
TA1.17 The tester shall describe what testing was performed to validate any volume encapsulation.
Modified
p. 13
TA1.18 The tester shall describe any attachment or “forming” methods (such as soldering, elastomeric strips, or adhesive for attachment, and plastic/metal walls for forming the shape of flexible circuits) used as part of the security features of the POI. For example, the tester shall detail the methods used to secure any flexible tamper grids, or “cover PCBs” so they cannot be bent or lifted out of the way.
Modified
p. 13 → 14
TA1.20 The tester shall provide details on the security processor used in the POI, including how it drives tamper-detection features. The tester shall provide and reference a picture of the location and area surrounding the security processor.
Modified
p. 13 → 14
TA1.21 The tester shall describe any POI security features used to protect customer PINs that have not already been covered in the previous descriptions (for example, special processor packaging). The tester shall detail what testing has been performed to validate each of these features.
Modified
p. 13 → 14
TA1.22 The tester shall provide and make reference to a schematic diagram of the tamper circuits of the POI, showing connections to all tamper-detection features including switches and tamper grids.
Removed
p. 14
TA1.29 The tester shall explain how the POI is protected against attacks from the rear of the device.
TA1.30 The tester shall explain how the POI is protected against attacks from the front of the device.
Identification stage of attack “P1”
1. Description of Step 1 2. Description of Step 2 3. Description of Step 3 4. Etc.
TA1.30 The tester shall explain how the POI is protected against attacks from the front of the device.
Identification stage of attack “P1”
1. Description of Step 1 2. Description of Step 2 3. Description of Step 3 4. Etc.
Modified
p. 14
TA1.24 The tester shall describe how the POI responds to a tamper-detection event. The tester shall show the visible response(s) of the device’s display (if any) upon tampering.
Modified
p. 14
TA1.25 Deriving from the previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the POI results from tamper-detection events.
Modified
p. 14
TA1.26 From the above descriptions the tester shall explain how the POI is rendered inoperative after any tamper event.
Modified
p. 14
TA1.27 The tester shall explain how the device is designed to mitigate against overlays.
Modified
p. 14
TA1.28 The tester shall explain how the POI is protected against an internal overlay being placed across the keypad.
Modified
p. 14
TA1.29 The tester shall explain how the POI is protected against attacks from each of all sides of the POI, including the front and rear of the device.
Modified
p. 14
TA1.30 Describe the different attack paths considered. Using the format shown in Appendix B, and providing images allowing the principle steps in the analysis to be understood, the tester shall generate PIN-attack calculations, using different attack techniques on the POI, and present the two most feasible. The attacks should be dissimilar in approach unless the lab can fully justify the infeasibility of any second divergent approach. The tester shall state explicitly where testing has verified any specific stage of the …
Removed
p. 15
1. Description of Step 1 2. Description of Step 2 3. Description of Step 3 4. Etc.
Step Expertise Knowledge Equipment Parts Samples Time 1 Expert Public Standard None 1 Mechanical 80 hours 2 Expert Public Standard Standard 40 hours 3 Expert Public Standard None 1 Mechanical 80 hours Cost breakdown of attack “P1” Identification Phase Value Attack Time 0 < One hour Expertise 0 Layman Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 0 None Specific Parts 0 None Identification Total 3.0 Exploitation Phase Value Attack time 2 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 0 None Specific Parts 0 None Exploitation Total 6.0 (FAIL) Grand Total 9.0 (FAIL) Attack “P2” for Online PINs Identification stage of attack “P2”
Step Expertise Knowledge Equipment Parts Samples Time 1 Expert Public Standard None 1 Mechanical 80 hours 2 Expert Public Standard Standard 40 hours 3 Expert Public Standard None 1 Mechanical 80 hours Cost breakdown of attack “P1” Identification Phase Value Attack Time 0 < One hour Expertise 0 Layman Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 0 None Specific Parts 0 None Identification Total 3.0 Exploitation Phase Value Attack time 2 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 0 None Specific Parts 0 None Exploitation Total 6.0 (FAIL) Grand Total 9.0 (FAIL) Attack “P2” for Online PINs Identification stage of attack “P2”
Removed
p. 16
1. Description of Step 1 2. Description of Step 2 3. Description of Step 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Expert Public Standard None 1 Mechanical 80 hours 2 Expert Public Standard Standard 40 hours 3 Expert Public Standard None 1 Mechanical 80 hours Cost breakdown of attack “P2” Identification Phase Value Attack Time 0 < One hour Expertise 0 Layman Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 0 None Specific Parts 0 None Identification Total 3.0 Exploitation Phase Value Attack time 2 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 0 None Specific Parts 0 None Exploitation Total 6.0 (FAIL) Grand Total 9.0 (FAIL) TA1.32 The tester shall verify that no attack was able to be determined, including those outlined above, which could …
Modified
p. 18 → 15
• Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) The vendor must either provide substantive data to support the security of the product functioning outside normal operating conditions or show that the product uses sensors that will trigger a tamper response.
Modified
p. 18 → 15
TA2.1 The tester shall examine the response to Section A2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A2 of the PCI PTS POI Security Requirements for consistency relevant to Requirement A2. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.
Modified
p. 18 → 15
TA2.2 The tester shall examine and cite any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc., submitted by the vendor to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions. Such information must be clearly referenced.
Modified
p. 18 → 15
TA2.3 The tester shall provide the operational temperature and voltage range for the POI as detailed in vendor documentation.
Modified
p. 18 → 15
TA2.4 Using the schematic and description from TA1.6 and TA1.7 the tester shall list the temperature ranges for all components included in the tamper-detection circuit. This shall include mechanical switches and active elements (but not passive elements such as resistors and capacitors).
Modified
p. 19 → 16
TA2.7 Using a POI that has been configured by the vendor (using special test code from the vendor, which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table; or the vendor should provide sufficient test reports covering all required …
Modified
p. 19 → 16
TA2.8 The tester shall detail whether the self-test program used above executed correctly at all times during each of the tests above, within the ranges before activation of the environmental detection circuitry.
Modified
p. 19 → 16
TA2.9 Given the details and results above, the tester shall justify why the tamper-detection mechanisms will remain functional and the POI secure at all extremes within the range of environmental monitoring.
Modified
p. 19 → 16
TA2.10 The tester shall develop attack scenarios to compromise the device by altering operational conditions and consider whether altering environmental conditions may be used to develop attacks.
Modified
p. 19 → 16
TA2.11 The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, demonstrating compliance to this DTR.
Modified
p. 20 → 17
TA3.1 The tester shall examine the response to Section A3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI PTS POI Security Requirements for consistency relevant to Requirement A3. The vendor responses should clearly indicate what sensitive information and functions exists; and that sensitive functions or information are only used in the protected area(s) of the device; and that sensitive information and functions dealing with sensitive information are protected from unauthorized modification. …
Modified
p. 20 → 17
TA3.3 The tester shall verify the completeness of the information regarding sensitive information and functions presented by the vendor.
Modified
p. 20 → 17
TA3.4 In the following table, the tester shall outline the locations of all types of sensitive information and functions, adding to those provided where other types of sensitive information exist within the POI. This shall include both long-term and temporary storage locations, as well as information on any programmable logic used in the POI as part of the PIN storage/processing/entry circuit. The storage area column shall outline where and what type of storage is used for this information (such as …
Removed
p. 21
Sensitive Information Storage area Method of protection Plaintext PINs POI Firmware Public keys TA4.5 Using the information from the table above, the tester shall provide details on the different integrated circuits (memory, processors, programmable logic etc.) that are used to store, process, or secure sensitive information.
TA4.8 If external memory is implemented, and this is not included in the sensitive-information storage areas above, the tester shall detail what processes have been used to validate that this is the case.
TA4.8 If external memory is implemented, and this is not included in the sensitive-information storage areas above, the tester shall detail what processes have been used to validate that this is the case.
Modified
p. 21 → 18
TA3.6 For each of the integrated circuit elements (described above) which may be programmed or configured in some way, the tester shall provide the following information:
Modified
p. 21 → 18
TA3.7 The tester shall detail what methods have been implemented to disable all of the programming/testing features outlined above. The tester shall detail the testing performed to validate that these features are indeed disabled. The tester shall justify why these measures are sufficient and confirm that these features cannot be re-enabled.
Modified
p. 21 → 18
TA3.9 If the POI allows for execution of applications and firmware on the same processor that stores or operates on plaintext passwords/authentication codes, PINs, or public keys, the tester shall note what mechanisms are implemented to prevent these applications from modifying this information. The tester shall detail how this has been validated as sufficient.
Modified
p. 21 → 18
TA3.10 Where signatures are used as a method of protection, the tester shall:
Modified
p. 21 → 18
b) Detail what padding scheme is used for the signatures, and justify how this prevents attacks such as padding oracle attacks.
b) Detail what padding scheme is used for the signatures and justify how this prevents attacks such as padding oracle attacks.
Modified
p. 21 → 18
TA3.11 Where physical protections are used as a method of protection (for example, when plaintext information is stored in external memory), the tester shall:
Modified
p. 22 → 19
e) If a key stream mode of encryption is used (for example, OFB), justify how the encryption of different data with the same key is prevented.
e) If a key stream mode of encryption is usedfor example, OFBjustify how the encryption of different data with the same key is prevented.
Modified
p. 22 → 19
TA3.14 The tester shall describe and produce a costing for the most feasible attack to recover sensitive information from the POI. The tester shall detail for each step whether the information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.
Modified
p. 23 → 20
For A5 monitoring sound refers to other audible sounds apart from the beep generated by the device when a key is pressed.
For A4, monitoring sound refers to other audible sounds apart from the beep generated by the device when a key is pressed.
Modified
p. 23 → 20
Methods such as video monitoring and shoulder surfing are addressed in A8.
Methods such as video monitoring and shoulder surfing are addressed in A7.
Modified
p. 23 → 20
TA4.1 The tester shall examine the vendor’s response to Section A4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI PTS POI Security Requirements for consistency relevant to A4. The vendor responses should clearly indicate how the device is protected from monitoring during PIN entry. The tester shall summarize the responses.
Modified
p. 23 → 20
TA4.2 The tester shall examine and cite any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS POI Evaluation Vendor Questionnaire.
Modified
p. 23 → 20
TA4.3 The tester shall provide a circuit diagram of the input power circuitry of the POI, including any elements used to provide isolation of the power and EM emissions of the device.
Modified
p. 23 → 20
TA4.4 Using an in-line resistor, current probe, or other suitable method, the tester shall monitor the (external) current drawn by the POI when pressing each of the ten numeric buttons during a PIN entry function. The tester shall ensure methods are implemented to trigger the captures at the same time (for example, use the signal that drives the sounding device of the POI). The tester shall detail the method used, providing photographs of the test setup.
Modified
p. 23 → 20
TA4.5 The tester shall analyze the power captures obtained, as stated above, in both the time and frequency domains to determine whether any of the button presses provide a unique pattern that may be used to distinguish that button press from all others. The tester shall detail analysis and justify any conclusions drawn, referencing images where suitable as evidence. Generally, an initial observation of obtained signals is insufficient to validate that sensitive information does not leak. It is necessary to …
Modified
p. 23 → 20
TA4.6 Examine the layout and signal structure of the PIN input component (keypad) and determine how any sensitive information leakage by EM emissions may occur. Summarize findings.
Removed
p. 24
TA5.9 The tester shall use a microphone to monitor the signal for each of the ten numeric buttons. The tester shall perform signal analysis and signal processing as necessary to demonstrate that audible information determining key-press values is not leaked by the POI.
Modified
p. 24 → 21
TA4.11 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring, using attack scenarios. If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one …
Modified
p. 25 → 22
Keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered.
Keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix E, they do not need to be considered.
Modified
p. 25 → 22
TA5.1 The tester shall examine the vendor’s response to Section A5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS POI Security Requirements for consistency relevant to A5. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any PIN-security-related cryptographic key resident in the device. The tester shall summarize the responses.
Modified
p. 25 → 22
TA5.2 The tester shall examine and cite any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 25 → 22
TA5.4 The tester shall provide details on the type, location, and accessibility, of the security processor(s) used by the POI, and any other elements of the POI that have relevance to possible attacks. The tester shall reference information previously supplied in DTRs A1 and A3 where applicable.
Modified
p. 25 → 22
TA5.5 The tester shall provide details on how cryptographic keys are stored and managed within the POI. The tester shall reference this information to the table provided in DTR A3. The tester shall detail the testing performed to confirm the storage locations listed are correct.
Modified
p. 25 → 22
TA5.6 The tester shall provide details on any specific protections provided by the security processor that are designed to obstruct obtaining or determining the values of cryptographic keys.
Modified
p. 25 → 23
TA5.8 Verify the items above, generally using source-code review, that the side-channel protection methods are implemented. For example, if the POI relies on protections provided by the processor hardware cryptographic engine, the tester shall confirm that the registers that enable this protection are correctly set by the POI firmware before every use of this cryptographic engine. If the protections are provided by the firmware, the tester shall check that the implementation is as described by the vendor. This evaluation activity …
Removed
p. 26
TA6.10 The tester shall:
Modified
p. 26 → 23
The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device, consistent with an attack cost rating of 35 for identification and initial exploitation with a minimum of 15 for exploitation Justifications of these to be reported shall include (but are restricted to): the number of sample recordings acquired, sampling frequencies, alignment methods, signal analysis / filtering techniques, and correlation function(s) used, etc. Evidence to support …
Modified
p. 26 → 23
The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no greater than two years older than the date of the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A6 security requirements. To achieve this justification, the tester must provide thorough explanations of test methodologies and findings, sufficient to demonstrate these …
The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no greater than three years older than the date of the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A5 security requirements.
Modified
p. 26 → 24
b) Refer to testing and results from DTR A4 where applicable.
b) Refer to testing and results from DTR A3 where applicable.
Modified
p. 26 → 24
TA5.12 The tester shall describe what protections are implemented within the cryptographic processing elements to protect against physical attacks at the chip level to extract the cryptographic keys. The tester shall review the source code of the POI to confirm that any protection measures relied upon are enabled and effective.
Modified
p. 27 → 24
TA5.14 If the POI stores plaintext cryptographic keys within external memory, the tester shall detail the physical security methods implemented to protect this memory. Note that PCB-based tamper grids are not considered sufficient to protect plaintext cryptographic keys.
Modified
p. 27 → 24
TA5.15 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the POI, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.
Modified
p. 27 → 24
TA5.16 If the attack costing for DTR A3 was found to be less than the minimum points required for this DTR, the tester shall justify why the attack for DTR A3 cannot be used to recover cryptographic keys.
Modified
p. 28 → 25
A6 is applicable to a device that contains a display and may output non-PIN data.
Modified
p. 28 → 25
TA6.1 The tester shall examine the assertions provided by the vendor in response to Section A6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A6 of the PCI PTS POI Security Requirements for consistency relating to unauthorized alterations of prompts. The vendor responses should clearly indicate how display prompts are protected. The tester shall summarize the responses.
Modified
p. 28 → 25
TA6.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information on how prompts are generated and administered to determine whether it is possible to perform unauthorized alterations of prompts.
Modified
p. 28 → 25
TA6.3 The tester shall describe whether the POI allows for entry of non-PIN data to be passed external to the POI and whether that data is protected during the transfer. This non-PIN data must not be encrypted using the PIN key of the POI. The tester shall complete the following steps if the POI provides such functionality.
Modified
p. 28 → 25
TA6.4 The tester shall describe the path from the display to the processing element that controls the display. Specifically, the tester shall note whether this is the security processor that handles PIN entry and/or cryptographic keys, or whether a different processing element is used. The tester shall include information on any connectors, cables, or other sub-components that lie in this path.
Modified
p. 28 → 25
TA6.5 The tester shall describe the physical protections implemented to secure access to the display and path from the display to the controlling processing element. The tester shall make specific note of the following:
Modified
p. 28 → 25
TA6.6 The tester shall detail where prompts used for non-PIN entry are stored within the POI, and describe the protections implemented to protect these prompts. The tester shall reference this information to the table of sensitive information provided in DTR A3.
Removed
p. 30
TA8.1 The tester shall examine the vendor’s response to Section A8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A8 of the PCI PTS POI Security Requirements for consistency relevant to A8. The vendor responses should clearly indicate how visual observation deterrents are provided. The tester shall summarize the responses.
Modified
p. 30 → 27
TA7.2 The tester shall examine the means to deter the visual observation of PIN values provided by the device, and/or as described in the device documentation, to verify the assertions of the vendor. If the device provides physical observation deterrents, the tester shall show one or more images of these to support any conclusions.
Modified
p. 30 → 27
TA7.3 The tester shall describe whether the POI requires external power or communications connections or is intended to be operated with no external cable connections.
Modified
p. 30 → 27
TA7.4 The tester shall review any marketing literature and/or operations manuals provided with the POI, and state whether any of these explicitly describe handheld or desk-mounted operation.
Modified
p. 30 → 27
TA7.5 The tester shall review any marketing literature and/or operations manuals provided with the POI, and state whether any of these explicitly describe handheld or desk-mounted operation or add-on components such as privacy shields. The tester shall detail any literature used to reach this conclusion.
Modified
p. 30 → 27
TA7.6 The tester shall note whether the POI is intended to be deployed equipped with a privacy shield or whether the POI casing provides any fixture points, recess, or other indications that a privacy shield may be provided.
Modified
p. 30 → 27
TA7.7 The tester shall note whether the POI provides any screw points or other fixtures designed to facilitate the mounting of the POI into a stand or other receptacle that would preclude the device’s being operated in a handheld mode.
Modified
p. 31 → 28
Note: For a horizontal layout, exchange “width” and “length.” TA8.9 Using the above information, the tester shall state whether it is likely that the POI will be operated as a handheld or desk-mounted device. The tester shall justify the conclusions.
Note: For a horizontal layout, exchange “width” and “length.” TA7.9 Using the above information, the tester shall state whether the POI is designed such that handheld operation is enforced. The tester shall justify the conclusions.
Modified
p. 31 → 28
TA7.10 If the device provides a privacy shield, the tester shall complete the table below with angles of observation to the center of the “5” key. If the observation angle is taken from an angle other than the absolute horizontal plane (not the “flat” plane of the POI casing) the tester shall justify why this is the case (see Annex A of the Vendor Questionnaire).
Modified
p. 31 → 28
TA7.11 If the means to deter visual observation are not an integral part of the PIN entry device, the vendor shall specify by appropriate means (for example, drawings and description) how the visual observation is deterred by the structure or piece of equipment housing the device. These specifications shall be binding for the vendor and specified in the vendor security policy described in B20. The tester shall examine this specification to deter the visual observation of PIN values provided by …
Modified
p. 31 → 28
TA7.12 The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.
Modified
p. 32 → 29
TA8.1 The tester shall examine the vendor’s response to Section A8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A8 of the PCI PTS POI Security Requirements for consistency relevant to A8. The vendor responses should clearly indicate how the magnetic-stripe reader is protected. The tester shall summarize the responses.
Modified
p. 32 → 29
TA8.2 The tester shall examine and cite any additional relevant documentation, such as functional documentation, user guidance, test documentation and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 32 → 29
TA8.3 The tester shall describe whether the POI allows for capture of data from the magnetic stripe of a payment card. If the device processes magnetic-stripe information but does not integrate a magnetic-stripe card reader, the tester shall detail how magnetic-stripe information is obtained by the POI and provide any APIs used for this purpose. The tester shall only complete the following steps if the POI has an integrated magnetic-stripe card reader.
Modified
p. 32 → 29
TA8.4 The tester shall describe the location and operation of the magnetic-stripe card reader. The tester shall show one or more images of the device’s magnetic-stripe reader and associated hardware to support any conclusions.
Modified
p. 32 → 29
TA8.5 The tester shall describe the path from the magnetic-stripe card reader to the security processor, including any cables, connectors, or other sub-elements on this path.
Removed
p. 33
TA9.9 The tester shall describe and provide the most feasible costing for recovery of magnetic-stripe card data from the POI.
Modified
p. 33 → 30
TA8.7 If the device implements physical protections for the magnetic-stripe card reader, either in addition to or in lieu of logical protections, the tester shall detail the physical protections implemented to protect this path. The tester shall justify how this is sufficient to protect the entire path of the magnetic-stripe card signals from the read head to the security processor, including all vias, traces, connectors, and the pins on the read head itself.
Modified
p. 33 → 30
TA8.8 The tester shall provide measurements of any free space around the magnetic-stripe read head. The tester shall justify why placement of a secondary read head is made infeasible by the POI design, either through lack of space and/or through the physical protections of the POI. The tester shall check for any free space on the opposite site of the magnetic-stripe read head to analyze whether a reader with the capability to read heads regardless of the way the card …
Modified
p. 33 → 30
If an attack scenario can be developed that yields an attack potential of less than 16 per device for identification and initial exploitation or less than 8 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document. Calculations shall include evidence justifying particular rating levels as being appropriate.
If an attack scenario can be developed that yields an attack potential of less than 16 per device for identification and initial exploitation or less than 8 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. The tester may perform any test needed to validate the attack scenario. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual …
Modified
p. 34 → 31
The objective of this requirement is to assess the device’s ability to protect the component against removal from its frame or the cabinet. This protections aims against component device overlays or chained ICC readers; it also aims at complicating attacks against the component wherein it is taken away by attackers in order to perform subsequent attack steps under controlled conditions. This requirement applies to components that are used for PIN entry or handle the PIN, such as an ICCR.
The objective of this requirement is to assess the device’s ability to protect the component against removal from its frame or the cabinet. This protection aims against component device overlays or chained ICC readers; it also aims at complicating attacks against the component wherein it is taken away by attackers in order to perform subsequent attack steps under controlled conditions. This requirement applies to components that are used for PIN entry or handle the PIN, such as an ICCR.
Modified
p. 34 → 31
• Provide accountability and traceability including logging of user IDs, date and time stamp, and actions performed;
Modified
p. 34 → 31
OEM products that are “bolt-on” or drop-in type modules (e.g., OEM PEDs) for UPTs do not require removal protections if the module provides a complete tamper envelope around all security sensitive parts; and any attacks considered during the evaluation must not assign any points to access of the device, or the “fixing” of any tamper evidence with replacement parts or stickers (unless the attack must go through the front). In the absence of removal detection it should be assumed that …
Self-contained OEM products that are “bolt-on” or drop-in type modules, i.e. fully functional PED modules integrating all required components, do not require removal protections if the module provides a complete tamper envelope around all security sensitive parts; and any attacks considered during the evaluation must not assign any points to access of the device, or the “fixing” of any tamper evidence with replacement parts or stickers (unless the attack must go through the front). In the absence of removal detection, …
Modified
p. 34 → 31
TA9.1 The tester shall examine the vendor’s response to Section A9 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A9 of the PCI PTS POI Security Requirements for consistency relevant to A9. The vendor responses should clearly indicate what component protections against removal exist and how they are robust. The tester shall summarize the responses.
Modified
p. 34 → 31
TA9.2 The tester shall visually inspect the device to verify the assertions provided by the vendor in response to Section A9 PCI PTS POI Evaluation Vendor Questionnaire.
Modified
p. 34 → 31
TA9.3 The tester shall examine additional relevant documentation, such as schematics and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 35 → 32
• By having the device go to an unauthorized state upon removal, requiring an authorized re-installation process.
Modified
p. 35 → 32
TA9.5 The tester shall review the device literature provided by the vendor, as well as perform a search of publically available information. The tester shall note whether any information is found to indicate that the POI may be used in an unattended environment.
Modified
p. 35 → 32
TA9.6 The tester shall review the device security policy and note whether this clearly states the environments in which the POI is intended for use (attended, unattended or both). If the device is not intended for use in an unattended environment, no further testing is necessary.
Modified
p. 35 → 32
TA9.7 The tester shall note what mechanisms are used to detect the removal of the POI from its installed environment. The tester shall provide photographs of the mechanism(s).
Modified
p. 35 → 32
TA9.8 The tester shall detail the testing apparatus used to emulate the POI installation environment so that the removal detection mechanisms can be tested. The tester shall provide and cross- reference the findings to photographs or other images to demonstrate the device’s behavior under testing.
Modified
p. 35 → 32
TA9.9 The tester shall detail what occurs if the removal detection mechanism(s) are activated and justify how this prevents the use of the POI for PIN entry.
Modified
p. 35 → 32
TA9.10 The tester shall note whether the POI allows for authorized removal, such that the removal detection is disabled before removal of the device. The tester shall detail how the authorization process is performed. The tester shall confirm (and detail testing and findings for) the following:
Modified
p. 35 → 32
a) The process provides dual control through use of two or more passwords/PINs that are a minimum of seven characters or an equivalent strength and entered through the secure keypad of the POI; or
a) The process provides dual control through use of two or more passwords/authentication codes that are a minimum of seven characters or an equivalent strength and entered through the secure keypad of the POI; or
Modified
p. 35 → 32
TA9.11 The tester shall detail how the POI is initially installed into its operational environment, noting the order in which the removal detection is activated and/or cryptographic keys are loaded into the POI. The tester shall confirm that this is consistent with all testing and vendor documentation.
Modified
p. 35 → 32
TA9.12 The tester shall develop attack scenario(s) to defeat or circumvent the protection against removal. If an attack scenario can be developed that yields an attack potential of less than 18 per device for identification and initial exploitation or less than 9 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document.
Modified
p. 36 → 33
TA10.1 The tester shall examine the vendor’s response to Section A10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A10 of the PCI PTS POI Security Requirements for consistency relevant to A10. The vendor responses should clearly indicate why audible tones during PIN entry cannot be used to distinguish PIN digits. The tester shall summarize the responses.
Modified
p. 36 → 33
TA10.2 The tester shall examine and cite any additional information (i.e., specifications, schematics, block diagrams, etc.) that contains information on tone generation during PIN entry to determine whether it supports the assertions made by the vendor.
Modified
p. 36 → 33
TA10.3 The tester shall describe the method used by the POI to provide audible feedback for customer PIN entry, detailing what method is used to control both the duration and frequency of the audible tone.
Modified
p. 36 → 33
TA10.4 The tester shall connect an oscilloscope to the input of the sounding device of the POI and use microphones to monitor the signal for each of the ten numeric buttons. The tester shall perform signal analysis and signal processing as necessary to demonstrate that audible information determining key-press values is not leaked by the POI. The signals obtained should be sufficiently free from noise for the following analysis steps to be adequately performed. Perform multiple entries for each of …
Modified
p. 37 → 34
The device must perform an internal self-test automatically at least once every day, in addition to at power-up. It is acceptable to perform firmware integrity checks before each PIN transaction as opposed to performing them at least once every 24 hours. Self-tests after several minutes of inactivity may also be used, rather than once every 24 hours, in addition to power-up self-tests.
The device must perform an internal self-test automatically at least once every day, in addition to power-up (excludes wake-up from hibernation mode). It is acceptable to perform firmware integrity checks before each PIN transaction as opposed to performing them at least once every 24 hours. Self-tests after several minutes of inactivity may also be used, rather than once every 24 hours, in addition to power-up self-tests.
Modified
p. 38 → 35
TB1.5 The tester shall verify that the device self-tests are able to detect failures and in doing so, fail in a secure manner. The vendor shall provide evidence of testing that confirms the relevant component’s fails securely in the event of self-test failure.
Modified
p. 38 → 35
TB1.3 The tester shall describe the boot chain of the POI. The tester shall Include how initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are sequenced, loaded, and executed, up to and including software modules used for PIN entry functions, account data processing, and OP modules.
Removed
p. 39
The device controller is not in scope for this requirement for unattended devices.
Modified
p. 39 → 37
Vendors should provide software-design rules and specifications to support answers.
Vendors should provide software-design rules and specifications to support answers. .
Modified
p. 39 → 37
The Open Protocol Module shall be used to assess any communication method that uses a wireless, local, or wide-area network to transport data. This would include but is not limited to: Bluetooth, Wi-Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless or through a hub, switch, or other multiport device. In addition, any communication that uses a public domain protocol or security protocol would be assessed with the …
Modified
p. 39 → 37
TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS POI Security Requirements for consistency to verify that the relevant component’s functionality shall not be influenced by logical anomalies such as (but not restricted to): unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying invalid parameters or data that could result in the relevant component’s outputting the …
The device controller is not in scope for this requirement for unattended devices TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS POI Security Requirements for consistency to verify that the relevant component’s functionality shall not be influenced by logical anomalies such as (but not restricted to): unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying …
Modified
p. 39 → 37
TB2.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant component’s logical structure, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
TB2.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
Modified
p. 39 → 37
TB2.3 The tester shall analyze the vendor’s measures that ensure the relevant component’s functionality is not influenced by logical anomalies such as unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
TB2.3 The tester shall describe the vendor’s measures that ensure the relevant component’s functionality is not influenced by logical anomalies such as unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified
p. 39 → 37
TB2.4 The tester shall note the languages in which the POI source code is written for each of the security processing elements (as detailed in DTR A4).
TB2.4 The tester shall note the programming languages in which the POI’s firmware source code is written for each of the security processing elements (as detailed in DTR A3).
Modified
p. 39 → 37
TB2.5 The tester shall detail the type and configuration of the operating system(s) used on each of the POI security-processing elements (as detailed in DTR A4).
TB2.5 The tester shall detail the type, version, capabilities, and configuration of the operating system(s) used on each of the POI security-processing elements (as detailed in DTR A3).
Removed
p. 40
TB2.10 For systems that are designed to execute non-firmware applications, the tester shall use the development environment for the POI to create a program with a buffer-overflow vulnerability. The tester shall determine that the device behaves in accordance with the specifications.
TB2.12 The tester shall perform “fuzzing” of selected commands of each of the POI interfaces by exploring methodologies most likely to achieve compromises of the POI. The tester shall describe any assistance provided by the vendor to promote efficient fuzzing•for example, information supplied to systematically support white-box test methods). The tester shall develop these analysis paths to provide an optimum balance between the use of evaluation resources for penetration testing and reliance upon the vendor-provided information. The tester shall describe fuzzing processes and tools used, results obtained, and justify why this is considered sufficient to provide a demonstrably high level of confidence in the security of the POI interfaces, being …
TB2.12 The tester shall perform “fuzzing” of selected commands of each of the POI interfaces by exploring methodologies most likely to achieve compromises of the POI. The tester shall describe any assistance provided by the vendor to promote efficient fuzzing•for example, information supplied to systematically support white-box test methods). The tester shall develop these analysis paths to provide an optimum balance between the use of evaluation resources for penetration testing and reliance upon the vendor-provided information. The tester shall describe fuzzing processes and tools used, results obtained, and justify why this is considered sufficient to provide a demonstrably high level of confidence in the security of the POI interfaces, being …
Modified
p. 40 → 38
TB2.9 The tester shall detail in an appendix to the evaluation report a complete list of all APIs as defined by the vendor that are provided on each of the logical interfaces of the POI.
Modified
p. 40 → 38
TB2.10 The tester shall perform a source-code review of each relevant interface and confirm that it is handled securely, that only documented commands are implemented, and that secure defaults are provided for each interface. The tester shall detail the methods used to verify the length and content of each command before processing. The tester shall derive and describe vulnerability- analysis models from source-code review and other available evidence to determine attack paths and appropriate penetration testing.
Modified
p. 40 → 38
In case the POI includes Open Protocols, this task shall be performed together with the task required by DTR G2, on the additional interfaces of the POI not identified as an Open Protocol, and shall follow the methodology proposed in DTR G2.
Modified
p. 40 → 39
TB2.15 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.
Removed
p. 41
TB3.4 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware revision number.
Modified
p. 41 → 40
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, except for SCRs intended for use with COTS devices and SCRPs, where all code is considered firmware.
Modified
p. 41 → 40
• Mitigating them by techniques that include but are not limited to: Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Harvard Architecture and Stack Canaries.
Modified
p. 41 → 40
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS POI Security Requirements manual for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS POI Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
Modified
p. 41 → 40
TB3.4 The tester shall detail any compiler settings used by the vendor in order to maximize the mitigation of known vulnerabilities. If no specific compiler settings are used, the tester shall detail how known vulnerabilities are mitigated.
Modified
p. 41 → 40
TB3.5 The tester shall detail any mitigation techniques used by the vendor to help prevent common exploit. The tester must state and justify any reliance placed on these technique(s) in minimizing testing. If no specific techniques are used, the tester shall detail how the common exploits are prevented.
Removed
p. 42
TB3.15 The tester shall review previous firmware-verification audit reports and summarize these reports and their findings. The tester shall ensure that the reports sampled include security problems found during the review, and confirm that these problems have been addressed. If all audit reports reviewed indicate that no security problems have been found, the tester shall justify why it is possible that the firmware image is, and has always been, completely free of security defects.
Modified
p. 42 → 41
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers and testers, and does not rely on non-specific statements (for example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
TB3.7 The tester shall confirm that
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers and testers, and does not rely on non-specific statements (for example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers and testers, and does not rely on non-specific statements (for example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
Modified
p. 42 → 41
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR
TB3.8 The tester shall confirm that
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
Modified
p. 42 → 41
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.
TB3.9 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.
Modified
p. 42 → 41
TB3.10 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the POI code.
Modified
p. 42 → 41
TB3.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed after every security-relevant change, and before the firmware is released to production.
Modified
p. 42 → 41
TB3.12 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable process that shows the code review and security testing have been performed, and requiring sign-off by the person(s) performing the code review and security testing. The tester shall confirm that the process will show any problems noted during the code review and security testing.
Modified
p. 42 → 41
TB3.13 The tester shall obtain, review, and summarize the firmware-verification audit results provided by the vendor for the version of firmware submitted for evaluation. The tester shall confirm that this shows that no problems were found during review of this firmware (or that any problems found have been addressed).
Modified
p. 42 → 41
TB3.15 The tester shall identify and review publically available sources of vulnerability disclosure, including but not necessarily limited to those referenced in the vendor-certification process document and shall check that any vulnerabilities found cannot be exploited on the POI. The tester shall compare his/her analysis with the analysis provided by the vendor and confirm that the vendor has remediated any problems with these vulnerabilities, and that firmware-audit report documents exist and have been updated to validate this assertion.
Modified
p. 43 → 42
TB3.17 The tester shall outline the following information: If the firmware is based on a general-purpose operating system (like Linux or Windows CE), the steps described in TB3.15, in particular, hold for this operating system. The documentation provided by the developer shall show that state- of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues (like patch levels; not including unused packages, etc.; not being …
Removed
p. 44
TB4.3 The tester shall verify that the device cryptographically authenticates the software integrity. This will be accomplished, for example, by performing a simulated firmware update.
TB4.4 The tester shall verify that the device rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
TB4.4 The tester shall verify that the device rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
Modified
p. 44 → 43
The firmware and application version numbers must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. This shall be illustrated by photographic evidence provided in the evaluation report.
The firmware and application version numbers, and optionally the hardware version number must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. This shall be illustrated by photographic evidence provided in the evaluation report.
Modified
p. 44 → 43
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI PTS POI Security Requirements manual for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI PTS POI Security Requirements for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
Modified
p. 44
TB4.4 The tester shall determine by which component the authentication is performed.
Modified
p. 44
TB4.5 The tester shall determine the level of protection for the external component involved in firmware/software updates and that the authentication of firmware updates is performed by a component of equal or greater strength.
Modified
p. 44
TB4.6 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
Modified
p. 45 → 44
TB4.8 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 45 → 44
TB4.9 If the POI allows for loading of multiple types of code (for example, firmware for security processor, firmware for magnetic-stripe reader encryption chip, application code, etc.), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.
Modified
p. 45
TB4.11 If a CBC MAC is used for firmware authentication, the tester shall detail what methods are used to mitigate vulnerabilities when authenticating variable-length data.
Modified
p. 46 → 45
a) Confirm that it loads correctly into the POI. The tester shall detail the loading process.
a) Confirm that it loads correctly into the POI. The tester shall detail the process involved in performing the loading.
Modified
p. 46 → 45
TB4.13 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.
Removed
p. 47
TB4.1.3 The tester shall verify that the device cryptographically authenticates application integrity. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update.
TB4.1.4 The tester shall verify that the device rejects unauthorized applications. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update with inadequate or modified authentication information.
TB4.1.4 The tester shall verify that the device rejects unauthorized applications. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update with inadequate or modified authentication information.
Modified
p. 47 → 46
Applications are considered to be any code that can be loaded onto the device that is not firmware. This includes any non-firmware code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
Applications are considered to be any code that can be loaded onto the device that is not firmware. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
Modified
p. 47 → 46
TB4.1.3 The tester shall determine by which component the authentication is performed.
Modified
p. 47 → 46
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component
TB4.1.4 The tester shall determine the rank of protection strength for the component involved in application loads
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component TB4.1.5 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component TB4.1.5 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
Modified
p. 47 → 46
TB4.1.6 For each of the processing elements listed in DTR A3, the tester shall complete the following table. (See Annex A of the Vendor Questionnaire.) Where different parts of the code (for example, boot code, main firmware, etc.) can be updated independently, or if one part of the application cannot be updated, the tester shall ensure that this is detailed in the table as well.
Removed
p. 48
TB4.1.10 If the POI allows for loading of multiple types of code (for example, firmware for security processor, firmware for magnetic-stripe-reader encryption chip, application code, etc.), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.
Modified
p. 48 → 47
TB4.1.7 The tester shall review the source code of the POI to confirm that the application authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 48 → 47
TB4.1.8 If (H)MAC method(s) are used for application authentication, the tester shall confirm through source-code review that the method used to compare the application-authentication block does not leak timing information•for example, the “C” memcmp() function is not used. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 48 → 47
TB4.1.9 If a CBC MAC is used for application authentication, the tester shall detail what methods are used to mitigate vulnerabilities in this method when used to authenticate variable-length data.
Modified
p. 48 → 47
TB4.1.10 For each of the methods of authentication the tester shall obtain a correctly authenticated application image and if applicable, a software and/or configuration update, and:
Modified
p. 48 → 47
c) Change a single bit in the firmware block of the image, and confirm that this modified image is rejected when loaded into the POI.
c) Change a single bit in the application block of the image, and confirm that this modified image is rejected when loaded into the POI.
Modified
p. 48 → 47
TB4.1.11 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.
Removed
p. 49
TB4.2.6 The tester shall validate the documented justification for loading each unsigned file to ensure the file cannot affect the security of the device and that the justification is complete and correct.
Modified
p. 49 → 48
• The signing process is performed under dual control.
Modified
p. 49 → 48
• All executable files are signed.
Modified
p. 49 → 48
• Software is only signed using a secure cryptographic device provided by the terminal vendor.
Modified
p. 49 → 48
TB4.2.6 The tester may perform any additional analysis necessary to validate the device’s documentation. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified
p. 50 → 49
A PIN-handling component of the device (for example, the PIN entry device) never outputs information to another component (for example, a display or a device controller), allowing the differentiation of the PIN digits entered.
A PIN-handling component of the device (for example, the PIN entry device) never outputs information to another component (for example, a display or a device controller), allowing the differentiation of the PIN digits entered. Digit presses on touch-screen devices should never be displayed.
Modified
p. 51 → 50
• The device has timed out waiting for the response from the cardholder or merchant.
Modified
p. 51 → 50
• That sensitive information shall not be present any longer or used more often than strictly necessary; • The immediate encryption of online PIN data; and • That the device automatically clears its internal buffers when either the transaction is completed or the device has timed out waiting for the response from the cardholder or merchant. The vendor must specify the states “completion of transaction” and “timeout” and define the appropriate actions.
Modified
p. 51 → 50
TB6.3 The tester shall verify that
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included.Passwords, plaintext cryptographic keys, or key components outside of the crypto-processor, and PIN values are considered sensitive data.
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included.
TB6.3 The tester shall verify that
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included. Passwords/authentication codes, plaintext PIN values, plaintext cryptographic keys, or key components outside of the crypto-processor are considered sensitive data.
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included. Passwords/authentication codes, plaintext PIN values, plaintext cryptographic keys, or key components outside of the crypto-processor are considered sensitive data.
Modified
p. 52 → 51
• Review of a small sample of compiled object code to validate that the code to clear the buffer remains in the compiled code;
Modified
p. 53 → 52
TB7.3 The tester shall verify from vendor documentation
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, andpasswords. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and
TB7.3 The tester shall verify from vendor documentation
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords/authentication codes. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords/authentication codes. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified
p. 53 → 52
• Data inputs cannot be discerned from any displayed characters.
Modified
p. 53 → 52
• Data inputs cannot be discerned by monitoring audible or electro-magnetic emissions.
Modified
p. 53 → 52
• Sensitive data is cleared from internal buffers upon exiting the sensitive mode.
Modified
p. 53 → 52
• Entering data while accessing sensitive services.
Modified
p. 54 → 53
TB7.10 The tester shall confirm that and describe how any entry of sensitive information through the keypad of the POI is protected to the same extent as customer PINs, conforming to all relevant requirements (such as A1, A4, and A6).
TB7.10 The tester shall confirm that and describe how any entry of sensitive information through the keypad of the POI is protected to the same extent as customer PINs, conforming to all relevant requirements (such as A1, A3, and A5).
Modified
p. 55 → 54
TB7.14 The tester shall validate that
•and describe how
•allpasswords implemented to provide dual control are at least seven characters or an equivalent strength.
•and describe how
•all
TB7.14 The tester shall validate that
•and describe how
•all passwords/authentication codes implemented to provide dual control are at least seven characters or an equivalent strength.
•and describe how
•all passwords/authentication codes implemented to provide dual control are at least seven characters or an equivalent strength.
Modified
p. 55 → 54
TB7.15 The tester shall attempt to load cryptographic keys or components into the POI without changing the default values of the passwords. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TB7.15 The tester shall attempt to load cryptographic keys or components into the POI without changing the default values of the passwords/authentication codes. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 55 → 54
TB7.16 The tester shall attempt to set the passwords in the POI so that two or more of the passwords in the same device have the same value. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TB7.16 The tester shall attempt to set the passwords/authentication codes in the POI so that two or more of the passwords/authentication codes in the same device have the same value. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 55 → 54
TB7.17 The tester shall attempt to set the passwords of the POI to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TB7.17 The tester shall attempt to set the passwords/authentication codes of the POI to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 56 → 55
• The vendor has provided a rationale for the value chosen as a limit on the number of actions and the time limits imposed.
Modified
p. 56 → 55
• The vendor has provided a rationale as to how the limits minimize the risks from unauthorized use of sensitive services.
Modified
p. 56 → 55
TB8.6 For any password-entry modes, the tester shall detail how the functional limits ensure that any arbitrary password guess has less than a 1/10000000 chance of success, and any multiple attempts within a one-minute period have a less than 1/10000 chance of success of correctly providing the password value. The tester shall detail the testing performed to validate these functional limits.
TB8.6 For any password-entry modes, the tester shall detail how the functional limits ensure that any arbitrary password/authentication code guess has less than a 1/10000000 chance of success, and any multiple attempts within a one-minute period have a less than 1/10000 chance of success of correctly providing the password/authentication code value. The tester shall detail the testing performed to validate these functional limits.
Modified
p. 56 → 55
TB8.7 For any password-entry modes, the tester shall confirm through source code examination that the method of validating the password value is not vulnerable to a timing attack (for example, a standard “strcmp” or “memcmp” function is not used), or that the functional limits are set to values that prevent utilization of any leaked timing information. This evaluation activity should be focused at relevant, security-critical sections of the source code to provide an optimum balance between use of evaluation resources …
TB8.7 For any password-entry modes, the tester shall confirm through source code examination that the method of validating the password/authentication code value is not vulnerable to a timing attack (for example, a standard “strcmp” or “memcmp” function is not used), or that the functional limits are set to values that prevent utilization of any leaked timing information. This evaluation activity should be focused at relevant, security-critical sections of the source code to provide an optimum balance between use of evaluation …
Modified
p. 57 → 56
TB8.9 For all sensitive services requiring the input of passwords and key components into the POI keypad, the tester shall confirm that an inactivity time-out is implemented such that if a button is not pressed every 60 seconds, the device will exit the sensitive state.
TB8.9 For all sensitive services requiring the input of passwords/authentication code and key components into the POI keypad, the tester shall confirm that an inactivity time-out is implemented such that if a button is not pressed every 60 seconds, the device will exit the sensitive state.
Modified
p. 58 → 57
The device shall be capable of meeting the statistical tests of NIST SPPUB 800-22). See Appendix C.
The device shall be capable of meeting the statistical tests of NIST SP PUB 800-22). See Appendix D.
Modified
p. 58 → 57
TB9.3 The tester shall detail the method used by the POI to generate random numbers, including any seed values used, hardware systems, and software-based deterministic pseudo random number generators (DPRNG). The tester shall outline the process used by the vendor to ensure that any secret values relied upon for random number generation (such as seed values, or keys used in DPRNGs) are sufficiently random, and unique per POI.
TB9.3 The tester shall detail the method used by the POI to generate random numbers, including any seed values used, hardware systems, and software-based DRBGs.
Modified
p. 59 → 58
The tester shall review the source code of each of these services, and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
TB9.6 The tester shall review the source code of each of these services and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 59 → 58
TB9.7 The tester shall obtain at least 128MB of random data from the POI under test. This data may be supplied directly by the vendor. The tester shall detail the method used to generate this data and justify why this sufficiently replicates the way in which the RNG will be used by the POI. The tester shall pass the 128MB of data through the NIST STS test program, and detail the results, indicating pass and fail results and how these …
Removed
p. 60
Use of a unique key per transaction technique. (Prevents the attack.) Preventing the entry of the PIN through other than the keypad, and limiting the rate at which the device will encrypt PINs to the average (for example, over 120 transactions) of one per 30 seconds. (Deters the attack.) The device is exclusively used for offline PIN and the ICC reader is integrated into the PIN entry device.
Modified
p. 60 → 59
• The exclusive use of ISO PIN-block formats 1, 3, and/or 4 whereby each PIN is enciphered using a unique except by chance random pad of characters with permissible values ranging from 0000 to 1111 depending on the format may be used to prevent exhaustive PIN determination.
Modified
p. 60 → 59
TB10.1 The tester shall examine the response to Section B10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS POI Security Requirements manual for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PIN determination. The tester shall summarize the responses.
TB10.1 The tester shall examine the response to Section B10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS POI Security Requirements for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PIN determination. The tester shall summarize the responses.
Modified
p. 60 → 59
TB10.4 The tester shall note whether the POI only supports ISO format 3 or ISO format 1 PIN blocks. If so, the tester shall review the source code of the POI to confirm that the padding used on these PIN blocks is generated by the random number generator validated under Requirement B9. If this is the case, no further testing is necessary for this requirement.
TB10.4 The tester shall note whether the POI only supports ISO format 4 or format 3 or ISO format 1 PIN blocks. If so, the tester shall review the source code of the POI to confirm that the padding used on these PIN blocks is generated by the random number generator validated under Requirement B9. If this is the case, no further testing is necessary for this requirement.
Modified
p. 61 → 60
TB10.7 Using a functional sample device, the tester shall attempt to perform at least 120 PIN entry operations. The tester shall note the time taken and the response of the POI when the final transaction is performed, and whether another transaction is possible before an elapsed time of one hour from the entry of the first PIN.
Modified
p. 61 → 60
TB10.8 Using a functional sample device, the tester shall attempt to perform 120 PIN entry operations in less than one hour. If the device blocks attempts to perform PIN entry, the tester shall remove the power from the device. Upon re-powering the device, the tester shall attempt to perform another PIN entry operation and note whether this is possible. The tester shall describe the device’s behavior under this test. If the tester can perform another (121st) PIN entry, the device …
Modified
p. 61 → 60
TB10.9 If the method used to prevent the entry of more than 120 PINs within an hour utilizes the real- time clock of the POI, the tester shall detail what methods are available to change the value of this clock and justify why these methods do not allow for the bypassing of the PIN entry rate limiting.
Removed
p. 62
Be secret; Be generated randomly or pseudo-randomly; Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source; Be used in the appropriate order as specified by the particular mode; Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and Cannot be unbundled for any purpose.
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.
Loaded using asymmetric keys of equivalent or greater strength. …
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.
Loaded using asymmetric keys of equivalent or greater strength. …
Modified
p. 63
TB11.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods. (Note: EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d.)
TB11.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods. (Note: EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d.). SCRPs shall only support the loading of encrypted keying material.
Modified
p. 63
a) When entering plaintext secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally …
a) When entering plaintext secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/authentication codes that are unique per device …
Modified
p. 63
Entry of key components without the use of at least two separate passwords/PINs results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Modified
p. 63 → 64
Injection of plaintext secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Injection of plaintext secret keys or their components/shares where the device does not itself require the use of at least two passwords/authentication codes for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Modified
p. 64
d) Remote key-loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements.
d) Remote key-loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements. See below for further information.
Modified
p. 64
TB11.6 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange, or establishment are stated in Appendix D.
TB11.6 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange, or establishment are stated in Appendix E.
Modified
p. 64
If a public-key technique for the distribution of symmetric secret keys is used, it must:
If a public-key technique for the remote distribution of symmetric secret keys is used, it must:
Modified
p. 64
a) Use public and private-key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA, see also DTR B16.2).
a) Use public and private-key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA).
Modified
p. 64
TB11.9 The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 DUKPT, fixed key, or Master/Session key management.
TB11.9 The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 DUKPT, Fixed key, or Master/Session key management.
Modified
p. 66 → 68
TB11.16 Using the key table as a reference, the tester shall confirm that all keys are unique per device, and what method is used to ensure this is the case.
TB11.16 Using the key table as a reference, the tester shall confirm that all secret and private keys are unique per device, and what method is used to ensure this is the case.
Modified
p. 66 → 68
b) The tester shall detail any key-generation methods used, and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.
b) The tester shall detail any key-generation methods used and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.
Modified
p. 66 → 69
b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to six hexadecimal characters or less or they are never output from the POI.
b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to values as defined in TB11.22 or they are never output from the POI.
Modified
p. 66 → 69
c) The method used does not rely on the check digits (e.g., mod 10 calculation) of a (T)DES key as part of the key comparison.
c) The method used does not rely on the check digits (e.g., mod 10 calculation) of a (T) DES key as part of the key comparison.
Modified
p. 66 → 69
TB11.22 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value of more than six hexadecimal values from the POI.
TB11.22 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value except as noted below
Modified
p. 67 → 69
• Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.
Modified
p. 67 → 70
TB11.26 For any methods that rely on the use of key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. The requirements of this DTR are not met if it is possible …
TB11.26 For any methods that rely on the use of full-length key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. For key shares, the tester shall use the same value for …
Removed
p. 68
Note: The device must support at least one of the following key-management techniques using TDES as described in ANSI X9.24 and ISO/IEC 18033-3:
DUKPT Fixed Master/Session The device must also support at least one of the following PIN block formats if supporting online PIN entry:
ISO Format 0 ISO Format 1 ISO Format 3 For offline PIN:
b) Where the ICC reader is not integrated into the PIN entry device, and PINs are enciphered only for transmission between the PIN entry device and the IC reader, the device shall use one of the PIN block formats specified in ISO 9564-1. Where ISO Format 2 PIN blocks are used, a unique key per transaction method in accordance with ISO 11568 shall be used. Format 2 shall be used only in connection with either offline PIN verification or PIN-change operations in connection with ICC environments.
DUKPT Fixed Master/Session The device must also support at least one of the following PIN block formats if supporting online PIN entry:
ISO Format 0 ISO Format 1 ISO Format 3 For offline PIN:
b) Where the ICC reader is not integrated into the PIN entry device, and PINs are enciphered only for transmission between the PIN entry device and the IC reader, the device shall use one of the PIN block formats specified in ISO 9564-1. Where ISO Format 2 PIN blocks are used, a unique key per transaction method in accordance with ISO 11568 shall be used. Format 2 shall be used only in connection with either offline PIN verification or PIN-change operations in connection with ICC environments.
Modified
p. 68 → 71
TB12.1 The tester shall examine the response to Section B12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS POI Security Requirements manual for consistency relating to the TDES or AES PIN-encryption implementation in the device and compliance with ISO 9564. The tester shall summarize the responses.
TB12.1 The tester shall examine the response to Section B12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS POI Security Requirements for consistency relating to the TDES or AES PIN-encryption implementation in the device and compliance with ISO 9564. The tester shall summarize the responses.
Modified
p. 68 → 72
TB12.4 From the above list of PIN-block formats, the tester shall confirm that the POI supports at least one format that is compliant with ISO 9564 (format 0, 1, or 3 for online PINs if the device supports online PIN, and format 2 for offline PINs if the device supports offline PIN).
TB12.4 From the above list of PIN-block formats, the tester shall confirm that the POI supports at least one format that is compliant with ISO 9564 (format 0, 1, 3 or 4 for online PINs if the device supports online PIN, and format 2 for offline PINs if the device supports offline PIN).
Modified
p. 68 → 72
TB12.6 The tester shall detail all methods that the POI supports for external PIN transfer. This will include encryption of PINs for transport to an acquiring financial institution, as well as transfer to any external card readers or other devices/sub-components outside of the area of the POI validated as secure under Requirement A1.
Modified
p. 69 → 72
TB12.8 For each ISO-compliant PIN-block method supported by the POI, the tester shall perform a PIN entry operation and confirm that:
Modified
p. 69 → 72
TB12.9 For PIN-block formats 0, 3, and 4, the tester shall confirm whether the PAN values are supplied by the firmware or by the application. If the values are provided by the firmware, the tester shall confirm that the correct digits of the PAN are used in the PIN block. If the values are provided by the application, the tester shall confirm that the POI development documentation details the correct values of the PAN to be used. Note: For SCRPs, …
Modified
p. 70 → 73
PIN-encryption keys shall only be used to encrypt PIN data. Key-encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt PIN data.
PIN-encryption keys shall only be used to encrypt PIN data. Key-encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt PIN data. Data keys shall not be used to encrypt other keys or PIN data.
Modified
p. 70 → 73
A secret key used to encrypt a PIN must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose. However, variants of the same key may be used for different purposes. Any variant of the PEK or a key used to protect the PEK must be protected in the same manner, i.e., under the principles of dual control and split knowledge. Any key calculated as …
A secret key used to encrypt a PIN must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose. However, variants of the same key may be used for different purposes. Any key calculated as a variant of another key shall be protected in a manner equivalent to or greater in security as the original key•i.e., under the principles of dual control and split knowledge. …
Modified
p. 70 → 73
The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus the uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded. The check must occur across all secret-key hierarchies supported by the device. No two secret keys, regardless of purpose, can have the same value.
The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus the uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded. The check must occur within all secret-key hierarchies supported by the device. No two secret keys, regardless of purpose, can have the same value.
Modified
p. 70 → 73
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS POI Security Requirements manual for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses.
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS POI Security Requirements for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses.
Modified
p. 71 → 74
• The key-usage information of any downloaded key must be cryptographically bound to the key value using accepted methods, and the device must enforce that the key is only used for the intended use.
Modified
p. 71 → 74
• The addition of a new key type (slot) subsequent to the initial configuration of the device causes the zeroization of all other secret keys. Devices supporting remote key- distribution techniques using asymmetric techniques shall only support the use of such techniques for the loading of TMKs. Support shall not exist to use remote key-distribution techniques for working keys (for example, PIN, data, MAC, etc.) unless the key-usage information is cryptographically bound to each individual key.
Modified
p. 71 → 74
• Downloaded data keys must not be accepted by the device unless enciphered by a terminal master key that is different than sensitive keys such as the PEK or MAC key types.
Modified
p. 71 → 74
• The device does not provide any support for a decrypt data or similar function.
Modified
p. 72 → 75
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B14 of the PCI PTS POI Security Requirements manual for consistency relating to the output of clear-text keys and protection of PINs. The clear-text PIN must never exist in an unprotected environment. The tester shall summarize the responses.
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B14 of the PCI PTS POI Security Requirements for consistency relating to the output of clear-text keys and the protection of PINs. The clear-text PIN must never exist in an unprotected environment. The tester shall summarize the responses.
Modified
p. 74 → 77
B16 applies to both acquirer and vendor controlled prompts that are updatable.
B16 applies to both acquirer and vendor-controlled prompts that are updatable.
Modified
p. 74 → 77
Prompts stored inside the cryptographic unit are physically protected according to Requirement A7.
Prompts stored inside the cryptographic unit are physically protected according to Requirement A6.
Modified
p. 74 → 77
If the device model is to be listed as both an acquirer-controlled and a vendor-controlled display- prompts device, there must be a differentiation so customers can distinguish between the two (for example, different hardware and/or firmware versions).
If the device model is to be listed as both an acquirer-controlled and a vendor-controlled display- prompts device, there must be a differentiation so acquirers/merchants can distinguish between the two (for example, different hardware and/or firmware versions).
Modified
p. 74 → 77
Cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication do not need to be considered secret data and therefore do not need to be erased.
Cryptographic keys that are never used to encrypt or decrypt data or are not used for authentication do not need to be considered secret data and therefore do not need to be erased.
Modified
p. 74 → 77
Dual control must be enforced by an SCD. The SCD can be the PED itself or another device. If an SCD other than the PED enforces dual control, the vendor must either provide the SCD to third parties, or describe how an SCD must be used to comply with B16.2. The description must include an example of a specific, existing SCD that can be purchased and used to comply with B16.2. The PED must have an API that is compatible …
Dual control must be enforced by an SCD. The SCD can be the PED itself or another device. If an SCD other than the PED enforces dual control, the vendor must either provide the SCD to third parties, or describe how an SCD must be used to comply with B16. The description must include an example of a specific, existing SCD that can be purchased and used to comply with B16. The PED must have an API that is compatible …
Modified
p. 74 → 77
The controls shall be implemented and enforced by the device. As an exception, a vendor of an unattended device may decide to include into the to be approved-device scope not only the PIN entry device, but also the device controller and the controls implemented to ensure a secure configuration, the device’s display management, properties of the device’s cabinet, or procedural controls for the device.
The controls shall be implemented and enforced by the device. As an exception, a vendor of an unattended device may decide to include into the to-be-approved device scope not only the PIN entry device but also the device controller and the controls implemented to ensure a secure configuration, the device’s display management, and properties of the device’s cabinet, or procedural controls for the device.
Modified
p. 75 → 78
TB16.4 The tester shall examine the vendor-supplied documentation to verify that the controls to ensure the authenticity and the proper use of the prompts provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
TB16.4 The tester shall examine the vendor-supplied documentation to verify that the controls to ensure the authenticity and the proper use of the prompts provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
Removed
p. 77
They cannot adversely affect the security features of the product that are relevant to the PCI POI approval. They cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted. The application is strongly authenticated to the POI secure controller by digital signature. The application can only work on the keys it alone manages and cannot affect or see any other keys. A mechanism must exist to display the application version upon request.
Modified
p. 77 → 80
The vendor must provide clear security guidance for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This guidance must be included in the security policy delineated in DTR B20 Applications, in this context, are functional entities that execute within the secure boundary of the POI and may or may not provide services external to the POI. Applications are typically …
The vendor must provide clear security guidance for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This guidance must be included in the security policy delineated in DTR B20.
Modified
p. 78 → 81
• Having access to the top-level master keys that protect the working keys
•i.e., the application cannot extract or modify the top-level master key.
•i.e., the application cannot extract or modify the top-level master key.
Modified
p. 78 → 81
• Having access to operator or security-officer functions, and therefore cannot change security configurations or change privileges.
Modified
p. 78 → 81
• Introducing new primitive cryptographic functions (although it can use these to implement new composite functionality).
Removed
p. 80
The tester shall compare this configuration with the supplied documentation, and note whether they agree or have differences. If differences are detected, it is necessary to address why these occur with regards to compliance to this requirement.
Modified
p. 80 → 83
The intended operation is considered as the functionality relevant to B2, to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals.
The intended operation is considered as the functionality relevant to B2, to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access.
Modified
p. 80 → 83
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to plaintext cryptographic keys and components, customer PINs, passwords used for entry into sensitive states, or other items of information or configuration which is required to meet the core logical and physical requirements.
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to plaintext cryptographic keys and components, customer PINs, passwords/authentication codes used for entry into sensitive states, or other items of information or configuration which is required to meet the core logical and physical requirements.
Modified
p. 80 → 83
TB18.4 The tester shall verify that API functionality and commands that are not required to support specific functionality are removed whenever possible or disabled if removal is not feasible.
Modified
p. 80 → 83
TB18.5 The tester shall examine the methods and tools provided by the vendor, which ensure that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the OS.
Modified
p. 80 → 83
TB18.7 The tester shall note whether the POI implements a commercial operating system, custom operating system, function executive, or other mechanism. If the POI uses a commercial operating system, the tester shall note the name and version of this system.
Modified
p. 80 → 84
TB18.9 The tester shall obtain the configuration information for the operating system used in the POI.
Removed
p. 83
TB20.4 The tester shall confirm that the security policy includes procedures for the decommissioning of devices that are removed from service, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device. The procedures may differentiate between temporary and permanent removal.
TB20.5 For privacy shielding the tester shall perform the following tests:
b) If the POI has been approved for use with a privacy shield, the tester shall confirm that the security policy provides a picture of the approved privacy shield as properly installed and tested by the lab.
c) If the POI has been approved without a privacy shield, the tester shall confirm that any guidance on the use of the POI device as required by Appendix A.2 is provided in the security policy document.
TB20.6 The tester shall confirm that the security policy contains specific details on the cryptographic algorithms (TDES, SHA-2, etc.) …
TB20.5 For privacy shielding the tester shall perform the following tests:
b) If the POI has been approved for use with a privacy shield, the tester shall confirm that the security policy provides a picture of the approved privacy shield as properly installed and tested by the lab.
c) If the POI has been approved without a privacy shield, the tester shall confirm that any guidance on the use of the POI device as required by Appendix A.2 is provided in the security policy document.
TB20.6 The tester shall confirm that the security policy contains specific details on the cryptographic algorithms (TDES, SHA-2, etc.) …
Modified
p. 83 → 86
TB20.3 Confirm that the security policy clearly outlines the method of use for which the device has been approved
•e.g., handheld and/or desktop or unattended
•and that the security policy clearly notes that use of the device in an unapproved method will violate the PCI PTS approval of the device.
•e.g., handheld and/or desktop or unattended
•and that the security policy clearly notes that use of the device in an unapproved method will violate the PCI PTS approval of the device.
Modified
p. 83 → 87
TB20.7 The tester shall review the device security policy and note whether this clearly states the environments in which the POI is intended for use (attended, unattended or both).
Modified
p. 83 → 87
TB20.9 The tester shall confirm that the security policy includes all configuration settings necessary to meet the security requirements defined in this document.
Removed
p. 84
TB20.9 The tester shall confirm that the security policy contains specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with B16, or any mechanisms used for authenticating application code as assessed under Requirements B4.
TB20.10 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords and certificates.
TB20.12 The tester shall confirm that the security policy contains references to any software- development guidance required for compliance, if applicable, with the Module 3 (Open Protocol) and Module 4 (SRED) requirements. This documentation must clearly outline which functions, APIs, or modes of operation of cryptographic functions (such as cipher suites) have been evaluated by the PTS laboratory for securing cardholder data.
TB20.19 The tester shall examine the security policy to verify that the device is properly identified.
Product name, hardware version, and software version information should …
TB20.10 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords and certificates.
TB20.12 The tester shall confirm that the security policy contains references to any software- development guidance required for compliance, if applicable, with the Module 3 (Open Protocol) and Module 4 (SRED) requirements. This documentation must clearly outline which functions, APIs, or modes of operation of cryptographic functions (such as cipher suites) have been evaluated by the PTS laboratory for securing cardholder data.
TB20.19 The tester shall examine the security policy to verify that the device is properly identified.
Product name, hardware version, and software version information should …
Modified
p. 84 → 87
TB20.10 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords/authentication codes and certificates.
Modified
p. 84 → 87
TB20.12 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods TB20.13 The tester shall confirm that the security policy defines guidance for the proper implementation of any Open Protocols that are part of the approval.
Modified
p. 84 → 88
TB20.21 The tester shall confirm that the security policy contains information on how the device will indicate a tamper-response event, and any requirements for the return of this device to the vendor for examination following such an event (as required for compliance to DTR A1).
Modified
p. 84 → 88
TB20.22 The tester shall examine the security policy and relevant vendor documentation to verify that any periodic maintenance procedures required for the secure operation of the device are included in the security policy.
Modified
p. 84 → 88
TB20.23 The tester shall examine the security policy to verify that it identifies all self-tests that the module performs, procedures that an operator may need to initiate any self-tests, and the conditions under which each self-test is executed (for example, power up, periodic, conditional, on operator demand).
Modified
p. 84 → 88
TB20.24 The tester shall examine the security policy to verify that it identifies all roles supported by the device and indicates the services and permissions available for each role.
Modified
p. 84 → 89
TB20.33 The tester shall examine the security policy to verify that it states that keys should be replaced with new keys whenever the compromise of the original key is known or suspected, and whenever the time deemed feasible to determine the key by exhaustive attack elapses, as defined in NIST SP 800-57-1. .
Removed
p. 85
TB20.22 The tester shall confirm that the security policy includes any communication methods and protocols, including wireless, used by the device. Use of any method not listed in the policy invalidates the device approval.
Modified
p. 85 → 88
TB20.25 The tester shall examine the security policy and relevant vendor documentation to verify that the device has update and patch procedures required for the secure operation of the device and that the procedures are included in the security policy. The policy will include both local and remote update and patch downloading procedures for software, firmware, and configuration parameters, including those necessary for meeting Section J of the Open Protocols Module.
Modified
p. 86 → 90
C1 is not applicable to devices that do not include commands for external key selection, or cannot hold multiple key hierarchies related to PIN encryption.
C1 is not applicable to devices that do not include commands for external key selection or cannot hold multiple key hierarchies related to PIN encryption.
Modified
p. 86 → 90
TC1.1 The tester shall examine the response to Section C1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS POI Security Requirements manual for consistency relating relating to multiple keys and unauthorized key replacement and key misuse. The tester shall summarize the responses.
TC1.1 The tester shall examine the response to Section C1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS POI Security Requirements for consistency relating to multiple keys and unauthorized key replacement and key misuse. The tester shall summarize the responses.
Removed
p. 87
Note: All attacks shall include a minimum of ten hours attack time for exploitation.
In addition to the specified minimum attack potential values, any feasible penetration attack against the ICCR for the purpose of determining or modifying sensitive data must entail at least ten hours of exploitation time.
In addition to the specified minimum attack potential values, any feasible penetration attack against the ICCR for the purpose of determining or modifying sensitive data must entail at least ten hours of exploitation time.
Modified
p. 87 → 91
• The placement of the bug must not cause tamper evidence that would be noticed by a typical cardholder.
Modified
p. 88 → 92
TD1.7 The tester shall perform a simulated transaction whilst inserting two un-embossed cards into the slot. If it is possible to insert two cards and perform the transaction, then the device does not comply with this requirement.
TD1.7 The tester shall perform a simulated transaction whilst inserting two unembossed cards into the slot. If it is possible to insert two cards and perform the transaction, then the device does not comply with this requirement. The tester shall measure the IC slot width, height (or different heights), and depth and record these, referring to an image of the IC slot opening location.
Modified
p. 89 → 93
If an attack scenario can be developed that requires an attack potential of less than 20 per device for identification and initial exploitation or less than 10 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document. Calculations shall include evidence justifying particular rating levels as being appropriate.
If an attack scenario can be developed that requires an attack potential of less than 20 (26 for SCRPs) per device for identification and initial exploitation or less than 10 (13 for SCRPs) for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document. Calculations shall include evidence justifying particular rating levels as …
Modified
p. 92 → 96
• An enciphered PIN, the PIN block shall be enciphered between the device encrypting the PIN and the ICC reader either using an authenticated encipherment key of the IC card or in accordance with ISO 9564.
Modified
p. 92 → 96
• A plaintext PIN, the PIN block shall be enciphered from the device encrypting the PIN to the ICC reader (the ICC reader will then decipher the PIN for transmission in plaintext to the IC card) in accordance with ISO 9564.
Modified
p. 92 → 96
• An enciphered PIN, the PIN block shall be enciphered using an authenticated encipherment key of the IC card.
Modified
p. 92 → 96
• A plaintext PIN, encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the plaintext PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.
Modified
p. 92 → 96
A plaintext PIN from the PIN entry device to the ICC reader is never permitted except when the PIN entry device and ICC reader are integrated into the same secure module.
• A plaintext PIN from the PIN entry device to the ICC reader is never permitted except when the PIN entry device and ICC reader are integrated into the same secure module.
Modified
p. 92 → 96
When the cardholder verification method is determined to be an enciphered PIN, the encipherment must occur within the PIN entry device itself or a secure component of the device. The PIN must be enciphered in accordance with ISO 9564 for secure transport between the PIN entry device and the secure component. The PIN must be encrypted immediately after PIN entry is complete and has been signified as such by the cardholder for example, via pressing the enter button.
• When the cardholder verification method is determined to be an enciphered PIN, the encipherment must occur within the PIN entry device itself or a secure component of the device. The PIN must be enciphered in accordance with ISO 9564 for secure transport between the PIN entry device and the secure component. The PIN must be encrypted immediately after PIN entry is complete and has been signified as such by the cardholder for example, via pressing the enter button.
Modified
p. 92 → 96
In order to receive an approval for offline PIN entry, a device must be capable of supporting both plaintext and enciphered PINs.
• In order to receive an approval for offline PIN entry, a device must be capable of supporting both plaintext and enciphered PINs.
Modified
p. 92 → 96
The authentication must occur in a secure component of the device, such as the PIN pad or ICCR. This includes the authentication of the ICC public key(s) as well as the associated issuer public key in the certificate chain, up to the applicable payment-brand key.
• The authentication must occur in a secure component of the device, such as the PIN pad or ICCR. This includes the authentication of the ICC public key(s) as well as the associated issuer public key in the certificate chain, up to the applicable payment-brand key.
Modified
p. 92 → 96
The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.
• The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.
Modified
p. 92 → 96
PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique key per transaction method in accordance with ISO 11568 shall be used.
• PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique key per transaction method in accordance with ISO 11568 shall be used.
Modified
p. 93 → 97
TD4.3 The tester shall confirm from the vendor documentation that the POI supports both plaintext and encrypted offline PIN. The tester shall detail the APIs that are used for these purposes, and justify how these ensure that the customer PIN is always encrypted by the firmware of the POI and is never passed to the application in plaintext.
TD4.3 The tester shall confirm from the vendor documentation that the POI supports both plaintext and encrypted offline PIN. The tester shall detail the APIs that are used for these purposes and justify how these ensure that the customer PIN is always encrypted by the firmware of the POI and is never passed to the application in plaintext.
Modified
p. 93 → 97
TD4.4 If the ICC acceptor is a separate part, the tester shall detail how the customer PIN is encrypted for transmission between the two parts. This encryption must use ISO 9564-compliant PIN blocks and encryption mechanisms (an authenticated encipherment key of the ICC or TDES). The tester shall review the source code that performs the PIN block formatting and encryption and confirm it is compliant to ISO 9564. This evaluation activity should be focused at relevant security-critical sections of the …
TD4.4 If the ICC acceptor is a separate part, the tester shall detail how the customer PIN is encrypted for transmission between the two parts. This encryption must use ISO 9564-compliant PIN blocks and encryption mechanisms (an authenticated encipherment key of the ICC or TDES). The tester shall review the source code that performs the PIN-block formatting and encryption and confirm it is compliant to ISO 9564. This evaluation activity should be focused at relevant security-critical sections of the source …
Modified
p. 93 → 97
TD4.6 If the ICC acceptor is a separate part, the tester shall perform at least two transactions using the same customer PIN and card details, and note whether the PIN transferred between the two parts is the same.
TD4.6 If the ICC acceptor is a separate part, the tester shall perform at least two transactions using the same customer PIN and card details and note whether the encrypted PIN block transferred between the two parts is the same.
Modified
p. 93 → 97
TD4.8 The tester shall perform at least two test transactions with a card that requires an encrypted PIN. The tester shall capture the data sent to the customer card in each case, and note whether the two encrypted PIN blocks have the same value.
TD4.8 The tester shall perform at least two test transactions with a card that requires an encrypted PIN. The tester shall capture the data sent to the customer card in each case and note whether the two encrypted PIN blocks have the same value.
Modified
p. 93 → 97
TD4.10 The tester shall detail how the POI authenticates the customer ICC PIN-encryption public key. If this authentication is performed by the application, the tester shall confirm that the application authentication mechanisms have been tested as part of Requirement B4.
TD4.10 The tester shall detail how the POI authenticates the customer ICC PIN-encryption public key. If this authentication is performed by the application, the tester shall confirm that the application authentication mechanisms have been tested as part of Requirement B4.1.
Modified
p. 100 → 104
The ability to physically access the connection between devices (for example, EPP, UPT controller, and ICC reader) must not facilitate attacks to interfere with that correspondence and especially to collect clear PIN data (for example, commands are authenticated and/or enciphered). Keys used for such protocols must only be used for this purpose, and may then be stored and used in the UPT controller in the clear. It is not required to use a cryptographic module in the controller for that …
The ability to physically access the connection between devices (for example, EPP, UPT controller, and ICC reader) must not facilitate attacks to interfere with that correspondence and especially to collect clear PIN data (for example, commands are authenticated and/or enciphered). Keys used for such protocols must only be used for this purpose and may then be stored and used in the UPT controller in the clear. It is not required to use a cryptographic module in the controller for that …
Modified
p. 100 → 104
TE3.4.1 The tester shall examine the assertions provided by the vendor in response to Section E3.4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.4 of the PCI PTS POI Security Requirements manual for consistency relating to the control of the device’s operating modes and the corresponding display messages visible to the cardholder. The tester shall summarize the responses.
TE3.4.1 The tester shall examine the assertions provided by the vendor in response to Section E3.4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.4 of the PCI PTS POI Security Requirements for consistency relating to the control of the device’s operating modes and the corresponding display messages visible to the cardholder. The tester shall summarize the responses.
Modified
p. 100 → 104
TE3.4.3 The tester shall detail where prompts used for non-PIN entry are stored within the POI and describe the protections implemented to protect these prompts. The tester shall reference this information to the table of sensitive information provided in DTR A4.
TE3.4.3 The tester shall detail where prompts used for non-PIN entry are stored within the POI and describe the protections implemented to protect these prompts. The tester shall reference this information to the table of sensitive information provided in DTR A3.
Removed
p. 102
The device must is equipped with only one payment card PIN-accepting keyboard, and If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry, for example, it must not have numeric keys, or it must not be possible to use it otherwise for numeric entry or it is controlled in a manner consistent with A7, B16.1, B16.2 or E3.4.
Modified
p. 102 → 106
TE3.5.1 The tester shall examine the vendor’s response to Section E3.5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.5 of the PCI PTS POI Security Requirements to verify that any interface of the device that can be used to accept payment card numeric entry is controlled, and that the device is equipped with only one PIN-accepting keyboard or it is controlled in a manner consistent with A7, B16.1, B16.2 or E3.4. The tester shall …
TE3.5.1 The tester shall examine the vendor’s response to Section E3.5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.5 of the PCI PTS POI Security Requirements to verify that any interface of the device that can be used to accept payment card numeric entry is controlled, and that the device is equipped with only one PIN-accepting keyboard or it is controlled in a manner consistent with A6, B16, or E3.4. The tester shall summarize …
Modified
p. 102 → 106
TE3.5.4 If the device is equipped with more than one keyboard, and if the keyboard not intended for payment card PIN entry may be operated to accept numeric entry (for example, since it is equipped with numeric keys or since it is fully programmable, like a touch screen), the tester shall verify that these numeric modes may not be used to enter a payment card PIN, especially that a possible use of numeric entry modes does not interfere with Requirement …
TE3.5.4 If the device is equipped with more than one keyboard, and if the keyboard not intended for payment card PIN entry may be operated to accept numeric entry (for example, since it is equipped with numeric keys or since it is fully programmable, like a touch screen), the tester shall verify that these numeric modes may not be used to enter a payment card PIN, especially that a possible use of numeric entry modes does not interfere with Requirement …
Modified
p. 103 → 107
The objective of this section is to assess the device’s ability to protect the device against removal from the cabinet. This protections aims against PIN entry device overlays or chained ICC readers; it also aims at complicating attacks against the PIN entry device and ICC reader. As such, this requirement applies to devices and modules aimed at being mechanically integrated into a compound device, for example, kiosk or AFD.
The objective of this section is to assess the device’s ability to protect the device against removal from the cabinet. This protection aims against PIN entry device overlays or chained ICC readers; it also aims at complicating attacks against the PIN entry device and ICC reader. As such, this requirement applies to devices and modules aimed at being mechanically integrated into a compound device, for example, kiosk or AFD.
Modified
p. 103 → 107
• Use dual-control techniques; • Provide accountability and traceability; • Prevent replay of authorization data; and • Cause the device to not process PIN data until authorized to do so.
Modified
p. 103 → 107
• Review the report(s) covering the removal detection mechanisms of each sub-component.
Modified
p. 103 → 107
• Confirm how these removal mechanisms have been implemented in the final form-factor of the device.
Modified
p. 103 → 107
• Confirm that the method of installation does not invalidate the removal sensor technique used (for example, the sub-component is installed on a sub-chassis which itself can be removed).
Modified
p. 104 → 108
• Determine what methods of approved removal are implemented and confirm that they are the same as those evaluated in DTR A10. Verify that the approved removal creates an audit trail that can be accessed and detail the method that must be used to access the audit trail on the device.
Modified
p. 104 → 108
TE4.1.5 The tester shall determine whether the device uses passive and/or active protection(s), and assess the method for installation and for permanent or temporary removal. The tester shall assess the method for installation and full/temporary removal. An option for temporary removal without secret and private-key erasure requires an authorized method.
TE4.1.5 The tester shall determine whether the device uses passive and/or active protection(s) and assess the method for installation and for permanent or temporary removal. The tester shall assess the method for installation and full/temporary removal. An option for temporary removal without secret and private-key erasure requires an authorized method.
Modified
p. 104 → 108
TE4.1.8 The tester shall detail what occurs if the removal detection mechanism(s) are activated, and justify how this prevents the use of the POI for PIN entry.
TE4.1.8 The tester shall detail what occurs if the removal detection mechanism(s) are activated and justify how this prevents the use of the POI for PIN entry.
Modified
p. 104 → 108
a) The process provides dual control through use of two or more character passwords/PINs that are at least seven characters or an equivalent strength entered through the secure keypad of the POI, or
a) The process provides dual control through use of two or more passwords/authentication codes that are a minimum of seven characters or an equivalent strength and entered through the secure keypad of the POI; or
Removed
p. 105
TE4.2.1 The tester shall examine The tester shall examine the vendor’s response to Section E4.2 of the
Modified
p. 105 → 109
PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.2 of the PCI PTS POI Security Requirements for consistency relevant to E4.2. The tester shall summarize the responses.
TE4.2.1 The tester shall examine the vendor’s response to Section E4.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.2 of the PCI PTS POI Security Requirements for consistency relevant to E4.2. The tester shall summarize the responses.
Modified
p. 105 → 109
TE4.2.4 The tester shall verify that the integration documentation is properly maintained, for example, in case of a device update. More specifically, the tester shall examine and document the vendor document-release cycle, and assess how it integrates with the device design/manufacturing update process.
TE4.2.4 The tester shall verify that the integration documentation is properly maintained, for example, in case of a device update. More specifically, the tester shall examine and document the vendor document-release cycle and assess how it integrates with the device design/manufacturing update process.
Modified
p. 107 → 111
The objective of this section is to identify all physical interfaces and the corresponding logical protocols that are supported by the device. It is required that a device vendor knows of all interfaces and protocols supported by the device, and provide details of these protocols and interfaces within documentation.
The objective of this section is to identify all physical interfaces and the corresponding logical protocols that are supported by the device. It is required that a device vendor know of all interfaces and protocols supported by the device and provide details of these protocols and interfaces within documentation.
Modified
p. 107 → 111
• Cellular (GPRS and CDMA) Protocols, such as: but not limited to:
Modified
p. 107 → 111
• TLS1.2 or above* The vendor must also identify where they derive their code that is used to implement protocols, as well as document all protocols and which physical interfaces they apply to.
Modified
p. 107 → 111
Note: If the device implements an IP stack, the device must support TLS 1.2 or higher.
Note: If the device implements an IP stack, the device must support TLS 1.2 or higher. When the TLS protocol is supported, this needs to be evaluated under Section I, “Operational Testing” and corresponding PCI Technical FAQs.
Modified
p. 107 → 112
TF1.2 The tester shall examine any relevant documentation distributed by the vendor such as schematics and assembly drawings, submitted by the vendor to ensure that the vendor has exhaustively defined all protocols and interfaces supported by the device.
TF1.2 The tester shall examine any relevant documentation distributed by the vendor such as schematics, data sheets, and assembly drawings, submitted by the vendor to ensure that the vendor has exhaustively defined all protocols and interfaces supported by the device. The vendor must also identify where they derive their code that is used to implement protocols, as well as document all protocols and which physical interfaces they apply to. When public libraries are used to implement protocols, their versions must …
Modified
p. 108 → 112
TF1.6 The tester shall perform any additional tests necessary to validate the device’s documented list of protocols, services, and physical interfaces. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified
p. 109 → 113
The mechanism the vendor uses to assess each protocol and interface should be effective for that protocol or interface. For example, it is not acceptable to use automated network scanning tools to assess a client type protocol for vulnerabilities.
The mechanism the vendor uses to assess each protocol and interface should be effective for that protocol or interface. For example, it is not acceptable to use automated network scanning tools to assess a client protocol for vulnerabilities.
Modified
p. 109 → 113
TG1.2 The tester shall examine any relevant documentation distributed by the vendor to ensure that the vendor has provided for effective detection of vulnerabilities in each of the protocols and interfaces defined in F1. The tester shall summarize the responses.
TG1.2 The tester shall examine any relevant documentation distributed by the vendor to ensure that the vendor has provided for effective detection of vulnerabilities in each of the protocols and interfaces defined in F1. The tester shall list the methods and tools used by the vendor for vulnerability assessment including but not limited to test scripts, practical tests, review of information in public domain, and security analysis to locate vulnerabilities.
Modified
p. 110 → 114
TG2.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TG2.2 The tester shall examine additional relevant documentation, such as scan reports, test reports or vulnerability analysis documentation submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 110 → 114
TG2.3 The test shall examine the vendors sign-off form specified in Requirement G1 to ensure that it has been completed and signed off by management.
TG2.3 The test shall examine the vendor’s sign-off form specified in Requirement G1 to ensure that it has been completed and signed off by management.
Modified
p. 110 → 114
TG2.5 The tester shall execute a vulnerability assessment by research, analysis, and testing, to identify vulnerabilities associated with the protocols.
TG2.5 The tester shall execute an independent vulnerability assessment by research, analysis, and testing, to identify vulnerabilities associated with the protocols.
Removed
p. 111
The vendor’s processes must ensure that vulnerability information is disclosed to relevant parties within two weeks of discovery.
Modified
p. 112 → 116
TH1.1 The tester shall inspect the vendor security guidance to verify the assertions provided by the vendor in response to Section H1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s security guidance for the protocols and interfaces. The vendor must clearly provide security guidance for each interface and protocol defined in Section F1. The tester shall summarize the responses.
TH1.1 The tester shall inspect the vendor security guidance to verify the assertions provided by the vendor in response to Section H1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s security guidance for the protocols and interfaces addressed to the application developers. The vendor must clearly provide security guidance for each interface and protocol defined in Section F1. The tester shall summarize the responses.
Modified
p. 112 → 116
TH1.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor claims.
TH1.2 The tester shall examine any relevant documentation, such as a user guide, application developer’s guide, design specifications, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor claims.
Modified
p. 112 → 116
TH1.3 The tester shall examine and assess the distribution process of the security guidance. It must ensure that all necessary users are aware of it, and have access to the latest version.
TH1.3 The tester shall examine and assess the distribution process of the security guidance. It must ensure that all necessary users are aware of it and have access to the latest version. The vendor must specify what is the accessibility scope of each document•i.e., indicate which documents are intended as public and which documents have a restricted audience.
Modified
p. 113 → 117
TH2.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify that it supports the vendor claims that each interface is default in a secure or disabled state.
TH2.2 The tester shall examine any relevant documentation, such as a user guide, the application developer’s guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify that it supports the vendor claims that each interface is default in a secure or disabled state. When the protocol or interface allows configurable non-secure settings, user guidance to strongly recommend against configuring to non-secure settings must be provided.
Removed
p. 114
TH3.4 The tester shall perform any additional tests necessary to validate the device’s documentation. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified
p. 114 → 118
d) Key-management security guidance ensures secure use of keys and certificates.
d) Key-management security guidance ensures secure use of keys and certificates, including certificate status (e.g., revoked), secure download, and roll over of keys.
Modified
p. 114 → 118
TH3.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify that it supports the vendor’s key- management security claims covering the use of keys and certificates.
TH3.2 The tester shall examine any relevant documentation, such as a user guide, application developer guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify that it supports the vendor’s key-management security claims covering the use of keys and certificates.
Modified
p. 114 → 118
• Cover all the keys and certificates used by the security protocols; • Cover all key properties, minimally type and length (e.g., TDES 112-bits);
• Cover all users of keys and certificates. If different users are involved, responsibilities must be clearly indicated; • Be complete, clear and unambiguous; and • Ensure that keys are not shared between security protocols.
• Cover all users of keys and certificates. If different users are involved, responsibilities must be clearly indicated; • Be complete, clear and unambiguous; and • Ensure that keys are not shared between security protocols.
Modified
p. 115 → 119
TI.11 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s use of secure protocols. The vendor must ensure that the declared security protocol(s) covers each protocol listed in Section F1. The tester shall summarize the responses.
Modified
p. 115 → 119
TI1.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines the declared security protocol for each interface.
Modified
p. 115 → 119
TI1.3 The tester shall assess the physical and logical interfaces of the device to ensure the declared security protocol is present for each interface.
Modified
p. 115 → 119
TI1.4 The tester shall execute tests to verify that each interface can use a declared security protocol in a secure way. The tester may perform any additional tests necessary to validate the device’s documentation. The tester should use his or her own judgment in determining appropriate tests. The vendor shall provide any necessary test support to access and use the interfaces under test. The tester shall summarize the testing and responses for each interface tested.
Modified
p. 116 → 120
TI2.3 The tester shall execute tests necessary to validate the device’s implementation of a security protocol is providing for confidentiality of data in line with the documented method. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support to access and use the each interfaces under test. The tester shall summarize the testing and responses for …
TI2.3 The tester shall execute tests necessary to validate the device’s implementation of a security protocol is providing for confidentiality of data in line with the documented method. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support •including testing keys and/or certificates and tools to load them on the device
•to access and use the interfaces …
•to access and use the interfaces …
Modified
p. 117 → 121
c) Examples of appropriate algorithms and minimum key sizes are stated in Appendix D of the
c) Examples of appropriate algorithms and minimum key sizes are stated in Appendix E of the
Modified
p. 118 → 122
a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question as denoted in Appendix D.
a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question as denoted in Appendix E.
Modified
p. 118 → 122
TI4.3 The tester shall execute tests to verify device behavior when receiving incorrect certificates, including:
TI4.3 In the case when certificates are used for server authentication, the tester shall execute tests to verify device behavior when receiving incorrect certificates, including:
Modified
p. 118 → 122
c) Chaining error in certificate TI4.4 The tester shall verify the device’s behavior when connecting to an un-authenticated server. The tester shall verify that the connection is rejected. If the default behavior is to accept the connection documentation must exist to strongly suggest mutual authentication is enabled.
c) Chaining error in certificate TI4.4 The tester shall verify the device’s behavior when connecting to an un-authenticated server. The tester shall verify that the connection is rejected. If the default behavior is to accept the connection without device authentication, documentation must exist to strongly suggest mutual authentication is enabled. One example could be achieving mutual authentication in a higher- level protocol, such as an application level one.
Modified
p. 119 → 123
TI5.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that the declared security protocol for each interface provides exception handling and replay detection TI5.3 The tester shall test to verify device behavior when receiving incorrect data packets, replay messages, or other anomalies.
TI5.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that the declared security protocol for each interface provides exception handling and replay detection TI5.3 Unless it can be shown that by design the used security protocol provides message replay countermeasures (by the usage of counters or nonces, for example) and that there …
Modified
p. 120 → 124
TI6.4 The tester shall verify device behavior when receiving incorrect data or other anomalies.
TI6.4 The tester shall verify device behavior while attempting to break session management rules• e.g., request to exceed number of simultaneous connections.
Modified
p. 121 → 125
TJ1.1 The tester shall examine the vendor’s response to Section J1 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J1 of the PCI PTS POI Security Requirementsmanual to verify that the vendor has clearly documented security guidance for configuration management. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J1 of the PCI PTS POI Security Requirements
TJ1.1 The tester shall examine the vendor’s response to Section J1 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J1 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security guidance for configuration management. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J1 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security guidance for configuration management. The tester shall summarize the responses.
Modified
p. 122 → 126
TJ2.1 The tester shall examine the vendor’s response to Section J2 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J2 of the PCI PTS POI Security Requirementsmanual to verify that the vendor has clearly documented security maintenance measures. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J2 of the PCI PTS POI Security Requirements
TJ2.1 The tester shall examine the vendor’s response to Section J2 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J2 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security maintenance measures. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J2 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security maintenance measures. The tester shall summarize the responses.
Modified
p. 122 → 126
• Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
Removed
p. 123
Be complete, clear, and unambiguous, Via the remote update mechanism, ensure security, i.e.,, integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol; Cover all elements of device maintenance including terminal updates to the device configuration, firmware and software, as well statistics pulled from the device; and Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
Modified
p. 123 → 127
The vendor maintains security guidance describing how the update mechanism must be used.
Modified
p. 123 → 127
TJ3.1 The tester shall examine the vendor’s response to Section J3 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J3 of the PCI PTS POI Security Requirementsmanual to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J3 of the PCI PTS POI Security Requirements
TJ3.1 The tester shall examine the vendor’s response to Section J3 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J3 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J3 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.
Modified
p. 123 → 127
• Include both local and remote scenarios.
Removed
p. 124
Be complete, clear, and unambiguous; Via the update mechanism, ensure security, i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol; Cover all elements of device maintenance including terminal updates to configuration files, firmware and software, as well statistics pulled from the device; and Cover all types of users that may need maintenance guidance. If different types of users are involved, responsibilities must be clearly indicated.
Modified
p. 124 → 128
• Include both local and remote scenarios.
Modified
p. 124 → 128
TJ4.1 The tester shall examine the vendor’s response to Section J4 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J4 of the PCI PTS POI Security Requirementsmanual to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J4 of the PCI PTS POI Security Requirements
TJ4.1 The tester shall examine the vendor’s response to Section J4 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module
• Protocol Declaration Form, and the response to Requirement J4 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.
• Protocol Declaration Form, and the response to Requirement J4 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.
Modified
p. 126 → 130
Note that MSRs and ICCRs must meet the attack potentials stipulated in DTRs A9 and D1 respectively.
Note that MSRs and ICCRs must meet the attack potentials stipulated in DTRs A8 and D1 respectively.
Modified
p. 126 → 130
TK1.1.1 The tester shall examine the vendor’s response to Section K1.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.1 of the PCI PTS POI Security Requirements for consistency relevant to K1.1.
DTRs A1.8, A1.11, and A1.13 must be completed for the ICCR where any specific references to “PIN” are to be read as “account data.” TK1.1.1 The tester shall examine the vendor’s response to Section K1.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.1 of the PCI PTS POI Security Requirements for consistency relevant to K1.1.
Modified
p. 126 → 130
TK1.1.2 The tester shall verify that all testing procedures specified for Requirement D1 for chip data and A9 for magnetic-stripe data in the core physical requirements have been satisfied in relation to the protection of account data.
TK1.1.2 The tester shall verify that all testing procedures specified for Requirement D1 for chip data and A8 for magnetic-stripe data in the core physical requirements have been satisfied in relation to the protection of account data. The tester shall confirm whether the device supports contactless data entry. The tester shall confirm whether the device supports manual PAN entry.
Modified
p. 126 → 130
TK1.1.6 The tester shall develop attack scenarios to penetrate the device to make any additions, substitutions, or modifications to either the device hardware or software, in order to determine or modify any account data, with an attack potential of at least 16 per device for identification and initial exploitation, with a minimum of 8 for exploitation. (Note that MSRs and ICCRS must meet the attack potentials stipulated in DTRs A9 and D1 respectively). The tester shall detail where costing information …
Removed
p. 127
In general, techniques may include any combination of tamper-detection methods. Security mechanisms must not rely on insecure services or characteristics provided by the device such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods involving tamper evidence are not considered a security mechanism.
This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.
This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.
Removed
p. 127
TK1.2.1 The tester shall examine the response to Section K1.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.2 of the PCI PTS POI Security Requirements manual for consistency relevant to DTR K1.2. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise device security. The tester shall summarize the responses.
TK1.2.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TK1.2.3 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.
TK1.2.4 The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test unit when necessary TK1.2.5 The tester shall present sufficient …
TK1.2.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TK1.2.3 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.
TK1.2.4 The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test unit when necessary TK1.2.5 The tester shall present sufficient …
Modified
p. 129 → 133
Account-data protection keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered.
Account-data protection keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix E, they do not need to be considered.
Modified
p. 129 → 133
TK3.1 The tester shall examine the vendor’s response to Section K3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K3 of the PCI PTS POI Security Requirements for consistency relevant to K3. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any account data protection related cryptographic key resident in the device. The tester shall summarize the responses.
Modified
p. 129 → 133
TK3.4 The tester shall provide details on how cryptographic keys are stored, managed, and protected within the POI. Where applicable, the tester shall reference this information to the table provided in DTR A4. The tester shall detail the testing performed to confirm the storage locations listed are correct.
TK3.4 The tester shall provide details on how cryptographic keys are stored, managed, and protected within the POI. Where applicable, the tester shall reference this information to the table provided in DTR A3. The tester shall detail the testing performed to confirm the storage locations listed are correct.
Modified
p. 129 → 133
TK3.6 The tester shall detail all of the different cryptographic operations implemented within the POI. The tester shall verify whether they are implemented in software or hardware, and what side- channel analysis protections are implemented to protect each of these operations. The tester shall describe methods used for each side-channel protection (for example, time variance, masking, dual rail logic, etc.). Note that any operations that only function using public keys do not require side-channel protections to be implemented.
TK3.6 The tester shall check the evidence provided by the vendor on the implemented cryptographic operations and detail all of the different cryptographic operations implemented within the POI. The tester shall verify whether they are implemented in software or hardware, and what side- channel analysis protections are implemented to protect each of these operations. The tester shall describe methods used for each side-channel protection (for example, time variance, masking, dual rail logic, etc.). Note that any operations that only function …
Modified
p. 130 → 134
TK3.9 Where the results indicate that key recovery is not possible, the tester shall justify the methodologies used and findings. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device, consistent with an attack cost rating of 26 for identification and initial exploitation with a minimum of 13 for exploitation Justifications of these to be reported shall include (but are restricted to): the number of …
TK3.9 The tester shall justify the methodologies used and findings in accordance with Appendix F. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device, consistent with an attack cost rating of 26 for identification and initial exploitation with a minimum of 13 for exploitation Justifications of these to be reported shall include (but are restricted to): the number of sample recordings acquired, sampling frequencies, …
Modified
p. 130 → 134
Where no definite sensitive data leakage is achieved, validate why this is the case and provide explanations The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no greater than two years older than the date of the current evaluation’s submission unless the existing evidence can be shown to be still valid according to the current state of the art. If leveraging separate evidence, …
Where no definite sensitive data leakage is achieved, validate why this is the case and provide explanations The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no greater than three years older than the date of the current evaluation’s submission unless the existing evidence can be shown to be still valid according to the current state of the art. If leveraging separate evidence, …
Modified
p. 130 → 134
TK3.10 The tester shall describe what protections the cryptographic processing elements implement to protect against glitch attacks to force cryptographic errors. Where applicable, the tester shall refer to testing and results from DTR A4. The tester shall review the source code of the POI to confirm that any protection measures relied upon are correctly enabled. The tester shall describe why any secure boot-up operations are implemented appropriately to obstruct glitch attacks, referring to any available literature and vulnerability disclosures to …
TK3.10 The tester shall describe what protections the cryptographic processing elements implement to protect against glitch attacks to force cryptographic errors. Where applicable, the tester shall refer to testing and results from DTR A3. The tester shall review the source code of the POI to confirm that any protection measures relied upon are correctly enabled. The tester shall describe why any secure boot-up operations are implemented appropriately to obstruct glitch attacks, referring to any available literature and vulnerability disclosures to …
Modified
p. 130 → 135
TK3.12 Referring to the information provided in DTR A4, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the POI cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.
TK3.12 Referring to the information provided in DTR A3, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the POI cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.
Modified
p. 132 → 136
Public keys not stored in certificates or in a secure cryptographic device must be stored encrypted, or have a MAC (Message Authentication Code) created using the algorithm defined in ISO 16609, in order to ensure authenticity and integrity.
Public keys not stored in certificates or in a secure cryptographic device must be stored encrypted or have a MAC (Message Authentication Code) created using the algorithm defined in ISO 16609, in order to ensure authenticity and integrity.
Modified
p. 133 → 137
TK4.3 In the event of a non-standard mode of operation being used, the tester shall examine documented credentials of the expert reviewer and assess his/her ability to perform the review. The tester shall also examine documentation supporting the assertion of independence of review and confirm that the reviewer is indeed independent. The tester shall use his or her judgment in determining the appropriate due diligence, and explain this.
TK4.3 In the event of a non-standard mode of operation being used, the tester shall examine documented credentials of the expert reviewer and assess his/her ability to perform the review. The tester shall also examine documentation supporting the assertion of independence of review and confirm that the reviewer is indeed independent. The tester shall use his or her judgment in determining the appropriate due diligence and explain this.
Modified
p. 138 → 142
TK8.1 The tester shall examine the response to Section K8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K8 of the PCI PTS POI Security Requirements for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses..
TK8.1 The tester shall examine the response to Section K8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K8 of the PCI PTS POI Security Requirements for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses.
Modified
p. 139 → 143
TK8.4 The tester shall verify by testing that the device enforces that data keys, key-encipherment keys, and PIN-encryption keys have different values•for example, by attempting to load keys of different types with effectively the same value. The tester shall attempt to load two keys of the same value into the POI, and detail the results. If unsuccessful, the tester shall attempt to load two keys that vary only in the parity bits but produce the same key value. The tester …
TK8.4 The tester shall verify by testing that the device enforces that data keys, key-encipherment keys, and PIN-encryption keys have different values•for example, by attempting to load keys of different types with effectively the same value. The tester shall attempt to load two keys of the same value into the POI and detail the results. If unsuccessful, the tester shall attempt to load two keys that vary only in the parity bits but produce the same key value. The tester …
Removed
p. 141
TK10.4 The tester shall verify and demonstrate that the device displays or otherwise makes available the revision number.
Modified
p. 141 → 145
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, except for SCRs intended for use with COTS devices and SCRPs, where all code is considered firmware.
Modified
p. 141 → 145
• Mitigating them by techniques like techniques that include but are not limited to Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Harvard Architecture and Stack Canaries.
Modified
p. 141 → 145
TK10.1 The tester shall examine the response to Section K10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K10 of the PCI PTS POI Security Requirements manual for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
TK10.1 The tester shall examine the response to Section K10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K10 of the PCI PTS POI Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
Modified
p. 141 → 145
TK10.4 The tester shall detail any compiler settings used by the vendor in order to maximize the mitigation of known vulnerabilities. If no specific compiler settings are used, the tester shall detail how known vulnerabilities are mitigated.
Modified
p. 141 → 145
TK10.5 The tester shall detail any mitigation techniques used by the vendor to help prevent common exploits. The tester must state and justify any reliance placed on these technique(s) in minimizing testing. If no specific techniques are used, the tester shall detail how the common exploits are prevented.
Modified
p. 142 → 146
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers, and testers and does not rely on non-specific statements. For example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
TK10.7 The tester shall confirm that
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers, and testers and does not rely on non-specific statements. For example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers, and testers and does not rely on non-specific statements. For example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
Modified
p. 142 → 146
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR
TK10.8 The tester shall confirm that
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
Modified
p. 142 → 146
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.
TK10.9 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.
Modified
p. 142 → 146
TK10.10 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the POI code.
Modified
p. 142 → 146
TK10.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed after every change, and before the firmware is released to production.
Modified
p. 142 → 146
TK10.12 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable process that shows the code review and security testing have been performed, and requires sign-off by the person(s) performing the code review and security testing. The tester shall confirm that the process will show any problems that were noted during the code review and security testing.
Modified
p. 142 → 146
TK10.13 The tester shall obtain, review, and summarize the firmware-verification audit results provided by the vendor for the version of firmware submitted for evaluation. The tester shall confirm that this shows that no problems were found during review of this firmware (or that any problems found have been addressed).
Modified
p. 142 → 146
TK10.14 The tester shall review previous firmware-verification audit reports provided by the vendor and summarize these reports and their findings. The tester shall ensure that the reports sampled include security problems found during the review, and confirm that these problems have been addressed. If all audit reports are found to indicate that no security problems have been found, the tester shall justify why it is possible that the firmware image is, and has always been, completely free of security defects.
Modified
p. 142 → 146
TK10.15 The tester shall identify and review publically available sources of vulnerability disclosure, including but not necessarily limited to those referenced in the vendor-certification process document and shall check that any vulnerabilities found cannot be exploited on the POI. The tester shall compare his/her analysis with the analysis provided by the vendor and confirm that the vendor has remediated any problems with these vulnerabilities, and that firmware-audit report documents exist and have been updated to validate this assertion.
Modified
p. 143 → 147
TK10.17 The tester shall outline the following information. If the firmware is based on a general-purpose operating system (like Linux or Windows CE), the steps described in TK10.15, in particular, hold for this operating system. The documentation provided by the developer shall show that state-of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues (like patch levels; not including unused packages, etc.; not being able …
Removed
p. 144
TK11.1.4 The tester shall verify that the device rejects unauthorized applications. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update with inadequate or modified authentication information.
Modified
p. 144 → 148
Applications are considered to be any code that can be loaded onto the device that is not firmware. This includes any non-firmware code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
Applications are considered to be any code that can be loaded onto the device that is not firmware. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
Modified
p. 144 → 148
TK11.1.3 The tester shall verify that the device cryptographically authenticates application integrity. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update.
TK11.1.3 The tester shall verify that the device rejects unauthorized applications. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update with inadequate or modified authentication information.
Modified
p. 144 → 148
TK11.1.4 The tester shall determine by which component the authentication is performed.
Modified
p. 144 → 148
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component
TK11.1.5 The tester shall determine the rank of protection strength for the component involved in application loads
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component TK11.1.6 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component TK11.1.6 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
Modified
p. 144 → 148
TK11.1.7 For each of the processing elements listed in DTR A3, the tester shall complete the following table. Where different parts of the code (for example, boot code, main firmware, etc.) can be updated independently, or if one part of the application cannot be updated, the tester shall ensure that this is detailed in the table as well.
Modified
p. 145 → 149
c) Change a single bit in the firmware block of the image, and confirm that this modified image is rejected when loaded into the POI.
c) Change a single bit in the application block of the image, and confirm that this modified image is rejected when loaded into the POI.
Modified
p. 145 → 149
TK11.1.8 The tester shall review the source code of the POI to confirm that the application- authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure application of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 145 → 149
TK11.1.9 If the POI allows for loading of multiple types of code (for example, application for security processor, application for magnetic-stripe-reader encryption chip, application code, etc.), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.
Modified
p. 145 → 149
TK11.1.10 If (H)MAC method(s) are used for application authentication, the tester shall confirm through source-code review that the method used to compare the application-authentication block does not leak timing information•for example, the “C” memcmp() function is not used. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 145 → 149
TK11.1.11 If a CBC MAC is used for application authentication, the tester shall detail what methods are used to mitigate vulnerabilities in this method when used to authenticate variable-length data.
Modified
p. 145 → 149
TK11.1.12 For each of the methods of authentication the tester shall obtain a correctly authenticated application image and if applicable, a software and/or configuration update, and:
Modified
p. 145 → 149
TK11.1.13 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.
Modified
p. 147 → 150
• That it is not possible for applications to be influenced by logical anomalies that could result in clear-text data being outputted whilst the terminal is in encrypting mode.
Modified
p. 147 → 150
• That account data is not retained any longer, or used more often, than strictly necessary.
Removed
p. 148
TK12.3 The tester shall verify that the device cryptographically authenticates the software integrity. This will be accomplished, for example, by performing a simulated firmware update.
TK12.4 The tester shall verify that the device rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
TK12.5 The tester shall determine by which component the authentication is performed.
TK12.4 The tester shall verify that the device rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
TK12.5 The tester shall determine by which component the authentication is performed.
Modified
p. 148 → 151
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.The authentication must not be performed by a component of lesser protection strength than the …
Modified
p. 148 → 151
The firmware and application version numbers must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. This shall be illustrated by photographic evidence provided in the evaluation report.
The firmware and application version numbers, and optionally the hardware version number must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. This shall be illustrated by photographic evidence provided in the evaluation report. For SCRPs and SCRs intended for use with commercial-off-the-shelf devicese.g., mobile phones and tabletsthe SCRPs and SCRs must respond with their model name/number, hardware version, firmware version(s), and a unique device …
Modified
p. 148 → 151
TK12.1 The tester shall examine the response to Section K12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K12 of the PCI PTS POI Security Requirements manual for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
TK12.1 The tester shall examine the response to Section K12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K12 of the PCI PTS POI Security Requirements for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
Modified
p. 148 → 152
TK12.5 The tester shall determine the level of protection for the external component involved in firmware/software updates and that the authentication of software updates is performed by a component of equal or greater strength.
Modified
p. 148 → 152
TK12.6 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
Modified
p. 149 → 152
Processing/ Elements Used to Perform Authentication Algorithms and Key Sizes Used for Firmware Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the firmware differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of how initial code is loaded into the POI.
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. (See Annex A of the Vendor Questionnaire.) Processing/ Elements Used to Perform Authentication Algorithms and Key Sizes Used for Firmware Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the firmware differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of …
Modified
p. 149 → 152
TK12.8 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 149 → 152
TK12.9 If the POI allows for loading of multiple types of code (for example, firmware for security processor, firmware for magnetic-strip-reader encryption chip, application code, etc.), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.
Modified
p. 149 → 153
TK12.11 If a CBC MAC is used for firmware authentication, the tester shall detail what methods are used to mitigate vulnerabilities in this method when used to authenticate variable-length data.
Modified
p. 150 → 153
TK12.13 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.
Removed
p. 151
The Open Protocol Module shall be used to assess any communication method that uses a wireless, local, or wide-area network to transport data. This would include, but is not limited to: Bluetooth, Wi- Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless or through a hub, switch, or other multiport device. In addition, any communication that uses a public domain protocol or security protocol would be assessed with the Open Protocol Module.
Modified
p. 151 → 154
TK13.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant component’s logical structure, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
TK13.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
Modified
p. 151 → 154
TK13.3 The tester shall analyze the vendor’s measures that ensure that the relevant component’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
TK13.3 The tester shall describe the vendor’s measures that ensure that the relevant component’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified
p. 151 → 154
TK13.4 The tester shall note the languages in which the POI source code is written for each of the security processing elements (as detailed in DTR A4).
TK13.4 The tester shall note the programming languages in which the POI’s firmware source code is written for each of the security processing elements (as detailed in DTR A3).
Modified
p. 151 → 154
TK13.5 The tester shall detail the type and configuration of the operating system(s) used on each of the POI security-processing elements (as detailed in DTR A4).
TK13.5 The tester shall detail the type, version, capabilities, and configuration of the operating system(s) used on each of the POI security-processing elements (as detailed in DTR A3).
Modified
p. 151 → 155
TK13.8 If the device includes command-execution interfaces or parsers: The tester shall detail how each of the above interfaces is configured to accept commands•for example, whether a command executive is used, or other methods are used to parse input commands. The tester shall define which common functionalities exist between interfaces to determine which test approaches may be applied in common to more than one interface.
Removed
p. 152
The evaluation may rely upon appropriate vendor documentation available from existing fuzz testing to replace/supplement some of the laboratory testing workload described here. Such evidence must be no greater than two years older than the date of the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR B2 security requirements. To achieve this justification, the tester must provide thorough explanations of test methodologies and findings, sufficient to demonstrate these are at least as robust as the criteria described here.
TK13.10 For systems that are designed to execute non-firmware applications, the tester shall use the development environment for the POI to create a program with a buffer-overflow vulnerability. The tester shall determine that the device behaves in accordance with the specifications TK13.11 The tester shall execute a vulnerability assessment, by research, analysis and testing, to identify vulnerabilities associated with the …
TK13.10 For systems that are designed to execute non-firmware applications, the tester shall use the development environment for the POI to create a program with a buffer-overflow vulnerability. The tester shall determine that the device behaves in accordance with the specifications TK13.11 The tester shall execute a vulnerability assessment, by research, analysis and testing, to identify vulnerabilities associated with the …
Modified
p. 152 → 155
TK13.10 The tester shall perform a source-code review of each relevant interface and confirm they are handled securely, that only documented commands are implemented and that secure defaults are provided for each interface. The tester shall detail what methods are used to verify the length and content of each command before processing. The tester shall derive and describe vulnerability-analysis models from source-code review and other available evidence to determine attack paths and appropriate penetration testing.
Modified
p. 152 → 156
TK13.15 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified
p. 154 → 158
PAN data that is encrypted, hashed (with salt), masked or truncated PANs may be outputted from the device. Truncated PANs are typically defined as a maximum of the first six and the last four digits. However, due to differing PAN lengths, the determination must be made if the truncated digits offer sufficient protection against attacks designed to predict valid, full PANs (with longer BIN ranges). This would partially depend on the potential universe of PANs that could be included and …
PAN data that is encrypted, hashed (with salt), masked or truncated PANs may be outputted from the device. Truncated PANs are typically defined as a maximum of the first six and the last four digits. However, due to differing PAN lengths, the determination must be made if the truncated digits offer sufficient protection against attacks designed to predict valid, full PANs (with longer BIN ranges). This would partially depend on the potential universe of PANs that could be included and …
Modified
p. 154 → 158
TK15.1 The tester shall examine the response to Section K15 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K15 of the PCI PTS POI Security Requirements manual for consistency relating to the output of clear-text PANs.
TK15.1 The tester shall examine the response to Section K15 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K15 of the PCI PTS POI Security Requirements for consistency relating to the output of clear-text PANs.
Removed
p. 155
The authorization implements the principles of dual control, Sensitive information required for the authorization (for example, passwords or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device, An authorized switch must provide traceability and accountability.
Modified
p. 155 → 159
• Data inputs cannot be discerned from any displayed characters.
Modified
p. 155 → 159
• Data inputs cannot be discerned by monitoring audible or electro-magnetic emissions.
Modified
p. 155 → 159
• Sensitive data is cleared from internal buffers upon exiting the sensitive mode.
Modified
p. 155 → 159
• Entering data while changing modes.
Modified
p. 155 → 159
• If changes to the mode of operation can occur remotely, the tester shall verify that a cryptographic authorization mechanism consistent to that used for remote access authentication (per K9) is implemented.
Modified
p. 156 → 160
• That clear-text account data is only output to authenticated applications;
Modified
p. 157 → 161
• Review of a small sample of compiled object code to validate that the code to clear the buffer remains in the compiled code;
Modified
p. 157 → 161
• The terminal has timed out waiting for the response from the cardholder or merchant.
Modified
p. 157 → 161
• That account data shall not be present any longer or used more often than strictly necessary; • That the device automatically clears its internal buffers when either the transaction is completed or the device has timed out waiting for the response from the cardholder, merchant, or authorization service. The vendor must specify the states “completion of transaction” and “timeout” and define the appropriate actions.
Modified
p. 157 → 161
TK15.2.3 The tester shall verify that
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive account data is included.Passwords, plaintext cryptographic keys, or key components outside of the crypto- processor, and account data are included.
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive account data is included.
TK15.2.3 The tester shall verify that
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive account data is included. Passwords/authentication codes, plaintext cryptographic keys, or key components outside of the crypto-processor, and account data are included.
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive account data is included. Passwords/authentication codes, plaintext cryptographic keys, or key components outside of the crypto-processor, and account data are included.
Modified
p. 160 → 164
• Salts that are unique per transaction or otherwise unique per device must be generated by the transaction device.
Modified
p. 160 → 164
• Salts that are unique per merchant are generated outside the transaction device and require loading to each merchant device. The vendor must supply documentation to the merchant/acquirer processor on how to securely load the salt values and that this loading is treated as a sensitive service in accordance with K22.
Removed
p. 162
Be secret; Be generated randomly or pseudo-randomly; Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source; Be used in the appropriate order as specified by the particular mode; Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and Cannot be unbundled for any purpose.
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.
Loaded using asymmetric keys of equivalent or greater strength. …
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.
Loaded using asymmetric keys of equivalent or greater strength. …
Modified
p. 163 → 168
a) When entering plaintext secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally …
a) When entering plaintext secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/authentication codes that are unique per device …
Modified
p. 163 → 168
Entry of key components without the use of at least two separate passwords/PINs results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Modified
p. 163 → 169
Injection of plaintext secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Injection of plaintext secret keys or their components/shares where the device does not itself require the use of at least two passwords/authentication codes for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Modified
p. 164 → 169
If a public-key technique for the distribution of symmetric secret keys is used, it must:
If a public-key technique for the remote distribution of symmetric secret keys is used, it must:
Modified
p. 164 → 169
TK17.6 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange, or establishment are stated in Appendix D.
TK17.6 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange, or establishment are stated in Appendix E.
Modified
p. 164 → 169
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA, see also DTR B16.2).
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA.
Modified
p. 164 → 169
TK17.9 The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 DUKPT, fixed key, or Master/Session key management.
TK17.9 The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 DUKPT, Fixed key, or Master/Session key management.
Modified
p. 166 → 171
TK17.15 Using the key table as a reference, the tester shall confirm that all keys are unique per device, and what method is used to ensure that this is the case.
TK17.15 Using the key table as a reference, the tester shall confirm that all secret and private keys are unique per device, and what method is used to ensure that this is the case.
Modified
p. 166 → 171
TK17.17 Using the table of sensitive-information storage from Requirement A 5 (if applicable) and the key table above, the tester shall confirm:
TK17.17 Using the table of sensitive-information storage from Requirement A5 (if applicable) and the key table above, the tester shall confirm:
Modified
p. 166 → 172
b) If key check values (KCVs) are used for this purpose, the KCV values stored are limited to six hexadecimal characters or less or they are never output from the POI.
b) If key check values (KCVs) are used for this purpose, the KCV values stored are limited to values as defined in TK17.21 or they are never output from the POI.
Modified
p. 166 → 172
TK17.21 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value of more than six hexadecimal values from the POI.
TK17.21 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value except as noted below
Modified
p. 167 → 172
• Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.
Modified
p. 167 → 172
TK17.24 The tester shall confirm that any key-bundling key can only be used for that purpose, and cannot be used as a “generic” master or working key, as part of a non-bundled key- management scheme.
TK17.24 The tester shall confirm that any key-bundling key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-bundled key- management scheme.
Removed
p. 168
Use of a unique key per transaction technique. (Prevents the attack.) Limiting the rate at which the device will encrypt PANs. (Deters the attack.) For example, the function would be a maximum of the throughput that could be achieved through the physical interface during intended usage.
Modified
p. 168 → 174
TK18.1 The tester shall examine the response to Section K18 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K18 of the PCI PTS POI Security Requirements manual for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PAN determination.
TK18.1 The tester shall examine the response to Section K18 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K18 of the PCI PTS POI Security Requirements for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PAN determination.
Modified
p. 169 → 175
TK19.1 The tester shall examine the response to Section K19 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K19 of the PCI PTS POI Security Requirements manual for consistency relevant to Requirement K19. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.
TK19.1 The tester shall examine the response to Section K19 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K19 of the PCI PTS POI Security Requirements for consistency relevant to Requirement K19. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.
Modified
p. 169 → 175
TK19.5 The tester shall use the table below to detail the environmental-protection features implemented by the POI. For voltage, the tester shall outline which voltage is being monitored (for example, external, main processor core voltage, battery voltage, etc.). If more than one voltage monitoring is provided, the tester shall detail all of these. For each environmental factor monitored, the tester shall detail what circuitry is performing this monitoring and what occurs when during an out-of-range detection.
TK19.5 The tester shall use the table below to detail the environmental-protection features implemented by the POI. For voltage, the tester shall outline which voltage is being monitored (for example, external, main processor core voltage, battery voltage, etc.). If more than one voltage monitoring is provided, the tester shall detail all of these. For each environmental factor monitored, the tester shall detail what circuitry is performing this monitoring and what occurs when during an out-of-range detection (see Annex A of …
Modified
p. 170 → 176
TK19.7 Using a POI that has been configured (using special test code from the vendor which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.
TK19.7 Using a POI that has been configured by the vendor (using special test code from the vendor which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table, or the vendor should provide sufficient test reports covering all required …
Modified
p. 170 → 176
The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.
The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, demonstrating compliance to this DTR.
Removed
p. 171
OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined with B1.
Modified
p. 171 → 177
Applications are considered to be separated by access rights. Applications may share data by design.
Applications are considered to be separated by access rights. Applications may share data by design. OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined with K10.
Modified
p. 171 → 177
They cannot adversely affect the security features of the product that are relevant to the PCI POI approval.
• They cannot adversely affect the security features of the product that are relevant to the PCI POI approval.
Modified
p. 171 → 177
They cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.
• They cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.
Modified
p. 171 → 177
The application is strongly authenticated to the POI secure controller by digital signature.
• The application is authenticated to the POI secure controller by digital signature.
Modified
p. 171 → 177
The application can only work on the keys it alone manages and cannot affect or see any other keys.
• The application can only work on the keys it alone manages and cannot affect or see any other keys.
Modified
p. 171 → 177
A mechanism must exist to display the application version upon request.
• A mechanism must exist to display the application version upon request.
Modified
p. 171 → 177
The vendor must provide clear security guidance for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This guidance must be included in the security policy delineated in DTR B20 Applications, in this context, are functional entities that execute within the secure boundary of the POI and may or may not provide services external to the POI. Applications are typically …
The vendor must provide clear security guidance for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This guidance must be included in the security policy delineated in DTR B20 Vendors should provide configuration lists and description of the separation mechanism to support answers.
Modified
p. 172 → 178
• Having access to the top-level master keys that protect the working keys
•i.e., the application cannot extract or modify the top-level master key.
•i.e., the application cannot extract or modify the top-level master key.
Modified
p. 172 → 178
• Having access to operator or security-officer functions, and therefore cannot change security configurations or change privileges.
Modified
p. 172 → 178
• Introducing new primitive cryptographic functions (although it can use these to implement new composite functionality).
Removed
p. 174
The operating system of the device must contain only the software (components and services) necessary for the intended operation. The operating system must be configured securely and run with least privilege. The security policy enforced by the device must not allow unauthorized or unnecessary functions. API functionality and commands that are not required to support specific functionality must be disabled (and where possible, removed).
Modified
p. 174 → 180
The intended operation is considered as the functionality relevant to B2. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals.
The intended operation is considered as the functionality relevant to B2. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals. Therefore, operating-system code is necessarily part of the firmware as defined within K10.
Modified
p. 175 → 181
TK21.9 The tester shall obtain the configuration information for the operating system used in the POI.
Modified
p. 175 → 181
TK21.10 The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the POI execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce the functionality of the POI to only those components and services necessary for the intended operation of the device.
Modified
p. 176 → 182
TK22.3 The tester shall verify from vendor documentation
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys andpasswords/PINs. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys and
TK22.3 The tester shall verify from vendor documentation
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys and passwords/authentication codes. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
•and summarize
•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys and passwords/authentication codes. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified
p. 177 → 183
TK22.12 The tester shall validate that
•and describe how
•allpasswords implemented to provide dual control are at least seven characters or an equivalent strength.
•and describe how
•all
TK22.12 The tester shall validate that
•and describe how
•all passwords/authentication codes implemented to provide dual control are at least seven characters or an equivalent strength.
•and describe how
•all passwords/authentication codes implemented to provide dual control are at least seven characters or an equivalent strength.
Modified
p. 177 → 183
TK22.13 The tester shall attempt to load cryptographic keys or components into the POI without changing the default values of the passwords. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TK22.13 The tester shall attempt to load cryptographic keys or components into the POI without changing the default values of the passwords/authentication codes. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 177 → 183
TK22.14 The tester shall attempt to set the passwords in the POI so that two or more of the passwords in the same device have the same value. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TK22.14 The tester shall attempt to set the passwords/authentication codes in the POI so that two or more of the passwords/authentication codes in the same device have the same value. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 177 → 183
TK22.15 The tester shall attempt to set the passwords of the POI to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TK22.15 The tester shall attempt to set the passwords/authentication codes of the POI to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 178 → 184
• The vendor has provided a rationale for the value chosen as a limit on the number of actions and the time limits imposed.
Modified
p. 178 → 184
• The vendor has provided a rationale as to how the limits minimize the risks from unauthorized use of sensitive services.
Modified
p. 178 → 184
TK23.6 For any password-entry modes, the tester shall detail how the functional limits ensure that any arbitrary password guess has less than a 1/1000000 chance of success, and any multiple attempts within a one-minute period have a less than 1/10000 chance of success of correctly providing the password value. The tester shall detail the testing performed to validate these functional limits.
TK23.6 For any password-entry modes, the tester shall detail how the functional limits ensure that any arbitrary password/authentication code guess has less than a 1/1000000 chance of success, and any multiple attempts within a one-minute period have a less than 1/10000 chance of success of correctly providing the password/authentication code value. The tester shall detail the testing performed to validate these functional limits.
Modified
p. 178 → 184
TK23.7 For any password-entry modes, the tester shall confirm through source code examination that the method of validating the password value is not vulnerable to a timing attack (for example, a standard “strcmp” or “memcmp” function is not used), or that the functional limits are set to values that prevent utilization of any leaked timing information. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources …
TK23.7 For any password-entry modes, the tester shall confirm through source code examination that the method of validating the password/authentication code value is not vulnerable to a timing attack (for example, a standard “strcmp” or “memcmp” function is not used), or that the functional limits are set to values that prevent utilization of any leaked timing information. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation …
Modified
p. 179 → 185
For sensitive services requiring the input of two or more passwords, the maximum timer must be started upon entry of the first password digit and include the time taken to both enter the password and perform the service that password authenticates (for example, entry of a single key component, or access to a sensitive menu function). If the POI separates the entry of each component such that a single password is entered prior to each component value, it is not …
For sensitive services requiring the input of two or more passwords/authentication codes, the maximum timer must be started upon entry of the first password/authentication code digit and include the time taken to both enter the password/authentication code and perform the service that password/authentication code authenticates (for example, entry of a single key component, or access to a sensitive menu function). If the POI separates the entry of each component such that a single password/authentication code is entered prior to each …
Modified
p. 179 → 185
TK23.9 For all sensitive services requiring the input of passwords and key components into the POI keypad, the tester shall confirm that an inactivity time-out is implemented such that if a button is not pressed every 60 seconds, the device will exit the sensitive state.
TK23.9 For all sensitive services requiring the input of passwords/authentication codes and key components into the POI keypad, the tester shall confirm that an inactivity time-out is implemented such that if a button is not pressed every 60 seconds, the device will exit the sensitive state.
Modified
p. 180 → 187
TL1.3 The tester shall review any vendor documentation describing all changes to the software to ensure that changes that rectify errors or faults did not remove, modify, or add additional functionality unless they are submitted immediately upon completion for evaluation.
TL1.3 The tester shall review any vendor documentation describing all changes to the software to ensure that changes that rectify errors or faults did not remove, modify, or add additional functionality that impacts security unless they are submitted immediately upon completion for evaluation. This is to validate the process of deferring submissions for evaluation unless all changes are submitted for evaluation immediately upon completion.
Modified
p. 180 → 188
TL1.5 The tester shall interview those responsible for the change control processes (including engineers and programming staff, supervisory staff, technical management, etc.) to verify that the documented and approved procedures are known and understood by all affected parties.
TL1.5 The tester shall interview those responsible for the change control processes •including engineers and programming staff, supervisory staff, technical management, etc.
Removed
p. 181
All changes to PCI approved devices have been submitted for re-evaluation; or Only changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality are deferred from submission and not submitted immediately, but are instead submitted on an aggregate basis.
Modified
p. 182 → 189
All certified firmware must be signed prior to distribution and signed using dual control. It should be managed such that no single person is able to sign files. If two secrets (passwords or PINs) are required for operation of the signing tool, no single person should know both secrets. All certified firmware must be reviewed against the organization’s coding standards prior to signature.
All certified firmware must be signed prior to distribution and signed using dual control. It should be managed such that no single person is able to sign files. If two secrets (passwords/authentication codes) are required for operation of the signing tool, no single person should know both secrets. All certified firmware must be reviewed against the organization’s coding standards prior to signature.
Modified
p. 182 → 189
TL2.4 The tester shall interview those responsible for the firmware control processes (including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.) to verify that the documented and approved procedures are known and understood by all affected parties.
TL2.4 The tester shall interview those responsible for the firmware control processes •including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.
Modified
p. 183 → 190
TL3.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement.. The documentation should detail the components used and the component control processes and procedures for storage and verification during the manufacturing process including components identification verification, with the procedures checked in TL1.2. .
TL3.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should detail the components used and the component control processes and procedures for storage and verification during the manufacturing process including components identification verification, with the procedures checked in TL1.2. .
Modified
p. 183 → 190
TL3.3 The tester shall interview those responsible for component control processes (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the documented and approved procedures are known and understood by all affected parties.
TL3.3 The tester shall interview those responsible for component control processes •including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 184 → 191
TL4.4 The tester shall interview those responsible for the software (e.g., firmware) control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.
TL4.4 The tester shall interview those responsible for the software (e.g., firmware) control processes
Modified
p. 185 → 192
TL5.4 The tester shall interview those responsible for the post-production control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
TL5.4 The tester shall interview those responsible for the post-production control processes
Modified
p. 185 → 192
TL5.7 The tester shall examine the vendor’s tamper-evident packing or accessed-controlled area to ensure unauthorized access to devices or their components is not possible.
TL5.7 The tester shall examine the vendor’s tamper-evident packing or access-controlled area to ensure unauthorized access to devices or their components is not possible.
Removed
p. 186
TL6.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the key- loading facility or the facility of initial deployment by means of secret information placed in the device during manufacturing, the secret is installed in the device under dual control to ensure that it is not disclosed during installation Where required to validate via site inspection, the tester shall complete the following additional steps:
Modified
p. 186 → 193
TL6.4 The tester shall interview those responsible for the control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
TL6.4 The tester shall interview those responsible for the control processes •including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 187 → 194
TL7.3 The tester shall interview those responsible for component control processes (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved documented procedures are known and understood by all affected parties.
TL7.3 The tester shall interview those responsible for component control processes •including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 188 → 195
TL8.4 The tester shall interview those responsible for repair, inspection, and post-inspection control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
TL8.4 The tester shall interview those responsible for repair, inspection, and post-inspection control processes •including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 189 → 196
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key- loading facility or to the facility of initial deployment and stored en route under auditable controls that can account for the location of every POI at every point in time.
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key- loading facility or to the facility of initial deployment and stored en route under auditable controls that can account for the location of every POI at every point in time•such as the use of serialized tamper-evident packing for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.
Modified
p. 189 → 196
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Modified
p. 189 → 196
The product shall be protected for at all points during the shipping process. Tamper-evident packaging, instructions for receiving and inspection, and documentation should tamper be suspected, must be provided and used.
The product shall be protected for at all points during the shipping process. Tamper-detection security features, instructions for receiving and inspection, and documentation should tamper be suspected, must be provided and used.
Modified
p. 189 → 196
TM1.1 The tester shall examine the vendor’s response to Section M1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M1 of the PCI PTS POI Security Requirements for shipping tamper protection documentation. The tester shall summarize the responses.
TM1.1 The tester shall examine the vendor’s response to Section M1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M1 of the PCI PTS POI Security Requirements regarding the protection of devices during shipping. The tester shall summarize the responses.
Modified
p. 189 → 196
TM1.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence for customers that provides instruction on validation the authenticity and integrity of the POI. Alternatively, the approved documentation must detail how the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored en …
TM1.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence for customers that provides instruction on validation of the authenticity and integrity of the POI. Alternatively, the approved documentation must detail how the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored …
Modified
p. 189 → 197
TM1.4 The tester shall interview those responsible for the shipping control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the approved documented procedures are known and understood by all affected parties.
TM1.4 The tester shall interview those responsible for the shipping control processes •including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 191 → 198
TM2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment …
TM2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment. …
Modified
p. 191 → 198
TM2.3 The tester shall interview those responsible for the shipping control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the approved documented procedures are known and understood by all affected parties.
TM2.3 The tester shall interview those responsible for the shipping control processes •including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 192 → 199
• Shipped and stored in tamper-evident packaging; and/or • Shipped and stored containing a secret that:
• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
• Can be verified by the initial key-loading facility but cannot feasibly be determined by unauthorized personnel.
• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
• Can be verified by the initial key-loading facility but cannot feasibly be determined by unauthorized personnel.
Modified
p. 192 → 199
TM3.3 The tester shall interview those responsible for the shipping control processes (including engineers, software developers, line staff, supervisory staff, technical management, etc.) to verify that the approved documented procedures are known and understood by all affected parties.
TM3.3 The tester shall interview those responsible for the shipping control processes •including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 193 → 200
TM4.1 The tester shall examine the vendor’s response to Section M4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M4 of the PCI PTS POI Security Requirements for consistency relevant to assure the authenticity of the TOE’s security relevant components at the initial key-loading facility. The tester shall summarize the responses.
TM4.1 The tester shall examine the vendor’s response to Section M4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M4 of the PCI PTS POI Security Requirements for consistency relevant to assure the authenticity of the TOE’s security-relevant components at the initial key-loading facility. The tester shall summarize the responses.
Modified
p. 193 → 200
TM4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the device’s development-security documentation to ensure the authenticity of the devices security relevant components and describe how this shows compliance to this requirement.
TM4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the device’s development-security documentation to ensure the authenticity of the devices security-relevant components and describe how this shows compliance to this requirement.
Modified
p. 193 → 200
TM4.3 The tester shall interview those responsible for the initial key-loading facility (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved documented procedures are known and understood by all affected parties.
TM4.3 The tester shall interview those responsible for the initial key-loading facility •including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 194 → 201
TM5.3 The tester shall interview those responsible for the initial key-loading facility (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
TM5.3 The tester shall interview those responsible for the initial key-loading facility •including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 195 → 202
TM6.3 The tester shall interview those responsible for the initial key-loading facility (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
TM6.3 The tester shall interview those responsible for the initial key-loading facility •including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 197 → 204
• Data on production and personalization • Hardware version identification • Repair and maintenance • Removal from operation • Loss or theft The operational management manual provides instructions and information concerning the identification, use, repair, updates, and configuration of hardware and firmware components of the device. This manual is in addition to user and application operation and configuration manuals.
Modified
p. 197 → 204
TM8.3 The tester shall interview those responsible for maintaining the operation management manual (including engineers and software developers, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
TM8.3 The tester shall interview those responsible for maintaining the operation management manual •including engineers and software developers, supervisory staff, technical management, etc.
Modified
p. 200 → 207
5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a touch screen, the viewing barrier may be implemented by polarizers (for example, as film on the touch screen surface), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.
5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a touch screen, the viewing barrier may be implemented by polarizers (for example, as film embedded within layers of a touch screen), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.
Modified
p. 204 → 211
• Positioning of terminal on the check-stand in such way as to make visual observation of the PIN- entry process infeasible. Examples include:
Modified
p. 204 → 211
• Installing device on an adjustable stand that allows consumers to swivel the terminal sideways and/or tilt it forwards/backwards to a position that makes visual observation of the PIN-entry process difficult.
Modified
p. 204 → 211
• Positioning of in-store security cameras such that the PIN-entry keypad is not visible.
Modified
p. 204 → 211
• Instructing the cardholder regarding safe PIN-entry. This can be done with a combination of
Modified
p. 206 → 213
In this document, “exploitation” and “initial exploitation” are alternatively used to designate “initial exploitation.” Factors to be Considered The following factors should be considered for the analysis of the attack potentials required to exploit vulnerability:
In this document, “exploitation” and “initial exploitation” are alternatively used to designate “initial exploitation.” Factors to be Considered The following factors should be considered for the analysis of the attack potentials required to exploit a vulnerability:
Modified
p. 206 → 213
b) Potential to acquire the required knowledge of the PIN entry device’s design and operation;
b) Potential to acquire the required knowledge of the POI device’s design and operation;
Modified
p. 206 → 213
b) Potential to acquire the required knowledge of the PIN entry device’s design and operation;
b) Potential to acquire the required knowledge of the POI device’s design and operation;
Modified
p. 206 → 213
c) Potential for the access to the PIN entry device;
c) Potential for the access to the POI device;
Modified
p. 206 → 213
c) Potential for the access to the PIN entry device;
c) Potential for the access to the POI device;
Modified
p. 206 → 213
e) PIN entry device specific spare components.
e) POI device specific spare components.
Modified
p. 206 → 213
e) PIN entry device specific spare components.
e) POI device specific spare components.
Modified
p. 206 → 213
d) Equipment required like instruments, components, IT hardware, software required for the
d) Equipment required such as instruments, components, IT hardware, software required for the
Modified
p. 206 → 213
In many cases these factors don’t depend on each other but might be substituted for each other in varying degrees. For example, expertise or hardware/software can be a substitute for time. A discussion of these factors follows.
In many cases these factors don’t depend on each other but might be substituted for each other in varying degrees. For example, expertise or hardware/software can be a substitute for time. A discussion of these factors follows. In most situations, the first identification phase shall include a complete simulation of the second phase•i.e., the initial exploitation phase. Therefore, it is not acceptable to allocate calculation factors (such as time, experience, equipment) of the simulation to an exploitation phase when these …
Removed
p. 207
a) Experts are familiar with the underlying algorithms, protocols, hardware, structures, etc., implemented in the product or system type and the principles and concepts of security employed.
b) Proficient persons are knowledgeable in that they are familiar with the security behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully.
b) Proficient persons are knowledgeable in that they are familiar with the security behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully.
Modified
p. 207 → 214
Expertise refers to the level of generic knowledge of the application area or product type (for example, Unix operation systems, and Internet protocols). Identified levels are as follows:
Expertise refers to the level of generic capabilities including but not limited to knowledge, skills, experience, etc. of the application area or product type (for example, UNIX operation systems, and Internet protocols). Identified levels are as follows:
Modified
p. 207 → 214
a) Layman is a person without professional or specialized knowledge in a particular subject. They are unknowledgeable compared to experts, proficient, or skilled persons, with no particular expertise but capable of implementing simple attack steps, or capable of implementing more complex attack steps under direction. For the purpose of exploitation, they can implement an attack based on a script or a written procedure, without requiring any particular skill.
Modified
p. 207 → 214
If proficient expertise on various areas of technology is required for an attack, for example, on electrical engineering and cryptography, an expert level of expertise can be assumed.
If proficient expertise in various areas of technology is required for an attack
•for example, on electrical engineering and cryptography
•an expert level of expertise can be assumed. In most attack scenarios, the exploitation level of expertise is less than the required identification level of expertise.
•for example, on electrical engineering and cryptography
•an expert level of expertise can be assumed. In most attack scenarios, the exploitation level of expertise is less than the required identification level of expertise.
Modified
p. 207 → 214
Knowledge of the PIN entry device refers to obtaining specific expertise in relation to the PIN entry device. This is different from generic expertise but not unrelated to it. Identified levels are as follows:
Knowledge of the POI device refers to obtaining specific expertise in relation to the POI device. This is different from generic expertise but not unrelated to it. Identified levels are as follows:
Modified
p. 207 → 214
a) Public information about the PIN entry device (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.
a) Public information about the POI device (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.
Modified
p. 207 → 214
b) Restricted information concerning the PIN entry device (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (for example, like the PCI PTS POI DTRs).
b) Restricted information concerning the POI device (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (for example, like the PCI PTS POI DTRs).
Modified
p. 207 → 214
c) Sensitive information about the PIN entry device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
c) Sensitive information about the POI device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
Modified
p. 207 → 214
Distinction must be made between information required to identify the vulnerability and the information required to exploit it, especially in the area of sensitive information. Requiring sensitive information for exploitation would be unusual.
Modified
p. 207 → 215
Access to the PIN entry device is also an important factor. It is assumed here that the PIN entry device would be purchased or otherwise obtained by the attacker and that beside other factors there is not any time limit in analyzing or modifying the PIN entry device. Differences are defined in the status and functionality of the device to be analyzed/tested.
Access to the POI device is also an important factor. It is assumed here that the POI device would be purchased or otherwise obtained by the attacker and that beside other factors there is not any time limit in analyzing or modifying the POI device. Differences are defined in the status and functionality of the device to be analyzed/tested.
Modified
p. 207 → 215
b) Functional samples without working keys might be used for the logical and electrical behavior of the device but are not loaded with working keys and are therefore not functional within a payment
b) Functional samples without working keys might be used for the logical and electrical behavior of the device but are not loaded with working keys and are therefore not functional within a payment network or with real payment cards. Such devices might be regularly purchased. Please note that these also include devices fitted with test or dummy keys.
Removed
p. 208
Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort. This could include purchase of moderate amounts of equipment (for example, dedicated electronic cards, specialized test bench, protocol analyzers, oscilloscopes, microprobe workstation, chemical workbench, precise milling machines, etc.) or development of more extensive attack scripts or programs.
Bespoke equipment is not readily available to the public, as it might need to be specially produced (for example, very sophisticated software), or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered in the exploitation phase.
b) Scanning Electron Microscope
c) Abrasive Laser Equipment
Bespoke equipment is not readily available to the public, as it might need to be specially produced (for example, very sophisticated software), or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered in the exploitation phase.
b) Scanning Electron Microscope
c) Abrasive Laser Equipment
Modified
p. 208 → 215
Table 1: Multiple Samples Factors Number of Devices Factor Equipment refers to the equipment that is required to identify or exploit vulnerability.
Table B1: Multiple Samples Factors Number of Devices Factor Equipment refers to the equipment that is required to identify or exploit vulnerability. See Appendix C for details of equipment classification.
Modified
p. 208 → 215
a) Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•for example, from retail outlets or acquired/downloaded from the Internet.
Modified
p. 208 → 216
d) Chip-level equipment, necessary to implement chip-level attacks, is generally not widely available on the market and its access is restricted. It is also very expensive, and therefore is considered as a category on its own. Only the following equipment belong to this category:
Removed
p. 209
If the same equipment used for the identification phase can be reused for exploitation, it may not be accounted for twice. In such case, the cost of equipment can be divided by two and spread equally over identification and exploitation.
Modified
p. 209 → 216
a) Standard parts are readily available to the attacker, either by purchasing them from a supply store or by re-using parts from a mechanical sample of the same device.
Modified
p. 209 → 216
b) Specialized parts are not readily available to the attacker but could be acquired without undue effort. These might be parts that are not readily available from a supply store but can be ordered from stock and require delivery time or a certain minimum component count for purchase.
Modified
p. 209 → 216
c) Bespoke parts are not readily available and have to be specifically manufactured. It is very unlikely that an attack requires bespoke spare parts.
Removed
p. 210
Rating Success of an Attack If the difficulty of implementing an attack is sufficiently high, resulting in the attack being likely to succeed on a limited number of targets, multiple devices can be considered, given the following limitations.
To reflect this matter of fact, the number of target devices (i.e., functional samples with working keys in the exploitation phase) can be multiplied using the following factors:
Table 2: Success Rate Multiplying Factor Probability of success Factor 0.5 > P 0.25 1.5 P < 0.25 2 When determining the probability, each step of the attack must be divided into likely independent phases with a featured probability. The overall probability is obtained by multiplying all factors together.
Proper documentation is required when the overall probability falls under 0.5. Determining the probability is typically based upon experiments with the devices, and may involve proper sampling to obtain meaningful statistical figures.
To reflect this matter of fact, the number of target devices (i.e., functional samples with working keys in the exploitation phase) can be multiplied using the following factors:
Table 2: Success Rate Multiplying Factor Probability of success Factor 0.5 > P 0.25 1.5 P < 0.25 2 When determining the probability, each step of the attack must be divided into likely independent phases with a featured probability. The overall probability is obtained by multiplying all factors together.
Proper documentation is required when the overall probability falls under 0.5. Determining the probability is typically based upon experiments with the devices, and may involve proper sampling to obtain meaningful statistical figures.
Modified
p. 210 → 216
• Knowledge If several attack scenarios lead to the same potential in total and exploitation, then the one that has the lowest cost in exploitation, exclusive of the items above, must be considered. Attack calculations must allocate ratings that assume the most conservative trade-offs between time, expertise and equipment. Particularly, attack calculations shall not distribute ratings in a way that increases overall and/or exploitation minimum ratings above the most conservative approach.
Modified
p. 211 → 217
Table 3: Attack Potential Factors Identification Exploitation Attack time ≤1 hour 0 0 ≤ 8 hours 2 2 ≤ 24 hours 3 3 ≤ 40 hours 3.5 3.5 ≤ 80 hours 4 4 ≤ 160 hours 5 5 Beyond 160 hours 5.5 5.5 Expertise Layman 0 0 Proficient 1.5 1.5 Expert 4 4 Knowledge of the PIN entry device Public 0 0 Restricted 2 2 Sensitive 3 3 Access to the PIN entry device per device required for the attack. …
Table B2: Attack Potential Factors Identification Exploitation Attack time ≤ 1 hour 0 0 ≤ 2 hours 1 1 ≤ 4 hours 1.5 1.5 ≤ 6 hours 2 2 ≤ 8 hours 3 3 ≤ 12 hours 4 4 ≤ 16 hours 4.5 4.5 ≤ 24 hours 5 5 ≤ 40 hours 5.5 5.5 ≤ 60 hours 6 6 ≤ 100 hours 6.5 6.5 ≤ 160 hours 7 7 Beyond 160 hours 7.5 7.5 Expertise Layman 0 0 Skilled 1 …
Removed
p. 212
First Attack Example The attack aims to insert a PIN-disclosing bug into a PIN entry device. The bug is placed nearby the keyboard PCB, under the housing, and aims at monitoring the keypad signal and record PIN entries.
1. Reverse-engineer the device to understand its design, including the tamper-detecting sensors and keypad signal. Expert level in electronics is required to understand the routing of security signals, as well as to understand the keyboard scanning method. Locations of tamper mechanisms are determined and methods devised to bypass/deactivate them. It is therefore determined that 60 working hours, expert skills, standard equipment and one mechanical sample are required.
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public None 1 mechanical 60 hours
2. A bug is customized to monitor the keypad signals and record PIN entry. In this example, the scanning technique is simple, therefore the following levels apply: Expert, 30 hours’ work, standard parts, …
1. Reverse-engineer the device to understand its design, including the tamper-detecting sensors and keypad signal. Expert level in electronics is required to understand the routing of security signals, as well as to understand the keyboard scanning method. Locations of tamper mechanisms are determined and methods devised to bypass/deactivate them. It is therefore determined that 60 working hours, expert skills, standard equipment and one mechanical sample are required.
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public None 1 mechanical 60 hours
2. A bug is customized to monitor the keypad signals and record PIN entry. In this example, the scanning technique is simple, therefore the following levels apply: Expert, 30 hours’ work, standard parts, …
Modified
p. 212 → 218
Determining Applicable Time and Levels For each phase, the testing laboratory shall document all necessary steps, including expertise, equipment, and specific parts needed, time required to operate (in hours), and when relevant, a probability of success.
Determining Applicable Time and Levels For each phase, the testing laboratory shall document all necessary steps, including expertise, equipment, specific parts needed, and time required to operate (in hours).
Modified
p. 212 → 218
This information is best summarized in a table containing all the items described above, and helping in the determination of the applicable item for the table.
This information is best summarized in a table containing all the items described above.
Removed
p. 213
1. Attack the tamper-detection mechanisms to penetrate into the device. It is deemed that, assuming the housing can be replaced by a spare part, each detection mechanism can be disabled with a success rate of 0.9 and requires one hour per mechanism. In this example, there are eight tamper-detection mechanisms, but only four of them need to be defeated. One additional hour is required to stabilize the attack.
While the attack is scripted, it nevertheless requires good mechanical skills and practice to successfully implement. Therefore, the level of expertise is considered as “proficient.” Expertise Equipment Knowledge Parts Samples Time needed Proficient Standard (reused) Public None 1 working with keys P(success) = 0.94 ≈ 0.66
2. Once inside, the attack needs to reach sensitive signals (for example, key scanning signals) located within a deeper layer of the terminal, protected by other, harder to defeat, tamper-detection mechanisms.
Expertise Equipment Knowledge Parts Samples Time needed Expert …
While the attack is scripted, it nevertheless requires good mechanical skills and practice to successfully implement. Therefore, the level of expertise is considered as “proficient.” Expertise Equipment Knowledge Parts Samples Time needed Proficient Standard (reused) Public None 1 working with keys P(success) = 0.94 ≈ 0.66
2. Once inside, the attack needs to reach sensitive signals (for example, key scanning signals) located within a deeper layer of the terminal, protected by other, harder to defeat, tamper-detection mechanisms.
Expertise Equipment Knowledge Parts Samples Time needed Expert …
Removed
p. 214
Table 4: Attack Potential for Inserting a PIN-Disclosing Bug Aspect Identifying Value Exploiting Value Attack time ≤ 160h 5 ≤ 24 h 3 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to PIN entry device 1 mechanical sample 1 working sample without working keys 3 Functional sample with working keys P(success) ≈ 0.52 Equipment Standard 1 Specialized 3 Specific parts Standard 1 Standard 1 Attack potential per phase 16 15 Total Attack Potential 31 Second Attack Example The attack aims at determining a DES key used for encryption by a PIN entry device using side-channel analysis for example, differential power analysis (DPA). It is assumed that:
A function of the device requires a PIN to be entered for every execution of the cryptographic calculation exercising the key under attack. The data input for DPA can be acquired from an external interface of the …
A function of the device requires a PIN to be entered for every execution of the cryptographic calculation exercising the key under attack. The data input for DPA can be acquired from an external interface of the …
Modified
p. 214 → 230
2. Determine the method to run DPA on the device. This consists mostly of analyzing the electrical and logical interface. This step requires expert knowledge of electronic and computer engineering.
Removed
p. 215
Table 5: Attack Potentials Example for DPA Analysis Aspect Identifying Value Exploiting Value Attack time Beyond 160h 5.5 < 80h 4 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to PIN entry device Functional sample with trial 2 Functional sample with working keys Equipment Bespoke 5 Specialized 3 Specific parts Standard 1 No further parts Attack potential per phase 19.5 15 Total Attack Potential 34.5
Modified
p. 216 → 235
A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009], and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing a Test” …
A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing a Test” …
Modified
p. 217 → 236
[3] For the Block Frequency test, if n=106, the test block size should be set between 104 and 106. (See SP800-22r1a Section 2.2.7.) [4] The Non-Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. (See SP800-22r1a Sections 2.7.7 and 2.8.7.) For a template length of 10, the MAXNUMOFTEMPLATES constant (in defs.h) should be set to at least 284 prior to compiling STS, otherwise most 10 bit aperiodic templates with a leading …
[3] For the Block Frequency test, if n=106, the test block size should be set between 104 and 106. (See SP 800-22r1a Section 2.2.7.) [4] The Non-Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. (See SP 800-22r1a Sections 2.7.7 and 2.8.7.) For a template length of 10, the MAXNUMOFTEMPLATES constant (in defs.h) should be set to at least 284 prior to compiling STS, otherwise most 10-bit aperiodic templates with a …
Modified
p. 217 → 236
[5] The Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. When n=106, the template size of 9 comes closest to fulfilling the parameter selection criteria. (See SP800-22r1a Section 2.8.7.) [6] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP800-22r1a Section 2.9.7. For n=106, the only acceptable values are (L=6, Q=640) and (L=7, Q=1280). Note, any parameters passed into this test are …
[5] The Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. When n=106, the template size of 9 comes closest to fulfilling the parameter selection criteria. (See SP 800-22r1a Section 2.8.7.) [6] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP800-22r1a Section 2.9.7. For n=106, the only acceptable values are (L=6, Q=640) and (L=7, Q=1280). Note, any parameters passed into this test …
Modified
p. 217 → 236
[7] For the Approximate Entropy (ApEn) test, SP800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for large scale testing.
[7] For the Approximate Entropy (ApEn) test, SP 800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for large scale testing.
Modified
p. 217 → 236
(See SP800-22r1a Section 2.11.7.) [9] The Linear Complexity test block length is required to be set to between 500 and 5,000 (inclusive), and requires that . (See SP800-22r1a Section 2.10.7.) References [Rukhin 2010] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP 800-22, Revision 1a.
(See SP 800-22r1a Section 2.11.7.) [9] The Linear Complexity test block length is required to be set to between 500 and 5,000 (inclusive) and requires that . (See SP 800-22r1a Section 2.10.7.) References [Rukhin 2010] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP 800-22, Revision 1a.
Modified
p. 219 → 238
• DH implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity shall generate a private key x and a public key y using the domain parameters (p, q, g).
Modified
p. 219 → 238
• ECDH implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity shall generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS186-4 for methods of generating d and Q).
Modified
p. 219 → 238
• Each private key shall be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
Modified
p. 219 → 238
•Requirements for message authentication using symmetric techniques. One of the following: MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method 4, should be used.
• Entities must authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques. One of the following: MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method 4, should be used.
•Requirements for message authentication using symmetric techniques. One of the following: MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method 4, should be used.