PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

PCI_POI_DTRs_v3.1.pdf → PCI_PTS_POI_DTRs_v4-1b.pdf
51% similar
160 → 219 Pages
49549 → 85018 Words
600 Content Changes

Content Changes

600 content changes. 275 administrative changes (dates, page numbers) hidden.

Added p. 3
February 2013 4.x RFC version and combining of DTRs and DTPs

June 2013 4.0 Public release

June 2015 4.1 Updates for errata and new Core Section J

July 2015 4.1a Minor errata
Added p. 7
Minimal contents of reports and minimal test activities All reports shall include a device summary section at the beginning of the document. This summary shall include the following:

 A device overview that summarizes the device’s design, hardware and software architectures, and functionalities;  An overview of all security-relevant features, necessary to derive principal assets, threats, and attacks;  A summary list of DTRs with verdicts on whether tested and whether compliant; and  A summary of any assistance provided by the vendor to the lab.

In support of some test steps, as directed by the test laboratory, the vendor must support the laboratory in various tasks (code review, fuzzing interfacing, DPA, etc.) to avoid prohibitively lengthy test activities.

The vendor shall make source code available to the lab and provide assistance to make a systematic review of relevant security functions.

Note that a copy of the Vendor Questionnaire shall be submitted to the …
Added p. 8
 The text of the security requirements and guidance  Validate the completed Vendor Questionnaire and other vendor responses by stating:

a) Whether the evidence supports vendor assertions that the device is compliant with this requirement.

i. Where the evidence does support vendor assertions, assign a verdict of “Verified”;

ii. Where it does not, assign a verdict of “Not Verified.”

b) Whether the vendor’s responses appear to be consistent and comply with the relevant PCI Requirement(s).

i. If consistent and compliant, provide a brief written description of why the responses appear to be consistent and the device complies with the PCI requirement.

ii. If the responses do not appear to be consistent and do not comply with PCI requirements, provide a brief written description of why they are not consistent and do not comply.

The evaluation report document shall demonstrate compliance to Security Requirements. For all DTRs, the tester shall present sufficient information on direct tests and …
Added p. 12
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

e) Outline of the tamper-detection mechanisms used on that board (such as “4 tamper switches on lower face,” “6 tamper switches on upper face,” “two internal tamper grids,” etc.).
Added p. 12
PCB Designator PCB Version PCB Purpose Picture Reference Tamper-Detection Mechanisms TA1.8 For each PCB that carries customer PIN signals, the tester shall describe what tamper-detection mechanisms protect these signals from being accessed (such as tamper grids). The tester shall confirm that these mechanisms protect the entire path taken by the signals, as described above.

TA1.9 The tester shall describe whether any of the items on the path of the keypad signals are not protected by all tamper-detection mechanism. For example, the tester shall note if a signal via terminates on the same layer as a tamper grid and if any passive components are located outside of the protected area or are connected to vias (including power vias) that terminate outside of the protected area(s).

TA1.10 Using vendor documentation for each tamper grid that is implemented, the tester shall complete the details indicated in the table below, describing, at a minimum:

a) The location …
Added p. 13
TA1.12 For each tamper switch used in the POI, the tester shall complete the details indicated in the table below, at a minimum.

The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack (such as being covered by a flexible tamper grid, or having a unique construction).

Switch Location Number Used in that Location Physical Implementation Size of Switch Conductive Ink Protections Additional Comments TA1.13 The tester shall describe what testing was performed to validate the protection provided by each of the tamper switches enumerated above.

TA1.14 The tester shall note which tamper-detection mechanisms use active high, active low, dynamic, resistive (or other) types of sensors. The tester shall confirm that any guard rings or interspaced traces in tamper grids are at opposing voltages that will activate tamper detection if electronically shorted. The tester shall note what …
Added p. 14
TA1.23 The tester shall describe how the POI responds to a tamper-detection event.

TA1.24 Deriving from the previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the POI results from tamper-detection events.

TA1.25 From the above descriptions the tester shall explain how the POI is rendered inoperative after any tamper event.

TA1.26 The tester shall explain how the device is designed to mitigate against overlays.

TA1.27 The tester shall explain how the POI is protected against an internal overlay being placed across the keypad.

TA1.28 The tester shall explain how the POI is protected against attacks from each of all sides of the POI.

TA1.29 The tester shall explain how the POI is protected against attacks from the rear of the device.

TA1.30 The tester shall explain how the POI is protected against attacks from the front of the device.

TA1.31 Describe the different attack paths considered. Using the format …
Added p. 15
1. Description of Step 1 2. Description of Step 2 3. Description of Step 3 4. Etc.

Step Expertise Knowledge Equipment Parts Samples Time 1 Expert Public Standard None 1 Mechanical 80 hours 2 Expert Public Standard Standard 40 hours 3 Expert Public Standard None 1 Mechanical 80 hours Cost breakdown of attack “P1” Identification Phase Value Attack Time 0 < One hour Expertise 0 Layman Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 0 None Specific Parts 0 None Identification Total 3.0 Exploitation Phase Value Attack time 2 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 0 None Specific Parts 0 None Exploitation Total 6.0 (FAIL) Grand Total 9.0 (FAIL) Attack “P2” for Online PINs Identification stage of attack “P2”
Added p. 16
1. Description of Step 1 2. Description of Step 2 3. Description of Step 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Expert Public Standard None 1 Mechanical 80 hours 2 Expert Public Standard Standard 40 hours 3 Expert Public Standard None 1 Mechanical 80 hours Cost breakdown of attack “P2” Identification Phase Value Attack Time 0 < One hour Expertise 0 Layman Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 0 None Specific Parts 0 None Identification Total 3.0 Exploitation Phase Value Attack time 2 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 0 None Specific Parts 0 None Exploitation Total 6.0 (FAIL) Grand Total 9.0 (FAIL) TA1.32 The tester shall verify that no attack was able to be determined, including those outlined above, which could …
Added p. 19
TA3.7 Using a POI that has been configured (using special test code from the vendor, which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.

TA3.8 The tester shall detail whether the self-test program used above executed correctly at all times during each of the tests above, within the ranges before activation of the environmental detection circuitry.

TA3.9 Given the details and results above, the tester shall justify why the tamper-detection mechanisms will remain functional and the POI secure at all extremes within the range of environmental monitoring.

The lab shall consider glitch attacks including (but not restricted to): voltage and EM glitching. At a minimum, these should consider the core and …
Added p. 22
a) Confirm that the encryption uses approved algorithms and key lengths.

b) Note what mode of operation is used for the encryption.

c) Justify how this prevents the re-location of memory from one area to another.

d) Justify how the method of encryption prevents the exposure of sensitive information through building of a “dictionary” of possible encrypted values.

e) If a key stream mode of encryption is used (for example, OFB), justify how the encryption of different data with the same key is prevented.

TA4.13 The tester shall describe and produce a costing for the most feasible attack to recover sensitive information from the POI. The tester shall detail for each step whether the information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.

If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation …
Added p. 23
TA5.3 The tester shall provide a circuit diagram of the input power circuitry of the POI, including any elements used to provide isolation of the power and EM emissions of the device.

TA5.4 Using an in-line resistor, current probe, or other suitable method, the tester shall monitor the (external) current drawn by the POI when pressing each of the ten numeric buttons during a PIN entry function. The tester shall ensure methods are implemented to trigger the captures at the same time (for example, use the signal that drives the sounding device of the POI). The tester shall detail the method used, providing photographs of the test setup.

TA5.5 The tester shall analyze the power captures obtained, as stated above, in both the time and frequency domains to determine whether any of the button presses provide a unique pattern that may be used to distinguish that button press from all others. The …
Added p. 24
TA5.9 The tester shall use a microphone to monitor the signal for each of the ten numeric buttons. The tester shall perform signal analysis and signal processing as necessary to demonstrate that audible information determining key-press values is not leaked by the POI.
Added p. 24
The tester shall present evidence allowing test methodologies and results to be validated.

The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units).

TA6.3 The tester shall provide details on the type, location, and accessibility, of the security processor(s) used by the POI, and any other elements of the POI that have relevance to possible attacks. The tester shall reference information previously supplied in DTRs A1 and A4 where applicable.

TA6.4 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. The tester shall detail the testing performed to confirm the storage locations listed are correct.

TA6.5 The tester shall provide details on …
Added p. 26
The tester shall describe any assistance provided by the vendor to ensure efficient side- channel testing•for example command scripts, event triggers, etc.

TA6.9 Where the results indicate that key recovery is not possible, the tester shall justify the methodologies used and findings. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device, consistent with an attack cost rating of 35 for identification and initial exploitation with a minimum of 15 for exploitation Justifications of these to be reported shall include (but are restricted to): the number of sample recordings acquired, sampling frequencies, alignment methods, signal analysis / filtering techniques, and correlation function(s) used, etc. Evidence to support this shall include (but is not restricted to) annotated graphical profiling of side-channel results such: as SPA/SEMA characterization, noise-removal test results, alignment test results, demonstrations of non- sensitive data …
Added p. 27
TA6.13 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.14 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the POI, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.

The tester is not required to perform the attack entirely but may perform all or part of the attack to verify its validity. The calculation shall be based on the methodology depicted in Appendix B. If an attack scenario can be developed that yields an attack potential of less than 35 per device for identification and initial exploitation or less than 15 per device for exploitation …
Added p. 28
TA7.3 The tester shall describe whether the POI allows for entry of non-PIN data to be passed external to the POI and whether that data is protected during the transfer. This non-PIN data must not be encrypted using the PIN key of the POI. The tester shall complete the following steps if the POI provides such functionality.

TA7.4 The tester shall describe the path from the display to the processing element that controls the display. Specifically, the tester shall note whether this is the security processor that handles PIN entry and/or cryptographic keys, or whether a different processing element is used. The tester shall include information on any connectors, cables, or other sub-components that lie in this path.

TA7.5 The tester shall describe the physical protections implemented to secure access to the display and path from the display to the controlling processing element. The tester shall make specific note of the following:

a) …
Added p. 29
If an attack scenario can be developed that requires an attack potential of less than 18 per device for identification and initial exploitation or less than 9 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document. Calculations shall include evidence justifying particular rating levels as being appropriate.

The tester shall present evidence of test methodologies followed and validation results.

The vendor shall provide a privacy shield providing protections as described in Appendix A of this document. Alternatively, the vendor may use less restrictive privacy-shield criteria provided that the vendor supplies rules and guidance as to how the visual observation is to be deterred by the environment in which the device is installed. These rules shall be binding for the organization placing the device …
Added p. 31
Note: For a horizontal layout, exchange “width” and “length.” TA8.9 Using the above information, the tester shall state whether it is likely that the POI will be operated as a handheld or desk-mounted device. The tester shall justify the conclusions.

TA8.10 If the device provides a privacy shield, the tester shall complete the table below with angles of observation to the center of the “5” key. If the observation angle is taken from an angle other than the absolute horizontal plane (not the “flat” plane of the POI casing) the tester shall justify why this is the case.

Angle of POI Angle of observation to Minimum angle required by Annex A1.1 Minimum angle required by Annex A1.2 The tester shall consider the examples included in Appendix A, Section A.2, of this document when evaluating the vendor's visual-observation deterrence rules. The user (acquirer or merchant) instructions provided by the vendor shall clearly state …
Added p. 33
a) The integrated circuits used to provide the encryption, and any physical protections provided to these elements.

b) What algorithm, mode of operation, and key management are used for this purpose.

c) How cryptographic keys are loaded into the read head. The tester shall note whether keys can be updated after initial loading, and whether the POI supports this (for example, through an API or internal function of the security processor).

d) The method used to generate the keys loaded into the read head, and how this ensures that these keys are unique to each POI device.

TA9.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 …
Added p. 36
TA11.2 The tester shall examine and cite any additional information (i.e., specifications, schematics, block diagrams, etc.) that contains information on tone generation during PIN entry to determine whether it supports the assertions made by the vendor.

TA11.3 The tester shall describe the method used by the POI to provide audible feedback for customer PIN entry, detailing what method is used to control both the duration and frequency of the audible tone.

TA11.4 The tester shall connect an oscilloscope to the input of the sounding device of the POI and/or use microphones to monitor the signal for each of the ten numeric buttons. The tester shall perform signal analysis and signal processing as necessary to demonstrate that audible information determining key-press values is not leaked by the POI. The signals obtained should be sufficiently free from noise for the following analysis steps to be adequately performed. Perform multiple entries for each of the …
Added p. 40
TB2.8 The tester shall detail in an appendix to the evaluation report a complete list of all APIs as defined by the vendor that are provided on each of the logical interfaces of the POI.

TB2.9 The tester shall perform a source-code review of each interface and confirm that only documented commands are implemented and that secure defaults are provided for each interface. The tester shall detail the methods used to verify the length and content of each command before processing. The tester shall derive and describe vulnerability-analysis models from source-code review and other available evidence to determine attack paths and appropriate penetration testing. These evaluation activities should be targeted on relevant security-critical functionalities such as (but not restricted to): buffer overflows; unhandled exceptions, read-access violations, and denial-of-service conditions, etc., including factors that are specific to the POI’s OS, communications protocols, and source code software language(s).

TB2.10 For systems that are designed …
Added p. 42
The tester shall confirm that

•and summarize how

•the POI vendor has a documented software-development process that details how firmware developers need to be trained to recognize and avoid common security problems.

The tester shall reference the names and versions of all relevant documents that define the software-development process.

TB3.8 The tester shall confirm that

•and summarize how

•the documented software-development process provides specific guidance for programmers, reviewers and testers, and does not rely on non-specific statements (for example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.

TB3.9 The tester shall confirm that

•and summarize how

•the certification process includes checking of all code that executes in all processing elements as listed in DTR A4.

TB3.10 The tester shall confirm that

•and summarize how

•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may …
Added p. 43
TB3.18 The tester shall outline the following information: If the firmware is based on a general-purpose operating system (like Linux or Windows CE), the steps described in TB3.15, in particular, hold for this operating system. The documentation provided by the developer shall show that state- of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues (like patch levels; not including unused packages, etc.; not being able to log into the operating system without cryptographic authentication in operational mode of the POI; not being able to use debug functions like "netdump" during operational use) with remarks indicating how each issue has been addressed for the firmware under evaluation. Similar steps need to be done for other firmware parts that are taken from external sources. The evidence provided by the developer should also include acceptance procedures, showing …
Added p. 45
Elements Used to Perform Authentication Algorithms and Key Sizes Used for Firmware Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the firmware differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of how initial code is loaded into the POI.

In the “Format of Authentication Block Column,” include details on the format and padding of the authentication block (for example X.509 certificate using OAEP padding).

TB4.9 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB4.10 If the POI allows …
Added p. 46
a) Confirm that it loads correctly into the POI. The tester shall detail the loading process.
Added p. 46
TB4.14 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.
Added p. 47
Applications are considered to be any code that can be loaded onto the device that is not firmware. This includes any non-firmware code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.

The authentication must not be performed by a component of lesser protection strength than the one for which the access is intended, OR the authentication must be performed by the target component.

TB4.1.1 The tester shall examine the vendor’s response to Section B4.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B4.1 of the PCI PTS POI Security Requirements for consistency to verify that the device enforces that only authenticated applications and application/configuration updates can be loaded onto the device. The vendor responses should clearly indicate how software authenticity is assured. The …
Added p. 48
TB4.1.9 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB4.1.10 If the POI allows for loading of multiple types of code (for example, firmware for security processor, firmware for magnetic-stripe-reader encryption chip, application code, etc.), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.

TB4.1.11 If (H)MAC method(s) are used for firmware authentication, the tester shall confirm through source-code review …
Added p. 48
TB4.1.14 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.
Added p. 49
 The signing process is performed under dual control.

 All executable files are signed.

 Software is only signed using a secure cryptographic device provided by the terminal vendor.

All executable files must be signed. By default, all other files should also be signed unless there is clear documented justification why a signature is not required (i.e., the file cannot affect the security of the device).

Signing applies to any and all files that are executed or interpreted on the system (by either the firmware or the application). The firmware will have the ability to verify file signatures and will delete anything that fails verification.

TB4.2.1 The tester shall examine the response to Section B4.2 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the application and firmware signing. The tester shall summarize the responses.

TB4.2.2 The tester shall examine any additional documentation (i.e., user guides, security policies, application guidance, etc.) containing information that …
Added p. 50
TB5.5 The tester shall confirm through testing or source-code review which of the POI interfaces provide notifications of entered values during customer PIN entry. The tester shall include the display and logical interfaces for this investigation. This evaluation activity should be focused at relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB5.6 The tester shall review the API interface of the POI and detail any options provided with the PIN entry API that may be used to alter the notification(s) output during PIN entry.

TB5.7 If the POI implements a touch screen for PIN entry, the tester shall verify that and describe how “button highlight” methods used to provide cardholder feedback do not provide visual indication of the digit entered.

TB5.8 The tester shall perform and describe a PIN entry process and monitor all of the POI interfaces during this …
Added p. 52
 Review of a small sample of compiled object code to validate that the code to clear the buffer remains in the compiled code;  Extraction of memory from a special sample device after execution of the buffer-clearing code; or  Confirmation that any compiler flags to ensure optimization are functioning as expected.

TB6.7 The tester shall confirm that and indicate how, via review, the vendor has the requirement for buffer clearing documented in their software-development practices documentation, including specific notes on how this should be done to prevent removal by compiler optimization, and that the correct implementation of this guide is reviewed as part of the firmware-verification process validated as part of DTR B3.

TB6.8 The tester shall perform any additional tests necessary to verify that all data is automatically cleared when either the transaction is completed or the device has timed out waiting for the response from the cardholder or …
Added p. 54
The items provided in the table below are for the purposes of example only:

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 TB7.7 The tester shall confirm and note in the table that all methods above conform to one of the four approved key-loading methods of TB11.5.

The tester shall include a reference to the method used (TB11.5 a, b, c, or d) in each of the rows in the table above.

TB7.8 The tester shall justify why each of the methods that can be used to load cryptographic keys enforces both dual control and split knowledge.

TB7.9 The tester shall detail any further sensitive services provided by the POI that have not been addressed as defined above. This …
Added p. 55
TB7.13 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.

TB7.14 The tester shall validate that

•and describe how

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

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

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

TB7.17 The tester shall attempt to set …
Added p. 57
Validation of the maximum timer value may involve testing of only one of the sensitive states if source-code review can confirm that the same code is used for all sensitive states. The tester shall detail the specific method of testing used, and how these results ensure that it is not possible to maintain a sensitive state for more than 15 minutes of elapsed time.

TB8.9 For all sensitive services requiring the input of passwords and key components into the POI keypad, the tester shall confirm that an inactivity time-out is implemented such that if a button is not pressed every 60 seconds, the device will exit the sensitive state.

Validation of the time-out value may involve testing of only one of the sensitive states if source- code review can confirm that the same code is used for all sensitive states. The tester shall detail the specific method of testing used and how …
Added p. 59
The tester shall review the source code of each of these services, and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB9.6 The tester shall obtain at least 128MB of random data from the POI under test. The tester shall detail the method used to generate this data, and justify why this sufficiently replicates the way in which the RNG will be used by the POI. The tester shall pass the 128MB of data through the NIST STS test program, and detail the results, indicating pass and fail results and how these demonstrate compliance to this DTR. In some situations it is necessary to repeat such tests, using additionally obtained data, to validate findings. See Appendix C.

 The …
Added p. 61
TB10.6 Using a functional sample device, the tester shall attempt to perform at least 120 PIN entry operations. The tester shall note the time taken and the response of the POI when the final transaction is performed, and whether another transaction is possible before an elapsed time of one hour from the entry of the first PIN.

TB10.7 Using a functional sample device, the tester shall perform 120 PIN entry operations in less than one hour and remove the power from the device. Upon re-powering the device, the tester shall attempt to perform another PIN entry operation and note whether this is possible. The tester shall describe the device’s behavior under this test. If the tester can perform another (121st) PIN entry, the device fails.

TB10.8 If the method used to prevent the entry of more than 120 PINs within an hour utilizes the real- time clock of the POI, the tester …
Added p. 66
TB11.16 Using the key table as a reference, the tester shall confirm that all keys are unique per device, and what method is used to ensure this is the case.

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

TB11.18 Using the table of sensitive-information storage from Requirement A4 and the key table above, the tester shall confirm:

a) No key is encrypted under a key of lesser strength; and

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

TB11.19 The tester shall detail any ways in which the POI generates keys from other keys, specifically:

a) Variants are not used across different levels of the hierarchy•for example, variants of KEKs are not used to produce working keys. The only allowable exception to this requirement is the use of TR-31 …
Added p. 66
TB11.22 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value of more than six hexadecimal values from the POI.

TB11.23 The tester shall note what methods are implemented to authenticate the cryptographic keys of the POI to ensure that they have not been modified after loading.
Added p. 67
 Key confidentiality  Key integrity  Key purpose  Algorithm used for the key  Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.

TB11.25 The tester shall confirm that any key-bundling key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-bundled key- management scheme.

TB11.26 For any methods that rely on the use of key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component …
Added p. 69
TB12.7 For each ISO-compliant PIN-block method supported by the POI, the tester shall perform a PIN entry operation and confirm that:

a) The format used is correct

b) PINs of less than 4 digits are not supported

c) PINs of more than 12 digits are not supported

d) PINs of all values between (and including) 4 to 12 digits are accepted

e) The application does not provide data for padding of format 3 PIN blocks; this padding is instead generated by the POI random number generator. Use source-code review or other information gathered during B9 to validate.

TB12.8 For PIN-block formats 0 and 3, the tester shall confirm whether the PAN values are supplied by the firmware or by the application. If the values are provided by the firmware, the tester shall confirm that the correct digits of the PAN are used in the PIN block. If the values are provided by the application, the tester …
Added p. 71
TB13.4 If the POI supports data-encryption keys, the tester shall confirm what methods are implemented to prevent the use of this function to decrypt PINs. Examples of acceptable solutions are:

 The key-usage information of any downloaded key must be cryptographically bound to the key value using accepted methods, and the device must enforce that the key is only used for the intended use.

 The addition of a new key type (slot) subsequent to the initial configuration of the device causes the zeroization of all other secret keys. Devices supporting remote key- distribution techniques using asymmetric techniques shall only support the use of such techniques for the loading of TMKs. Support shall not exist to use remote key-distribution techniques for working keys (for example, PIN, data, MAC, etc.) unless the key-usage information is cryptographically bound to each individual key.

 Downloaded data-key types must not be accepted by the device unless enciphered …
Added p. 74
B16 applies to both acquirer and vendor controlled prompts that are updatable.

Prompts stored inside the cryptographic unit are physically protected according to Requirement A7.

If the device model is to be listed as both an acquirer-controlled and a vendor-controlled display- prompts device, there must be a differentiation so customers can distinguish between the two (for example, different hardware and/or firmware versions).

Audio prompts must be considered if applicable.

Dual control must be enforced by an SCD. The SCD can be the PED itself or another device. If an SCD other than the PED enforces dual control, the vendor must either provide the SCD to third parties, or describe how an SCD must be used to comply with B16.2. The description must include an example of a specific, existing SCD that can be purchased and used to comply with B16.2. The PED must have an API that is compatible with the SCD. The complete …
Added p. 78
TB17.5 The tester shall note whether the POI is designed to allow for non-firmware applications to be executed, and what firmware functions are provided by the processor on which such non- firmware applications would execute (for example, PIN processing, cryptographic-key operations, prompt control, etc.).

TB17.7 The tester shall detail what mechanisms exist within the POI to allow for the execution of non- ROM-based configuration or program data (for example, processors, micro-controllers, FPGAs, etc.). The tester shall note which of these mechanisms execute code that has been considered in-scope (code that impacts these security requirements) of the evaluation, and which do not.

TB17.8 If the POI relies upon the use of different processors to provide for the separation between the firmware and any applications, the tester shall review and briefly describe the method of communications provided between these processors, including any physical interface and API(s).

TB17.9 If the POI allows for different applications to …
Added p. 80
TB18.3 The tester shall verify that API functionality and commands that are not required to support specific functionality are removed whenever possible or disabled if removal is not feasible.

TB18.5 The tester shall note whether the POI implements a commercial operating system, custom operating system, function executive, or other mechanism. If the POI uses a commercial operating system, the tester shall note the name and version of this system.

TB18.6 If the POI uses a commercial operating system, the tester shall review publically available sources of vulnerability information and note whether any vulnerabilities exist for this system. The tester shall note the sources reviewed and any potential vulnerabilities found, and justify why any such vulnerabilities are mitigated by the vendor configuration(s).

TB18.7 The tester shall obtain the configuration information for the operating system used in the POI.

The tester shall compare this configuration with the supplied documentation, and note whether they agree or have …
Added p. 82
TB19.2 For secure component devices the tester shall perform the following tests and describe the

c) Verify that the integration documentation is properly maintained•for example, in case of a device update. More specifically, the tester shall examine and document the vendor document-release cycle, and assess how it integrates with the device design/manufacturing update process.
Added p. 83
The policy must include all configuration settings necessary to meet these security requirements.

The policy must include 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. Procedures may differentiate between temporary and permanent removal.

An English-language version of the security policy must be made available for posting to PCI SSC.

TB20.1 The tester shall examine the vendor’s response to Section B20 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B20 of the PCI PTS POI Security Requirements for consistency.

TB20.2 The tester shall review the device security policy and note whether this clearly states the environments in which the POI is intended for use (attended, unattended or both).

TB20.3 The tester shall confirm that the security policy includes all configuration settings necessary to meet the security requirements defined …
Added p. 84
TB20.8 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B7 and assessed by the PTS laboratory.

TB20.9 The tester shall confirm that the security policy contains specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with B16, or any mechanisms used for authenticating application code as assessed under Requirements B4.

TB20.10 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords and certificates.

TB20.11 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 guidance would be: outlining methods to check the slot of …
Added p. 85
TB20.21 The tester shall examine the security policy and relevant vendor documentation to verify that the device has update and patch procedures required for the secure operation of the device and that the procedures are included in the security policy. The policy will include both local and remote update and patch downloading procedures for software, firmware, and configuration parameters, including those necessary for meeting Section J of the Open Protocols Module.

TB20.22 The tester shall confirm that the security policy includes any communication methods and protocols, including wireless, used by the device. Use of any method not listed in the policy invalidates the device approval.

TC1.3 Referencing the key table provided in Requirement B11, the tester shall note whether the POI:

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 …
Added p. 89
If an attack scenario can be developed that requires an attack potential of less than 20 per device for identification and initial exploitation or less than 10 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document. Calculations shall include evidence justifying particular rating levels as being appropriate.

