Document Comparison
PCI_PTS_POI_DTRs_v6.2.pdf
→
PCI_PTS_POI_DTRs_v7.0.pdf
91% similar
237 → 249
Pages
91364 → 96283
Words
422
Content Changes
Content Changes
422 content changes. 273 administrative changes (dates, page numbers) hidden.
Added
p. 7
• For the purposes of PTS, the definition of “impractical” or “not practical” should be understood as not feasible within the scope of the PTS DTRs, for example according to attack potential values and/or other criteria stated in the DTRs and guidance.
Added
p. 10
Multiple test requirements require the test laboratories to review source code to facilitate validation to the applicable Security Requirements. Unless stated in the test requirement that the sample is not required, the code segments (snippets) are considered evidence of meeting the security requirement. Code samples serve as evidence in a manner similar to the inclusion of pictures of hardware components as evidence in meeting physical requirements.
Added
p. 11
For example, a device that provides a magnetic stripe reader (MSR) or contactless reader must be evaluated against the requirements for the physical security of MSR components (requirement A10). Similarly, a device that provides for the execution of third-party applications (which are not authenticated through processes validated in requirement B2.1 and B2.2) must be evaluated against the requirements that cover third-party applications.
However, some requirements may be optionally included in the evaluation of some approval classes. If included, these requirements must be verified•a report that is submitted to PCI SSC for approval cannot contain items that were included in the scope of the evaluation but were found to be Not Verified. Examples of requirements which may be optionally included in the scope of evaluation for some approval classes include:
• Biometric reader functionality
• Secure Reading and Exchange of Data (SRED) functionality For example, a device may provide functionality to encrypt non-PIN account …
However, some requirements may be optionally included in the evaluation of some approval classes. If included, these requirements must be verified•a report that is submitted to PCI SSC for approval cannot contain items that were included in the scope of the evaluation but were found to be Not Verified. Examples of requirements which may be optionally included in the scope of evaluation for some approval classes include:
• Biometric reader functionality
• Secure Reading and Exchange of Data (SRED) functionality For example, a device may provide functionality to encrypt non-PIN account …
Added
p. 22
Sensitive functions or data are defined by the device implementation and asset flow, and includes all account data, all cryptographic material used to protect that account data, and all firmware.
The protected areas of the device are defined as the areas that meet the attack rating of this requirement, and that are covered by the tamper detection and response features of the device.
The protected areas of the device are defined as the areas that meet the attack rating of this requirement, and that are covered by the tamper detection and response features of the device.
Added
p. 23
a) Within a certificate created by a trusted Certificate Authority (CA)
b) Stored within the protected area of a secure cryptographic device
c) Encrypted by a symmetric key
d) Protected by a message authentication code (MAC) created using an algorithm defined in The mechanism for protection of public keys must ensure that it is not possible to illegitimately substitute one key for another.
b) Stored within the protected area of a secure cryptographic device
c) Encrypted by a symmetric key
d) Protected by a message authentication code (MAC) created using an algorithm defined in The mechanism for protection of public keys must ensure that it is not possible to illegitimately substitute one key for another.
Added
p. 26
TA5.9 Where the device supports third-party applications, the tester shall confirm that protections are provided to prevent the disclosure of PINs during entry through the use of device sensors such as accelerometers, gyroscopes, etc. This may be met through disabling access to sensors during PIN entry, or through keypad implementations that complicate the capture and analysis of sensors during PIN entry.
Added
p. 31
For an SRED-enabled device, the tester shall outline why analysis parameters provide a high level of confidence that key recovery of any account-data security related secret or private cryptographic key resident in the device through side-channel analysis is not possible without an attack potential of at least 26 points for identification and initial exploitation with a minimum of 13 for initial exploitation, as defined in Appendix B.
Added
p. 33
If the POI has multiple screens, all screens must be considered unless the screen will not be used to display prompts.
Added
p. 43
DTRs A1.4, A1.5, and A1.7 must be completed for the ICCR where any specific references to “PIN” are to be read as “account data.” SCRs intended for use with COTS devices do not require the higher level of attack potential because they do not perform a PIN translation like SCRPs.
Added
p. 48
The intent of this requirement is not to establish parameters regarding the function of the biometric reader, for example with regards to false positive / false negative rates, but to ensure that the physical and logical security of the implementation is sufficient.
Implementations of sensors which are not intended for biometric capture, such as cameras used for barcode scanning or other non-biometric purposes, are not in scope of this requirement. If the POI does not capture or process biometric data, this DTR can be marked as N/A.
In the context of this requirement, “sensitive data” refers to the data captured by the biometric sensor as well as any cryptographic keys or other material used to secure that data. This includes raw data captured by the biometric sensor prior to processing it into a template or other post-processed form.
This requirement applies to the capture of sensitive data for cardholder verification method (CVM) usage …
Implementations of sensors which are not intended for biometric capture, such as cameras used for barcode scanning or other non-biometric purposes, are not in scope of this requirement. If the POI does not capture or process biometric data, this DTR can be marked as N/A.
In the context of this requirement, “sensitive data” refers to the data captured by the biometric sensor as well as any cryptographic keys or other material used to secure that data. This includes raw data captured by the biometric sensor prior to processing it into a template or other post-processed form.
This requirement applies to the capture of sensitive data for cardholder verification method (CVM) usage …
Added
p. 49
a) The integrated circuits used to provide the encryption, and any physical protections provided to these elements.
b) What algorithm, mode of operation, and key management are used for this purpose.
c) How cryptographic keys are loaded into the biometric sensor. The tester shall note whether keys can be updated after initial loading, and whether the POI supports this (for example, through an API or internal function of the security processor).
d) The method used to generate the keys loaded into the biometric sensor, and how this ensures that these keys are unique to each POI device.
TA15.5 If the device implements physical protections for the biometric sensor(s), 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 biometric signals from the biometric sensor(s) to the processing …
b) What algorithm, mode of operation, and key management are used for this purpose.
c) How cryptographic keys are loaded into the biometric sensor. The tester shall note whether keys can be updated after initial loading, and whether the POI supports this (for example, through an API or internal function of the security processor).
d) The method used to generate the keys loaded into the biometric sensor, and how this ensures that these keys are unique to each POI device.
TA15.5 If the device implements physical protections for the biometric sensor(s), 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 biometric signals from the biometric sensor(s) to the processing …
Added
p. 55
TB2.9 The tester shall verify that authentication methods with known public vulnerabilities and weaknesses, such as a CBC MAC, are not used for firmware authentication.
TB2.1.8 The tester shall verify that authentication methods with known public vulnerabilities and weaknesses, such as a CBC MAC, are not used for payment application authentication.
• Compliant signatures are generated and attached to all non-third-party executable files.
TB2.1.8 The tester shall verify that authentication methods with known public vulnerabilities and weaknesses, such as a CBC MAC, are not used for payment application authentication.
• Compliant signatures are generated and attached to all non-third-party executable files.
Added
p. 59
Third-party applications must be signed.
“Third-party applications” are applications and data which are not managed or signed using methods assessed to meet Requirement B2.2.
Third-party applications and the software aspects of the third-party application execution environment must be signed, however the process of signing these applications need not meet Requirement B2.2.
Execution Environments used for the storage or execution of third-party applications must not be able to access or otherwise obtain cleartext account data, including PINs, PANs, CVV, and track data. Any such data must be only input to, and processed by, either another physical processing element (such as a separate security processor), or an execution environment on the same processor that is isolated using mandatory access controls. Any sensitive data must be suitably encrypted prior to output to a third-party execution environment.
The laboratory is expected to perform validation of isolation methods used to separate the payment execution environment from the third-party execution …
“Third-party applications” are applications and data which are not managed or signed using methods assessed to meet Requirement B2.2.
Third-party applications and the software aspects of the third-party application execution environment must be signed, however the process of signing these applications need not meet Requirement B2.2.
Execution Environments used for the storage or execution of third-party applications must not be able to access or otherwise obtain cleartext account data, including PINs, PANs, CVV, and track data. Any such data must be only input to, and processed by, either another physical processing element (such as a separate security processor), or an execution environment on the same processor that is isolated using mandatory access controls. Any sensitive data must be suitably encrypted prior to output to a third-party execution environment.
The laboratory is expected to perform validation of isolation methods used to separate the payment execution environment from the third-party execution …
Added
p. 60
TB2.3.6 The tester shall verify that third-party applications and the software of the third-party application execution environment, are signed using cryptographic algorithms outlined in Appendix E (excluding TDES).
TB2.3.7 The tester shall verify that the execution environment validates the third-party application signature, ensuring the integrity and identity of the loaded application.
TB2.3.8 If the third-party application execution environment is not isolated using mandatory access controls on the same processor, the tester shall verify that the firmware authenticates the software of the third-party application execution environment.
TB2.3.9 The tester shall verify that authentication methods with known weaknesses, such as a CBC MAC, are not used for third-party application authentication.
TB2.3.10 The tester shall attempt to bypass the controls used to isolate the payment execution environment from the third-party execution environment, for the purposes of access sensitive data or influencing the execution of payment code. The tester shall document the results of this testing and use …
TB2.3.7 The tester shall verify that the execution environment validates the third-party application signature, ensuring the integrity and identity of the loaded application.
TB2.3.8 If the third-party application execution environment is not isolated using mandatory access controls on the same processor, the tester shall verify that the firmware authenticates the software of the third-party application execution environment.
TB2.3.9 The tester shall verify that authentication methods with known weaknesses, such as a CBC MAC, are not used for third-party application authentication.
TB2.3.10 The tester shall attempt to bypass the controls used to isolate the payment execution environment from the third-party execution environment, for the purposes of access sensitive data or influencing the execution of payment code. The tester shall document the results of this testing and use …
Added
p. 72
In some situations, the data set will produce minor fail cases on individual tests, notwithstanding sufficient random generation. In this case, the tester shall repeat the tests using a second data set to demonstrate the STS tests genuinely pass. See Appendix D, “Configuration and Use of the STS Tool.”.
Added
p. 75
This requirement is addressed if the device can compute an ECDH shared secret and verify an ECDSA or ECSDSA signature using curve P-256 or above.
Testing logs or other equivalent records generated by a device shall be obtained and used as evidence.
For storage and distribution of symmetric keys using symmetric techniques:
• Where the key and sensitive attributes field are encrypted with TDES, devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and the device may optionally support, in addition, the TDKW method from ANSI X9.102.
• Where the key and sensitive attributes field are encrypted with AES, devices must support the X9.143 methodology and/or the ISO 20038 methodology. The device may optionally support in addition, mechanism 2 of ISO/IEC 19772.
X9.143 is recognized as interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. This does not imply that the device must enforce ANSI …
Testing logs or other equivalent records generated by a device shall be obtained and used as evidence.
For storage and distribution of symmetric keys using symmetric techniques:
• Where the key and sensitive attributes field are encrypted with TDES, devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and the device may optionally support, in addition, the TDKW method from ANSI X9.102.
• Where the key and sensitive attributes field are encrypted with AES, devices must support the X9.143 methodology and/or the ISO 20038 methodology. The device may optionally support in addition, mechanism 2 of ISO/IEC 19772.
X9.143 is recognized as interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. This does not imply that the device must enforce ANSI …
Added
p. 77
See the POI Technical FAQs for required characteristics for equivalent methods.
For distribution of symmetric keys using asymmetric techniques, the device must support at least
• RSA OAEP encryption of, at least, the symmetric key with RSA signature over the encrypted key and attributes specified below.
• ECDH to allow derivation of a shared secret key or keys. The ECDH-based protocol must include mutual authentication of both parties. The key derivation process or protocol used must include a means to constrain the usage of each derived shared secret(s) and/or ephemeral key(s) to a single intended purpose while employed in the exchange. Any subject keys sent encrypted via a derived key must be bound to their attributes, as defined below, via signature or using an acceptable key block.
All key block methods must at a minimum include:
• One or more attributes as set by the intended purpose definition that defines the operations for which the …
For distribution of symmetric keys using asymmetric techniques, the device must support at least
• RSA OAEP encryption of, at least, the symmetric key with RSA signature over the encrypted key and attributes specified below.
• ECDH to allow derivation of a shared secret key or keys. The ECDH-based protocol must include mutual authentication of both parties. The key derivation process or protocol used must include a means to constrain the usage of each derived shared secret(s) and/or ephemeral key(s) to a single intended purpose while employed in the exchange. Any subject keys sent encrypted via a derived key must be bound to their attributes, as defined below, via signature or using an acceptable key block.
All key block methods must at a minimum include:
• One or more attributes as set by the intended purpose definition that defines the operations for which the …
Added
p. 79
Post-Quantum Cryptography should be supported in addition to classic cryptography. Specifically, cryptographic algorithms that are currently thought (e.g., as published by NIST) to be secure against a cryptanalytic attack by a quantum computer.
TB9.3 The minimum key sizes and parameters for the algorithm(s) for key management used for terminal security (such as firmware authentication, tamper/storage keys, etc.) must provide an effective key strength of 128 bits or greater.
TB9.3 The minimum key sizes and parameters for the algorithm(s) for key management used for terminal security (such as firmware authentication, tamper/storage keys, etc.) must provide an effective key strength of 128 bits or greater.
Added
p. 83
• One or more attributes that define the cryptographic algorithm and mode of use for which the key can be used.
• One or more attributes that define whether the protected key may be transferred outside the cryptographic domain in which the key is found i.e., exportability.
• Authentication over the encrypted key and attributes (i.e., MAC, digital signature, or authenticated encryption).
• Key length TB9.22 The tester shall validate and detail that all key block methods at a minimum include:
• One or more attributes as set by the intended purpose definition that define the operations for which the key can be used.
• Using key length obfuscation padding to the maximum length for the algorithm⎯192 bits for TDEA and 256 bits for AES.
TB9.23 The tester shall verify that the device checks the length of the binary key data and rejects a block whose length does not meet key length obfuscation padding to the …
• One or more attributes that define whether the protected key may be transferred outside the cryptographic domain in which the key is found i.e., exportability.
• Authentication over the encrypted key and attributes (i.e., MAC, digital signature, or authenticated encryption).
• Key length TB9.22 The tester shall validate and detail that all key block methods at a minimum include:
• One or more attributes as set by the intended purpose definition that define the operations for which the key can be used.
• Using key length obfuscation padding to the maximum length for the algorithm⎯192 bits for TDEA and 256 bits for AES.
TB9.23 The tester shall verify that the device checks the length of the binary key data and rejects a block whose length does not meet key length obfuscation padding to the …
Added
p. 90
For purposes of this DTR, PIN data includes a generated value that is formatted into a valid ISO 9564 PIN-block format for purposes of Consumer Device Cardholder Verification Method (CDCVM) transactions at ATMs.
Added
p. 93
TB14.3 The tester shall confirm that devices supporting third-party applications do not allow for account- data (such as PIN or PAN) entry to be performed using physical interfaces that can be accessed by the third-party application execution environment during the entry of that account data.
TB14.4 The tester shall confirm that devices supporting third-party applications do not allow for access to cleartext account data from the device card readers (ICCR, MSR, and contactless interfaces).
TB14.4 The tester shall confirm that devices supporting third-party applications do not allow for access to cleartext account data from the device card readers (ICCR, MSR, and contactless interfaces).
Added
p. 94
All screens must be considered if the POI has multiple screens, unless the screen will not be used to display prompts.
Third-party applications are not in scope.
Third-party applications are not in scope.
Added
p. 100
If software security domains are supported, the laboratory shall perform an asset flow analysis as described in Appendix G. It shall at least identify all external interfaces of the device and describe the location and flow of all assets and asset containers in all modes of operation, including power-down and device boot, and for all kinds of transactions.
The operating system must implement mandatory access controls that provide for logical protection and isolation of software considered and assessed as firmware, with respect to any other software executed on the same processor. Where the mandatory access-control system uses configuration settings with security-related impact, these settings must be properly configured to ensure the system provides the expected protection.
This requirement for mandatory access controls applies to all devices and device subsystems that provide for executables that are not considered within the scope of firmware, regardless of whether that device implements third-party applications assessed under …
The operating system must implement mandatory access controls that provide for logical protection and isolation of software considered and assessed as firmware, with respect to any other software executed on the same processor. Where the mandatory access-control system uses configuration settings with security-related impact, these settings must be properly configured to ensure the system provides the expected protection.
This requirement for mandatory access controls applies to all devices and device subsystems that provide for executables that are not considered within the scope of firmware, regardless of whether that device implements third-party applications assessed under …
Added
p. 106
TB20.3 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.11 The tester shall confirm that the security policy defines guidance for the proper implementation of any Open Protocols that are part of the approval.
TB20.11 The tester shall confirm that the security policy defines guidance for the proper implementation of any Open Protocols that are part of the approval.
Added
p. 109
TB20.31 The tester shall examine the security policy to verify that it describes how, if supported, third- party applications are loaded and are prevented from accessing cleartext account data, as well as how the applications are authenticated in accordance with DTR B2.3.
TB20.35 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR D12 for any device implementing BR, EDR, or High Speed (HS) features. Specifically, implementations must use Bluetooth 4.1 or higher and Security Mode 4 Level 4 must be used. This requires Secure Connections, which involves authenticated pairing and encryption using 128-bit strength keys generated by means of FIPS-approved Advanced Encryption Standard (AES) encryption. Except where a device communicates with Bluetooth 2.1 through 4.0 peripheral devices, the device may fall back to Security Mode 4 Level 3. Just Works cannot be used at any time, except as delineated for …
TB20.35 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR D12 for any device implementing BR, EDR, or High Speed (HS) features. Specifically, implementations must use Bluetooth 4.1 or higher and Security Mode 4 Level 4 must be used. This requires Secure Connections, which involves authenticated pairing and encryption using 128-bit strength keys generated by means of FIPS-approved Advanced Encryption Standard (AES) encryption. Except where a device communicates with Bluetooth 2.1 through 4.0 peripheral devices, the device may fall back to Security Mode 4 Level 3. Just Works cannot be used at any time, except as delineated for …
Added
p. 114
Cleartext account data must never be available to execution environments that are able to execute third-party applications, even through the use of whitelists.
Primary account number (PAN) data can be output from the POI firmware encrypted, as a keyed hash (validated through requirement B24), or truncated using methods compliant to relevant PCI DSS FAQs. POI firmware is not permitted to provide functions or other methods to pass truncated PAN data directly to third party applications (applications and data which are not managed or signed using methods assessed to meet Requirement B2.2).
TB23.8 Where the device supports third-party applications, the tester shall confirm that any execution environments that are able to execute third-party applications are not able to receive cleartext account data, even through the use of whitelists.
Devices supporting third-party applications must not pass cleartext account data to the execution environment executing the third-party application, even through the use of whitelists.
TB23.1.2 The tester …
Primary account number (PAN) data can be output from the POI firmware encrypted, as a keyed hash (validated through requirement B24), or truncated using methods compliant to relevant PCI DSS FAQs. POI firmware is not permitted to provide functions or other methods to pass truncated PAN data directly to third party applications (applications and data which are not managed or signed using methods assessed to meet Requirement B2.2).
TB23.8 Where the device supports third-party applications, the tester shall confirm that any execution environments that are able to execute third-party applications are not able to receive cleartext account data, even through the use of whitelists.
Devices supporting third-party applications must not pass cleartext account data to the execution environment executing the third-party application, even through the use of whitelists.
TB23.1.2 The tester …
Added
p. 119
TB25.7 If the method used to prevent the entry of more than 120 card presentment operations per hour in a 24-hour period 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 card presentment rate limitation.
Added
p. 129
Where a physical interface is extensible with multiple logical interfaces, such as USB, the vendor must also define which protocols and/or device classes are supported on those interfaces.
The tester shall identify in the Asset Flow Diagrams the physical interfaces through analysis of the device design, as well as verify the presence of logical interfaces through methods such as passive monitoring of communications, port/protocol scans, and code review.
*Note: If the device implements an IP stack, the device must support TLS 1.3 or higher, and must prevent the use of TLS versions less than v1.2 as well as cipher suites that do not provide cryptographic protections equivalent to an effective key strength of 128 bits or greater. Certificate authentication with a key strength of 128 bits or greater must be supported, but certificate authentication with a key strength of 112 bits or greater may also be supported. This does not apply to …
The tester shall identify in the Asset Flow Diagrams the physical interfaces through analysis of the device design, as well as verify the presence of logical interfaces through methods such as passive monitoring of communications, port/protocol scans, and code review.
*Note: If the device implements an IP stack, the device must support TLS 1.3 or higher, and must prevent the use of TLS versions less than v1.2 as well as cipher suites that do not provide cryptographic protections equivalent to an effective key strength of 128 bits or greater. Certificate authentication with a key strength of 128 bits or greater must be supported, but certificate authentication with a key strength of 112 bits or greater may also be supported. This does not apply to …
Added
p. 145
Where a Bluetooth 4.1 or higher device must communicate with Bluetooth 2.1 through 4.0 peripheral devices, it may fall back to Security Mode 4 Level 3.
Added
p. 147
TD13.3 and TD13.4 apply to devices that are able to create their own Wi-Fi hotspot and/or devices specifically distributed with another component, such as a router or printer.
WPS is not allowed for use.
TD13.2 Using a test system, the tester will confirm that the device does not support WEP or WPS.
TD13.3 Where the device supports pre-shared key (PSK) mode, the tester shall describe how the password is entered, whether any default values are handled, and the minimum character length and types required.
WPS is not allowed for use.
TD13.2 Using a test system, the tester will confirm that the device does not support WEP or WPS.
TD13.3 Where the device supports pre-shared key (PSK) mode, the tester shall describe how the password is entered, whether any default values are handled, and the minimum character length and types required.
Added
p. 151
• When these procedures are not yet in use, for example production has not taken place, samples of the template to be used during process operation, or samples from another device which has used the same process in operation.
Added
p. 159
• Access-controlled area logs (may be by electronic/signing logs).
• Inventory logs⎯sample/log that the vendor maintains (any PLM system) for the parts, devices (includes raw materials) to track.
• Inventory logs⎯sample/log that the vendor maintains (any PLM system) for the parts, devices (includes raw materials) to track.
Added
p. 169
This applies even where the manufacturing and initial key loading facilities are in the same physical building or part of the same business complex, as the device will transit between two separate secure areas.
Added
p. 172
TF6.3 The tester shall examine a sample of documentation, including user documentation and component-validation procedures to ensure procedures are followed at the initial key-loading facility.
Added
p. 213
Additionally, NIST approved Post-Quantum Cryptography (PQC) algorithms are approved for use.
• 15360 512 15360/512 256 For device security, algorithms and key sizes approved for use are a minimum of AES 128, IFC 3072, ECC 256 and FFC 3072/256.
• 15360 512 15360/512 256 For device security, algorithms and key sizes approved for use are a minimum of AES 128, IFC 3072, ECC 256 and FFC 3072/256.
Added
p. 219
* Examples of specific attributes of SCA toolsets satisfying these expectations are listed below.
Added
p. 224
A good test may discover total, partial, or zero key leakage, that is practical in a field attack scenario, and/or practical in the white-box context of the evaluation. In situations where a practical attack is known to be capable of exposing the key, the evaluation shall explain definitively the effort needed to extract the key and how compliance is assessed considering obstacles to key-leakage attacks. In assessing this, the evaluation must consider and justify how any degree of key leakage is considerably above an acceptable level, considering that successful attacks may require a lower degree of effort than the effort discovered through testing.
Added
p. 231
A description of this analysis should be in the hardware architecture. It should make clear on implementation level where the assets are produced, transferred, stored, and destroyed, giving a focused design description.
Added
p. 249
• If the device supports third-party applications, this section details how these applications are loaded and prevented from accessing cleartext account data and how they are authenticated in accordance with DTR B2.3.
Modified
p. 7
These are identified by a “T,” followed by the component identification number For example, the first DTR under A1 is:
These are identified by a “T,” followed by the component identification number.
Modified
p. 7
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:
Reporting Requirements for PTS Laboratories To be acceptable for reviewing, evaluation reports must present evidence of a device’s compliance with 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:
Modified
p. 8
• A device overview that summarizes the device’s design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or functions including (but not restricted to):
• A device overview that summarizes the device’s design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or functions including but not restricted to:
Modified
p. 9
• Throughout the report, inline references to specific documents when addressing other sub- requirements
• Throughout the report, inline references to specific documents when addressing other sub- requirements.
Modified
p. 9
• References to relevant information in the overview sections of the evaluation report, and to other DTRs where appropriate;
• References to relevant information in the overview sections of the evaluation report, and to other DTRs where appropriate.
Modified
p. 10
Re-use of test results for PTS POI v6.x evaluations is only allowed where the evidence is no older than the last prior major version⎯i.e., v5.x or other v6.x reviews may supplement work done in the current review.
Re-use of test results for PTS POI v7.x evaluations is only allowed where the evidence is no older than the last prior major version⎯i.e., v6.x or other v7.x reviews may supplement work done in the current review.
Modified
p. 10
Asset Flow Analysis The purpose of the Asset Flow Analysis is to describe in block-diagram form how assets travel within the device (both logically and physically) and are protected as they are processed and manipulated by it. The Asset Flow Analysis does not have to be provided as a single flow diagram. It can be made up from several flow diagrams so long as it is clear how each flow diagram is interconnected and/or interrelated.
Asset Flow Analysis The purpose of the Asset Flow Analysis is to describe in block-diagram form how assets travel within the device (both logically and physically) and are protected as they are processed and manipulated by it. The Asset Flow Diagram does not have to be provided as a single flow diagram. It can be made up from several flow diagrams so long as it is clear how each flow diagram is interconnected and/or interrelated.
Modified
p. 10
Within the Asset Flow Analysis, appropriate domains are assigned for each logical and physical component in the device including software modules, hardware components, and PCB tracks (which may be grouped if several tracks combine a bus). The tester then uses this Asset Flow Analysis to scope the device and apply the appropriate DTRs for the specific domain.
Within the Asset Flow Diagram, appropriate domains are assigned for each logical and physical component in the device including software modules, hardware components, and PCB tracks (which may be grouped if several tracks combine a bus). The tester then uses this Asset Flow Diagram to scope the device and apply the appropriate DTRs for the specific domain.
Modified
p. 10
Requirement The vendor shall provide an Asset Flow Analysis highlighting each physical and logical component in the device and indicating how each asset flows between each physical component, showing the logical modules used to protect it. The general idea is to indicate the status of an asset as it travels through the device⎯for example, whether the asset is clear text or encrypted at a point in the data flow. Any hardware component or software module interfacing with the asset will …
Requirement The laboratory shall produce an Asset Flow Diagram highlighting each physical and logical component in the device and indicating how each asset flow diagrams between each physical component, showing the logical modules used to protect it. The goal is to indicate the status of an asset as it travels through the device⎯for example, whether the asset is cleartext or encrypted at a point in the data flow. Any hardware component or software module interfacing with the asset will be …
Modified
p. 10
It is important that asset flows and domains are correct and complete for each asset. The lab will validate and notify the vendor if discrepancies are discovered in the asset flows for corrective action.
It is important that asset flows and domains are correct and complete for each asset.
Removed
p. 11
For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information.” “Secret information” consists of any private or secret cryptographic keys or passwords/authentication codes relied on by the device to maintain security characteristics governed by PCI requirements.
The device is protected against penetration by including features that detect any feasible attempts to tamper with the device and cause immediate erasure of all cryptographic keys and sensitive data when such an attempt is detected.
The device is protected against penetration by including features that detect any feasible attempts to tamper with the device and cause immediate erasure of all cryptographic keys and sensitive data when such an attempt is detected.
Modified
p. 11 → 12
The objective of this section is to assess the device’s ability to protect clear-text PINs and other sensitive data. Attack scenarios are not presented in this requirement. DTRs A2, A4, A6, A8, A10, and A13 include attack costings which will incorporate tamper-detection results from this requirement during the attack development.
The objective of this section is to assess the device’s ability to protect cleartext PINs and other sensitive data. Attack scenarios are not presented in this requirement. DTRs A2, A4, A5, A6, A7, A8, A10, A13, and A15 include attack costings which will incorporate tamper-detection results from this requirement during the attack development.
Modified
p. 11 → 12
Any tamper-detection/key-erasure mechanisms function even in the absence of applied power.
Any tamper-detection mechanisms function even in the absence of applied power.
Modified
p. 11 → 12
• Prior to erasure, keys must still be protected in accordance with Requirement A6.
Modified
p. 11 → 13
Secret or private cryptographic keys that are never used to encrypt or decrypt data (e.g., keys, accounts, PINs), or are not used for authentication, do not need to be considered secret data and therefore do not need to be erased•for example, where the device uses a chip set that automatically generates keys at initialization, but the keys are not subsequently used by the device.
Secret or private cryptographic keys that are never used to encrypt or decrypt data (e.g., keys, accounts, PINs) or are not used for authentication, do not need to be considered secret data and therefore do not need to be erased•for example, where the device uses a chipset that automatically generates keys at initialization, but the keys are not subsequently used by the device.
Removed
p. 12
• Opaqueness: Epoxy must be opaque in the visible spectrum.
• Hardness: Epoxy must be hard enough so that a sharp object cannot be used to penetrate the epoxy to the depth of the underlying circuitry.
• Tamper Evidence: The epoxy must show visible evidence of tamper when an attempt to penetrate the epoxy with a sharp object is made.
• Adhesion: Epoxy must resist attempts to forcibly separate it from the circuit board. When enough force is applied to remove the epoxy, severe damage should result such that the device is non-functional.
If switches are used as the primary protection for the area around a physical keypad area, then at least three blind, tamper switches must be implemented. The switches must be protected from attacks that use the application of adhesives or conductive liquids to disable the switches. The design must ensure that a minimum of three switches in the keypad area must …
• Hardness: Epoxy must be hard enough so that a sharp object cannot be used to penetrate the epoxy to the depth of the underlying circuitry.
• Tamper Evidence: The epoxy must show visible evidence of tamper when an attempt to penetrate the epoxy with a sharp object is made.
• Adhesion: Epoxy must resist attempts to forcibly separate it from the circuit board. When enough force is applied to remove the epoxy, severe damage should result such that the device is non-functional.
If switches are used as the primary protection for the area around a physical keypad area, then at least three blind, tamper switches must be implemented. The switches must be protected from attacks that use the application of adhesives or conductive liquids to disable the switches. The design must ensure that a minimum of three switches in the keypad area must …
Modified
p. 12 → 13
If tamper grids are used as a primary mechanism, they meet the following:
If tamper grids are used as a primary tamper-detection and response mechanism, the following best practice methods should be considered:
Modified
p. 12 → 13
• 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).
• 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. 12 → 13
• Tamper switches and components connecting to these SCRPs must be capable of providing information to a query from an external source (such as a payment application on a mobile phone) to indicate if in a tamper state.
• Tamper switches and components connecting to these Secure card readers
• PIN (SCRPs) must be capable of providing information to a query from an external source (such as a payment application on a mobile phone) to indicate if in a tamper state.
• PIN (SCRPs) must be capable of providing information to a query from an external source (such as a payment application on a mobile phone) to indicate if in a tamper state.
Modified
p. 13 → 14
TA1.3 The tester shall describe any physical shielding⎯i.e., active, passive⎯or other chip or embedded physical protections that any microprocessors used in the device that contain clear- text secret or sensitive data, and how these are effective against tampering the physical package(s)⎯e.g., die encasement. The tester shall describe any physical barriers that surround microprocessors in the device, and state whether/how these totally envelop or partly surround microprocessors, and whether such barriers are tamper-responsive.
TA1.3 The tester shall describe any physical shielding⎯i.e., active, passive⎯or other chip or embedded physical protections that any microprocessors used in the device that contain cleartext secret or sensitive data, and how these are effective against tampering the physical package(s)⎯e.g., die encasement. The tester shall describe any physical barriers that surround microprocessors in the device, and state whether/how these totally envelop or partly surround microprocessors, and whether such barriers are tamper-responsive.
Modified
p. 13 → 14
b) The version of the PCB; the main purpose of the PCB;
b) The version of the PCB (and PCBA version, if provided), and the main purpose of the
Modified
p. 13 → 14
d) Note as to whether the PCB contains any sensitive signals (such as clear-text PINs, MSR, ICC, or display connections•but not tamper signals); and finally
d) Note as to whether the PCB contains any sensitive signals (such as cleartext PINs, MSR, ICC, or display connections•but not tamper signals); and finally
Removed
p. 15
TA1.10 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.
TA1.11 The tester shall describe what testing was performed to validate any volume encapsulation.
Testing must include chemical and/or abrasive, and heating methods to bypass this protection.
TA1.11 The tester shall describe what testing was performed to validate any volume encapsulation.
Testing must include chemical and/or abrasive, and heating methods to bypass this protection.
Modified
p. 15 → 16
TA1.10 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. 15 → 16
TA1.11 The tester shall describe what testing was performed to validate any attachment and forming methods. Methods of testing must include use of localized heating, solvents, and abrasion. The tester shall justify why the testing performed was sufficient and why the security measures cannot be bent, melted, or otherwise bypassed, to gain access to sensitive signals.
Modified
p. 15 → 16
TA1.12 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. 15 → 16
TA1.13 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.
Modified
p. 15 → 16
TA1.14 The tester shall state how any passive components, connectors, or other items that carry tamper signals are protected against being accessed. The tester shall include any connections to power planes through hole vias that may be exposed outside of the tamper-detecting areas of the POI.
Modified
p. 15 → 16
TA1.15 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. 15 → 16
TA1.16 Deriving from previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the POI results from tamper-detection events, and if applicable, where any of these keys are not zeroized, how other mechanisms exist to disable the device, and how these keys are protected in accordance with Requirement A6.
Modified
p. 15 → 16
TA1.17 From the above descriptions, the tester shall explain how the POI is rendered immediately inoperative after any tamper event, except as noted in the next step.
Modified
p. 16 → 18
Keypads used for PIN entry require an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for initial exploitation, exclusive of the IC card reader, as defined in Appendix B.
Keypads used for PIN entry require an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for initial exploitation, exclusive of the integrated circuit (IC) card reader, as defined in Appendix B.
Modified
p. 16 → 18
Keypads used for manual PAN entry, but not PIN entry
•e.g., a non-PED
•require an attack potential of at least 16 per device for identification, with a minimum of 8 points for initialexploitation.
•e.g., a non-PED
•require an attack potential of at least 16 per device for identification, with a minimum of 8 points for initial
Keypads used for manual PAN entry, but not PIN entry
•e.g., a non-PED
•require an attack potential of at least 16 per device for identification, with a minimum of 8 points for initial exploitation, as defined in Appendix B.
•e.g., a non-PED
•require an attack potential of at least 16 per device for identification, with a minimum of 8 points for initial exploitation, as defined in Appendix B.
Modified
p. 16 → 18
Sensitive keypads are defined as those through which clear-text PINs or manual PANs can be entered.
Sensitive keypads are defined as those through which cleartext PINs or manual PANs can be entered.
Modified
p. 16 → 18
A2 allows the evaluator to use any method of attack feasible against the terminal limited only by the attack potential of 26 in total with 13 for initial exploitation for PIN entry, and 16 in total with 8 for initial exploitation for account-data entry. The POI device must be able to withstand attack from any side, including front and rear case replacement up to the attack potential value.
A2 allows the evaluator to use any method of a practical attack against the terminal limited only by the attack potential of 26 in total with 13 for initial exploitation for PIN entry, and 16 in total with 8 for initial exploitation for account-data entry. The POI device must be able to withstand attack from any side, including front and rear case replacement up to the attack potential value.
Modified
p. 16 → 18
For reference, see information gathered in prior DTR.
For reference, see information gathered in Requirement A1.
Modified
p. 16 → 18
TA2.2 The tester shall describe the path taken by the signals that connect the sensitive keypad entry mechanism(s) to the secure processor(s). The tester shall reference the relevant aspects of the asset flow.
TA2.2 The tester shall describe the path taken by the signals that connect the sensitive keypad entry mechanism(s) to the secure processor(s). The tester shall reference the relevant aspects of the Asset Flow Diagram.
Modified
p. 16 → 18
TA2.3 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 or manual PAN signals. The tester shall reference the relevant aspects of the asset flow.
TA2.3 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 or manual PAN signals. The tester shall reference the relevant aspects of the Asset Flow Diagram in the report.
Modified
p. 17 → 19
TA2.10 The tester shall describe the different attack paths considered. Using the format shown in Appendix B and providing images allowing the principal steps in the analysis to be understood, the tester shall generate sensitive keypad attack calculations using different attack techniques on the POI, and present the most feasible attacks for capturing PIN, and if SRED, the most feasible attack for capturing PAN data
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
TA2.10 The tester shall describe the different attack paths considered. Using the format shown in Appendix B and providing images allowing the principal steps in the analysis to be understood, the tester shall generate sensitive keypad attack calculations using different attack techniques on the POI, and present the most practical attacks for capturing PIN, and if SRED, the most practical attack for capturing PAN data
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
Modified
p. 18 → 20
• Environmental conditions
• Environmental conditions, nor
Removed
p. 20
Protected area of the device is that area(s) within the boundaries of the tamper-detection and response mechanisms.
Modified
p. 20 → 22
It is expected that each type of information may have multiple “storage areas” and “methods of protection” (for example, clear-text PINs may appear in internal memory of the security processor, as well as on the external heap cache and within the processor registers, and the external memory may be protected by encryption with the external bus key as well as with physical protections of the secure area of the POI).
It is expected that each type of information may have multiple “storage areas” and “methods of protection” (for example, cleartext PINs may appear in internal memory of the security processor, as well as on the external heap cache and within the processor registers, and the external memory may be protected by encryption with the external bus key as well as with physical protections of the secure area of the POI).
Removed
p. 21
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. 21 → 23
TA4.8 If the POI allows for execution of applications and firmware on the same processor that stores or operates on clear-text 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.
TA4.8 If the POI allows for execution of applications and firmware on the same processor that stores or operates on cleartext 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. 22 → 24
TA4.13 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.
TA4.13 The tester shall describe and produce a costing for the most practical 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 → 25
For A5, monitoring sound refers to other audible sounds apart from the beep generated by the device when a key is pressed.
For Requirement A5, monitoring sound refers to other audible sounds apart from the beep generated by the device when a key is pressed.
Modified
p. 24 → 26
TA5.10 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 initial exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least …
Modified
p. 25 → 27
Keys resident in the device or its components means clear-text 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.
Keys resident in the device or its components means cleartext 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. 26 → 28
TA6.7 If the POI stores clear-text 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 clear-text cryptographic keys.
TA6.7 If the POI stores cleartext 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 cleartext cryptographic keys.
Modified
p. 26 → 28
TA6.8 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. This information should include, at minimum:
TA6.8 The tester shall describe and cost the most practical 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. This information should include, at minimum:
Modified
p. 26 → 28
• Attacks involving some or all of attacks modeled elsewhere. For example, DTRs A1, A2, A4, and A7 (but not restricted thereto) must be considered and included in this attack, if relevant.
• Attacks involving some or all of attacks modeled elsewhere. For example, DTRs A2, A4, and A7 (but not restricted thereto) must be considered and included in this attack, if relevant.
Modified
p. 26 → 28
• If an attack scenario (including any method related to A1, A2, A4, and A7) can be developed that yields an attack potential for any PIN security-related cryptographic key of less than 35 per device for identification and initial exploitation or less than 15 per device for initial 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 examples shown in Appendix B …
• If an attack scenario (including any method related to Requirements A2, A4 and A7) can be developed that yields an attack potential for any PIN security-related cryptographic key of less than 35 per device for identification and initial exploitation or less than 15 per device for initial 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 examples shown in Appendix B …
Modified
p. 27 → 29
For PIN security-related keys, the evaluation should determine at least one algorithm to analyze thoroughly, applying the SCA approach most likely to succeed, based on a rigorous assessment of asset value versus feasible attacks. Reasoning for not testing any algorithm must 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.
For PIN security-related keys, the evaluation should determine at least one algorithm to analyze thoroughly, applying the SCA approach most likely to succeed, based on a rigorous assessment of asset value versus practical attacks. Reasoning for not testing any algorithm must 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.
Modified
p. 28 → 30
• A list of all PIN security-related cryptographic keys (secret and private) that may be directly attacked by side-channel analysis approaches. For SRED devices this includes account- data-security-related cryptographic keys. This list shall indicate whether the most applicable approach is statistical analysis of static keys with variable inputs or outputs, or other approaches such as, but (not restricted to) timing analysis.
• A list of all security-related cryptographic keys (secret and private) that may be directly attacked by side-channel analysis approaches. For SRED devices this includes account- data-security-related cryptographic keys. This list shall indicate whether the most applicable approach is statistical analysis of static keys with variable inputs or outputs, or other approaches such as, but (not restricted to) timing analysis.
Modified
p. 28 → 30
• A list of all PIN security-related keys that may be indirectly attacked by side-channel analysis•for example, keys that may be attacked following additional attack steps. For SRED devices this includes account-data-security-related cryptographic keys.
• A list of all security-related keys that may be indirectly attacked by side-channel analysis for example, keys that may be attacked following additional attack steps. For SRED devices this includes account-data-security-related cryptographic keys.
Modified
p. 28 → 30
• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as unique keys per operation or other constraints on exercising static key values or any other algorithmic constraints on SCA attacks.
• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as unique-keys-per-operation or other constraints on exercising static key values or any other algorithmic constraints on SCA attacks.
Removed
p. 29
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 older than the last prior major version⎯i.e., v5.x or other v6.x reviews may supplement work done in the current review⎯of the PCI POI Security Requirements prior to the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A7 security requirements.
Modified
p. 29 → 31
TA7.5 The tester shall justify the methodologies used and findings, in accordance with Appendix F and with regard to published attacks. 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.
TA7.5 The tester shall justify the methodologies used and findings, in accordance with Appendix F and with regard to published attacks. The tester shall outline why analysis parameters provide a high level of confidence that key recovery of any PIN-security-related secret or private cryptographic key resident in the device through side-channel analysis is not possible without an attack potential of at least 35 points for identification and initial exploitation with a minimum of 15 for initial exploitation, as defined in …
Modified
p. 29 → 31
• Whether the attack can be feasible at any distance away from the processor,
• Whether the attack can be practical at any distance away from the processor,
Modified
p. 30 → 33
A8 is applicable to a device that contains a display and may output non-PIN data.
Requirement A8 is applicable to a device that contains a display and may output non-PIN data.
Modified
p. 30 → 33
A8 applies to any components or paths containing clear-text display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.
A8 applies to any components or paths containing cleartext display signals between the processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.
Modified
p. 30 → 33
“Non-PIN data” refers to numeric data other than the PIN that is entered via the keypad. It does not include control inputs such as “enter,” “cancel,” etc. It also does not apply to data entered while the device is in special modes⎯e.g., maintenance⎯that are not intended to be accessed by cardholders and merchants.
“Non-PIN data” refers to numeric data other than the PIN that is entered via the keypad. It does not include control inputs such as “enter,” “cancel,” etc. It also does not apply to data entered while the device is in special modes⎯e.g., maintenance⎯that are not intended to be accessed by cardholders and merchants. The intent of the testing is to determine if the device falsely prompts for PIN when the device is expecting non-PIN data and is not in a …
Modified
p. 30 → 33
TA8.1 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.
TA8.1 The tester shall describe whether the POI firmware allows for entry of non-PIN data to be passed to an application or 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. 31 → 34
TA8.8 The tester shall describe and provide a costing for the most feasible attack to change the prompts on the display of the POI. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.
TA8.8 The tester shall describe and provide a costing for the most practical attack to change the prompts on the display of the POI. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.
Modified
p. 34 → 37
Note: Contact chip is addressed in A13. Manual PAN entry is addressed in A2.
Note: Contact chip is addressed in Requirement A13. Manual PAN entry is addressed in A2.
Modified
p. 34 → 37
Access to the inside of the device for routine maintenance (for example, replenishing paper) shall not allow access to clear-text account data, for example, by making cabling which transmits the data physically inaccessible to routine maintenance personnel or encrypting the sensitive card data transmitted internally within the device between components.
Access to the inside of the device for routine maintenance (for example, replenishing paper) shall not allow access to cleartext account data, for example, by making cabling which transmits the data physically inaccessible to routine maintenance personnel or encrypting the sensitive card data transmitted internally within the device between components.
Modified
p. 34 → 37
As per the asset flow diagrams, all methods of card-data entry that are natively supported by the SRED firmware must be assessed. Magnetic stripe and contactless are addressed in this DTR. A device validated to SRED cannot have any card-reader types as part of the approved hardware and firmware version identifiers where that reader could not meet this requirement, A2 and/or A13, as applicable. Nor can the firmware support the receiving of card data from an external component that does …
As per the Asset Flow Diagrams, all methods of card-data entry that are natively supported by the SRED firmware must be assessed. Magnetic stripe and contactless are addressed in this DTR. A device validated to SRED cannot have any card-reader types as part of the approved hardware and firmware version identifiers where that reader could not meet this requirement, A2 and/or A13, as applicable. Nor can the firmware support the receiving of card data from an external component that does …
Modified
p. 35 → 38
TA10.8 The tester shall provide accurate measurements of any free space around the magnetic-stripe read head. The tester shall justify why placement of a secondary read head (even one that is very small and/or thin) 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 …
TA10.8 The tester shall provide accurate measurements of any free space around the magnetic-stripe read head. The tester shall justify why placement of a secondary read head (even one that is very small and/or thin) is made impractical 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 …
Modified
p. 35 → 38
TA10.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.
TA10.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 cleartext PINs and magnetic-stripe data.
Modified
p. 37 → 40
The objective of this requirement is to ensure that all account data is handled in a secure manner. The requirement allows for the encryption of account data directly at the read head or for account data to be submitted to the device in clear-text form. This data is then communicated to a secure controller where it is processed.
The objective of this requirement is to ensure that all account data is handled in a secure manner. The requirement allows for the encryption of account data directly at the read head or for account data to be submitted to the device in cleartext form. This data is then communicated to a secure controller where it is processed.
Modified
p. 37 → 40
The term “processed” is used as a generic term, which includes but is not limited to account-data encryption and the selective disclosure of clear-text account data by the secure controller to cryptographically authenticated applications (per B23.1).
The term “processed” is used as a generic term, which includes but is not limited to account-data encryption and the selective disclosure of cleartext account data by the secure controller to cryptographically authenticated applications (per Requirement B23.1).
Modified
p. 37 → 40
• The application must be cryptographically authenticated by keys secured within the key domain of the POI using algorithms and keys sizes consistent with those stipulated in B10.
• The application must be cryptographically authenticated by keys secured within the non-PIN key domain of the POI using algorithms and keys sizes consistent with those stipulated in B10.
Modified
p. 37 → 40
• The PAN itself. If the PAN can be parsed, the parts of the PAN in clear text must not exceed the maximum truncation requirements of the associated payment brand when considered in totality with all possible firmware output methods.
• The PAN itself. If the PAN can be parsed, the parts of the PAN in cleartext must not exceed the maximum truncation requirements of the associated payment brand when considered in totality with all possible firmware output methods.
Modified
p. 37 → 40
For example, SRED-compliant POI devices are permitted to output clear-text PAN data to authenticated applications, as well as based on firmware authenticated whitelists. To support acceptable truncation formats for each Payment Brand, a POI may pass the clear-text data to an application for processing, or it may perform truncation and/or encryption of parts of the PAN based on firmware-authenticated whitelists. Whitelists allowing for digits of the PAN to be output in clear text when the system is operating in a …
For example, SRED-compliant POI devices are permitted to output cleartext PAN data to authenticated applications, as well as based on firmware authenticated whitelists. To support acceptable truncation formats for each Payment Brand, a POI may pass the cleartext data to an application for processing, or it may perform truncation and/or encryption of parts of the PAN based on firmware-authenticated whitelists. Whitelists allowing for digits of the PAN to be output in cleartext when the system is operating in a format-preserving …
Modified
p. 37 → 40
In addition, the following must be encrypted if it is feasible to associate with the corresponding clear-text PAN:
In addition, the following must be encrypted if it is practical to associate with the corresponding cleartext PAN:
Modified
p. 37 → 40
• Service code In all cases cardholder name, expiration date, and service code must be encrypted for SCRs intended for use with COTS devices and for SCRPs.
• Service code In all cases cardholder name, expiration date, and service code must be encrypted for secure card readers (SCRs) intended for use with commercial off-the-shelf (COTS) devices and for SCRPs.
Modified
p. 38 → 41
The POI shall only display one clear-text digit at a time during manual (key-entered) PAN entry. The display is required to obfuscate the digit prior to the display of the next clear-text digit. No more than one clear-text digit may be displayed at any time during entry.
The POI shall only display one cleartext digit at a time during manual (key-entered) PAN entry. The display is required to obfuscate the digit prior to the display of the next cleartext digit. No more than one cleartext digit may be displayed at any time during entry.
Modified
p. 38 → 41
TA11.2 The tester shall verify that the application handling clear-text account data executes within the secure boundary of the device. This should correlate with information presented in the Asset Flow Analysis or else constitutes an exception.
TA11.2 The tester shall verify that the application handling cleartext account data executes within the secure boundary of the device. This should correlate with information presented in the Asset Flow Diagram or else constitutes an exception.
Modified
p. 38 → 41
TA11.3 The tester shall validate that any manual PAN-entry functions implemented by the POI firmware never display more than one clear-text PAN digit at a time, and that any clear-text digit that is displayed is obfuscated prior to the display of the next digit.
TA11.3 The tester shall validate that any manual PAN-entry functions implemented by the POI firmware never display more than one cleartext PAN digit at a time, and that any cleartext digit that is displayed is obfuscated prior to the display of the next digit.
Modified
p. 39 → 42
Access to the inside of the device for routine maintenance (for example, replenishing paper) shall not allow access to clear-text account data•for example, by making cabling that transmits the data physically inaccessible to routine maintenance personnel or encrypting the sensitive card data transmitted internally within the device between components.
Access to the inside of the device for routine maintenance (for example, replenishing paper) shall not allow access to cleartext account data•for example, by making cabling that transmits the data physically inaccessible to routine maintenance personnel or encrypting the sensitive card data transmitted internally within the device between components.
Modified
p. 40 → 43
SCRPs shall require an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for initial exploitation.
SCRPs shall require an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for initial exploitation as defined in Appendix B.
Modified
p. 40 → 43
TA13.1 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 device when necessary.
Modified
p. 41 → 44
TA13.10 As per the asset flow diagrams, the tester shall list any components, including ICC interface components, passive components, connectors, or other items, that are connected to the path of the customer ICC I/O signal.
TA13.10 The tester shall list any components, including ICC interface components, passive components, connectors, or other items, that are connected to the path of the customer ICC I/O signal.
Modified
p. 42 → 45
TA13.17 The tester shall describe and provide a costing for the most feasible attack to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.
TA13.17 The tester shall describe and provide a costing for the most practical attack to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.
Modified
p. 43 → 46
The intent of requirement A14 is to make successful installation of PIN-disclosing bugs via the card slot infeasible. To meet this requirement the cardholder must have at least the ability to inspect the entry. And where the slot is neither positioned straight towards the cardholder nor upward facing ⎯i.e., it is downward facing⎯a design has to meet the following criteria:
The intent of requirement A14 is to make successful installation of PIN-disclosing bugs via the card slot impractical. To meet this requirement the cardholder must have at least the ability to inspect the entry. And where the slot is neither positioned straight towards the cardholder nor upward facing⎯i.e., it is downward facing⎯a design has to meet the following criteria:
Removed
p. 45
A memory re-initialization (security) cycle may last longer than 24 hours to allow the adjustment of the security cycle of the PIN entry device (maximum 24 hours duration) to the business cycle of an integrated POS system it may be connected to (maximum 24 hours duration). The firmware of the PIN entry device, during the cycles’ adjustment processes, must not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours). This must be included in the security policy for the device.
Modified
p. 45 → 50
Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must be either cryptographically protected using a key (for example, HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption). As such, an authenticity check will also confirm the integrity of the installed firmware, an additional integrity check is not necessary, but optionally may be additionally performed using a non-authenticated digest such as a CRC.
Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must be either cryptographically protected using a key (for example, HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption). As such, an authenticity check will also confirm the integrity of the installed firmware, an additional integrity check is not necessary but optionally may be additionally performed using a non-authenticated digest such as a CRC.
Modified
p. 45 → 50
The self-tests shall include authenticated applications, as well as Open Protocols and Secure Reading and Exchange of Data code as applicable.
The self-tests shall include authenticated applications, as well as Open Protocols and Secure Reading and Exchange of Data code as applicable. Authenticated applications in this context do not include applications falling under Security Requirement B2.3.
Modified
p. 46 → 51
TB1.1 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. The tester shall reference the relevant aspects of the asset flow.
TB1.1 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. The tester shall reference the relevant aspects of the Asset Flow Diagram.
Modified
p. 46 → 51
TB1.5 The tester shall review the source code of the POI to confirm what algorithms and keys are used to perform the self-test functions that are implemented by the firmware of the POI. The tester shall confirm that any register settings required to activate hardware-based self-test functions are correctly assigned.
TB1.5 The tester shall review the source code of the POI to confirm what algorithms and keys are used to perform the self-test functions that are implemented by the firmware of the POI, and that cryptography used for this purpose provides an effective key strength of 128 bits or stronger. The tester shall confirm that any register settings required to activate hardware-based self-test functions are correctly assigned.
Modified
p. 49 → 54
TB2.3 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.
TB2.3 The tester shall determine the level of protection for the external (outside of the boundary of the device) 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. 49 → 54
TB2.4 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, along with examples of acceptable hashing algorithms.
TB2.4 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 such that they provide an effective key strength of 128 bits or stronger. Permitted appropriate algorithms are stated in Appendix E (excluding TDES).
Removed
p. 50
TB2.9 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. 50 → 55
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 payment 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 (COTS) 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 payment application on the COTS device. A secure channel, as defined in the guidance, must be used for non-physically protected internal links and external electronic communications.
Modified
p. 51 → 56
Payment applications are considered to be any code that can be loaded onto the device that is not firmware or part of a third-party application. Payment applications are signed as part of DTR B2.2. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
Modified
p. 51 → 56
TB2.1.2 The tester shall determine the rank of protection strength for the component involved in application authentication, including configuration updates and that the authentication is performed by an appropriate component.
TB2.1.2 The tester shall determine the rank of protection strength for the component involved in payment application authentication, including configuration updates and that the authentication is performed by an appropriate component.
Modified
p. 51 → 56
TB2.1.3 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, along with examples of acceptable hashing algorithms.
TB2.1.3 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 such that they provide an effective key strength of 128 bits or stronger. AES 128 or other algorithms and key sizes equivalent to or greater in strength than AES 128 must be used. Permitted algorithms are stated in Appendix E (excluding TDES).
Modified
p. 51 → 56
TB2.1.4 For each of the processing elements listed in DTR A4, 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.
TB2.1.4 For each of the processing elements listed in DTR A4, 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 payment application cannot be updated, the tester shall ensure that this is detailed in the table as well.
Removed
p. 52
TB2.1.8 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. 52 → 57
TB2.1.7 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.
TB2.1.7 If (H)MAC method(s) are used for payment 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. 52 → 57
TB2.1.9 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:
TB2.1.9 For each of the methods of authentication the tester shall obtain a correctly authenticated payment application image and, if applicable, a software and/or configuration update, and:
Removed
p. 53
• All executable files are signed.
Modified
p. 53 → 58
• Software is only signed using a secure cryptographic device⎯e.g., smartcard⎯provided by the terminal vendor.
• Software is only signed using a secure cryptographic device or hardware-management devices (HMDs)⎯e.g., smartcards⎯provided by the terminal vendor.
Modified
p. 53 → 58
Signing applies to any and all files that are executed or interpreted on the system (by either the firmware or the application). The firmware will have the ability to verify file signatures and will delete anything that fails verification.
Signing applies to any and all files that are executed or interpreted on the system (by either the firmware or the payment application). The firmware will have the ability to verify file signatures and will delete anything that fails verification.
Modified
p. 53 → 58
TB2.2.1 The tester shall verify that the signing process can only be performed under dual control and that the software is only signed using a secure cryptographic device provided by the vendor.
TB2.2.1 The tester shall verify that the signing process can only be performed under dual control and that the software is only signed using a secure cryptographic device or HMDs provided by the vendor.
Modified
p. 54 → 61
TB3.1 The tester shall perform a test in which a PIN is entered to verify that the device does not output any digits of the PIN value. The tester shall note and report any characters, signals, or tones that are outputted. The device must display the same non-significant character for all PIN-entry uses. The tester shall provide an image capturing this.
TB3.1 The tester shall perform a test in which a PIN is entered to verify that the device does not output any digits of the PIN value. The tester shall note and report any characters, signals, or tones that are outputted. The device must display the same non-significant character for all PIN entry uses. The tester shall provide an image capturing this.
Modified
p. 56 → 63
The device must automatically clear its internal buffers of full track data (or chip equivalent) and sensitive authentication data is cleared when either:
The device must automatically clear its internal buffers of full track data (or chip equivalent), and sensitive authentication data is cleared when either:
Modified
p. 56 → 63
Cleartext PINs must not exist for more than ninety seconds maximum from the completion of the cardholder’s PIN entry. In all cases, erasure of the cleartext PIN must occur before the tamper- detection mechanisms can be disabled using attack methods described in A2.
Modified
p. 56 → 63
TB4.1 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,clear-text PIN or account-data values, clear-text 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,
TB4.1 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, cleartext PIN or account-data values, cleartext 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, cleartext PIN or account-data values, cleartext cryptographic keys, or key components outside of the crypto-processor are considered sensitive data.
Removed
p. 59
The items provided in the table below are for the purposes of example only:
Modified
p. 59 → 66
Cryptographic Method of loading per Authentication TMK Components through keypad Two seven-character passwords through keypad Encrypted under PKman Provided by encryption Clear text through serial port Operator authentication provided on key-loading device Pkman Embedded in firmware Two eight-character passwords required to operate firmware loading TB5.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods.
Cryptographic Method of loading per Authentication TB5.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods.
Modified
p. 59 → 66
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.
Note: POI devices must support at least one of the encrypted key-loading methods for the loading of private or secret keys. Encrypting Pin Pads (EPPs) and Original Equipment Manufacturer PIN Entry Devices (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. 59 → 66
a) When entering clear-text 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 …
a) When entering cleartext 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. 59 → 66
b) For injecting clear-text secret or private keys from a key loader (which must be some type of secure cryptographic device), either the key loader or the device or both must require two or more passwords/authentication codes before injecting the clear-text key into the device.
b) For injecting cleartext secret or private keys from a key loader (which must be some type of secure cryptographic device), either the key loader or the device or both must require two or more passwords/authentication codes before injecting the cleartext key into the device.
Modified
p. 60 → 67
Injection of clear-text 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.
Injection of cleartext 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. 60 → 67
TB5.7 The tester shall verify that the loading of all private or secret keys can be performed without using plaintext key injection (as required by PCI PIN). If an asymmetric key-loading technique which does not support mutual cryptographic authentication is used for loading the initial keys, a secure room as defined in PIN Security Requirements 32-9 must be used. If devices generate key pairs and have the public key signed, this process must occur in this same secure environment.
TB5.7 The tester shall verify that the loading of all private or secret keys can be performed without using cleartext key injection (as required by PCI PIN). If an asymmetric key-loading technique which does not support mutual cryptographic authentication is used for loading the initial keys, a secure room as defined in PIN Security Requirements 32-9 must be used. If devices generate key pairs and have the public key signed, this process must occur in this same secure environment.
Modified
p. 60 → 67
TB5.8 The tester shall detail any further sensitive services provided by the POI that have not been addressed as defined above. This must include the disabling or alteration of any systems or functions relied upon by the POI to meet the PTS requirements. Examples include but are not limited to changing SRED encryption modes or altering system time that may be used to verify certificate validity (or used for other system security services).
TB5.8 The tester shall detail any further sensitive services provided by the POI that have not been addressed as defined above. This must include the disabling or alteration of any systems or functions relied upon by the POI to meet the POI requirements. Examples include but are not limited to changing SRED encryption modes or altering system time that may be used to verify certificate validity (or used for other system security services).
Modified
p. 62 → 69
TB6.6 For all sensitive services, excluding loading of encrypted key values but including loading of clear-text key value from an external key-loading device, the tester shall confirm that a timer is implemented that will return the POI to a non-sensitive mode after a maximum of 15 minutes, regardless of input or continued activity.
TB6.6 For all sensitive services, excluding loading of encrypted key values but including loading of cleartext key value from an external key-loading device, the tester shall confirm that a timer is implemented that will return the POI to a non-sensitive mode after a maximum of 15 minutes, regardless of input or continued activity.
Modified
p. 64 → 71
Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the random number generator at startup cannot be abused to intentionally reproduce a given random value or sequence.
Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the random-number generator at startup cannot be abused to intentionally reproduce a given random value or sequence.
Modified
p. 64 → 71
Usages include use for the EMV unpredictable number.
Usages include use for the EMV® unpredictable number.
Modified
p. 64 → 71
Pseudorandom-number generator (PRNG) designs (also known as deterministic random-bit generator, or DRBG) from NIST SP800-90A or ISO 18031 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.
Modified
p. 64 → 71
B7 is mandatory for the SCRP approval class in order to provide a source of entropy for external payment applications. 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 SCRP.
Requirement B7 is mandatory for the SCRP approval class in order to provide a source of entropy for external payment applications.
Modified
p. 64 → 71
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.
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.
Modified
p. 64 → 71
TB7.2 The tester shall confirm that the process outlined in TB7.1 includes a method to provide entropy (the seed length shall be at least 256 bits) from a hardware-based source, as well as a software-based “whitening” process such as a DRBG to remove any bias in the hardware-based system. The tester shall provide a justification that this method ensures that sufficient entropy is provided for all uses of the random number generator. For example, the tester might cite that when …
TB7.2 The tester shall confirm that the process outlined in TB7.1 includes a method to provide entropy (the seed length shall be at least 256 bits) from a hardware-based source, as well as a software-based “whitening” process such as a DRBG to remove any bias in the hardware-based system. The tester shall provide a justification that this method ensures that sufficient entropy is provided for all uses of the random-number generator. For example, the tester might cite that when the …
Modified
p. 65 → 72
TB7.4 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.
TB7.4 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. 65 → 72
TB7.5 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 …
TB7.5 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 …
Modified
p. 66 → 73
• The exclusive use of ISO PIN-block formats 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.
• 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. 66 → 73
Offline devices that do not have the PIN entry device and the ICC reader integrated into the same secure module, and which are using ISO format 0 and are not using a unique key per transaction for the conveyance of the PIN from the point of entry to the ICC reader, must comply with this requirement.
Offline devices that do not have the PIN entry device and the ICC reader integrated into the same secure module, and which are using ISO format 0 and are not using a unique-key-per-transaction for the conveyance of the PIN from the point of entry to the ICC reader, must comply with this requirement.
Modified
p. 66 → 73
TB8.2 The tester shall note whether the POI only supports for online PIN ISO format 4 or ISO format 3 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 B7. If this is the case, no further testing is necessary for this requirement.
TB8.2 The tester shall note whether the POI only supports for online PIN ISO format 4 or 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 B7. If this is the case, no further testing is necessary for this requirement.
Removed
p. 68
A device may include more than one compliant key exchange and storage scheme.
Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support the X9.143 methodology and/or the ISO 20038 methodology. X9.143 are recognized as interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. The X9.143 Key Variant (Calculation) methods are no longer allowed.
Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support the X9.143 methodology and/or the ISO 20038 methodology. X9.143 are recognized as interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. The X9.143 Key Variant (Calculation) methods are no longer allowed.
Modified
p. 68 → 75
POI devices used for IC card acceptance must have chipsets that support ECC and are enabled for use.
POI devices used for IC card acceptance must have chipsets that support Elliptic Curve Cryptography (ECC) and are enabled for use.
Removed
p. 69
This does not imply that the device must enforce X9.143 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.
Modified
p. 69 → 76
• The review by the independent expert must include proof that in the equivalent method the encrypted key and its attributes in the key block have integrity protection such that it is computationally infeasible for the key to be used if the key or its attributes have been modified. Modification includes, but is not limited to:
• The review by the independent expert must include proof that in the equivalent method the encrypted key and its attributes in the key block have integrity protection such that it is computationally impracticable for the key to be used if the key or its attributes have been modified. Modification includes, but is not limited to:
Modified
p. 69 → 77
These methods must be used for key loading whenever a symmetric key⎯e.g., AES or TDES⎯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.
These methods must be supported for key loading whenever a symmetric key⎯e.g., AES or TDES⎯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 cleartext symmetric keys or their components are loaded using standard dual control techniques.
Modified
p. 70 → 78
• Internally generated using a random number generator compliant with B7.
• Internally generated using a random-number generator compliant with Requirement B7.
Modified
p. 70 → 78
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 …
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 …
Removed
p. 71
The software library/chipset used to generate asymmetric keys shall be identified in the Asset Flow Diagram to help safeguard against weak key-generation algorithms.
Modified
p. 71 → 79
TB9.1 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of Unique Key(s) per device.
TB9.1 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of Unique- Key(s)-per-device.
Modified
p. 71 → 79
TB9.2 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.
TB9.2 The minimum key sizes and parameters for algorithm(s) for acquirer-based key-management that must be used for key transport, exchange, or establishment are stated in Appendix E.
Modified
p. 71 → 79
TB9.4 The tester shall determine from vendor documentation all storage and usage locations for each key for example, ROM, external RAM, EPROM, processor chip, etc., and list the details in a key summary table. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 72 → 80
TB9.6 The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 DUKPT or Master/Session key management.
Modified
p. 72 → 80
TB9.7 For systems that support Master/Session key management, the tester shall define what (if any) standard this key management complies with (for example, where the POI implements country specific key management). The tester shall note the name, version, and authoring party of this standard.
Modified
p. 72 → 80
TB9.8 The tester shall review the API guide and operational manual of the POI and confirm that this does not detail any other key-management schemes or methods that the POI may use. If the POI supports extensible key management for use with non-PIN transactions, the tester shall justify what prevents this from being used with PCI-based PINs, using extracts from the vendor documentation to support this claim. The tester shall provide references to all extracts used.
Modified
p. 72 → 80
TB9.9 If the POI implements an ICC reader, the tester shall detail which EMV®-based keys are supported by the firmware. If EMV® functions are provided by the application, the tester shall detail how offline PIN functions are provided, including how the PIN key of the customer ICC card is authenticated. The tester shall justify how the methods used are sufficient to prevent the application from accessing cleartext PINs.
Modified
p. 72 → 80
TB9.10 The tester shall detail any other types of key management or cryptographic keys used by the POI. This should include any keys used for firmware or application authentication, self-testing, boot strapping, remote key injection, local key injection, dual control, etc.
Modified
p. 72 → 80
TB9.11 The tester shall provide a key table for the POI, accurately including all of the keys and key- management methods outlined above. The key table shall include all PIN- or SRED-related keys used in the device, including but not limited to acquirer keys, software authentication keys, and storage of keys within the device. Cryptographic keys used for Open Protocol security must be listed in DTR D5. Keys that are not considered to be PIN or SRED security-related may either …
Modified
p. 73 → 81
Form Factor in which Key is Loaded to Available Key Slots (Registers) Unique per Device/ Acquirer/ Vendor- specific/ Other (describe) Storage Area How Key is Identified by the Device so it is used only as Intended IPEK Initial DUKPT Key TDES 128 Acquirer Clear text from key-injection One Device Designated Key Register DUKPT PEKs (Future Keys Register) PIN encipherment for online PIN TDES 128 Acquirer Derived originally from Up to 21 Future Keys Device Designated Key Register KPT PIN encipherment …
Form Factor in which Key is Loaded to Available Key Slots (Registers) Unique per Device/ Acquirer/ Vendor- specific/ Other (describe) Storage Area How Key is Identified by the Device so it is used only as Intended IPEK Initial DUKPT Key AES 128 Acquirer Cleartext from key-injection One Device Designated Key Register DUKPT PEKs (Future Keys Register) PIN encipherment for online PIN AES 128 Acquirer Derived originally from Up to 21 Future Keys Device Designated Key Register KPT PIN encipherment between …
Modified
p. 73 → 81
TB9.12 Using the key table as a reference, the tester shall note which keys are actively erased by the POI during a tamper event, and which keys are not erased but instead rely upon the erasure of a KEK to prevent their subsequent misuse.
Modified
p. 73 → 81
TB9.13 Using the key table as a reference, the tester shall confirm that all secret and private keys, including those used for account-data encryption, are unique per device, and what method is used to ensure this is the case.
Modified
p. 74 → 82
TB9.15 Using the table of sensitive-information storage from Requirement A4 and the key table above, the tester shall confirm:
Modified
p. 74 → 82
b) Clear-text cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).
b) Cleartext cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).
Modified
p. 74 → 82
TB9.16 The tester shall detail any ways in which the POI generates keys from other keys and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.
Modified
p. 74 → 82
TB9.17 The tester shall note whether the POI generates any keys using an internal random-number generator. The tester shall confirm through source-code review that these keys are generated using the same process validated under Requirement B7. 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. 74 → 82
TB9.18 The tester shall detail the method used by the POI to confirm that no one key can take the same value as any other key within the POI. Through source-code review confirm the following:
Modified
p. 74 → 82
b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to values as defined in TB9.18 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 TB9.19 or they are never output from the POI.
Modified
p. 74 → 82
TB9.19 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. 75 → 83
TB9.21 The tester shall detail the key-block method(s) supported by the POI device, providing details on exact contents of any header, payload, padding, etc. as well as noting which parts are encrypted and which are included in any authentication calculation. If methods defined in the guidance for storage and distribution of symmetric keys using symmetric techniques or for distribution of symmetric keys using asymmetric techniques are not exclusively used, the tester shall cite the publicly available independent expert review to …
Modified
p. 75 → 83
TB9.24 The tester shall confirm that any key-block protection key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-key-block key- management scheme.
Modified
p. 75 → 83
TB9.25 For any methods that rely on the use of full-length TDES 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 …
Modified
p. 75 → 83
TB9.26 The tester shall confirm that if the device supports remote key loading using asymmetric techniques that it utilizes an acceptable method to protect against man-in-the-middle attacks and the hijacking of payment-acceptance devices.
Modified
p. 75 → 84
TB9.28 The tester shall verify an SCRP contains cryptographic keys and functions that can be used to securely provision cryptographic keys and other data to an external system (such as a payment application on a mobile phone). The tester shall detail the relevant key names, function names, and function behavior.
Modified
p. 75 → 84
TB9.29 If the device supports IC card acceptance, the tester shall validate that the device supports ECC as described in the guidance.
Modified
p. 76 → 85
All account data shall be encrypted using only ANSI X9 or ISO-approved encryption algorithms (for example, AES, TDES). The encryption algorithm should use a mode of operation described in ISO/IEC 10116:2006 (or equivalent) and follow secure padding guidelines. Any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format- preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (for example, a standards body) and subjected to independent …
All account data shall be encrypted using only ANSI X9 or ISO-approved encryption algorithms (for example, AES, TDES). The encryption algorithm should use a mode of operation described in ISO/IEC 10116:2006 (or equivalent) and follow secure padding guidelines. Any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format- preserving Feistel-based Encryption Mode (FFX)) SHALL be approved by at least one independent security evaluation organization (for example, a standards body) AND subjected to independent …
Modified
p. 76 → 85
• Where a device implements a “whitelist” function
•i.e., the device can be configured to allow for output of some subset of card data inclear text (e.g., for loyalty or other non-PCI cards)
•i.e., the device can be configured to allow for output of some subset of card data in
• Where a device implements a “whitelist” function
•i.e., the device can be configured to allow for output of some subset of card data in cleartext (e.g., for loyalty or other non-PCI cards)
•i.e., the device can be configured to allow for output of some subset of card data in cleartext (e.g., for loyalty or other non-PCI cards)
Modified
p. 76 → 85
• For devices that allow the enablement (turning on) or the disablement (turning off) of SRED functionality, the enablement must result in the firmware revision number changing and the device providing visual indication of SRED enablement. Disablement must result in the firmware revision number reverting and the device no longer providing visual indication of SRED enablement. The visual indication must not be transient and shall be illustrated by photographic evidence provided in the evaluation report. This is treated as a …
• For devices that allow the enablement (turning on) or the disablement (turning off) of SRED functionality, the enablement must result in the firmware revision number changing and the device providing visual indication of SRED enablement. Disablement must result in the firmware revision number reverting and the device no longer providing visual indication of SRED enablement. The visual indication must not be transient and shall be illustrated by photographic evidence provided in the evaluation report. This is treated as a …
Modified
p. 77 → 86
• The PAN itself. If the PAN can be parsed, the parts of the PAN in clear text must not exceed the maximum truncation requirements of the associated payment brand when considered in totality with all possible firmware output methods.
• The PAN itself. If the PAN can be parsed, the parts of the PAN in cleartext must not exceed the maximum truncation requirements of the associated payment brand when considered in totality with all possible firmware output methods.
Modified
p. 77 → 86
For example, SRED-compliant POI devices are permitted to output clear-text PAN data to authenticated applications, as well as based on firmware authenticated whitelists. To support acceptable truncation formats for each Payment Brand, a POI may pass the clear-text data to an application for processing, or it may perform truncation and/or encryption of parts of the PAN based on firmware-authenticated whitelists. Whitelists allowing for digits of the PAN to be output in clear text when the system is operating in a …
For example, SRED-compliant POI devices are permitted to output cleartext PAN data to authenticated applications, as well as based on firmware authenticated whitelists. To support acceptable truncation formats for each Payment Brand, a POI may pass the cleartext data to an application for processing, or it may perform truncation and/or encryption of parts of the PAN based on firmware-authenticated whitelists. Whitelists allowing for digits of the PAN to be output in cleartext when the system is operating in a format-preserving …
Modified
p. 77 → 86
In addition, the following must be encrypted if it is feasible to associate with the corresponding clear-text PAN:
In addition, the following must be encrypted if it is practical to associate with the corresponding cleartext PAN:
Modified
p. 78 → 87
TB10.4 The tester shall verify that cryptographic keys require compliance with PCI defined criteria for key sizes. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.
TB10.4 The tester shall verify that cryptographic keys require compliance with PCI defined criteria for key sizes. Permitted algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.
Modified
p. 79 → 88
a) The PIN that is submitted by the ICC reader to the IC shall be contained in a PIN block conforming to ISO format 2 PIN block. This applies whether the PIN is submitted in clear text or enciphered using an encipherment key of the IC.
a) The PIN that is submitted by the ICC reader to the IC shall be contained in a PIN block conforming to ISO format 2 PIN block. This applies whether the PIN is submitted in cleartext or enciphered using an encipherment key of the IC.
Modified
p. 80 → 89
e) The application does not provide data for padding of format 3 PIN blocks; this padding is instead generated by the POI random number generator. Use source-code review or other information gathered during B7 to validate.
e) The application does not provide data for padding of format 3 PIN blocks; this padding is instead generated by the POI random-number generator. Use source-code review or other information gathered during B7 to validate.
Modified
p. 81 → 90
The device must enforce that PIN encryption, account-data encryption, data-encryption keys and key-encipherment keys have different values.
The device must enforce that PIN encryption, account-data encryption, data-encryption keys, and key-encipherment keys have different values.
Modified
p. 83 → 92
Cleartext secret and private keys and cleartext PINs must not exist in unprotected environments.
Modified
p. 83 → 92
TB13.1 The tester shall examine any documentation•i.e., the Asset Flow Analysis, API programmer’s guide, specifications, block diagrams, etc.•containing information relating to the output of clear-text keys and the protection of PINs, the encryption of a key or PIN under a key that might itself be disclosed, and the transfer of a key from a high-security component to a lower-security component TB13.2 Referencing the table of sensitive-information storage provided in Requirement A4, the tester shall note whether cryptographic keys, customer PINs, …
TB13.1 The tester shall examine any documentation•i.e., the Asset Flow Diagram, API programmer’s guide, specifications, block diagrams, etc.•containing information relating to the output of cleartext keys and the protection of PINs, the encryption of a key or PIN under a key that might itself be disclosed, and the transfer of a key from a high-security component to a lower-security component TB13.2 Referencing the table of sensitive-information storage provided in Requirement A4, the tester shall note whether cryptographic keys, customer PINs, …
Modified
p. 85 → 94
A8 applies to any components or paths containing clear-text display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.
Requirement A8 applies to any components or paths containing cleartext display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.
Modified
p. 85 → 94
B15 applies to both acquirer and vendor-controlled prompts that are updatable.
B15 applies to all prompts that are updatable.
Modified
p. 85 → 94
Prompts stored inside the cryptographic unit are physically protected according to Requirement A8.
Prompts stored inside the cryptographic unit must be physically protected according to Requirement A8.
Modified
p. 85 → 94
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).
If the device model is to be listed as supporting more than one type of prompt type, such as acquirer- controlled or vendor-controlled, there must be a differentiation so acquirers/merchants can distinguish between the three (for example, different hardware and/or firmware versions). Devices that may optionally allow for the display to be controlled by third-party applications must also differentiate between devices that provide this support and those that do not.
Modified
p. 85 → 94
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 B15. The description must include an example of a specific, existing SCD that can be purchased and used to comply with B15. The PED must have an API that is compatible …
Dual control must be enforced by a secure cryptographic device (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 B15. The description must include an example of a specific, existing SCD that can be purchased and used to comply with B15. The PED must have an API …
Modified
p. 88 → 97
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 within B1.
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 within Requirement B1.
Modified
p. 88 → 97
• The application can only work on the keys it alone manages and cannot affect or see any other keys. The application must not handle PIN or SRED security-related clear-text keys or key components.
• The application can only work on the keys it alone manages and cannot affect or see any other keys. The application must not handle PIN or SRED security-related cleartext keys or key components.
Modified
p. 88 → 97
• Applications must never process or have access to clear-text PINs or clear-text passwords/authentication codes.
• Applications must never process or have access to cleartext PINs or cleartext passwords/authentication codes.
Modified
p. 88 → 97
It is acceptable for applications to be able to initiate changes to security functions, providing the firmware fully implements the authentication mechanisms. When password-based authentication is used, the firmware must manage the password entry and comparison.
It is acceptable for applications to be able to initiate changes to security functions, provided the firmware fully implements the authentication mechanisms. When password-based authentication is used, the firmware must manage the password entry and comparison.
Modified
p. 88 → 97
• PIN- or SRED-related keys Sensitive functions include:
• PIN- or SRED-related keys
Modified
p. 89 → 98
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.
The vendor must provide clear security guidance for the development and implementation of applications that are able to access account data (i.e., where access is not prevented through the use of controls assessed under Requirement B2.3). 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. 90 → 99
TB16.10 If the device allows customers or integrators to install additional applications, the tester shall verify that the POI’s design prevents the embedded application from:
TB16.10 If the device allows for the installation of additional non-firmware code, the tester shall verify that the POI’s design prevents this non-firmware code from:
Modified
p. 90 → 99
Additionally, the embedded application is separated from the approved device’s functionality by an internal security boundary that prevents embedded applications from obtaining any elevated privilege or access to any data belonging to other embedded or host-side applications.
Additionally, any non-firmware code is separated from the approved device’s functionality (that is, the firmware) by an internal security boundary that prevents embedded applications from obtaining any elevated privilege or access to any data belonging to other embedded or host- side applications.
Modified
p. 90 → 99
TB16.11 The tester shall verify that clear security guidance for the development and implementation of the aforementioned additional applications is included in the security policy cited in B20. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized.
TB16.11 The tester shall verify that clear security guidance for the development and implementation of the aforementioned additional applications is included in the security policy cited in B20. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This does not apply to third-party applications.
Modified
p. 90 → 99
TB16.12 Using the Asset Flow Analysis, the tester shall describe the path of clear-text PINs from entry through to encryption or transfer to an IC card. Justification must be provided as to why applications cannot access buffers used to store clear-text PINs.
TB16.12 The tester shall describe the path of cleartext PINs from entry through to encryption or transfer to an IC card. Justification must be provided as to why applications cannot access buffers used to store cleartext PINs. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 90 → 99
TB16.13 The tester shall describe the software module/s handling PIN- or SRED-related cryptographic keys. Memory used to persistently or temporarily store clear-text keys must be separated from the application.
TB16.13 The tester shall describe the software module/s handling PIN- or SRED-related cryptographic keys. Memory used to persistently or temporarily store cleartext keys must be separated from the application.
Modified
p. 90 → 99
TB16.14 The tester shall review the API guide and source code provided by the vendor to ensure that no clear-text sensitive data is transferred between firmware and application. Sensitive data includes clear-text PINs, clear-text keys, clear-text key components or clear-text passwords/authentication codes.
TB16.14 The tester shall review the API guide and source code provided by the vendor to ensure that no cleartext sensitive data is transferred between firmware and application. Sensitive data includes cleartext PINs, cleartext keys, cleartext key components or cleartext passwords/authentication codes.
Removed
p. 91
If software security domains are supported, the vendor shall perform an asset flow analysis as described in Appendix G It shall at least identify all external interfaces of the device and describe the location and flow of all assets and asset containers in all modes of operation, including power-down and device boot, and for all kinds of transactions.
TB16.1.4 The tester shall examine any relevant documentation to check whether the asset flow analysis covers all transactions, sensitive services, and operational modes including, but not limited to, key loading, software update, and device boot.
TB16.1.4 The tester shall examine any relevant documentation to check whether the asset flow analysis covers all transactions, sensitive services, and operational modes including, but not limited to, key loading, software update, and device boot.
Modified
p. 91 → 100
The laboratory shall confirm how each domain is mutually segregated from other domains and how the corresponding mechanisms are configured and enforced.
Modified
p. 91 → 100
TB16.1.4 The tester shall examine the boot procedure to verify that all loaders, OS layers, etc., are not tagged as a lower domain than the code that they load or maintain.
Modified
p. 92 → 101
• 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.
• That it is not possible for applications to be influenced by logical anomalies that could result in cleartext data being outputted while the terminal is in encrypting mode.
Modified
p. 92 → 101
Where the POI firmware implements SRED functions, guidance must be provided on how to correctly utilize these functions. This includes application implementations of manual PAN entry where no more than one clear-text PAN digit may be displayed at a time, and a PAN digit displayed during entry must be obfuscated prior to the display of the next digit.
Where the POI firmware implements SRED functions, guidance must be provided on how to correctly utilize these functions. This includes application implementations of manual PAN entry where no more than one cleartext PAN digit may be displayed at a time, and a PAN digit displayed during entry must be obfuscated prior to the display of the next digit.
Modified
p. 92 → 101
TB16.2.4 Where SRED features are implemented, the tester shall examine any relevant documentation to ensure that it includes guidance for the correct use of the SRED APIs. The guidance must also outline that PAN digit entry functions provided by an application cannot display more than one clear-text digit at a time, and that the displayed PAN digit is obfuscated prior to the entry of the next digit.
TB16.2.4 Where SRED features are implemented, the tester shall examine any relevant documentation to ensure that it includes guidance for the correct use of the SRED APIs. The guidance must also outline that PAN digit entry functions provided by an application cannot display more than one cleartext digit at a time, and that the displayed PAN digit is obfuscated prior to the entry of the next digit.
Modified
p. 93 → 102
The intended operation is considered as the functionality relevant to D2 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 intended operation is considered as the functionality relevant to Requirement D2 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. 93 → 102
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to clear-text 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 logical and physical requirements.
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to cleartext 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 logical and physical requirements.
Modified
p. 93 → 102
TB17.2 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.
TB17.2 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 practical.
Modified
p. 94 → 103
TB17.9 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. 95 → 104
a) Provides for a single master key (either symmetric or asymmetric) for all hierarchies into which a PIN key may be loaded, and that this master key is the only key that can be loaded into the POI in clear text.
a) Provides for a single master key (either symmetric or asymmetric) for all hierarchies into which a PIN key may be loaded, and that this master key is the only key that can be loaded into the POI in cleartext.
Removed
p. 97
TB20.3 The tester shall confirm that the security policy contains references to any software- development guidance required for compliance, if applicable, with the Open Protocol and SRED-relevant 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.
Modified
p. 97 → 106
• General Description (DTRs B20.1
•B20.6)
•
• General Description (DTRs B20.1
• B20.5)
• B20.5)
Modified
p. 97 → 106
• Installation and Guidance (DTRs B20.7
•B20.16)
•
• Installation and Guidance (DTRs B20.6
• B20.15)
• B20.15)
Modified
p. 97 → 106
• Operation and Maintenance (DTRs B20.17
• B20.24)
• B20.24)
• Operation and Maintenance (DTRs B20.16
• B20.24)
• B20.24)
Modified
p. 97 → 106
• Security (DTRs B20.25
•B20.33) This is the minimum information that must be presented. Additional information may be presented.
•
• Security (DTRs B20.25
• B20.35) This is the minimum information that must be presented. Additional information may be presented.
• B20.35) This is the minimum information that must be presented. Additional information may be presented.
Modified
p. 97 → 106
TB20.1 The tester shall examine the security policy to verify that the device is properly identified. Model name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes actual (not computer-generated or similar) pictures of the device, and how to validate the hardware, firmware, and application versions and the exact approval class and use case of the device including the specific POI Security Requirements version …
TB20.1 The tester shall examine the security policy to verify that the device is properly identified. Model name, hardware version, and software version information shall be included in the identification of the approved device. The tester shall validate that the security policy includes actual (not computer-generated or similar) pictures of the device, and how to validate the hardware, firmware, and application versions and the exact approval class and use case of the device including the specific POI Security Requirements version …
Removed
p. 98
TB20.5 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.
Modified
p. 98 → 107
TB20.5 The tester shall confirm the security policy defines and documents all hardware and firmware version options, both security and non-security relevant. Security-relevant options must be exhaustively defined and documented. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
Modified
p. 98 → 107
TB20.6 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.
Modified
p. 98 → 107
TB20.7 The tester shall confirm that the security policy includes all configuration settings necessary to meet the security requirements defined in this document.
Modified
p. 98 → 107
TB20.8 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. 98 → 107
TB20.9 The tester shall confirm that the security policy contains any installation or user guidance as required by the laboratory for compliance with the PCI PTS requirements. Examples of such required guidance, includes but is not limited to:
Modified
p. 98 → 107
TB20.10 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.
Modified
p. 98 → 107
•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 the connectivity
•the tester shall confirm that the security policy states how the device is compliant to PCI PTS POI Evaluation Technical FAQ
TB20.12 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 the connectivity
•the tester shall confirm that the security policy states how the device is compliant to PCI PTS POI Evaluation Technical FAQ regarding this in the General Questions section.
•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 the connectivity
•the tester shall confirm that the security policy states how the device is compliant to PCI PTS POI Evaluation Technical FAQ regarding this in the General Questions section.
Modified
p. 98 → 107
TB20.13 The tester shall confirm that for any handheld PIN entry device, if the device does not support SRED encryption, the security policy must clearly state that the system cannot be implemented to connect to a tablet or mobile phone, and any such use will violate the approval of the device.
Modified
p. 98 → 107
TB20.14 The tester shall confirm that for any device having beacons, the security policy states how those are compliant to PCI PTS POI Evaluation Technical FAQ #14.
Modified
p. 99 → 108
TB20.17 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.
Modified
p. 99 → 108
TB20.18 For privacy shielding the tester shall perform the following tests:
Modified
p. 99 → 108
TB20.19 The tester shall confirm that the security policy contains information on all ways 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). This shall include an illustration to show the user an actual tamper-response display message and accurate information on any other tamper-responsive behaviors.
Modified
p. 99 → 108
TB20.20 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. 99 → 108
TB20.21 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. 99 → 108
TB20.22 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. 99 → 108
TB20.23 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 the Open Protocols requirements.
Modified
p. 99 → 108
TB20.24 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR B1, for any device where the required memory re-initialization (security) cycle lasts longer than 24 hours. Specifically, how the firmware of the device during the cycles’ adjustment processes does not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours).
Modified
p. 100 → 109
TB20.28 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 ofclear-text account data using techniques such as whitelisting.
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of
TB20.28 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 cleartext account data using techniques such as whitelisting.
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of cleartext account data using techniques such as whitelisting.
Modified
p. 100 → 109
• Clear-text key components through the keypad (TB5.5 a),
• Cleartext key components through the keypad (TB5.5 a),
Modified
p. 100 → 109
• Clear-text key injection (as per TB5.5 b),
• Cleartext key injection (as per TB5.5 b),
Modified
p. 100 → 109
TB20.30 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 B15, or any mechanisms used for authenticating application code as assessed under Requirements B2.1.
TB20.30 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 B15, or any mechanisms used for authenticating application code as assessed under Requirements B2.1 and B2.2.
Modified
p. 100 → 109
TB20.32 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 practical to determine the key by exhaustive attack elapses, as defined in NIST SP 800-57-1.
Modified
p. 100 → 110
TB20.34 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR D12 for any device implementing Bluetooth Low Energy (BLE). Specifically, implementations must use version 4.2 or higher and use LE Security Mode 1 Level 4 (Secure Connections) only. Just Works cannot be used at any time, except as delineated for SCRPs and SCRs used exclusively for a Software-Based PIN Entry on COTS/Mobile Payments on COTS (SPoC/MPoC) solution. The device …
Modified
p. 101 → 111
• 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.
• 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. 101 → 111
• A clear-text 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 clear-text to the IC card) in accordance with ISO 9564.
• A cleartext 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 cleartext to the IC card) in accordance with ISO 9564.
Modified
p. 101 → 111
• A clear-text PIN, encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the clear-text PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.
• A cleartext PIN, encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the cleartext PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.
Modified
p. 101 → 111
SCRPs with ICCRs shall support both enciphered and clear-text PIN for offline PIN authentication.
SCRPs with ICCRs shall support enciphered and should support cleartext PIN for offline PIN authentication.
Modified
p. 101 → 111
B21 requires that the following be met:
Requirement B21 requires that the following be met:
Modified
p. 101 → 111
• A clear-text 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 cleartext 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. 101 → 111
• In order to receive an approval for offline PIN entry, a device must be capable of supporting both clear-text and enciphered PINs.
• In order to receive an approval for offline PIN entry, a device must be capable of supporting enciphered PINs.
Modified
p. 102 → 112
TB21.2 The tester shall confirm from the vendor documentation that the POI supports both clear-text 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 clear text.
TB21.2 The tester shall confirm from the vendor documentation that the POI supports encrypted offline PIN, and if it also supports cleartext 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 cleartext.
Modified
p. 102 → 112
TB21.8 The tester shall perform at least two test transactions with a card that requires a clear-text PIN.
TB21.8 The tester shall perform at least two test transactions (with different PIN values) with a card that requires a cleartext PIN. The tester shall capture the data sent to the customer card in each case and note whether the PIN is correctly formatted as an ISO 9564 format 2 PIN block.
Modified
p. 102 → 112
TB21.10 The tester shall perform four offline transactions and monitor the value of the unpredictable number (UN) provided by the terminal in each case. Through observation of this value, the tester shall confirm that the unpredictable number is not implemented as a simple counter or some other easily guessable value. The tester shall also review the source code used to generate the UN and confirm that the terminal uses the random number generator of the terminal, evaluated under Requirement B7, …
TB21.10 The tester shall perform four offline transactions and monitor the value of the unpredictable number (UN) provided by the terminal in each case. Through observation of this value, the tester shall confirm that the unpredictable number is not implemented as a simple counter or some other easily guessable value. The tester shall also review the source code used to generate the UN and confirm that the terminal uses the random-number generator of the terminal, evaluated under Requirement B7, to …
Modified
p. 103 → 113
Requirements B2.1, B2.3, and B2 address application loads and firmware, application, and configuration updates. B22 is intended to address other types of administration activities, such as those more prevalent with unattended devices. In any case, unless there is not any impact (for example, the load itself is cryptographically authenticated at the target), a secure session should be established (for example, TLS) for those communications.
Modified
p. 104 → 114
If the implementation permits truncation methods that don't conform to the brand guidance, a 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 if the vendor is required to output more PAN data than permitted by the card brands, it must demonstrate that the probability of PAN recovery is equivalent to …
Modified
p. 104 → 114
Encrypting mode is defined to be when the device’s encryption of account-data functionality is enabled and operational. Changing between modes is considered a sensitive service as stated in B5 and B6 and therefore requires that authentication use dual-control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data.
Encrypting mode is defined to be when the device’s encryption of account-data functionality is enabled and operational. Changing between modes is considered a sensitive service as stated in Requirements B5 and B6 and therefore requires that authentication use dual-control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data.
Modified
p. 106 → 116
The device shall only release clear-text account data to authenticated applications. The device must never release any other clear-text data such as cryptographic keys.
The device shall only release cleartext account data to authenticated applications. The device must never release any other cleartext data such as cryptographic keys, or cleartext PINs.
Modified
p. 106 → 116
TB23.1.1 The tester shall verify that the vendor has identified all data that is provided to authenticated applications.
TB23.1.1 The tester shall verify that cleartext account data is only able to be released to applications authenticated under the requirements of B2.1.
Removed
p. 107
• Input to the hash function must use a salt with minimum length of 64 bits.
• The salt is kept secret and appropriately protected.
• Disclosure of the salt cannot occur without requiring an attack potential of at least 16 per device for identification and initial exploitation with a minimum of 8 for initial exploitation, as defined in Appendix B.
A cryptographic salt comprises random bits that can be input into a cryptographic function. Random bits shall be generated such that probability of the same random bits being output is statistically insignificant. A known salt value may compromise the effectiveness of the cryptographic function.
The salt may be unique per transaction, unique per a group of transactions, unique per device, or unique per merchant.
• 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 …
• The salt is kept secret and appropriately protected.
• Disclosure of the salt cannot occur without requiring an attack potential of at least 16 per device for identification and initial exploitation with a minimum of 8 for initial exploitation, as defined in Appendix B.
A cryptographic salt comprises random bits that can be input into a cryptographic function. Random bits shall be generated such that probability of the same random bits being output is statistically insignificant. A known salt value may compromise the effectiveness of the cryptographic function.
The salt may be unique per transaction, unique per a group of transactions, unique per device, or unique per merchant.
• 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 …
Modified
p. 107 → 117
The cryptographic key used for a keyed-hash function must be, at a minimum, unique per device. For a given device, it may be unique per transaction. Keys that are unique per transaction or otherwise unique per device must be generated by the transaction device.
Modified
p. 107 → 117
TB24.2 Where a hash function is used to generate surrogate PAN values:
TB24.2 Where a hash function is used to generate surrogate PAN values the tester shall verify:
Modified
p. 109 → 118
• Use of a unique-key-per-transaction technique. (Prevents the attack.)
• Use of a unique-key, and if applicable initial vector, per-transaction technique. (Prevents the attack.)
Modified
p. 109 → 118
• 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.
• Limiting the rate at which the device will encrypt PANs with a non-unique key without random padding or a random initialization vector, or if applicable, a sufficiently variable tweak (block ciphers used with FPE). (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. 109 → 118
TB25.1 The tester shall perform functional testing to verify the device characteristics regarding B25.
TB25.1 The tester shall perform functional testing to verify the device characteristics regarding Requirement B25.
Modified
p. 110 → 120
The SCRP may continue to provide functions necessary for the resumption of payment acceptance and processing by the SCRP, even when an enablement token is not provided within the acceptable time period. Examples of functions permitted in the absence of an enablement token may include the ability to establish a secure channel with the external system interfacing to the SCRP (such as a payment application on a mobile phone), providing data required for the attestation of the SCRP device, and …
The SCRP may continue to provide functions necessary for the resumption of payment acceptance and processing by the SCRP, even when an enablement token is not provided within the acceptable time period. Examples of functions permitted in the absence of an enablement token may include the ability to establish a secure channel with the external system interfacing to the SCRP (such as a payment application on a mobile phone), providing data required for the attestation of the SCRP device, and …
Modified
p. 112 → 122
Recessed keypads should be avoided when possible, as it increases the risk of successfully implanting an overlay and yet remain unnoticed for an extended period of time. If recessed area(s) are used, other mechanisms must be implemented to deter overlay placement.
Recessed keypads should be avoided, when possible, as it increases the risk of successfully implanting an overlay and yet remain unnoticed for an extended period of time. If recessed area(s) are used, other mechanisms must be implemented to deter overlay placement.
Modified
p. 115 → 125
TC2.3.3 If the vendor does not provide with the final PIN-enabled payment application, the tester shall verify that the vendor provides third party developers with the appropriate documentation on how to implement the transaction flow, such as it is reasonably obvious for a cardholder to distinguish whether or not he or she is about to enter his or her PIN on the device.
TC2.3.3 If the vendor does not provide with the final PIN-enabled payment application, the tester shall verify that the vendor provides third-party developers with the appropriate documentation on how to implement the transaction flow, such as it is reasonably obvious for a cardholder to distinguish whether or not they are about to enter their PIN on the device.
Modified
p. 116 → 126
The alteration of the correspondence between the display messages visible to the cardholder and the operating state of the PIN entry device cannot occur without requiring an attack potential of at least 18 per POI for identification and initial exploitation with a minimum of 9 for initial exploitation, as defined in Appendix B.
The alteration of the correspondence between the display messages visible to the cardholder and the operating state of the PIN entry device cannot occur without requiring an attack potential of at least 18 per POI for identification and initial exploitation, with a minimum of 9 for initial exploitation, as defined in Appendix B.
Modified
p. 116 → 126
A8 applies to any components or paths containing clear-text display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.
A8 applies to any components or paths containing cleartext display signals between the cryptographic processor and display unit. Requirement B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.
Modified
p. 118 → 128
Devices implementing at the same time a touchscreen for PIN entry and a separate keypad (for example, to meet visual impaired regulations) must meet this requirement.
Devices implementing at the same time a touchscreen for PIN entry and a separate keypad (for example, to meet visual impairment regulations) must meet this requirement.
Modified
p. 118 → 128
TC2.5.2 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 touchscreen), 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 A8, …
TC2.5.2 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 touchscreen), 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 Requirements A8, …
Removed
p. 119
The tester is required to verify the claims of the vendor as described in the asset flow to ensure that the vendor listing of physical and logical interfaces in complete. This requires the tester to both identify physical interfaces through analysis of the design, as well as verify the presence of logical interfaces through methods such as passive monitoring of communications, port/protocol scans, and code review.
Modified
p. 119 → 129
The objective of this section is to identify all physical interfaces and the corresponding logical protocols that are supported by the device. This is not restricted to only those declared in the Open Protocols − Protocols Declaration Form. 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.
The objective of this section is to identify all external physical interfaces and the corresponding logical protocols that are supported by the device. This is not restricted to only those declared in the Open Protocols Module − Protocol Declaration Form. 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 the documentation.
Modified
p. 119 → 129
Interfaces, which provide for communications, such as but not limited to:
Interfaces, which provide for communications such as, but not limited to:
Modified
p. 119 → 129
• Cellular (GPRS and CDMA) Protocols, such as: but not limited to:
• Cellular (GPRS and CDMA) Protocols, such as, but not limited to:
Modified
p. 119 → 129
• 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.
• TLS1.2 or above* The vendor must also identify where it derives its code that is used to implement protocols, as well as document all protocols and which physical interfaces they apply to.
Modified
p. 119 → 129
• If the module is under the control of the firmware and runs in the same process 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 the module is under the control of the firmware and runs in the same process space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for the wireless technologies listed previously) is provided for and that secure communication is enforced by the interface.
Removed
p. 120
Note: If the device implements an IP stack, the device must support TLS 1.2 or higher.
TD1.2 The tester shall examine any relevant documentation distributed by the vendor such as schematics, data sheets, asset flow diagrams, 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 it derives its 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 be specified.
TD1.2 The tester shall examine any relevant documentation distributed by the vendor such as schematics, data sheets, asset flow diagrams, 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 it derives its 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 be specified.
Modified
p. 120 → 130
TD1.1 The tester shall examine the vendor’s asset flow diagrams to verify that they accurately portray all interfaces and protocols present on the device.
TD1.1 The tester shall describe in the Asset Flow Diagrams all interfaces and protocols present on the device.
Modified
p. 120 → 130
Example Protocol Table Component Handling the Physical Interface 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 TD1.4 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 …
Example Protocol Table Component Handling the Physical Interface Source Code Security Protocol Additional Information IP (General) Application Processor Linux (5.15.133) TLS 1.3 Application Processor OpenSSL (3.2.0) GPRS GPRS Modem Modem vendor IP (GPRS) GPRS Modem Modem vendor MSD Application Processor USB Linux (5.15.133) HID Application Processor USB Linux (5.15.133) TD1.4 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 …
Modified
p. 121 → 132
Vendors should provide software-design rules and specifications to support answers. .
Vendors should provide software-design rules and specifications to support answers.
Modified
p. 121 → 132
All interfaces and associated communication methods of the device must be assessed to ensure that no interface can be abused or used as an attack vector. This includes the tester enumerating and assessing all logical and physical interfaces regardless of intended usage, without exception. Specifically, this includes any physical, logical, or application interface that is executed within the POI device with sufficient privilege to allow for direct interface to sensitive assets within the POI (should that protocol be compromised in …
All interfaces and associated communication methods of the device must be assessed to ensure that no interface can be abused or used as an attack vector. This includes the tester enumerating and assessing all logical and physical interfaces regardless of intended usage, without exception. Specifically, this includes any physical, logical, or application interface that is executed within the POI device with sufficient privilege to allow for direct interface to sensitive assets within the POI (should that protocol be compromised in …
Modified
p. 121 → 132
• Source code reviews targeting specific relevant security-critical functionalities.
• Source-code reviews targeting specific relevant security-critical functionalities.
Modified
p. 121 → 132
• Penetration testing to validate the robustness of the device to protect against feasible attacks by addressing known attack methods. For example (but not restricted to) fuzzing, using appropriate tools and techniques.
• Penetration testing to validate the robustness of the device to protect against practical attacks by addressing known attack methods. For example (but not restricted to) fuzzing, using appropriate tools and techniques.
Modified
p. 122 → 133
TD2.5 The tester shall enumerate all logical and physical interfaces provided by the POI. For example, the tester shall include physical interfaces such as USB input, serial input, IC interface, TCP/IP interface, etc., as well as API interfaces provided to applications that may execute on the POI.
TD2.5 The tester shall enumerate all logical and physical interfaces provided by the POI. For example, the tester shall include physical interfaces such as USB input, serial input, IC interface, TCP/IP interface, etc., as well as any services or API interfaces provided to applications that may execute on the POI. For example, a physical USB interface must be defined by the classes or services it supports.
Modified
p. 122 → 133
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).
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).
Modified
p. 126 → 137
a) The key-management guidance is at the disposal of internal users and/or of application developers, system integrators, and end-users of the device.
a) The key-management guidance is at the disposal of internal users and/or application developers, system integrators, and end-users of the device.
Modified
p. 126 → 137
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.
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. 126 → 137
Note: This does not supersede any criteria in B9 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.
Note: This does not supersede any criteria in Requirement B9 but rather is required for any device implementing protocols evaluated under Open Protocols•i.e., key-related Security Protocols, such as TLS, SSH, VPN technologies.
Modified
p. 126 → 137
• Cover all key properties, minimally type and length⎯e.g., TDES 112-bits;
• Cover all key properties, minimally type and length⎯e.g., AES 128-bits;
Modified
p. 128 → 139
For D7, D8, and D9, the minimum requirements for cryptographic algorithms used to provide security are specified in DTR B9. Only TDES, RSA, ECC, DSA, and AES are acceptable for encryption or signing operations. SHA256 or above may also be used for hashing purposes. See Appendix E.
For D7, D8, and D9, the minimum requirements for cryptographic algorithms used to provide security are specified in DTR B9. Only TDES, RSA, ECC, and AES are acceptable for encryption or signing operations. SHA256 or above may also be used for hashing purposes. See Appendix E.
Modified
p. 128 → 139
TD6.3 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.
TD6.3 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, including source-code review, 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. 129 → 140
TD7.2 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 under …
•including testing keys and/or certificates and tools to load them on the device
•to access and use the interfaces under …
TD7.2 The tester shall perform source-code review and other tests determined as 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 their own judgment in determining the additional 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 …
•including testing keys and/or certificates and tools to load them on the device
•to access …
Modified
p. 130 → 141
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384, or SHA-512.
Modified
p. 130 → 141
c) Examples of appropriate algorithms and minimum key sizes are stated in Appendix E of the
c) Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.
Modified
p. 130 → 141
TD8.3 The tester shall perform any additional tests necessary to validate the device’s implementation of security protocol is sufficiently able to provide integrity. 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. The tester shall summarize the testing and responses for each interface tested.
TD8.3 The tester shall perform any additional tests, including source-code review, necessary to validate the device’s implementation of security protocol is sufficiently able to provide integrity. 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. The tester shall summarize the testing and responses for each interface tested.
Modified
p. 131 → 142
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384, or SHA-512.
Modified
p. 131 → 142
e) The device’s trusted root certificate store shall contain only public key certificates from trusted CA's or else self-signed certificates verified by the acquirer.
e) The device’s trusted root certificate store shall contain only public-key certificates from trusted CAs or else self-signed certificates verified by the acquirer.
Modified
p. 131 → 142
TD9.4 The tester shall perform any additional tests necessary to validate the device’s implementation of the security protocol is able to provide authentication. 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.
TD9.4 The tester shall perform any additional tests, including source-code review, necessary to validate the device’s implementation of the security protocol is able to provide authentication. 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. 132 → 143
TD10.3 The tester shall perform any additional tests necessary to validate the device’s implementation of security protocol is able to provide exception handling and replay detection. 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. The tester shall summarize the testing and responses for each interface tested.
TD10.3 The tester shall perform any additional tests, including source-code review, necessary to validate the device’s implementation of security protocol is able to provide exception handling and replay detection. 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. The tester shall summarize the testing and responses for …
Modified
p. 134 → 145
Note: If Bluetooth is used, D14 may alternatively be used.
Note: If Bluetooth is used, Requirement D14 may alternatively be used.
Modified
p. 134 → 145
Bluetooth implementations that have Basic Rate (BR), Enhanced Data Rate (EDR), or High Speed (HS) features must use Bluetooth 4.1 or higher. Security Mode 4, Level 4 must be used. This requires Secure Connections, which involves authenticated pairing and encryption using 128-bit strength keys generated by means of FIPS-approved Advanced Encryption Standard (AES) encryption.
Modified
p. 134 → 145
Bluetooth Low Energy (BLE) implementations must use version 4.2 or higher. BLE must use LE Security Mode 1 Level 4 (Secure Connections) only⎯Just Works cannot be used at any time. The device must not support or allow for the use of insecure communication options such as, but not limited to, LE Security Mode 2, and levels 1, 2 and 3 of LE Security Mode 1 and the “Just Works” secure pairing option of Security Mode 1. This must be documented …
Modified
p. 134 → 145
BLE implementations in SCRPs, regardless of Bluetooth version, for use in SPoC/MPoC Solutions may use unauthenticated pairing (Just Works) provided compensating controls to mitigate against eavesdropping and MITM attacks are in place as part of the Solution. These controls shall be validated during testing of the SPoC/MPoC solution. SCRPs that allow either the use of Just Works for pairing or do not exclusively implement Secure Connections are not approved for use outside of a SPoC/MPoC Solution.
Bluetooth BR/EDR/HS or BLE implementations in SCRPs or SCRs exclusively used in SPoC/MPoC solutions, regardless of Bluetooth version, may use unauthenticated pairing (Just Works), provided compensating controls to mitigate against eavesdropping and MITM attacks are in place as part of the solution. These controls shall be validated during testing of the SPoC/MPoC solution. SCRPs or SCRs that allow either the use of Just Works for pairing or do not exclusively implement Secure Connections are not approved for use outside of …
Modified
p. 134 → 145
TD12.3 The tester shall set up the device and confirm that the connections as specified above are operable.
TD12.3 The tester shall set up the device and confirm that the connections as specified above are operable. The tester shall review source code where necessary to verify the configuration.
Modified
p. 134 → 145
TD12.4 The tester shall try to attempt to connect to the device using non-supported modes, including no encryption, Just Works, or BLE 4.0 Legacy Pairing.
TD12.4 The tester shall try to attempt to connect to the device using non-supported modes, including no encryption, Just Works, or BLE 4.0 Legacy Pairing. The tester shall review source code where necessary to verify the configuration.
Modified
p. 135 → 147
Note: If Wi-Fi is used, D14 may alternatively be used.
Note: If Wi-Fi is used, Requirement D14 may alternatively be used.
Modified
p. 135 → 147
If a Wi-Fi interface is used, the Wi-Fi interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. Security must be enabled. WEP cannot be used or configured at any time, and WPA2 and/or WPA3 must be supported. If passkey is used, it must not be a vendor default. The evaluator must validate that default values can be changed on the target of evaluation.
If a Wi-Fi interface is used, the Wi-Fi interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. Security must be enabled, including authentication. WEP cannot be used or configured at any time, and WPA2 and/or WPA3 must be supported. If a password is used, it must not be a vendor default and must be a minimum of 12 characters. The evaluator must validate that default values can be changed on the …
Modified
p. 135 → 147
TD13.1 The tester shall describe the different protocols and modes supported by the device TD13.2 Using a test system, the tester will confirm that the device does not support WEP.
TD13.1 The tester shall describe the different protocols and modes supported by the device.
Modified
p. 135 → 147
TD13.4 The tester shall describe how the password is entered and whether any default values are handled.
Modified
p. 136 → 148
Note: Where the applicable security requirements D12 and/or D13 for Bluetooth or Wi-Fi are not met, D14 must be used.
Note: Where the applicable security Requirements D12 and/or D13 for Bluetooth or Wi-Fi are not met, D14 must be used.
Modified
p. 136 → 148
Interfaces in scope for this requirement must be protected using cryptography and may be required to be additionally isolated using hardware separation, depending on how the interfaces are used and what data is processed. Systems that manage only PAN data or are only able to obtain card data from a payment instrument that provides its own authentication data (such as an EMV payment card) may implement cryptographic protection only for an insecure interface.
Interfaces in scope for this requirement must be protected using cryptography and may be required to be additionally isolated using hardware separation, depending on how the interfaces are used and what data is processed. Systems that manage only PAN data or are only able to obtain card data from a payment instrument that provides its own authentication data (such as an EMV® payment card) may implement cryptographic protection only for an insecure interface.
Modified
p. 136 → 148
Insecure interfaces are assumed to be open to compromise; therefore, measures must be implemented to ensure they are not able to expose clear-text sensitive data and that the execution environments in which that data is processed are protected. It is not sufficient to ensure that data transmitted across such an interface is simply encrypted if there are not also authentication controls to prevent injection of malicious data.
Insecure interfaces are assumed to be open to compromise; therefore, measures must be implemented to ensure they are not able to expose cleartext sensitive data and that the execution environments in which that data is processed are protected. It is not sufficient to ensure that data transmitted across such an interface is simply encrypted if there are not also authentication controls to prevent injection of malicious data.
Modified
p. 138 → 150
TD14.8 The tester shall confirm how the cryptographic controls ensure that all connections across the wireless interfaces are cryptographically authenticated. This authentication must cover all data transmissions and allow for the authentication of the receiving end point in any connection that negotiates keys as part of the initiation of the connection (such as TLS).
TD14.8 The tester shall confirm how the cryptographic controls ensure that all connections across the wireless interfaces are cryptographically authenticated. This authentication must cover all data transmissions and allow for the authentication of the receiving endpoint in any connection that negotiates keys as part of the initiation of the connection (such as TLS).
Modified
p. 138 → 150
TD14.9 The tester shall confirm if the POI allows for the input or processing of customer PINs or card data. Where this is the case, the tester shall detail how the wireless interfaces are physically isolated from the card data and PIN processing elements. Use of a separate processor for implementing the interface is an example of acceptable physical isolation TD14.10 The tester shall confirm that systems that allow for the input or processing of customer PINs or card data …
TD14.9 The tester shall confirm if the POI allows for the input or processing of customer PINs or card data. Where this is the case, the tester shall detail how the wireless interfaces are physically isolated from the card data and PIN processing elements. Use of a separate processor for implementing the interface is an example of acceptable physical isolation.
Modified
p. 139 → 151
• Evidence of existence
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company thatimplements the requirement.
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that
• Evidence of existence
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implement the requirement.
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implement the requirement.
Modified
p. 139 → 151
DTR E1 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. 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. Approval of delta submissions is contingent on evidence of …
DTR E1 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. 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.
Modified
p. 147 → 159
TE6.3 The tester shall examine a sample of documentation for post-production storage, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed.
TE6.3 The tester shall examine a sample of documentation for post-production storage, including:
Removed
p. 148
Authentication by secret information is mandatory in POI v6.
Modified
p. 148 → 160
TE7.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that 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.
TE7.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that 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 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.
Modified
p. 149 → 161
TE8.2 The tester shall examine a sample of approved documentation for component control during design and development, including user documentation, and component validation procedures to ensure procedures are followed.
TE8.2 The tester shall examine a sample of approved documentation for component control during design and development, including user documentation and component validation procedures to ensure procedures are followed.
Modified
p. 150 → 162
Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an accessed controlled area until shipped. The device or components should be checked prior to shipping to ensure the device has not been modified or tampered.
Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an access-controlled area until shipped. The device or components should be checked prior to shipping to ensure the device has not been modified or tampered.
Modified
p. 151 → 163
It is understood that vulnerability survey only represents a snapshot in time, and that vulnerabilities may become known in the public domain after that time. It is therefore expected that the vulnerability analysis incorporate up-to-date assessment mechanisms.
It is understood that vulnerability survey only represents a snapshot in time, and that vulnerabilities may become known in the public domain after that time. It is therefore expected that the vulnerability analysis incorporates up-to-date assessment mechanisms.
Modified
p. 153 → 165
b) The vulnerability-disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description, and assessment of the vulnerabilities.
b) The vulnerability-disclosure measures ensure a timely distribution of information about newly-found vulnerabilities. This information includes identification, description, and assessment of the vulnerabilities.
Modified
p. 153 → 165
The vendor must maintain documentation that describes their internal processes.
The vendor must maintain documentation that describes its internal processes.
Modified
p. 154 → 166
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 enroute 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.
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key- loading facility (where transactional (acquirer) keys are loaded) 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 packaging for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.
Modified
p. 154 → 166
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.
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage it is managing is compliant with this requirement. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Modified
p. 156 → 168
TF2.1 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. …
TF2.1 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 it receives the device until the time it is received by the next intermediary or the point of initial deployment. …
Modified
p. 156 → 168
TF2.5 The tester shall verify that where the device is shipped via intermediaries such as resellers, accountability is 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.
TF2.5 The tester shall verify that where the device is shipped via intermediaries such as resellers, accountability is with the intermediary from the time at which it receives the device until the time it is received by the next intermediary or the point of initial deployment.
Modified
p. 162 → 174
• 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.
• Device validation 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. 162 → 174
TF8.1 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 include instructions for recording the entire life cycle of the POI security-related components and the manner in which those components are integrated into a single POI. The operations management manual must be current and up to date.
TF8.1 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance with this requirement. The documentation should include instructions for recording the entire life cycle of the POI security-related components and the manner in which those components are integrated into a single POI. The operations management manual must be current and upto-date.
Modified
p. 170 → 182
• Positioning of terminal on the check-stand in such way as to make visual observation of the PIN- entry process infeasible. Examples include:
• Positioning of terminal on the check-stand in such way as to make visual observation of the PIN entry process impractical. Examples include:
Modified
p. 170 → 182
• 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
• 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.
Modified
p. 170 → 182
• 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.
• 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. 170 → 182
• Positioning of in-store security cameras such that the PIN-entry keypad is not visible.
• Positioning of in-store security cameras such that the PIN entry keypad is not visible.
Modified
p. 170 → 182
• Instructing the cardholder regarding safe PIN-entry. This can be done with a combination of
• Instructing the cardholder regarding safe PIN entry. This can be done with a combination of
Modified
p. 170 → 182
• A logo for safe PIN-entry process.
• A logo for safe PIN entry process.
Modified
p. 170 → 182
Other methods are possible as well. The above are examples of some of the methods a vendor can propose to protect PINs during PIN entry. The vendor must provide adequate techniques in the device documentation and also include a matrix showing which techniques should be used to protect against specific observation corridors. Table A1 on the following page shows an example matrix .
Other methods are possible as well. The above are examples of some of the methods a vendor can propose to protect PINs during PIN entry. The vendor must provide adequate techniques in the device documentation and also include a matrix showing which techniques should be used to protect against specific observation corridors. Table A1 on the following page shows an example matrix.
Modified
p. 177 → 189
Software required for a PIN-disclosing bug is typically straightforward to implement and would not be considered bespoke. Bespoke software would be software that requires significant time and expertise to develop such as is required for side channel attacks. PCI requires strong justification to be provided when bespoke parts is indicated as necessary for an attack.
Software required for a PIN-disclosing bug is typically straightforward to implement and would not be considered bespoke. Bespoke software would be software that requires significant time and expertise to develop such as is required for side-channel attacks. PCI requires strong justification to be provided when bespoke parts is indicated as necessary for an attack.
Modified
p. 179 → 191
Where sensitive data is exposed inside the PED or EPP, but outside of the immediate area of the keypad contacts⎯i.e., outside the keypad area⎯or internally within the security processor, this data must be protected by a tamper-responsive envelope. Use of physical barriers alone, such as plastic walls or tamper evident protections, is not considered sufficient to meet the requirements to protect customer PIN data or cryptographic keys. A POI that does not implement tamper-detecting side walls for its secure area …
Where sensitive data is exposed inside the PED or EPP, but outside of the immediate area of the keypad contacts⎯i.e., outside the keypad area⎯or internally within the security processor, this data must be protected by a tamper-responsive envelope. Use of physical barriers alone, such as plastic walls or tamper-evident protections, is not considered sufficient to meet the requirements to protect customer PIN data or cryptographic keys. A POI that does not implement tamper-detecting side walls for its secure area must …
Modified
p. 181 → 193
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the clear-text PIN at the keypad controller serial I²C Bus. This bug must be very small to fit into the original housing or must be attached on the back case in a fake housing. The PIN-disclosing bug has to handle I²C Bus signals. The development of the dedicated bug hardware and software has to be performed by an Expert. Standard equipment and circuits have to be …
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the cleartext PIN at the keypad controller serial I²C Bus. This bug must be very small to fit into the original housing or must be attached on the back case in a fake housing. The PIN-disclosing bug has to handle I²C Bus signals. The development of the dedicated bug hardware and software has to be performed by an Expert. Standard equipment and circuits have to be …
Modified
p. 184 → 196
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 bug hardware and software requires about 40 hours and has to be performed by an Expert with standard equipment.
2. The attack has to be prepared by developing a PIN-disclosing bug for logging the cleartext 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 bug hardware and software requires about 40 hours and has to be performed by an Expert with standard equipment.
Modified
p. 184 → 196
3. The deactivation of the lateral tamper grid (flexible foil printed with conductive ink on two layers, integrated in a plastic shape filled with resin) may be performed by reaching the connector of the tamper grid to the security processor or by direct manipulation of the mesh. If the grid is deactivated, the attacker may drill a hole in the lateral side of the POI to insert a PIN-disclosing bug. The attacker will uncover the security grid lines of the …
3. The deactivation of the lateral tamper grid (flexible foil printed with conductive ink on two layers, integrated in a plastic shape filled with resin) may be performed by reaching the connector of the tamper grid to the security processor or by direct manipulation of the mesh. If the grid is deactivated, the attacker may drill a hole in the lateral side of the POI to insert a PIN-disclosing bug. The attacker will uncover the security grid lines of the …
Modified
p. 185 → 197
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 …
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⎯e.g., for an endoscope⎯is needed. This can be accomplished …
Modified
p. 187 → 199
1. The attacker has to perform reverse-engineering of the device to develop the attack procedure.
1. The attacker has to perform the reverse engineering of the device to develop the attack procedure.
Modified
p. 193 → 205
• 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;
• 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.
Modified
p. 197 → 209
• 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.
• Laser abrading/cutting Bespoke equipment “Rule of thumb” followed: If it cannot be obtained for less than US$50,000 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.
Modified
p. 197 → 209
• Automated (“push-button”) side-channel software to be used on a specific POI model to bypass strong countermeasures and leak keys from that specific model.
• Automated (“push-button”) side-channel software to be used on a specific POI model to bypass strong countermeasures and leak keys from that specific model
Modified
p. 197 → 209
• Sophisticated X-ray 3-D imaging equipment Chip-level equipment “Rule of thumb” followed: Absolutely required for attacks at the feature level on chips (not bus level).
• Sophisticated X-ray 3D imaging equipment Chip-level equipment “Rule of thumb” followed: Absolutely required for attacks at the feature level on chips (not bus level).
Modified
p. 198 → 210
Configuration Item Setting Reference in Length of bit streams (n) 1,000,000 [1] Number of bit streams (sample size) (M) 1,073 [2] Block Frequency block length 20,000 [3] Non-Overlapping Templates template length 9 [4] Overlapping Template template length 9 [5] Universal block length (L), number of initialization steps (Q) L=7, Q=1,280 [6] Approximate Entropy block length 8 [7] Serial block length 16 [8] Linear Complexity block length 1,000 [9]
Configuration Item Setting Reference in Length of bit streams (n) 1,000,000 [1] Number of bit streams (sample size) (M) 1,073 [2] Block Frequency block length 20,000 [3] Non-Overlapping Templates template length 9 [4] Overlapping Templates template length 9 [5] Universal block length (L), number of initialization steps (Q) L=7, Q=1,280 [6] Approximate Entropy block length 8 [7] Serial block length 16 [8] Linear Complexity block length 1,000 [9]
Modified
p. 201 → 213
• Symmetric-key algorithms used for encryption and decryption: AES must be used, with key size >= 128 bits or TDES with keys size >= 112 bits.
• Symmetric-key algorithms used for encryption and decryption: AES must be used, with key size >= 128 bits; or where TDES is used in addition to AES, TDES keys must use keys with size >= 112 non-parity bits. TDES keys of any size must not be used for device security purposes (such as firmware authenticity, device-level key storage, etc.).
Modified
p. 201 → 213
• Signature algorithms: DSA, RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below.
• Signature algorithms: RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below. DSA is no longer allowed for use.
Modified
p. 201 → 213
SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions⎯i.e., KDFs⎯and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.
SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions⎯i.e., KDFs⎯and random-number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.
Modified
p. 202 → 214
TDES IFC (RSA) ECC (ECDSA, EdDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Key size in number of bits:
TDES IFC (RSA) ECC (ECDSA, ECSDSA, EdDSA, ECDH, ECMQV) FFC (DH, MQV) AES Key size in number of bits:
Modified
p. 202 → 214
TDES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size.
Modified
p. 202 → 214
• Each private key must be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
• Each private key must be statistically unique, unpredictable, and created using an approved random-number generator as described in this document.
Modified
p. 202 → 215
• Entities must authenticate the FFC or ECC public keys using DSA, ECDSA, a certificate, or a MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques. One of the following shall be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4).
•Requirements for message authentication using symmetric techniques. One of the following shall be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4).
• Entities must authenticate the FFC or ECC public keys using ECDSA, a certificate, or a MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques. One of the following shall be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4).
•Requirements for message authentication using symmetric techniques. One of the following shall be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4).
Modified
p. 203 → 216
Note: This appendix is for use in conjunction with DTR A7, “Non-Invasive Attacks for Cryptographic Keys.” 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, may show how a key can be fully exposed but at an acceptable level of difficulty, or …
Note: This appendix is for use in conjunction with DTR A7, “Non-Invasive Attacks for Cryptographic Keys.” 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, may show how a key can be fully exposed but at an acceptable level of difficulty, or …
Modified
p. 203 → 216
This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. Much of the information here is directly applicable to statistical testing on batches of device operations in the case of static key values. However other published analysis paths or example (but not restricted to) timing attacks, can be in scope. 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 …
This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. Much of the information here is directly applicable to statistical testing on batches of device operations in the case of static key values. However other published analysis paths or example (but not restricted to) timing attacks, can be in scope. 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 practical method to …
Modified
p. 206 → 219
•for example, in the absence of SCA countermeasures
•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.
Critical steps in SCA scenarios Even in straightforward scenarios
•for example, in the absence of SCA countermeasures
•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.
•for example, in the absence of SCA countermeasures
•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.
Modified
p. 207 → 220
• Correlation: Computations such as (but not restricted to) the Pearson product-moment coefficient are a crucial element in a test’s capability to achieve alignment. Effective correlation capabilities are also crucial for identification of leakage that may often be obscured, for example to identify security- significant patterns in waveforms, test a device’s relative susceptibility to leak internally processed data, localize sensitive operations for making well-targeted attacks, launch and develop attacks to infer secret data values. The evaluation should use correlation-analysis techniques …
• Correlation: Computations such as (but not restricted to) the Pearson product-moment coefficient are a crucial element in a test’s capability to achieve alignment. Effective correlation capabilities are also crucial for identification of leakage that may often be obscured, for example to identify security- significant patterns in waveforms, test a device’s relative susceptibility to leak internally processed data, localize sensitive operations for making well-targeted attacks, launch and develop attacks to infer secret data values. The evaluation should use correlation-analysis techniques …
Modified
p. 210 → 223
Effort to complete the overall device side-channel analysis The descriptions below outline typical parameters that are acceptable for testing. Good attackers are creative and will not limit their efforts to below pre-defined limits such as disk storage size or an exact number of acquisitions, etc. PCI SCC expects the degree of any key leakage to be quantified using effective techniques⎯e.g., correlation, key attacks related to DPA, etc.⎯that are in agreement with these typical parameters but without reliance on parameter values …
Effort to complete the overall device side-channel analysis The descriptions below outline typical parameters that are acceptable for testing. Good attackers are creative and will not limit their efforts to below pre-defined limits such as disk storage size or an exact number of acquisitions, etc. PCI SSC expects the degree of any key leakage to be quantified using effective techniques⎯e.g., correlation, key attacks related to DPA, etc.⎯that are in agreement with these typical parameters but without reliance on parameter values …
Removed
p. 211
A good test may discover total, partial, or zero key leakage, feasible in a field attack scenario, and/or feasible in the white-box context of the evaluation. In situations where a feasible attack is known to be capable of exposing the key, the evaluation shall explain definitively the effort needed to extract the key and how compliance is assessed considering obstacles to key-leakage attacks. In assessing this, the evaluation must consider and justify how any degree of key leakage is considerably above an acceptable level, considering that successful attacks may require a lower degree of effort than the effort discovered through testing.
Modified
p. 214 → 227
It is therefore expected that the developer of the PTS device will perform this domain-based asset flow analysis and provide the results and a proper explanation to the testers. The test lab will verify the analysis and use the effective domain rating as input for the evaluation.
It is therefore expected that the laboratory will generate an Asset Flow Diagram or Diagrams for the device.
Modified
p. 214 → 227
Assets and Domains “Domains” is used herein as a shortened term for “security domains group assets” with similar protection requirements. Such domains are easily reflected by similar attack cost thresholds. While in general domains with the same requirements concerning attack potential might have to be kept segregated to reflect different administrative requirements, such a structure is as yet not foreseen in PCI POI. Therefore, the domain hierarchy is linear⎯i.e., any domain can always be represented by another domain with higher …
Assets and Domains “Domains” is used herein as a shortened term for “security domains group assets” with similar protection requirements. Such domains are easily reflected by similar attack cost thresholds. While in general domains with the same requirements concerning attack potential might have to be kept segregated to reflect different administrative requirements, such a structure is as yet not foreseen in PCI POI. Therefore, the domain hierarchy is linear⎯i.e., any domain can always be represented by another domain with higher …
Modified
p. 214 → 227
The PCI POI criteria defines various assets with corresponding protection requirements. Assets are defined by data and which kind of access it shall be protected against. Integrity means that any modification to the asset, whether spurious or induced, shall prohibit it being processed any longer. Confidentiality means that clear text of the data must not be disclosed. In Table H1 below, five Security Domains are defined from higher-protection requirements to lesser requirements:
The PCI POI criteria defines various assets with corresponding protection requirements. Assets are defined by data and which kind of access it shall be protected against. Integrity means that any modification to the asset, whether spurious or induced, shall prohibit it being processed any longer. Confidentiality means that cleartext of the data must not be disclosed. In Table H1 below, five Security Domains are defined from higher-protection requirements to lesser requirements:
Modified
p. 215 → 228
Public keys used for functions that impact security requirements, such as firmware updates, display prompt control, account data protection, or remote key distribution schemes; and secret/private keys used for functions that impact security requirements, including securing operations in the data domain, must be protected to resist an attack potential of 26 points. All these keys must be protected for integrity and authenticity. Secret and private keys must also have their confidentiality protected as well.
Modified
p. 215 → 228
PIN The cardholder PIN is protected to resist an attack potential of 26 points in DTR A1. PINs must not be disclosed. Passwords meet the same category. Although DTR A13 puts offline PIN at 20 points, the PIN shall consistently be considered as an asset class.
PIN The cardholder PIN is protected to resist an attack potential of 26 points in DTR A2. PINs must not be disclosed. Passwords meet the same category. Although DTR A13 puts offline PIN at 20 points, the PIN shall consistently be considered as an asset class.
Modified
p. 215 → 228
Lower Protection Data This class covers all other transaction data⎯e.g., PAN⎯and display prompts. The DTRs protect these assets at 20 points or less. The EMV L2 kernel sits here.
Lower Protection Data This class covers all other transaction data⎯e.g., PAN⎯and display prompts. The DTRs protect these assets at 20 points or less. The EMV® L2 kernel sits here.
Modified
p. 215 → 228
It is vital that any lower domain cannot access any higher domain other than by dedicated, confined, and well-specified interfaces provided by the higher domain or any of its parents. Explicitly, the vendor domain has no access beyond itself, meaning that it is infeasible for any change of the code of this domain to gain any access to assets in a higher domain or change the behavior of any higher domain (except through the defined interfaces provided by those higher …
It is vital that any lower domain cannot access any higher domain other than by dedicated, confined, and well-specified interfaces provided by the higher domain or any of its parents. Explicitly, the vendor domain has no access beyond itself, meaning that it is impractical for any change of the code of this domain to gain any access to assets in a higher domain or change the behavior of any higher domain (except through the defined interfaces provided by those higher …
Modified
p. 216 → 229
For example, it is valid to store keys in a domain of lesser security⎯if the keys are stored in compliant key-block formats and algorithms used for encryption and MAC are adequately strong. The modules and components performing the cryptography and processing the validated or clear-text assets necessarily belong to the PIN Key domain. This represents the idea of firmware in previous PCI PTS POI requirements.
For example, it is valid to store keys in a domain of lesser security⎯if the keys are stored in compliant key-block formats and algorithms used for encryption and MAC are adequately strong. The modules and components performing the cryptography and processing the validated or cleartext assets necessarily belong to the PIN Key domain. This represents the idea of firmware in previous PCI PTS POI requirements.
Modified
p. 216 → 229
We define “code” as any instructions for a processing hardware, including microcode or netlists for programmable hardware, and any kind of data that may affect the processing by these instructions. Such data can be as simple as configuration bits, whether or not a certain security function is enforced. In PCI POI such data often is interpreted code, from simple access control rules represented as data for an engine up to large amounts of code⎯e.g., Java byte code in Android-based systems. …
We define “code” as any instructions for a processing hardware, including microcode or netlists for programmable hardware, and any kind of data that may affect the processing by these instructions. Such data can be as simple as configuration bits, whether or not a certain security function is enforced. In PCI POI such data often is interpreted code, from simple access-control rules represented as data for an engine up to large amounts of code⎯e.g., Java byte code in Android-based systems. As …
Modified
p. 216 → 229
Standard concepts comprise separated processors or CPU with memory management and execution modes of graded privileges. The proper configuration of the segregation hardware may not be overly simple, but in general it should be feasible to verify its effectiveness.
Standard concepts comprise separated processors or CPU with memory management and execution modes of graded privileges. The proper configuration of the segregation hardware may not be overly simple, but in general it should be practical to verify its effectiveness.
Modified
p. 217 → 230
1. Consider the software in operational state and perform all transactions⎯e.g., key loading, online, offline encrypted PIN, offline clear-text PIN, etc. Follow the incoming data from each external interface until messages are sent on external interfaces. Consider where assets or parts of them pass through the firmware. Tag each module with the corresponding asset domain.
1. Consider the software in operational state and perform all transactions⎯e.g., key loading, online, offline encrypted PIN, offline cleartext PIN, etc. Follow the incoming data from each external interface until messages are sent on external interfaces. Consider where assets or parts of them pass through the firmware. Tag each module with the corresponding asset domain.
Removed
p. 218
A description of this analysis should be in the hardware architecture delivered by the vendor. It should make clear on implementation level where the assets are produced, transferred, stored, and destroyed, giving a focused design description.
Modified
p. 218 → 231
The vendor shall provide a block diagram at domain level that clearly identifies how the domains interact with one another. The corresponding programming interfaces or, if applicable, hardware interfaces shall be uniquely identified and documented. The diagram shall clearly identify whether software is executed on the same hardware or on separate CPU, memory, etc.
The lab shall provide a block diagram at domain level that clearly identifies how the domains interact with one another. The corresponding programming interfaces or, if applicable, hardware interfaces shall be uniquely identified and documented. The diagram shall clearly identify whether software is executed on the same hardware or on separate CPU, memory, etc.
Modified
p. 218 → 231
PCI PTS allows applications in the data domain and the vendor domain. Applications therefore can never handle clear-text PIN or keys of the PIN Key domain (although applications may handle keys in the Non- PIN Key domain, for example in the form of EMV public keys).
PCI PTS allows applications in the data domain and the vendor domain. Applications therefore can never handle cleartext PIN or keys of the PIN Key domain (although applications may handle keys in the Non- PIN Key domain, for example in the form of EMV® public keys).
Removed
p. 222
On the Application Processor /dev/ttyS1 is acquired by the Payment Application. Upon receiving a START_TRANSACTION message, it returns a QUERY_AMOUNT message and displays an amount prompt via /dev/pty1, which interfaces to the display driver of the Linux OS.
The QUERY_AMOUNT message causes the Security Processor to scan the numeric keypad. Once amount entry is completed, the Security Processor returns AMOUNT_DONE to the Payment Application. The latter stores the amount and prompts for a card via /dev/pty1. It puts the Security Processor to card acceptance mode sending WAIT_FOR_CARD.
The cardholder inserts a card. The Security Processor detects this by polling the card switch. It selects contact payment and reads information from the card including the PAN, which is stored in the Security Processor. The latter sends CVM and Issuer Identification Number (IIN) to the Payment Application using TRANSACTION_TYPE.
The Payment Application selects the type of transaction and returns the decision using a RUN_TRANSACTION message
• …
The QUERY_AMOUNT message causes the Security Processor to scan the numeric keypad. Once amount entry is completed, the Security Processor returns AMOUNT_DONE to the Payment Application. The latter stores the amount and prompts for a card via /dev/pty1. It puts the Security Processor to card acceptance mode sending WAIT_FOR_CARD.
The cardholder inserts a card. The Security Processor detects this by polling the card switch. It selects contact payment and reads information from the card including the PAN, which is stored in the Security Processor. The latter sends CVM and Issuer Identification Number (IIN) to the Payment Application using TRANSACTION_TYPE.
The Payment Application selects the type of transaction and returns the decision using a RUN_TRANSACTION message
• …
Modified
p. 222 → 235
Figure G-2: Asset Flow Description Manual amount entry with offline encrypted PIN1 The merchant presses “START” on the keypad. The Security Controller firmware detects the key and sends a START_TRANSACTION message using the UART to the Application Processor. The latter is handled by an interrupt handler of the Linux OS, which maps it to the character device /dev/ttyS1 for the process spaces maintained by Linux.
Figure G-2: Asset Flow Description Manual amount entry with offline encrypted PIN1 1 See Table G4, “Identification of Operations,” lines 5 and 6, on previous page.
Removed
p. 224
The Payment Application displays the transaction outcome and creates a record for the payment processor containing Amount, Transaction Cryptogram, Time, Terminal ID, and encrypted PAN: This record is sent via the Unix domain socket /var/run/terminal to the Terminal Application for proper formatting. Unix domain sockets are handled by the Linux OS.
The terminal application will format the record according to the specifications of the particular processor and send the record to the payment processor using a network socket.
The network socket in turn is managed by the Linux OS. It wraps the message in appropriate TCP/IP frames and routes them via the proper interface. Depending on the connectivity, this may be the GSM modem or the Ethernet connection.
The GSM modem handles all GSM specific protocols internally. It is served by interrupt handlers of the Linux kernel, which handles it as a network interface. Similarly, the physical Ethernet layer is served by interrupt …
The terminal application will format the record according to the specifications of the particular processor and send the record to the payment processor using a network socket.
The network socket in turn is managed by the Linux OS. It wraps the message in appropriate TCP/IP frames and routes them via the proper interface. Depending on the connectivity, this may be the GSM modem or the Ethernet connection.
The GSM modem handles all GSM specific protocols internally. It is served by interrupt handlers of the Linux kernel, which handles it as a network interface. Similarly, the physical Ethernet layer is served by interrupt …
Modified
p. 224 → 237
Asset Immediate Asset Container Domain Prompt Exists in Payment Application Conveyed by Linux OS to display PAN Read from ICC Encrypted in Security Controller Created in Security Controller Sent to payment processor via Payment Application, Terminal Application, Linux OS and GSM or Ethernet PAN Key Resides in Security Controller Non-PIN Key Issuer CA Key Resides in Security Controller Non-PIN Key ICC Public Key Key determined valid after signature verification in Security Controller Certificate read from ICC Non-PIN Key PIN Read …
Asset Immediate Asset Container Domain Prompt Exists in Payment Application Conveyed by Linux OS to display PAN Read from ICC Encrypted in Security Controller Created in Security Controller Sent to payment processor via Payment Application, Terminal Application, Linux OS and GSM or Ethernet PAN Key Resides in Security Controller Non-PIN Key Issuer CA Key Resides in Security Controller Non-PIN Key ICC Public Key Key determined valid after signature verification in Security Controller Certificate read from ICC Non-PIN Key PIN Read …
Modified
p. 225 → 237
Note: Security Controller denotes both the controller hardware and the monolithic software running on it. For simplicity it has been assumed that both Security and Application Controller use internal memories, only, or that the developer is willing to tag all external memory as the same domain as the controller itself.
Modified
p. 226 → 238
The checklist applies to all processors inside any POI, which process any of the assets related to PCI POI Security Requirements⎯i.e., cryptographic keys relevant to PIN protection, clear-text PINs, clear-text PANs, display prompts, and clear-text card reader data. Please refer to Appendix G for definition of assets.
The checklist applies to all processors inside any POI, which process any of the assets related to PCI POI Security Requirements⎯i.e., cryptographic keys relevant to PIN protection, cleartext PINs, cleartext PANs, display prompts, and cleartext card reader data. Please refer to Appendix G for definition of assets.
Modified
p. 226 → 238
• Processes clear-text keys, which includes using these keys, or passwords relevant to PIN or account- data protection;
• Processes cleartext keys, which includes using these keys, or passwords relevant to PIN or account- data protection;
Modified
p. 226 → 238
• Processes clear-text PINs, PANs, or card-reader data;
• Processes cleartext PINs, PANs, or card-reader data;
Modified
p. 226 → 238
• Processes clear-text input from keypads, touchscreens, or any other input device;
• Processes cleartext input from keypads, touchscreens, or any other input device;
Modified
p. 227 → 239
Most modern CPUs use a BGA-type packaging. The testers shall consider techniques to contact solder- balls. If a CPU is accessible, it can be feasible to contact any single ball. It may be harder if specific combinations are required, or if the CPU is hard to reach. The testers shall still consider whether any mechanical obstacles must be removed prior to attacking the BGA.
Most modern CPUs use a BGA-type packaging. The testers shall consider techniques to contact solder- balls. If a CPU is accessible, it can be practical to contact any single ball. It may be harder if specific combinations are required, or if the CPU is hard to reach. The testers shall still consider whether any mechanical obstacles must be removed prior to attacking the BGA.
Modified
p. 228 → 240
External memory Since code and data sizes tend to grow, some POI designs use external memory⎯i.e., storage that is located in an area with lesser tamper protection than the CPU. Obviously, no clear text of confidential assets must ever be stored in external memory that is reachable by an attacker. But access to memory can have various dangerous effects. Even modification of encrypted memory may be exploited for various goals. Analysis of address access may yield information about internal processing, …
External memory Since code and data sizes tend to grow, some POI designs use external memory⎯i.e., storage that is located in an area with lesser tamper protection than the CPU. Obviously, no cleartext of confidential assets must ever be stored in external memory that is reachable by an attacker. But access to memory can have various dangerous effects. Even modification of encrypted memory may be exploited for various goals. Analysis of address access may yield information about internal processing, which …
Modified
p. 229 → 241
Random-Number Generators True random-number generators are a common feature of security CPUs. Using some homebrew post- processing or even an entirely distinct generator is a common drawback implemented by POI developers. Testers shall verify that the generator is actually used, the data is not post-processed, and that the results have been validated by the relevant NIST tests. In most cases, re-running the test may be more efficient than referring to external test results.
Modified
p. 229 → 241
• The original testing is not older than three years.
• The original testing is not older than the last prior major version.
Removed
p. 236
• 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.
Modified
p. 236 → 248
• 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 provides guidance how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with Requirement B15, or any mechanisms used for authenticating application code as assessed under B2.1.
Modified
p. 237 → 249
• 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 ofclear-text account data using techniques such as whitelisting.
•e.g., algorithms used, format- preserving encryption techniques
•and whether the device supports the pass-through of
• 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 cleartext account data using techniques such as whitelisting.
•e.g., algorithms used, format- preserving encryption techniques
•and whether the device supports the pass-through of cleartext account data using techniques such as whitelisting.
Modified
p. 237 → 249
• The guidance 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. The guidance should also include whom the merchant must contact and the contact method.
• The guidance 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 practical to determine the key by exhaustive attack elapses, as defined in NIST SP 800-57-1. The guidance should also include whom the merchant must contact and the contact method.