Document Diff - PCI Watch

Added p. 1

Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 6.1

March 2022 6.1 Added requirement for unauthenticated wireless communications.

Added p. 30

TA8.5 The tester shall list any components⎯including passive parts or segments, connectors, or other items⎯that are connected to the path of the display signals.

TA8.7 The tester shall describe whether any of the items on the path of the display signals are not protected by a tamper-detection mechanism.

Added p. 37

• 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.

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 format-preserving encryption mode must be considered in addition to any native truncation methods implemented by the POI.

The POI shall only display one clear-text digit at a time during manual (key-entered) PAN …

Added p. 51

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.

Added p. 60

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.

Note: This does not apply to key components entered into the keypad of a secure cryptographic device.

Added p. 70

Note that other public key techniques such as Diffie Hellman or Elliptic Curve must be used to convey AES keys greater in strength than 128 bits.

Added p. 74

a) No key is encrypted under a key of lesser strength⎯this includes KEKs, transport key (with the exception for 2048 RSA keys as noted in the guidance above), and storage keys. Where AES working keys are supported, such as for use with AES-based PIN blocks, the key hierarchy for those working keys (including the POI storage key) must not implement TDEA keys⎯i.e., must implement AES keys of equal or greater strength than the keys they protect; and

Added p. 77

• 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.

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 format-preserving encryption mode must be considered in addition to any native truncation methods implemented by the POI.

• Service code For an authenticated application:

• The application must reside and execute within the …

Added p. 92

• That SRED functions, where provided, are correctly implemented.

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.

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.

Added p. 100

• Clear-text key components through the keypad (TB5.5 a),

• Clear-text key injection (as per TB5.5 b),

• Symmetric encrypted keys (TB5.5 c), remote asymmetric key loading (TB5.5 d), or

• Local asymmetric key loading (similar to TB5.5 d, except the local environment provides the mutual authentication, not cryptography).

TB20.31 The tester shall examine the security policy to verify that it describes any PCI-approved components (as defined in the Device Testing and Approval Program Guide) that are used and how they are used in conjunction with this device.

Added p. 105

TB23.7 Where the firmware supports the output of truncated PAN values, the tester shall confirm that when operating in encrypting mode, the POI enforces truncation that meets relevant brand requirements and PCI FAQs. Examples of relevant FAQs includes, but may not be limited to, PCI DSS FAQ 1091.

Added p. 122

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.

Added p. 133

TD11.1 The tester shall review vendor documentation, confirm whether the declared security protocol for each interface provides session management, and describe how this is provided.

Note: If Bluetooth is used, D14 may alternatively be used.

Note: If Wi-Fi is used, D14 may alternatively be used.

Added p. 136

Note: Where the applicable security requirements D12 and/or D13 for Bluetooth or Wi-Fi are not met, D14 must be used.

This requirement is intended to cover wireless interfaces that are primarily designed for communications. Interfaces such as displays, cameras, speakers and microphones, and other types of transmission and receiving systems that are not primarily designed for data communication between two electronic systems are not in scope for this requirement. Wireless interfaces implemented primarily for payment acceptance, such as NFC or contactless interfaces, are also excluded.

Wireless interfaces are of particular concern because they allow for remote attack vectors or potential public access to the communications. This can allow for physically distant monitoring of communications or deployment of logical attacks onto one or more terminals from a remote location. To mitigate these risks, this standard has specific security requirements for some common wireless interfaces such as Bluetooth and Wi-Fi. Where a wireless interface …

Added p. 137

Hardware isolated systems must ensure that sensitive data is encrypted prior to being sent to the interface processor, although controls for the authenticity of the connections may be applied at the interface processor. For example, it would not be compliant for a system to pass unencrypted payment card data to the interface processor, where it was then encrypted using TLS for communication across the insecure interface. However, it may be acceptable for the data to be passed to the interface processor encrypted⎯using SRED, for example⎯and then the interface processor implements a TLS connection to validate the authenticity of the transmission endpoint.

Additionally, application of SRED controls that provide both confidentiality and authenticity controls, or the use of both SRED and TLS, prior to transmission to the interface processor may also be compliant.

TD14.1 The tester shall detail all wireless communication interfaces supported by the device, such as Wi-Fi, Bluetooth, cellular, bespoke wireless, …

Added p. 138

TD14.7 The tester shall confirm how the cryptographic controls ensure that all data transmitted across the wireless interface(s) is protected against eavesdropping.

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.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 …

Added p. 145

TE3.3 The tester shall examine a sample of documentation for firmware authentication⎯i.e., signing⎯and storage during manufacturing, including change-control logs and firmware validation procedures to ensure procedures are followed.

TE5.3 The tester shall examine a sample of documentation for firmware control and storage during manufacturing, including change-control logs and firmware validation procedure to ensure the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.

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.

TE7.3 The tester shall examine a sample of documentation for secret information, including user documentation, and device-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.

TE9.3 The tester shall examine a sample of approved documentation for repair, …

Added p. 156

TF1.3 The tester shall examine a sample of documentation for tamper protection, inspection, and transfer documentation, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed and describe how this shows compliance to this requirement.

TF2.2 The tester shall examine a sample of transfer documentation, including inventory logs, and shipping documentation, to ensure procedures are followed.

TF3.2 The tester shall examine a sample of documentation for tamper protection, inspection and transfer documentation, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed.

TF4.2 The tester shall examine a sample of documentation for device-development security, including user documentation, and component validation procedures to ensure procedures are followed.

TF5.2 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.

TF7.2 The tester shall verify and show evidence that the model name and hardware version are retrievable from the device by a …

Added p. 203

TDES IFC (RSA) ECC (ECDSA, EdDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Key size in number of bits:

Added p. 216

All keys used to secure information in the PIN domain, or other keys in the PIN Key domain, are included in this domain.

All public keys, and secret/private keys used for 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.

PANs must not be disclosed, except as allowed in PCI DSS⎯e.g., ensure that the solution doesn't exceed the allowable brand truncation/masking guidance when displaying the IIN/BIN and trailing digits of a PAN. Both PAN and prompts must maintain integrity.

Modified p. 12 → 11

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 chip set that automatically generates keys at initialization, but the keys are not subsequently used by the device.

Modified p. 14 → 13

d) Note as to whether the PCB contains any sensitive signals (such as ~~plaintext~~ 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 clear-text PINs, MSR, ICC, or display connections•but not tamper signals); and finally

Modified p. 17 → 16

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 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 IC card reader, as defined in Appendix B.

Modified p. 17 → 16

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 exploitation.

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.

Modified p. 17 → 16

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 exploitation for PIN entry, and 16 in total with 8 for 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 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.

Modified p. 17 → 16

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 in A1.~~

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.

Modified p. 17 → 16

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 in A1.~~

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.

Modified p. 21 → 20

It is expected that each type of information may have multiple “storage areas” and “methods of protection” (for example, ~~plaintext~~ 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, 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).

Modified p. 22 → 21

TA4.8 If the POI allows for execution of applications and firmware on the same processor that stores or operates on ~~plaintext~~ passwords/authentication codes, PINs, or public keys, the tester shall note what mechanisms are implemented to prevent these applications from modifying this information. The tester shall detail how this has been validated as sufficient.

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.

Modified p. 23 → 22

If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. If only attack scenarios can be developed yielding attack potentials above these thresholds, the tester shall present these to demonstrate how the device is compliant to this DTR. At least one attack scenario shall be presented, in …

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. If only attack scenarios can be developed yielding attack potentials above these thresholds, the tester shall present these to demonstrate how the device is compliant to this DTR. At least one attack scenario shall be presented, …