Tamper Grid Physical Implementation Size of Traces and Distance between Traces, Signals, or Tamper- detecting Signals Method of Connection Adjacent Signals? The tester shall describe what testing was performed to validate the protection provided by each of the tamper grids enumerated above.

TD1.17 From the above description the tester shall justify how the customer ICC I/O path is protected from interception at all points. Specifically, the tester shall note whether it is possible to intercept the …
Added p. 99
TE3.3.4 The tester shall establish a comprehensive list of all components, together with their relationship and qualification against security, and verify that they are physically or logically segregated.

TE3.4.3 The tester shall detail where prompts used for non-PIN entry are stored within the POI and describe the protections implemented to protect these prompts. The tester shall reference this information to the table of sensitive information provided in DTR A4.

TE3.4.7 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.

TE3.4.8 The tester shall develop attack scenarios to circumvent the control of the display by the device.

If an attack scenario can be developed that requires an attack potential of less than 18 per device for identification …
Added p. 104
b) Cryptographic mechanisms are used instead of dual control, and these mechanisms implement protections against replay and man-in-the-middle attacks.

For both of the above cases, the tester shall detail whether the POI is able to process PIN transactions while the removal detection mechanisms are disabled.

TE4.1.6 The tester shall note what mechanisms are used to detect the removal of the POI from its installed environment. The tester shall provide photographs of the mechanism(s).

TE4.1.7 The tester shall detail the testing apparatus used to emulate the POI installation environment so that the removal detection mechanisms can be tested. The tester shall provide photographs or other images as required to demonstrate evaluation techniques and conclusions.

TE4.1.8 The tester shall detail what occurs if the removal detection mechanism(s) are activated, and justify how this prevents the use of the POI for PIN entry.

TE4.1.9 The tester shall note whether the POI allows for authorized removal, such that the …
Added p. 107
The objective of this section is to identify all physical interfaces and the corresponding logical protocols that are supported by the device. It is required that a device vendor knows of all interfaces and protocols supported by the device, and provide details of these protocols and interfaces within documentation.

Interfaces, which provide for communications, such as but not limited to:

 Ethernet  Bluetooth  Cellular (GPRS and CDMA) Protocols, such as: but not limited to:

 UDP Light  TLS1.2 or above* The vendor must also identify where they derive their code that is used to implement protocols, as well as document all protocols and which physical interfaces they apply to.

The tester is required to verify the claims of the vendor to ensure that the vendor listing of physical and logical interfaces in complete. This requires the tester to both identify physical interfaces through analysis of the design, as well as verify …
Added p. 108
Example Protocol Table Component Handling the Source Code Security Protocol Additional Information IP (General) Security Processor Linux (3.7.1) TLS 1.2 Security Processor OpenSSL (1.0.1g) GPRS GPRS Modem Modem vendor IP (GPRS) GPRS Modem Modem vendor TF1.5 The tester shall perform any additional tests necessary to validate the device’s documented list of protocols, services, and physical interfaces. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support to access and use the interfaces under test.
Added p. 109
The intent of this requirement is to ensure that the vendor has an effective process for detecting vulnerabilities within protocols and interfaces implemented in firmware.

It is understood that vulnerability survey only represents a snapshot in time, and that vulnerabilities may become known in the public domain after that time. It is therefore expected that the vulnerability analysis incorporate up-to-date assessment mechanisms.

The mechanism the vendor uses to assess each protocol and interface should be effective for that protocol or interface. For example, it is not acceptable to use automated network scanning tools to assess a client type protocol for vulnerabilities.

If an OEM module is present and shares resources with the rest of the device, a vulnerability assessment is required to ensure that the OEM module cannot adversely impact the function of the device.

TG1.1 The tester shall inspect the vendor vulnerability assessment procedures to verify the assertions provided by the vendor in …
Added p. 111
a) The vulnerability-disclosure measures are documented.

b) The vulnerability-disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description, and assessment of the vulnerabilities.

c) The vulnerability-disclosure measures ensure a timely distribution of mitigation measures.

The intent of this requirement is to ensure that the vendor has a process whereby they are able to disclose vulnerabilities that affect the device.

The vendor must maintain documentation that describes their internal processes.

The vendor’s processes must ensure that vulnerability information is disclosed to relevant parties within two weeks of discovery.

TG3.1 The tester shall inspect the vendor vulnerability disclosure procedures to verify the assertions provided by the vendor in response to Section G3 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s internal policy. The vendor must clearly indicate that their vulnerability disclosure measures are correctly and in a timely manner. The tester shall summarize the responses.

TG3.3 The tester …
Added p. 113
The objective of this section is to verify the default configuration for interfaces and communications as defined by the vendor documentation and Section F1.

The lab must assess that the default configuration for each interface is not in an unsecure state and that non-essential services are disabled.

TH2.1 The tester shall inspect the vendor configuration guidance document to verify the assertions provided by the vendor in response to Section H2 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s default configuration settings each for the protocols and interfaces. The vendor must ensure that the all default configuration values are configured in a secure state or in a disabled state. The tester shall summarize the responses for each interface.

TH2.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to …
Added p. 115
This DTR must be executed and separately reported, per a security protocol that is indicated to be suitable for financial applications or device management.

The declared security protocol is able to ensure confidentiality, integrity, server authentication, and protection against replay.

THI.1 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s use of secure protocols. The vendor must ensure that the guidance is complete and correct and covers each protocol listed in Section F1. The tester shall summarize the responses.

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

THI.3 The tester shall assess the …
Added p. 124
TJ4.1 The tester shall examine the vendor’s response to Section J4 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module

• Protocol Declaration Form, and the response to Requirement J4 of the PCI PTS POI Security Requirements manual to verify that the vendor has clearly documented security guidance for terminal updates. The tester shall summarize the responses.

TJ4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail device authentication measure processes and procedures for configuration and software updates of the POI device.

TJ4.3 The tester shall assess the device to ensure the declared terminal update solution is implemented, which must:

 Be complete, clear, and unambiguous;  Via the update mechanism, ensure security, i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol;  Cover all elements of device maintenance including terminal updates to configuration files, firmware and …
Added p. 127
In general, techniques may include any combination of tamper-detection methods. Security mechanisms must not rely on insecure services or characteristics provided by the device such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods involving tamper evidence are not considered a security mechanism.

This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.

TK1.2.1 The tester shall examine the response to Section K1.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.2 of the PCI PTS POI Security Requirements manual for consistency relevant to DTR K1.2. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise device security. The tester shall summarize the responses.

TK1.2.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify …
Added p. 130
The tester shall describe any assistance provided by the vendor to ensure efficient side- channel testing•for example, command scripts, event triggers, etc.

TK3.9 Where the results indicate that key recovery is not possible, the tester shall justify the methodologies used and findings. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device, consistent with an attack cost rating of 26 for identification and initial exploitation with a minimum of 13 for exploitation Justifications of these to be reported shall include (but are restricted to): the number of sample recordings acquired, sampling frequencies, alignment methods, signal analysis / filtering techniques, and correlation function(s) used, etc. Evidence to support this shall include (but is not restricted to) annotated graphical profiling of side-channel results such: as SPA/SEMA characterization, noise-removal test results, alignment-test results, demonstrations of non- sensitive data leakage, …
Added p. 131
TK3.14 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the POI, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.

The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.

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 attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document.

The independent expert must be qualified via a combination of education, training, and experience …
Added p. 137
TK7.4 Using the key table in K17 as a reference, the tester shall confirm that all keys are unique per device, and what method is used to ensure that this is the case.

Key variants are only used in devices that possess the original key (for example, the POI device and the host it communicates with). Key variants are not used at different levels of the key hierarchy•i.e., a variant of a key-encipherment key used for key exchange cannot be used as a working key or as a master file key for local storage.

Private keys shall only be used to create digital signatures and to perform decryption operations. Private keys shall never be used to encrypt other keys.

TK8.3 Through source-code review, the tester shall confirm what methods the POI device uses to confirm the purpose and integrity of each key. The tester shall validate that this does not reduce the effective …
Added p. 141
The vendor shall indicate the compiler settings used in order to maximize the mitigation of known vulnerabilities.

The vendor shall implement measures to help prevent common exploits of "buffer overflow" and similar vulnerabilities. Strategies by the developer to address these vulnerabilities may include:

 Avoiding them by design (extreme example: using a programming language, which prevents buffer overflow by definition);  Finding them by adequate testing (for example, static-code analysis or comprehensive fuzz testing); and/or  Mitigating them by techniques like techniques that include but are not limited to Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Harvard Architecture and Stack Canaries.

The vendor shall document where labs may place reliance upon this in connection with K13 and other relevant requirements.

TK10.5 The tester shall detail any compiler settings used by the vendor in order to maximize the mitigation of known vulnerabilities.

TK10.6 The tester shall detail any mitigation techniques used by the vendor …
Added p. 142
TK10.8 The tester shall confirm that

•and summarize how

•the documented software-development process provides specific guidance for programmers, reviewers, and testers and does not rely on non-specific statements. For example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.

TK10.9 The tester shall confirm that

•and summarize how

•the certification process includes checking of all code that executes in all processing elements as listed in DTR A4.

TK10.10 The tester shall confirm that

•and summarize how

•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the POI firmware.

TK10.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the POI code.

TK10.12 The tester shall …
Added p. 143
TK10.18 The tester shall outline the following information. If the firmware is based on a general-purpose operating system (like Linux or Windows CE), the steps described in TK10.15, in particular, hold for this operating system. The documentation provided by the developer shall show that state-of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues (like patch levels; not including unused packages, etc.; not being able to log into the operating system without cryptographic authentication in operational mode of the POI; not being able to use debug functions like "netdump" during operational use) with remarks indicating how each issue has been addressed for the firmware under evaluation. Similar steps need to be done for other firmware parts that are taken from external sources. The evidence provided by the developer should also include acceptance procedures, showing how …
Added p. 145
TK11.1.9 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TK11.1.10 If the POI allows for loading of multiple types of code (for example, firmware for security processor, firmware for magnetic-stripe-reader encryption chip, application code, etc.), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.

TK11.11 If (H)MAC method(s) are used for firmware authentication, the tester shall confirm through source-code review …
Added p. 148
The firmware and application version numbers must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. This shall be illustrated by photographic evidence provided in the evaluation report.
Added p. 149
Processing/ Elements Used to Perform Authentication Algorithms and Key Sizes Used for Firmware Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the firmware differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of how initial code is loaded into the POI.

TK12.9 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TK12.10 If the POI allows for loading of multiple types of code (for example, firmware for security processor, firmware for magnetic-strip-reader encryption chip, application code, etc.), the tester …
Added p. 150
TK12.14 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.

All interfaces and associated communication methods of the device must be assessed. The interfaces must be documented and assessed regardless of whether they are used for or have access to card data. Sufficient evidence must be provided to demonstrate the validity of laboratory assessments.

The Open Protocol Module shall be used to assess any communication method that uses a wireless, local, or wide-area network to transport data. This would include, but is not limited to: Bluetooth, Wi- Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless …
Added p. 152
TK13.9 The tester shall perform a source-code review of each interface and confirm that only documented commands are implemented and that secure defaults are provided for each interface. The tester shall detail what methods are used to verify the length and content of each command before processing. The tester shall derive and describe vulnerability-analysis models from source-code review and other available evidence to determine attack paths and appropriate penetration testing. These evaluation activities should be targeted on relevant security-critical functionalities, such as (but not restricted to): buffer overflows; unhandled exceptions, read-access violations, and denial-of-service conditions, etc., including factors that are specific to the POI’s OS, communications protocols, and source-code software language(s).

TK13.10 For systems that are designed to execute non-firmware applications, the tester shall use the development environment for the POI to create a program with a buffer-overflow vulnerability. The tester shall determine that the device behaves in accordance with the …
Added p. 157
The tester shall summarize the responses.

 Review of a small sample of compiled object code to validate that the code to clear the buffer remains in the compiled code;  Extraction of memory from a special sample device after execution of the buffer-clearing code; or  Confirmation that any compiler flags to ensure optimization are functioning as expected.

TK15.2.3 The tester shall verify that

•and summarize how

•the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive account data is included. Passwords, plaintext cryptographic keys, or key components outside of the crypto- processor, and account data are included.

TK15.2.4 The tester shall review the source code of the POI and confirm that

•and summarize how account data is cleared from all storage locations after use, including local variables (before exiting the function) and registers. The tester shall detail the methods used to perform the erasure.

TK15.2.5 The …
Added p. 158
TK15.2.8 The tester shall perform any additional tests necessary to verify that all data is automatically cleared when either the transaction is completed or the device has timed out waiting for the response from the cardholder or merchant•for instance, by performing a partial simulated transaction to verify the behavior at time-out, or in general by entering the states that have been defined by the vendor under TK15.1.

The salt may be unique per transaction, unique per a group of transactions, unique per device, or unique per merchant.

 Salts that are unique per transaction or otherwise unique per device must be generated by the transaction device.

 Salts that are unique per merchant are generated outside the transaction device and require loading to each merchant device. The vendor must supply documentation to the merchant/acquirer processor on how to securely load the salt values and that this loading is treated as a sensitive service …
Added p. 163
Entry of key components without the use of at least two separate passwords/PINs results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.

TK17.6 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange, or establishment are stated in Appendix D.

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

TK17.8 The tester shall determine from vendor documentation how (for example, active or passive erasure) each key is destroyed for all device states (power-on, power-off, …
Added p. 166
TK17.15 Using the key table as a reference, the tester shall confirm that all keys are unique per device, and what method is used to ensure that this is the case.

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

TK17.17 Using the table of sensitive-information storage from Requirement A 5 (if applicable) and the key table above, the tester shall confirm:

a) No key is encrypted under a key of lesser strength,

TK17.18 The tester shall detail any ways in which the POI generates keys from other keys, specifically:

b) The tester shall detail any key-generation methods used and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.

TK17.19 The tester shall note whether the POI generates any keys using an internal random number generator. The tester shall confirm through source-code review that these keys …
Added p. 167
TK17.24 The tester shall confirm that any key-bundling key can only be used for that purpose, and cannot be used as a “generic” master or working key, as part of a non-bundled key- management scheme.

TK17.25 For any methods that rely on the use of key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. The requirements of this DTR are not met if it is possible to load a key where the value of that key can be known through knowledge of only one component. The findings of these tests shall be explained.

The tester may rely upon vendor testing as appropriate to …
Added p. 170
TK19.7 Using a POI that has been configured (using special test code from the vendor which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.

TK19.8 The tester shall detail whether the self-test program used above executed correctly at all times during each of the tests above, within the ranges before activation of the environmental detection circuitry.

TK19.9 Given the details and results above, the tester shall justify why the tamper-detection mechanisms will remain functional and the POI secure at all extremes within the range of environmental monitoring.

Applications are considered to be separated by access rights. Applications may share data by design.

The addition of applications that replace or disable the PCI-evaluated …
Added p. 172
TK20.5 The tester shall note whether the POI is designed to allow for non-firmware applications to be executed, and what firmware functions are provided by the processor on which such non- firmware applications would execute (for example, account-data processing, cryptographic-key operations, prompt control, etc.).

TK20.7 The tester shall detail what mechanisms exist within the POI to allow for the execution of non- ROM-based configuration or program data (for example, processors, micro-controllers, FPGAs, etc.). The tester shall note which of these mechanisms execute code that has been considered in-scope (code that impacts these security requirements) of the evaluation, and which do not.

TK20.8 If the POI relies upon the use of different processors to provide for the separation between the firmware and any applications, the tester shall review and briefly describe the method of communications provided between these processors, including any physical interface and API(s).

TK20.9 If the POI allows for different applications to …
Added p. 174
The intended operation is considered as the functionality relevant to B2. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals.

TK21.6 The tester shall note whether the POI implements a commercial operating system, custom operating system, function executive, or other mechanism. If the POI uses a commercial operating system, the tester shall note the name and version of this system.
Added p. 175
TK21.8 The tester shall obtain the configuration information for the operating system used in the POI.

The tester shall compare this configuration with the supplied documentation and note whether they agree or there are differences. If differences are detected, it is necessary to address why these occur with regards to compliance to this requirement.

TK21.9 The tester shall obtain the configuration policy from the vendor detailing the testing and methodology used to determine the functions necessary for the POI execution environment. The tester shall reference the name and version of this document. The tester shall justify that this document sufficiently details the steps necessary to reduce the functionality of the POI to only those components and services necessary for the intended operation of the device.

TK22.3 The tester shall verify from vendor documentation

•and summarize

•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive …
Added p. 177
a) Why any packets that do not have an authentication parameter attached cannot be used as part of a man-in-the-middle attack.

b) Why any freshness indicators are sufficient to prevent replay of any part of the message that would result in the re-loading of a previously installed cryptographic key.

c) Why it is not possible for any party, other than the “owner” of the existing public key, to change any public key in the device once it has been initially loaded.

The tester shall include a reference to the method used (TK17.5 a, b, c, or d) in each of the rows in the table above.

TK22.6 The tester shall justify why each of the methods that can be used to load cryptographic keys enforces both dual control and split knowledge.

TK22.7 The tester shall detail any further sensitive services provided by the POI that have not been addressed as defined above. This must include …
Added p. 179
For sensitive services requiring the input of two or more passwords, the maximum timer must be started upon entry of the first password digit and include the time taken to both enter the password and perform the service that password authenticates (for example, entry of a single key component, or access to a sensitive menu function). If the POI separates the entry of each component such that a single password is entered prior to each component value, it is not necessary for the POI to implement the timer between each password/component entry operation.

Validation of the maximum timer value may involve testing of only one of the sensitive states if source-code review can confirm that the same code is used for all sensitive states. The tester shall detail the specific method of testing used and how these results ensure that it is not possible to maintain a sensitive state for more …
Added p. 180
The organization must utilize a documented and approved secure change management system, such that all development is traceable and access restricted. All changes should be reviewed and approved prior to release. The change control procedures shall include the unique identification of all configuration items and their developer, including the device, its parts (such as ICCR, MSR, and keyboard) and its firmware.

TL1.1 The tester shall examine the vendor’s response to Section L1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L1 of the PCI PTS POI Security Requirements for consistency relevant to physical and functional change control procedures. The tester shall summarize the responses.

TL1.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail change control processes and procedures for physical and functional changes to the POI device, describing how the items are uniquely identified such that it is …
Added p. 180
TL1.5 The tester shall interview those responsible for the change control processes (including engineers and programming staff, supervisory staff, technical management, etc.) to verify that the documented and approved procedures are known and understood by all affected parties.

TL1.6 The tester shall examine a sample of documentation of physical and functional changes to POI devices, such as change control logs, to validate that procedures are followed, including the submission and sign-off processes.
Added p. 181
 All changes to PCI approved devices have been submitted for re-evaluation; or  Only changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality are deferred from submission and not submitted immediately, but are instead submitted on an aggregate basis.
Added p. 182
All certified firmware must be signed prior to distribution and signed using dual control. It should be managed such that no single person is able to sign files. If two secrets (passwords or PINs) are required for operation of the signing tool, no single person should know both secrets. All certified firmware must be reviewed against the organization’s coding standards prior to signature.

TL2.1 The tester shall examine the vendor’s response to Section L2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L2 of the PCI PTS POI Security Requirements for consistency relevant to certified firmware control procedures. The tester shall summarize the responses.

TL2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control and validation processes and procedures for storage during the manufacturing process.

TL2.3 The tester shall examine and cite any supporting documentation submitted by the …
Added p. 183
TL3.1 The tester shall examine the vendor’s response to Section L3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L3 of the PCI PTS POI Security Requirements for consistency relevant to device component control procedures. The tester shall summarize the responses.

TL3.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement.. The documentation should detail the components used and the component control processes and procedures for storage and verification during the manufacturing process including components identification verification, with the procedures checked in TL1.2. .

TL3.3 The tester shall interview those responsible for component control processes (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the documented and approved procedures are known and understood by all affected parties.

TL3.4 The tester shall examine the device parts listing and sample components during manufacturing, …
Added p. 184
All software (e.g., firmware) loaded into the device must be signed prior to use and all software (e.g., firmware) needs to be controlled and protected during manufacturing. All software (e.g., firmware) must be validated before each use to prevent unauthorized modifications and/or substitutions.

TL4.1 The tester shall examine the vendor’s response to Section L4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L4 of the PCI PTS POI Security Requirements for consistency relevant to production firmware control procedures. The tester shall summarize the responses.

TL4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for loading firmware during the manufacturing process.

TL4.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for transporting and storing firmware during the manufacturing process and …
Added p. 185
Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an accessed controlled area until shipped. The device or components must be checked prior to shipping to ensure the device has not been modified or tampered.

TL5.1 The tester shall examine the vendor’s response to Section L5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L5 of the PCI PTS POI Security Requirements for consistency relevant to post-production storage. The tester shall summarize the responses.

TL5.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail documented and approved post-production control processes and procedures for storage and validation of devices or their components subsequent to production but prior to shipping.

TL5.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail tamper-evident packaging or the …
Added p. 186
TL6.1 The tester shall examine the vendor’s response to Section L6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L6 of the PCI PTS POI Security Requirements for consistency relevant to secret information. The tester shall summarize the responses.

TL6.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the key-loading facility or the facility of initial deployment by means of secret information placed in the device during manufacturing, this secret information is unique to each device, unknown, and unpredictable to any person.

TL6.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the key- loading facility or the facility of initial deployment by means of secret information placed in the device during manufacturing, …
Added p. 187
The PCI Terminal Software Security Best Practices Guidance document can provide additional guidance for software development and testing.

TL7.1 The tester shall examine the vendor’s response to Section L7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L7 of the PCI PTS POI Security Requirements for consistency relevant to component control procedures during design and development. The tester shall summarize the responses.

TL7.2 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 following additional steps:

TL7.3 The tester …
Added p. 188
Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an accessed controlled area until shipped. The device or components should be checked prior to shipping to ensure the device has not been modified or tampered.

TL8.1 The tester shall examine the vendor’s response to Section L8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement L8 of the PCI PTS POI Security Requirements for consistency relevant to repair and inspection subsequent to repair. The tester shall summarize the responses.

TL8.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail repair, including the resetting of tamper mechanisms, inspection, and post-inspection control processes and procedures for storage and validation of devices or their components subsequent to repair and inspection but prior to shipping.

TL8.3 The tester shall examine, cite, and reference any supporting documentation …
Added p. 189
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key- loading facility or to the facility of initial deployment and stored en route under auditable controls that can account for the location of every POI at every point in time.

Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.

The product shall be protected for at all points during the shipping process. Tamper-evident packaging, instructions for receiving and inspection, and documentation should tamper be suspected, must be provided and used.

TM1.1 The tester shall examine the vendor’s response to Section M1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M1 of the PCI PTS POI Security Requirements for shipping tamper protection documentation. The tester shall summarize the responses.

TM1.2 The …
Added p. 191
The product shall be accounted for at all points during the shipping process until transfer of responsibility. Documentation shall be maintained for each POI.

TM2.1 The tester shall examine the vendor’s response to Section M2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M2 of the PCI PTS POI Security Requirements for device-accountability transfer procedures. The tester shall summarize the responses.

TM2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment Where required to validate via site …
Added p. 192
 Shipped and stored in tamper-evident packaging; and/or  Shipped and stored containing a secret that is immediately and automatically erased if any physical or functional alteration to the device is attempted, that can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.

TM3.1 The tester shall examine the vendor’s response to Section M3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M3 of the PCI PTS POI Security Requirements for shipping tamper protection documentation. The tester shall summarize the responses.

TM3.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 and describe how this shows compliance to this requirement.

TM3.3 The tester shall interview those responsible for the shipping control processes (including engineers, software …
Added p. 193
TM4.1 The tester shall examine the vendor’s response to Section M4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M4 of the PCI PTS POI Security Requirements for consistency relevant to assure the authenticity of the TOE’s security relevant components at the initial key-loading facility. The tester shall summarize the responses.

TM4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the device’s development-security documentation to ensure the authenticity of the devices security relevant components and describe how this shows compliance to this requirement.

TM4.3 The tester shall interview those responsible for the initial key-loading facility (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved documented procedures are known and understood by all affected parties.

TM4.4 The tester shall examine a sample of documentation for device-development security, including user documentation, and component validation procedures …
Added p. 194
TM5.1 The tester shall examine the vendor’s response to Section M5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M5 of the PCI PTS POI Security Requirements for consistency relevant to assure the authenticity of the POI security related components. The tester shall summarize the responses.

TM5.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures for the manufacturer to ensure the authenticity of the devices security relevant components.

TM5.3 The tester shall interview those responsible for the initial key-loading facility (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.

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

TM5.5 The tester shall observe the initial key-loading procedures to ensure the …
Added p. 195
TM6.1 The tester shall examine the vendor’s response to Section M6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M6 of the PCI PTS POI Security Requirements for consistency relevant to assure the manufacturer provides the means to the initial key-loading facility to assure the authenticity of the POI security-related components. The tester shall summarize the responses.

TM6.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures provided by the manufacturer to the initial key-loading facility to assure the authenticity of the devices security relevant components for the initial key- loading facility.

TM6.3 The tester shall interview those responsible for the initial key-loading facility (including engineers and line staff, supervisory staff, technical management, etc.) to verify that the approved and documented procedures are known and understood by all affected parties.
Added p. 196
TM7.1 The tester shall examine the vendor’s response to Section M7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M7 of the PCI PTS POI Security Requirements for consistency relevant to the manufacturer providing a unique visible identifier for each device. The tester shall summarize the responses.

TM7.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail how the change control procedures required in L1 are used in compliance with this requirement.

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

TM7.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 L1.
Added p. 197
 Data on production and personalization  Hardware version identification  Repair and maintenance  Removal from operation  Loss or theft The operational management manual provides instructions and information concerning the identification, use, repair, updates, and configuration of hardware and firmware components of the device. This manual is in addition to user and application operation and configuration manuals.

TM8.1 The tester shall examine the vendor’s response to Section M8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M8 of the PCI PTS POI Security Requirements for consistency relevant to assure the vendor maintains a manual that provides instructions for the operational management of the POI. The tester shall summarize the responses.

TM8.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should include instructions for recording the entire life cycle of …
Added p. 206
d) Equipment required such as instruments, components, IT hardware, and software required for the

b) Potential to acquire the required knowledge of the PIN entry device’s design and operation;
Added p. 214
 A function of the device requires a PIN to be entered for every execution of the cryptographic calculation exercising the key under attack.  The data input for DPA can be acquired from an external interface of the PIN entry device. The PIN entry device need not be further physically attacked to get the required test data.  The PIN entry device does not have robust DPA countermeasures.

2. Develop the attack set-up, including controls to exercise the PIN entry device, sufficiently automated to acquire recordings from multiple PIN entry events. This requires a bespoke mechanical interface to be developed to perform many PIN entries sequentially. This equipment will be used for both Identification and Exploitation.

3. Acquire DPA measurements from the device. A few thousand PIN entry steps inducing the target encryption events must be collected. In the Identification phase, collections may have to be repeated several times before it …
Added p. 216
The tester shall use NIST's STS tool, version 2.1.2 or later, or its mathematical equivalent. The tester shall verify that the compiled instance of the STS tool is operating correctly on the testing device by testing the NIST-provided sample data and comparing the results with those found in NIST SP 800-22 Revision 1a (SP800-22r1a), Appendix B. This configuration guidance is for use with STS version 2.1.2, though it will likely continue to be applicable to future versions.

A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009], and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the …
Added p. 219
Minimum key size in number of bits: 112 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys sizes by row are considered equivalent.

DSA/D-H AES Minimum key size in number of bits: 112 1024 160 1024/160

• Minimum key size in number of bits: 168 2048 224 2048/224

• Minimum key size in number of bits:

• 3072 256 3072/256 128 Minimum key size in number of bits:

• 7680 384 7680/384 192 Minimum key size in number of bits:

• 15360 512 15360/512 256 DES refers to TDES keys with non-parity bits. The RSA key size refers to the …
Modified p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 3.1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements Version 4.1b
Removed p. 7
For example, the first component under the section for DTR A.1.1 is:
Modified p. 7
 POS Terminal Integration Derived Test Requirements,  Core PIN Entry Derived Test Requirements,  Open Protocols Derived Test Requirements, and  Secure Reading and Exchange of Data Derived Test Requirements Each PCI requirement as stated in the PCI PTS POI Security Requirements manual is represented by a subsection. For example, Requirement P1.1 is represented in this document as:
 Core PIN Entry Derived Test Requirements,  POS Terminal Integration Derived Test Requirements,  Open Protocols Derived Test Requirements, and  Secure Reading and Exchange of Data Derived Test Requirements Structure of the DTRs Each PCI requirement as stated in the PCI PTS POI Security Requirements manual is represented by a subsection. For example, Requirement A1 is represented in this document as:
Modified p. 7
DTR A1.1 Tamper-Detection Mechanisms When appropriate, each PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement.
DTR A1 Tamper-Detection Mechanisms Each PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement. These components parts are DTRs.
Modified p. 7
DTRs are provided under each of these components. These are identified by a ―T,‖ followed by the component identification number, which is followed by a number that distinguishes it from the other DTRs of the same component. For example, the first DTR under A1.1 is:
These are identified by a “T,” followed by the component identification number For example, the first DTR under A1 is:
Modified p. 8 → 9
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario.
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario. All attacks shall include a minimum of ten hours’ attack time for exploitation.
Modified p. 8 → 10
Requirement A7 focuses on determination of secret or private keys. This requirement focuses on tamper-detection and response mechanisms in place to prevent PIN disclosure.
Requirement A6 focuses on determination of secret or private keys. This requirement focuses on tamper-detection and response mechanisms in place to prevent PIN disclosure.
Modified p. 8 → 10
―Immediate‖ is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.
“Immediate” is defined as fast enough to ensure erasure occurs before the tamper-detection mechanisms can be disabled using attack methods described in A1.
Modified p. 8 → 10
For those devices that do not contain secret information, device disablement may be used in lieu of ―immediate erasure of all secret information.‖ ―Secret information‖ consists of any private or secret cryptographic keys that the device relies on to maintain security characteristics governed by PCI requirements. If any of these keys are not zeroized, then other mechanisms must exist to disable the device, and these keys must be protected in accordance with Requirement A7.
For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information.” “Secret information” consists of any private or secret cryptographic keys that the device relies on to maintain security characteristics governed by PCI requirements.
Modified p. 8 → 10
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 secret data and therefore do not need to be erased•e.g., 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, 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.
Removed p. 9
TA1.1.3 The tester shall open the device to activate the tamper-detection mechanisms and then perform tests to support evidence that the device is no longer operational. The tester shall then perform tests to support evidence that keys and secret data have been erased or are otherwise non-recoverable. Tests that may be performed could include attempting a transaction to determine if the transaction fails, using a special function of the device that allows a user to determine the status of secret data, or using special software to determine whether secret data has been erased.

TA1.1.4 The tester shall examine the response to Section A1.1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to response of the PIN entry device to tamper detection, for consistency.

TA1.1.5 The tester shall examine vendor-supplied documentation to determine whether the device employs active or passive (i.e., removal of power) erasure. If the device employs passive erasure, the …
Modified p. 9 → 11
TA1.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA1.2 The tester shall examine and cite any additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 10 → 17
This requirement does not imply the need for redundant security mechanisms.
This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.
Modified p. 10 → 17
TA1.2.1 The tester shall examine the response to Section A1.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A1.2 of the PCI PTS POI Security Requirements manual for consistency relevant to DTR A1.2. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise device security.
TA.2.1 The tester shall examine the response to Section A2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A2 of the PCI PTS POI Security Requirements manual for consistency relevant to DTR A2. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise device security. The tester shall summarize the responses.
Modified p. 10 → 17
TA1.2.2 The tester shall examine any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA2.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 10 → 17
TA1.2.3 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.
TA2.3 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.
Removed p. 11
The ICC reader may consist of areas of different protection level: the areas of the IC card itself and the area holding retracted cards.

―Immediate‖ is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.

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

TA2.1 The tester shall examine the response to Section A2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A2 of the PCI PTS POI Security Requirements for consistency relevant to A2.

TA2.2 The tester shall examine any relevant documentation, such as assembly …
Removed p. 13
TA3.3 The tester shall verify that the vendor‘s stated measures protect against the compromise of the device by altering either environmental conditions or operational conditions, and assess the adequateness of the vendor test procedures and reports.
Modified p. 13 → 18
 Environmental conditions  Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) The vendor must either provide substantive data to support the security of the product outside normal operating conditions, or show that the product uses sensors that will trigger a tamper response.
 Environmental conditions  Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) The vendor must either provide substantive data to support the security of the product functioning outside normal operating conditions, or show that the product uses sensors that will trigger a tamper response.
