Document Comparison
PCI_PTS_POI__DTRs_v6-1.pdf
→
PCI_PTS_POI_DTRs_v6.2.pdf
95% similar
238 → 237
Pages
90838 → 91364
Words
144
Content Changes
Content Changes
144 content changes. 244 administrative changes (dates, page numbers) hidden.
Added
p. 35
TA10.2 For SCRPs, the tester shall confirm that the SCRP does not contain a hybrid reader.
Added
p. 69
Note: Multiple individuals who collectively possess the necessary expertise who meet the independence criteria can be used. When using a group approach, each individual must have at least 10 years of experience in the relevant subject and must subscribe to an ethical code of conduct.
Added
p. 80
TB11.10 For SCRPs, the tester shall verify that the SCRP performs PIN translation from encryption using a tokenized PAN under the AES key shared with the external system (such as a payment application on a mobile phone) to encryption using the real PAN under a different key shared with the host. This key shared with the host may be either TDES or AES.
Added
p. 98
TB20.6 The tester shall confirm the security policy defines and documents all hardware and firmware version options, both security and non-security relevant. Security-relevant options must be exhaustively defined and documented. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
TB20.11 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods TB20.12 The tester shall confirm that the security policy defines guidance for the proper implementation of any Open Protocols that are part of the approval.
TB20.33 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR D12 for any device implementing BLE. Specifically, implementations must use version 4.2 or higher and use LE Security …
TB20.11 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods TB20.12 The tester shall confirm that the security policy defines guidance for the proper implementation of any Open Protocols that are part of the approval.
TB20.33 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR D12 for any device implementing BLE. Specifically, implementations must use version 4.2 or higher and use LE Security …
Added
p. 110
The SCRP may continue to provide functions necessary for the resumption of payment acceptance and processing by the SCRP, even when an enablement token is not provided within the acceptable time period. Examples of functions permitted in the absence of an enablement token may include the ability to establish a secure channel with the external system interfacing to the SCRP (such as a payment application on a mobile phone), providing data required for the attestation of the SCRP device, and the supply of random data for the purposes of seeding external DRNGs.
TB26.2 The tester shall confirm that an enablement token is required to be provided to the SCRP upon power-up, prior to the SCRP accepting payment cards, except in the case of offline (store-and- forward) payment. The token may be replayed as long as not expired.
TB26.2 The tester shall confirm that an enablement token is required to be provided to the SCRP upon power-up, prior to the SCRP accepting payment cards, except in the case of offline (store-and- forward) payment. The token may be replayed as long as not expired.
Added
p. 234
• This section defines and documents all hardware and firmware version options, both security and non-security relevant. Security-relevant options must be exhaustively defined and documented. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 6.1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 6.2
Modified
p. 9
• For each DTR, the DTR definition and guidance (if any), followed by the sequence of all DTR work items (e.g., TA1.1, TA1.2, TA1.3, … etc.), directly preceding the report’s explanations on each item. Cited DTRs text shall match the current DTRs version and shall be clearly distinguishable from Laboratory-generated report text. ‘N/A’ verdicts shall be clearly identifiable as such.
• For each DTR, the DTR definition and guidance (if any), followed by the sequence of all DTR work items⎯e.g., TA1.1, TA1.2, TA1.3, … etc.⎯directly preceding the report’s explanations on each item. Cited DTRs text shall match the current DTRs version and shall be clearly distinguishable from Laboratory-generated report text. ‘N/A’ verdicts shall be clearly identifiable as such.
Modified
p. 12
• Tamper switches and components connecting to these SCRPs must be capable of providing information to a query from the PIN CVM application to indicate if in a tamper state.
• Tamper switches and components connecting to these SCRPs must be capable of providing information to a query from an external source (such as a payment application on a mobile phone) to indicate if in a tamper state.
Modified
p. 13
TA1.3 The tester shall describe any physical shielding (i.e., active, passive) or other chip or embedded physical protections that any microprocessors used in the device that contain clear-text secret or sensitive data, and how these are effective against tampering the physical package(s)⎯e.g., die encasement. The tester shall describe any physical barriers that surround microprocessors in the device, and state whether/how these totally envelop or partly surround microprocessors, and whether such barriers are tamper-responsive.
TA1.3 The tester shall describe any physical shielding⎯i.e., active, passive⎯or other chip or embedded physical protections that any microprocessors used in the device that contain clear- text secret or sensitive data, and how these are effective against tampering the physical package(s)⎯e.g., die encasement. The tester shall describe any physical barriers that surround microprocessors in the device, and state whether/how these totally envelop or partly surround microprocessors, and whether such barriers are tamper-responsive.
Modified
p. 15
TA1.20 For SCRPs, the tester shall validate that the SCRP is capable of providing information to a query from the PIN CVM application to indicate if in a tamper state.
TA1.20 For SCRPs, the tester shall validate that the SCRP is capable of providing information to a query from an external source (such as a payment application on a mobile phone) to indicate if in a tamper state.
Modified
p. 17
TA2.10 The tester shall describe the different attack paths considered. Using the format shown in Appendix B and providing images allowing the principle steps in the analysis to be understood, the tester shall generate sensitive keypad attack calculations using different attack techniques on the POI, and present the most feasible attacks for capturing PIN, and if SRED, the most feasible attack for capturing PAN data
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
TA2.10 The tester shall describe the different attack paths considered. Using the format shown in Appendix B and providing images allowing the principal steps in the analysis to be understood, the tester shall generate sensitive keypad attack calculations using different attack techniques on the POI, and present the most feasible attacks for capturing PIN, and if SRED, the most feasible attack for capturing PAN data
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
•i.e., presenting at least one distinct example of each. The attacks should be dissimilar in approach …
Removed
p. 23
Devices that use a randomized touchscreen layout
•i.e., for each PIN entry the positioning of the digits is different
•the signals should not contain any information that leads to PIN leakage. The lab must still validate through testing that the keypad is truly random.
The attack is considered successful if any PIN digit is discovered.
•i.e., for each PIN entry the positioning of the digits is different
•the signals should not contain any information that leads to PIN leakage. The lab must still validate through testing that the keypad is truly random.
The attack is considered successful if any PIN digit is discovered.
Modified
p. 25
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 are not subject to this requirement.
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 are not subject to this requirement.
Modified
p. 26
e) Describe why invasive and/or glitch attacks intending to change flags (e.g., flipping a bit value enabling a defense) are effectively obstructed.
e) Describe why invasive and/or glitch attacks intending to change flags⎯e.g., flipping a bit value enabling a defense⎯are effectively obstructed.
Modified
p. 29
The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no older than the last prior major version (i.e., v5.x or other v6.x reviews may supplement work done in the current review) of the PCI POI Security Requirements prior to the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A7 security …
The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no older than the last prior major version⎯i.e., v5.x or other v6.x reviews may supplement work done in the current review⎯of the PCI POI Security Requirements prior to the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A7 security requirements.
Modified
p. 30
“Non-PIN data” refers to numeric data other than the PIN that is entered via the keypad. It does not include control inputs such as “enter,” “cancel,” etc. It also does not apply to data entered while the device is in special modes (e.g., maintenance) that are not intended to be accessed by cardholders and merchants.
“Non-PIN data” refers to numeric data other than the PIN that is entered via the keypad. It does not include control inputs such as “enter,” “cancel,” etc. It also does not apply to data entered while the device is in special modes⎯e.g., maintenance⎯that are not intended to be accessed by cardholders and merchants.
Modified
p. 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. SCRPs must not contain a hybrid (combined contact chip and MSR) reader.
Modified
p. 35
TA10.3 The tester shall describe whether the POI allows for capture of data from the magnetic stripe of a payment card. If the device processes magnetic-stripe information but does not integrate a magnetic-stripe card reader, the tester shall detail how magnetic-stripe information is obtained by the POI and provide any APIs used for this purpose. The tester shall only complete steps A10.3 through A10.9 if the POI has an integrated magnetic-stripe card reader.
Modified
p. 35
TA10.4 The tester shall describe the location and operation of the magnetic-stripe card reader. The tester shall show one or more images of the device’s magnetic-stripe reader and associated hardware to support any conclusions.
Modified
p. 35
TA10.5 The tester shall describe the path from the magnetic-stripe card reader to the security processor, including any cables, connectors, or other sub-elements on this path.
Modified
p. 35
TA10.6 The tester shall describe whether the magnetic-stripe card reader implements logical protections (for example, encryption). The tester shall detail the following:
Modified
p. 35
TA10.7 If the device implements physical protections for the magnetic-stripe card reader, either in addition to or in lieu of logical protections, the tester shall detail the physical protections implemented to protect this path. The tester shall justify how this is sufficient to protect the entire path of the magnetic-stripe card signals from the read head to the security processor, including all vias, traces, connectors, and the pins on the read head itself.
Modified
p. 35
TA10.8 The tester shall provide accurate measurements of any free space around the magnetic-stripe read head. The tester shall justify why placement of a secondary read head (even one that is very small and/or thin) is made infeasible by the POI design, either through lack of space and/or through the physical protections of the POI. The tester shall check for any free space on the opposite site of the magnetic-stripe read head to analyze whether a reader with the capability …
Modified
p. 35
TA10.9 The tester shall identify whether the device implements any physical or logical ICCR/MSR combinations•for example, if the hybrid reader facilitates both skimming of the magnetic stripe and capture of the PIN during an ICCR “dip” read operation. In this case, the tester shall describe how there is no residual vulnerability to attacks on the combination reader intending to harvest both clear-text PINs and magnetic-stripe data.
Modified
p. 35
TA10.10 The tester shall explain how the POI is protected against attacks for MSR data from all sides of the POI, including the front and rear of the device.
Modified
p. 36
•including passive parts or segments, connectors, or other items
•that are connected to the path of the digitized contactless card data.
TA10.12 The tester shall list any components and describe the path from the point of digitalization to the secure processor
•including passive parts or segments, connectors, or other items
•that are connected to the path of the digitized contactless card data.
•including passive parts or segments, connectors, or other items
•that are connected to the path of the digitized contactless card data.
Modified
p. 36
TA10.13 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. 36
TA10.14 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 …
Modified
p. 37
• Manually entered security validation value (e.g., CVV2, CVC2, and CID2);
• Manually entered security validation value⎯e.g., CVV2, CVC2, and CID2;
Modified
p. 43
The ICC reader is constructed so that wires running out of the slot of the IC reader to a recorder or a transmitter (an external bug) can be observed by the cardholder.
The ICC reader is constructed so that wires running out of the slot of the IC reader to a recorder or transmitter (an external bug) can be observed by the cardholder.
Modified
p. 43
The intent of requirement A14 is to make successful installation of PIN-disclosing bugs via the card slot infeasible. To meet this requirement the cardholder must have at least the ability to inspect the entry. And where the slot is neither positioned straight towards the cardholder nor upward facing (i.e., it is downward facing), a design has to meet the following criteria:
The intent of requirement A14 is to make successful installation of PIN-disclosing bugs via the card slot infeasible. To meet this requirement the cardholder must have at least the ability to inspect the entry. And where the slot is neither positioned straight towards the cardholder nor upward facing ⎯i.e., it is downward facing⎯a design has to meet the following criteria:
Modified
p. 49
TB2.1 The tester shall verify that the device supports firmware updates, and the vendor has a methodology for deploying updates to the device as they become available (such as a Terminal Management System).
TB2.1 The tester shall verify that the device supports firmware updates, including updates from a remote host, and that the vendor has a methodology for deploying updates remotely to the device as they become available (such as a Terminal Management System).
Modified
p. 53
• Software is only signed using a secure cryptographic device (e.g., smartcard) provided by the terminal vendor.
• Software is only signed using a secure cryptographic device⎯e.g., smartcard⎯provided by the terminal vendor.
Modified
p. 53
All executable files must be signed. By default, all other files should also be signed unless there is clearly documented justification why a signature is not required (i.e., the file cannot affect the security of the device).
All executable files must be signed. By default, all other files should also be signed unless there is clearly documented justification why a signature is not required⎯i.e., the file cannot affect the security of the device.
Modified
p. 54
TB3.5 If the POI implements a touchscreen for PIN entry, the tester shall verify that it does not provide visual indication of any of the digits entered, e.g., no “button highlight” is used.
TB3.5 If the POI implements a touchscreen for PIN entry, the tester shall verify that it does not provide visual indication of any of the digits entered⎯e.g., no “button highlight” is used.
Modified
p. 56
TB4.1 The tester shall verify that
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction iscompleted and that all sensitive data is included. Passwords/authentication codes, clear-text PIN or account-data values, clear-text cryptographic keys, or key components outside of the crypto-processor are considered sensitive data.
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is
TB4.1 The tester shall verify that
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed, and that all sensitive data is included. Passwords/authentication codes, clear-text PIN or account-data values, clear-text cryptographic keys, or key components outside of the crypto-processor are considered sensitive data.
•and summarize how
•the vendor has identified all data that is automatically cleared when the transaction is completed, and that all sensitive data is included. Passwords/authentication codes, 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. 61
Note: This applies to the loading of initial high-level (e.g., root) keys. Where those keys are embedded in the firmware, they will leverage the mechanisms used for the firmware as required under E5. Other public keys that are loaded after the device has received its FW can be authenticated using cryptographic mechanisms (like a certificate or a MAC), and the loading can happen in a non-secure area without compromising security.
Note: This applies to the loading of initial high-level⎯e.g., root⎯keys. Where those keys are embedded in the firmware, they will leverage the mechanisms used for the firmware as required under E5. Other public keys that are loaded after the device has received its FW can be authenticated using cryptographic mechanisms (like a certificate or a MAC), and the loading can happen in a non-secure area without compromising security.
Modified
p. 64
B7 is mandatory for the SCRP approval class in order to provide a source of entropy for the PIN CVM application. It is a requirement that any random numbers used on the COTS device for security purposes must be seeded from a value provided from the RNG on an SCRP.
B7 is mandatory for the SCRP approval class in order to provide a source of entropy for external payment applications. It is a requirement that any random numbers used on the COTS device for security purposes must be seeded from a value provided from the RNG on an SCRP.
Modified
p. 68
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.
Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support the X9.143 methodology and/or the ISO 20038 methodology. X9.143 are recognized as interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. The X9.143 Key Variant (Calculation) methods are no longer allowed.
Modified
p. 69
• Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA, CES, or GCHQ); and
• Holds one or more professional credentials applicable to the field⎯e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA, CES, or GCHQ); and
Modified
p. 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 X9.143 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.
Modified
p. 69
These methods must be used for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.
These methods must be used for key loading whenever a symmetric key⎯e.g., AES or TDES⎯is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually⎯i.e., through the keypad⎯using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.
Modified
p. 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 …
1. For devices under a PKI hierarchy that facilitates more than one acquirer⎯e.g., a hierarchy under a PIN-acceptance device vendor’s root⎯the PIN-acceptance device can be forced to bind to a specific transaction-processing host’s certificate, and not accept commands digitally signed by any other hosts. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted below. 2. The acquirer KDH public key can be loaded only once and requires a factory return (preceded …
Modified
p. 71
SCRPs shall provide for the use of cryptographic keys stored within the SCRP to provide security to the provisioning process. This process loads cryptographic keys and other data to the PIN CVM application upon initial configuration as described in DTR B8: Secure Provisioning of the PCI Software-based PIN Entry on COTS DTRs.
SCRPs shall provide for the use of cryptographic keys stored within the SCRP to provide security to the provisioning process. This process loads cryptographic keys and other data to an external system (such as a payment application on a mobile phone) upon initial configuration as described in DTR B8: Secure Provisioning of the PCI Software-based PIN Entry on COTS DTRs.
Modified
p. 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 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 …
Form Factor in which Key is Loaded to Available Key Slots (Registers) Unique per Device/ Acquirer/ Vendor- specific/ Other (describe) Storage Area How Key is Identified by the Device so it is used only as Intended IPEK Initial DUKPT Key TDES 128 Acquirer Clear text from key-injection One Device Designated Key Register DUKPT PEKs (Future Keys Register) PIN encipherment for online PIN TDES 128 Acquirer Derived originally from Up to 21 Future Keys Device Designated Key Register KPT PIN encipherment …
Modified
p. 74
c) The method used does not rely on the check digits (e.g., mod 10 calculation) of a (T) DES key as part of the key comparison.
c) The method used does not rely on the check digits⎯e.g., mod 10 calculation⎯of a (T) DES key as part of the key comparison.
Modified
p. 75
TB9.25 The tester shall verify the SCRP contains cryptographic keys and functions that can be used to securely provision cryptographic keys and other data to the PIN CVM application. The tester shall detail the relevant key names, function names, and function behavior.
TB9.25 The tester shall verify the SCRP contains cryptographic keys and functions that can be used to securely provision cryptographic keys and other data to an external system (such as a payment application on a mobile phone). The tester shall detail the relevant key names, function names, and function behavior.
Modified
p. 77
• Manually entered security validation value (e.g., CVV2, CVC2, and CID2);
• Manually entered security validation value⎯e.g., CVV2, CVC2, and CID2);
Modified
p. 77
• The application must be cryptographically authenticated by keys secured within the key domain of the POI using algorithms and keys sizes consistent with those stipulated in B10.
• The application must be cryptographically authenticated by keys secured within at least the level of the Non-PIN Key domain of the POI using algorithms and keys sizes consistent with those stipulated in B10.
Modified
p. 79
SCRPs shall only support ISO format 4 for PIN conveyance from the PIN CVM application on the COTS device, using a tokenized version of the PAN provided by the SCRP. This PIN-encryption key shall be unique per transaction.
SCRPs shall only support ISO format 4 for PIN conveyance from an external system (such as a payment application on a mobile phone which has captured and encrypted the PIN for transferal to the SCRP), using a tokenized version of the PAN provided by the SCRP. This PIN-encryption key shall be unique per transaction.
Modified
p. 79
SCRPs shall perform PIN translation from encryption under the AES key shared with the COTS PIN CVM application to encryption under a different key shared with the host. This key shared with the host may be either TDES or AES.
SCRPs shall perform PIN translation from encryption using a tokenized PAN under the AES key shared with the external system (such as a payment application on a mobile phone) to encryption using the real PAN under a different key shared with the host. This key shared with the host may be either TDES or AES.
Modified
p. 80
TB11.3 The tester shall confirm that SCRPs support the use of a unique-per-transaction, AES PIN- encryption key for conveyance of PINs from the PIN CVM application on the COTS device and detail the methods used to generate this key.
TB11.3 The tester shall confirm that SCRPs support the use of a unique-per-transaction, AES PIN- encryption key for conveyance of PINs from an external system (such as a payment application on a mobile phone) and detail the methods used to generate this key.
Modified
p. 80
TB11.8 For SCRPs, the tester shall verify that the SCRP generates a PAN token as stated in B24 for use by the PIN CVM application on the COTS device for conveyance of an ISO format 4 PIN block to the SCRP.
TB11.8 For SCRPs, the tester shall verify that the SCRP generates a PAN token as stated in B24 for use by an external system (such as a payment application on a mobile phone) for conveyance of an ISO format 4 PIN block to the SCRP.
Modified
p. 80
TB11.9 For SCRPs, the tester shall verify that the SCRP does not support the use of format 1 PIN blocks, and that only ISO format 0, 3, or 4 PIN blocks are supported for translation of the customer PIN as transmitted from the PIN CVM application.
TB11.9 For SCRPs, the tester shall verify that the SCRP does not support the use of format 1 PIN blocks, and that only ISO format 0, 3, or 4 PIN blocks using the real PAN are supported for translation of the customer PIN as transmitted from an external system (such as a payment application on a mobile phone) for conveyance to a host system.
Modified
p. 91
Software security domains and respective security requirements, in this context, are defined in Appendix G, “Domain-Based Asset Flow Analysis.” A vendor may choose to run all software inside a single domain, i.e., the key domain. In this case, the device is not considered to support applications, and all software is considered firmware, which must comply with all DTR relevant to firmware.
Software security domains and respective security requirements, in this context, are defined in Appendix G, “Domain-Based Asset Flow Analysis.” A vendor may choose to run all software inside a single domain⎯i.e., the PIN Key domain. In this case, the device is not considered to support applications, and all software is considered firmware, which must comply with all DTR relevant to firmware.
Modified
p. 93
The intended operation is considered as the functionality relevant to D1 to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access.
The intended operation is considered as the functionality relevant to D2 to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access.
Modified
p. 93
TB17.4 The tester shall determine whether the OS supports multiple privilege levels or user privileges.
TB17.4 The tester shall determine whether the OS supports multiple privilege levels or user privileges. If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the firmware privilege level.
Modified
p. 97
• General Description (DTRs B20.1
•B20.5)
•
• General Description (DTRs B20.1
• B20.6)
• B20.6)
Modified
p. 97
• Installation and Guidance (DTRs B20.6
•B20.15)
•
• Installation and Guidance (DTRs B20.7
• B20.16)
• B20.16)
Modified
p. 97
• Operation and Maintenance (DTRs B20.16
•B20.23)
•
• Operation and Maintenance (DTRs B20.17
• B20.24)
• B20.24)
Modified
p. 97
• Security (DTRs B20.24
•B20.31) This is the minimum information that must be presented. Additional information may be presented.
•
• Security (DTRs B20.25
• B20.33) This is the minimum information that must be presented. Additional information may be presented.
• B20.33) This is the minimum information that must be presented. Additional information may be presented.
Modified
p. 97
TB20.1 The tester shall examine the security policy to verify that the device is properly identified. Model name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions and the exact approval class and use case of the device including the specific POI Security Requirements version validated and approved against. The …
TB20.1 The tester shall examine the security policy to verify that the device is properly identified. Model name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes actual (not computer-generated or similar) pictures of the device, and how to validate the hardware, firmware, and application versions and the exact approval class and use case of the device including the specific POI Security Requirements version …
Removed
p. 98
TB20.10 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods TB20.11 The tester shall confirm that the security policy defines guidance for the proper implementation of any Open Protocols that are part of the approval.
Modified
p. 98
TB20.7 The tester shall examine the security policy to verify that it identifies all conditions (for example, voltage, humidity, and temperature) that will cause environmental failure-protection mechanisms to trigger.
Modified
p. 98
TB20.8 The tester shall confirm that the security policy includes all configuration settings necessary to meet the security requirements defined in this document.
Modified
p. 98
TB20.9 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords/authentication codes and certificates.
Modified
p. 98
TB20.10 The tester shall confirm that the security policy contains any installation or user guidance as required by the laboratory for compliance with the PCI PTS requirements. Examples of such required guidance, includes but is not limited to:
Modified
p. 98
•i.e., where two physically and electronically distinct
•the tester shall confirm that the security policy states how the device is compliant to PCI PTS POI Evaluation Technical FAQ #26.
TB20.13 For PIN entry devices that appear as a single device
•i.e., where two physically and electronically distinct devices⎯e.g., a PED and a commercial off-the-shelf (COTS) device such as a mobile phone⎯appear as a single device through the use of the plastics to mask the connectivity
•the tester shall confirm that the security policy states how the device is compliant to PCI PTS POI Evaluation Technical FAQ #26.
•i.e., where two physically and electronically distinct devices⎯e.g., a PED and a commercial off-the-shelf (COTS) device such as a mobile phone⎯appear as a single device through the use of the plastics to mask the connectivity
•the tester shall confirm that the security policy states how the device is compliant to PCI PTS POI Evaluation Technical FAQ #26.
Modified
p. 98
TB20.14 The tester shall confirm that for any handheld PIN entry device, if the device does not support SRED encryption, the security policy must clearly state that the system cannot be implemented to connect to a tablet or mobile phone, and any such use will violate the approval of the device.
Modified
p. 98
TB20.15 The tester shall confirm that for any device having beacons, the security policy states how those are compliant to PCI PTS POI Evaluation Technical FAQ #14.
Modified
p. 99
TB20.18 The tester shall confirm that the security policy includes procedures for the decommissioning of devices that are removed from service, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device. The procedures may differentiate between temporary and permanent removal.
Modified
p. 99
TB20.19 For privacy shielding the tester shall perform the following tests:
Modified
p. 99
TB20.20 The tester shall confirm that the security policy contains information on all ways the device will indicate a tamper-response event, and any requirements for the return of this device to the vendor for examination following such an event (as required for compliance to DTR A1). This shall include an illustration to show the user an actual tamper-response display message and accurate information on any other tamper-responsive behaviors.
Modified
p. 99
TB20.21 The tester shall examine the security policy and relevant vendor documentation to verify that any periodic maintenance procedures required for the secure operation of the device are included in the security policy.
Modified
p. 99
TB20.22 The tester shall examine the security policy to verify that it identifies all self-tests that the module performs, procedures that an operator may need to initiate any self-tests, and the conditions under which each self-test is executed (for example, power up, periodic, conditional, on operator demand).
Modified
p. 99
TB20.23 The tester shall examine the security policy to verify that it identifies all roles supported by the device and indicates the services and permissions available for each role.
Modified
p. 99
TB20.24 The tester shall examine the security policy and relevant vendor documentation to verify that the device has update and patch procedures required for the secure operation of the device and that the procedures are included in the security policy. The policy will include both local and remote update and patch downloading procedures for software, firmware, and configuration parameters, including those necessary for meeting the Open Protocols requirements.
Modified
p. 99
TB20.25 The tester shall confirm that the security policy defines how the device is compliant to PCI PTS POI Evaluation DTR B1, for any device where the required memory re-initialization (security) cycle last longer than 24 hours. Specifically, how the firmware of the device during the cycles’ adjustment processes does not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours).
Modified
p. 100
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
TB20.28 The tester shall confirm that the security policy contains specific details on any account-data protection schemes employed
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
•e.g., algorithms used, format-preserving encryption techniques
•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.
Modified
p. 100
TB20.29 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. 100
TB20.30 The tester shall confirm that the security policy contains specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with B15, or any mechanisms used for authenticating application code as assessed under Requirements B2.1.
Modified
p. 100
TB20.31 The tester shall examine the security policy to verify that it states that keys should be replaced with new keys whenever the compromise of the original key is known or suspected, and whenever the time deemed feasible to determine the key by exhaustive attack elapses, as defined in NIST SP 800-57-1.
Modified
p. 100
TB20.32 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.
Modified
p. 101
If the devices encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:
If the PIN entry device and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:
Modified
p. 101
For an SCRP, this requirement is applied without consideration of the conveyance of the PIN from the PIN CVM application on the COTS device. The conveyance of the PIN from the PIN CVM application on the COTS device to the SCRP shall always use ISO format 4 for that conveyance.
For an SCRP, this requirement is applied without consideration of the conveyance of the PIN from an external system (such as a payment application on a mobile phone). The conveyance of the PIN from any such external system to the SCRP shall always use ISO format 4 for that conveyance.
Modified
p. 107
SCRPs must tokenize the PAN data to send to the PIN CVM application on the COTS device for use in formatting the ISO format 4 PIN block. An example of an acceptable PAN token is one described in ANSI X9.119-2 using a format-preserving scheme.
SCRPs must tokenize the PAN data to send to any external system (such as a payment application on a mobile phone) for use in formatting the ISO format 4 PIN block. An example of an acceptable PAN token is one described in ANSI X9.119-2 using a format-preserving scheme.
Removed
p. 110
TB26.2 The tester shall document the features of the monitor token that prevent replay of this value.
Modified
p. 110
TB26.1 The tester shall confirm that without a cryptographically secure enablement token being supplied to the SCRP, the SCRP will cease accepting consumer cards within a time no more than twice (i.e., ten minutes) that of the maximum monitor frequency. Re-enablement of the SCRP to accept consumer cards may be performed at any time, with the validation of a fresh monitor token.
TB26.1 The tester shall confirm that without a cryptographically secure enablement token being supplied to the SCRP, the SCRP will cease accepting payment cards within a time no more than 24 hours. Re-enablement of the SCRP to accept payment cards may be performed at any time with the validation of a fresh enablement token.
Modified
p. 110
The tester shall attempt to replay the monitor token and confirm that this does not allow for the continued operation, or re-enablement, of the SCRP.
TB26.3 The tester shall document the features of the enablement token that prevent replay of this value. The tester shall attempt to replay the enablement token and confirm that this does not allow for the continued operation, or re-enablement, of the SCRP.
Modified
p. 113
TC2.1.2 The tester shall verify that the failure of secure component does not lead the PIN entry POI terminal to fall back in a non-safe mode (i.e., no more protecting the PIN as per requirements).
TC2.1.2 The tester shall verify that the failure of secure component does not lead the PIN entry POI terminal to fall back in a non-safe mode⎯i.e., no more protecting the PIN as per requirements.
Modified
p. 126
• Cover all key properties, minimally type and length (e.g., TDES 112-bits);
• Cover all key properties, minimally type and length⎯e.g., TDES 112-bits;
Modified
p. 131
d) Certificate signed using a weak hash e.g., SHA1 or MD5
d) Certificate signed using a weak hash⎯e.g., SHA1 or MD5
Modified
p. 134
BLE implementations in SCRPs, regardless of Bluetooth version, for use in SPoC Solutions may use unauthenticated pairing (Just Works) provided compensating controls to mitigate against eavesdropping and MITM attacks are in place as part of the Solution. These controls shall be validated during testing of the SPoC solution. SCRPs that allow either the use of Just Works for pairing or do not exclusively implement Secure Connections are not approved for use outside of a SPoC Solution.
BLE implementations in SCRPs, regardless of Bluetooth version, for use in SPoC/MPoC Solutions may use unauthenticated pairing (Just Works) provided compensating controls to mitigate against eavesdropping and MITM attacks are in place as part of the Solution. These controls shall be validated during testing of the SPoC/MPoC solution. SCRPs that allow either the use of Just Works for pairing or do not exclusively implement Secure Connections are not approved for use outside of a SPoC/MPoC Solution.
Modified
p. 140
TE1.3 The tester shall confirm that the POI devices are labeled with the unique reference assigned within the change-control procedures. The tester shall also confirm that the tamper-resistant parts (e.g., PED, ICCR) have a unique identifier that is visible without opening the devices. The tester shall confirm that the firmware is uniquely identified.
TE1.3 The tester shall confirm that the POI devices are labeled with the unique reference assigned within the change-control procedures. The tester shall also confirm that the tamper-resistant parts⎯e.g., PED, ICCR⎯have a unique identifier that is visible without opening the devices. The tester shall confirm that the firmware is uniquely identified.
Modified
p. 142 → 141
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, …
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, except …
Modified
p. 151 → 150
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..
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. 151 → 150
TE9.5 The tester shall observe the device repair, inspection and post-inspection storage process to ensure that procedures are followed subsequent to production.
TE9.5 The tester shall observe the device repair, inspection, and post-inspection storage process to ensure that procedures are followed subsequent to production.
Modified
p. 155 → 154
Prior to initial financial-key loading, the POI should be protected against modification. Such protection shall be a combination of the characteristics of the device (i.e., tamper evidence, resistance, and responsiveness) and device-management procedures. If the device has any manufacturer keys loaded, compromise shall be both prevented and detected.
Prior to initial financial-key loading, the POI should be protected against modification. Such protection shall be a combination of the characteristics of the device⎯i.e., tamper evidence, resistance, and responsiveness⎯and device-management procedures. If the device has any manufacturer keys loaded, compromise shall be both prevented and detected.
Removed
p. 162
• affixed to it. This information shall also be retrievable by a query.
Modified
p. 175 → 174
c) Sensitive information about the POI device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering). Sensitive information is not intended to be distributed to external entities and is obtained by means such as “social engineering” theft or coercion. Typical examples are terminal schematics and firmware source code.
c) Sensitive information about the POI device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse-engineering). Sensitive information is not intended to be distributed to external entities and is obtained by means such as “social engineering” theft or coercion. Typical examples are terminal schematics and firmware source code.
Modified
p. 179 → 178
Attack Considerations If an attack requires damage to a part of the POI casing, the attack does not need the replacement of that entire casing to hide the tamper evidence. This is because there are many ways in which tamper evidence can be hidden, either through the installed environment of the POI, through the application of stickers, epoxy putty and paint, or other methods. Complete replacement of the plastic part is to be considered only when it adds little or …
Attack Considerations If an attack requires damage to a part of the POI casing, the attack does not need the replacement of that entire casing to hide the tamper evidence. This is because there are many ways in which tamper evidence can be hidden, either through the installed environment of the POI, through the application of stickers, epoxy putty and paint, or other methods. Complete replacement of the plastic part is to be considered only when it adds little or …
Modified
p. 179 → 178
Damage to the front or back should not be treated differently, even though there is increased visibility of frontal damage, unless the rear can be expected to not be visible (e.g., in an EPP) where any damage does not need to be covered up at all. If an attack path requires damage to the part visible to the cardholder, the effort for hiding it⎯replacement parts (spare device), time needed, and skill to mask it⎯must be considered.
Damage to the front or back should not be treated differently, even though there is increased visibility of frontal damage, unless the rear can be expected to not be visible⎯e.g., in an EPP⎯where any damage does not need to be covered up at all. If an attack path requires damage to the part visible to the cardholder, the effort for hiding it⎯replacement parts (spare device), time needed, and skill to mask it⎯must be considered.
Modified
p. 180 → 179
Where sensitive data is exposed inside the PED or EPP, but outside of the immediate area of the keypad contacts (i.e., outside the keypad area), or internally within the security processor, this data must be protected by a tamper-responsive envelope. Use of physical barriers alone, such as plastic walls or tamper evident protections, is not considered sufficient to meet the requirements to protect customer PIN data or cryptographic keys. A POI that does not implement tamper-detecting side walls for its …
Where sensitive data is exposed inside the PED or EPP, but outside of the immediate area of the keypad contacts⎯i.e., outside the keypad area⎯or internally within the security processor, this data must be protected by a tamper-responsive envelope. Use of physical barriers alone, such as plastic walls or tamper evident protections, is not considered sufficient to meet the requirements to protect customer PIN data or cryptographic keys. A POI that does not implement tamper-detecting side walls for its secure area …
Modified
p. 180 → 179
If a device includes front-case switches with guard rings as the only keypad (front case) security mechanisms protecting against the insertion of a PIN bug, then a Proficient level of expertise should be used in the exploitation phase of the attack for Requirement A1. If Expert level is accounted for in the exploitation phase, strong justification, including full testing on a sufficient number of samples, must be provided in the assessment. In most cases, the device must include additional types …
If a device includes front-case switches with guard rings as the only keypad (front case) security mechanisms protecting against the insertion of a PIN bug, then a Proficient level of expertise should be used in the exploitation phase of the attack for Requirement A2. If Expert level is accounted for in the exploitation phase, strong justification, including full testing on a sufficient number of samples, must be provided in the assessment. In most cases, the device must include additional types …
Modified
p. 180 → 179
In general, the Identification phase should include a full dry run for the installation and testing of a PIN bug, resulting in a complete script to be followed in the Exploitation phase. In rare instances, additional steps may be required in the Exploitation phase because of nuances (e.g., slight variations in tamper- switch connections) between devices.
In general, the Identification phase should include a full dry run for the installation and testing of a PIN bug, resulting in a complete script to be followed in the Exploitation phase. In rare instances, additional steps may be required in the Exploitation phase because of nuances⎯e.g., slight variations in tamper- switch connections⎯between devices.
Modified
p. 180 → 179
For the Identification phase for PIN-bug attacks, additional time spent analyzing the device under attack can be used in lieu of Restricted or Sensitive information. Restricted or Sensitive information should only be used when the total attack-potential calculation using Restricted or Sensitive information is less than the total attack-potential calculation using the additional attack time, such as through reverse engineering.
For the Identification phase for PIN-bug attacks, additional time spent analyzing the device under attack can be used in lieu of Restricted or Sensitive information. Restricted or Sensitive information should only be used when the total attack-potential calculation using Restricted or Sensitive information is less than the total attack-potential calculation using the additional attack time, such as through reverse-engineering.
Modified
p. 182 → 181
Attack Examples In the following examples, attacks on a very well-designed device are described. These examples are intended to illustrate how attack ratings may be represented. New devices must be rated through direct testing and under no circumstances may have ratings relying on these examples. The device is very compact and there is limited space inside the device; therefore, it is assumed that a bug or its circuit has to be installed into a fake housing that provides more space …
Attack Examples In the following examples, attacks on a very well-designed device are described. These examples are intended to illustrate how attack ratings may be represented. New devices must be rated through direct testing and under no circumstances may have ratings relying on these examples. The device is very compact and there is limited space inside the device; therefore, it is assumed that a bug or its circuit has to be installed into a fake housing that provides more space …
Modified
p. 182 → 181
This step requires Expert knowledge of electronic engineering and the capability to perform the mechanical and electronic tests required. The device will cause an alarm during the development phase, since the case switches have to be opened. For the reverse-engineering of PED internals, only one mechanical sample is needed.
This step requires Expert knowledge of electronic engineering and the capability to perform the mechanical and electronic tests required. The device will cause an alarm during the development phase, since the case switches have to be opened. For the reverse-engineering of POI internals, only one mechanical sample is needed.
Modified
p. 185 → 184
This step requires Expert knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The attacker has first to identify the potential way to reach the I/O PIN of the IC card reader. Therefore, one sample of the PED will be opened. The location of the I/O PIN and the protection measures have to be analyzed. The device will cause an alarm during that development phase since the case switches have to be opened. For …
This step requires Expert knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The attacker has first to identify the potential way to reach the I/O PIN of the IC card reader. Therefore, one sample of the POI will be opened. The location of the I/O PIN and the protection measures have to be analyzed. The device will cause an alarm during that development phase since the case switches have to be opened. For …
Modified
p. 185 → 184
3. The deactivation of the lateral tamper grid (flexible foil printed with conductive ink on two layers, integrated in a plastic shape filled with resin) may be performed by reaching the connector of the tamper grid to the security processor or by direct manipulation of the mesh. If the grid is deactivated, the attacker may drill a hole in the lateral side of the PED to insert a PIN-disclosing bug. The attacker will uncover the security grid lines of the …
3. The deactivation of the lateral tamper grid (flexible foil printed with conductive ink on two layers, integrated in a plastic shape filled with resin) may be performed by reaching the connector of the tamper grid to the security processor or by direct manipulation of the mesh. If the grid is deactivated, the attacker may drill a hole in the lateral side of the POI to insert a PIN-disclosing bug. The attacker will uncover the security grid lines of the …
Modified
p. 188 → 187
6. The track data is collected from the replaced MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
6. The track data is collected from the replaced MSR head and logged in the memory of the track data logging circuit⎯e.g., located in a fake housing⎯or sent to another device.
Modified
p. 189 → 188
3. The track data is collected from the replaced MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
3. The track data is collected from the replaced MSR head and logged in the memory of the track data logging circuit⎯e.g., located in a fake housing⎯or sent to another device.
Modified
p. 189 → 188
Table used for Exploitation
• Attack Example 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard 1 functional with working keys and SW 2 Skilled Public Standard Standard Same functional 2 hours 3 Skilled Public None None None 30 minutes Total Skilled Public Standard Standard 1 functional with working keys and SW Combined Attack Potential Rating for MSR Bug replacement
• Attack Example 3 Aspect Identifying Value Exploiting Value Attack time a: ≤ 100 hours b: ≤ 40 …
• Attack Example 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard 1 functional with working keys and SW 2 Skilled Public Standard Standard Same functional 2 hours 3 Skilled Public None None None 30 minutes Total Skilled Public Standard Standard 1 functional with working keys and SW Combined Attack Potential Rating for MSR Bug replacement
• Attack Example 3 Aspect Identifying Value Exploiting Value Attack time a: ≤ 100 hours b: ≤ 40 …
Table used for Exploitation
• Attack Example 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard 1 functional with working keys and SW 2 Skilled Public Standard Standard Same functional 2 hours 3 Skilled Public None None None 30 minutes Total Skilled Public Standard Standard 1 functional with working keys and SW Combined Attack Potential Rating for MSR Bug replacement
• Attack Example 3 Aspect Identifying Value Exploiting Value Attack time a: ≤ 100 hours b: ≤ 40 …
• Attack Example 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard 1 functional with working keys and SW 2 Skilled Public Standard Standard Same functional 2 hours 3 Skilled Public None None None 30 minutes Total Skilled Public Standard Standard 1 functional with working keys and SW Combined Attack Potential Rating for MSR Bug replacement
• Attack Example 3 Aspect Identifying Value Exploiting Value Attack time a: ≤ 100 hours b: ≤ 40 …
Modified
p. 190 → 189
5. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
5. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit⎯e.g., located in a fake housing⎯or sent to another device.
Modified
p. 190 → 189
3. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit (e.g., located in a fake housing) or sent to another device.
3. The track data is collected from the manipulated MSR head and logged in the memory of the track data logging circuit⎯e.g., located in a fake housing⎯or sent to another device.
Modified
p. 192 → 191
1. The attacker has to perform reverse-engineering of the device to develop the attack procedure. This step requires expert knowledge of electronic engineering and the capability to perform the mechanical and electronic tests required. The device will cause an alarm during that development phase since the case switches have to be opened. For the reverse-engineering of PED internals, which is calculated with 32 hours’ working time
•two days’ reverse-engineering (expert) and two days’ attack development (proficient)
•only one mechanical sample is needed.
•two days’ reverse-engineering (expert) and two days’ attack development (proficient)
•only one mechanical sample is needed.
1. The attacker has to perform reverse-engineering of the device to develop the attack procedure. This step requires expert knowledge of electronic engineering and the capability to perform the mechanical and electronic tests required. The device will cause an alarm during that development phase since the case switches have to be opened. For the reverse-engineering of POI internals, which is calculated with 32 hours’ working time
•two days’ reverse-engineering (expert) and two days’ attack development (proficient)
•only one mechanical sample is needed.
•two days’ reverse-engineering (expert) and two days’ attack development (proficient)
•only one mechanical sample is needed.
Modified
p. 192 → 191
5. A PIN-disclosing bug is placed into the PED housing of a functional sample. In this example, the keypad matrix lines have to be connected (fixing/gluing) to the additional circuit with thin wires with help of standard equipment. The manipulated device has to be tested. The work has to be performed by a skilled attacker.
5. A PIN-disclosing bug is placed into the POI housing of a functional sample. In this example, the keypad matrix lines have to be connected (fixing/gluing) to the additional circuit with thin wires with help of standard equipment. The manipulated device has to be tested. The work has to be performed by a skilled attacker.
Modified
p. 194 → 193
The attack aims at the determination of DES/AES and RSA keys used for various purposes (e.g., account-data encryption, key download, MACing, building the TLS session layer etc.) at the device using differential power analysis (DPA).
The attack aims at the determination of DES/AES and RSA keys used for various purposes⎯e.g., account-data encryption, key download, MACing, building the TLS session layer etc.⎯at the device using differential power analysis (DPA).
Modified
p. 198 → 197
• Automated (“push-button”) side-channel software to be used on a specific PED model to bypass strong countermeasures and leak keys from that specific model.
• Automated (“push-button”) side-channel software to be used on a specific POI model to bypass strong countermeasures and leak keys from that specific model.
Modified
p. 202 → 201
SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions (i.e., KDFs) and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.
SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions⎯i.e., KDFs⎯and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.
Modified
p. 210 → 209
The outcome for an evaluation’s SCA testing is to either defeat the device emulating a realistic attack scenario or derive a definitive rating showing that the effort for an attack in the field is clearly above the necessary threshold. If the latter is not achieved in a test, detailed evidence is necessary to demonstrate compliance otherwise. The evaluation test report is the principle resource for demonstrating compliance to Security Requirements. The report must be self-consistent and adequate to justify compliance …
The outcome for an evaluation’s SCA testing is to either defeat the device emulating a realistic attack scenario or derive a definitive rating showing that the effort for an attack in the field is clearly above the necessary threshold. If the latter is not achieved in a test, detailed evidence is necessary to demonstrate compliance otherwise. The evaluation test report is the principal resource for demonstrating compliance to Security Requirements. The report must be self-consistent and adequate to justify compliance …
Modified
p. 210 → 209
• Authentication (e.g., firmware, display prompts)
• Authentication⎯e.g., firmware, display prompts
Modified
p. 211 → 210
Effort to complete the overall device side-channel analysis The descriptions below outline typical parameters that are acceptable for testing. Good attackers are creative and will not limit their efforts to below pre-defined limits such as disk storage size or an exact number of acquisitions, etc. PCI SCC expects the degree of any key leakage to be quantified using effective techniques (e.g., correlation, key attacks related to DPA, etc.) that are in agreement with these typical parameters but without reliance on …
Effort to complete the overall device side-channel analysis The descriptions below outline typical parameters that are acceptable for testing. Good attackers are creative and will not limit their efforts to below pre-defined limits such as disk storage size or an exact number of acquisitions, etc. PCI SCC expects the degree of any key leakage to be quantified using effective techniques⎯e.g., correlation, key attacks related to DPA, etc.⎯that are in agreement with these typical parameters but without reliance on parameter values …
Modified
p. 212 → 211
It is very likely that a significant part (even the majority) of the test effort will involve processing data (e.g., iteratively collecting, analyzing, filtering, aligning, performing correlation trials) following initial collections, to optimize inputs to key attacks.
It is very likely that a significant part (even the majority) of the test effort will involve processing data⎯e.g., iteratively collecting, analyzing, filtering, aligning, performing correlation trials⎯following initial collections, to optimize inputs to key attacks.
Modified
p. 212 → 211
Testing from separate evaluations meeting these best practices criteria can be reused, provided that (1) testing is no longer than from the previous major version of the standard (e.g., v5.x work can be reused if appropriate as part of a v6.x review and (2) a complete chain of trust is demonstrated validating why previous testing is wholly applicable to a newly evaluated device. For “System on Chip” (SoC) type cryptographic implementations, where expert-level work, multiple effective SCA countermeasures, and collection …
Testing from separate evaluations meeting these best practices criteria can be reused, provided that (1) testing is no longer than from the previous major version of the standard⎯e.g., v5.x work can be reused if appropriate as part of a v6.x review⎯and (2) a complete chain of trust is demonstrated validating why previous testing is wholly applicable to a newly evaluated device. For “System on Chip” (SoC) type cryptographic implementations, where expert-level work, multiple effective SCA countermeasures, and collection sizes in …
Modified
p. 215 → 214
Assets and Domains “Domains” is used herein as a shortened term for “security domains group assets” with similar protection requirements. Such domains are easily reflected by similar attack cost thresholds. While in general domains with the same requirements concerning attack potential might have to be kept segregated to reflect different administrative requirements, such a structure is as yet not foreseen in PCI POI. Therefore, the domain hierarchy is linear⎯i.e., any domain can always be represented by another domain with higher …
Assets and Domains “Domains” is used herein as a shortened term for “security domains group assets” with similar protection requirements. Such domains are easily reflected by similar attack cost thresholds. While in general domains with the same requirements concerning attack potential might have to be kept segregated to reflect different administrative requirements, such a structure is as yet not foreseen in PCI POI. Therefore, the domain hierarchy is linear⎯i.e., any domain can always be represented by another domain with higher …
Modified
p. 215 → 214
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:
The PCI POI criteria defines various assets with corresponding protection requirements. Assets are defined by data and which kind of access it shall be protected against. Integrity means that any modification to the asset, whether spurious or induced, shall prohibit it being processed any longer. Confidentiality means that clear text of the data must not be disclosed. In Table H1 below, five Security Domains are defined from higher-protection requirements to lesser requirements:
Modified
p. 217 → 216
2. Segregation of process by simulation leads to a virtual hardware support. Standard concepts are interpreted programs like Java. Since such solutions often allow calls to native libraries, i.e., which are not interpreted, and the interpreter itself may be quite complex, in general it is much harder to verify that such segregation is actually effective.
2. Segregation of process by simulation leads to a virtual hardware support. Standard concepts are interpreted programs like Java. Since such solutions often allow calls to native libraries⎯i.e., which are not interpreted, and the interpreter itself may be quite complex, in general it is much harder to verify that such segregation is actually effective.
Modified
p. 218 → 217
Hardware Tagging All of the assets discussed above enter the PCI POI at some time using external interfaces, i.e., the devices are not produced with the assets built-in already.
Hardware Tagging All of the assets discussed above enter the PCI POI at some time using external interfaces⎯i.e., the devices are not produced with the assets built-in already.
Modified
p. 227 → 226
The checklist applies to all processors inside any POI, which process any of the assets related to PCI POI Security Requirements, i.e., cryptographic keys relevant to PIN protection, clear-text PINs, clear-text PANs, display prompts, and clear-text card reader data. Please refer to Appendix G for definition of assets.
The checklist applies to all processors inside any POI, which process any of the assets related to PCI POI Security Requirements⎯i.e., cryptographic keys relevant to PIN protection, 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 → 226
• Can select key hierarchies, e.g., depending on tokenized pans.
• Can select key hierarchies⎯e.g., depending on tokenized pans.
Modified
p. 228 → 227
• Sufficient to fulfill the PCI POI criteria (e.g., a single signal static penetration-detection pin would fail PCI POI criteria).
• Sufficient to fulfill the PCI POI criteria⎯e.g., a single signal static penetration-detection pin would fail PCI POI criteria.
Removed
p. 235
• This section should show where to find the hardware ID and version, software, and firmware versions.
Modified
p. 235 → 234
• This section should detail how the device is to be used
•countertop, hand-held, multi-lane, etc.
•countertop, hand-held, multi-lane, etc.
• This section details how the device is to be used
•countertop, hand-held, multi-lane, etc.
•countertop, hand-held, multi-lane, etc.
Modified
p. 235 → 234
• This section should state the POI Security Requirements version and Approval Class the device is evaluated and approved against.
• This section states the POI Security Requirements version and Approval Class the device is evaluated and approved against.
Modified
p. 235 → 234
• Other attributes of the device should be listed here. Functions provided (MSR, ICCR, PIN entry, etc.) and the communication types (cellular, Bluetooth, Wi-Fi, etc.) on which the device is approved for use.
• Other attributes of the device are listed here. Functions provided (MSR, ICCR, PIN entry, etc.) and the communication types (cellular, Bluetooth, Wi-Fi, etc.) on which the device is approved for use.
Modified
p. 235 → 234
• This section should include pictures of screen shots and procedures on how to locate the information both physically and logically on the device.
• This section includes pictures of screen shots and procedures on how to locate the information both physically and logically on the device.
Modified
p. 235 → 234
• User guidance is provided to the merchant for physical inspection of the product to ensure the device has not been tampered or modified in transit.
• This section provides user guidance to the merchant for physical inspection of the product to ensure the device has not been tampered or modified in transit.
Modified
p. 235 → 234
• User guidance should include how to install the equipment, installing cables, and any environmental considerations, such as security cameras or stands.
• This section provides user guidance for how to install the equipment, installing cables, and any environmental considerations, such as security cameras or stands.
Modified
p. 236 → 235
• This section will include the environmental operating ranges including temperature, voltage, and humidity.
• This section includes the environmental operating ranges including temperature, voltage, and humidity.
Modified
p. 236 → 235
• Guidance and procedures are provided for continual visual and logical inspection of the product. An example would be to check the card slot for shim and look for wires, additional labels, or modification of the device plastics. This section should include picture and screen shots of the device.
• Guidance and procedures are provided for continual visual and logical inspection of the product. An example would be to check the card slot for shim and look for wires, additional labels, or modification of the device plastics. This section should include picture and screen shots of the card slot.
Modified
p. 236 → 235
• Additional information should be provided for any device where the required memory re-initialization (security) cycle lasts longer than 24 hours. Specifically, describe how the firmware of the device during the cycle’s adjustment processes does not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours).
• Additional information must be provided for any device where the required memory re-initialization (security) cycle lasts longer than 24 hours. Specifically, describe how the firmware of the device during the cycle’s adjustment processes does not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours).
Modified
p. 237 → 236
• This section should include pictures and screen shots as well as how the merchant is to react to a tamper event
•i.e., stop using the device, call the help desk, notify your vendor etc.
•i.e., stop using the device, call the help desk, notify your vendor etc.
• This section includes pictures and screen shots as well as how the merchant is to react to a tamper event
•i.e., stop using the device, call the help desk, notify your vendor etc.
•i.e., stop using the device, call the help desk, notify your vendor etc.