Modified p. 25 → 24

TA5.9 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring, using attack scenarios. If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one …

TA5.9 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. 26 → 25

Keys resident in the device or its components means ~~plaintext~~ secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix E, they do not need to be considered.

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.

Modified p. 26 → 25

TA6.1 The tester shall provide details on the type, location, and accessibility of the security-relevant processor(s) used by the POI, and any other elements of the POI that have relevance to possible attacks. This shall include a list of all barriers obstructing access to keys, beginning with the device exterior case and ending with inner-most barriers, clearly indicating which barriers are tamper-responsive, or not. The tester shall reference information previously supplied in DTRs A1 and A4 where applicable. The tester …

Modified p. 26 → 25

TA6.2 The tester shall provide details on how cryptographic keys are stored and managed within the POI. The tester shall reference this information to the table provided in DTR A4, allowing the location of all applicable keys to be defined. The tester shall detail the testing performed to confirm the storage locations listed are correct. The tester shall reference the relevant aspects of the asset ~~flow in A1.~~

TA6.2 The tester shall provide details on how cryptographic keys are stored and managed within the POI. The tester shall reference this information to the table provided in DTR A4, allowing the location of all applicable keys to be defined. The tester shall detail the testing performed to confirm the storage locations listed are correct. The tester shall reference the relevant aspects of the asset flow.

Modified p. 27 → 26

TA6.7 If the POI stores ~~plaintext~~ cryptographic keys within external memory, the tester shall detail the physical security methods implemented to protect this memory. Note that PCB-based tamper grids are not considered sufficient to protect ~~plaintext~~ cryptographic keys.

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.

Modified p. 27 → 26

• If an attack scenario 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 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 in this document. Calculations shall include evidence justifying particular rating …

• 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 …

Modified p. 27 → 26

• If an attack scenario can be developed that yields an attack potential for any account-data- security-related key of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the examples shown in Appendix B in this document. Calculations shall include evidence justifying particular rating levels as …

• If an attack scenario can be developed that yields an attack potential for any account-data- security-related key 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 one attack scenario shall be presented, in a format consistent with the examples shown in Appendix B in this document. Calculations shall include evidence justifying particular rating levels …

Modified p. 36 → 34

SCRPs may include an ~~MSR,~~ but cannot exclusively contain only an MSR. SCRPs must include contact and/or contactless chip card functionality.

SCRPs may include an MSR but cannot exclusively contain only an MSR. SCRPs must include contact and/or contactless chip card functionality.

Modified p. 38 → 36

~~TA10.11~~ The tester shall explain how the POI is protected against attacks for contactless data from all sides of the POI, including the front and rear of the device.

TA10.12 The tester shall explain how the POI is protected against attacks for contactless data from all sides of the POI, including the front and rear of the device.

Modified p. 38 → 36

~~TA10.12~~ The tester shall develop attack scenarios to penetrate the device to make any additions, substitutions, or modifications to either the device hardware or software, in order to determine or modify any account data, with an attack potential of at least 16 per device for identification and initial exploitation, with a minimum of 8 for exploitation. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual …

TA10.13 The tester shall develop attack scenarios to penetrate the device to make any additions, substitutions, or modifications to either the device hardware or software, in order to determine or modify any account data, with an attack potential of at least 16 per device for identification and initial exploitation, with a minimum of 8 for initial exploitation. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than …

Removed p. 39

• The PAN itself. If the PAN can be parsed, the sensitive PAN middle digits⎯after the first six left-most digits of the PAN, the Issuer Identification Number, and before trailing digits (max of four) must be encrypted.

Modified p. 39 → 37

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 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 clear-text account data by the secure controller to cryptographically authenticated applications (per B23.1).

Modified p. 39 → 37

• The application must be cryptographically authenticated by the ~~secure chip~~ 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 key domain of the POI using algorithms and keys sizes consistent with those stipulated in B10.

Modified p. 40 → 39

Note: Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered sensitive 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.

Note: Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered sensitive 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.

Modified p. 41 → 40

SCRPs shall require an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation.

SCRPs shall require an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for initial exploitation.

Modified p. 47 → 46

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 in A1.~~

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.

Modified p. 49 → 48

The firmware and application version ~~numbers,~~ and ~~optionally~~ the hardware version number must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols.

The firmware and application version numbers and the hardware version number must be shown on the display or printed during startup or upon request. This includes all modules addressed in testing, including SRED and Open Protocols.

Modified p. 49 → 48

The displayed firmware version number must represent all firmware in the ~~device.~~

The displayed firmware version number must represent all firmware in the device that is currently able to be executed.

Modified p. 50 → 49

TB2.5 For each of the processing elements listed in DTR A4, the tester shall complete the following table. Where different parts of the code can be updated independently or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well. The tester shall reference the relevant aspects of the asset ~~flow in A1.~~

TB2.5 For each of the processing elements listed in DTR A4, the tester shall complete the following table. Where different parts of the code can be updated independently or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well. The tester shall reference the relevant aspects of the asset flow.

Modified p. 51 → 50

TB2.12 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version ~~numbers,~~ and ~~optionally~~ the hardware version number during startup or on request. This includes all firmware numbers for impacted requirements.

TB2.12 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version numbers and the hardware version number during startup or upon request. This includes all firmware numbers for impacted requirements.

Modified p. 52 → 51

TB2.1.2 The tester shall determine the rank of protection strength for the component involved in application authentication, including configuration updatesand that the authentication is performed by an appropriate component 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. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.

Modified p. 57 → 56

~~Plaintext~~ 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 ~~plaintext~~ PIN must occur before the tamper- detection mechanisms can be disabled using attack methods described in A2.

Clear-text 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 clear-text PIN must occur before the tamper- detection mechanisms can be disabled using attack methods described in A2.

Modified p. 57 → 56

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, ~~plaintext~~ PIN or account-data values, ~~plaintext~~ cryptographic keys, or key components outside of the crypto-processor are considered sensitive data.

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.

Modified p. 60 → 59

Cryptographic Method of loading per Authentication TMK Components through keypad Two seven-character passwords through keypad Encrypted under PKman Provided by encryption ~~Plaintext~~ 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 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.

Modified p. 60 → 59

a) When entering ~~plaintext~~ secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/authentication codes that are unique per device …

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 …

Modified p. 60 → 59

b) For injecting ~~plaintext~~ 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 ~~plaintext~~ key into the device.

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.

Modified p. 61 → 60

~~TB5.7~~ 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 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).

Modified p. 61 → 60

~~TB5.8~~ The tester shall confirm that and describe how any entry of sensitive information through the keypad of the POI is protected to the same extent as customer PINs, conforming to all relevant requirements (for example, A1, A2, A4, A5 and A6).

TB5.9 The tester shall confirm that and describe how any entry of sensitive information through the keypad of the POI is protected to the same extent as customer PINs, conforming to all relevant requirements (for example, A1, A2, A4, A5 and A6).

Modified p. 62 → 61

~~TB5.11~~ The tester shall detail any other sensitive services offered by the POI and detail the authentication provided for these services. The tester shall justify how this ensures dual control is provided for all sensitive services.

TB5.12 The tester shall detail any other sensitive services offered by the POI and detail the authentication provided for these services. The tester shall justify how this ensures dual control is provided for all sensitive services.

Modified p. 62 → 61

~~TB5.12~~ The tester shall validate that