Modified p. 13 → 18
TA3.1 The tester shall examine the response to Section A3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI PTS POI Security Requirements manual for consistency relevant to Requirement A3. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions.
TA3.1 The tester shall examine the response to Section A3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI PTS POI Security Requirements manual for consistency relevant to Requirement A3. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.
Modified p. 13 → 18
TA3.2 The tester shall examine any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc., submitted by the vendor to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions.
TA3.2 The tester shall examine and cite any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc., submitted by the vendor to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions. Such information must be clearly referenced.
Modified p. 13 → 19
TA3.4 The tester shall develop attack scenarios to compromise the device by altering environmental and or operational conditions.
TA3.10 The tester shall develop attack scenarios to compromise the device by altering operational conditions, and consider whether altering environmental conditions may be used to develop attacks.
Modified p. 13 → 19
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
TA3.11 The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.
Removed p. 14
TA4.2 The tester shall examine any additional relevant documentation, such as assembly drawings and functional specifications submitted by the vendor to verify that it supports the vendor responses.

TA4.4 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms dealing with sensitive information and functions, 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.
Modified p. 14 → 20
TA4.1 The tester shall examine the response to Section A4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI PTS POI Security Requirements Manual for consistency relevant to Requirement A4. The vendor responses should clearly indicate what sensitive information and functions exists; and that sensitive functions or information are only used in the protected area(s) of the device; and that sensitive information and functions dealing with sensitive information are protected from modification.
TA4.1 The tester shall examine the response to Section A4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI PTS POI Security Requirements Manual for consistency relevant to Requirement A4. The vendor responses should clearly indicate what sensitive information and functions exists; and that sensitive functions or information are only used in the protected area(s) of the device; and that sensitive information and functions dealing with sensitive information are protected from modification. …
Modified p. 14 → 22
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
The tester may perform any test needed to validate the attack scenario.
Removed p. 15
TA5.1 The tester shall examine the vendor‘s response to Section A5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS POI Security Requirements for consistency relevant to A5.1.

TA5.2 The tester shall examine any additional information (i.e., specifications, schematics, block diagrams, etc.) that contains information on tone generation during PIN entry to determine whether it supports the assertions made by the vendor.

TA5.3 The tester shall verify that any audible tones accompanying PIN entry are indistinguishable, by analyzing or measuring the tone/tone-generation circuitry.
Removed p. 16
TA6.3 The tester shall visually inspect the device to verify the assertions provided by the vendor in the PCI PTS POI Evaluation Vendor Questionnaire relating to protections against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring. This could include verifying that any components that provide protection are as stated by the vendor.

TA6.4 The tester shall perform a sample transaction to verify the assertions provided by the vendor relating to protections against monitoring.
Modified p. 16 → 23
For A6 monitoring sound refers to other audible sounds apart from the beep generated by the device when a key is pressed.
For A5 monitoring sound refers to other audible sounds apart from the beep generated by the device when a key is pressed.
Modified p. 16 → 23
Methods such as video monitoring and shoulder surfing are addressed in A9.
Methods such as video monitoring and shoulder surfing are addressed in A8.
Modified p. 16 → 23
TA6.2 The tester shall examine any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS POI Evaluation Vendor Questionnaire.
TA5.2 The tester shall examine and cite any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS POI Evaluation Vendor Questionnaire.
Modified p. 16 → 24
TA6.5 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.
TA5.10 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring, using attack scenarios. If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one …
Modified p. 16 → 24
Monitoring must be done outside the protected areas of the device components (like the PIN entry device or ICC reader) and address the transmission inside these device components.
Monitoring must be done outside the protected areas of the device components (such as the PIN entry device’s tamper-protected casing, or ICC reader) and must investigate any data emanating from inside these device components.
Modified p. 16 → 25
TA6.1 The tester shall examine the vendor‘s response to Section A6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A6 of the PCI PTS POI Security Requirements for consistency relevant to A6.
TA6.1 The tester shall examine the vendor’s response to Section A6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A6 of the PCI PTS POI Security Requirements for consistency relevant to A6. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any PIN-security-related cryptographic key resident in the device. The tester shall summarize the responses.
Removed p. 17
The vendor may need to supply specific test software to the evaluation laboratory to enable rigorous side channel attack analysis to be performed.

Keys resident in the device or its components means plain-text secret or private keys.

TA7.3 The tester shall develop attack scenarios to determine any PIN-security-related cryptographic key resident in the device either by penetration or by monitoring emanations from the device. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. The calculation shall be based on the scheme depicted in Appendix B. If an attack scenario can be developed that yields an attack potential 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.
Modified p. 17 → 23
TA7.1 The tester shall examine the vendor‘s response to Section A7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS POI Security Requirements for consistency relevant to A7.
TA5.1 The tester shall examine the vendor’s response to Section A5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS POI Security Requirements for consistency relevant to A5. The vendor responses should clearly indicate how the device is protected from monitoring during PIN entry. The tester shall summarize the responses.
Modified p. 17 → 25
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 B11, they do not need to be considered.
Keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered.
Modified p. 17 → 25
TA7.2 The tester shall examine any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
TA6.2 The tester shall examine and cite any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
Removed p. 18
A8 should be selected when the prompts are fixed and cannot be updated; for example, when they are stored in ROM. B16.1 should be complied with for devices that allow prompts to be changed as part of firmware updates. B16.2 is appropriate for attended or unattended devices where the original equipment manufacturer has shipped the device with mechanisms for controlling the POI display and its use in place for the acquirer to control the display, and E3.4 is appropriate for unattended devices that do not meet any of the aforementioned.

TA8.3 The tester shall develop attack scenarios for the unauthorized alteration of prompts for non-PIN data entry into the PIN entry keypad such that PINs are compromised, i.e., by prompting for the PIN entry when the output is not encrypted. If an attack scenario can be developed that requires an attack potential of less than 18 per device for identification and …
Modified p. 18 → 28
TA8.1 The tester shall examine the assertions provided by the vendor in response to Section A8 of the PCI PTS POI Evaluation Vendor Questionnaire relating to unauthorized alterations of prompts.
TA7.1 The tester shall examine the assertions provided by the vendor in response to Section A7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS POI Security Requirements for consistency relating to unauthorized alterations of prompts. The vendor responses should clearly indicate how display prompts are protected. The tester shall summarize the responses.
Modified p. 18 → 28
TA8.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information on how prompts are generated and administered to determine whether it is possible to perform unauthorized alterations of prompts.
TA7.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information on how prompts are generated and administered to determine whether it is possible to perform unauthorized alterations of prompts.
Modified p. 18 → 29
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
The tester may perform any test needed to validate the attack scenario.
Removed p. 19
TA9.3 The tester will verify the physical properties of the privacy screen. The privacy screen shall provide protection as described in Appendix A of this document. Alternatively, the vendor may use less restrictive privacy shield criteria provided that the vendor supplies rules and guidance as to how the visual observation is to be deterred by the environment in which the device is installed. These rules shall be binding for the organization placing the device into the environment, e.g., the acquirer or merchant. If the vendor gives rules for an external physical privacy shield, then the vendor shall provide a demo/sample with the appropriate dimensions. The tester shall examine the information to verify the assertions of the vendor. The tester shall consider the examples included in Appendix A, Section A.2, of this document when evaluating the vendor's visual observation deterrence rules. The user (acquirer or merchant) instructions provided by the vendor …
Modified p. 19 → 30
TA9.1 The tester shall examine the vendor‘s response to Section A9 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A9 of the PCI PTS POI Security Requirements for consistency relevant to A9.
TA8.1 The tester shall examine the vendor’s response to Section A8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A8 of the PCI PTS POI Security Requirements for consistency relevant to A8. The vendor responses should clearly indicate how visual observation deterrents are provided. The tester shall summarize the responses.
Modified p. 19 → 30
TA9.2 The tester shall examine the means to deter the visual observation of PIN values provided by the device, and/or as described in the device documentation, to verify the assertions of the vendor.
TA8.2 The tester shall examine the means to deter the visual observation of PIN values provided by the device, and/or as described in the device documentation, to verify the assertions of the vendor. If the device provides physical observation deterrents, the tester shall show one or more images of these to support any conclusions.
Modified p. 19 → 31
TA9.4 If the means to deter visual observation are not an integral part of the PIN entry device, the vendor shall specify by appropriate means (e.g., drawings and description) how the visual observation is deterred by the structure or piece of equipment housing the device. These specifications shall be binding for the vendor. The tester shall examine this specification to deter the visual observation of PIN values provided by the device to verify the assertions of the vendor.
TA8.11 If the means to deter visual observation are not an integral part of the PIN entry device, the vendor shall specify by appropriate means (for example, drawings and description) how the visual observation is deterred by the structure or piece of equipment housing the device. These specifications shall be binding for the vendor and specified in the vendor security policy described in B20. The tester shall examine this specification to deter the visual observation of PIN values provided by …
Removed p. 20
Access to the inside of the device for routine maintenance (e.g., replenishing paper) shall not allow access to clear-text account data, e.g., by making cabling which transmits the data physically inaccessible to routine maintenance personnel or encrypting the sensitive card data transmitted internally within the device between components.

TA10.3 The tester shall visually inspect the device's magnetic-stripe reader and/or the device in general to verify the assertions provided by the vendor in response to Section A10 of the PCI PTS POI Evaluation Vendor Questionnaire. This will include disassembly of the test device when necessary.

TA10.4 The tester shall perform tests to verify that the protections of the device are such that the hardware and software of the device cannot be tampered without requiring an attack potential of at least 16 for identification and initial exploitation or at least 8 for exploitation. The cost calculation shall be based on the scheme depicted in …
Modified p. 20 → 32
TA10.1 The tester shall examine the vendor‘s response to Section A10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A10 of the PCI PTS POI Security Requirements for consistency relevant to A10.
TA9.1 The tester shall examine the vendor’s response to Section A9 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A9 of the PCI PTS POI Security Requirements for consistency relevant to A9. The vendor responses should clearly indicate how the magnetic-stripe reader is protected. The tester shall summarize the responses.
Modified p. 20 → 32
TA10.2 The tester shall examine additional relevant documentation, such as functional documentation, user guidance, test documentation and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
TA9.2 The tester shall examine and cite any additional relevant documentation, such as functional documentation, user guidance, test documentation and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
Modified p. 20 → 33
If an attack scenario can be developed that yields an attack potential of less than 16 per device for identification and initial exploitation or less than 8 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified.
If an attack scenario can be developed that yields an attack potential of less than 16 per device for identification and initial exploitation or less than 8 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document. Calculations shall include evidence justifying particular rating levels as being appropriate.
Removed p. 21
TA11.5 If the device allows for temporary removal and re-installation, the tester shall verify  The authorization for removal implements the principles of dual control.  Sensitive information required for the authorization (e.g., passwords) is initialized or used in a way that prevents replay at the same or a different device.  When removed/substituted without authorization the device will not further process PINs.  An authorized installation must provide traceability and accountability.
Modified p. 21 → 34
The objective of this section is to assess the device’s ability to protect the component against removal from its frame or the cabinet. This protections aims against component device overlays or chained ICC readers; it also aims at complicating attacks against the component whereas it is taken away by attackers in order to perform subsequent attack steps under laboratory conditions.
The objective of this requirement is to assess the device’s ability to protect the component against removal from its frame or the cabinet. This protections aims against component device overlays or chained ICC readers; it also aims at complicating attacks against the component wherein it is taken away by attackers in order to perform subsequent attack steps under controlled conditions. This requirement applies to components that are used for PIN entry or handle the PIN, such as an ICCR.
Modified p. 21 → 34
If all components are integrated into a single tamper envelope, then removal detection at the component level is not necessary and removal detection will be addressed in the Integration section for the final form factor, e.g., AFD.
If all components are integrated into a single tamper envelope, then removal detection at the component level is not necessary and removal detection will be addressed in the Integration section for the final form factor, for example, AFD.
Modified p. 21 → 34
TA11.2 The tester shall visually inspect the device to verify the assertions provided by the vendor in response to Section A11 PCI PTS POI Evaluation Vendor Questionnaire.
TA10.2 The tester shall visually inspect the device to verify the assertions provided by the vendor in response to Section A10 PCI PTS POI Evaluation Vendor Questionnaire.
Modified p. 21 → 34
TA11.3 The tester shall examine additional relevant documentation, such as schematics and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
TA10.3 The tester shall examine additional relevant documentation, such as schematics and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
Modified p. 21 → 36
TA11.1 The tester shall examine the vendor‘s response to Section A11 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A11 of the PCI PTS POI Security Requirements for consistency relevant to A11.
TA11.1 The tester shall examine the vendor’s response to Section A11 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A11 of the PCI PTS POI Security Requirements for consistency relevant to A11. The vendor responses should clearly indicate why audible tones during PIN entry cannot be used to distinguish PIN digits. The tester shall summarize the responses.
Removed p. 23
TB1.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses, including evidence of testing that confirms the relevant component fails securely in the event of self-test failure.
Modified p. 23 → 37
Firmware is considered to be any code within the device that provides security protections needed to comply with these requirements. In certain instances, the test houses may request copies of source code for review of specific functions.
Firmware is considered to be any code within the device that provides security protections needed to comply with these requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.
Modified p. 23 → 37
Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hashed must either be cryptogrphically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption).
Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must be either cryptographically protected using a key (for example, HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption).
Modified p. 23 → 37
LRC, CRC, and other non-cryptographic methods and weak cryptographic methods (e.g., SHA-1, MD5) are not allowed as the primary mechanism for either authentication or integrity checking.
LRC, CRC, and other non-cryptographic methods and weak cryptographic methods (for example, SHA-1, MD5) are not allowed as the primary mechanism for either authentication or integrity checking.
Modified p. 23 → 37
The device controller is only in scope if it impacts one or more of the security requirements, e.g., display prompt control.
The device controller is only in scope if it impacts one or more of the security requirements, for example, display prompt control.
Modified p. 23 → 37
Failing in a secure manner involves at least disabling any functionality of the device related to PIN handling and processing, including PIN entry and PIN encryption. More specifically, no sensitive data breach can occur as a consequence of device failure.
Failing in a secure manner involves at least disabling any functionality of the device related to PIN handling and processing, including PIN entry and PIN encryption. More specifically, no sensitive data breach can occur as a consequence of device failure. For OP and SRED applications, failing in a secure manner involves disabling of all CHD processing functionality.
Modified p. 23 → 37
TB1.1 The tester shall examine the vendor‘s response to Section B1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS POI Security Requirements to verify that the device performs a self-test upon start-up and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised state; and that in …
TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS POI Security Requirements for consistency to verify that the device performs a self-test upon start-up and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised state; and …
Modified p. 25 → 39
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of the device’s relevant components.
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of all of the device’s relevant components.
Modified p. 25 → 39
Vendors should provide software design rules and specifications to support answers.
Vendors should provide software-design rules and specifications to support answers.
Modified p. 25 → 39
The device controller is not in scope for this requirement for unattended devices TB2.1 The tester shall examine the vendor‘s response to Section B2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS POI Security Requirements to verify that the relevant component‘s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters …
TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS POI Security Requirements for consistency to verify that the relevant component’s functionality shall not be influenced by logical anomalies such as (but not restricted to): unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying invalid parameters or data that could result in the relevant component’s outputting the …
Modified p. 25 → 39
TB2.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the relevant component‘s logical structure, the interface specification, the software design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB2.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant component’s logical structure, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
Modified p. 25 → 39
TB2.3 The tester shall analyze the vendor‘s measures that ensure that the relevant component‘s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
TB2.3 The tester shall analyze the vendor’s measures that ensure the relevant component’s functionality is not influenced by logical anomalies such as unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified p. 25 → 40
TB2.4 The tester may perform tests needed to validate the device‘s property. The evaluator should use his or her own judgment in determining appropriate tests. Test support shall be provided by the vendor as needed to access and use the interfaces under test.
TB2.14 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified p. 26 → 41
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the firmware documentation and certification process, for consistency.
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS POI Security Requirements manual for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
Modified p. 26 → 41
TB3.2 The tester shall examine the support documentation submitted by the device vendor. The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.
TB3.2 The tester shall examine the support documentation submitted by the device vendor. The documents should be representative of a Configuration Control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable configuration control procedure.
Modified p. 26 → 41
TB3.4 The tester will verify that the device displays or otherwise makes available the revision number.
TB3.4 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware revision number.
Modified p. 27 → 44
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.
Modified p. 27 → 44
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the authentication procedures for firmware updates, for consistency.
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI PTS POI Security Requirements manual for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
Modified p. 27 → 44
TB4.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.
TB4.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.
Modified p. 27 → 44
TB4.7 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:
TB4.7 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 D.
Modified p. 28 → 50
A PIN-handling component of the device (e.g., the PIN entry device) never outputs information to another component (e.g., a display or a device controller), allowing the differentiation of the PIN digits entered.
A PIN-handling component of the device (for example, the PIN entry device) never outputs information to another component (for example, a display or a device controller), allowing the differentiation of the PIN digits entered.
Modified p. 28 → 50
TB5.1 The tester shall examine the vendor‘s response to Section B5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI PTS POI Security Requirements for consistency relevant to B5.
TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI PTS POI Security Requirements for consistency relevant to B5. The tester shall summarize the responses.
Modified p. 28 → 50
TB5.2 The tester shall examine any relevant documentation, such as an API user guide, submitted by the vendor to verify that supports the vendor responses.
TB5.2 The tester shall examine and cite any relevant documentation, such as an API user guide, submitted by the vendor to verify that supports the vendor responses.
Modified p. 28 → 50
TB5.3 The tester shall perform a test in which a PIN is entered to verify that the device does not output any digits of the PIN value. The tester shall note and report any characters, signals, or tones that are outputted. The device must display the same non-significant character for all PIN-entry uses.
TB5.3 The tester shall perform a test in which a PIN is entered to verify that the device does not output any digits of the PIN value. The tester shall note and report any characters, signals, or tones that are outputted. The device must display the same non-significant character for all PIN-entry uses. The tester shall provide an image capturing this.
Modified p. 28 → 50
TB5.4 If the device does not directly control the display, it must supply a suitable signal to indicate that a numeric key has been pressed and the value is stored inside the device. The tester shall examine the response to Section B5 of the PCI PTS POI Evaluation Vendor Questionnaire to determine the kind of signaling and to verify that the signal information is not related to the digit entered.
TB5.4 If the device does not directly control the display, it must supply a suitable signal to indicate that a numeric key has been pressed and the value is stored inside the device. The tester shall examine the response to Section B5 of the PCI PTS POI Evaluation Vendor Questionnaire to determine the kind of signaling and to verify and describe how the signal information is not related to the digit entered.
Removed p. 29
TB6.3 The tester will verify that the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included. Passwords, plain-text cryptographic keys, or key components outside of the crypto- processor, and PIN values are considered sensitive data.

TB6.4 The tester will verify that all data is automatically cleared when either the transaction is completed or the device has timed out waiting for the response from the cardholder or merchant. The tester will determine the appropriate test actions to be taken. For instance, by performing a partial simulated transaction to verify the behavior at time-out, or in general by entering the states that have been defined by the vendor under TB6.1.
Modified p. 29 → 51
Plain-text PINs must not exist for more than one minute maximum from the completion of the cardholder’s PIN entry. In all cases, erasure of the plain-text PIN must occur before the tamper-detection mechanisms can be disabled using attack methods described in A1.1.
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 A1.
Modified p. 29 → 51
The device may support the encipherment of the PIN multiple times as part of a transaction series; however, the PIN shall only be enciphered using the same PIN- encipherment key and transaction data, and not different keys or transaction data.
The device may support the encipherment of the PIN multiple times as part of a transaction series; however, the PIN shall only be enciphered using the same PIN-encipherment key and transaction data, and not different keys or transaction data.
Modified p. 29 → 51
TB6.1 The tester shall examine the vendor‘s response to Section B6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI PTS POI Security Requirements to verify:
TB6.1 The tester shall examine the vendor’s response to Section B6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI PTS POI Security Requirements for consistency to verify:
Modified p. 29 → 51
 That sensitive information shall not be present any longer or used more often than strictly necessary;  The immediate encryption of online PIN data; and  That the device automatically clears its internal buffers when either the transaction is completed or the device has timed out waiting for the response from the cardholder or merchant. The vendor must specify the states ―completion of transaction‖ and ―timeout‖ and define the appropriate actions.
 That sensitive information shall not be present any longer or used more often than strictly necessary;  The immediate encryption of online PIN data; and  That the device automatically clears its internal buffers when either the transaction is completed or the device has timed out waiting for the response from the cardholder or merchant. The vendor must specify the states “completion of transaction” and “timeout” and define the appropriate actions.
Modified p. 29 → 51
TB6.2 The tester shall examine any relevant documentation, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB6.2 The tester shall examine and cite any relevant documentation, including vendor test results for inspections of internal buffers, user guides, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Removed p. 30
TB7.4 The tester shall verify from vendor documentation and from functional testing that sensitive services require authentication.

TB7.5 The tester shall verify from vendor documentation and from functional testing that entering and exiting sensitive services does not reveal or otherwise affect sensitive information.

TB7.6 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified p. 30 → 53
A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc.
A sensitive service (state) allows the execution of functions that are not available during normal use• for example, load a master key, alter device configuration, etc.
Modified p. 30 → 53
TB7.1 The tester shall examine the vendor‘s response to Section B7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI PTS POI Security Requirements for consistency relevant to B7.
TB7.1 The tester shall examine the vendor’s response to Section B7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI PTS POI Security Requirements for consistency relevant to B7. The vendor responses should clearly indicate how sensitive services are protected. The tester shall summarize the responses.
Modified p. 30 → 53
TB7.2 The tester shall examine any relevant documentation (such as an API user guide) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services.
TB7.2 The tester shall examine and cite any relevant documentation (such as an API user guide) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services.
Modified p. 30 → 53
TB7.3 The tester shall verify from vendor documentation that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.
TB7.3 The tester shall verify from vendor documentation •and summarize

•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified p. 31 → 53
The testing shall include:
The testing shall include (but is not restricted to):
Modified p. 31 → 53
TB7.8 If mode transitions require input by a separate interface device, such as a key loader, the tester will document the mechanism(s) and methodology used.
TB7.5 If mode transitions require input by a separate interface device, such as a key loader, the tester shall document the mechanism(s) and methodology used.
Removed p. 32
This applies to each and any transition to the use of sensitive services.

TB8.5 The tester shall verify that a time limit is imposed such that after one minute of inactivity while accessing sensitive services, the device returns to its normal state. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded.

TB8.6 The tester shall verify that a time limit is imposed such that fifteen (15) minutes after accessing sensitive services, the device returns to its normal mode. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded. To prevent the device from reaching a limit of inactivity, sensitive functions will be used throughout the fifteen minutes.
Modified p. 32 → 56
TB8.1 The tester shall examine the vendor‘s response to Section B8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI PTS POI Security Requirements for consistency relevant to B8.
TB8.1 The tester shall examine the vendor’s response to Section B8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI PTS POI Security Requirements for consistency relevant to B8. The vendor responses should clearly indicate how limits are implemented appropriately. The tester shall summarize the responses.
Modified p. 32 → 56
TB8.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses.
TB8.2 The tester shall examine and cite any relevant documentation, such as user guides or the software specification, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 32 → 56
TB8.4 The tester shall verify the limits placed on the number of actions by causing the device to access sensitive services and attempting to exceed the limit. Once the limit is exceeded the tester will verify that the device has returned to its normal mode.
TB8.4 The tester shall verify the limits placed on the number of actions by causing the device to access sensitive services and attempting to exceed the limit. Once the limit is exceeded the tester shall verify that the device has returned to its normal mode.
Removed p. 33
TB9.3 The tester shall verify test information provided by the vendor to assess whether the random number generation is properly distributed to support cryptographic use. The tester shall use a suitable test method (for example, those listed in NIST PUB 800- 22). See Appendix C.

TB9.5 The tester shall document in the report the overall design of the random number generator, its randomness sources, and its usage on the device.
Modified p. 33 → 58
Source code may be required to validate this requirement.
Source code will be required to validate this requirement.
Modified p. 33 → 58
TB9.1 The tester shall examine the vendor‘s response to Section B9 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI PTS POI Security Requirements for consistency relevant to B9.
TB9.1 The tester shall examine the vendor’s response to Section B9 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI PTS POI Security Requirements for consistency relevant to B9. The vendor responses should clearly indicate why random number generation is robust. The tester shall summarize the responses.
Modified p. 33 → 58
TB9.4 The tester shall verify test information provided by the vendor to assess whether the random numbers are sufficiently unpredictable. More specifically, the tester shall ensure that initializing and/or seeding of the RNG cannot be abused to intentionally reproduce a given random value or sequence.
The tester shall ensure that initializing and/or seeding of the RNG cannot be abused to intentionally reproduce a given random value or sequence.
Removed p. 34
TB10.3 The tester shall perform functional testing to verify the device characteristics regarding B10.
Modified p. 34 → 60
TB10.1 The tester shall examine the response to Section B10 of the PCI PTS POI Evaluation Vendor Questionnaire relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PIN determination.
TB10.1 The tester shall examine the response to Section B10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS POI Security Requirements manual for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PIN determination. The tester shall summarize the responses.
Modified p. 34 → 60
TB10.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to characteristics that prevent or significantly deter exhaustive PIN determination to determine whether it supports the assertions made by the vendor.
TB10.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to characteristics that prevent or significantly deter exhaustive PIN determination to determine whether it supports the assertions made by the vendor.
Modified p. 35 → 62
TDES key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret-sharing scheme, e.g., Shamir. Private key components shall be combined using a recognized secret-sharing scheme.
TDES key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret-sharing scheme, for example, Shamir. Private key components shall be combined using a recognized secret-sharing scheme.
Modified p. 35 → 62
For all TDEA modes of operation, the three cryptographic keys (K1, K2, K3) define a TDEA key bundle (see X9.24). The bundle and the individual keys must:  Be secret;  Be generated randomly or pseudo-randomly;  Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;  Be used in the appropriate order as specified by the particular mode;  …
For all TDEA modes of operation, the three cryptographic keys (K1, K2, K3) define a TDEA key bundle (see X9.24). The bundle and the individual keys must:
Modified p. 35 → 62
TR-31 support or equivalent must use a key derivation methodology. The device may optionally support, in addition, the key calculation methodology.
TR-31 support or equivalent must use a key-derivation methodology. The device may optionally support, in addition, the key calculation methodology.
Modified p. 35 → 62
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods. Any binding or unbinding of key- usage information from the key must take place within the secure cryptographic boundary of the device.
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods. Any binding or unbinding of key-usage information from the key must take place within the secure cryptographic boundary of the device.
Removed p. 36
TB11.5 The tester shall determine from vendor documentation that the device provides support for a configuration option using TR-31 or an equivalent methodology for symmetric key distribution, and optionally, key storage. The tester shall determine that the TR-31 or equivalent configuration uses a key derivation methodology. The device may optionally support, in addition, the key calculation methodology.
Modified p. 36 → 63
TB11.2 The tester shall examine any relevant documentation such as a user guide or the API programmer‘s guide, submitted by the vendor to verify that it supports vendor responses.
TB11.2 The tester shall examine and cite any relevant documentation such as a user guide or the API programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified p. 36 → 63
TB11.4 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the implemented key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
TB11.4 The tester shall examine any additional documentation (for example, API reference, design documentation, key-management specification) that describes the implemented key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
Modified p. 36 → 63
TB11.6 The tester shall verify that the loading of private and secret keys uses one or more of the following methods. (Note: EPPs intended for use in an unattended environment shall only support methods a, c, and d.)
TB11.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods. (Note: EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d.)
Modified p. 36 → 63
a) When entering plain-text secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally …
a) When entering plaintext secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally …
Modified p. 36 → 63
b) For injecting plain-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 PINs/passwords before injecting the plain-text key into the device. (Note: This may be the entire key•if components, each component requires a separate password.) Passwords/PINs are at least five characters. These passwords are entered directly through the keypad of the applicable device or are conveyed encrypted …
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 PINs/passwords before injecting the plaintext key into the device. (Note: This may be the entire key•if components, each component requires a separate password.) Passwords/PINs are at least seven characters or an equivalent strength. These passwords are entered directly through the keypad of the applicable device …
Modified p. 36 → 63
Injection of plain-text secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (e.g., multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Injection of plaintext secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Removed p. 37
The following are the minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange or establishment:

Minimum key size in number of bits: 112 2048 224 2048/224 128 DES 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.

For Diffie-Hellman implementations:

 Entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity generates …
Modified p. 37 → 63
c) For encrypted values injected into the device, either from a key loader or from a network host, or via loading through the keypad, the ability of the device to successfully decrypt the value and use it is sufficient. In this case, the loading of the key-encipherment key would have been done under dual control, e.g., in examples a) and b) above.
c) For encrypted values injected into the device, either from a key loader or from a network host, or via loading through the keypad, the ability of the device to successfully decrypt the value and use it is sufficient. In this case, the loading of the key-encipherment key would have been done under dual control, for example, in examples a) and b) above.
Modified p. 37 → 64
d) Remote key loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements.
d) Remote key-loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements.
Modified p. 37 → 64
TB11.7 If a public-key technique for the distribution of symmetric secret keys is used, it
If a public-key technique for the distribution of symmetric secret keys is used, it must:
Modified p. 37 → 64
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 2048-bits minimum for RSA, see also DTR B16.2).
a) Use public and private-key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA, see also DTR B16.2).
Modified p. 37 → 64
c) Provide for mutual device authentication for both the host and the device, including assurance to the host that the device actually has (or actually can) compute the session key and that no other entity other than the device specifically identified can possibly compute the session key.
c) Provide for mutual device authentication for both the host and the device, including assurance to the host that the device actually has computed (or actually can compute) the session key and that no entity other than the device specifically identified can possibly compute the session key.
Removed p. 39
TB11.10 The tester shall determine from vendor documentation how (e.g., active or passive erasure) each key is destroyed for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.

TB12.3 The tester shall perform a transaction with a known encryption key. The tester shall use this key to create an encrypted PIN block with a test system, using the Primary Account Number, and PIN with the format (the format must be either ISO format 0, 1 or 3, specified by the vendor. The corresponding encrypted PIN block shall be generated by the device with a simulated transaction. If both encrypted PIN blocks are identical, the device is using the TDES algorithm and the specified format for encryption.
Modified p. 40 → 68
TB12.1 The tester shall examine the response to Section B12 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the TDES PIN-encryption implementation in the device, for consistency and compliance with ISO 9564.
TB12.1 The tester shall examine the response to Section B12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS POI Security Requirements manual for consistency relating to the TDES or AES PIN-encryption implementation in the device and compliance with ISO 9564. The tester shall summarize the responses.
Modified p. 40 → 68
TB12.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to the PIN- encryption technique implemented in the device.
TB12.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to the PIN-encryption technique implemented in the device.
Modified p. 40 → 68
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 plain-text or enciphered using an encipherment key of the IC.
a) The PIN that is submitted by the ICC reader to the IC shall be contained in a PIN block conforming to ISO Format 2 PIN block. This applies whether the PIN is submitted in plaintext or enciphered using an encipherment key of the IC.
Modified p. 40 → 68
b) Where the ICC reader is not integrated into the PIN entry device, and PINs are enciphered only for transmission between the PIN entry device and the IC reader, the device shall use one of the PIN block formats specified in ISO 9564- 1. Where ISO Format 2 PIN blocks are used, a unique key per transaction method in accordance with ISO 11568 shall be used. Format 2 shall be used only in connection with either offline PIN verification or …
b) Where the ICC reader is not integrated into the PIN entry device, and PINs are enciphered only for transmission between the PIN entry device and the IC reader, the device shall use one of the PIN block formats specified in ISO 9564-1. Where ISO Format 2 PIN blocks are used, a unique key per transaction method in accordance with ISO 11568 shall be used. Format 2 shall be used only in connection with either offline PIN verification or PIN-change …
Removed p. 41
TB13.4 The tester shall verify by testing that the device enforces that data keys, key- encipherment keys, and PIN-encryption keys have different values, e.g., by attempting to load keys of different types with effectively the same value.
Modified p. 41 → 70
The device may support the encipherment of the PIN multiple times as part of a transaction series; however, the PIN shall only be enciphered using the same PIN- encipherment key and transaction data, and not different keys or transaction data.
The device may support the encipherment of the PIN multiple times as part of a transaction series; however, the PIN shall only be enciphered using the same PIN-encipherment key and transaction data, and not different keys or transaction data.
Modified p. 41 → 70
A secret key used to encrypt a PIN must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose. However, variants of the same key may be used for different purposes. Any variant of the PEK or a key used to protect the PEK must be protected in the same manner, i.e., under the principles of dual control and split knowledge.
A secret key used to encrypt a PIN must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose. However, variants of the same key may be used for different purposes. Any variant of the PEK or a key used to protect the PEK must be protected in the same manner, i.e., under the principles of dual control and split knowledge. Any key calculated as …
Modified p. 41 → 70
Key variants are only used in devices that possess the original key (e.g., the PED and the host it communicates with). Key variants are not used at different levels of the key hierarchy, e.g., a variant of a key-encipherment key used for key exchange cannot be used as a working key or as a master file key for local storage.
Key variants are only used in devices that possess the original key (for example, the POI device and the host it communicates with). Key variants are not used at different levels of the key hierarchy, for example, a variant of a key-encipherment key used for key exchange cannot be used as a working key or as a master file key for local storage.
Modified p. 41 → 70
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS POI Evaluation Vendor Questionnaire relating to encryption and decryption of arbitrary data, for consistency.
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS POI Security Requirements manual for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses.
Modified p. 41 → 70
TB13.2 The tester shall examine any additional documentation such as the API programmer‘s guide, submitted by the vendor to verify that it supports vendor responses.
TB13.2 The tester shall examine and cite any additional documentation such as the API programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified p. 41 → 71
TB13.3 The tester shall verify the following:
The tester shall verify the following:
Modified p. 42 → 72
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the output of clear-text keys and protection of PINs for consistency. The clear-text PIN must never exist in an unprotected environment.
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B14 of the PCI PTS POI Security Requirements manual for consistency relating to the output of clear-text keys and protection of PINs. The clear-text PIN must never exist in an unprotected environment. The tester shall summarize the responses.
Modified p. 42 → 72
TB14.2 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
TB14.2 The tester shall examine and cite the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
Modified p. 42 → 72
TB14.3 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the transfer of a key from a high- security component to a lower-security component, for consistency.
TB14.3 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the transfer of a key from a high-security component to a lower- security component, for consistency.
Modified p. 42 → 72
TB14.4 The tester shall examine any additional documentation (i.e., API programmer‘s guide, specifications, block diagrams, etc.) containing information that relates to any of the aforementioned to determine whether it supports the assertions made by the vendor.
TB14.4 The tester shall examine any additional documentation (i.e., API programmer’s guide, specifications, block diagrams, etc.) containing information that relates to any of the aforementioned to determine whether it supports the assertions made by the vendor.
Removed p. 43
TB15.2 The tester shall examine any relevant documentation to verify that the prompt for and entry of the PIN are distinctly separate from all other operations.
Modified p. 43 → 73
TB15.1 The tester shall examine the response to Section B15 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B15 of the PCI PTS POI Security Requirements for consistency relevant to B15.
TB15.1 The tester shall examine the response to Section B15 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B15 of the PCI PTS POI Security Requirements for consistency relevant to B15. The tester shall summarize the responses.
Modified p. 43 → 73
TB15.3 The tester shall perform a simulated transaction to verify that the prompt for PIN entry is distinctly separate from all other operations such as the display of the transaction amount. When prompting for PIN entry, the device must not accept any other data inputs. Control inputs such as ―Yes,‖ ―OK,‖ ―Cancel,‖ or ―No‖ are acceptable.
TB15.4 The tester shall perform a simulated transaction to verify that the prompt for PIN entry is distinctly separate from all other operations, such as the display of the transaction amount. When prompting for PIN entry, the device must not accept any other data inputs. Control inputs such as “Yes,” “OK,” “Cancel,” or “No” are acceptable.
Removed p. 44
A8 should be selected when the prompts are fixed and cannot be updated; for example, when they are stored in ROM. B16.1 should be complied with for devices that allow prompts to be changed as part of firmware updates. B16.2 is appropriate for attended or unattended devices where the original equipment manufacturer has shipped the device with mechanisms for controlling the POI display and its use in place for the acquirer to control the display; and E3.4 is appropriate for unattended devices that do not meet any of the aforementioned.

Audio prompts must be considered if applicable TB16.1.1 The tester shall examine the response to Section B16.1 of the PCI PTS POI Evaluation Vendor Questionnaire, relating to user prompts, and alteration of prompts for consistency. The tester shall verify that mechanisms exist to ensure the authenticity and proper use of the prompts and modification of the prompts or improper use of …
Modified p. 44 → 74
Cryptographic keys that are never used to encrypt or decrypt data; or are not used for authentication, do not need to be considered secret data, and therefore do not need to be erased.
Cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication do not need to be considered secret data and therefore do not need to be erased.
Modified p. 44 → 75
TB16.1.2 The tester shall examine all possible prompts to determine whether any can be used in conjunction with numeric entry in the clear.
TB16.2 The tester shall examine all possible prompts to determine whether any can be used in conjunction with numeric entry in the clear.
Modified p. 44 → 75
TB16.1.3 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, and 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.
TB16.3 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. 44 → 75
TB16.1.4 The tester shall examine the vendor-supplied documentation to verify that the controls to ensure the authenticity and the proper use of the prompts provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are:
TB16.4 The tester shall examine the vendor-supplied documentation to verify that the controls to ensure the authenticity and the proper use of the prompts provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Removed p. 45
TB16.1.5 The tester shall develop attack scenarios to circumvent the control of the display by the device. If an attack scenario can be developed that requires an attack potential of less than 18 per device for identification and initial exploitation or less than 9 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified.

A8 should be selected when the prompts are fixed and cannot be updated; for example, when they are stored in ROM. B16.1 should be complied with for devices that allow prompts to be changed as part of firmware updates. B16.2 is appropriate for attended or unattended devices where the original equipment manufacturer has shipped the device with mechanisms for controlling the POI display and its use in place for the acquirer to control the display, and E3.4 is appropriate for unattended devices that do not meet any of the aforementioned.

Non-PIN data …
Modified p. 46 → 74
The controls shall be implemented and enforced by the device. As an exception, an unattended device vendor may decide to include into the to be approved device scope not only the PIN entry device, but also the device controller and the controls implemented to ensure a secure configuration, the device‘s display management, properties of the device‘s cabinet or procedural controls for the device.
The controls shall be implemented and enforced by the device. As an exception, a vendor of an unattended device may decide to include into the to be approved-device scope not only the PIN entry device, but also the device controller and the controls implemented to ensure a secure configuration, the device’s display management, properties of the device’s cabinet, or procedural controls for the device.
Modified p. 46 → 76
TB16.2.4 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.
TB16.13 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.
Removed p. 47
TB16.2.6 The tester shall examine the response to Section B16.2 of the PCI PTS POI Evaluation Vendor Questionnaire and other vendor-supplied documentation (i.e., user guide, the installation and setup guide and the interface specification) 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:

Examples of acceptable hashing algorithms include SHA-256 and higher. MD5 and SHA-1 are not allowed for use.

TB16.2.8 The tester shall examine the vendor-supplied documentation to verify that key- management techniques and other control mechanisms are defined and include appropriate application of the principles of dual control and split knowledge.

TB16.2.9 The tester shall examine any additional documentation (i.e., specifications, open standards, public documentation etc.) containing information on the methods for key-management techniques and other control mechanisms and the appropriate application of the principles of dual control and split knowledge.
Modified p. 47 → 75
The vendor may alternately provide user documentation detailing the management of cryptographic keys following these principles and implementing the use of a secure cryptographic device for management of these keys. The process exists upstream of the device, but the device must still provide enforcement, e.g., validates the MAC or digital signature.
The vendor may alternately provide user documentation detailing the management of cryptographic keys following these principles and implementing the use of a secure cryptographic device for management of these keys. The process exists upstream of the device, but the device must still provide enforcement•for example, validate the MAC or digital signature.
Modified p. 47 → 76
TB16.2.7 The tester shall examine the response to Section B16.2 of the PCI PTS POI Evaluation Vendor Questionnaire to verify that key-management techniques and other control mechanisms are defined and include appropriate application of the principles of dual control and split knowledge. These control mechanisms must exist and must be suitable even when they are not provided solely by the device.
The tester shall examine the vendor-supplied documentation to verify that key-management techniques and other control mechanisms are defined and include appropriate application of the principles of dual control and split knowledge.
Modified p. 48 → 77
Applications are considered to be separated by access rights. OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined with B1.
OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined within B1.
Modified p. 48 → 77
TB17.1 The tester shall examine the vendor‘s response to Section B17 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B17 of the PCI PTS POI Security Requirements to verify that if the device supports multiple applications, it enforces the separation between applications with security impact from those without security impacts. Furthermore, the tester shall examine which part of the firmware is considered OS, and which part is considered as application with security impact.
TB17.1 The tester shall examine the vendor’s response to Section B17 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B17 of the PCI PTS POI Security Requirements to verify that if the device supports multiple applications, it enforces the separation between applications with security impact from those without security impacts. Furthermore, the tester shall examine which part of the firmware is considered OS, and which part is considered as application with security impact. The tester …
Modified p. 48 → 77
TB17.2 The tester shall examine any relevant documentation, such as the user guide, specification of the device‘s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB17.2 The tester shall examine and cite any relevant documentation, such as user guides, specification of the device’s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 48 → 78
TB17.3 The tester shall analyze the vendor‘s measures that ensure that the device enforces the separation between applications with security impact from those without security impacts. The tester will verify that it is not possible that one application interferes with or tampers another application or the OS of the device

•especially to access, use, or modify data objects belonging to another application

•even if they are distributed over separate components of the device.
TB17.4 The tester shall analyze the vendor’s measures that ensure that the device enforces the separation between applications with security impact from those without security impacts. The tester shall verify that it is not possible that one application interferes with or tampers another application or the OS of the device

•especially to access, use, or modify data objects belonging to another application

•even if they are distributed over separate components of the device.
Modified p. 48 → 78
TB17.4 If the OS and / or any application with security impact are distributed over separate components of the device, the tester will verify that the communication in between separated parts is consistent with the separation mechanisms as described by the vendor. The vendor shall provide evidence concerning the communication in between the separated parts and how the communication protocols maintain the separation of applications with security impact from those without security impacts.
TB17.6 If the OS and/or any application with security impact are distributed over separate components of the device, the tester shall verify that the communication in between separated parts is consistent with the separation mechanisms as described by the vendor. The vendor shall provide evidence concerning the communication in between the separated parts and how the communication protocols maintain the separation of applications with security impact from those without security impacts.
Removed p. 49
TB18.3 The tester shall verify that all components and services indicated in the configuration list are necessary for the intended operation. For that purpose, the vendor shall provide a configuration list, which shows all OS components and other software with an explanation of the purpose and a rationale for its presence.
Modified p. 49 → 80
The intended operation is considered as the functionality relevant to B2, to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, are permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals.
The intended operation is considered as the functionality relevant to B2, to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals.
Modified p. 49 → 80
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to plain-text cryptographic keys and components, customer PINs, passwords used for entry into sensitive states, or other items of information or configuration which is required to meet the core logical and physical requirements.
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to plaintext cryptographic keys and components, customer PINs, passwords used for entry into sensitive states, or other items of information or configuration which is required to meet the core logical and physical requirements.
Modified p. 49 → 80
TB18.1 The tester shall examine the vendor‘s response to Section B18 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS POI Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation.
TB18.1 The tester shall examine the vendor’s response to Section B18 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS POI Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation. The tester shall summarize the responses.
Modified p. 49 → 80
TB18.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the device‘s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB18.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 49 → 80
TB18.4 The tester shall verify that the operating system is enforcing least privilege.
The tester shall verify that the operating system is enforcing least privilege.
Modified p. 49 → 80
TB18.5 The tester will examine the methods and tools provided by the vendor, which ensure, that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the O/S.
TB18.4 The tester shall examine the methods and tools provided by the vendor, which ensure that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the OS.
Removed p. 50
TB19.4 The tester shall verify that the integration documentation is properly maintained, e.g., in case of a device update. More specifically, the tester shall examine and document the vendor document release cycle, and assess how it integrates with the device design/manufacturing update process.
Modified p. 50 → 82
TB19.1 The tester shall examine the vendor‘s response to Section B19 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B19 of the PCI PTS POI Security Requirements for consistency relevant to B19.
TB19.1 The tester shall examine the vendor’s response to Section B19 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B19 of the PCI PTS POI Security Requirements for consistency relevant to B19. The tester shall summarize the responses.
Modified p. 50 → 82
TB19.2 The tester shall visually inspect the secure component as well as examine any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor for consistency between documentation and implementation.
a) Visually inspect the secure component as well as examine any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor for consistency between documentation and implementation.
Modified p. 50 → 82
TB19.3 The tester shall verify that procedures exist for the integration documentation to be shipped or otherwise made available to the customer.
b) Verify that procedures exist for the integration documentation to be shipped or otherwise made available to the customer.
Modified p. 51 → 86
The term ―externally selected‖ means selected by an interface function to the device component that performs the PIN encryption. Both human interfaces and command interfaces are considered, and both direct and indirect.
The term “externally selected” means selected by an interface function to the device component that performs the PIN encryption. Both human interfaces and command interfaces are considered, and both direct and indirect.
Modified p. 51 → 86
External selection also includes interference with or manipulation of the data by which the PIN-encrypting device component selects the key to be used.
External selection also includes interference with or manipulation of the data by which the PIN- encrypting device component selects the key to be used.
Modified p. 51 → 86
TC1.1 The tester shall examine the response to Section C1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to multiple keys and unauthorized key replacement and key misuse, for consistency.
TC1.1 The tester shall examine the response to Section C1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS POI Security Requirements manual for consistency relating relating to multiple keys and unauthorized key replacement and key misuse. The tester shall summarize the responses.
Modified p. 51 → 86
TC1.2 The tester shall examine any additional documentation such as a user‘s manual or the API programmer‘s guide submitted by the vendor to verify that it supports vendor responses.
TC1.2 The tester shall examine and cite any additional documentation such as a user’s manual or the API programmer’s guide submitted by the vendor to verify that it supports vendor responses.
Modified p. 52 → 87
The card reader may consist of areas of different protection levels, e.g., the areas of the ICC card interface itself, and the area holding retracted cards.
The card reader may consist of areas of different protection levels, for example, the areas of the IC card interface itself, and the area holding retracted cards.
Modified p. 52 → 87
Implementation guidance is provided to facilitate detection of shim devices by the entities (e.g., merchants) deploying these devices.
Implementation guidance is provided to facilitate detection of shim devices by the entities (for example, merchants) deploying these devices.
Modified p. 52 → 87
TD1.1 The tester shall examine the vendor‘s response to Section D1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D1 of the PCI PTS POI Security Requirements for consistency relevant to D1.
TD1.1 The tester shall examine the vendor’s response to Section D1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D1 of the PCI PTS POI Security Requirements for consistency relevant to D1. The tester shall summarize the responses.
Modified p. 52 → 87
TD1.2 The tester shall examine any relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TD1.2 The tester shall examine and cite any relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Removed p. 53
TD1.8 The tester shall develop attack scenarios to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader‘s hardware or software, in order to determine or modify any sensitive data. If an attack scenario can be developed that requires an attack potential of less than 20 per device for identification and initial exploitation or less than 10 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified.
Modified p. 53 → 88
TD1.6 The tester shall develop an attack scenario to enlarge the slot. The tester will use his or her experience to determine what type of testing is necessary to determine the attack feasibility.
TD1.6 The tester shall develop an attack scenario to enlarge the slot.
Modified p. 53 → 88
TD1.7 The tester shall perform a simulated transaction whilst inserting two cards into the slot. If it is possible to insert two cards and perform the transaction, then the device does not comply with this requirement.
TD1.7 The tester shall perform a simulated transaction whilst inserting two un-embossed cards into the slot. If it is possible to insert two cards and perform the transaction, then the device does not comply with this requirement.
Modified p. 53 → 89
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
The tester may perform any test needed to validate the attack scenario. The tester shall present evidence of the test methodologies followed and the validation results.
Modified p. 54 → 90
TD2.1 The tester shall examine the vendor‘s response to Section D2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D2 of the PCI PTS POI Security Requirements for consistency relevant to D2.
TD2.1 The tester shall examine the vendor’s response to Section D2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D2 of the PCI PTS POI Security Requirements for consistency relevant to D2. The tester shall summarize the responses.
Modified p. 54 → 90
TD2.2 The tester shall examine a test device to verify vendor assertions that the ICC reader‘s slot is in full view of the cardholder so that any untoward obstructions or suspicious objects at the opening are detectable. The construction of the device should be such that the entire slot opening is in full view of the cardholder prior to card insertion.
TD2.2 The tester shall examine a test device to verify vendor assertions that the ICC reader’s slot is in full view of the cardholder so that any untoward obstructions or suspicious objects at the opening are detectable. The construction of the device should be such that the entire slot opening is in full view of the cardholder prior to card insertion.
Modified p. 55 → 91
TD3.1 The tester shall examine the vendor‘s response to Section D3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D3 of the PCI PTS POI Security Requirements for consistency relevant to D3.
TD3.1 The tester shall examine the vendor’s response to Section D3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D3 of the PCI PTS POI Security Requirements for consistency relevant to D3. The tester shall summarize the responses.
Removed p. 56
 Both D4.1 and D4.2 must be complied with for any non-integrated device supporting offline PIN entry.