•and describe how

•all passwords/authentication codes implemented to provide dual control are at least seven characters or an equivalent strength.

TB5.13 The tester shall validate that

•and describe how

•all passwords/authentication codes implemented to provide dual control are at least seven characters or an equivalent strength.

Modified p. 62 → 61

~~TB5.13~~ The tester shall attempt to load cryptographic keys or components into the POI without changing the default values of the passwords/authentication codes. The tester shall detail the results. The requirements of this DTR are not met if this can be done.

TB5.14 The tester shall attempt to load cryptographic keys or components into the POI without changing the default values of the passwords/authentication codes. The tester shall detail the results. The requirements of this DTR are not met if this can be done.

Modified p. 62 → 61

~~TB5.14~~ The tester shall attempt to set the passwords/authentication codes in the POI so that two or more of the passwords/authentication codes in the same device have the same value. The tester shall detail the results. The requirements of this DTR are not met if this can be done.

TB5.15 The tester shall attempt to set the passwords/authentication codes in the POI so that two or more of the passwords/authentication codes in the same device have the same value. The tester shall detail the results. The requirements of this DTR are not met if this can be done.

Modified p. 62 → 61

~~TB5.15~~ The tester shall attempt to set the passwords/authentication codes of the POI to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.

TB5.16 The tester shall attempt to set the passwords/authentication codes of the POI to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.

Modified p. 63 → 62

TB6.6 For all sensitive services, excluding loading of encrypted key values but including loading of ~~plaintext~~ 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 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.

Modified p. 67 → 66

• Preventing the entry of the PIN through other than the ~~keypad,~~ and limiting the rate at which the device will encrypt PINs to the average (for example, over 120 transactions) of one per 30 seconds. The intent of the requirement statement is that for any 120 consecutive transactions, the average time between encryptions for a specific PIN entry is approximately 30 seconds. (Deters the attack.)

• Preventing the entry of the PIN through other than the keypad and limiting the rate at which the device will encrypt PINs to the average (for example, over 120 transactions) of one per 30 seconds. The intent of the requirement statement is that for any 120 consecutive transactions, the average time between encryptions for a specific PIN entry is approximately 30 seconds. (Deters the attack.)

Modified p. 69 → 68

Devices must support the ANSI ~~TR-31~~ key-derivation methodology for TDES keys, and for AES keys must support ~~either~~ the ~~TR-31~~ methodology or the ISO 20038 ~~methodology or equivalent methods. TR-31 is~~ recognized as an interoperable ~~method~~ for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. The ~~TR-31~~ Key Variant (Calculation) ~~method is~~ no longer allowed.

Devices must support the ASC X9 TR 31 or ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support the TR 31 and/or X9.143 methodology and/or the ISO 20038 methodology. TR 31 and X9.143 are recognized as interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. The TR 31 and X9.143 Key Variant (Calculation) methods are no longer allowed.

Modified p. 70 → 69

This does not imply that the device must enforce ~~TR-31~~ or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.

This does not imply that the device must enforce TR 31 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.

Modified p. 70 → 69

This does not imply that the device must support ~~TR-31~~ for TDES and AES or ISO 20038 for AES or an equivalent methodology between the device and an external ICC reader, but it optionally may do so. The device may also optionally support ~~TR-31~~ for TDES and AES or ISO 20038 for AES or an equivalent methodology for the storage of keys encrypted under a symmetric key.

This does not imply that the device must support TR 31 or X9.143 for TDES and AES or ISO 20038 for AES or an equivalent methodology between the device and an external ICC reader, but it optionally may do so. The device may also optionally support TR 31 or X9.143 for TDES and AES or ISO 20038 for AES or an equivalent methodology for the storage of keys encrypted under a symmetric key.

Modified p. 71 → 70

• Loaded using asymmetric keys of equivalent or greater strength

•note a specific exception is allowed for the use of 2048 RSA keys to encrypt 128 bits AES keys for remote key distribution using asymmetric keys as delineated in PIN Security Requirement 10; or

• Loaded using asymmetric keys of equivalent or greater strength

•note a specific exception is allowed for the use of 2048 RSA keys to encrypt 128 bits AES keys for remote key distribution as described in ANSI X9.143 using asymmetric keys as delineated in PIN Security Requirement 10; or

Modified p. 71 → 70

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 …

Modified p. 72 → 71

TB9.3 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 in A1.~~

TB9.3 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. 73 → 72

TB9.8 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 ~~plaintext~~ PINs.

TB9.8 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 clear-text PINs.

Modified p. 73 → 72

TB9.10 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 ~~D1.~~ Keys that are not considered to be PIN or SRED security-related may either …

TB9.10 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. 74 → 73

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 Scheme (Certification Authority) Public Keys• Authentication of issuer key from IC RSA Varies Payment Schemes EMV Public Key Certificate Six per payment schemes

• three payment schemes Payment scheme-specific Designated Key Register Manufacturer Firmware Authentication Root or Sub- CA Public Key Authentication of firmware updates …

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 KPT PIN encipherment between EPP and IC card reader TDES 128 Acquirer 2 or 3 clear- text components One Device Designated Key Register Scheme (Certification Authority) Public Keys• Authentication of issuer key from IC RSA Varies Payment Schemes EMV Public Key Certificate Six per …

Modified p. 74 → 73

TB9.13 Using the key table and API guide as a reference, the tester shall note which keys can be loaded by applications in ~~plaintext.~~

TB9.13 Using the key table and API guide as a reference, the tester shall note which keys can be loaded by applications in clear text.

Modified p. 75 → 74

b) ~~Plaintext~~ cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).

b) Clear-text cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).

Modified p. 75 → 74

Note: Check values ~~for TDES and~~ AES ~~shall~~ use ~~a technique~~ where the KCV is calculated by MACing an ~~all-zero~~ block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a …

Note: Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all-binary zeros block using the key or component as the encryption key, using the leftmost n-bits of the result, where n is at most 24 bits (6 hexadecimal digits/3 bytes). In the second method the KCV is calculated by MACing an all-binary zeros block using the CMAC algorithm …

Modified p. 77 → 76

• 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 ~~plaintext~~ (e.g., for loyalty or other non-PCI cards)

• 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 clear text (e.g., for loyalty or other non-PCI cards)

Removed p. 78

• The PAN itself. If the PAN can be parsed, the sensitive PAN middle digits⎯after the first six left-most digits of the PAN, the Issuer Identification Number, and before trailing digits (max of four) must be encrypted.

Modified p. 80 → 79

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 ~~plaintext~~ 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 clear text or enciphered using an encipherment key of the IC.

Removed p. 87

TB15.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information on non-PIN data entry and prompts for non-PIN data entry, on data entry and erasure, and on how authentic user prompts are generated and administered to determine whether it supports the assertions made by the vendor.

Modified p. 87 → 86

~~TB15.3~~ The tester shall examine the vendor-supplied documentation to verify that the controls to ensure the authenticity and the proper use of the prompts provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.

TB15.2 The tester shall examine the vendor-supplied documentation to verify that the controls to ensure the authenticity and the proper use of the prompts provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.

Modified p. 87 → 86

~~TB15.4~~ The tester shall note how prompts are stored in the POI and cross-reference this with the information provided in Requirement A4.

TB15.3 The tester shall note how prompts are stored in the POI and cross-reference this with the information provided in Requirement A4.

Modified p. 87 → 86

~~TB15.5~~ The tester shall note how prompts can be updated, specifically including information on if the update mechanism requires changing the hardware, firmware, or some other mechanism (for example, changing the POI application).