Modified p. 56 → 92
A plain-text PIN from the PIN entry device to the ICC reader is never permitted except when the PIN entry device and ICC reader are integrated into the same secure module.
A plaintext PIN from the PIN entry device to the ICC reader is never permitted except when the PIN entry device and ICC reader are integrated into the same secure module.
Modified p. 56 → 92
When the cardholder verification method is determined to be an enciphered PIN, the encipherment must occur within the PIN entry device itself or a secure component of the device. The PIN must be enciphered in accordance with ISO 9564 for secure transport between the PIN entry device and the secure component.
When the cardholder verification method is determined to be an enciphered PIN, the encipherment must occur within the PIN entry device itself or a secure component of the device. The PIN must be enciphered in accordance with ISO 9564 for secure transport between the PIN entry device and the secure component. The PIN must be encrypted immediately after PIN entry is complete and has been signified as such by the cardholder for example, via pressing the enter button.
Modified p. 56 → 92
In order to receive an approval for offline PIN entry, a device must be capable of supporting both plain-text and enciphered PINs.
In order to receive an approval for offline PIN entry, a device must be capable of supporting both plaintext and enciphered PINs.
Modified p. 56 → 92
TD4.1.1 The tester shall examine the vendor‘s response to Section D4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS POI Security Requirements for consistency relevant to D4.
TD4.1 The tester shall examine the vendor’s response to Section D4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS POI Security Requirements for consistency relevant to D4. The tester shall summarize the responses.
Removed p. 57
a) An authenticated encipherment key of the ICC

b) Triple-DES Tests that may be performed include: performing a simulated transaction so that PIN data can be captured and analyzed, using a special function of the device that allows a user to determine the methods of encryption used, or using test tools (such as ICC emulators) and software to determine the method of encipherment. The tester may require the vendor to supply special hardware and software to facilitate this test, or they can use their own hardware and test tools.
Removed p. 58
A plain-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.

Both D4.1 and D4.2 must be complied with for any non-integrated device supporting offline PIN entry.
Removed p. 58
TD4.2.2 The tester shall test the device to determine that the PIN is enciphered between the device‘s PIN entry device and the ICC reader in accordance with ISO 9564.

Tests that may be performed include: performing a simulated transaction so that PIN data can be captured and analyzed, using a special function of the device that allows a user to determine the methods of encryption used, or using test tools (such as ICC reader emulators) and software to determine the method of encipherment. The tester may require the vendor to supply special hardware and software to facilitate this test, or they can use their own hardware and test tools.
Removed p. 59
Both D4.3 and D4.4 must be complied with for any integrated device supporting offline PIN entry.

The authentication must occur in a secure component of the device, such as the PIN pad or ICCR. This includes the authentication of the ICC public key(s) as well as the associated issuer public key in the certificate chain, up to the applicable payment-brand key.

TD4.3.2 The tester will perform a transaction and capture the encrypted PIN block between the device‘s PIN entry device and ICC reader. The tester may require the vendor to supply special hardware and software to facilitate this test, or they can use their own hardware and test tools.

Both D4.3 and D4.4 must be complied with for any integrated device supporting offline PIN entry.
Removed p. 60
TD4.4.2 The tester shall verify that the plain-text PIN is transmitted wholly through a protected environment. This will be accomplished by examining the device to determine that its tamper-detection protections are equivalent to the protections required by D1, and for compliance to ISO 9564.

TD4.4.3 If the plain-text PIN is transmitted to the ICC reader through an unprotected environment, the tester shall test the device to determine that the PIN is enciphered between the device's PIN entry device and the ICC reader in accordance with ISO 9564.

Tests that may be performed include: performing a simulated transaction so that PIN data can be captured and analyzed; using a special function of the device that allows a user to determine the methods of encryption used; or using test tools (such as ICC reader emulators) and software to determine the method of encipherment.
Modified p. 61 → 94
TE1.1 The tester shall examine the response to Section E1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E1 of the PCI PTS POI Security Requirements for consistency relevant to E1.
TE1.1 The tester shall examine the response to Section E1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E1 of the PCI PTS POI Security Requirements for consistency relevant to E1. The tester shall summarize the responses.
Modified p. 61 → 94
TE1.2 The tester shall examine any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
TE1.2 The tester shall examine and cite any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
Modified p. 62 → 95
A PIN-handling component of the device (e.g., the EPP) never outputs information to another component (e.g., a display or a device controller) allowing the differentiation of the PIN digits entered.
A PIN-handling component of the device (for example, the EPP) never outputs information to another component (for example, a display or a device controller) allowing the differentiation of the PIN digits entered.
Modified p. 62 → 95
DTRs E2.1 to E2.2 specifically care about the PIN entry function and how it is integrated into a payment terminal (irrespective of the form factor), whereas DTRs E3.1 to E3.5 aim at ensuring that components are being properly integrated. As such, DTRs E3.1 to E3.5 target compound architectures and are not relevant to, e.g., countertop devices.
DTRs E2.1 to E2.2 specifically care about the PIN entry function and how it is integrated into a payment terminal (irrespective of the form factor), whereas DTRs E3.1 to E3.5 aim at ensuring that components are being properly integrated. As such, DTRs E3.1 to E3.5 target compound architectures and are not relevant to, for example, countertop devices.
Modified p. 62 → 95
TE2.1.1 The tester shall examine the response to Section E2.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E2.1 of the PCI PTS POI Security Requirements for consistency relevant to E2.1.
TE2.1.1 The tester shall examine the response to Section E2.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E2.1 of the PCI PTS POI Security Requirements for consistency relevant to E2.1. The tester shall summarize the responses.
Modified p. 62 → 95
TE2.1.2 The tester shall examine any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
TE2.1.2 The tester shall examine and cite any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
Modified p. 62 → 95
TE2.1.4 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.
TE2.1.4 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. 63 → 96
TE2.2.1 The tester shall examine the response to Section E2.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E2.2 of the PCI PTS POI Security Requirements for consistency relevant to E2.2.
TE2.2.1 The tester shall examine the response to Section E2.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E2.2 of the PCI PTS POI Security Requirements for consistency relevant to E2.2. The tester shall summarize the responses.
Modified p. 63 → 96
TE2.2.2 The tester shall examine any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
TE2.2.2 The tester shall examine and cite any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
Modified p. 63 → 96
TE2.2.3 The tester shall develop attack scenario(s) to place an overlay with a PIN-disclosing bug. 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.
TE2.2.3 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 example shown in DTR A1 …
Modified p. 64 → 97
DTRs E2.1 to E2.2 specifically care about the PIN entry function and how it is integrated into a payment terminal (irrespective of the form factor), whereas DTRs E3.1 to E3.5 aim at ensuring that components are being properly integrated. As such, DTRs E3.1 to E3.5 target compound architectures and are not relevant to, e.g., countertop devices.
DTRs E2.1 to E2.2 specifically care about the PIN entry function and how it is integrated into a payment terminal (irrespective of the form factor), whereas DTRs E3.1 to E3.5 aim at ensuring that components are being properly integrated. As such, DTRs E3.1 to E3.5 target compound architectures and are not relevant to, for example, countertop devices.
Modified p. 64 → 97
Logical integration encompasses communication protocols between secure devices and non-secure devices. Devices pairing, unbinding, mutual authentication, and other security- sensitive mechanisms enter this category. Special care is needed when combining devices that were approved in isolation.
Logical integration encompasses communication protocols between secure devices and non-secure devices. Devices pairing, unbinding, mutual authentication, and other security-sensitive mechanisms enter this category. Special care is needed when combining devices that were approved in isolation.
Modified p. 64 → 97
Physical integration of components encompasses, e.g., integration into a cabinet.
Physical integration of components encompasses, for example, integration into a cabinet.
Modified p. 64 → 97
Protocol fault injections are covered by requirement B2, whereas protocol abuses through regular requests are covered by this requirement.
Protocol fault injections are covered by Requirement B2, whereas protocol abuses through regular requests are covered by this requirement.
Modified p. 64 → 97
TE3.1.1 The tester shall examine the response to Section E3.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.1 of the PCI PTS POI Security Requirements for consistency relevant to E3.1.
TE3.1.1 The tester shall examine the response to Section E3.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.1 of the PCI PTS POI Security Requirements for consistency relevant to E3.1. The tester shall summarize the responses.
Modified p. 64 → 97
TE3.1.2 The tester shall examine any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
TE3.1.2 The tester shall examine and cite any additional relevant documentation, such as schematics, housing/frame, data sheets, etc., submitted by the vendor to verify that it supports vendor responses.
Modified p. 64 → 97
TE3.1.3 The tester shall examine that the integration of the approved secure component into the PIN entry POI terminal has been performed strictly according to the component manufacturer‘s recommendations.
TE3.1.3 The tester shall examine that the integration of the approved secure component into the PIN entry POI terminal has been performed strictly according to the component manufacturer’s recommendations.
Modified p. 64 → 97
TE3.1.4 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).
TE3.1.4 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. 65 → 98
TE3.2.1 The tester shall examine the vendor‘s response to Section E3.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.2 of the PCI PTS POI Security Requirements for consistency relevant to E3.2.
TE3.2.1 The tester shall examine the vendor’s response to Section E3.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.2 of the PCI PTS POI Security Requirements for consistency relevant to E3.2. The tester shall summarize the responses.
Modified p. 66 → 99
TE3.3.1 The tester shall examine the vendor‘s response to Section E3.3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.3 of the PCI PTS POI Security Requirements for consistency relevant to E3.3.
TE3.3.1 The tester shall examine the vendor’s response to Section E3.3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.3 of the PCI PTS POI Security Requirements for consistency relevant to E3.3. The tester shall summarize the responses.
Modified p. 66 → 99
More specifically, there is a clear logical and/or physical segregation between PIN security-related interfaces and generic cardholder POS interface (keys, display, card- reading, etc.).
More specifically, there is a clear logical and/or physical segregation between PIN security-related interfaces and generic cardholder POS interface (keys, display, card-reading, etc.).
Modified p. 66 → 99
The usage of visually segregate displays (or a single display with clearly segregated entry interface) may support the logical segregation of interfaces (or security functions).
The usage of visually separate displays (or a single display with clearly separated entry interfaces) may support the logical separation of interfaces (or security functions).
Modified p. 66 → 99
TE3.3.3 The tester shall examine any relevant documentation, such as a user guide, the specification of the device‘s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TE3.3.3 The tester shall examine any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 66 → 99
TE3.3.4 The tester shall establish a comprehensive list of all components, together with their relationship and qualification against security, and verify that they are physically or logically segregated TE3.3.5 If the vendor does not provide with the final PIN-enabled payment application, the tester shall verify that the vendor provides third party developers with the appropriate documentation on how to implement the transaction flow, such as it is reasonably obvious for a cardholder to distinguish whether or not he or she …
TE3.3.5 If the vendor does not provide with the final PIN-enabled payment application, the tester shall verify that the vendor provides third party developers with the appropriate documentation on how to implement the transaction flow, such as it is reasonably obvious for a cardholder to distinguish whether or not he or she is about to enter his or her PIN on the device.
Removed p. 67
A8 should be selected when the prompts are fixed and cannot be updated; for example, when they are stored in ROM. B16.1 should be complied with for devices that allow prompts to be changed as part of firmware updates. B16.2 is appropriate for attended or unattended devices where the original equipment manufacturer has shipped the device with mechanisms for controlling the POI display and its use in place for the acquirer to control the display, and E3.4 is appropriate for all unattended or other devices that do not meet any of the aforementioned.
Modified p. 67 → 100
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 (for example, a store controller), the commands enabling data entry must be authenticated.
Modified p. 67 → 100
The ability to physically access the connection between devices (e.g., EPP, UPT controller, and ICC reader) must not facilitate attacks to interfere with that correspondence and especially to collect clear PIN data (e.g., commands are authenticated and/or enciphered). Keys used for such protocols must only be used for this purpose, and may then be stored and used in the UPT controller in the clear. It is not required to use a cryptographic module in the controller for that purpose.
The ability to physically access the connection between devices (for example, EPP, UPT controller, and ICC reader) must not facilitate attacks to interfere with that correspondence and especially to collect clear PIN data (for example, commands are authenticated and/or enciphered). Keys used for such protocols must only be used for this purpose, and may then be stored and used in the UPT controller in the clear. It is not required to use a cryptographic module in the controller for that …
Modified p. 67 → 100
Section E3.4 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the control of the device‘s operating modes and the corresponding display messages visible to the cardholder, for consistency.
TE3.4.1 The tester shall examine the assertions provided by the vendor in response to Section E3.4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.4 of the PCI PTS POI Security Requirements manual for consistency relating to the control of the device’s operating modes and the corresponding display messages visible to the cardholder. The tester shall summarize the responses.
Modified p. 67 → 100
TE3.4.2 The tester shall examine any additional documentation (i.e., API programmer‘s guide, specifications, schematics, block diagrams, etc.) containing information that relates to the control of the device‘s operating modes and the corresponding display messages visible to the cardholder, to determine whether it supports the assertions made by the vendor.
TE3.4.2 The tester shall examine and cite any additional documentation (i.e., API programmer’s guide, specifications, schematics, block diagrams, etc.) containing information that relates to the control of the device’s operating modes and the corresponding display messages visible to the cardholder, to determine whether it supports the assertions made by the vendor.
Modified p. 67 → 100
TE3.4.3 The tester shall verify by testing, that the ability to physically access the connection between devices does must not facilitate attacks to interfere with that correspondence. If commands are authenticated and/or enciphered, the existence and efficiency of this mechanism must be verified.
TE3.4.4 The tester shall describe the path from the display to the processing element that controls the display. The tester shall verify, by testing, that the ability to physically access the connection between devices does must not facilitate attacks to interfere with that correspondence. If commands are authenticated and/or enciphered, the existence and efficiency of this mechanism must be verified.
Removed p. 68
TE3.4.6 The tester shall develop attack scenarios for the alteration of the correspondence between the display messages visible to the cardholder and the operating state of the device such that PINs are compromised, i.e., by prompting for the PIN entry when the output is not encrypted. The attack potential calculation shall be based on the scheme depicted in Appendix B. If an attack scenario can be developed that requires an attack potential of less than 18 per device for identification and initial exploitation or less than 9 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be verified.
Modified p. 68 → 101
TE3.4.5 If commands impacting the correspondence between the display messages and the operating state of the device are received from an external device (e.g., a store controller), the tester must verify that the commands enabling data entry are authenticated and that the mechanisms are efficient.
TE3.4.6 If commands impacting the correspondence between the display messages and the operating state of the device are received from an external device (for example, a store controller), the tester must verify that the commands enabling data entry are authenticated and that the mechanisms are efficient.
Modified p. 69 → 102
Devices implementing at the same time a touch screen for PIN entry and a separate keypad (e.g., to meet visual impaired regulations) must meet this requirement.
Devices implementing at the same time a touch screen for PIN entry and a separate keypad (for example, to meet visual impaired regulations) must meet this requirement.
Modified p. 69 → 102
TE3.5.1 The tester shall examine the vendor‘s response to Section E3.5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.5 of the PCI PTS POI Security Requirements to verify that any interface of the device that can be used to accept payment card numeric entry is controlled, and that the device is equipped with only one PIN-accepting keyboard or it is controlled in a manner consistent with A8, B16.1, B16.2 or E3.4.
TE3.5.1 The tester shall examine the vendor’s response to Section E3.5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.5 of the PCI PTS POI Security Requirements to verify that any interface of the device that can be used to accept payment card numeric entry is controlled, and that the device is equipped with only one PIN-accepting keyboard or it is controlled in a manner consistent with A7, B16.1, B16.2 or E3.4. The tester shall …
Modified p. 69 → 102
TE3.5.2 The tester shall examine any additional documentation (i.e., user guide, specifications, block diagrams, etc.) containing information about data entry devices and its possible use for numeric entry, submitted by the vendor to verify that it supports the vendor assertions.
TE3.5.2 The tester shall examine and cite any additional documentation (i.e., user guides, specifications, block diagrams, etc.) containing information about data entry devices and its possible use for numeric entry, submitted by the vendor to verify that it supports the vendor assertions.
Modified p. 69 → 102
 The device must is equipped with only one payment card PIN-accepting keyboard, and  If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry, e.g., it must not have numeric keys, or it must not be possible to use it otherwise for numeric entry or it is controlled in a manner consistent with A8, B16.1, B16.2 or E3.4.
 The device must is equipped with only one payment card PIN-accepting keyboard, and  If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry, for example, it must not have numeric keys, or it must not be possible to use it otherwise for numeric entry or it is controlled in a manner consistent with A7, B16.1, B16.2 or E3.4.
Modified p. 69 → 102
TE3.5.4 If the device is equipped with more than one keyboard, and if the keyboard not intended for payment card PIN entry may be operated to accept numeric entry (e.g., since it is equipped with numeric keys or since it is fully programmable, like a touch screen), the tester shall verify that these numeric modes may not be used to enter a payment card PIN, especially that a possible use of numeric entry modes does not interfere with Requirement A8, …
TE3.5.4 If the device is equipped with more than one keyboard, and if the keyboard not intended for payment card PIN entry may be operated to accept numeric entry (for example, since it is equipped with numeric keys or since it is fully programmable, like a touch screen), the tester shall verify that these numeric modes may not be used to enter a payment card PIN, especially that a possible use of numeric entry modes does not interfere with Requirement …
Modified p. 70 → 103
The objective of this section is to assess the device’s ability to protect the device against removal from the cabinet. This protections aims against PIN entry device overlays or chained ICC readers; it also aims at complicating attacks against the PIN entry device and ICC reader. As such, this requirement applies to devices and modules aimed at being mechanically integrated into a compound device, e.g., kiosk or AFD.
The objective of this section is to assess the device’s ability to protect the device against removal from the cabinet. This protections aims against PIN entry device overlays or chained ICC readers; it also aims at complicating attacks against the PIN entry device and ICC reader. As such, this requirement applies to devices and modules aimed at being mechanically integrated into a compound device, for example, kiosk or AFD.
Modified p. 70 → 103
The mechanisms for protection from unauthorized removal for secure components previously evaluated in A11 shall be assessed to determine proper implementation in the final form factor under assessment.
The mechanisms for protection from unauthorized removal for secure components previously evaluated in A10 shall be assessed to determine proper implementation in the final form factor under assessment.
Modified p. 70 → 103
TE4.1.1 The tester shall examine the vendor‘s response to Section E4.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.1 of the PCI PTS POI Security Requirements for consistency relevant to E4.1.
TE4.1.1 The tester shall examine the vendor’s response to Section E4.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.1 of the PCI PTS POI Security Requirements for consistency relevant to E4.1. The tester shall summarize the responses.
Modified p. 70 → 103
TE4.1.4 For secure components previously assessed under A11, the tester shall:
TE4.1.4 For secure components previously assessed under A10, the tester shall:
Modified p. 70 → 103
 Review the report(s) covering the removal detection mechanisms of each sub- component.
 Review the report(s) covering the removal detection mechanisms of each sub-component.
Modified p. 70 → 103
 Confirm that the method of installation does not invalidate the removal sensor technique used (e.g., the sub-component is installed on a sub-chassis which itself can be removed).
 Confirm that the method of installation does not invalidate the removal sensor technique used (for example, the sub-component is installed on a sub-chassis which itself can be removed).
Removed p. 71
TE4.1.6 If the device allows for temporary removal and re-installation, the tester shall verify  The authorization for removal implements the principles of dual control.  Sensitive information required for the authorization (e.g., passwords) is initialized or used in a way that prevents replay at the same or a different device.  When removed/substituted without authorization, the device will not further process PINs.  An authorized installation must provide traceability and accountability.
Modified p. 71 → 104
 Determine what methods of approved removal are implemented, and confirm that they are the same as those evaluated in DTR A11. Verify that the approved removal creates an audit trail that can be accessed, and detail the method which must be used to access the audit trail on the device.
 Determine what methods of approved removal are implemented, and confirm that they are the same as those evaluated in DTR A10. Verify that the approved removal creates an audit trail that can be accessed, and detail the method that must be used to access the audit trail on the device.
Modified p. 71 → 104
TE4.1.5 The tester shall determine whether the device uses passive or active protection, and assess the method for installation and for permanent or temporary removal. Assess the method for installation and full/temporary removal. An option for temporary removal without secret and private key erasure requires an authorized method.
TE4.1.5 The tester shall determine whether the device uses passive and/or active protection(s), and assess the method for installation and for permanent or temporary removal. The tester shall assess the method for installation and full/temporary removal. An option for temporary removal without secret and private-key erasure requires an authorized method.
Modified p. 71 → 104
TE4.1.7 The tester shall develop attack scenario(s) to defeat or circumvent the protection against removal. If an attack scenario can be developed that yields an attack potential of less than 18 per device for identification and initial exploitation or less than 9 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified.
TE4.1.11 The tester shall develop attack scenario(s) to defeat or circumvent the protection against removal. If an attack scenario can be developed that yields an attack potential of less than 18 per device for identification and initial exploitation or less than 9 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. At least one attack scenario shall be presented, in a format consistent with the example shown in DTR A1 in this document.
Modified p. 72 → 105
TE4.2.1 The tester shall examine The tester shall examine the vendor‘s response to Section E4.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.2 of the PCI PTS POI Security Requirements for consistency relevant to E4.2.
TE4.2.1 The tester shall examine The tester shall examine the vendor’s response to Section E4.2 of the
Modified p. 72 → 105
TE4.2.4 The tester shall verify that the integration documentation is properly maintained, e.g., in case of a device update. More specifically, the tester shall examine and document the vendor document release cycle, and assess how it integrates with the device design/manufacturing update process.
TE4.2.4 The tester shall verify that the integration documentation is properly maintained, for example, in case of a device update. More specifically, the tester shall examine and document the vendor document-release cycle, and assess how it integrates with the device design/manufacturing update process.
Removed p. 73
TE4.3.3 The tester shall verify that procedures exist for the integration documentation to be shipped or otherwise made available to the customer.

TE4.3.4 The tester shall verify that the integration documentation is properly maintained, e.g., in case of device updates. More specifically, the tester shall examine and document the vendor document release cycle, and assess how it integrates with the device design/manufacturing update process.
Modified p. 73 → 106
TE4.3.1 The tester shall examine the vendor‘s response to Section E4.3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.3 of the PCI PTS POI Security Requirements for consistency relevant to E4.3.
TE4.3.1 The tester shall examine the vendor’s response to Section E4.3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E4.3 of the PCI PTS POI Security Requirements for consistency relevant to E4.3. The tester shall summarize the responses.
Modified p. 73 → 106
TE4.3.5 The tester shall visually inspect the device, and attempt to remove the component(s), to verify whether the unauthorized removal protection is effective.
TE4.3.3 The tester shall visually inspect the device, and attempt to remove the component(s), to verify whether the unauthorized removal protection is effective.
Removed p. 74
TF1.1 The tester shall examine, for consistency and completeness:

 The response to Requirement F1 of the PCI PTS POI Security Requirements,  The declaration of link layer options in the Open Protocols Module

• Protocol Declaration Form,  The vendor‘s response, and the referenced documentation, in Section F1 of the PCI PTS POI Vendor Questionnaire,  Any other relevant documentation submitted by the vendor or publicly available.

TF1.2 The tester shall execute a communication test using at least one link layer option.

TF1.3 The tester shall examine if, using the active link layer option(s), a complete security assessment of the platform‘s IP and link layer can be executed.

TF2.1 The tester shall examine, for consistency and completeness:

 The response to Requirement F2 of the PCI PTS POI Security Requirements,  The declaration of link layer options in the Open Protocols Module