TB15.4 The tester shall note how prompts can be updated, specifically including information on if the update mechanism requires changing the hardware, firmware, or some other mechanism (for example, changing the POI application).

Modified p. 87 → 86

~~TB15.6~~ Where updates to the prompts require a change to the hardware or firmware, the tester shall confirm from the vendor that this would result in a change to the approved designator of the POI.

TB15.5 Where updates to the prompts require a change to the hardware or firmware, the tester shall confirm from the vendor that this would result in a change to the approved designator of the POI.

Modified p. 87 → 86

~~TB15.7~~ Where updates to the prompts require changes to non-firmware items (such as the POI application), the tester shall confirm that any such non-firmware items must be cryptographically authenticated prior to being installed into the POI. The tester shall detail the cryptographic methods used for this authentication, referencing the key table where necessary.

TB15.6 Where updates to the prompts require changes to non-firmware items (such as the POI application), the tester shall confirm that any such non-firmware items must be cryptographically authenticated prior to being installed into the POI. The tester shall detail the cryptographic methods used for this authentication, referencing the key table where necessary.

Modified p. 87 → 86

~~TB15.8~~ The tester shall note what entities may have access to the keys and mechanisms used to generate the authentication data for such non-firmware items.

TB15.7 The tester shall note what entities may have access to the keys and mechanisms used to generate the authentication data for such non-firmware items.

Modified p. 87 → 86

~~TB15.9~~ The tester shall detail what mechanisms are implemented to ensure that “default” certificates or keys, which may be used for development purposes, are not installed in production devices.

TB15.8 The tester shall detail what mechanisms are implemented to ensure that “default” certificates or keys, which may be used for development purposes, are not installed in production devices.

Modified p. 88 → 87

~~TB15.11~~ For devices where prompts are acquirer-controlled, the tester shall examine logging documentation provided by the vendor of the actual performance of the techniques and control mechanisms specified by the vendor.

TB15.10 For devices where prompts are acquirer-controlled, the tester shall examine logging documentation provided by the vendor of the actual performance of the techniques and control mechanisms specified by the vendor.

Modified p. 88 → 87

~~TB15.12~~ The tester shall perform tests to modify the display content and device usage in order to verify that the controls are effective. The tests shall include performing an intended change/update of software and/or display messages and verifying that the result conforms to the specification of the vendor.

TB15.11 The tester shall perform tests to modify the display content and device usage in order to verify that the controls are effective. The tests shall include performing an intended change/update of software and/or display messages and verifying that the result conforms to the specification of the vendor.

Modified p. 89 → 88

• 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 ~~plaintext~~ 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 clear-text keys or key components.

Modified p. 89 → 88

• Applications must never process or have access to ~~plaintext~~ PINs or ~~plaintext~~ passwords/authentication codes.

• Applications must never process or have access to clear-text PINs or clear-text passwords/authentication codes.

Modified p. 91 → 90

TB16.12 Using the Asset Flow Analysis, the tester shall describe the path of ~~plaintext~~ 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 ~~plaintext~~ PINs.

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.

Modified p. 91 → 90

TB16.13 The tester shall describe the software module/s handling PIN- or SRED-related cryptographic keys. Memory used to persistently or temporarily store ~~plaintext~~ 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 clear-text keys must be separated from the application.

Modified p. 91 → 90

TB16.14 The tester shall review the API guide and source code provided by the vendor to ensure that no ~~plaintext~~ sensitive data is transferred between firmware and application. Sensitive data includes ~~plaintext~~ PINs, ~~plaintext~~ keys, ~~plaintext~~ key components or ~~plaintext~~ passwords/authentication codes.

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.

Modified p. 94 → 93

For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to ~~plaintext~~ cryptographic keys and components, customer PINs, passwords/authentication codes used for entry into sensitive states, or other items of information or configuration which is required to meet the logical and physical requirements.

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.

Modified p. 96 → 95

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 ~~plaintext.~~

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.

Modified p. 96 → 95

TB18.2 The tester shall note whether the POI enforces the use of dual control (within the firmware of the POI) to load these keys. The tester shall reference testing of these dual-control features as part of Requirement B5. If dual control is enforced on the POI for the loading of all ~~plaintext~~ keys, then no further testing is necessary for this requirement.

TB18.2 The tester shall note whether the POI enforces the use of dual control (within the firmware of the POI) to load these keys. The tester shall reference testing of these dual-control features as part of Requirement B5. If dual control is enforced on the POI for the loading of all clear -text keys, then no further testing is necessary for this requirement.

Modified p. 98 → 97

• Security (DTRs B20.24

• ~~B20.30)~~ This is the minimum information that must be presented. Additional information may be presented.

• Security (DTRs B20.24

• B20.31) This is the minimum information that must be presented. Additional information may be presented.

Modified p. 99 → 98

• Outlining methods to check the slot of the customer ICC acceptor for shim devices, as required by DTR ~~A13;~~ or

• Outlining methods to check the slot of the customer ICC acceptor for shim devices, as required by DTR A13, including a diagram of the card slot illustrating the process; or

Modified p. 101 → 100

TB20.28 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B5 and assessed by the PTS laboratory.

TB20.28 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B5 and assessed by the PTS laboratory. The security policy must categorize the key-loading techniques supported as either:

Modified p. 102 → 101

• A ~~plaintext~~ PIN, the PIN block shall be enciphered from the device encrypting the PIN to the ICC reader (the ICC reader will then decipher the PIN for transmission in ~~plaintext~~ to the IC card) in accordance with ISO 9564.

• 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.

Modified p. 102 → 101

• A ~~plaintext~~ PIN, encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the ~~plaintext~~ PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.

• 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.

Modified p. 102 → 101

SCRPs with ICCRs shall support both enciphered and ~~plaintext~~ PIN for offline PIN authentication.

SCRPs with ICCRs shall support both enciphered and clear-text PIN for offline PIN authentication.

Modified p. 102 → 101

• A ~~plaintext~~ PIN from the PIN entry device to the ICC reader is never permitted except when the PIN entry device and ICC reader are integrated into the same secure module.

• A 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.

Modified p. 102 → 101

• In order to receive an approval for offline PIN entry, a device must be capable of supporting both ~~plaintext~~ and enciphered PINs.

• In order to receive an approval for offline PIN entry, a device must be capable of supporting both clear-text and enciphered PINs.

Modified p. 103 → 102

TB21.2 The tester shall confirm from the vendor documentation that the POI supports both ~~plaintext~~ and encrypted offline PIN. The tester shall detail the APIs that are used for these purposes and justify how these ensure that the customer PIN is always encrypted by the firmware of the POI and is never passed to the application in ~~plaintext.~~

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.

Modified p. 103 → 102

TB21.8 The tester shall perform at least two test transactions with a card that requires a ~~plaintext~~ PIN.

TB21.8 The tester shall perform at least two test transactions with a card that requires a clear-text PIN.

Modified p. 105 → 104

PAN data that is encrypted, hashed (with salt), masked or truncated PANs may be outputted from the device. Truncated PANs are typically defined as a maximum of the first six and the last four digits. ~~However, due~~ to ~~differing PAN lengths,~~ the determination must be made if the truncated digits offer sufficient protection against attacks designed to predict valid, full PANs (with longer BIN ranges). This would partially depend on the potential universe of PANs that could be ~~included~~ and …