• Protocol Declaration Form,  The vendor‘s response, and the referenced documentation, in Section …
Removed p. 75
TF2.6 The tester shall examine whether the IP and link layer does not contain exploitable vulnerabilities.
Modified p. 75 → 110
a) The vulnerability assessment is supported by a documented analysis describing the security of the IP and link layer.
a) The vulnerability assessment is supported by a documented analysis describing the security of the protocols and interfaces.
Modified p. 75 → 110
TF2.5 The tester shall execute a vulnerability assessment, to examine whether there are vulnerabilities in the IP and link layer.
TG2.5 The tester shall execute a vulnerability assessment by research, analysis, and testing, to identify vulnerabilities associated with the protocols.
Removed p. 76
b) The security guidance ensures secure use of the IP and link layer.

TF3.1 The tester shall examine, for consistency and completeness:

 The response to Requirement F3 of the Security Compliance Statements,  The vendor‘s response, and the referenced documentation, in Section F3 of the

PCI PTS POI Vendor Questionnaire.

TF3.2 The tester shall examine the referenced documentation to assess whether the security guidance ensures that application developers, system integrators and end- users of the platform are clearly and correctly guided into the secure use of the IP and link layer.

TF3.3 The tester shall examine the referenced documentation to assess whether procedures ensure correct and complete distribution of the security guidance.
Modified p. 76 → 114
a) The platform vendor puts the security guidance at the disposal of application developers, system integrators, and end-users of the platform.
a) The key-management guidance is at the disposal of internal users and/or of application developers, system integrators, and end-users of the device.
Removed p. 77
TF4.1 The tester shall examine, for consistency and completeness:

 The response to Requirement F4 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section F4 of the

PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TF4.2 The tester shall examine the referenced documentation to assess whether the default configuration of the IP and link layer is in line with the security guidance.

PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.
Removed p. 78
TG1.1 The tester shall examine, for consistency and completeness:

 The response to Requirement G1 of the PCI PTS POI Security Requirements,  The declaration of IP protocols in the Open Protocols Module

• Protocol Declaration Form,  The vendor‘s response, and the referenced documentation, in Section G1 of the

TG1.2 The tester shall execute an IP protocol scan, to identify available IP protocols.

TG1.3 The tester shall monitor platform communication, to ensure that all the declared IP protocols are visible, and that no other IP protocols are present.

TG1.4 The tester shall examine whether a complete assessment of the security of the platform‘s IP protocols can be executed.
Removed p. 79
a) The vulnerability assessment is supported by a documented analysis describing the security of the IP protocols.

b) The vulnerability assessment is supported by a vulnerability survey of information available in the public domain.

TG2.1 The tester shall examine, for consistency and completeness:

 The response to Requirement G2 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section G2 of the PCI PTS POI Vendor Questionnaire  Any other relevant documentation submitted by the vendor or publicly available.

TG2.4 The tester shall execute a vulnerability assessment, by research, analysis and testing, to identify vulnerabilities associated with the IP protocols.

TG2.5 The tester shall examine that, if anomalies are present in the IP protocols:

TG2.6 The tester shall examine whether the IP protocols of the platform do not contain exploitable vulnerabilities.
Modified p. 79 → 110
c) The vulnerability assessment is supported by testing.
Review the vulnerability assessment for each interface as defined in F1.
Modified p. 79 → 110
TG2.2 The tester shall examine the referenced documentation to assess whether the vulnerability assessment measures described ensure that all IP Protocol vulnerabilities are detected.
TG2.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 79 → 111
TG2.3 The tester shall examine the reference documentation to assess whether the vulnerability assessment measures described are supported by evidence.
TG3.2 The tester shall examine any relevant documentation, such as a user guide or the merchant implementation guide submitted by the vendor, to verify that it supports the vendor responses.
Removed p. 80
TG3.1 The tester shall examine, for consistency and completeness:

 The response to Requirement G3 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section G3 of the PCI PTS POI Vendor Questionnaire.
Removed p. 80
TG3.2 The tester shall examine the referenced documentation to assess whether the security guidance ensures that application developers, system integrators and end- users of the platform are clearly and correctly guided into the secure use of the IP protocols.

TG3.3 The tester shall examine the referenced documentation to assess whether procedures ensure correct and complete distribution of the security guidance.
Removed p. 81
TG4.1 The tester shall examine, for consistency and completeness:

 The response to Requirement G4 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section G4 of the PCI PTS POI Vendor Questionnaire.

TG4.2 The tester shall examine the referenced documentation to assess whether the default configuration of the IP protocols is in line with the security guidance.
Removed p. 82
TH1.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H1 of the PCI PTS POI Security Requirements,  The declaration of security protocols in the Open Protocols Module

• Protocol Declaration Form,  The vendor‘s response, and the referenced documentation, in Section H1 of the PCI PTS POI Vendor Questionnaire.

TH1.2 The tester shall monitor platform communication, to ensure that all the declared security protocols are visible, and that no other security protocols are present.

TH1.3 The tester shall examine whether a complete assessment of the security of the platform‘s security protocols can be executed.

b) The vulnerability assessment is supported by a vulnerability survey of information available in the public domain.
Removed p. 83
a) The vulnerability assessment is supported by a documented analysis describing why the vendor is convinced of the security protocols not jeopardizing platform security.

TH2.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H2 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H2 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TH2.2 The tester shall examine the referenced documentation to assess whether the vulnerability assessment measures described ensure that all security protocol vulnerabilities are detected.

TH2.3 The tester shall examine the reference documentation, to assess whether the vulnerability assessment measures described are supported by evidence.

TH2.4 The tester shall execute a vulnerability assessment, by analysis, research and testing, to identify vulnerabilities associated with the security protocols.

TH2.5 The tester shall examine that, if anomalies are present in security protocols:

TH2.6 The tester …
Modified p. 83 → 111
c) The vulnerability assessment is supported by testing.
Review the vulnerability assessment for each interface as defined in F1.
Removed p. 84
b) The security guidance ensures secure use of the security protocols.

c) The security guidance clearly mentions if specific security protocols must not be used for financial applications and/or platform management.

d) The security guidance clearly mentions if specific configurations of security protocols must not be used for financial applications and/or platform management.

TH3.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H3 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H3 of the PCI PTS POI Vendor Questionnaire. TH3.2 The tester shall examine the referenced documentation to assess if the security guidance ensures that application developers, system integrators and end-users of the platform are clearly and correctly guided into the secure use of the security protocols.

TH3.3 The tester shall examine the referenced documentation to assess if procedures ensure correct and complete distribution of the security guidance.
Modified p. 84 → 114
a) The platform vendor puts the security guidance at the disposal of application developers, system integrators, and end-users of the platform.
c) Key-management security guidance describes the responsibilities of the device vendor, application developers, system integrators, and end-users of the device.
Removed p. 85
TH4.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H4 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H4 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TH4.2 The tester shall examine the referenced documentation to assess whether the default configuration of the security protocols is in line with the security guidance.
Removed p. 86
a) The platform vendor puts the key-management security guidance at the disposal of internal users, and/or of application developers, system integrators and end-users of the platform.

c) Key-management security guidance describes the responsibilities of the platform vendor, application developers, system integrators and end-users of the platform.

TH5.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H5 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H5 of the PCI PTS POI Vendor Questionnaire.

TH5.2 The tester shall examine the referenced documentation to assess that keys are not shared between independent security protocols.

TH5.3 The tester shall examine the referenced documentation to assess whether the security guidance ensures that the vendor‘s internal users and/or application developers, system integrators and end-users of the platform, are clearly and correctly guided into the secure use of keys and certificates.
Modified p. 86 → 114
b) Key-management security guidance describes the properties of all keys and certificates that can be used by the platform.
b) Key-management security guidance describes the properties of all keys and certificates that can be used by the device.
Removed p. 87
TH6.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H6 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation in Section H6 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TH6.2 The tester shall examine the referenced documentation to assess whether the provided encryption is in line with Requirement H6.

TH6.3 The tester shall execute tests to verify whether the implementation is in line with the documentation.
Modified p. 87 → 116
b) Encryption is provided by using keys that are established in a secure manner using appropriate key-management procedures, such as those listed in NISTSP800-21, Guidelines for Implementing Cryptography.
b) Encryption is provided by using keys that are established in a secure manner using appropriate key-management procedures, such as those listed in NIST SP800-21, Guideline for Implementing Cryptography in the Federal Government and ISO 11568 Banking

• Key Management (Retail).
Removed p. 88
TH7.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H7 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H7 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TH7.2 The tester shall examine the referenced documentation to assess whether the provided integrity is in line with Requirement H7.

TH7.3 The tester shall execute tests to verify whether the implementation is in line with the documentation.
Modified p. 88 → 117
a) Integrity is provided by a MAC or by a digital signature.
a) Integrity is provided by a MAC as defined in ISO 16609, or by a digital signature.
Modified p. 88 → 117
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA- 384 and SHA-512.
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.
Removed p. 89
TH8.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H8 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H8 of the PCI PTS POI Vendor Questionnaire=.  Any other relevant documentation submitted by the vendor or publicly available.

TH8.2 The tester shall examine the referenced documentation to assess whether the provided server authentication is in line with Requirement H8.

TH8.3 The tester shall execute tests to verify whether the implementation is in line with the documentation.
Modified p. 89 → 118
a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question.
a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question as denoted in Appendix D.
Modified p. 89 → 118
b) The platform is able to verify the validity of the public keys it receives
c) The device is able to verify the validity of the public keys it receives.
Modified p. 89 → 118
c) The platform is able to verify the authenticity of the public keys it receives.
d) The device is able to verify the authenticity of the public keys it receives.
Modified p. 89 → 118
TH8.4 The tester shall execute tests to verify platform behavior when receiving incorrect certificates.
TI4.3 The tester shall execute tests to verify device behavior when receiving incorrect certificates, including:
Removed p. 90
TH9.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H9 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H9 of the PCI PTS POI Vendor Questionnaire.

TH9.2 The tester shall examine the referenced documentation to assess whether the provided replay detection is in line with Requirement H9.

TH9.3 The tester shall execute tests to verify whether the implementation is in line with the documentation.
Modified p. 90 → 117
TH9.4 The tester shall execute tests to verify platform behavior when receiving replayed messages.
TI3.3 The tester shall verify device behavior when receiving incorrect data packets.
Removed p. 91
TH10.1 The tester shall examine, for consistency and completeness:

 The response to Requirement H10 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section H10 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TH10.2 The tester shall examine the referenced documentation to assess whether the provided random generator is in line with Requirement H10.
Removed p. 92
TI1.1 The tester shall examine, for consistency and completeness:

 The response to Requirement I1 of the PCI PTS POI Security Requirements,  The declaration of IP services in the Open Protocols Module

• Protocol Declaration Form  The vendor‘s response, and the referenced documentation, in Section I1 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TI1.2 The tester shall execute a scan, to identify platform services that are acting as a server.

TI1.3 The tester shall monitor platform communication, to ensure that all the declared IP Services are visible, and that no other IP services are present.

TI1.4 The tester shall examine whether a complete assessment of the security of the platform‘s security protocols can be executed.
Removed p. 93
a) The assessment is supported by a documented analysis describing why the vendor is convinced of the IP Services not jeopardizing platform security.

b) The assessment is supported by a vulnerability survey of information available in the public domain.

c) The assessment is supported by testing.

TI2.1 The tester shall examine, for consistency and completeness:

 The response to Requirement I2 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section I2 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TI2.2 The tester shall examine the referenced documentation to assess whether the vendor‘s vulnerability assessment measures ensure that all the vulnerabilities in the IP Services can be detected.

TI2.3 The tester shall examine the referenced documentation to assess whether the vendor‘s vulnerability assessment measures are supported by evidence.

TI2.4 The tester shall execute a vulnerability assessment, by analysis, research …
Modified p. 94 → 121
a) The platform vendor puts the security guidance at the disposal of application developers, system integrators and end-users of the platform.
a) The guidance is at the disposal of internal users, and/or of application developers, system integrators, and end-users of the device.
Removed p. 95
TI4.1 The tester shall examine, for consistency and completeness:

 The response to Requirement I4 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section I4 of the PCI PTS POI Vendor Questionnaire.  Any other relevant documentation submitted by the vendor or publicly available.

TI4.2 The tester shall examine the referenced documentation to assess whether the default configuration of the IP services is in line with the security guidance.

TI5.1 The tester shall examine, for consistency and completeness:

 The response to Requirement I5 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section I5 of the PCI PTS POI Vendor Questionnaire.

TI5.2 The tester shall examine the referenced documentation to assess whether the provided session management is in line with Requirement I5.

TI5.3 The tester shall execute tests to verify whether the implementation is in line with the documentation.
Modified p. 96 → 120
a) The platform keeps track of all connections and restricts the number of sessions that can remain active on the platform to the minimum necessary number.
a) The device keeps track of all connections and restricts the number of sessions that can remain active on the device to the minimum necessary number.
Modified p. 96 → 120
b) The platform sets time limits for sessions and ensures that sessions are not left open for longer than necessary.
b) The device sets time limits for sessions and ensures that sessions are not left open for longer than necessary.
Removed p. 97
TI6.1 The tester shall examine, for consistency and completeness:

 The response to Requirement I6 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section I6 of the PCI PTS POI Vendor Questionnaire.

TI6.2 The tester shall examine the referenced documentation to assess whether the provided information is in line with Requirement I6.

TI6.3 The tester shall execute tests to verify whether the implementation is in line with the documentation.
Removed p. 98
a) The platform vendor puts the security guidance at the disposal of internal users, and/or of application developers, system integrators and end-users of the platform.

TJ1.1 The tester shall examine, for consistency and completeness:

 The response to Requirement J1 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section J1 of the PCI PTS POI Vendor Questionnaire.

TJ1.2 The tester shall examine the referenced documentation to assess the vendor‘s security guidance describing configuration management measures.
Modified p. 98 → 121
b) The security guidance covers the complete platform; including firmware, applications, certificates and keys.
b) The guidance covers the complete device•including firmware, payment and non-payment applications, forms, multimedia files, certificates, configuration files, configuration setting, and keys.
Modified p. 98 → 121
c) The security guidance covers the complete life cycle of the platform from development, over manufacturing, up to delivery and operation.
c) The guidance covers the complete life cycle of the device from development, over manufacturing, up to delivery and operation.
Modified p. 98 → 121
e) The security guidance ensures that any modification of a PCI-approved platform that impacts platform security, results in a change of the platform identifier.
e) The security guidance ensures that any modification of a PTS-approved device that impacts security, results in a change of the device identifier.
Removed p. 99
TJ2.1 The tester shall examine, for consistency and completeness:

 The response to Requirement J2 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section J2 of the PCI PTS POI Vendor Questionnaire.
Modified p. 99 → 122
a) The security maintenance measures are documented.
a) The maintenance measures are documented.
Modified p. 99 → 122
b) The security maintenance measures ensure timely detection of vulnerabilities that apply to the device by periodical execution of a vulnerability assessment that includes activities such as: analysis, survey of information available in the public domain, and testing.
b) The maintenance measures ensure timely detection of vulnerabilities that apply to the device by periodic execution of a vulnerability assessment that includes activities such as: analysis, survey of information available in the public domain, and testing.
Modified p. 99 → 122
c) The security maintenance measures ensure timely assessment and classification of newly found vulnerabilities.
c) The maintenance measures ensure timely assessment and classification of newly found vulnerabilities.
Modified p. 99 → 122
d) The security maintenance measures ensure timely creation of mitigation measures for newly found vulnerabilities that may impact platform security.
d) The maintenance measures ensure timely creation of mitigation measures for newly found vulnerabilities that may impact device security.
Modified p. 99 → 122
TJ2.2 The tester shall examine the referenced documentation to assess the vendor‘s security maintenance measures.
TJ2.3 The tester shall assess the device to ensure the declared security-maintenance measures are present, which must:
Removed p. 100
a) The vulnerability disclosure measures are documented.

b) The vulnerability disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description and assessment of the vulnerabilities.

c) The vulnerability disclosure measures ensure a timely distribution of mitigation measures.

TJ3.1 The tester shall examine, for consistency and completeness:

 The response to Requirement J3 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section J3 of the PCI PTS POI Vendor Questionnaire.

TJ3.2 The tester shall examine the referenced documentation to assess the vendor‘s vulnerability disclosure measures.
Removed p. 101
d) The security guidance describes the responsibilities of application developers, system integrators and end-users of the platform.

TJ4.1 The tester shall examine, for consistency and completeness:

 The response to Requirement J4 of the PCI PTS POI Security Requirements,  The vendor‘s response, and the referenced documentation, in Section J4 of the PCI PTS POI Vendor Questionnaire.

TJ4.3 The tester shall examine the referenced documentation to assess whether the guidance ensures that application developers, system integrators and end-users of the platform are clearly and correctly guided into the secure use of the update mechanism.
Modified p. 101 → 123
a) The update mechanism ensures confidentiality, integrity, server authentication and protection against replay by using an appropriate, and declared, security protocol. If the device allows software and/or configuration updates, the device cryptographically authenticates the update and if the authenticity is not confirmed, the update is rejected and deleted.
a) The update mechanism ensures security i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol.
Modified p. 101 → 123
b) The platform vendor puts the security guidance for updating deployed platforms at the disposal of application builders, system integrators and end-users of the platform.
d) The security guidance describes the responsibilities of application developers, system integrators and end-users of the device.
Modified p. 101 → 123
c) The security guidance covers the update of firmware, applications, certificates and keys.
c) The security guidance covers the update of firmware, payment and non-payment applications, forms, multimedia files, configuration files, certificates and keys.
Modified p. 101 → 123
e) The security guidance ensures that deployed platforms are timely and securely updated.
e) The security guidance describes how updates to deployed devices are timely and secure.
Modified p. 101 → 123
TJ4.2 The tester shall examine the referenced documentation to assess the vendor‘s update mechanism.
TJ3.3 The tester shall assess the device maintenance documentation to ensure the declared terminal update solution is present, which must:
Modified p. 102 → 125
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 K16.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 authenticated applications (per K15.1).
Removed p. 103
The tester may perform any test needed to validate the attack scenario. The tester shall determine the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
Modified p. 103 → 126
All methods of card-data entry supported by the PED must be assessed. This includes both contactless and any manual PAN-entry modes that are natively supported by the SRED firmware. The path for contactless data must be secured to 16 points from the point of digitization of this data.
All methods of card-data entry supported by the device must be assessed. This includes both contactless and any manual PAN-entry modes that are natively supported by the SRED firmware. The path for contactless data must be secured to 16 points from the point of digitization of this data.
Modified p. 103 → 126
TK1.1.1 The tester shall examine the vendor‘s response to Section K1.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.1 of the PCI PTS POI Security Requirements for consistency relevant to K1.1.
TK1.1.1 The tester shall examine the vendor’s response to Section K1.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.1 of the PCI PTS POI Security Requirements for consistency relevant to K1.1.
Modified p. 103 → 126
TK1.1.2 The tester will verify that all testing procedures specified for Requirement D1 for chip data and A10 for magnetic-stripe data in the core physical requirements have been satisfied in relation to the protection of account data.
TK1.1.2 The tester shall verify that all testing procedures specified for Requirement D1 for chip data and A9 for magnetic-stripe data in the core physical requirements have been satisfied in relation to the protection of account data.
Modified p. 103 → 126
TK1.1.5 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 attack potential calculation shall be based on the scheme depicted in Appendix B.
TK1.1.5 The tester shall develop attack scenarios to penetrate the device to make any additions, substitutions, or modifications to either the device hardware or software, in order to determine or modify any account data, with an attack potential of at least 16 per device for identification and initial exploitation, with a minimum of 8 for exploitation. (Note that MSRs and ICCRS must meet the attack potentials stipulated in DTRs A9 and D1 respectively). The tester shall detail where costing information …
Modified p. 104 → 128
The objective of this requirement is to assess those terminals where the card reader is integrated into the final solution and to ensure that that as an integrated device it does not create any new weaknesses or permit new attack methods to be used against the data.
The objective of this requirement is to assess those terminals where the card reader is integrated into the final solution and to ensure that as an integrated device it does not create any new weaknesses or permit new attack methods to be used against the data.
Modified p. 104 → 128
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•e.g., 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. 104 → 128
TK2.1 The tester shall examine the vendor‘s response to Section K2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement 2 of the PCI PTS POI Security Requirements for consistency relevant to K2.
TK2.1 The tester shall examine the vendor’s response to Section K2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement 2 of the PCI PTS POI Security Requirements for consistency relevant to K2.
Modified p. 104 → 128
TK2.2 The tester will verify that all testing procedures specified for Requirement A2 in the core physical requirements have been satisfied in relation to the protection of account data.
TK2.2 The tester shall verify that all testing procedures specified for Requirement A2 in the core physical requirements have been satisfied in relation to the protection of account data.
Removed p. 105
The vendor may need to supply specific test software to the evaluation laboratory to enable rigorous side channel attack analysis to be performed.

Account data protection keys resident in the device or its components means plain-text secret or private keys.

TK3.1 The tester shall examine the vendor‘s response to Section K3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K3 of the PCI PTS POI Security Requirements for consistency relevant to K3.

TK3.3 The tester shall develop attack scenarios to determine any account data-security- related cryptographic key resident in the device either by penetration or by monitoring emanations from the device. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. The calculation shall be based on the scheme depicted in Appendix B. If an attack scenario can be developed that yields an attack potential of …
Modified p. 105 → 129
TK3.2 The tester shall examine any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
TK3.2 The tester shall examine and cite any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
Modified p. 106 → 132
TK3.1.1 The tester shall examine the vendor‘s response to Section K3.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K3.1 of the PCI PTS POI Security Requirements for consistency relevant to K3.1.
TK3.1.1 The tester shall examine the vendor’s response to Section K3.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K3.1 of the PCI PTS POI Security Requirements for consistency relevant to K3.1.
Modified p. 106 → 132
TK3.1.2 The tester shall verify that plain-text public keys only exist within a certificate or a secure cryptographic device and that it is not possible to illegitimately substitute one key for another.
TK3.1.2 The tester shall verify that plaintext public keys only exist within a certificate or a secure cryptographic device and that it is not possible to illegitimately substitute one key for another.
Modified p. 106 → 132
Public keys not stored in certificates or in a secure cryptographic device must be stored encrypted, or have a MAC (Message Authentication Code) created using the algorithm defined in ISO 16609:2004, in order to ensure authenticity and integrity.
Public keys not stored in certificates or in a secure cryptographic device must be stored encrypted, or have a MAC (Message Authentication Code) created using the algorithm defined in ISO 16609, in order to ensure authenticity and integrity.
Modified p. 106 → 132
The tester may perform any test needed to validate the attack scenario. The tester will use his or her judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
The tester may perform any test needed to validate the attack scenario. The tester shall use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory, and why.
Modified p. 107 → 133
All account data shall be encrypted using only ANSI X9 or ISO approved encryption algorithms (e.g., AES, TDES). The encryption algorithm should use a mode of operation described in ISO/IEC 10116:2006 (or equivalent) and follow secure padding guidelines. Any method used to produce encrypted text that relies on ―non-standard‖ modes of operations (e.g., format-preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (e.g., a standards body) and subjected to independent expert review; such …
All account data shall be encrypted using only ANSI X9 or ISO approved encryption algorithms (for example, AES, TDES). The encryption algorithm should use a mode of operation described in ISO/IEC 10116:2006 (or equivalent) and follow secure padding guidelines. Any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format- preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (for example, a standards body) and subjected to …
Modified p. 107 → 133
TK4.1 The tester shall examine the vendor‘s response to Section K4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K4 of the PCI PTS POI Security Requirements for consistency relevant to K4.
TK4.1 The tester shall examine the vendor’s response to Section K4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K4 of the PCI PTS POI Security Requirements for consistency relevant to K4.
Modified p. 107 → 133
TK4.3 In the event of a non-standard mode of operation being used, the tester shall examine documented credentials of the expert reviewer and assess his/her ability to perform the review. The tester shall also examine documentation supporting the assertion of independence of review and confirm that the reviewer is indeed independent. The tester will use his or her judgment in determining the appropriate due diligence.
TK4.3 In the event of a non-standard mode of operation being used, the tester shall examine documented credentials of the expert reviewer and assess his/her ability to perform the review. The tester shall also examine documentation supporting the assertion of independence of review and confirm that the reviewer is indeed independent. The tester shall use his or her judgment in determining the appropriate due diligence, and explain this.
Modified p. 107 → 133
TK4.5 The tester shall examine all core physical and core logical test requirements that relate to cryptographic keys used to protect PIN and/or other sensitive data and ensure that equivalent protections (including key-management guidance) are applied to cryptographic keys used for account data protection.
TK4.5 The tester shall examine all core physical and core logical test requirements that relate to cryptographic keys used to protect account data and/or other sensitive data and ensure that equivalent protections (including key-management guidance) are applied to cryptographic keys used for account data protection.
Modified p. 108 → 135
If an identity-based scheme is used, pair-wise keys may be ―exchanged‖ using a non- interactive process.
If an identity-based scheme is used, pair-wise keys may be “exchanged” using a non-interactive process.
Modified p. 108 → 135
TK5.1 The tester shall examine the vendor‘s response to Section K5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K5 of the PCI PTS POI Security Requirements for consistency relevant to K5.
TK5.1 The tester shall examine the vendor’s response to Section K5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K5 of the PCI PTS POI Security Requirements for consistency relevant to K5.
Modified p. 109 → 136
TK6.1 The tester shall examine the vendor‘s response to Section K6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K6 of the PCI PTS POI Security Requirements for consistency relevant to K6.
TK6.1 The tester shall examine the vendor’s response to Section K6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K6 of the PCI PTS POI Security Requirements for consistency relevant to K6.
Modified p. 110 → 137
The use of a single secret key deployed to numerous devices introduces unacceptable vulnerabilities into the payment chain. Should a single device be compromised, all data encrypted from devices which share a common key may be decrypted.
The use of a single secret key deployed to numerous devices introduces unacceptable vulnerabilities into the payment chain. Should a single device be compromised, all data encrypted from devices that share a common key may be decrypted.
Modified p. 110 → 137
TK7.1 The tester shall examine the vendor‘s response to Section K7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K7 of the PCI PTS POI Security Requirements for consistency relevant to K7.
TK7.1 The tester shall examine the vendor’s response to Section K7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K7 of the PCI PTS POI Security Requirements for consistency relevant to K7.
Modified p. 110 → 137
TK7.2 The tester shall verify that there is a negligible probability that two devices share a secret key. The tester shall examine any relevant documentation such as a user guide or the API programmer‘s guide, submitted by the vendor to verify that it supports vendor responses.
TK7.2 The tester shall verify that there is a negligible probability that two devices share a secret key. The tester shall examine any relevant documentation such as a user guide or the API programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified p. 110 → 137
TK7.3 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the implemented key generation, key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
TK7.3 The tester shall examine any additional documentation (for example, API reference, design documentation, key-management specification) that describes the implemented key generation, key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
Modified p. 111 → 138
Account data encryption keys shall only be used to encrypt account data. Key-encrypting keys shall only be used to encrypt keys. Account data keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt account data.
Account-data encryption keys shall only be used to encrypt account data. Key-encrypting keys shall only be used to encrypt keys. Account data keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt account data.
Modified p. 111 → 138
The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus the integrity check applies when the device is initially loaded with these keys. Session keys (working keys such as data, and MAC keys) or key- encipherment keys subsequently downloaded during normal operations must be randomly generated, and there should only be collisions (duplication) by chance.
The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus the integrity check applies when the device is initially loaded with these keys. Session keys (working keys such as data, and MAC keys) or key-encipherment keys subsequently downloaded during normal operations must be randomly generated, and there should only be collisions (duplication) by chance.
Modified p. 111 → 138
Any key calculated as a variant of another key shall be protected in a manner equivalent to or greater in security as the original key.
Any key calculated as a variant of another key shall be protected in a manner equivalent to or greater in security as the original key•i.e., under the principles of dual control and split knowledge.
Modified p. 111 → 138
TK8.1 The tester shall examine the response to Section K8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K8 of the PCI PTS POI Security Requirements for consistency relevant to K8.
TK8.1 The tester shall examine the response to Section K8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K8 of the PCI PTS POI Security Requirements for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses..
Modified p. 111 → 138
TK8.2 The tester shall examine any additional documentation such as the API programmer‘s guide, submitted by the vendor to verify that it supports vendor responses.
TK8.2 The tester shall examine and cite any additional documentation such as the API programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified p. 111 → 138
TK8.3 The tester shall verify the following:
The tester shall verify the following:
Modified p. 111 → 138
a) Account data encryption keys are only used to encrypt account data and transaction relevant information.
a) Account-data encryption keys are only used to encrypt account data and transaction- relevant information.
Modified p. 111 → 138
c) Account data encryption keys shall never be used to encrypt keys.
c) Account-data encryption keys shall never be used to encrypt keys.
Modified p. 111 → 139
TK8.4 The tester shall verify by testing that the device enforces that data keys, key- encipherment keys, and PIN-encryption keys have different values, e.g., by attempting to load keys of different types with effectively the same value.
TK8.4 The tester shall verify by testing that the device enforces that data keys, key-encipherment keys, and PIN-encryption keys have different values•for example, by attempting to load keys of different types with effectively the same value. The tester shall attempt to load two keys of the same value into the POI, and detail the results. If unsuccessful, the tester shall attempt to load two keys that vary only in the parity bits but produce the same key value. The tester …
Modified p. 112 → 140
K11.1 and K12 address application loads and firmware, application, and configuration updates. K9 is intended to address other types of administration activities, such as those more prevalent with unattended devices. In any case, unless there is not any impact (e.g., the load itself is cryptographically authenticated at the target), a secure session should be established (e.g., TLS) for those communications.
K11.1 and K12 address application loads and firmware, application, and configuration updates. K9 is intended to address other types of administration activities, such as those more prevalent with unattended devices. In any case, unless there is not any impact (for example, the load itself is cryptographically authenticated at the target), a secure session should be established (for example, TLS) for those communications.
Modified p. 113 → 141
TK10.1 The tester shall examine the response to Section K10 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the firmware documentation and certification process, for consistency.
TK10.1 The tester shall examine the response to Section K10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K10 of the PCI PTS POI Security Requirements manual for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
Modified p. 113 → 141
The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.
TK10.2 The tester shall examine the support documentation submitted by the device vendor. The documents should be representative of a Configuration Control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.
Modified p. 113 → 141
TK10.4 The tester will verify that the device displays or otherwise makes available the revision number.
TK10.4 The tester shall verify and demonstrate that the device displays or otherwise makes available the revision number.
Removed p. 114
Firmware is considered to be any code within the device that provides security protections needed to comply with these requirements. In certain instances, the test houses may request copies of source code for review of specific functions.