PAN data that is encrypted, hashed (with salt), masked or truncated PANs may be outputted from the device. Truncated PANs are typically defined as a maximum of the first six and the last four digits. Individual card brands have defined guidance for truncation that varies for individual cards based on PAN length, IIN/BIN type, etc. 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 …

Modified p. 108 → 107

• 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 exploitation, as defined in Appendix B.

• 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.

Modified p. 112 → 111

TC1.1.2 The tester shall verify that the failure, removal, or absence of a PCI-approved secure component does not lead to another approved secure component revealing any PIN-related sensitive ~~information,~~ and does not lead the PIN entry POI terminal to fall back into a non-safe operating mode.

TC1.1.2 The tester shall verify that the failure, removal, or absence of a PCI-approved secure component does not lead to another approved secure component revealing any PIN-related sensitive information and does not lead the PIN entry POI terminal to fall back into a non-safe operating mode.

Modified p. 113 → 112

An overlay attack must require an attack potential of at least 18 for identification and initial exploitation, with a minimum of 9 for exploitation, as defined in Appendix B.

An overlay attack must require an attack potential of at least 18 for identification and initial exploitation, with a minimum of 9 for initial exploitation, as defined in Appendix B.

Modified p. 113 → 112

TC1.2.1 The tester shall develop attack scenario(s) for the fraudulent placement of an overlay over the PIN pad. If an attack scenario can be developed that yields an attack potential of less than 18 per device for identification and initial exploitation or less than 9 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the examples shown in Appendix B …

TC1.2.1 The tester shall develop attack scenario(s) for the fraudulent placement of an overlay over the PIN pad. If an attack scenario can be developed that yields an attack potential of less than 18 per device for identification and initial exploitation or less than 9 per device for 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 …

Modified p. 117 → 116

If commands impacting the correspondence between the display messages and the operating state of the PIN entry device are received from an external ~~device (e.g.,~~ a store ~~controller),~~ the commands enabling data entry must be authenticated.

If commands impacting the correspondence between the display messages and the operating state of the PIN entry device are received from an external device⎯e.g., a store controller⎯ the commands enabling data entry must be authenticated.

Modified p. 117 → 116

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 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. 120 → 119

The objective of this section is to identify all physical interfaces and the corresponding logical protocols that are supported by the device. It is required that a device vendor know of all interfaces and protocols supported by the device and provide details of these protocols and interfaces within documentation.

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.

Modified p. 122 → 121

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. 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 some way). The interfaces must be documented and assessed whether they are used for or have access to …

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 …

Removed p. 125

TD3.1 The tester shall examine relevant documentation, such as a user guide, application developer’s guide, design specifications, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor claims.

Modified p. 125 → 124

~~TD3.2~~ The tester shall examine and assess the distribution process of the security guidance. It must ensure that all necessary users are aware of it and have access to the latest version. The vendor must specify what is the accessibility scope of each document•i.e., indicate which documents are intended as public and which documents have a restricted audience.

TD3.1 The tester shall examine and assess the distribution process of the security guidance. It must ensure that all necessary users are aware of it and have access to the latest version. The vendor must specify what is the accessibility scope of each document•i.e., indicate which documents are intended as public and which documents have a restricted audience.

Modified p. 125 → 124

~~TD3.3~~ The tester shall summarize all the protocols and interfaces provided by the firmware to application developers. The tester shall ensure that each of these protocols and interfaces have associated guidance within vendor documentation that ensures that application developers are guided towards secure use of any interface or protocol.

TD3.2 The tester shall summarize all the protocols and interfaces provided by the firmware to application developers. The tester shall ensure that each of these protocols and interfaces have associated guidance within vendor documentation that ensures that application developers are guided towards secure use of any interface or protocol.

Modified p. 126 → 125

TD4.1 The tester shall examine any relevant ~~documentation, such~~ as a user guide, the application developer’s guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation ~~guidance submitted by the vendor to verify that it supports the vendor claims~~ that each interface ~~is default in~~ a secure or disabled state. ~~When the protocol or interface allows configurable non-secure settings, user guidance to strongly recommend against configuring to non-secure settings must be provided.~~

TD4.1 The tester shall examine any relevant documentation⎯such as a user guide, the application developer’s guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance⎯and confirm that each interface defaults to a secure or disabled state.

Removed p. 127

TD5.1 The tester shall examine any relevant documentation, such as a user guide, application developer guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify that it supports the vendor’s key-management security claims covering the use of keys and certificates.

Modified p. 127 → 126

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. 127 → 126

~~TD5.2~~ The tester shall examine the key-management security guidance, which must:

TD5.1 The tester shall examine the key-management security guidance, which must:

Modified p. 127 → 126

~~TD5.3~~ The tester shall verify whether the cipher suites used by the declared security protocol are in line with the PCI PTS POI Technical FAQs. The tester shall perform any additional tests necessary to validate the device’s documentation.

TD5.2 The tester shall verify whether the cipher suites used by the declared security protocol are in line with the PCI PTS POI Technical FAQs. The tester shall perform any additional tests necessary to validate the device’s documentation.

Modified p. 129 → 128

TD6.1 The tester shall ~~examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules~~ and ~~specifications, or the implementation guidance submitted by the vendor to verify~~ the documentation clearly defines the declared security protocol for each interface.

TD6.1 The tester shall review vendor documentation and describe how the documentation clearly defines the declared security protocol for each interface.

Modified p. 130 → 129

TD7.1 The tester shall ~~examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules~~ and ~~specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that~~ the declared security protocol for each interface provides data confidentiality.

TD7.1 The tester shall review vendor documentation and describe how the declared security protocol for each interface provides data confidentiality.

Modified p. 131 → 130

TD8.1 The tester shall ~~examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules~~ and ~~specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that~~ the declared security protocol for each interface provides data integrity.

TD8.1 The tester shall review vendor documentation and describe how the declared security protocol for each interface provides data integrity.

Modified p. 132 → 131

TD9.1 The tester shall ~~examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules~~ and ~~specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that~~ the declared security protocol provides mutual authentication.

TD9.1 The tester shall review vendor documentation and describe how the declared security protocol provides mutual authentication.

Modified p. 133 → 132

TD10.1 The tester shall ~~examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules~~ and ~~specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that~~ the declared security protocol for each interface provides exception handling and replay detection.

TD10.1 The tester shall review vendor documentation and describe how the declared security protocol for each interface provides exception handling and replay detection.

Removed p. 134

TD11.1 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that the declared security protocol for each interface provides session management.

Modified p. 136 → 135

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 ~~WPA~~ and/or ~~WPA2~~ 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. 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.

Modified p. 137 → 139

• When these procedures are in use, samples of the process in operation. For this purpose

•in a timeframe of 3, 6, or 12 months

•samples can be randomly collected and validated. Example: For ~~E2,~~ the lab can randomly select a few occasions and ask for the related log belonging to the dual control or standardized cryptographic authentication procedure used.

• When these procedures are in use, samples of the process in operation. For this purpose

•in a timeframe of 3, 6, or 12 months

•samples can be randomly collected and validated. Example: For E3, the lab can randomly select a few occasions and ask for the related log belonging to the dual control or standardized cryptographic authentication procedure used.

Modified p. 139 → 141

~~TE1.4~~ The tester shall interview those responsible for the change-control processes

•including engineers and programming staff, supervisory staff, technical management, etc.

TE1.5 The tester shall interview those responsible for the change-control processes

•including engineers and programming staff, supervisory staff, technical management, etc.

Modified p. 139 → 141

~~TE1.5~~ The tester shall validate that either:

TE1.6 The tester shall validate that either:

Modified p. 140 → 142

Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. This is true regardless of how labelled, e.g., (OS, EPROM code, DLL’s, parameter files, applications, kernel code). Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, except for SCRs intended for use with COTS devices and SCRPs, where all code is considered firmware.

Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. This is true regardless of how labelled, e.g., (OS, EPROM code, DLL’s, parameter files, applications, kernel code). This includes any code that is not in the Vendor Domain as defined in Appendix G, “Domain-Based Asset Flow Analysis.” Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, …

Modified p. 140 → 142

~~Firmware is any code, regardless of how labelled, that is not in the Vendor Domain as defined in Appendix G, “Domain-Based Asset Flow Analysis.”~~ TE2.1 The tester shall examine details provided by the vendor that the documented process explicitly addresses how testing/auditing has been carried out to check for unauthorized and undocumented functions.

TE2.1 The tester shall examine details provided by the vendor that the documented process explicitly addresses how testing/auditing has been carried out to check for unauthorized and undocumented functions.

Modified p. 141 → 143

TE2.10 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable process that shows the code review and security testing have been ~~performed,~~ and requiring sign-off by the person(s) performing the code review and security testing. The tester shall confirm that the process will show any problems noted during the code review and security testing.

TE2.10 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable process that shows the code review and security testing have been performed and requiring sign-off by the person(s) performing the code review and security testing. The tester shall confirm that the process will show any problems noted during the code review and security testing.

Removed p. 143

TE3.4 The tester shall examine a sample of documentation for firmware authentication (e.g., signing) and storage during manufacturing, including change-control logs and firmware validation procedure to ensure procedures are followed.

Modified p. 143 → 145

~~TE3.3~~ The tester shall interview those responsible for the firmware control processes

•including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.

TE3.4 The tester shall interview those responsible for the firmware control processes

•including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.

Modified p. 144 → 146

TE4.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 detail the hardware components used and the hardware-component control processes and procedures for storage and verification during the manufacturing process including hardware-component identification verification, with the procedures checked in ~~TE1.1.~~

TE4.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 detail the hardware components used and the hardware-component control processes and procedures for storage and verification during the manufacturing process including hardware-component identification verification, with the procedures checked in TE1.

Modified p. 144 → 146

• Providing details on how components are stored before being assembled into devices.

• Providing details on how hardware components are stored before being assembled into devices.

Removed p. 145

TE5.4 The tester shall examine a sample of documentation for firmware control and storage during manufacturing, including change-control logs and firmware validation procedure to ensure the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.

Modified p. 145 → 147

~~TE5.3~~ The tester shall interview those responsible for the software (e.g., firmware) control processes

TE5.4 The tester shall interview those responsible for the software (e.g., firmware) control processes

Removed p. 146

TE6.4 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.

Modified p. 146 → 148

~~TE6.3~~ The tester shall interview those responsible for the post-production control processes

TE6.4 The tester shall interview those responsible for the post-production control processes

Removed p. 147

TE7.4 The tester shall examine a sample of documentation for secret information, including user documentation, and device-validation procedures to ensure procedures are followed.

Modified p. 147 → 149

~~TE7.3~~ The tester shall interview those responsible for the control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TE7.4 The tester shall interview those responsible for the control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Removed p. 148

The PCI Terminal Software Security Best Practices Guidance document can provide additional guidance for software development and testing.

TE8.3 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. 148 → 150

TE8.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the design and development processes and procedures to ensure security measures are followed during the development and maintenance of the POI security- related components. Furthermore, the approved documentation must justify that the security measures provide the necessary level of protection to maintain the integrity of the POI security- related ~~components Where required to validate via site inspection, the tester shall complete the …~~

TE8.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the design and development processes and procedures to ensure security measures are followed during the development and maintenance of the POI security- related components. Furthermore, the approved documentation must justify that the security measures provide the necessary level of protection to maintain the integrity of the POI security- related components.

Modified p. 148 → 150

~~TE8.2~~ The tester shall interview those responsible for component control processes

•including engineers and line staff, supervisory staff, technical management, etc.

TE8.3 The tester shall interview those responsible for component control processes

•including engineers and line staff, supervisory staff, technical management, etc.

Modified p. 148 → 150

TE8.4 The tester shall observe the approved ~~development~~ component control procedures to ensure security measures are followed during the development and maintenance of the POI ~~security- related~~ components.

TE8.4 The tester shall observe the approved component control procedures to ensure security measures are followed during the development and maintenance of the POI security-related components.

Removed p. 149

TE9.4 The tester shall examine a sample of approved documentation for repair, including the resetting of tamper mechanisms, inspection and post-inspection storage, including inventory logs, repair logs, shipping documentation, and device-validation procedures to ensure procedures are followed.

Modified p. 149 → 151

Device undergoing repair must be in a dual-access-controlled ~~area.~~

Device undergoing repair must be in a dual-access-controlled area or decommissioned such that all sensitive information and CSPs are cleared from the device prior to being returned to the device manufacturer..

Modified p. 149 → 151

~~TE9.3~~ The tester shall interview those responsible for repair, inspection, and post-inspection control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TE9.4 The tester shall interview those responsible for repair, inspection, and post-inspection control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Modified p. 151 → 153

TE11.2 The ~~test~~ shall examine the vendor’s sign-off form specified in Requirement E10 to ensure that it has been completed and signed off by management.

TE11.2 The tester shall examine the vendor’s sign-off form specified in Requirement E10 to ensure that it has been completed and signed off by management.

Modified p. 153 → 155

• When these procedures are in use, samples of the process in operation. For this purpose

•in a timeframe of 3, 6, or 12 months

•samples can be randomly collected and validated. Example: For ~~M3,~~ the lab can randomly select a few occasions and ask for the related log belonging to the received shipments proving that the packaging is validated on tamper evidence.

• When these procedures are in use, samples of the process in operation. For this purpose

•in a timeframe of 3, 6, or 12 months

•samples can be randomly collected and validated. Example: For F3, the lab can randomly select a few occasions and ask for the related log belonging to the received shipments proving that the packaging is validated on tamper evidence.

Modified p. 153 → 155

~~TF1.2~~ The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence for customers that provides instruction on validation of the authenticity and integrity of the POI. Alternatively, the approved documentation must detail how the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored …

TF1.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence for customers that provides instruction on validation of the authenticity and integrity of the POI. Alternatively, the approved documentation must detail how the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored …

Removed p. 154

TF1.5 The tester shall examine a sample of documentation for tamper protection, inspection and transfer documentation, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed and describe how this shows compliance to this requirement. .

Modified p. 154 → 156

~~TF1.6~~ The tester shall observe the shipping process to ensure that customers are provided documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI or alternatively, 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.

TF1.5 The tester shall observe the shipping process to ensure that customers are provided documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI or alternatively, 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.

Removed p. 155

TF2.3 The tester shall examine a sample of transfer documentation, including inventory logs, and shipping documentation, to ensure procedures are followed.

Modified p. 155 → 157

~~TF2.2~~ The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TF2.3 The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Removed p. 156

TF3.3 The tester shall examine a sample of documentation for tamper protection, inspection and transfer documentation, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed.

Modified p. 156 → 158

~~TF3.2~~ The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TF3.3 The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Removed p. 157

TF4.3 The tester shall examine a sample of documentation for device-development security, including user documentation, and component validation procedures to ensure procedures are followed.