The device must perform an internal self-test automatically at least once every day, in addition to at power-up. It is acceptable to perform firmware integrity checks before each account data encryption transaction as opposed to performing them at least once every 24 hours. Self-tests after several minutes of inactivity may also be used, rather than once every 24 hours, in addition to power-up self-tests.

Software integrity tests may include techniques such as SHA-2 or equivalent. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption).

The device controller is in scope only if it impacts one or more of the security requirements, e.g., display prompt control.

SHA-1, LRC, CRC, and other non-cryptographic methods are not allowed …
Modified p. 115 → 144
TK11.1.1 The tester shall examine the vendor‘s response to Section K11.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K11.1 of the PCI PTS POI Security Requirements to verify that the device enforces that only authenticated applications and application/configuration updates can be loaded onto the device.
TK11.1.1 The tester shall examine the vendor’s response to Section K11.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K11.1 of the PCI PTS POI Security Requirements to verify that the device enforces that only authenticated applications and application/configuration updates can be loaded onto the device.
Modified p. 115 → 144
TK11.1.6 The tester shall determine the rank of protection strength for the component involved in application loads

•and if applicable, software and/or configuration updates

•and that the authentication is performed by an appropriate component TK11.1.7 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:
TK11.1.6 The tester shall determine the rank of protection strength for the component involved in application loads

•and if applicable, software and/or configuration updates

•and that the authentication is performed by an appropriate component TK11.1.7 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 D.
Modified p. 116 → 147
 That it is not possible for applications to be influenced by logical anomalies which could result in clear-text data being outputted whilst the terminal is in encrypting mode.
 That it is not possible for applications to be influenced by logical anomalies that could result in clear-text data being outputted whilst the terminal is in encrypting mode.
Modified p. 116 → 147
TK11.2.1 The tester shall examine the vendor‘s response to Section K11.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K11.2 of the PCI PTS POI Security Requirements to verify that the device enforces that only authenticated applications can be loaded onto the device.
TK11.2.1 The tester shall examine the vendor’s response to Section K11.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K11.2 of the PCI PTS POI Security Requirements to verify that the device enforces that only authenticated applications can be loaded onto the device.
Modified p. 117 → 148
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.
Modified p. 117 → 148
TK12.1 The tester shall examine the response to Section K12 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the authentication procedures for firmware updates, for consistency.
TK12.1 The tester shall examine the response to Section K12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K12 of the PCI PTS POI Security Requirements manual for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
Modified p. 117 → 148
TK12.7 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:
TK12.7 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 D.
Modified p. 118 → 151
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of the device’s relevant components.
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of all of the device’s relevant components.
Modified p. 118 → 151
Vendors should provide software design rules and specifications to support answers.
Vendors should provide software-design rules and specifications to support answers.
Modified p. 118 → 151
The device controller is not in scope for this requirement.
The device controller is not in scope for this requirement for unattended devices.
Modified p. 118 → 151
TK13.1 The tester shall examine the vendor‘s response to Section K13 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K13 of the PCI PTS POI Security Requirements to verify that the relevant component‘s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data that could result in the relevant component‘s outputting the clear-text account …
TK13.1 The tester shall examine the vendor’s response to Section K13 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K13 of the PCI PTS POI Security Requirements for consistency to verify that the relevant component’s functionality shall not be influenced by logical anomalies such as (but not restricted to): unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying invalid parameters or data that could result in the relevant component’s outputting the …
Modified p. 118 → 151
TK13.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the relevant component‘s logical structure, the interface specification, the software design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TK13.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the relevant component’s logical structure, the interface specification, the software-design rules and specifications, or the software implementation submitted by the vendor, etc., to verify that it supports the vendor responses.
Modified p. 118 → 151
TK13.3 The tester shall analyze the vendor‘s measures that ensure that the relevant component‘s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
TK13.3 The tester shall analyze the vendor’s measures that ensure that the relevant component’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified p. 118 → 152
TK13.4 The tester may perform tests needed to validate the device‘s property. The evaluator should use his or her own judgment in determining appropriate tests. Test support shall be provided by the vendor as needed to access and use the interfaces under test.
TK13.14 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified p. 119 → 153
All security requirements and corresponding testing requirements specified in Sections H and J of DTR Module 3: Open Protocols Requirements shall be met.
Weak implementations of IP stacks, and/or ancillary IP services can act as attack vectors into a device. All security requirements and corresponding testing requirements specified in Sections F, G, H, and I of DTR Module 3: Open Protocols Requirements shall be met.
Modified p. 119 → 153
TK14.1 The tester shall examine all responses to Sections H and J of the PCI PTS POI Evaluation Vendor Questionnaire and the responses to Sections H and J of the PCI PTS POI Security Requirements for consistency.
TK14.1 The tester shall examine all responses to Sections F, G, H, and I of the PCI PTS POI Evaluation Vendor Questionnaire and the responses to Sections F, G, H and I of the PCI PTS POI Security Requirements for consistency.
Modified p. 119 → 153
TK14.2 The tester will verify that all testing procedures specified in Sections H and J of DTR Module 3: Open Protocols Requirements have been met.
TK14.2 The tester shall verify that all testing procedures specified in Sections F, G, H, and I of DTR Module 3: Open Protocols Requirements have been met.
Removed p. 120
Weak implementations of IP stacks and/or ancillary IP services can act as attack vectors into a platform. All security requirements and corresponding testing requirements specified in Sections F, G, and I of DTR Module 3: Open Protocols Requirements shall be met.

TK15.1 The tester shall examine all responses to Sections F, G, and I of the PCI PTS POI Evaluation Vendor Questionnaire and the responses to Sections F, G, and I of the PCI PTS POI Security Requirements for consistency.

TK15.2 The tester will verify that all testing procedures specified in sections F, G, and I of DTR Module 3: Open Protocols Requirements have been met.
Modified p. 121 → 154
TK16.1 The tester shall examine the response to Section K16 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the output of clear-text PANs for consistency.
TK15.1 The tester shall examine the response to Section K15 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K15 of the PCI PTS POI Security Requirements manual for consistency relating to the output of clear-text PANs.
Modified p. 121 → 154
TK16.2 The tester shall examine any additional documentation (i.e., API programmer‘s guide, specifications, block diagrams, etc.) that contains information that relates to the output of clear-text cardholder data and sensitive authentication data to determine whether it supports the assertions made by the vendor.
TK15.2 The tester shall examine any additional documentation (i.e., API programmer’s guide, specifications, block diagrams, etc.) that contains information that relates to the output of clear- text cardholder data and sensitive authentication data to determine whether it supports the assertions made by the vendor.
Modified p. 121 → 154
TK16.3 The tester shall examine any log or trace files generated by the device to determine whether they support the assertions made by the vendor.
TK15.3 The tester shall examine any log or trace files generated by the device to determine whether they support the assertions made by the vendor.
Modified p. 121 → 154
TK16.4 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions do not reveal or otherwise affect sensitive information.
TK15.4 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions do not reveal or otherwise affect sensitive information.
Modified p. 121 → 154
TK16.5 The tester shall verify from vendor documentation and from functional testing that changing modes of operation requires cryptographic authentication.
TK15.5 The tester shall verify from vendor documentation and from functional testing that changing modes of operation requires cryptographic authentication.
Modified p. 122 → 155
TK16.8 If the device allows for a change of modes between encrypting and non-encrypting, the tester shall verify that:
TK15.8 If the device allows for a change of modes between encrypting and non-encrypting, the tester shall verify that:
Modified p. 122 → 155
 The authorization implements the principles of dual control,  Sensitive information required for the authorization (e.g., passwords or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device,  An authorized switch must provide traceability and accountability.
 The authorization implements the principles of dual control,  Sensitive information required for the authorization (for example, passwords or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device,  An authorized switch must provide traceability and accountability.
Modified p. 123 → 156
TK16.1.1 The tester shall examine the vendor‘s response to Section K16.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K16.1 of the PCI PTS POI Security Requirements to verify:  That clear-text account data is only output to authenticated applications;  How the applications are authenticated.
TK15.1.1 The tester shall examine the vendor’s response to Section K15.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K15.1 of the PCI PTS POI Security Requirements to verify:
Modified p. 123 → 156
TK16.1.2 The tester shall examine any relevant documentation, including vendor test results for how applications are authenticated, the user guide, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TK15.1.2 The tester shall examine any relevant documentation, including vendor test results for how applications are authenticated, user guides, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 123 → 156
TK16.1.3 The tester will verify that the vendor has identified all data that is provided to authenticated applications.
TK15.1.3 The tester shall verify that the vendor has identified all data that is provided to authenticated applications.
Removed p. 124
TK16.2.3 The tester will verify that the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive account data is included. Passwords, plain-text cryptographic keys, or key components outside of the crypto-processor, and account data are included.

The tester will determine the appropriate test actions to be taken. For instance, by performing a partial simulated transaction to verify the behavior at time-out, or in general by entering the states that have been defined by the vendor under DTR K16.
Modified p. 124 → 157
The terminal must automatically ensure that full track data (or chip equivalent) and sensitive authentication data is cleared when either:  The transaction is completed, or  The terminal has timed out waiting for the response from the cardholder or merchant.
The terminal must automatically ensure that full track data (or chip equivalent) and sensitive authentication data is cleared when either:
Modified p. 124 → 157
TK16.2.1 The tester shall examine the vendor‘s response to Section K16.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K16.2 of the PCI PTS POI Security Requirements to verify:
TK15.2.1 The tester shall examine the vendor’s response to Section K15.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K15.2 of the PCI PTS POI Security Requirements to verify:
Modified p. 124 → 157
 That account data shall not be present any longer or used more often than strictly necessary;  That the device automatically clears its internal buffers when either the transaction is completed or the device has timed out waiting for the response from the cardholder, merchant or authorization service. The vendor must specify the states ―completion of transaction‖ and ―timeout‖ and define the appropriate actions.
 That account data shall not be present any longer or used more often than strictly necessary;  That the device automatically clears its internal buffers when either the transaction is completed or the device has timed out waiting for the response from the cardholder, merchant or authorization service. The vendor must specify the states “completion of transaction” and “timeout” and define the appropriate actions.
Modified p. 124 → 157
TK16.2.2 The tester shall examine any relevant documentation, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TK15.2.2 The tester shall examine and cite any relevant documentation, including vendor test results for inspections of internal buffers, user guides, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 124 → 157
TK16.2.4 The tester will verify that all data is automatically cleared when either the transaction is completed or the device has timed out waiting for the response from the cardholder, merchant or authorization service.
The transaction is completed, or  The terminal has timed out waiting for the response from the cardholder or merchant.
Modified p. 125 → 159
TK17.1 The tester shall examine the response to Section K17 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K17 of the PCI PTS POI Security Requirements for consistency relevant to K17.
TK16.1 The tester shall examine the response to Section K16 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K16 of the PCI PTS POI Security Requirements for consistency relevant to K16.
Modified p. 125 → 159
TK17.2 The tester shall examine any additional documentation (i.e. specifications, schematics, block diagrams, etc.) that contains information that relates to surrogate value creation to determine whether it supports the assertions made by the vendor.
TK16.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to surrogate value creation to determine whether it supports the assertions made by the vendor.
Modified p. 125 → 159
TK17.3 If a cryptographic key or algorithm is used to generate surrogate values, the tester shall examine the vendor-supplied documentation to verify that the controls utilize algorithms and/or key sizes appropriate for the surrogate creation mechanism in question.
TK16.3 If a cryptographic key or algorithm is used to generate surrogate values, the tester shall examine the vendor-supplied documentation to verify that the controls utilize algorithms and/or key sizes appropriate for the surrogate creation mechanism in question.
Modified p. 126 → 160
TK17.1.1 The tester shall examine the response to Section K17.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K17.1 of the PCI PTS POI Security Requirements for consistency relevant to K17.1.
TK16.1.1 The tester shall examine the response to Section K16.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K16.1 of the PCI PTS POI Security Requirements for consistency relevant to K16.1.
Modified p. 126 → 160
TK17.1.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor responses.
TK16.1.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor responses.
Modified p. 126 → 160
TK17.1.3 The tester shall verify test information provided by the vendor to assess whether the random numbers are sufficiently unpredictable. The tester shall use a suitable test method (for example, those listed in NIST PUB 800-22).
TK16.1.3 The tester shall verify test information provided by the vendor to assess whether the random numbers are sufficiently unpredictable. The tester shall use a suitable test method (for example, those listed in NIST PUB 800-22).
Modified p. 126 → 160
TK17.1.4 The tester shall verify by testing that the device generates salt values with a minimum length of 64-bits.
TK16.1.4 The tester shall verify by testing that the device generates salt values with a minimum length of 64-bits.
Modified p. 127 → 161
TK17.2.1 The tester shall examine the response to Section K17.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K17.2 of the PCI PTS POI Security Requirements for consistency relevant to K17.2.
TK16.2.1 The tester shall examine the response to Section K16.2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K16.2 of the PCI PTS POI Security Requirements for consistency relevant to K16.2.
Modified p. 127 → 161
TK17.2.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to surrogate value creation to determine whether it supports the assertions made by the vendor. The vendor responses should clearly indicate that salt data is maintained in the protected area(s) of the device; and that sensitive information and functions dealing with salt data are protected from modification.
TK16.2.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to surrogate value creation to determine whether it supports the assertions made by the vendor. The vendor responses should clearly indicate that salt data is maintained in the protected area(s) of the device; and that sensitive information and functions dealing with salt data are protected from modification.
Modified p. 128 → 162
TDES key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret-sharing scheme, e.g., Shamir. Private key components shall be combined using a recognized secret-sharing scheme.
TDES key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret-sharing scheme, for example, Shamir. Private key components shall be combined using a recognized secret-sharing scheme.
Modified p. 128 → 162
For all TDEA modes of operation, the three cryptographic keys (K1, K2, K3) define a TDEA key bundle (see X9.24). The bundle and the individual keys must:  Be secret;  Be generated randomly or pseudo-randomly;  Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;  Be used in the appropriate order as specified by the particular mode;  …
For all TDEA modes of operation, the three cryptographic keys (K1, K2, K3) define a TDEA key bundle (see X9.24). The bundle and the individual keys must:
Modified p. 128 → 162
TR-31 support or equivalent must use a key derivation methodology. The device may optionally support, in addition, the key calculation methodology.
TR-31 support or equivalent must use a key-derivation methodology. The device may optionally support, in addition, the key calculation methodology.
Modified p. 128 → 162
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods. Any binding or unbinding of key- usage information from the key must take place within the secure cryptographic boundary of the device.
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods. Any binding or unbinding of key-usage information from the key must take place within the secure cryptographic boundary of the device.
Removed p. 129
TK18.5 The tester shall determine from vendor documentation that the device provides support for a configuration option using TR-31 or an equivalent methodology for symmetric key distribution, and optionally, key storage. The tester shall determine that the TR-31 or equivalent configuration uses a key derivation methodology. The device may optionally support, in addition, the key calculation methodology.
Modified p. 129 → 163
a) When entering plain-text secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally …
a) When entering plaintext secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally …
Modified p. 129 → 163
b) For injecting plain-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 PINs/passwords before injecting the plain-text key into the device. (Note: This may be the entire key•if components, each component requires a separate password.) Passwords/PINs are at least five characters. These passwords are entered directly through the keypad of the applicable device or are conveyed encrypted …
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 PINs/passwords before injecting the plaintext key into the device. (Note: This may be the entire key•if components, each component requires a separate password.) Passwords/PINs are at least seven characters or an equivalent strength. These passwords are entered directly through the keypad of the applicable device …
Modified p. 129 → 163
Injection of plain-text secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (e.g., multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Injection of plaintext secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.
Modified p. 129 → 163
TK18.2 The tester shall examine any relevant documentation such as a user guide or the API programmer‘s guide, submitted by the vendor to verify that it supports vendor responses.
TK17.2 The tester shall examine and cite any relevant documentation such as a user guide or the API programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified p. 129 → 163
TK18.3 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of Unique Key(s) per device.
TK17.3 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of Unique Key(s) per device.
Modified p. 129 → 163
TK18.4 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the implemented key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
TK17.4 The tester shall examine any additional documentation (for example, API reference, design documentation, key-management specification) that describes the implemented key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
Modified p. 129 → 163
TK18.6 The tester shall verify that the loading of private and secret keys uses one or more of the following methods. (Note: EPPs intended for use in an unattended environment shall only support methods a, c, and d.)
TK17.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods. (Note: EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d.)
Removed p. 130
The following are the minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange or establishment:

Minimum key size in number of bits: 112 2048 224 2048/224 128 DES 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.

For Diffie-Hellman implementations:

 Entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity generates …
Modified p. 130 → 164
d) Remote key loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements.
d) Remote key-loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements.
Modified p. 130 → 164
TK18.7 If a public-key technique for the distribution of symmetric secret keys is used, it
If a public-key technique for the distribution of symmetric secret keys is used, it must:
Modified p. 130 → 164
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 2048-bits minimum for RSA, see also DTR B16.2).
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA, see also DTR B16.2).
Removed p. 132
TK18.10 The tester shall determine from vendor documentation how (e.g., active or passive erasure) each key is destroyed for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.
Modified p. 133 → 168
 Use of a unique key per transaction technique. (Prevents the attack.)  Limiting the rate at which the device will encrypt PANs. (Deters the attack.) E.g., the function would be a maximum of the throughput that could be achieved through the physical interface during intended usage.
 Use of a unique key per transaction technique. (Prevents the attack.)  Limiting the rate at which the device will encrypt PANs. (Deters the attack.) For example, the function would be a maximum of the throughput that could be achieved through the physical interface during intended usage.
Modified p. 133 → 168
TK19.1 The tester shall examine the response to Section K19 of the PCI PTS POI Evaluation Vendor Questionnaire relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PAN determination.
TK18.1 The tester shall examine the response to Section K18 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K18 of the PCI PTS POI Security Requirements manual for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PAN determination.
Modified p. 133 → 168
TK19.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to characteristics that prevent or significantly deter exhaustive PAN determination to determine whether it supports the assertions made by the vendor.
TK18.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to characteristics that prevent or significantly deter exhaustive PAN determination to determine whether it supports the assertions made by the vendor.
Modified p. 133 → 168
TK19.3 The tester shall perform functional testing to verify the device characteristics regarding K19.
TK18.3 The tester shall perform functional testing to verify the device characteristics regarding K18.
Removed p. 134
―Immediate‖ is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.

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•e.g., where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.
Removed p. 134
TK20.1 The tester shall examine the response to Section K20 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K20 of the PCI PTS POI Security Requirements for consistency relevant to K20.

TK20.2 The tester shall examine any relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.

TK20.3 The tester shall identify the device components applicable to this requirement.

TK20.4 The tester shall verify the existence and design of any mechanisms asserted by the vendor to protect any physical access ports and/or to prevent immediate access to information like account and cryptographic data. This will be accomplished by disassembling the device and examining the mechanisms.

TK20.5 For each of the applicable device components, the tester shall attempt to remove the access cover by disabling or defeating the tamper-detection mechanisms. To remove the cover the tester may open, pry, or otherwise disassemble …
Removed p. 136
TK21.2 The tester shall examine any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc., submitted by the vendor to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions.

TK21.3 The tester shall verify that the vendor‘s stated measures protect against the compromise of the device by altering either environmental conditions or operational conditions, and assess the adequateness of the vendor test procedures and reports.
Modified p. 136 → 169
TK21.1 The tester shall examine the response to Section K21 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K21 of the PCI PTS POI Security Requirements manual for consistency relevant to Requirement K21. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions.
TK19.1 The tester shall examine the response to Section K19 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K19 of the PCI PTS POI Security Requirements manual for consistency relevant to Requirement K19. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.
Modified p. 136 → 170
TK21.4 The tester shall develop attack scenarios to compromise the device by altering environmental and or operational conditions.
TK19.10 The tester shall develop attack scenarios to compromise the device by altering operational conditions, and consider whether altering environmental conditions may be used to develop attacks.
Modified p. 136 → 170
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.
Modified p. 137 → 171
Applications are considered to be separated by access rights. OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined with B1.
OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined with B1.
Modified p. 137 → 171
TK22.1 The tester shall examine the vendor‘s response to Section K22 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K22 of the PCI PTS POI Security Requirements to verify that if the device supports multiple applications, it enforces the separation between applications with security impact from those without security impacts. Furthermore, the tester shall examine which part of the firmware is considered OS, and which part is considered as application with security impact.
TK20.1 The tester shall examine the vendor’s response to Section K20 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K20 of the PCI PTS POI Security Requirements to verify that if the device supports multiple applications, it enforces the separation between applications with security impact from those without security impacts. Furthermore, the tester shall examine which part of the firmware is considered OS, and which part is considered as application with security impact. The tester …
Modified p. 137 → 171
TK22.2 The tester shall examine any relevant documentation, such as the user guide, specification of the device‘s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TK20.2 The tester shall examine and cite any relevant documentation, such as user guides, specification of the device’s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 137 → 172
TK22.3 The tester shall analyze the vendor‘s measures that ensure that the device enforces the separation between applications with security impact from those without security impacts. The tester will verify that it is not possible that one application interferes or tampers with another application or the OS of the device

•especially to access, use, or modify data objects belonging to another application

•even if they are distributed over separate components of the device.
TK20.4 The tester shall analyze the vendor’s measures that ensure that the device enforces the separation between applications with security impact from those without security impacts. The tester shall verify that it is not possible that one application interferes or tampers with another application or the OS of the device

•especially to access, use, or modify data objects belonging to another application