Modified p. 157 → 159

~~TF4.2~~ The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

TF4.3 The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

Removed p. 158

TF5.3 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.

Modified p. 158 → 160

~~TF5.2~~ The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

TF5.3 The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

Modified p. 160 → 162

~~TF7.2~~ The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.

TF7.3 The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.

Modified p. 160 → 162

~~TF7.3~~ The tester shall sample the devices to ensure that each visible identifier is unique and is consistent with the identifiers checked with the change-control procedure in as required in E1.

TF7.4 The tester shall sample the devices to ensure that each visible identifier is unique and is consistent with the identifiers checked with the change-control procedure in as required in E1.

Modified p. 169 → 171

Note: This option does not preclude the use of privacy mechanisms as defined in ~~A1,~~ but allows less restrictive physical mechanisms.

Note: This option does not preclude the use of privacy mechanisms as defined in A1 but allows less restrictive physical mechanisms.

Removed p. 200

Algorithm TDES IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits: 112 2048 224 2048/224 128 1 Except as noted, the use of SHA-1 is prohibited for all digital signatures used on the device in connection with meeting PCI security requirements. This includes certificates used by the device that are non-device specific and part of a vendor PKI, up to and including a vendor root certificate. The only exception to this is that the initial code on ROM that initiates upon the device start may authenticate itself using SHA-1, but all subsequent code must be authenticated using SHA-2.

Modified p. 200 → 202

The following are the minimum key sizes 3 and parameters for the algorithm(s) in question that must be used in connection with key transport, exchange, or establishment and for data protection in connection with these requirements. Other key sizes and algorithms may be supported for non-PCI payment-brand- relevant transactions:

The following are the minimum key sizes 3 and parameters for the algorithm(s) in question that must be used in connection with key transport, exchange, or establishment and for data protection in connection with these requirements. Other key sizes and algorithms may be supported for non-PCI payment-brand- relevant transactions: IFC (RSA) ECC (ECDSA, EdDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number 112 2048 224 2048/224 128 1 Except as noted, the use of SHA-1 is …

Modified p. 201 → 203

Algorithm TDES IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Key size in number of bits: 112 1024 160 1024/160

• Key size in number of bits: 168 2048 224 2048/224

• Key size in number of bits:

• 3072 256 3072/256 128 Key size in number of bits:

• 7680 384 7680/384 192 Key size in number of bits:

• 15360 512 15360/512 256 TDES refers to TDES keys with non-parity bits. The RSA key size refers to the size of …

• 15360 512 15360/512 256 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. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup.

Modified p. 201 → 203

• ECC implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see ~~FIPS 186-4).~~ The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity must generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See ~~FIPS 186-4~~ for methods of generating d and Q.)

• ECC implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see NIST SP 800-186). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity must generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See NIST SP 800-186 for methods of generating d and Q.)

Modified p. 201 → 203

• 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 ~~should~~ 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 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).

Modified p. 213 → 215

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 ~~plaintext~~ of the data must not be disclosed. In Table H1 below, four 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 clear text of the data must not be disclosed. In Table H1 below, four Security Domains are defined from higher-protection requirements to lesser requirements:

Removed p. 214

Although account-data protection keys require a lesser attack potential⎯i.e., 26 points⎯this is still in excess of the related SRED security, requiring 20 points or less. Therefore, keys constitute a separate asset class in this environment, too.

PANs must not be disclosed, except as allowed in PCI DSS, e.g. when displayed the first six and last four digits are the maximum number of digits to be displayed. Both PAN and prompts must maintain integrity.

Modified p. 214 → 216

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 ~~not possible by~~ any change of the code of this domain to gain any access to assets in ~~that~~ domain or change the behavior of ~~that domain.~~ It is not sufficient that the access is not foreseen, …

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 …

Modified p. 214 → 216

If confidential assets are encrypted using keys of at least the next higher domain, the encrypted asset is not a confidential asset. ~~Keys~~ from the Key domain may encrypt other keys of the Key domain. ~~Note~~ that the encrypting keys must at least have the same cryptographic strength as the keys they ~~encrypt.~~

If confidential assets are suitably encrypted using keys of at least the next higher domain, the encrypted asset is not a confidential asset. For example, keys from the PIN Key domain may encrypt other keys of the PIN Key domain, or of the Non-PIN Key domain. “Suitably encrypted” here means that the encrypting keys must at least have the same cryptographic strength as the keys they encrypt, use appropriate modes of operation, and meet any other PTS requirements such as …

Modified p. 214 → 217

Assets that require integrity protection may be accompanied by integrity/authenticity tokens⎯e.g., MAC, HMAC, or a signature. The critical time for an attack is the time span from the token validation to the processing of the asset. Additionally, unbundling must be prevented⎯i.e., it must not be possible to use a foreign token with the asset.

Assets that require integrity or integrity-plus-authenticity protection may be accompanied by integrity/authenticity tokens⎯e.g., hash, MAC, HMAC, or a signature. Keyed tokens must be used for any asset that requires integrity plus authenticity. The critical time for an attack is the time span from the token validation to the processing of the asset. Additionally, unbundling must be prevented⎯i.e., it must not be possible to use a foreign token with the asset.

Modified p. 214 → 217

For example, it is valid to store keys in a domain of lesser security⎯if the keys are ~~encrypted and MAC’d, the MAC contains the key name, and the keys~~ and algorithms used for encryption and MAC are adequately strong. The modules and components performing the cryptography and processing the validated or ~~plaintext~~ assets necessarily belong to the Key domain. This represents the idea of firmware in previous PCI 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 clear-text assets necessarily belong to the PIN Key domain. This represents the idea of firmware in previous PCI PTS POI requirements.

Modified p. 215 → 217

Firmware and Process Spaces While hardware tagging is quite simple⎯i.e., any single component may or may not process or store an ~~asset ⎯the~~ situation is more complex with software. In this section we define some ~~terms.~~

Firmware and Process Spaces While hardware tagging is quite simple⎯i.e., any single component may or may not process or store an asset⎯the situation is more complex with software. In this section we define some terms to help clarify the process.

Modified p. 216 → 218

1. Consider the software in operational state and perform all transactions⎯e.g., key loading, online, offline encrypted PIN, offline ~~plaintext~~ 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 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.

Modified p. 216 → 218

Whatever software remains untagged by this algorithm is in the vendor domain⎯i.e., no firmware in the sense of the DTR. ~~All other software parts are then assigned a proper firmware domain.~~

Whatever software remains untagged by this algorithm is in the vendor domain⎯i.e., not firmware in the sense of the DTR.

Removed p. 217

Table G2: Asset Tagging Examples Asset Protection Domain PIN encryption key Confidentiality / integrity Key domain Key decryption key Confidentiality / integrity Key domain Code validation public key Integrity Key domain PIN Confidentiality PIN domain PAN Confidentiality / integrity Data domain Display prompt Integrity Data domain EMV public card key Integrity Key Domain Magstripe data Confidentiality / integrity Data Domain Key for magstripe data (e.g., SRED) Confidentiality / integrity Key Domain EMV Level 2 code Integrity Data Domain Key matrix signals Confidentiality PIN domain Touch Position Confidentiality PIN domain

Modified p. 217 → 219

Applications An application in the sense of a PCI PTS device is code that is for any reason not considered firmware. The developer produces guidance on how such code shall be developed and installs procedures to verify compliance with this guidance as a precondition for signing the code. Application code must ~~be authentic~~ to be installed.