•even if they are distributed over separate components of the device.
Modified p. 137 → 172
TK22.4 If the OS and / or any application with security impact are distributed over separate components of the device, the tester will verify that the communication in between separated parts is consistent with the separation mechanisms as described by the vendor. The vendor shall provide evidence concerning the communication in between the separated parts and how the communication protocols maintain the separation of applications with security impact from those without security impacts.
TK20.6 If the OS and/or any application with security impact are distributed over separate components of the device, the tester shall verify that the communication in between separated parts is consistent with the separation mechanisms as described by the vendor. The vendor shall provide evidence concerning the communication in between the separated parts and how the communication protocols maintain the separation of applications with security impact from those without security impacts.
Removed p. 138
TK23.3 The tester shall verify that all components and services indicated in the configuration list are necessary for the intended operation. For that purpose, the vendor shall provide a configuration list that shows all OS components and other software with an explanation of their purpose and a rationale for their presence.
Modified p. 138 → 174
The intended operation is considered as the functionality relevant to B2. For multi- application devices, the intended operation furthermore includes the operation of applications without security impacts.
For multi-application devices, the intended operation furthermore includes the operation of applications without security impacts.
Modified p. 138 → 174
O/S modules such as, for example, peripheral drivers, file systems, or inter-process communication protocols shall be regarded as components. Applications responding to external interfaces or communicating with the firmware shall be regarded as services.
OS modules such as, for example, peripheral drivers, file systems, or inter-process communication protocols shall be regarded as components. Applications responding to external interfaces or communicating with the firmware shall be regarded as services.
Modified p. 138 → 174
TK23.1 The tester shall examine the vendor‘s response to Section K23 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement BK23 of the PCI PTS POI Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation.
TK21.1 The tester shall examine the vendor’s response to Section K21 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K21 of the PCI PTS POI Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation. The tester shall summarize the responses.
Modified p. 138 → 174
TK23.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the device‘s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TK21.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 138 → 174
TK23.4 The tester shall verify that the operating system is enforcing least privilege.
The tester shall verify that the operating system is enforcing least privilege.
Modified p. 138 → 174
TK23.5 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.
TK21.3 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.
Modified p. 138 → 174
TK23.6 The tester shall verify that API functionality and commands that are not required to support specific functionality are removed whenever possible or disabled if removal is not feasible.
TK21.4 The tester shall verify that API functionality and commands that are not required to support specific functionality are removed whenever possible or disabled if removal is not feasible.
Modified p. 138 → 174
TK23.7 The tester will examine the methods and tools provided by the vendor, which ensure that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the O/S.
TK21.5 The tester shall examine the methods and tools provided by the vendor, which ensure that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the OS.
Removed p. 139
TK24.3 The tester shall verify from vendor documentation that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.

TK24.4 The tester shall verify from vendor documentation and from functional testing that sensitive services require authentication.

TK24.5 The tester shall verify from vendor documentation and from functional testing that entering and exiting sensitive services does not reveal or otherwise affect sensitive information.

TK24.6 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified p. 139 → 176
A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc.
A sensitive service (state) allows the execution of functions that are not available during normal use• for example, load a master key, delete stored transactions, alter device configuration, etc.
Modified p. 139 → 176
TK24.1 The tester shall examine the vendor‘s response to Section K24 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K24 of the PCI PTS POI Security Requirements for consistency relevant to K24.
TK22.1 The tester shall examine the vendor’s response to Section K22 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K22 of the PCI PTS POI Security Requirements for consistency relevant to K22. The vendor responses should clearly indicate how sensitive services are protected. The tester shall summarize the responses.
Modified p. 139 → 176
TK24.2 The tester shall examine any relevant documentation (such as an API user guide) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services.
TK22.2 The tester shall examine and cite any relevant documentation (such as an API user guide) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services.
Removed p. 140
TK25.5 The tester shall verify that a time limit is imposed such that after one minute of inactivity while accessing sensitive services, the device returns to its normal state. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded.

TK25.6 The tester shall verify that a time limit is imposed such that fifteen (15) minutes after accessing sensitive services, the device returns to its normal mode. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded. To prevent the device from reaching a limit of inactivity, sensitive functions will be used throughout the fifteen minutes.
Modified p. 140 → 178
TK25.1 The tester shall examine the vendor‘s response to Section K25 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K25 of the PCI PTS POI Security Requirements for consistency relevant to K25.
TK23.1 The tester shall examine the vendor’s response to Section K23 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K23 of the PCI PTS POI Security Requirements for consistency relevant to K23. The vendor responses should clearly indicate how limits are implemented appropriately. The tester shall summarize the responses.
Modified p. 140 → 178
TK25.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses.
TK23.2 The tester shall examine and cite any relevant documentation, such as user guides or the software specification, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 140 → 178
TK25.3 The tester shall examine the rationale provided by the vendor in Section K25 of the
TK23.3 The tester shall examine the rationale provided by the vendor in Section K23 of the PCI PTS POI Evaluation Vendor Questionnaire to verify the following:
Modified p. 140 → 178
TK25.4 The tester shall verify the limits placed on the number of actions by causing the device to access sensitive services and attempting to exceed the limit. Once the limit is exceeded the tester will verify that the device has returned to its normal mode.
TK23.4 The tester shall verify the limits placed on the number of actions by causing the device to access sensitive services and attempting to exceed the limit. Once the limit is exceeded the tester shall verify that the device has returned to its normal mode.
Modified p. 143 → 200
: Angle between the vertical plane through the ‗5‘ key and a virtual line which connects the ‗5‘ key and an observer‘s eye b: Horizontal position of an observer relative to the PIN entry device‘s position g: Horizontal range which is to be covered by the privacy screen : Angle between the keypad plane and the horizontal plane Design rules:
: Angle between the vertical plane through the “5” key and a virtual line which connects the “5” key and an observer’s eye b: Horizontal position of an observer relative to the PIN entry device’s position g: Horizontal range which is to be covered by the privacy screen : Angle between the keypad plane and the horizontal plane Design rules:
Modified p. 143 → 200
1. These definitions apply to a privacy shield, which is provided as design property by the device. It may be a part of the PIN entry device, or provided by the device‘s cabinet. The rules and the figures above are to be considered as guidelines, which may be replaced by other means of at least the same efficiency.
1. These definitions apply to a privacy shield, which is provided as design property by the device. It may be a part of the PIN entry device, or provided by the device’s cabinet. The rules and the figures above are to be considered as guidelines, which may be replaced by other means of at least the same efficiency.
Modified p. 143 → 200
2. The keypad reference point is taken as the column position in the middle of the keypad in the row containing the numeric key ‗5.‘
2. The keypad reference point is taken as the column position in the middle of the keypad in the row containing the numeric key “5.”
Modified p. 143 → 200
5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a touch screen, the viewing barrier may be implemented by polarizers (e.g., as film on the touch screen surface), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.
5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a touch screen, the viewing barrier may be implemented by polarizers (for example, as film on the touch screen surface), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.
Modified p. 145 → 202
: Angle between the horizontal plane through the ‗5‘ key and a virtual line which connects the ‗5‘ key and an observer‘s eye b: Horizontal position of an observer relative to the PIN entry device user‘s position g: Horizontal range which is to be covered by the privacy screen : Angle between the keypad plane and the horizontal plane
: Angle between the horizontal plane through the “5” key and a virtual line which connects the “5” key and an observer’s eye b: Horizontal position of an observer relative to the PIN entry device user’s position g: Horizontal range which is to be covered by the privacy screen : Angle between the keypad plane and the horizontal plane
Modified p. 146 → 203
5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a touch screen, the viewing barrier may be implemented by polarizers (e.g., as film on the touch screen surface), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.
5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a touch screen, the viewing barrier may be implemented by polarizers (for example, as film on the touch screen surface), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.
Modified p. 146 → 203
2. A handheld device must by weight, size, and shape encourage its handheld operation. The criteria are:
2. A handheld device must by weight, size, and shape encourage its handheld operation. The criteria
Modified p. 146 → 203
b) Width at the ‗5‘ key should not be more than three (3) inches or 7.62 cm;
b) Width at the “5” key should not be more than three (3) inches or 7.62 cm;
Modified p. 146 → 203
c) Sum of width and height at the ‗5‘ key should not be more than four (4) inches or 10.16 cm; and
c) Sum of width and height at the “5” key should not be more than four (4) inches or 10.16 cm; and
Modified p. 146 → 203
If the device‘s properties clearly fall outside these ranges, it will not be accepted as a handheld device for purposes of this test. A handheld device must by its size and case shape encourage its handheld use. Being small may not be sufficient. Even if the device is small, if the standing and/or mounting support indicate that the PIN entry device is to be installed on a swivel arm or a similar apparatus, it will be considered as a desktop …
If the device’s properties clearly fall outside these ranges, it will not be accepted as a handheld device for purposes of this test. A handheld device must by its size and case shape encourage its handheld use. Being small may not be sufficient. Even if the device is small, if the standing and/or mounting support indicate that the PIN entry device is to be installed on a swivel arm or a similar apparatus, it will be considered as a desktop …
Modified p. 147 → 204
Note: This option does not preclude the use of privacy mechanisms as defined in A1, but allows less restrictive physical mechanisms, e.g.,   20°.
Note: This option does not preclude the use of privacy mechanisms as defined in A1, but allows less restrictive physical mechanisms, for example,   20°.
Modified p. 147 → 204
• Visual shields designed into the check-stand. The shields may be solely for shielding purposes, or may be part of the general check-stand design, e.g., used as selling area.
• Visual shields designed into the check-stand. The shields may be solely for shielding purposes, or may be part of the general check-stand design, for example, used as selling area.
Removed p. 149
b) Potential to acquire the required knowledge of the PIN entry device‘s design and operation;

d) Equipment required like instruments, components, IT hardware, software required for the
Modified p. 149 → 206
In this document, ―exploitation‖ and ―initial exploitation‖ are alternatively used to designate ―initial exploitation.‖ Factors to be Considered The following factors should be considered for the analysis of the attack potentials required to exploit vulnerability:
In this document, “exploitation” and “initial exploitation” are alternatively used to designate “initial exploitation.” Factors to be Considered The following factors should be considered for the analysis of the attack potentials required to exploit vulnerability:
Modified p. 149 → 206
b) Potential to acquire the required knowledge of the PIN entry device‘s design and operation;
b) Potential to acquire the required knowledge of the PIN entry device’s design and operation;
Modified p. 149 → 206
In many cases these factors don‘t depend on each other but might be substituted for each other in varying degrees. For example, expertise or hardware/software can be a substitute for time. A discussion of these factors follows.
In many cases these factors don’t depend on each other but might be substituted for each other in varying degrees. For example, expertise or hardware/software can be a substitute for time. A discussion of these factors follows.
Modified p. 149 → 206
The attack time is given in the time in hours taken by an attacker to identify or exploit an attack. If the attack consists of several steps, the attack time can be determined and added to achieve a total attack time for each of these steps. Actual labor time must be used instead of time expired as long as there is not a minimum attack time enforced by the attack method applied (for instance, the time needed for performing a …
The attack time is given in the time in hours taken by an attacker to identify or exploit an attack. If the attack consists of several steps, the attack time can be determined and added to achieve a total attack time for each of these steps. Actual labor time must be used instead of time expired as long as there is not a minimum attack time enforced by the attack method applied (for instance, the time needed for performing a …
Modified p. 150 → 207
Expertise refers to the level of generic knowledge of the application area or product type (e.g., Unix operation systems, Internet protocols). Identified levels are as follows:
Expertise refers to the level of generic knowledge of the application area or product type (for example, Unix operation systems, and Internet protocols). Identified levels are as follows:
Modified p. 150 → 207
c) Laymen are unknowledgeable compared to experts or proficient persons, with no particular expertise. For the purpose of exploitation, they can implement an attack based on a script or a written procedure, without requiring any particular skill.
c) Laymen are unknowledgeable compared to experts or proficient persons, with no particular expertise. For the purpose of exploitation, they can implement an attack-based on a script or a written procedure, without requiring any particular skill.
Modified p. 150 → 207
If proficient expertise on various areas of technology is required for an attack, e.g., on electrical engineering and cryptography, an expert level of expertise can be assumed.
If proficient expertise on various areas of technology is required for an attack, for example, on electrical engineering and cryptography, an expert level of expertise can be assumed.
Modified p. 150 → 207
a) Public information about the PIN entry device (or no information): Information is considered public if it can be easily obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer.
a) Public information about the PIN entry device (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.
Modified p. 150 → 207
b) Restricted information concerning the PIN entry device (e.g., as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (e.g., like the PCI PTS POI DTRs).
b) Restricted information concerning the PIN entry device (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (for example, like the PCI PTS POI DTRs).
Modified p. 150 → 207
c) Sensitive information about the PIN entry device (e.g., knowledge of internal design, which may have to be obtained by ―social engineering‖ or exhaustive reverse engineering).
c) Sensitive information about the PIN entry device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
Modified p. 150 → 207
Specialist expertise and knowledge of the PIN entry device are concerned with the information required for persons to be able to attack a PIN entry device. There is an implicit relationship between an attacker‘s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker‘s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this …
Specialist expertise and knowledge of the PIN entry device are concerned with the information required for persons to be able to attack a PIN entry device. There is an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this …
Modified p. 150 → 207
Access to the PIN entry device is also an important factor. It is assumed here that the PIN entry device would be purchased or otherwise obtained by the attacker and that beside other factors there‘s no time limit in analyzing or modifying the PIN entry device. Differences are defined in the status and functionality of the device to be analyzed/tested.
Access to the PIN entry device is also an important factor. It is assumed here that the PIN entry device would be purchased or otherwise obtained by the attacker and that beside other factors there is not any time limit in analyzing or modifying the PIN entry device. Differences are defined in the status and functionality of the device to be analyzed/tested.
Modified p. 150 → 207
b) Functional samples without working keys might be used for the logical and electrical behavior of the device but aren‘t loaded with working keys and are therefore not functional within a payment network or with real payment cards. Such devices might be regularly purchased. Please note that these also include devices fitted with test or dummy keys.
b) Functional samples without working keys might be used for the logical and electrical behavior of the device but are not loaded with working keys and are therefore not functional within a payment
Modified p. 151 → 208
 Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•e.g., at a nearby store or downloaded from the Internet. The equipment might consist of simple attack scripts, personal computers, card readers, pattern generators, simple optical microscopes, power supplies, or simple mechanical tools.
 Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•for example, at a nearby store or downloaded from the Internet. The equipment might consist of simple attack scripts, personal computers, card readers, pattern generators, simple optical microscopes, power supplies, or simple mechanical tools.
Modified p. 151 → 208
 Specialized equipment isn‘t readily available to the attacker, but could be acquired without undue effort. This could include purchase of moderate amounts of equipment (e.g., dedicated electronic cards, specialized test bench, protocol analyzers, oscilloscopes, microprobe workstation, chemical workbench, precise milling machines, etc.) or development of more extensive attack scripts or programs.
 Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort. This could include purchase of moderate amounts of equipment (for example, dedicated electronic cards, specialized test bench, protocol analyzers, oscilloscopes, microprobe workstation, chemical workbench, precise milling machines, etc.) or development of more extensive attack scripts or programs.
Modified p. 151 → 208
 Bespoke equipment is not readily available to the public, as it might need to be specially produced (e.g., very sophisticated software), or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered in the exploitation phase.
 Bespoke equipment is not readily available to the public, as it might need to be specially produced (for example, very sophisticated software), or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered in the exploitation phase.
Modified p. 152 → 209
If the same equipment used for the identification phase can be reused for exploitation, it may not be accounted twice. In such case, the cost of equipment can be divided by two and spread equally over identification and exploitation.
If the same equipment used for the identification phase can be reused for exploitation, it may not be accounted for twice. In such case, the cost of equipment can be divided by two and spread equally over identification and exploitation.
Modified p. 153 → 210
Rating Success of an Attack If the difficulty of implementation an attack is sufficiently high, resulting in the attack to succeed on a limited number of targets, multiple devices can be considered, given the following limitations.
Rating Success of an Attack If the difficulty of implementing an attack is sufficiently high, resulting in the attack being likely to succeed on a limited number of targets, multiple devices can be considered, given the following limitations.
Modified p. 153 → 210
To reflect this matter of fact, the number of target devices (i.e. functional samples with working keys in the exploitation phase) can be multiplied using the following factors:
To reflect this matter of fact, the number of target devices (i.e., functional samples with working keys in the exploitation phase) can be multiplied using the following factors:
Modified p. 153 → 210
Table 2: Success Rate Multiplying Factor Probability of success Factor 0.5 > P  0.25 1.5 P < 0.25 2 When determining the probability, each step of the attack must be divided in likely independent phases with a featured probability. The overall probability is obtained by multiplying all factors together.
Table 2: Success Rate Multiplying Factor Probability of success Factor 0.5 > P  0.25 1.5 P < 0.25 2 When determining the probability, each step of the attack must be divided into likely independent phases with a featured probability. The overall probability is obtained by multiplying all factors together.
Modified p. 153 → 210
An Approach to Calculation The above section identifies the factors to be considered. The table below gives guidelines for the individual factors. When a factor falls close to a boundary, the evaluator should consider use of an intermediate value to those in the table.
An Approach to Calculation The above section identifies the factors to be considered. The table below gives guidelines for the individual factors. When a factor falls close to a boundary, the tester should consider use of an intermediate value to those in the table.
Modified p. 153 → 210
For a given attack it might be necessary to make several passes through the table for different attack scenarios (e.g., trading off expertise for time or equipment). The lowest value obtained for these passes should be retained. In the case of a vulnerability that has been identified and is in the public domain, the identifying values should be selected for an attacker to uncover that attack scenario in the public domain, rather than to initially identify it.
For a given attack it might be necessary to make several passes through the table for different attack scenarios (for example, trading off expertise for time or equipment). The lowest value obtained for these passes should be retained. In the case of a vulnerability that has been identified and is in the public domain, the identifying values should be selected for an attacker to uncover that attack scenario in the public domain, rather than to initially identify it.
Modified p. 155 → 212
2. A bug is customized to monitor the keypad signals and record PIN entry. In this example, scanning technique is simple, therefore the following levels apply: Expert, 30 hours‘ work, standard parts, standard equipment, and reusing the same mechanical sample.
2. A bug is customized to monitor the keypad signals and record PIN entry. In this example, the scanning technique is simple, therefore the following levels apply: Expert, 30 hours’ work, standard parts, standard equipment, and reusing the same mechanical sample.
Modified p. 155 → 212
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Restricted Standard 1 working with testing keys 40 hours As a summary for the identification phase, the following would apply:
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Restricted Standard 1 working with test keys 40 hours As a summary for the identification phase, the following would apply:
Modified p. 155 → 212
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Restricted Standard 1 mechanical 1 working with testing keys
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Restricted Standard 1 mechanical 1 working with test keys
Modified p. 156 → 213
While the attack is scripted, it nevertheless requires good mechanical skills and practice to successfully implement. Therefore, the level of expertise is considered as ―proficient.‖ Expertise Equipment Knowledge Parts Samples Time needed Proficient Standard (reused) Public None 1 working with keys P(success) = 0.94 ≈ 0.66
While the attack is scripted, it nevertheless requires good mechanical skills and practice to successfully implement. Therefore, the level of expertise is considered as “proficient.” Expertise Equipment Knowledge Parts Samples Time needed Proficient Standard (reused) Public None 1 working with keys P(success) = 0.94 ≈ 0.66
Modified p. 156 → 213
2. Once inside, the attack needs to reach sensitive signals (e.g., key scanning signals) located within a deeper layer of the terminal, protected by other, harder to defeat, tamper-detection mechanisms.
2. Once inside, the attack needs to reach sensitive signals (for example, key scanning signals) located within a deeper layer of the terminal, protected by other, harder to defeat, tamper-detection mechanisms.
Removed p. 157
 A function of the PIN entry device is used which requires a PIN to be entered for every execution of the cryptographic action with the key under attack;  The data used for DPA can be acquired at an external interface of the PIN entry device, e.g., the PIN entry device needs not be further physically attacked to get the required test data; and that  The PIN entry device does not have effective countermeasures against DPA.

2. Develop the attack set-up including the control to run the PIN entry device in an automated way.

Since a large number of PIN entries are required, which can hardly be performed manually, special mechanics must be developed to perform the PIN entries. This is bespoke equipment, developed specially for this attack, which will be used for both Identification and Exploitation.

3. Get a PIN entry device and perform the measurement. We expect that at …
Modified p. 157 → 214
Table 4: Attack Potential for Inserting a PIN-Disclosing Bug Aspect Identifying Value Exploiting Value Attack time ≤ 160h 5 ≤ 24 h 3 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to PIN entry device 1 mechanical sample 1 working sample without working key 4 Functional sample with working keys P(success) ≈ 0.52 Equipment Standard 1 Specialized 3 Specific parts Standard 1 Standard 1 Attack potential per phase 17 15 Total Attack Potential 32 …
Table 4: Attack Potential for Inserting a PIN-Disclosing Bug Aspect Identifying Value Exploiting Value Attack time ≤ 160h 5 ≤ 24 h 3 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to PIN entry device 1 mechanical sample 1 working sample without working keys 3 Functional sample with working keys P(success) ≈ 0.52 Equipment Standard 1 Specialized 3 Specific parts Standard 1 Standard 1 Attack potential per phase 16 15 Total Attack Potential 31 …
Modified p. 157 → 214
The attack would consist of the following steps:
The attack consists of the following steps:
Modified p. 157 → 214
1. Determine the method to run DPA on a PIN entry device. This consists mostly of analyzing the electrical and logical interface. This step requires professional knowledge of electronic and computer engineering.
1. Determine methods to record DPA data from the device. This consists mostly of analyzing the electrical signals and logical (I/O data) interface. This step requires expert knowledge of electronic/computer engineering.
Modified p. 157 → 214
4. Analyze the data samples and retrieve the PIN-encrypting key.
4. Analyze the data samples and retrieve the PIN-encrypting key, applying side-channel cryptanalysis techniques to achieve key exposure.
Removed p. 159
A note on sts versions: Prior to version of 1.7, the Discrete Fourier Transform (Spectral) test was conducted using the incorrect peak height threshold value (called T in Section 2.6.4 of SP 800-22) and calculated the normalized difference (d) incorrectly. In order to use an older version of the sts tool, the corrections described in [Kim 2004] should be implemented for this test. In versions 1.7 and later, these corrections are already included.

All tests other than the Lempel-Ziv test should be run [0] (for later versions of sts, the Lempel-Ziv test is normally inaccessible).
Modified p. 159 → 216
The tester should request and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor-supplied data is interpreted correctly by the sts tool (the sts tool assumes that binary data is in big-endian formatting on all platforms).
The tester should request and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor-supplied data is interpreted correctly by the STS tool (the STS tool assumes that binary data is in big-endian formatting on all devices).
Modified p. 159 → 216
The sts testing on the data shall be judged as a "pass" if it passes all of the tests, for both the "Proportion of Sequences Passing a Test" interpretation approach and "Uniform Distribution of P-Values" interpretation approach. If the data does not pass all tests, and the failure is marginal, the tester should acquire additional data from the vendor and repeat the testing, including both the initial data and the additional vendor-supplied data.
The STS testing on the data shall be judged as a "pass" if it passes all of the tests, for both the "Proportion of Sequences Passing a Test" interpretation approach and "Uniform Distribution of P-Values" interpretation approach. If the data does not pass all tests, and the failure is marginal, the tester should acquire additional data from the vendor and repeat the testing, including both the initial data and the additional vendor-supplied data.
Modified p. 159 → 216
The sts tool should be configured as per guidance provided in SP800-22, which is summarized below.
The STS tool should be configured as per guidance provided in SP 800-22 Revision 1a, which is summarized below.
Modified p. 159 → 216
The following settings are consistent with the SP800-22 document:
The following settings are consistent with the SP 800-22 Revision 1a document:
Modified p. 159 → 216
Configuration Item Setting Length of bit streams (n) 1,000,000 [1] Number of bit streams (sample size) (M) 1,073 [2] Block Frequency block length 20,000 [3] Non-Overlapping Templates template length 10 [4] Overlapping Template template length 10 [4] Universal block length (L), number of initialization steps (Q) L=7, Q=1,280 [5] Approximate Entropy block length 8 [6] Serial block length 16 [7] Linear Complexity block length 1,000 [8]
Configuration Item Setting Reference in Length of bit streams (n) 1,000,000 [1] Number of bit streams (sample size) (M) 1,073 [2] Block Frequency block length 20,000 [3] Non-Overlapping Templates template length 9 [4] Overlapping Template template length 9 [5] Universal block length (L), number of initialization steps (Q) L=7, Q=1,280 [6] Approximate Entropy block length 8 [7] Serial block length 16 [8] Linear Complexity block length 1,000 [9]
Removed p. 160
[Rukhin 2004] Rukhin, Andrew (NIST). E-mail correspondence regarding Kim, et al, paper.

[Kim 2004] Kim, Song-Ju, et al., "Corrections of the NIST Statistical Test Suite for Randomness." [Bassham 2004] Bassham, Larry (NIST). "Validation Testing and NIST Statistical Test Suite" presentation dated July 22, 2004.

[Hill 2004] Hill, Joshua (InfoGard Labs). "ApEn Test Parameter Selection."
Modified p. 160 → 217
[3] For the Block Frequency Test, if n=106, the test block size should be set between 104 and 106. (See SP800-22 Section 2.2.7.) [4] The two template tests (Non-Overlapping and Overlapping tests) both require selection of a template length of 9 or 10 in order to produce meaningful results. (See SP800-22 Sections 2.7.7 and 2.8.7.) [5] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP800-22 Section 2.9.7. For n=106, the only …
[3] For the Block Frequency test, if n=106, the test block size should be set between 104 and 106. (See SP800-22r1a Section 2.2.7.) [4] The Non-Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. (See SP800-22r1a Sections 2.7.7 and 2.8.7.) For a template length of 10, the MAXNUMOFTEMPLATES constant (in defs.h) should be set to at least 284 prior to compiling STS, otherwise most 10 bit aperiodic templates with a leading …
Modified p. 160 → 217
[6] For the Approximate Entropy (ApEn) test, SP800-22 Section 2.13.7 requires the block length to be less than [log2 n] - 2, however the sts tool warns if the block size is greater than [log2 n] - 5 (which is consistent with the information in Section 4.3 f). Other analysis [Hill 2004] has shown that for n=1,000,000 values block lengths greater than 8 can cause failures more often than expected for large scale testing.
[7] For the Approximate Entropy (ApEn) test, SP800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for large scale testing.
Modified p. 160 → 217
[7] The Serial Test block length is also set based on n. If n=106, the block length must be less than 17.
[8] The Serial Test block length is also set based on n. If n=106, the block length must be less than 17.
Modified p. 160 → 217
(See SP800-22 Section 2.12.7) [8] The Linear Complexity Test block length is required to be set to between 500 and 5,000 (inclusive), and requires that . (See SP800-22 Section 2.11.7.) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,‖ NIST SP800-22, revisions dated May 15, 2001.
(See SP800-22r1a Section 2.11.7.) [9] The Linear Complexity test block length is required to be set to between 500 and 5,000 (inclusive), and requires that . (See SP800-22r1a Section 2.10.7.) References [Rukhin 2010] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP 800-22, Revision 1a.