Applications An application in the sense of a PCI PTS device is code that is for any reason not considered firmware. The developer produces guidance on how such code shall be developed and installs procedures to verify compliance with this guidance as a precondition for signing the code. Application code must have its authenticity verified by the POI firmware to be installed.

Modified p. 217 → 219

PCI PTS allows applications in the data domain and the vendor domain. Applications therefore can never handle ~~plaintext~~ PIN or keys of the ~~key domain.~~

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).

Modified p. 217 → 219

Applications shall be segregated from ~~other~~ firmware, including firmware of the same ~~domain~~ and other applications at least from different issuers. This requires applications to run in unique process spaces. The tester shall verify that the separation of process spaces is effective for application ~~sandboxing, which obviously exceeds the requirements for domain separation.~~

Applications shall be segregated from all firmware, including firmware of the same domain, and other applications at least from different issuers. This requires applications to run in unique process spaces. The tester shall verify that the separation of process spaces is effective for application sandboxing.

Removed p. 218

Structure and Contents The developer shall provide an Asset Flow Analysis as evidence for the entire scoping of the PCI PTS testing. The asset flow must be complete and unambiguous. Verification of the asset flow is a critical task in the assessment. The following requirements describe the content of the analysis and test requirements for verification.

• The vendor shall list all interfaces accessible without tampering the device. This explicitly includes interfaces that are not visible on the PCB but are available after removing any covers.

• The tester shall visually inspect the device to verify that all accessible interfaces have been listed.

• If interfaces connect to hardware subsystems that support multiple process spaces, the vendor shall clearly state which process space handles the low-level communication with the respective interface. Note that in most cases this will pertain to some kind of operating system.

• The tester shall consider any relevant documentation to …

Modified p. 218 → 220

If the design can exclude that the display shows anything that the cardholder could somehow mistake for a PIN prompt, then key matrix signals and touch position data do not have to be treated as confidential. ~~The vendor shall present strong evidence⎯e.g., hard-coded prompts⎯that potentially misleading prompts cannot be displayed while the keypad is in clear-text mode.~~

If the design can exclude that the display shows anything that the cardholder could somehow mistake for a PIN prompt, then key matrix signals and touch position data do not have to be treated as confidential.

Modified p. 218 → 220

In common designs using a security processor (SP) and an application processor (AP), with the AP driving the display, the AP is at least part of the data domain. ~~This is also the case if~~ the SP is expected to verify the prompt before ~~display.~~

In common designs using a security processor (SP) and an application processor (AP), with the AP driving the display, the AP is at least part of the data domain. Even in cases where the SP is expected to verify the prompt before display, an AP will usually require the ability to authenticate its own firmware or application code. This will result in the AP being considered in at least the Non-PIN Key domain.

Removed p. 219

• For hardware components, the tester shall verify that no boundary intersects a single chip. Exceptions for SoC with dedicated firewalling though uncommon may exist.

• For software components, the tester shall verify that no boundary intersects a process space.

• The vendor shall describe which kinds of transactions and other PCI-related communications are supported by the device. Typical transactions are online PIN with MK/SK, online PIN with DUKPT, offline PIN with card public key, etc. Transactions that require a different key management shall be listed separately. “Other communication” refers to any other security-related communication by firmware or applications. At a minimum, it relates to firmware updates and key loading.

• The tester shall verify that all possible transactions for the device type and the claimed key- management schemes are listed.

• The tester shall verify that there are key-loading communications for each component storing keys.

• The tester shall verify that there is at …

Removed p. 220

• If the device supports applications, the vendor shall describe how the applications are separated from firmware and from each other. If the applications may communicate with interfaces not considered firmware, these interfaces shall be described at the same level as those for firmware.

• The tester shall verify that the process spaces for applications are clearly defined.

• The tester shall verify that the process spaces for applications are distinct from those of firmware and other applications.

• The tester shall perform asset tagging on each application process space and verify that it is in the data domain or vendor domain.

• All hardware and software tagged as vendor domain may be taken out of scope. As such, the boundary of the device is clearly defined. It may also be used as guidance for the security officer of the vendor to decide which modifications may clearly be covered by wildcards.

• The domain assigned …

Modified p. 223

Figure G-2: Asset Flow Description ~~6 with 51:~~ Manual amount entry with offline encrypted ~~PIN~~ 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 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.

Modified p. 225

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 ~~PIN~~ Issuer CA Key Resides in Security Controller Key ICC Public Key Key determined valid after signature verification in Security Controller Certificate read from ICC Key PIN Read from Keypad Encrypted …

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. 226

Component Immediate Assets Effective Domain ICCR ~~PAN~~ Data Security Controller PAN, PAN Key, Issuer CA Key, ICC Public Key, PIN ~~Key~~ Keypad PIN PIN Display Prompt Data Payment Application Prompt Data Linux OS Payment Application, Prompt ~~Data~~ Application Controller Linux OS, Prompt ~~Data~~ All remaining components are tagged as vendor domain for this particular use-case. The effective tagging for each component is the most secure domain assigned.

Component Immediate Assets Effective Domain ICCR PAN, encrypted PIN (vendor domain due to encryption) Data Security Controller PAN, PAN Key, Issuer CA Key, ICC Public Key, PIN PIN-Key Keypad PIN PIN Display Prompt Data Payment Application Prompt Data Linux OS Application authentication keys, Payment Application, Prompt Non-PIN Key Application Controller Linux authentication keys, Linux OS, Prompt Non-PIN Key All remaining components are tagged as vendor domain for this particular use-case. The effective tagging for each component is the most secure …

Modified p. 227

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, ~~plaintext~~ PINs, ~~plaintext~~ PANs, display prompts, and ~~plaintext~~ 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, clear-text PINs, clear-text PANs, display prompts, and clear-text card reader data. Please refer to Appendix G for definition of assets.

Modified p. 227

• Processes ~~plaintext~~ keys, which includes using these keys, or passwords relevant to PIN or account- data protection;

• Processes clear-text keys, which includes using these keys, or passwords relevant to PIN or account- data protection;

Modified p. 227

• Processes ~~plaintext~~ PINs, PANs, or card-reader data;

• Processes clear-text PINs, PANs, or card-reader data;

Modified p. 227

• Processes ~~plaintext~~ input from keypads, touchscreens, or any other input device;

• Processes clear-text input from keypads, touchscreens, or any other input device;

Modified p. 228

Tamper sensors Security CPUs often support tamper or removal detection. ~~Otherwise~~ these features are mostly implemented using GPIO and appropriate software. The corresponding signals available at the CPU contacts are sensitive signals in the sense described above.

Tamper sensors Security CPUs often support tamper or removal detection. Otherwise, these features are mostly implemented using GPIO and appropriate software. The corresponding signals available at the CPU contacts are sensitive signals in the sense described above.

Modified p. 229

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 ~~plaintext~~ 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 …

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, …

Modified p. 231

If the detailed test procedures and results for whatever reason cannot be made available, PCI may accept reports from other PCI labs or attested to by trusted third parties⎯e.g., a CAST certification or a CC certification involving assurance to AVA_VAN.5. As an example, Table ~~I-1~~ summarizes the information that shall be supplied to justify re-use.

If the detailed test procedures and results for whatever reason cannot be made available, PCI may accept reports from other PCI labs or attested to by trusted third parties⎯e.g., a CAST certification or a CC certification involving assurance to AVA_VAN.5. As an example, Table H-1 summarizes the information that shall be supplied to justify re-use.

Document Comparison

Content Changes