Document Diff - PCI Watch

Added p. 3

June 2020 6.0

• Restructured Modules.

• Added appendices for Domain-Based Asset Flow Analysis and Evaluation Guidance for CPUs.

• Modification of Visual Observation Deterrents criteria.

• Eliminated Removal Detection requirements.

• Added required support for ECC for POI devices that accept IC cards.

• Split requirement A1 into two separate requirements:

1) Tamper-Detection Mechanisms 2) Protection of Sensitive Keypad Inputs

• Split requirement A6 into two separate requirements:

1) Invasive Attacks for Cryptographic Keys 2) Non-invasive Attacks for Cryptographic Keys.

• Allow the inclusion of MSRs in SCRPs for use in SPoC solutions.

Added p. 8

• DTR Module 3: Communications and Interfaces

• At the beginning of the report, a list of all documentation, including DTR sections and Technical FAQs version used during the evaluation

• For each DTR, the DTR definition and guidance (if any), followed by the sequence of all DTR work items (e.g., TA1.1, TA1.2, TA1.3, … etc.), directly preceding the report’s explanations on each item. Cited DTRs text shall match the current DTRs version and shall be clearly distinguishable from Laboratory-generated report text. ‘N/A’ verdicts shall be clearly identifiable as such.

• Proofs of the reliability of testing reused between devices having similar characteristics;

• Justifications for any reliance on test evidence derived from devices other than the device under test;

• Explanations for any conclusions based on theoretical analysis instead of applied testing.

Where test evidence from prior evaluations is being reused, the similarities and differences between the prior and current devices must be detailed. Evidence …

Added p. 11

Re-use of test results for PTS POI v6.x evaluations is only allowed where the evidence is no older than the last prior major version⎯i.e., v5.x or other v6.x reviews may supplement work done in the current review.

Asset Flow Analysis The purpose of the Asset Flow Analysis is to describe in block-diagram form how assets travel within the device (both logically and physically) and are protected as they are processed and manipulated by it. The Asset Flow Analysis does not have to be provided as a single flow diagram. It can be made up from several flow diagrams so long as it is clear how each flow diagram is interconnected and/or interrelated.

Within the Asset Flow Analysis, appropriate domains are assigned for each logical and physical component in the device including software modules, hardware components, and PCB tracks (which may be grouped if several tracks combine a bus). The tester then uses …

Added p. 15

TA1.7 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.8 The tester shall describe what testing was performed to validate the protection provided by each of the tamper switches enumerated above.

TA1.20 For SCRPs, the tester shall validate that the SCRP is capable of providing information to a query from the PIN CVM application to indicate if in a tamper state.

Added p. 17

Keypads used for PIN entry require an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for exploitation, exclusive of the IC card reader, as defined in Appendix B.

Keypads used for manual PAN entry, but not PIN entry

•e.g., a non-PED

•require an attack potential of at least 16 per device for identification, with a minimum of 8 points for exploitation.

Sensitive keypads are defined as those through which clear-text PINs or manual PANs can be entered.

Protection of manual PAN entry is only applicable if the device is being assessed against the SRED feature.

When designing an attack against the device, replacement of casing parts like the front and rear case of the device shall be considered as part of the overall attack.

A2 allows the evaluator to use any method of attack feasible against the terminal limited only by the attack potential of 26 in …

Added p. 22

TA4.4 Using the information from the table above, the tester shall provide details on the different integrated circuits (memory, processors, programmable logic etc.) that are used to store, process, or secure sensitive information.

c) Unused features and programming that should be disabled.

Added p. 24

The attack is considered successful if any PIN digit is discovered.

Secret or private cryptographic keys that are never used to encrypt or decrypt data (e.g., keys, accounts, PINs), or are not used for authentication, do not need to be considered secret data and therefore are not subject to this requirement.

All physical and logical protections shall be evaluated and reported. Only protections that can be demonstrated as both enabled and efficacious shall be used to determine attack potential.

e) Describe why invasive and/or glitch attacks intending to change flags (e.g., flipping a bit value enabling a defense) are effectively obstructed.

Added p. 27

• The steps needed in any penetration.

• Attacks involving some or all of attacks modeled elsewhere. For example, DTRs A1, A2, A4, and A7 (but not restricted thereto) must be considered and included in this attack, if relevant.

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

Added p. 28

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), allowing the evaluator to perform analysis with direct access to security-relevant processor(s).

Where a device exclusively supports DUKPT or similar unique-key-per-transaction methodology for the protection of sensitive data, such as PINs, static-key statistical side-channel analysis using large batches of recordings does not need to be applied for these keys.

Secret or private cryptographic keys that are never used to encrypt or decrypt data⎯e.g., keys, accounts, PINs⎯or are not used for authentication, do not need to be considered secret data and therefore are not subject to this requirement.

Notwithstanding physical protections (which may be validated by other DTRs), approved devices must not contain cryptographic implementations which, under analysis, can be straightforwardly compromised …

Added p. 29

TA7.1 The tester shall identify and show in a table:

• A list of all PIN security-related cryptographic keys (secret and private) that may be directly attacked by side-channel analysis approaches. For SRED devices this includes account- data-security-related cryptographic keys. This list shall indicate whether the most applicable approach is statistical analysis of static keys with variable inputs or outputs, or other approaches such as, but (not restricted to) timing analysis.

• A list of all PIN security-related keys that may be indirectly attacked by side-channel analysis•for example, keys that may be attacked following additional attack steps. For SRED devices this includes account-data-security-related cryptographic keys.

• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as unique keys per operation or other constraints on exercising static key values or any other algorithmic constraints on SCA attacks.

TA7.2 The tester shall check the evidence provided by the vendor on the implemented cryptographic …

Added p. 30

The tester shall describe any assistance provided by the vendor to ensure efficient side- channel testing•for example command scripts, event triggers, access to the processor, etc.

TA7.5 The tester shall justify the methodologies used and findings, in accordance with Appendix F and with regard to published attacks. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device.

Justifications of these to be reported shall include, but are not restricted to:

• Equipment used, and a summary of test parameters such as collection elapsed time and analysis elapsed time,

• Whether the attack can be feasible at any distance away from the processor,

• The number of sample recordings acquired,

• Sampling frequencies,

• Signal analysis / filtering techniques,

• Correlation function(s) used,

• How optimum quality data collection was achieved, etc.

• How adequate key selection function coverage was applied.

Evidence to support this shall include …

Added p. 31

The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no older than the last prior major version (i.e., v5.x or other v6.x reviews may supplement work done in the current review) of the PCI POI Security Requirements prior to the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A7 security requirements.

TA8.5 The tester shall explain how the POI is protected against display attacks from each of all sides of the POI, including the front and rear of the device.

TA9.6 When a device is claimed as handheld, the tester shall enter details of the POI into the table below. Accurate measurements should be taken with the POI configured so that it is at the maximum size and weight it would have …

Added p. 36

Note: Contact chip is addressed in A13. Manual PAN entry is addressed in A2.

Protections must exist against attacks wherein a bug is installed on the opposite side of the card track of the original MSR such that the attacker would only capture card data if the cardholder swipes the card with the track side facing the wrong way. This is due to some MSRs that are intentionally designed to capture the track data regardless of which way the card is swiped. Thus, cardholders become conditioned to swiping the card from either side, even where the reader does not support.

As per the asset flow diagrams, all methods of card-data entry that are natively supported by the SRED firmware must be assessed. Magnetic stripe and contactless are addressed in this DTR. A device validated to SRED cannot have any card-reader types as part of the approved hardware and firmware version identifiers where …

Added p. 37

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

Added p. 38

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

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

If an attack scenario can be developed that requires an attack potential of less than 16 per device for identification and initial exploitation or less than 8 for initial exploitation per device as defined in Appendix B, the vendor assertion cannot be …

Added p. 39

The term “processed” is used as a generic term, which includes but is not limited to account-data encryption and the selective disclosure of clear-text account data by the secure controller to authenticated applications (per B23.1).

For an authenticated application:

• The application must reside and execute within the physically and logically secure boundary of the target of evaluation.

• The application must be cryptographically authenticated by the secure chip of the POI using algorithms and keys sizes consistent with those stipulated in B10.

The minimum that must be encrypted, if present, under SRED, is:

• Full track or equivalent (when aggregated as a single data element), including both Track 1 and Track 2;

• Manually entered security validation value (e.g., CVV2, CVC2, and CID2);

• Issuer discretionary data (as a single, unparsed field);

• Issuer discretionary data

• sensitive data (as a parsed field). Any or all portions of the discretionary data are considered to be sensitive unless known …

Added p. 40

TA12.1 The tester shall verify that all testing procedures specified for Requirement A1 in the physical requirements have been satisfied in relation to the protection of account data.

TA12.2 The tester shall examine the device to verify that the asserted protections exist, how they are effective, and how they conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test device when necessary.

Added p. 41

All contact points must be evaluated The ICC reader may be equipped with mechanical and/or optical mechanisms to meet this requirement when used in conjunction with the implementation guidance.

A PIN-disclosing bug shall be prevented from being inserted into the device through the card slot. The volume of space accessible via the card slot that could be utilized by an attacker can vary with the geometry of the space and attack methods. For this reason, the requirement does not prohibit or specify a maximum volume. Rather, the feasibility of effective bug placement is to be considered when assessing A13 compliance. Examples of these considerations are:

DTRs A1.4, A1.5, and A1.7 must be completed for the ICCR where any specific references to “PIN” are to be read as “account data.” TA13.1 The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor …

Added p. 42

TA13.5 The tester shall provide and reference a picture of the area of the POI where the ICC acceptor is located.

TA13.6 The tester shall provide and reference a picture of the ICC acceptor itself. The tester shall note the manufacturer and model of the acceptor used.

TA13.7 The tester shall detail any active detection mechanisms the ICC acceptor utilizes to prevent a “shim” from being left in the slot. Where active protections are not present, the tester shall provide an extract from the merchant document that details how the slot can be checked for such items on a daily basis.

TA13.8 The tester shall provide and reference a picture of the internal space of the ICC acceptor (this may require the disassembly of one or more acceptors). The tester shall note whether there is any area within the acceptor that is larger than 10mm x 10mm in area, and has a depth …

Added p. 43

TA13.14 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 signal with a probe, such as a metal pin (either straight or bent) inserted through a hole in the casing of the POI at any point.

TA13.15 From the above description the tester shall explain how the POI is rendered inoperative after a tamper event in the ICC-acceptor area.

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

TA13.17 The tester shall describe and provide a costing for the most feasible attack to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any …

Added p. 44

The intent of requirement A14 is to make successful installation of PIN-disclosing bugs via the card slot infeasible. To meet this requirement the cardholder must have at least the ability to inspect the entry. And where the slot is neither positioned straight towards the cardholder nor upward facing (i.e., it is downward facing), a design has to meet the following criteria:

• The ICCR slot entry area must be designed such that a cardholder has a full unlimited view of the housing surrounding the card slot opening. The card entry area should be extended to make it easier to observe the card slot area.

• The ICCR contacts must be strongly protected to prevent attachment of bug wires.

• There must not be any seams around the slot that can be used to hide wires.

• The ICCR slot internal sizes must not be sufficient to simultaneously insert two un-embossed cards and execute a …

Added p. 45

TA14.7 From the above information, the tester shall justify why it is not possible to pass a wire from the slot of the customer ICC acceptor without this wire being visible to the customer operating the POI.

Added p. 46

For firmware that is rarely executed, such as a boot block, it is acceptable to perform an integrity and authenticity check immediately prior to each execution, rather than every 24 hours. However, note that all firmware must additionally be checked as part of the self-test performed at startup.

Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must be either cryptographically protected using a key (for example, HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption). As such, an authenticity check will also confirm the integrity of the installed firmware, an additional integrity check is not necessary, but optionally may be additionally performed using a non-authenticated digest such as a CRC.

Internal generation of a cryptographic signature is valid right after firmware update, assuming it complies with Requirement B2; it is also valid for devices that do …

Added p. 47

Chip-level code delivered with a component that cannot be configured, modified, or changed by any standard interface, and where an error cannot compromise the security of the device, does not need to be validated against Requirement B1. Examples may include smart card controllers, keypad controllers, or modem firmware.

TB1.1 The tester shall describe the boot chain of the POI. The tester shall include how initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are sequenced, loaded, and executed, up to and including software modules used for PIN entry functions, account-data processing, and OP modules. The tester shall reference the relevant aspects of the asset flow in A1.

TB1.2 The tester shall verify that the device performs self-tests upon start up and on a periodic basis at least once per day to check firmware and security mechanisms for signs of tampering, and whether the device …

Added p. 48

Boot stage Algorithms and Key Sizes Used for Authentication Area/Code/Registers Authenticated Method and Frequency of Re-authentication Action Performed TB1.10 The tester shall confirm that the self-tests include validation of register settings relied upon for the security of the POI (for example, registers used to activate security features of the POI). The tester shall validate that these include checking of all features detailed and relied upon for compliance to the physical security requirements.

TB1.11 The tester shall perform testing to verify that the device reinitializes memory at least every 24 hours. The tester shall activate the mechanism and look for the result as shown by the device.

TB1.12 The tester shall review the source code of the POI to confirm how it is ensured that the re- initialization process is repeated every 24 hours or less.

TB1.13 The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.

Added p. 49

The update mechanism ensures security⎯i.e., integrity, mutual authentication, and protection against replay⎯by using an appropriate and declared security protocol when using a network connection.

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

• If firmware blocks have independent version numbers, the version number display should include the version number of each firmware block.

• If a single version number is used, a documented process must be used to ensure the single version number is updated whenever changes are made to any of the firmware blocks in the device.

This information shall be illustrated by photographic evidence provided in the evaluation report.

For SCRPs and SCRs intended for use with commercial-off-the-shelf devices⎯e.g., mobile phones and tablets⎯the SCRPs and SCRs must respond with their model name/number, hardware version, firmware version(s), and a unique device identifier to a query from the payment application on the COTS device.

If done between physically and logically disparate components, …

Added p. 50

TB2.2 The tester shall determine by which component the authentication is performed.

TB2.3 The tester shall determine the level of protection for the external component involved in firmware/software updates and that the authentication of firmware updates is performed by a component of equal or greater strength.

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

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

Added p. 51

TB2.9 If a CBC MAC is used for firmware authentication, the tester shall detail what methods are used to mitigate vulnerabilities when authenticating variable-length data.

TB2.10 For each of the methods of authentication, the tester shall obtain a correctly authenticated firmware image and:

b) Change a single bit in the authentication block for the entire image and confirm that this modified image is rejected when loaded into the POI.

c) Change a single bit in the firmware block of the image and confirm that this modified image is rejected when loaded into the POI.

TB2.11 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.

TB2.12 The tester shall verify and demonstrate …

Added p. 52

If the device allows software application and/or configuration updates, the device cryptographically authenticates updates consistent with B2.

TB2.1.1 The tester shall determine by which component the authentication is performed.

TB2.1.2 The tester shall determine the rank of protection strength for the component involved in application authentication, including configuration updatesand that the authentication is performed by an appropriate component TB2.1.3 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.

TB2.1.4 For each of the processing elements listed in DTR A4, the tester shall complete the following table. Where different parts of the code (for example, boot code, main firmware, etc.) can be updated independently, or if one part of the application cannot be updated, the tester shall …

Added p. 53

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

TB2.1.7 If (H)MAC method(s) are used for application authentication, the tester shall confirm through source-code review that the method used to compare the application-authentication block does not leak timing information•for example, the “C” memcmp() function is not used. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB2.1.8 If a CBC MAC is used for application authentication, the tester shall detail …

Added p. 54

• Software is only signed using a secure cryptographic device (e.g., smartcard) provided by the terminal vendor.

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

TB2.2.1 The tester shall verify that the signing process can only be performed under dual control and that the software is only signed using a secure cryptographic device provided by the vendor.

TB2.2.2 The tester shall verify that any unsigned executable file cannot launch and is deleted by the device. The tester shall detail the device response.

TB2.2.3 The tester shall validate the documented justification for each unsigned file to ensure the file cannot affect the security of the device and that the justification is complete and correct.

TB2.2.4 The tester may perform any additional analysis necessary to validate the device’s …

Added p. 60

Note: EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d. SCRPs shall only support the loading of encrypted keying material.

Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing secret keys, i.e., the invoking of the key- loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.

Passwords/authentication codes are at least seven characters or an equivalent strength. These passwords/authentication codes are entered directly through the keypad of the applicable device or are conveyed encrypted into the device. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired …

Added p. 61

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 a) and b) above.

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 Appendix D, “Configuration and Use of the STS Tool,” and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Appendix A of the PCI PIN Security Requirements. See below for further information.

Note: This applies to the loading of initial high-level (e.g., root) keys. …

Added p. 67

Note: Master/session is NOT a unique-key-per-transaction technique.

The average time delay between encryptions should be calculated for exhaustive attack to determine a single PIN value and is NOT averaged over attacks on multiple PINs.

TB8.3 If the previous areas of testing were negative, or have not been conducted, the tester shall detail the method used by the POI to ensure that it is not possible to encrypt more than 120 PINs in less than one hour of elapsed time.

POI devices used for IC card acceptance must have chipsets that support ECC and are enabled for use.

ECC functionality should support standard prime curves (at minimum the NIST recommended curves P-256 and P-521) and should include scalar multiplication of a point on the curve and prime field arithmetic (including exponentiation with full size exponent).

Symmetric key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret-sharing scheme, …

Added p. 70

• Changing or replacing any bit(s) in the attributes or encrypted key

• The review by the independent expert must include proof that in the equivalent method the encrypted key and its attributes in the key block have integrity protection such that it is computationally infeasible for the key to be used if the key or its attributes have been modified. Modification includes, but is not limited to:

• Interchanging any bits of the protected key block with bits from another part of the block

• The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. “Independent expert” is further defined below.

• The PTS laboratory will validate that any device vendors implementing this methodology have done so following all guidelines of said evaluation and peer review, including any recommendations for associated …

Added p. 73

TB9.8 If the POI implements an ICC reader, the tester shall detail which EMV-based keys are supported by the firmware. If EMV functions are provided by the application, the tester shall detail how offline PIN functions are provided, including how the PIN key of the customer ICC card is authenticated. The tester shall justify how the methods used are sufficient to prevent the application from accessing plaintext PINs.

TB9.10 The tester shall provide a key table for the POI, accurately including all of the keys and key- management methods outlined above. The key table shall include all PIN- or SRED-related keys used in the device, including but not limited to acquirer keys, software authentication keys, and storage of keys within the device. Cryptographic keys used for Open Protocol security must be listed in DTR D1. Keys that are not considered to be PIN or SRED security-related may either be listed in …

Added p. 76

• Key length TB9.21 The tester shall confirm that any key-block protection key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-key-block key- management scheme.

TB9.24 The tester shall confirm that for a device supporting remote key loading using asymmetric techniques using a “binding” technique, it supports an acceptable method for unbinding in the event of decommissioning.

TB9.26 If the device supports IC card acceptance, the tester shall validate that the device supports ECC as described in the guidance.

Added p. 77

All account data shall be encrypted using only ANSI X9 or ISO-approved encryption algorithms (for example, AES, TDES). The encryption algorithm should use a mode of operation described in ISO/IEC 10116:2006 (or equivalent) and follow secure padding guidelines. Any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format- preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (for example, a standards body) and subjected to independent expert review; such methods shall also be implemented following all guidelines of said evaluation and peer review including any recommendations for associated key management.

The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert qualifications are further defined in the glossary in the PTS POI Modular Security …

Added p. 79

TB10.4 The tester shall verify that cryptographic keys require compliance with PCI defined criteria for key sizes. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E, along with examples of acceptable hashing algorithms.

Added p. 80

The device must support at least one of the following key-management techniques using AES as described in ANSI X9.24 and ISO/IEC 18033-3:

• Master/Session TDES as described in ANSI X9.24 and ISO/IEC 18033-3 may also be supported using the following key-management techniques:

• Master/Session POI devices shall not support fixed key management for TDES or AES.

b) Where the ICC reader is not integrated into the PIN entry device, and PINs are enciphered only for transmission between the PIN entry device and the IC reader, the device shall use one of the PIN-block formats specified in ISO 9564-1. Where ISO format 2 PIN blocks are used, a unique-key-per-transaction method in accordance with ISO 11568 shall be used. Format 2 shall be used only in connection with either offline PIN verification or PIN-change operations in connection with ICC environments.

TB11.1 Through source-code review of all PIN entry methods, API guides, and other vendor documentation as …

Added p. 81

TB11.3 The tester shall confirm that SCRPs support the use of a unique-per-transaction, AES PIN- encryption key for conveyance of PINs from the PIN CVM application on the COTS device and detail the methods used to generate this key.

TB11.4 The tester shall detail all methods that the POI supports for external PIN transfer. This will include encryption of PINs for transport to an acquiring financial institution, as well as transfer to any external card readers or other devices/sub-components outside of the area of the POI validated as secure under Requirement A1.

TB11.5 From the above information, the tester shall confirm that if configured to use ISO PIN-block formats, the POI does not enforce the use of non-ISO-compliant PIN-block formats for any PIN- transfer mechanisms.

TB11.6 For each ISO-compliant PIN-block method supported by the POI, the tester shall perform a PIN entry operation and confirm that:

e) The application does not provide data for …

Added p. 82

The device must enforce that PIN encryption, account-data encryption, data-encryption keys and key-encipherment keys have different values.

Account-data encryption keys shall only be used to encrypt account data. Account-data encryption keys shall never be used to encrypt keys.

Note: The use of variants is not allowed for AES keys.

The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus, the uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded. The check must occur within all secret-key hierarchies supported by the device. No two secret keys, regardless of purpose, can have the same value. Keys that are identical except for parity bits must be rejected because they have the same effective value.

TB12.1 Through source-code review, the tester shall confirm what methods the POI device uses to confirm the purpose and integrity of …

Added p. 83

TB12.3 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 shall detail the results.

Added p. 84

TB13.1 The tester shall examine any documentation•i.e., the Asset Flow Analysis, API programmer’s guide, specifications, block diagrams, etc.•containing information relating to the output of clear-text keys and the protection of PINs, the encryption of a key or PIN under a key that might itself be disclosed, and the transfer of a key from a high-security component to a lower-security component TB13.2 Referencing the table of sensitive-information storage provided in Requirement A4, the tester shall note whether cryptographic keys, customer PINs, or other sensitive data are exported outside the security processor to other components (including memory components) within the POI. The tester shall justify why any such transfer of keys ensures that they remain secure.

TB13.3 The tester shall verify through review of the API guide and source-code review whether the POI allows for injection of customer PINs from an external device. If such functionality is provided by the device, the tester …

Added p. 85

For devices implementing at the same time a touchscreen for PIN entry and a separate keypad, these must have a default entry mode; switching to the other mode requires an explicit operation on the device, which remains valid for one transaction.

TB14.1 The tester shall review the source code and detail what protections are provided to ensure that only encrypted data (as verified in Requirement B11) can be output from the POI firmware when the POI is in a PIN entry mode. 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.

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

Added p. 86

A8 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.

B15 applies to both acquirer and vendor-controlled prompts that are updatable.

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

A device must automatically record events that are relevant to B15 to a file that is automatically saved. Because each device vendor solution will be unique, the data set that is appropriate to be included in a log file can vary. At a minimum, it is expected that actions that involve cryptographic operations, the user(s), and the time and date of the action will be recorded in the log file. The …

Added p. 87

Authenticity checking provided by TLS is not sufficient to meet B15. TLS is only designed to offer IP security; it does not provide security or integrity of the message interpretive content or context. I.e., it does not prevent message content code (such as HTML5, Java, Javascript, etc.) from requesting an input prompt.

Vendor- or acquirer-certified applications and/or data that are communicated using a managed PKI (in addition to TLS) are acceptable. However, the application and/or data provider must attest that the application and/or data does not contain instructions to make use of a prompt.

TB15.1 The tester shall examine all possible prompts to determine whether any can be used in conjunction with numeric entry in the clear.

TB15.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information on non-PIN data entry and prompts for non-PIN data entry, on data entry and erasure, and on how authentic user …

Added p. 88

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

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

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

• Applications must not share process spaces with each other or with the firmware.

It is acceptable for applications to be able to initiate changes to security functions, providing the firmware fully implements the authentication mechanisms. When password-based authentication is used, the firmware must manage the password entry and comparison.

Sensitive data in this requirement is defined as:

• Passwords/authentication codes

• PIN- …

Added p. 90

TB16.1 The tester shall note whether the POI allows for non-firmware code to be executed. If not, no further testing is necessary for this requirement.

TB16.2 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.

TB16.12 Using the Asset Flow Analysis, the tester shall describe the path of plaintext PINs from entry through to encryption or transfer to an IC card. Justification must be provided as to why applications cannot access buffers used to store plaintext PINs.

TB16.13 The tester shall describe the software module/s handling PIN- or SRED-related cryptographic keys. Memory …

Added p. 92

Software security domains and respective security requirements, in this context, are defined in Appendix G, “Domain-Based Asset Flow Analysis.” A vendor may choose to run all software inside a single domain, i.e., the key domain. In this case, the device is not considered to support applications, and all software is considered firmware, which must comply with all DTR relevant to firmware.

Please refer to Appendix G for a definition of “code” and what is considered software in the sense of this DTR.

If software security domains are supported, the vendor shall perform an asset flow analysis as described in Appendix G It shall at least identify all external interfaces of the device and describe the location and flow of all assets and asset containers in all modes of operation, including power-down and device boot, and for all kinds of transactions.

Vendors shall detail how each domain is mutually segregated from other domains and …

Added p. 94

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

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

Added p. 96

B18 is not applicable to devices that do not include commands for external key selection or cannot hold multiple key hierarchies related to PIN encryption.

TB18.1 Referencing the key table provided in Requirement B9, the tester shall note whether the POI:

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

TB18.3 The tester shall note what mechanisms are provided by the POI to authenticate the selection or use of the PIN key and any PIN key-encrypting keys. These mechanisms must be considered a sensitive service and implement dual control or cryptographic mechanisms.

Added p. 97

TB19.1 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. 98

• General Description (DTRs B20.1

• B20.5)

• Installation and Guidance (DTRs B20.6

• B20.15)

• Operation and Maintenance (DTRs B20.16

• B20.23)

• Security (DTRs B20.24

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

See Appendix I for an example of an acceptable Security Policy layout.

TB20.1 The tester shall examine the security policy to verify that the device is properly identified. Model name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions and the exact approval class and use case of the device including the specific POI Security Requirements version validated and approved against. The tester shall check and confirm that the Security Policy is well-formatted, accurate, consistent, complete, and does not contain ambiguous or misleading information. The tester …

Added p. 99

TB20.5 The tester shall confirm that if the device supports SSL, the security policy must clearly state that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan.

TB20.6 The tester shall examine the security policy to verify that it identifies all conditions (for example, voltage, humidity, and temperature) that will cause environmental failure-protection mechanisms to trigger.

TB20.7 The tester shall confirm that the security policy includes all configuration settings necessary to meet the security requirements defined in this document.

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

TB20.9 The tester shall confirm that the security policy contains any installation or user guidance as required by the laboratory for compliance with the PCI PTS requirements. Examples of such guidance would be:

• Outlining methods to check …

Added p. 100

TB20.17 The tester shall confirm that the security policy includes procedures for the decommissioning of devices that are removed from service, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device. The procedures may differentiate between temporary and permanent removal.

TB20.18 For privacy shielding the tester shall perform the following tests:

TB20.19 The tester shall confirm that the security policy contains information on all ways the device will indicate a tamper-response event, and any requirements for the return of this device to the vendor for examination following such an event (as required for compliance to DTR A1). This shall include an illustration to show the user an actual tamper-response display message and accurate information on any other tamper-responsive behaviors.

TB20.20 The tester shall examine the security policy and relevant vendor documentation to verify that any periodic maintenance procedures required for the secure operation …

Added p. 101

TB20.27 The tester shall confirm that the security policy contains specific details on any account-data protection schemes employed

•e.g., algorithms used, format-preserving encryption techniques

•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.

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

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

TB20.30 The tester shall examine the security policy to verify that it states that keys should be replaced with new keys whenever the compromise of …

Added p. 102

If the devices encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:

DTRs A1 and A13 verify the physical protections relevant to DTR B21.

B21 requires that the following be met:

• PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique- key-per-transaction method in accordance with ISO 11568 shall be used.

Added p. 103

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

TB21.3 If the ICC acceptor is a separate part, the tester shall detail how the customer PIN is encrypted for transmission between the two parts. This encryption must use ISO 9564-compliant PIN blocks and encryption mechanisms (an authenticated encipherment key of the ICC, TDES, or AES). The tester shall review the source code that performs the PIN-block formatting and encryption and confirm it is compliant to ISO 9564. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against …

Added p. 104

B2.1 and B2 address application loads and firmware, application, and configuration updates. B22 is intended to address other types of administration activities, such as those more prevalent with unattended devices. In any case, unless there is not any impact (for example, the load itself is cryptographically authenticated at the target), a secure session should be established (for example, TLS) for those communications.

TB22.1 The tester shall verify that the device cryptographically authenticates remote access attempts.

TB22.2 The tester shall verify that the device rejects unauthorized remote access attempts. This will be accomplished, for example, by performing a simulated remote access update with inadequate or modified authentication information.

TB22.3 The tester shall determine by which component the authentication is performed.

TB22.4 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question.

TB22.5 The tester shall determine the level of protection …

Added p. 105

Encrypting mode is defined to be when the device’s encryption of account-data functionality is enabled and operational. Changing between modes is considered a sensitive service as stated in B5 and B6 and therefore requires that authentication use dual-control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data.

A secure card reader intended for use with a non-PTS-approved device such as, but not limited to, a mobile phone or tablet; or an SCRP, is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted.

TB23.1 The tester shall examine any log or trace files generated by the device to determine whether they support the assertions made by the vendor.

TB23.2 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions …

Added p. 106

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

TB23.6 If the device allows for a change of modes between encrypting and non-encrypting, the tester shall verify that:

• The authorization implements the principles of dual control.

• Sensitive information required for the authorization (for example, passwords/authentication codes or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device.

• If changes to the mode of operation can occur remotely, the tester shall verify that a cryptographic authorization mechanism consistent to that used for remote access authentication (per B22) is implemented.

Added p. 107

TB23.1.1 The tester shall verify that the vendor has identified all data that is provided to authenticated applications.

Added p. 108

• Input to the hash function must use a salt with minimum length of 64 bits.

• The salt is kept secret and appropriately protected.

• Disclosure of the salt cannot occur without requiring an attack potential of at least 16 per device for identification and initial exploitation with a minimum of 8 for exploitation, as defined in Appendix B.

A cryptographic salt comprises random bits that can be input into a cryptographic function. Random bits shall be generated such that probability of the same random bits being output is statistically insignificant. A known salt value may compromise the effectiveness of the cryptographic function.

• Salts that are unique per merchant are generated outside the transaction device and require loading to each merchant device. The vendor must supply documentation to the merchant/acquirer processor on how to securely load the salt values and that this loading is treated as a sensitive service in accordance with …

Added p. 110

• Use of a unique-key-per-transaction technique. (Prevents the attack.)

TB25.1 The tester shall perform functional testing to verify the device characteristics regarding B25.

Added p. 112

DTRs C1.1 to C1.2 specifically care about the PIN entry function and how it is integrated into a payment terminal (irrespective of the form factor), whereas DTRs C2.1 to C2.5 aim at ensuring that components are being properly integrated. As such, DTRs C2.1 to C2.5 target compound architectures and are not relevant to, for example, countertop devices.

TC1.1.1 The tester shall examine that the integration of every PCI-approved secure component has been performed strictly according to the component manufacturer recommendations.

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

TC1.1.3 If a secure component directly controls the display, the tester shall verify that it does not display any digits of the PIN value by performing a …

Added p. 113

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

DTRs C1.1 to C1.2 specifically care about the PIN entry function and how it is integrated into a payment terminal (irrespective of the form factor), whereas DTRs C2.1 to C2.5 aim at ensuring that components are being properly integrated. As such, DTRs C2.1 to C2.5 target compound architectures and are not relevant to, for example, countertop devices.

Added p. 114

Protocol fault injections are covered by Requirement D1, whereas protocol abuses through regular requests are covered by this requirement.

TC2.1.1 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.

TC2.1.2 The tester shall verify that the failure of secure component does not lead the PIN entry POI terminal to fall back in a non-safe mode (i.e., no more protecting the PIN as per requirements).

TC2.1.3 The tester shall verify that the protocols used for secure communication between secure components are strong enough to deter attacks aiming at stealing sensitive information, including those involving impersonation of one component, and replay attacks.

Added p. 115

TC2.2.1 The tester shall visually inspect the device's card reader and/or the device in general to verify the assertions provided by the vendor.

TC2.2.2 The tester shall perform suitable test to verify the functionality of the mechanisms.

Added p. 116

TC2.3.1 The tester shall visually inspect the PIN entry device as integrated inside the POS Terminal to verify the assertions provided by the vendor.

TC2.3.2 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.

TC2.3.3 If the vendor does not provide with the final PIN-enabled payment application, the tester shall verify that the vendor provides third party developers with the appropriate documentation on how to implement the transaction flow, such as it is reasonably obvious for a cardholder to distinguish whether or not he or she is about to enter his or her PIN on the device.

A8 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed …

Added p. 117

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.

TC2.4.1 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.

TC2.4.2 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.

TC2.4.3 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique …

Added p. 118

TC2.4.6 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. At least one attack scenario shall be presented, in a format consistent with the examples shown in Appendix B in this document.

Added p. 119

A keyboard may be a touchscreen if the cardholder can input numeric data to it.

Devices implementing at the same time a touchscreen for PIN entry and a separate keypad (for example, to meet visual impaired regulations) must meet this requirement.

TC2.5.1 The tester shall visually inspect the device to verify the assertions provided by the vendor in order to verify that:

• 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 A8, B15 or C2.4.

TC2.5.2 If the device is equipped with more than one keyboard, and if the keyboard not intended for payment card PIN entry may be operated to accept numeric entry (for example, since it is …

Added p. 120

The tester is required to verify the claims of the vendor as described in the asset flow to ensure that the vendor listing of physical and logical interfaces in complete. This requires the tester to both identify physical interfaces through analysis of the design, as well as verify the presence of logical interfaces through methods such as passive monitoring of communications, port/protocol scans, and code review.

• If the module is under the control of the firmware and runs in the same process space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for wireless technologies listed above) is provided for and that secure communication is enforced by the interface.

Added p. 121

TD1.1 The tester shall examine the vendor’s asset flow diagrams to verify that they accurately portray all interfaces and protocols present on the device.

TD1.2 The tester shall examine any relevant documentation distributed by the vendor such as schematics, data sheets, asset flow diagrams, and assembly drawings submitted by the vendor to ensure that the vendor has exhaustively defined all protocols and interfaces supported by the device. The vendor must also identify where it derives its code that is used to implement protocols, as well as document all protocols and which physical interfaces they apply to. When public libraries are used to implement protocols, their versions must be specified.

TD1.3 The tester shall complete a table describing all interfaces and protocols; and for each, identify which component implements the protocol, whether it is a security protocol, and the location from which the software was derived. The tester shall Include all exempted protocols …

Added p. 122

All interfaces and associated communication methods of the device must be assessed to ensure that no interface can be abused or used as an attack vector. Specifically, this includes any physical, logical, or application interface that is executed within the POI device with sufficient privilege to allow for direct interface to sensitive assets within the POI (should that protocol be compromised in some way). The interfaces must be documented and assessed whether they are used for or have access to card data or not. This analysis must be done in accordance with the Appendix G, “Domain-Based Asset Flow Analysis.” Sufficient evidence must be provided to demonstrate the validity of laboratory assessments including interfaces using open protocols.

This includes any Open Protocol 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. In addition, …

Added p. 123

TD2.4 Where a complex operating system (such as Linux, other *nix variants, and operating systems such as Android) is used, the tester shall verify that ASLR is enabled and correctly configured. For example, for Linux, this means setting “randomize_va_space” to a value of “2,” and ensuring that all code is correctly compiled (and/or configured) to implement and enable ASLR. Where options are provided for use of stack canaries and data-execution-prevention bits, these must always be enabled (including for application code).

TD2.6 If the device includes command-execution interfaces or parsers: The tester shall detail how each of the interfaces identified in D1 is configured to accept commands•for example, whether a command executive is used, or other methods are used to parse input commands. The tester shall define which common functionalities exist between interfaces to determine which test approaches may be applied in common to more than one interface.

TD2.7 The tester shall detail …

Added p. 124

TD2.12 The tester shall identify all command interpreters within the firmware⎯e.g., anything scriptable, including but not limited to SQL commands and OS commands (for example, UNIX system() and popen()). If command interpreters are called, the tester shall describe and justify why a command or environment cannot be manipulated to perform unauthorized functions.

TD2.13 The tester may perform any additional tests necessary to validate the device’s compliance to this DTR. The vendor shall provide any necessary test support to access and use the interfaces under test.

Added p. 125

The vendor must also identify and document all protocols and Interfaces identified in Section D1.

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

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

TD3.3 The tester shall summarize all the protocols and interfaces provided by the firmware to application developers. The tester shall ensure that each of these protocols and interfaces have associated guidance within vendor documentation that ensures that application developers …

Added p. 126

The objective of this section is to verify the default configuration for interfaces and communications as defined by the vendor documentation and Section D1.

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

TD4.2 The tester shall assess the default configuration of the device. The default configuration must be in line with security guidance•for example, default settings must disable non-essential services, must use secure configurations for security protocols.

TD4.3 The tester shall perform any additional tests necessary to validate the device’s documentation. The tester should use …

Added p. 127

d) Key-management security guidance ensures secure use of keys and certificates, including certificate status (e.g., revoked), secure download, and roll-over of keys.

Note: This does not supersede any criteria in B9 but rather is required for any device implementing protocols evaluated under Open Protocols•i.e., key-related Security Protocols, such as SSL/TLS, SSH, VPN technologies.

This requirement applies to all declared Security Protocols defined in Section D1.

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

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

• Be complete, clear, and unambiguous; and

TD5.3 The tester shall verify whether the cipher suites used by the declared security protocol are in line with the PCI PTS …

Added p. 129

For D7, D8, and D9, the minimum requirements for cryptographic algorithms used to provide security are specified in DTR B9. Only TDES, RSA, ECC, DSA, and AES are acceptable for encryption or signing operations. SHA256 or above may also be used for hashing purposes. See Appendix E.

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

TD6.2 The tester shall assess the physical and logical interfaces of the device to ensure the declared security protocol is present for each interface.

TD6.3 The tester shall execute tests to verify that each interface can use a declared security protocol in a secure way. The tester may perform any additional tests necessary to validate the device’s documentation. The tester should use …

Added p. 130

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

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

TD7.2 The tester shall execute tests necessary to validate the device’s implementation of a security protocol is providing for confidentiality of data in line with the documented method. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support

•including testing keys …

Added p. 131

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

TD8.2 The tester shall verify device behavior when receiving incorrect data packets.

TD8.3 The tester shall perform any additional tests necessary to validate the device’s implementation of security protocol is sufficiently able to provide integrity. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid. The vendor shall provide any necessary test support to access and use the interfaces under test. The tester shall summarize the testing and responses for each interface tested.

Added p. 132

a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question, as denoted in Appendix E.

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

TD9.2 In the case when certificates are used for server authentication, the tester shall execute tests to verify device behavior when receiving incorrect certificates, including:

c) Certificate with weak key size⎯e.g., RSA less than 2048 bits

d) Certificate signed using a weak hash e.g., SHA1 or MD5

e) Chaining error in certificate for cases a, b, c, or d TD9.3 The tester shall verify the device’s behavior when connecting to an un-authenticated server. The tester shall verify that the connection is rejected. If the default behavior is to accept the connection without device …

Added p. 133

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

TD10.2 Unless it can be shown that by design the used security protocol provides message replay countermeasures (by the usage of counters or nonces, for example) and that there is no publicly known replay attack on the protocol or its implementation under evaluation, the tester shall test to verify device behavior when receiving incorrect data packets, replay messages, or other anomalies.

TD10.3 The tester shall perform any additional tests necessary to validate the device’s implementation of security protocol is able to provide exception handling and replay detection. The tester should use his or her own judgment in determining the appropriate tests …

Added p. 134

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

TD11.2 The tester shall assess each interface of the device to ensure that each interface can provide session management.

TD11.3 The tester shall verify device behavior while attempting to break session management rules• e.g., request to exceed number of simultaneous connections.

TD11.4 The tester shall perform any additional tests necessary to validate the device’s implementation of security protocol is able to provide session management and that the device handles any anomalies correctly. 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 …

Added p. 135

If a Bluetooth interface is used, the Bluetooth interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. If PIN or passkey entry is to be used, the evaluator must validate that vendor default values can be changed. The device must not support or allow for the use of insecure communication options such as, but not limited to, Security Modes 1 and 2 and the “Just Works” secure pairing option of Security Mode 4.

For Bluetooth 4.1 or higher, devices that have BR, EDR, and High Speed (HS) features, Security Mode 4, Level 4 must be used. This requires Secure Connections, which uses authenticated pairing and encryption using 128-bit strength keys generated using FIPS-approved Advanced Encryption Standard (AES) encryption. For Bluetooth 2.1 through 4.0 devices, Security Mode 4, Level 3 must be used.

BLE implementations must use version 4.2 or higher. BLE must use …

Added p. 136

If a Wi-Fi interface is used, the Wi-Fi interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. Security must be enabled. WEP cannot be used or configured at any time, and WPA and/or WPA2 must be supported. If passkey is used, it must not be a vendor default. The evaluator must validate that default values can be changed on the target of evaluation.

TD13.1 The tester shall describe the different protocols and modes supported by the device TD13.2 Using a test system, the tester will confirm that the device does not support WEP.

TD13.3 The tester shall describe how the passkey is entered and whether any default values are handled.

The vendor must have a mechanism that allows for the identification of the exact parts (bill of materials or source code files) for a deployed device. For hardware, this mechanism may use the printed …

Added p. 140

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

“Certify firmware” refers to self-certification. This requirement, in essence, requires the vendor to have implemented and to use internal quality control and change-control systems. With these systems in place, the vendor is in control of the code and can attest to the fact that the code is free of hidden or unauthorized functions.

• Mitigating them by techniques that include but are not limited to: Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Harvard …

Added p. 141

TE2.5 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.

TE2.6 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.

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

TE2.8 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.

TE2.9 The tester shall …

Added p. 142

TE2.14 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 TE2.13 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 the developer …

Added p. 149

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

TE9.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The approved documentation shall detail:

• For when a device is returned to the vendor for maintenance, mechanisms are in place to automatically cause the erasure of all previously loaded acquirer secret keys upon servicing the device

•e.g., loading a new public RSA key causes the erasure of all previously loaded secret keys.

Added p. 150

The intent of this requirement is to ensure that the vendor has an effective process for detecting vulnerabilities within the firmware.

The scope of the vulnerability assessment includes all firmware executing inside the device that may affect security.

TE10.1 The tester shall examine any relevant documentation distributed by the vendor to ensure that the vendor has provided for effective detection of vulnerabilities in each of the protocols and interfaces defined in D1. The tester shall list the methods and tools used by the vendor for vulnerability assessment including but not limited to test scripts, practical tests, review of information in public domain, and security analysis to locate vulnerabilities.

TE10.2 The tester shall examine the vendor’s documentation and verify that a process for the classification of newly detected vulnerabilities exists. The classification includes an analysis of the effect on the device, correct description, a level of criticality, and mitigation measures for each vulnerability.

TE10.3 The …

Added p. 151

The intent of this requirement is to ensure that the vulnerability assessment process evaluated under Requirement E10 has been followed.

Review the vulnerability assessment for each interface as defined in D1.

TE11.1 The tester shall examine relevant documentation, such as scan reports, test reports or vulnerability analysis documentation submitted by the vendor to verify that it supports the vendor responses.

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

TE11.3 The tester shall examine any anomalies indicated by the vendor and determine whether they are correctly described, have a level of criticality assigned, and that mitigation measures are suggested.

Added p. 152

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

The vulnerability disclosure process applies to all code released by the device vendor.

TE12.1 The tester shall examine relevant documentation, such as a user guide or the merchant implementation guide submitted by the vendor, to verify that it supports the vendor responses.

TE12.2 The tester shall examine the documentation to verify both the timely creation of mitigation measures for newly found vulnerabilities and that procedures exist to continually update and document all vulnerabilities.

TE12.3 The tester shall perform any additional tests necessary to validate the vendor’s vulnerability- disclosure measures including auditing the vendor’s vulnerability management program output. 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 …

Added p. 156

TF3.5 The tester shall observe the shipping process to ensure that POI devices are 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.

Added p. 160

• affixed to it. This information shall also be retrievable by a query.

• Physical/chronological whereabouts

Added p. 167

4. A handheld device must by weight, size, and shape encourage its handheld operation. The criteria for a device with a physical keypad are:

Added p. 168

a) Weight should be 600 grams or less;

b) Width of the virtual effective keypad at the “5” key should not be more than three (3) inches or

c) Length of the virtual effective keypad should not be more than four (4) inches or 10.16 cm;

d) The diagonal of the display should be not more than ten (10) inches or 25.4 cm.

However, the guidelines listed are suggestions, not requirements.

Added p. 175

Specialist expertise and equipment are concerned with there being 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 relationship between expertise and the use of equipment does not always apply•for instance, when environmental measures prevent an expert attacker’s use of equipment; or when, through the efforts of others, attack tools requiring little expertise for effective use are created and freely distributed (for example, via the Internet).

Software required for a PIN-disclosing bug is typically straightforward to implement and would not be considered bespoke. Bespoke software would be software that requires significant time and expertise to develop such as is required for side channel attacks. PCI requires strong justification …

Added p. 178

Where sensitive data is exposed inside the PED or EPP, but outside of the immediate area of the keypad contacts (i.e., outside the keypad area), or internally within the security processor, this data must be protected by a tamper-responsive envelope. Use of physical barriers alone, such as plastic walls or tamper evident protections, is not considered sufficient to meet the requirements to protect customer PIN data or cryptographic keys. A POI that does not implement tamper-detecting side walls for its secure area must be implemented in such a way that the sensitive signals are otherwise protected with methods that go beyond purely physical and tamper evidence; otherwise, it fails the evaluation. This must include the use of a dedicated security processor which has internal protections against accessing signals on the pins or bond-out wires, with no sensitive signals exposed outside of this security processor that are not otherwise protected by …

Added p. 196

• Standard PC (either off the shelf or built from components) PC-based instruments such as protocol sniffers, USB attached oscilloscope adapters, and graphical multimeters are considered standard equipment, especially if they do not require dedicated hardware or adapters.

Added p. 200

• Hash functions: Only algorithms from the SHA2 and SHA3 family are allowed, with output size >255.

Added p. 200

• Symmetric-key algorithms used for encryption and decryption: AES must be used, with key size >= 128 bits or TDES with keys size >= 112 bits.

• Message authentication codes (MACs): CMAC or GMAC can be used with AES, as well as HMAC with an approved hash function and a key size >=128

• Signature algorithms: DSA, RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below.

• Approved key-establishment schemes are described in NIST SP800-56A (ECC/FCC 2-based key agreement), NIST SP800-56B (IFC-based key agreement), and NIST SP800-38F (AES-based key encryption/wrapping).

Algorithm TDES IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits: 112 2048 224 2048/224 128 1 Except as noted, the use of SHA-1 is prohibited for all digital signatures used on the device in connection with meeting PCI security requirements. This includes certificates used by the device that are non-device specific …

Added p. 201

TLS implementations must prevent the use of cipher suites that do not enforce the use of cryptographic ciphers, hash functions, and key lengths as defined in the Technical FAQs.

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

IFC, FFC, and ECC are vulnerable to attacks from large-scale quantum computers. In 2017, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, planned to end with a selection of new algorithms by 2023-2025.

Because of rapid progress in the field of quantum computing, it is advised to become informed/aware of this specific threat and its potential mitigations.

Note: This appendix is for use in conjunction with DTR A7, “Non-Invasive Attacks for Cryptographic Keys.” Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are …

Added p. 206

Establishing definite correlation of non-sensitive I/O data is important to (1) validate the collection setup and test methodology are not flawed, (2) to localize sensitive cryptographic operations, in developing attacks, and (3) demonstrate that cryptographic key data is more resistant to leakage than other data. The expectation is for most tests to be capable of establishing definite correlation of non-sensitive I/O data. Very strong justification for null correlation results is needed otherwise, in asserting device compliance.

Added p. 213

The general idea is to determine when a certain asset is available at a certain location. Any hardware component or software module dealing with the asset will be virtually marked with the domain that the asset belongs to. We call this imaginary process “tagging.” If a component or module is already tagged, it will keep the domain with the higher attack potential associated. Once the entire asset flow analysis is performed, the appropriate domain will be assigned for each software module, hardware component, and even PCB track. This allows the tester to apply the appropriate DTRs for the specific domain.

It is therefore expected that the developer of the PTS device will perform this domain-based asset flow analysis and provide the results and a proper explanation to the testers. The test lab will verify the analysis and use the effective domain rating as input for the evaluation.

For the vulnerability analysis⎯e.g., performed …

Added p. 214

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

PIN The cardholder PIN is protected to resist an attack potential of 26 points in DTR A1. PINs must not be disclosed. Passwords meet the same category. Although DTR A13 puts offline PIN at 20 points, the PIN shall consistently be considered as an asset class.

Lower Protection Data This class covers all other transaction data⎯e.g., PAN⎯and display prompts. The DTRs protect these assets at 20 points or less. The EMV L2 kernel sits here.

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

Vendor Any other data or functionality …

Added p. 215

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

Any code that could potentially endanger any asset⎯e.g., in case of malfunction or even complete replacement⎯is considered “firmware” in the sense of the DTR. We define “code” as any instructions for a processing hardware, including microcode or netlists for programmable hardware, and any kind of data that may affect the processing by these instructions. Such data can be as simple as configuration bits, whether or not a certain security function is enforced. In PCI POI such data often is interpreted code, from simple access control rules represented as data for an engine up to large amounts of code⎯e.g., Java byte code in Android-based systems. As soon as data has the potential to compromise any of …

Added p. 217

The vendor shall provide a block diagram at domain level that clearly identifies how the domains interact with one another. The corresponding programming interfaces or, if applicable, hardware interfaces shall be uniquely identified and documented. The diagram shall clearly identify whether software is executed on the same hardware or on separate CPU, memory, etc.

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

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

Applications shall be segregated from other firmware, including firmware of the same domain and other applications at least …

Added p. 218

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

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

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

Added p. 221

Figure G-1: 8-bit Microprocessor + 32-bit SoC with Linux The 8-bit CPU runs a monolithic secure firmware. The 32-bit SoC runs a Linux OS managing all other software.

Table G3: Identification of Interfaces Interface Purpose Handler (lowest level) NFC Radio Secure Firmware Encrypting MSR Read PAN for transactions from cards’ magnetic stripes Secure Firmware ICCR Read PAN for transactions from and convey PIN to ICC Secure Firmware Keypad Enter PIN and Amount Secure Firmware Display Display transaction information to cardholder and spam during idle time GSM Connect to payment host and terminal management Ethernet Connect to payment host and terminal management

Added p. 223

Figure G-2: Asset Flow Description 6 with 51: Manual amount entry with offline encrypted PIN The merchant presses ‘START’ on the keypad. The Security Controller firmware detects the key and sends a START_TRANSACTION message using the UART to the Application Processor. The latter is handled by an interrupt handler of the Linux OS, which maps it to the character device /dev/ttyS1 for the process spaces maintained by Linux.

On the Application Processor /dev/ttyS1 is acquired by the Payment Application. Upon receiving a START_TRANSACTION message, it returns a QUERY_AMOUNT message and displays an amount prompt via /dev/pty1, which interfaces to the display driver of the Linux OS.

The QUERY_AMOUNT message causes the Security Processor to scan the numeric keypad. Once amount entry is completed, the Security Processor returns AMOUNT_DONE to the Payment Application. The latter stores the amount and prompts for a card via /dev/pty1. It puts the Security Processor to card acceptance …

Added p. 224

Figure G-3: Transaction Process Flow

Added p. 225

The Payment Application displays the transaction outcome and creates a record for the payment processor containing Amount, Transaction Cryptogram, Time, Terminal ID, and encrypted PAN: This record is sent via the Unix domain socket /var/run/terminal to the Terminal Application for proper formatting. Unix domain sockets are handled by the Linux OS.

The terminal application will format the record according to the specifications of the particular processor and send the record to the payment processor using a network socket.

The network socket in turn is managed by the Linux OS. It wraps the message in appropriate TCP/IP frames and routes them via the proper interface. Depending on the connectivity, this may be the GSM modem or the Ethernet connection.

The GSM modem handles all GSM specific protocols internally. It is served by interrupt handlers of the Linux kernel, which handles it as a network interface. Similarly, the physical Ethernet layer is served by interrupt …

Added p. 226

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

Notes: Security Controller denotes both the controller hardware and the monolithic software running on it. For simplicity it has been assumed that both Security and Application Controller use internal memories, only, or that the developer is willing to tag all external memory as the same domain as the controller itself.

Added p. 227

The relevant security requirements as defined by the DTR are valid with respect to any CPU. Whether or not a CPU is properly used to cover or at least support any of these must be verified by the evaluators. This guidance shall be understood as a checklist, for which aspects should at least be considered. If a CPU is found to not cover any DTR entirely, the evaluators shall verify how other mechanisms are employed to bridge this gap.

The checklist applies to all processors inside any POI, which process any of the assets related to PCI POI Security Requirements, i.e., cryptographic keys relevant to PIN protection, plaintext PINs, plaintext PANs, display prompts, and plaintext card reader data. Please refer to Appendix G for definition of assets.

Processors that simply convey asset containers as defined in Appendix G can be left out of scope, provided that encryption or authentication is adequate according …

Added p. 228

Furthermore, any tamper-detection signals, removal switch signals, prompts, or display signals are considered sensitive signals, as well as any PCB tracks signaling special modes that may be linked to sensitive services. Attackers may try to modify these signals to compromise the security of the device.

Evaluators shall examine whether any busses, in particular to external memory, may carry sensitive data (see also section about external memory below).

Most modern CPUs use a BGA-type packaging. The testers shall consider techniques to contact solder- balls. If a CPU is accessible, it can be feasible to contact any single ball. It may be harder if specific combinations are required, or if the CPU is hard to reach. The testers shall still consider whether any mechanical obstacles must be removed prior to attacking the BGA.

Even if a specific ball appears unreachable⎯e.g., some inner ball under a BGA using underfill⎯there may be other spots to reach the …

Added p. 229

External memory Since code and data sizes tend to grow, some POI designs use external memory⎯i.e., storage that is located in an area with lesser tamper protection than the CPU. Obviously, no plaintext of confidential assets must ever be stored in external memory that is reachable by an attacker. But access to memory can have various dangerous effects. Even modification of encrypted memory may be exploited for various goals. Analysis of address access may yield information about internal processing, which might for example be exploited for side-channel attacks. Plaintext code memory might be replaced by other chosen content, etc.

There are secure CPUs that support encrypted memory with authentication, which counter most of these attacks. A good address layout randomization and sufficient cache size may complicate address-bus analyses.

There are methods to store databases and unused code⎯i.e., files, authenticated and encrypted in memory⎯that may be accessible to attackers. Actual process memory is …

Added p. 230

• When automatic erasure of memory is triggered;

• Whether it can be disabled;

• How erasure is performed;

• How long it takes until erasure is assured to be complete under any circumstances.

Random Number Generators True random number generators are a common feature of security CPUs. Using some homebrew post- processing or even an entirely distinct generator is a common drawback implemented by POI developers. Testers shall verify that the generator is actually used, the data is not post-processed, and that the results have been validated by the relevant NIST tests. In most cases, re-running the test may be more efficient than referring to external test results.

Side Channels There are CPUs with cryptographic libraries that were tested to not emit any side-channel information during specific cryptographic operations. These results are generally obtained in a dedicated measurement setup⎯i.e., not integrated in any payment device. If such CPUs are used, the tester shall verify …

Added p. 231

The CPU vendor has to supply sufficient detail of the implementation to allow the tester to work through each DTR. This may include code samples if required by the DTR. Boot code as the trust anchor of the boot stack necessarily deals with keys. The exact key management is part of the PCI POI report and shall be available to the tester.

Test Re-Use Security processors often claim various security features. Without exception, these features require the POI developer to correctly use and configure the CPU. This is the minimum effort for each test involving a security CPU and at least requires a clear and detailed guidance from the CPU vendor.

Beyond that, verification of the CPU vendor’s claims in general is quite a time-consuming effort, which requires a lot of different hardware evaluation skills. It is therefore an expensive part of the testing, and it may be worth considering re-use.

In order …

Added p. 232

Libraries Crypto-Lib: ACHSCL.lib version 1.2.34.56 supplied by ACME Corp.

Scope 3DES side-channel resistance (DPA, EMA) AES side-channel resistance (DPA, EMA) High-temperature sensor Low-temperature sensor Voltage glitch resistance (VCore, VBat) Clock glitch resistance (CPU & RTC) Erasure of Keys on external tamper The information in this table shall demonstrate that the quoted test results actually apply to the processor used in the current evaluation and that the functionality re-used is actually part of the scope originally tested. The final two bullets•how the test data was analyzed and why testing passed or failed⎯shall be examined by the test lab using the original evaluation report.

Added p. 235

• This section should state the POI Security Requirements version and Approval Class the device is evaluated and approved against.

Added p. 237

• This section includes an illustration to show the user an actual tamper-response display message.

Removed p. 1

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

Removed p. 7

• DTR Module 3: Open Protocols Derived Test Requirements

• DTR Module 4: Secure Reading and Exchange of Data Requirements

Modified p. 7 → 8

• DTR Module 1: ~~Core~~ Requirements

• DTR Module 1: Physical and Logical Requirements

Modified p. 7 → 8

• DTR Module ~~5: Device Management~~ Security Requirements Structure of the DTRs Each PCI requirement as stated in the PCI PTS POI Security Requirements is represented by a subsection. For example, Requirement A1 is represented in this document as:

• DTR Module 4: Life Cycle Security Requirements Structure of the DTRs Each PCI requirement as stated in the PCI PTS POI Security Requirements is represented by a subsection. For example, Requirement A1 is represented in this document as:

Removed p. 8

Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents, such as the Security Policy.

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

Modified p. 8 → 9

• Security processor(s) and other processors and memory, operating system(s), boot-up sequences, firmware modules, software applications, crypto functions, data-loading mechanisms, etc.

• Security processor(s) and other processors and memory, operating system(s), boot-up sequences, firmware modules, software applications, crypto functions, data-loading mechanisms, hardware versions and software versions with explanations of versioning, features and functions associated with the device’s approval, etc.

Modified p. 8 → 9

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

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

Modified p. 8 → 9

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

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

Removed p. 9

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.

Modified p. 9 → 10

The evaluation report document shall demonstrate compliance to Security ~~Requirements.~~ For all DTRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid against PTS Program•i.e., considering DTRs, FAQs, Program Guide, and any other related documents. Every DTR should be supported by …

The evaluation report document shall demonstrate compliance to Security Requirements and shall present all test evidence as requested within individual DTRs. For all DTRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid against PTS Program•i.e., considering DTRs, FAQs, Program Guide, …

Modified p. 9 → 10

• Descriptions of the vendor’s attestations of compliance to security requirements, ~~with~~

• Descriptions of the vendor’s attestations of compliance to security requirements, with:

Modified p. 9 → 10

• Accurate descriptions of relevant device attributes, for example (but not restricted to): physical and logical protections, chip architecture, OS, ~~etc.~~

• Accurate descriptions of relevant device attributes, for example (but not restricted to): physical and logical protections, chip architecture, OS, etc.;

Modified p. 9 → 10

~~• Explanations for any conclusions based on theoretical analysis instead of applied testing;~~ The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.

The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.

Removed p. 10

Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario.

Modified p. 10 → 12

The objective of this section is to assess the device’s ability to protect clear-text PINs and other sensitive data. Attack scenarios ~~must be~~ in ~~support of~~ the ~~compromise of clear-text PINs and other sensitive data as noted in A1.~~

The objective of this section is to assess the device’s ability to protect clear-text PINs and other sensitive data. Attack scenarios are not presented in this requirement. DTRs A2, A4, A6, A8, A10, and A13 include attack costings which will incorporate tamper-detection results from this requirement during the attack development.

Modified p. 10 → 12

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

Requirement A6 focuses on determination of secret or private keys. This requirement focuses on tamper-detection and response mechanisms in place to prevent disclosure of sensitive data.

Modified p. 10 → 12

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

“Immediate” is defined as fast enough to ensure erasure occurs before the tamper-detection mechanisms can be disabled.

Modified p. 10 → 12

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.

For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information.” “Secret information” consists of any private or secret cryptographic keys or passwords/authentication codes relied on by the device to maintain security characteristics governed by PCI requirements.

Modified p. 10 → 12

If any of these keys are not zeroized, then other mechanisms must exist to disable the device, and these keys must be protected in accordance with Requirement ~~A5.~~

If any of these keys are not zeroized, then other mechanisms must exist to disable the device, and these keys must be protected in accordance with Requirement A6.

Modified p. 10 → 12

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.

Secret or private cryptographic keys that are never used to encrypt or decrypt data (e.g., keys, accounts, PINs), or are not used for authentication, do not need to be considered secret data and therefore do not need to be erased•for example, where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.

Removed p. 11

TA1.1 The tester shall visually inspect the tamper-detection mechanism to verify the assertions provided by the vendor in response to Section A1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A1 of the PCI PTS POI Security Requirements for consistency relating to the tamper-detection mechanism. The vendor responses should clearly indicate how tamper-detection mechanisms are effective and robust. The tester shall summarize the responses.

TA1.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. 11 → 13

If switches are used as the primary protection for the area around a physical keypad area, then at least three blind, tamper switches must be implemented. The switches must be protected from attacks that use the application of adhesives or conductive liquids to disable the switches. The design must ensure that a minimum of three switches in the keypad area must be individually attacked to disable them. ~~Note that these criteria are in addition to exploitation time and attack potential …~~

If switches are used as the primary protection for the area around a physical keypad area, then at least three blind, tamper switches must be implemented. The switches must be protected from attacks that use the application of adhesives or conductive liquids to disable the switches. The design must ensure that a minimum of three switches in the keypad area must be individually attacked to disable them.

Modified p. 11 → 14

~~TA1.3~~ The tester shall provide an overview of the POI and how it is constructed. The tester shall include an exploded diagram of the POI showing how all sub-components are assembled and connected internally•for example, an explanation of processor (secure and unsecure) architectures and where these are located with regard to the internal areas of the device.

TA1.2 The tester shall provide an overview of the POI and how it is constructed. The tester shall include an exploded diagram of the POI showing how all sub-components are assembled and connected internally•for example, an explanation of processor (secure and unsecure) architectures and where these are located with regard to the internal areas of the device.

Modified p. 11 → 14

~~TA1.4~~ The tester shall describe any physical shielding (i.e., active, passive) or other chip or embedded physical protections that microprocessors in the device ~~possess,~~ and how these are effective against tampering the physical ~~package(s)e.g.,~~ die encasement.

TA1.3 The tester shall describe any physical shielding (i.e., active, passive) or other chip or embedded physical protections that any microprocessors used in the device that contain clear-text secret or sensitive data, and how these are effective against tampering the physical package(s)⎯e.g., die encasement. The tester shall describe any physical barriers that surround microprocessors in the device, and state whether/how these totally envelop or partly surround microprocessors, and whether such barriers are tamper-responsive.

Removed p. 12

TA1.6 The tester shall describe the path taken by the signals that connect the customer PIN entry mechanism(s) to the secure processor(s).

TA1.7 The tester shall list any components

•including passive parts or segments, connectors, or other items

•that are connected to the path of the customer PIN signals.

The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. (See Annex A of the Vendor Questionnaire.) PCB Designator PCB Version PCB Purpose Picture Reference Tamper-Detection Mechanisms TA1.9 For each PCB that carries customer PIN signals, the tester shall describe what tamper- detection mechanisms protect these signals from being accessed (such as tamper grids). The tester shall confirm that these mechanisms protect the entire path taken by the signals, as described above.

TA1.10 The tester shall describe whether any of the items on the path of the keypad signals are not protected by all tamper-detection …

Modified p. 12 → 14

~~TA1.8~~ The tester shall enumerate each of the circuit boards indicated in the POI in the table below, providing, at a minimum:

TA1.4 The tester shall enumerate each of the circuit boards indicated in the POI in the table below, providing, at a minimum:

Modified p. 12 → 14

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

PCB Designator PCB Version PCB Purpose Security Domain/Assets Picture Reference Tamper- Detection Mechanisms TA1.5 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:

Removed p. 13

TA1.13 For each tamper switch used in the POI, the tester shall complete the details indicated in the table below, at a minimum. (See Annex A of the Vendor Questionnaire.) The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack (such as being covered by a flexible tamper grid, or having a unique construction) Switch Location Number Used in that Location Physical Implementation Size of Switch Conductive Ink Protections Additional Comments TA1.14 The tester shall describe what testing was performed to validate the protection provided by each of the tamper switches enumerated above.

Modified p. 13 → 15

~~The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. (See Annex A of the Vendor Questionnaire.)~~ Tamper Grid Physical Implementation Size of Traces and Distance between Traces, Signals, or Layers Tamper- detecting Signals Method of Connection Adjacent Signals? ~~TA1.12~~ The tester shall describe what testing was performed to validate the protection provided by each of the tamper grids enumerated above.

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

Modified p. 13 → 15

~~TA1.15~~ The tester shall note which tamper-detection mechanisms use active high, active low, dynamic, resistive (or other) types of sensors. The tester shall confirm that any guard rings or interspaced traces in tamper grids are at opposing voltages that will activate tamper detection if electronically shorted. The tester shall note what testing has been performed to confirm this.

TA1.9 The tester shall note which tamper-detection mechanisms use active high, active low, dynamic, resistive (or other) types of sensors. The tester shall confirm that any guard rings or interspaced traces in tamper grids are at opposing voltages that will activate tamper detection if electronically shorted. The tester shall note what testing has been performed to confirm this.

Modified p. 13 → 16

~~TA1.17~~ The tester shall describe what testing was performed to validate any volume encapsulation.

TA1.11 The tester shall describe what testing was performed to validate any volume encapsulation.

Modified p. 13 → 16

~~TA1.18~~ The tester shall describe any attachment or “forming” methods (such as soldering, elastomeric strips, or adhesive for attachment, and plastic/metal walls for forming the shape of flexible circuits) used as part of the security features of the POI. For example, the tester shall detail the methods used to secure any flexible tamper grids, or “cover PCBs” so they cannot be bent or lifted out of the way.

TA1.12 The tester shall describe any attachment or “forming” methods (such as soldering, elastomeric strips, or adhesive for attachment, and plastic/metal walls for forming the shape of flexible circuits) used as part of the security features of the POI. For example, the tester shall detail the methods used to secure any flexible tamper grids, or “cover PCBs” so they cannot be bent or lifted out of the way.

Removed p. 14

TA1.30 Describe the different attack paths considered. Using the format shown in Appendix B, and providing images allowing the principle steps in the analysis to be understood, the tester shall generate PIN-attack calculations, using different attack techniques on the POI, and present the two most feasible. The attacks should be dissimilar in approach unless the lab can fully justify the infeasibility of any second divergent approach. The tester shall state explicitly where testing has verified any specific stage of the attack

•including the time, equipment, and skill required, and number of mechanisms to bypass

•and where assumptions are used in place of testing. The tester shall justify why any assumptions have been used instead of than actual testing. Calculations shall include evidence justifying particular rating levels as being appropriate.

TA1.31 The tester shall verify that no attack was able to be determined, including those outlined above, which could be performed for less than …

Modified p. 14 → 16

~~TA1.20~~ The tester shall provide details on the security processor used in the POI, including how it drives tamper-detection features. The tester shall provide and reference a picture of the location and area surrounding the security processor.

TA1.14 The tester shall provide details on the security processor used in the POI, including how it drives tamper-detection features. The tester shall provide and reference a picture of the location and area surrounding the security processor.

Modified p. 14 → 16

~~TA1.22~~ The tester shall provide and make reference to a schematic diagram of the tamper circuits of the POI, showing connections to all tamper-detection features including switches and tamper grids.

TA1.15 The tester shall provide and make reference to a schematic diagram of the tamper circuits of the POI, showing connections to all tamper-detection features including switches and tamper grids.

Modified p. 14 → 16

~~TA1.23~~ The tester shall state how any passive components, connectors, or other items that carry tamper signals are protected against being accessed. The tester shall include any connections to power planes through hole vias that may be exposed outside of the tamper-detecting areas of the POI.

TA1.16 The tester shall state how any passive components, connectors, or other items that carry tamper signals are protected against being accessed. The tester shall include any connections to power planes through hole vias that may be exposed outside of the tamper-detecting areas of the POI.

Modified p. 14 → 16

~~TA1.24~~ The tester shall describe how the POI responds to a tamper-detection event. The tester shall show the visible response(s) of the device’s display (if any) upon tampering.

TA1.17 The tester shall describe how the POI responds to a tamper-detection event. The tester shall show the visible response(s) of the device’s display (if any) upon tampering.

Modified p. 14 → 16

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

TA1.18 Deriving from previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the POI results from tamper-detection events, and if applicable, where any of these keys are not zeroized, how other mechanisms exist to disable the device, and how these keys are protected in accordance with Requirement A6.

Modified p. 14 → 16

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

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

Modified p. 14 → 18

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

TA2.7 The tester shall explain how the device is designed to mitigate against overlays.

Modified p. 14 → 18

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

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

Modified p. 14 → 18

~~TA1.29~~ The tester shall explain how the POI is protected against attacks from ~~each of~~ all sides of the POI, including the front and rear of the device.

TA2.9 The tester shall explain how the POI is protected against keypad attacks from all sides of the POI, including the front and rear of the device.

Removed p. 15

TA2.1 The tester shall examine the response to Section A2 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A2 of the PCI PTS POI Security Requirements for consistency relevant to Requirement A2. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.

TA2.2 The tester shall examine and cite any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc., submitted by the vendor to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions. Such information must be clearly referenced.

TA2.3 The tester shall provide the operational temperature and voltage range for the POI as detailed in vendor documentation.

Modified p. 15 → 19

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

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. 15 → 19

~~TA2.4~~ Using the ~~schematic~~ and ~~description~~ from ~~TA1.6 and TA1.7~~ the tester shall list the temperature ranges for all components included in the tamper-detection circuit. This shall include mechanical switches and active elements (but not passive elements such as resistors and capacitors).

TA3.1 Using the schematics and descriptions from TA1.2 through TA1.9, the tester shall accurately list the temperature and voltage ranges for all components included in the tamper-detection and response circuit. This shall include mechanical switches and active elements (but not passive elements such as resistors and capacitors).

Removed p. 16

TA2.10 The tester shall develop attack scenarios to compromise the device by altering operational conditions and consider whether altering environmental conditions may be used to develop attacks.

TA2.11 The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, demonstrating compliance to this DTR.

Modified p. 16 → 20

~~TA2.7~~ Using a POI that has been configured by the vendor (using special test code from the vendor, which shall be removed from production units) to operate self-tests such that the correct operation of the device can be ~~confirmed, the~~ tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table; or the vendor should provide sufficient test reports covering all required …

TA3.4 Using a POI that has been configured by the vendor (using special test code from the vendor, which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed. The tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table; or the vendor should provide sufficient test reports covering all required …

Modified p. 16 → 20

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

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

Modified p. 16 → 20

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

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

Removed p. 17

TA3.1 The tester shall examine the response to Section A3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI PTS POI Security Requirements for consistency relevant to Requirement A3. The vendor responses should clearly indicate what sensitive information and functions exists; and that sensitive functions or information are only used in the protected area(s) of the device; and that sensitive information and functions dealing with sensitive information are protected from unauthorized modification. The tester shall summarize the responses TA3.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings and functional specifications submitted by the vendor to verify that it supports the vendor responses. The tester shall reference this information and indicate how it supports the assessment.

Modified p. 17 → 21

~~TA3.3~~ The tester shall verify the completeness of the information regarding sensitive information and functions presented by the vendor.

TA4.1 The tester shall verify the completeness of the information regarding sensitive information and functions presented by the vendor.

Modified p. 17 → 21

~~TA3.4~~ In the following table, the tester shall outline the locations of all types of sensitive information and functions, adding to those provided where other types of sensitive information exist within the POI. This shall include both long-term and temporary storage locations, as well as information on any programmable logic used in the POI as part of the PIN storage/processing/entry circuit. The storage area column shall outline where and what type of storage is used for this information (such as …

TA4.2 In the following table, the tester shall outline the locations of all types of sensitive information and functions, adding to those provided where other types of sensitive information exist within the POI. This shall include both long-term and temporary storage locations, as well as information on any programmable logic used in the POI as part of the PIN storage/processing/entry circuit. The storage area column shall outline where and what type of storage is used for this information (such as …

Modified p. 18 → 22

~~TA3.6~~ For each of the integrated circuit elements (described above) which may be programmed or configured in some way, the tester shall ~~provide the following information:~~

TA4.5 For each of the integrated circuit elements (described above) which may be programmed or configured in some way, the tester shall enumerate:

Modified p. 18 → 22

a) ~~Enumerate the~~ different ways in which that element may be programmed or configured (for example, JTAG).

a) The different ways in which that element may be programmed or configured (for example, JTAG).

Modified p. 18 → 22

b) ~~Enumerate any~~ in-circuit testing or debugging features provided by these elements.

b) Any in-circuit testing or debugging features provided by these elements.

Modified p. 18 → 22

~~TA3.7~~ The tester shall detail what methods have been implemented to disable all of the programming/testing features outlined above. The tester shall detail the testing performed to validate that these features are indeed disabled. The tester shall justify why these measures are sufficient and confirm that these features cannot be re-enabled.

TA4.6 The tester shall detail what methods have been implemented to disable all of the programming/testing features outlined above. The tester shall detail the testing performed to validate that these features are indeed disabled. The tester shall justify why these measures are sufficient and confirm that these features cannot be re-enabled.

Modified p. 18 → 22

~~TA3.8~~ If additional memory is implemented and is not included in the sensitive-information storage areas above, the tester shall detail what processes have been used to validate that this is the case. The tester shall detail all memory in the device and detail where sensitive data is stored and how it is protected.

TA4.7 If additional memory is implemented and is not included in the sensitive-information storage areas above, the tester shall detail what processes have been used to validate that this is the case. The tester shall detail all memory in the device and detail where sensitive data is stored and how it is protected.

Modified p. 18 → 22

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

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

Modified p. 18 → 22

~~TA3.10~~ Where signatures are used as a method of protection, the tester shall:

TA4.9 Where signatures are used as a method of protection, the tester shall:

Modified p. 18 → 22

~~TA3.11~~ Where ~~physical protections are~~ used as a method of protection ~~(for example, when plaintext information is stored in external memory),~~ the tester shall:

TA4.10 Where encryption is used as a method of protection of sensitive information, the tester shall:

Modified p. 19 → 22

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

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

Modified p. 19 → 23

~~TA3.13~~ The tester shall analyze the device’s susceptibility to glitch attacks, including, but not restricted to, voltage and EM glitching. At a minimum, the tester shall consider the core and battery input for the security processor. Where applicable, the tester shall also consider embedded memory (SRAM, EEPROM, Flash, and ROM).

TA4.12 The tester shall analyze the device’s susceptibility to glitch attacks, including, but not restricted to, voltage and EM glitching. At a minimum, the tester shall consider the core and battery input for the security processor. Where applicable, the tester shall also consider embedded memory (SRAM, EEPROM, Flash, and ROM).

Modified p. 19 → 23

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

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.

Modified p. 19 → 23

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

Removed p. 20

Monitoring is to be done outside of the protected area of the device (in most cases: outside the PIN entry device).

TA4.1 The tester shall examine the vendor’s response to Section A4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI PTS POI Security Requirements for consistency relevant to A4. The vendor responses should clearly indicate how the device is protected from monitoring during PIN entry. The tester shall summarize the responses.

TA4.2 The tester shall examine and cite any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS POI Evaluation Vendor Questionnaire.

Modified p. 20 → 24

For ~~A4,~~ 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. 20 → 24

Methods such as video monitoring and shoulder surfing are addressed in ~~A7.~~

Methods such as video monitoring and shoulder surfing are addressed in A9.

Modified p. 20 → 24

Devices that use a randomized ~~touch-screen~~ layout

•i.e., for each PIN entry the positioning of the digits is different

•the signals should not contain any information that leads to PIN leakage.

Devices that use a randomized touchscreen layout

•i.e., for each PIN entry the positioning of the digits is different

•the signals should not contain any information that leads to PIN leakage. The lab must still validate through testing that the keypad is truly random.

Modified p. 20 → 24

~~TA4.3~~ The tester shall provide a circuit diagram of the input power circuitry of the POI, including any elements used to provide isolation of the power and EM emissions of the device.

TA5.1 The tester shall provide a circuit diagram of the input power circuitry of the POI, including any elements used to provide isolation of the power and EM emissions of the device.

Modified p. 20 → 24

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

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

Modified p. 20 → 24

~~TA4.5~~ The tester shall analyze the power captures obtained, as stated above, in both the time and frequency domains to determine whether any of the button presses provide a unique pattern that may be used to distinguish that button press from all others. The tester shall detail analysis and justify any conclusions drawn, referencing images where suitable as evidence. Generally, an initial observation of obtained signals is insufficient to validate that sensitive information does not leak. It is necessary to …

TA5.3 The tester shall analyze the power captures obtained, as stated above, in both the time and frequency domains to determine whether any of the button presses provide a unique pattern that may be used to distinguish that button press from all others. The tester shall detail analysis and justify any conclusions drawn, referencing images where suitable as evidence. Generally, an initial observation of obtained signals is insufficient to validate that sensitive information does not leak. It is necessary to …

Modified p. 20 → 24

~~TA4.6~~ Examine the layout and signal structure of the PIN input component (keypad) and determine how any sensitive information leakage by EM emissions may occur. Summarize findings.

TA5.4 Examine the layout and signal structure of the PIN input component (keypad) and determine how any sensitive information leakage by EM emissions may occur. Summarize findings.

Removed p. 21

The tester shall present evidence allowing test methodologies and results to be validated.

Modified p. 21 → 25

~~TA4.8~~ The tester shall analyze the ~~EM emissions (EME)~~ obtained ~~above~~ in both the time and frequency domains to determine whether any of the button presses provides a unique pattern that may be used to distinguish that button press from all others. The tester shall detail analysis and justify any conclusions drawn, referencing pictures where suitable as evidence. Generally, an initial observation of obtained signals is insufficient to validate that sensitive information does not leak. It is necessary to perform …

TA5.8 The tester shall analyze the acoustic captures obtained in TA5.7 in both the time and frequency domains to determine whether any of the button presses provides a unique pattern that may be used to distinguish that button press from all others. The tester shall detail analysis and justify any conclusions drawn, referencing pictures where suitable as evidence. Generally, an initial observation of obtained signals is insufficient to validate that sensitive information does not leak. It is necessary to perform …

Modified p. 21 → 25

~~TA4.9~~ Using suitable microphones, the tester shall use the microphones to monitor the acoustic signals of the POI when pressing each of the ten numeric buttons during a PIN entry function. The tester shall detail the methods used to capture sounds, providing photographs of the test setup and justifying the reason any particular location of the microphones was used (in preference to any other locations).

TA5.7 Using suitable microphones, the tester shall use the microphones to monitor the acoustic signals of the POI when pressing each of the ten numeric buttons during a PIN entry function. The tester shall detail the methods used to capture sounds, providing photographs of the test setup and justifying the reason any particular location of the microphones was used (in preference to any other locations).

Modified p. 21 → 25

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

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

Removed p. 22

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

Where a device exclusively supports DUKPT or similar unique key per transaction methodology for the protection of sensitive data, such as PINs, the side-channel analysis does not need to include these keys.

TA5.1 The tester shall examine the vendor’s response to Section A5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS POI Security Requirements for consistency relevant to A5. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any PIN-security-related cryptographic key resident in the device. The tester shall summarize the responses.

TA5.2 The tester shall examine and cite any relevant documentation, such as …

Modified p. 22 → 26

~~TA5.3~~ The tester ~~shall identify:~~

TA6.4 The tester shall:

Modified p. 22 → 26

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

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

Modified p. 22 → 26

~~TA5.5~~ The tester shall provide details on how cryptographic keys are stored and managed within the POI. The tester shall reference this information to the table provided in DTR ~~A3.~~ The tester shall detail the testing performed to confirm the storage locations listed are correct.

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

Modified p. 22 → 26

~~TA5.6~~ The tester shall provide details on any specific protections provided by the security processor that are designed to obstruct obtaining or determining the values of cryptographic keys.

TA6.3 The tester shall provide details on any specific protections provided by the security processor (or other processors if applicable) that are designed to obstruct obtaining or determining the values of cryptographic keys. If specific protections are unknown, the tester shall provide details on protections strongly inferred through testing.

Removed p. 23

TA5.8 Verify the items above, generally using source-code review, that the side-channel protection methods are implemented. For example, if the POI relies on protections provided by the processor hardware cryptographic engine, the tester shall confirm that the registers that enable this protection are correctly set by the POI firmware before every use of this cryptographic engine. If the protections are provided by the firmware, the tester shall check that the implementation is as described by the vendor. This evaluation activity may be focused at security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TA5.9 The tester shall perform preliminary side-channel analysis on the POI to characterize the cryptographic algorithms used to process sensitive data and/or operate with secret keys. Utilizing characterization results and knowledge of the POI physical design and software, the tester shall decide which side-channel attack paths provide …

Removed p. 24

TA5.12 The tester shall describe what protections are implemented within the cryptographic processing elements to protect against physical attacks at the chip level to extract the cryptographic keys. The tester shall review the source code of the POI to confirm that any protection measures relied upon are enabled and effective.

Modified p. 24 → 26

b) Refer to testing and results from DTR A3 where applicable.

b) Refer to testing and results from DTR A4 where applicable.

Modified p. 24 → 27

~~TA5.13~~ Referring to the information provided in DTR ~~A3,~~ the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the POI cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.

TA6.6 Referring to the information provided in DTR A4, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the POI cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.

Modified p. 24 → 27

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

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

Modified p. 24 → 27

~~TA5.15~~ The tester shall describe and cost the most feasible attack to recover cryptographic keys from the POI, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.

TA6.8 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the POI, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing. This information should include, at minimum:

Modified p. 24 → 27

~~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 only, as defined in Appendix B, the vendor assertion cannot be verified. At least …

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

Modified p. 24 → 27

~~TA5.16~~ If the attack costing for DTR A3 was found to be less than the minimum points required for this DTR, the tester shall justify why the attack for DTR A3 cannot be used to recover cryptographic keys.

TA6.9 If the attack costing for DTR A4 was found to be less than the minimum points required for this DTR, the tester shall justify why the attack for DTR A4 cannot be used to recover cryptographic keys.

Removed p. 25

TA6.1 The tester shall examine the assertions provided by the vendor in response to Section A6 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A6 of the PCI PTS POI Security Requirements for consistency relating to unauthorized alterations of prompts. The vendor responses should clearly indicate how display prompts are protected. The tester shall summarize the responses.

TA6.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information on how prompts are generated and administered to determine whether it is possible to perform unauthorized alterations of prompts.

Modified p. 25 → 32

A6 is applicable to a device that contains a display and may output non-PIN data.

A8 is applicable to a device that contains a display and may output non-PIN data.

Modified p. 25 → 32

A6 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. ~~B16~~ applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. ~~E3.4~~ is appropriate for unattended devices that do not meet any of the aforementioned.

A8 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. B15 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. C2.4 is appropriate for unattended devices that do not meet any of the aforementioned.

Modified p. 25 → 32

“Non-PIN data” refers to numeric data other than the PIN that is entered via the keypad.

“Non-PIN data” refers to numeric data other than the PIN that is entered via the keypad. It does not include control inputs such as “enter,” “cancel,” etc. It also does not apply to data entered while the device is in special modes (e.g., maintenance) that are not intended to be accessed by cardholders and merchants.

Modified p. 25 → 32

~~TA6.3~~ The tester shall describe whether the POI allows for entry of non-PIN data to be passed external to the POI and whether that data is protected during the transfer. This non-PIN data must not be encrypted using the PIN key of the POI. The tester shall complete the following steps if the POI provides such functionality.

TA8.1 The tester shall describe whether the POI allows for entry of non-PIN data to be passed external to the POI and whether that data is protected during the transfer. This non-PIN data must not be encrypted using the PIN key of the POI. The tester shall complete the following steps if the POI provides such functionality.

Modified p. 25 → 32

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

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

Modified p. 25 → 32

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

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

Modified p. 25 → 32

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

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

Modified p. 26 → 33

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.

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 examples shown in Appendix B in this document. Calculations shall include evidence justifying particular rating levels as being appropriate.

Removed p. 27

TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS POI Security Requirements for consistency relevant to A8. The vendor responses should clearly indicate how visual observation deterrents are provided. The tester shall summarize the responses.

TA7.5 The tester shall review any marketing literature and/or operations manuals provided with the POI, and state whether any of these explicitly describe handheld or desk-mounted operation or add-on components such as privacy shields. The tester shall detail any literature used to reach this conclusion.

Modified p. 27 → 34

~~TA7.2~~ The tester shall examine the means to deter the visual observation of PIN values provided by the device, and/or as described in the device documentation, to verify the assertions of the vendor. If the device provides physical observation deterrents, the tester shall show one or more images of these to support any conclusions.

TA9.1 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. 27 → 34

~~TA7.3~~ The tester shall describe whether the POI requires external power or communications connections or is intended to be operated with no external cable connections.

TA9.2 The tester shall describe whether the POI requires external power or communications connections or is intended to be operated with no external cable connections.

Modified p. 27 → 34

~~TA7.4~~ The tester shall review any marketing literature and/or operations manuals provided with the POI, and state whether any of these explicitly describe handheld or desk-mounted ~~operation.~~

TA9.3 The tester shall review any marketing literature and/or operations manuals provided with the POI, and state whether any of these explicitly describe handheld or desk-mounted operation or add-on components such as privacy shields. The tester shall detail any literature used to reach this conclusion.

Modified p. 27 → 34

~~TA7.6~~ The tester shall note whether the POI is intended to be deployed equipped with a privacy shield or whether the POI casing provides any fixture points, recess, or other indications that a privacy shield may be provided.

TA9.4 The tester shall note whether the POI is intended to be deployed equipped with a privacy shield or whether the POI casing provides any fixture points, recess, or other indications that a privacy shield may be provided.

Modified p. 27 → 34

~~TA7.7~~ The tester shall note whether the POI provides any screw points or other fixtures designed to facilitate the mounting of the POI into a stand or other receptacle that would preclude the device’s being operated in a handheld mode.

TA9.5 The tester shall note whether the POI provides any screw points or other fixtures designed to facilitate the mounting of the POI into a stand or other receptacle that would preclude the device’s being operated in a handheld mode.

Modified p. 28 → 35

Note: For a horizontal layout, exchange “width” and “length.” ~~TA7.9~~ Using the above information, the tester shall state whether the POI is designed such that handheld operation is enforced. The tester shall justify the conclusions.

Note: For a horizontal layout, exchange “width” and “length.” TA9.7 Using the above information, the tester shall state whether the POI is designed such that handheld operation is enforced. The tester shall justify the conclusions.

Modified p. 28 → 35

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

TA9.8 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.

Modified p. 28 → 35

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 that the acquirer or merchant must either meet the implementation criteria or deploy devices meeting the criteria defined in Appendix A, Section A1.1 or A1.2.

Angle of POI Angle of observation to Minimum angle required by Appendix A1.1 Minimum angle required by Appendix 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 that the acquirer or merchant must either meet the implementation criteria or deploy devices meeting the criteria defined in Appendix A, Section A1.1 or A1.2.

Modified p. 28 → 35

~~TA7.11~~ If the means to deter visual observation are not an integral part of the PIN entry device, the vendor shall specify by appropriate means (for example, drawings and description) how the visual observation is deterred by the structure or piece of equipment housing the device. These specifications shall be binding for the vendor and specified in the vendor security policy described in B20. The tester shall examine this specification to deter the visual observation of PIN values provided by …

TA9.9 If the means to deter visual observation are not an integral part of the PIN entry device, the vendor shall specify by appropriate means (for example, drawings and description) how the visual observation is deterred by the structure or piece of equipment housing the device. These specifications shall be binding for the vendor and specified in the vendor security policy described in B20. The tester shall examine this specification to deter the visual observation of PIN values provided by …

Modified p. 28 → 35

~~TA7.12~~ The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.

TA9.10 The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.

Removed p. 29

TA8.1 The tester shall examine the vendor’s response to Section A8 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement A8 of the PCI PTS POI Security Requirements for consistency relevant to A8. The vendor responses should clearly indicate how the magnetic-stripe reader is protected. The tester shall summarize the responses.

TA8.2 The tester shall examine and cite any additional relevant documentation, such as functional documentation, user guidance, test documentation and assembly drawings submitted by the vendor to verify that it supports the vendor responses.

Modified p. 29 → 36

Demonstrating compliance to this requirement requires the inclusion of high-resolution images and/or diagrams showing the ~~magnetic-stripe reader~~ and ~~its location.~~

Demonstrating compliance to this requirement requires the inclusion of high-resolution images and/or diagrams showing the different readers and their locations.

Modified p. 29 → 37

~~TA8.3~~ The tester shall describe whether the POI allows for capture of data from the magnetic stripe of a payment card. If the device processes magnetic-stripe information but does not integrate a magnetic-stripe card reader, the tester shall detail how magnetic-stripe information is obtained by the POI and provide any APIs used for this purpose. The tester shall only complete ~~the following~~ steps if the POI has an integrated magnetic-stripe card reader.

TA10.2 The tester shall describe whether the POI allows for capture of data from the magnetic stripe of a payment card. If the device processes magnetic-stripe information but does not integrate a magnetic-stripe card reader, the tester shall detail how magnetic-stripe information is obtained by the POI and provide any APIs used for this purpose. The tester shall only complete steps A10.3 through A10.9 if the POI has an integrated magnetic-stripe card reader.

Modified p. 29 → 37

~~TA8.4~~ The tester shall describe the location and operation of the magnetic-stripe card reader. The tester shall show one or more images of the device’s magnetic-stripe reader and associated hardware to support any conclusions.

TA10.3 The tester shall describe the location and operation of the magnetic-stripe card reader. The tester shall show one or more images of the device’s magnetic-stripe reader and associated hardware to support any conclusions.

Modified p. 29 → 37

~~TA8.5~~ The tester shall describe the path from the magnetic-stripe card reader to the security processor, including any cables, connectors, or other sub-elements on this path.

TA10.4 The tester shall describe the path from the magnetic-stripe card reader to the security processor, including any cables, connectors, or other sub-elements on this path.

Removed p. 30

TA8.10 The tester shall describe and provide the most feasible costing for recovery of magnetic-stripe card data from the POI, NOT including attacks attempting to install a second MSR head. If an attack attempting to install a second MSR head is potentially achievable (if there is available space), the tester shall additionally provide the most feasible costing for recover of magnetic- stripe card data using a malicious MSR head.

If an attack scenario can be developed that yields an attack potential of less than 16 per device for identification and initial exploitation or less than 8 per device for exploitation only, as defined in Appendix B, the vendor assertion cannot be verified. The tester may perform any test needed to validate the attack scenario. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing. At …

Modified p. 30 → 37

~~TA8.7~~ If the device implements physical protections for the magnetic-stripe card reader, either in addition to or in lieu of logical protections, the tester shall detail the physical protections implemented to protect this path. The tester shall justify how this is sufficient to protect the entire path of the magnetic-stripe card signals from the read head to the security processor, including all vias, traces, connectors, and the pins on the read head itself.

TA10.6 If the device implements physical protections for the magnetic-stripe card reader, either in addition to or in lieu of logical protections, the tester shall detail the physical protections implemented to protect this path. The tester shall justify how this is sufficient to protect the entire path of the magnetic-stripe card signals from the read head to the security processor, including all vias, traces, connectors, and the pins on the read head itself.

Modified p. 30 → 37

~~TA8.8~~ The tester shall provide measurements of any free space around the magnetic-stripe read head. The tester shall justify why placement of a secondary read head is made infeasible by the POI design, either through lack of space and/or through the physical protections of the POI. The tester shall check for any free space on the opposite site of the magnetic-stripe read head to analyze whether a reader with the capability to read heads regardless of the way the card …

TA10.7 The tester shall provide accurate measurements of any free space around the magnetic-stripe read head. The tester shall justify why placement of a secondary read head (even one that is very small and/or thin) is made infeasible by the POI design, either through lack of space and/or through the physical protections of the POI. The tester shall check for any free space on the opposite site of the magnetic-stripe read head to analyze whether a reader with the capability …

Modified p. 30 → 37

~~TA8.9~~ The tester shall identify whether the device implements any physical or logical ICCR/MSR combinations•for example, if the hybrid reader facilitates both skimming of the magnetic stripe and capture of the PIN during an ICCR “dip” read operation. In this case, the tester shall describe how there is no residual vulnerability to attacks on the combination reader intending to harvest both clear-text PINs and magnetic-stripe data.

TA10.8 The tester shall identify whether the device implements any physical or logical ICCR/MSR combinations•for example, if the hybrid reader facilitates both skimming of the magnetic stripe and capture of the PIN during an ICCR “dip” read operation. In this case, the tester shall describe how there is no residual vulnerability to attacks on the combination reader intending to harvest both clear-text PINs and magnetic-stripe data.

Removed p. 31

The objective of this requirement is to assess the device’s ability to protect the component against removal from its frame or the cabinet. This protection aims against component device overlays or chained ICC readers; it also aims at complicating attacks against the component wherein it is taken away by attackers in order to perform subsequent attack steps under controlled conditions. This requirement applies to components that are used for PIN entry or handle the PIN, such as an ICCR.

Installation or removal of the device requires an authorized process. An authorized installation must provide traceability and accountability (what happened, when, and who did it).

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.

Protection against removal may be implemented as detection of removal and …

Removed p. 32

• By secret and private key erasure, or

• By having the device go to an unauthorized state upon removal, requiring an authorized re-installation process.

TA9.5 The tester shall review the device literature provided by the vendor, as well as perform a search of publically available information. The tester shall note whether any information is found to indicate that the POI may be used in an unattended environment.

TA9.6 The tester shall review the device security policy and note whether this clearly states the environments in which the POI is intended for use (attended, unattended or both). If the device is not intended for use in an unattended environment, no further testing is necessary.

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

TA9.8 The tester shall detail the testing apparatus used to emulate the POI …

Modified p. 33 → 55

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

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

Removed p. 34

Internal generation of a cryptographic signature is valid right after firmware update, assuming it complies with Requirement B4; it is also valid for devices that do not allow for software updates outside of the factory.

Removed p. 35

TB1.3 The tester shall describe the boot chain of the POI. The tester shall Include how initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are sequenced, loaded, and executed, up to and including software modules used for PIN entry functions, account data processing, and OP modules.

TB1.4 The tester shall verify that the device performs self-tests upon start upon and on a periodic basis at least once per day to check firmware and security mechanisms for signs of tampering, and whether the device is in a compromised state. The tester shall activate the self-test(s) and look for the result of the self-test(s) as shown by the device.

TB1.5 The tester shall verify that the device self-tests are able to detect failures and in doing so, fail in a secure manner. The vendor shall provide evidence of testing that confirms the relevant component’s fails …

Removed p. 36

TB1.13 The tester shall perform testing to verify that the device reinitializes memory at least every 24 hours. The tester shall activate the mechanism and look for the result as shown by the device.

TB1.14 The tester shall review the source code of the POI to confirm how it is ensured that the re- initialization process is repeated every 24 hours or less.

TB1.15 The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.

Removed p. 37

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 or through a hub, switch, or other multiport device. In addition, any communication that uses a public domain protocol or security protocol would be assessed with the Open Protocol Module.

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 …

Removed p. 38

TB2.8 If the device includes command-execution interfaces or parsers: The tester shall detail how each of the above interfaces is configured to accept commands•for example, whether a command executive is used, or other methods are used to parse input commands. The tester shall define which common functionalities exist between interfaces to determine which test approaches may be applied in common to more than one interface.

TB2.9 The tester shall detail in an appendix to the evaluation report a complete list of all APIs as defined by the vendor that are provided on each of the logical interfaces of the POI.

TB2.10 The tester shall perform a source-code review of each relevant interface and confirm that it is handled securely, that only documented commands are implemented, and that secure defaults are provided for each interface. The tester shall detail the methods used to verify the length and content of each command before processing. …

Removed p. 39

TB2.15 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.

Removed p. 40

Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, except for SCRs intended for use with COTS devices and SCRPs, where all code is considered firmware.

• Mitigating them by techniques that include but are not limited to: Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Harvard Architecture and Stack Canaries.

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

TB3.1 The tester shall examine the response to Section B3 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS POI Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how …

Removed p. 41

TB3.7 The tester shall confirm that

•and summarize how

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

TB3.8 The tester shall confirm that

•and summarize how

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

TB3.9 The tester shall confirm that

•and summarize how

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

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

TB3.11 The tester shall …

Removed p. 42

TB3.17 The tester shall outline the following information: If the firmware is based on a general-purpose operating system (like Linux or Windows CE), the steps described in TB3.15, in particular, hold for this operating system. The documentation provided by the developer shall show that state- of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues (like patch levels; not including unused packages, etc.; not being 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 …

Removed p. 43

The firmware and application version numbers, and optionally the hardware version number must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. This shall be illustrated by photographic evidence provided in the evaluation report.

For SCRPs and SCRs intended for use with commercial-off-the-shelf devicese.g., mobile phones and tabletsthe SCRPs and SCRs must respond with their model name/number, hardware version, firmware version(s), and a unique device identifier to a query from the PIN CVM application on the COTS device.

If done between physically and logically disparate components it must use a secure channel as follows:

TB4.1 The tester shall examine the response to Section B4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI PTS POI Security Requirements for consistency relating to the authentication procedures for firmware updates. The vendor responses …

Removed p. 44

TB4.4 The tester shall determine by which component the authentication is performed.

TB4.5 The tester shall determine the level of protection for the external component involved in firmware/software updates and that the authentication of firmware updates is performed by a component of equal or greater strength.

TB4.6 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.

Removed p. 44

TB4.7 For each of the processing elements listed in DTR A3, the tester shall complete the following table. (See Annex A of the Vendor Questionnaire.) Where different parts of the code can be updated independently (for example, boot code, main firmware, etc.), or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well.

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.8 The tester shall review the source code of the POI to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the POI. This evaluation activity should be focused at relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation …

Removed p. 45

TB4.11 If a CBC MAC is used for firmware authentication, the tester shall detail what methods are used to mitigate vulnerabilities when authenticating variable-length data.

TB4.12 For each of the methods of authentication, the tester shall obtain a correctly authenticated firmware image and:

Removed p. 45

c) Change a single bit in the firmware block of the image, and confirm that this modified image is rejected when loaded into the POI.

TB4.13 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.

TB4.14 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version numbers, and optionally the hardware version number during startup or on request. This includes all firmware numbers where Core, SRED and OP have different numbering.

For SCRPs and SCRs intended for use with commercial-off-the-shelf devices, the tester shall confirm that the SCRPs and SCRs respond with their model name/number, hardware version, firmware version(s), and …

Removed p. 46

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 tester shall summarize the responses TB4.1.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to application loading and application/configuration updates, including remote access, to determine whether it supports the assertions made by the vendor.

TB4.1.3 The tester shall determine by which component the authentication is performed.

TB4.1.4 The tester shall determine the rank of protection strength for the component involved in application loads

•and if applicable, software and/or configuration updates

•and that the authentication is performed by an …

Removed p. 47

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

TB4.1.8 If (H)MAC method(s) are used for application authentication, the tester shall confirm through source-code review that the method used to compare the application-authentication block does not leak timing information•for example, the “C” memcmp() function is not used. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB4.1.9 If a CBC MAC is used for application authentication, the tester shall detail what methods are used to mitigate vulnerabilities …

Removed p. 48

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

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 relates to firmware and software signing to determine whether it supports the assertions made by the vendor.

TB4.2.3 The tester shall verify that the signing process can only be performed under dual control and that the software is only signed using a secure cryptographic device provided by the vendor.

TB4.2.4 The tester shall …

Removed p. 50

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:

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

The tester shall summarize the 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.

Modified p. 50 → 57

The device must automatically clear its internal buffers when either:

The device must automatically clear its internal buffers of full track data (or chip equivalent) and sensitive authentication data is cleared when either:

Modified p. 50 → 57

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

Plaintext PINs must not exist for more than ninety seconds maximum from the completion of the cardholder’s PIN entry. In all cases, erasure of the plaintext PIN must occur before the tamper- detection mechanisms can be disabled using attack methods described in A2.

Modified p. 50 → 57

~~TB6.3~~ The tester shall verify that

•and summarize how

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

TB4.1 The tester shall verify that

•and summarize how

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

Modified p. 50 → 57

~~TB6.4~~ The tester shall review the source code of the POI and confirm that

•and summarize how

TB4.2 The tester shall review the source code of the POI and confirm that

•and summarize how

Modified p. 50 → 57

~~TB6.5~~ The tester shall detail the method used by the vendor to ensure that this buffer-clearing code/function cannot be removed by compiler optimizations or other means of code optimization, if employed by the vendor.

TB4.3 The tester shall detail the method used by the vendor to ensure that this buffer-clearing code/function cannot be removed by compiler optimizations or other means of code optimization, if employed by the vendor.

Modified p. 51 → 58

~~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 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 ~~TB6.1.~~

TB4.6 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 TB4.

Removed p. 52

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.

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. 52 → 59

Authentication shall require ~~dual control~~ techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material.

Authentication shall require dual-control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. In all cases, the authentication values (passwords, authentication codes, or similar) on a given device must be different for each user.

Modified p. 52 → 59

~~TB7.3~~ The tester shall verify from vendor documentation

•and summarize

•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords/authentication codes. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.

TB5.1 The tester shall verify from vendor documentation

•and summarize

•that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords/authentication codes. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.

Modified p. 52 → 59

~~TB7.4~~ If access to sensitive services requires input by the keypad, the tester shall verify and describe that the protections for PIN data, such as the following, are also afforded to data entered while accessing sensitive services:

TB5.2 If access to sensitive services requires input by the keypad, the tester shall verify and describe that the protections for PIN data, such as the following, are also afforded to data entered while accessing sensitive services:

Modified p. 52 → 59

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

TB5.3 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.

Modified p. 53 → 60

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

Cryptographic Method of loading per Authentication TMK Components through keypad Two seven-character passwords through keypad Encrypted under PKman Provided by encryption Plaintext through serial port Operator authentication provided on key-loading device Pkman Embedded in firmware Two eight-character passwords required to operate firmware loading TB5.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods.

Modified p. 53 → 61

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.

The tester shall include a reference to the method used in each of the rows in the table above.

Modified p. 53 → 61

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

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

Modified p. 53 → 61

~~TB7.9~~ The tester shall detail any further sensitive services provided by the POI that have not been addressed as defined above. This must include the disabling or alteration of any systems or functions relied upon by the POI to meet the PTS requirements. Examples include but are not limited ~~to: disabling removal detection,~~ changing SRED encryption ~~modes,~~ or altering system time that may be used to verify certificate validity (or used for other system security services).

TB5.7 The tester shall detail any further sensitive services provided by the POI that have not been addressed as defined above. This must include the disabling or alteration of any systems or functions relied upon by the POI to meet the PTS requirements. Examples include but are not limited to changing SRED encryption modes or altering system time that may be used to verify certificate validity (or used for other system security services).

Modified p. 53 → 61

~~TB7.10~~ The tester shall confirm that and describe how any entry of sensitive information through the keypad of the POI is protected to the same extent as customer PINs, conforming to all relevant requirements ~~(such as~~ A1, ~~A3,~~ and ~~A5).~~

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

Modified p. 53 → 61

~~TB7.11~~ For any asymmetric key-loading methods, the tester shall provide a message-flow diagram showing the contents of each data packet exchanged during the asymmetric key-loading process, including any authentication parameters, freshness indicators, and padding. From this diagram, for each asymmetric key-loading method, the tester shall provide the following justifications:

TB5.9 For any asymmetric key-loading methods, the tester shall provide a message-flow diagram showing the contents of each data packet exchanged during the asymmetric key-loading process, including any authentication parameters, freshness indicators, and padding. From this diagram, for each asymmetric key-loading method, the tester shall provide the following justifications:

Modified p. 53 → 61

d) Why the protocol provides mutual authentication of the POI and host before any cryptographic key is used for a security-sensitive process (such as ~~encrypting customer PINs).~~

d) Why the protocol provides mutual authentication of the POI and host before any cryptographic key is used for a security-sensitive process (such as cryptographic key loading).

Modified p. 54 → 62

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

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

Modified p. 54 → 62

~~TB7.14~~ The tester shall validate that

•and describe how

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

TB5.12 The tester shall validate that

•and describe how

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

Modified p. 54 → 62

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

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

Modified p. 54 → 62

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

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

Modified p. 54 → 62

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

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

Removed p. 55

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.

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.

TB8.3 The tester shall examine the rationale provided by the vendor in Section B8 of the PCI PTS POI Evaluation Vendor Questionnaire to verify the following:

Modified p. 55 → 63

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

TB6.2 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. 55 → 63

~~TB8.5~~ Referencing the sensitive services outlined in the previous requirement, the tester shall detail the functional limits provided for each of these services.

TB6.3 Referencing the sensitive services outlined in the previous requirement, the tester shall detail the functional limits provided for each of these services.

Modified p. 55 → 63

~~TB8.6~~ For any password-entry modes, the tester shall detail how the functional limits ensure that any arbitrary password/authentication code guess has less than a 1/10000000 chance of success, and any multiple attempts within a one-minute period have a less than 1/10000 chance of success of correctly providing the password/authentication code value. The tester shall detail the testing performed to validate these functional limits.

TB6.4 For any password-entry modes, the tester shall detail how the functional limits ensure that any arbitrary password/authentication code guess has less than a 1/10000000 chance of success, and any multiple attempts within a one-minute period have a less than 1/10000 chance of success of correctly providing the password/authentication code value. The tester shall detail the testing performed to validate these functional limits.

Modified p. 55 → 63

~~TB8.7~~ For any password-entry modes, the tester shall confirm through source code examination that the method of validating the password/authentication code value is not vulnerable to a timing attack (for example, a standard “strcmp” or “memcmp” function is not used), or that the functional limits are set to values that prevent utilization of any leaked timing information. This evaluation activity should be focused at relevant, security-critical sections of the source code to provide an optimum balance between use of evaluation …

TB6.5 For any password-entry modes, the tester shall confirm through source code examination that the method of validating the password/authentication code value is not vulnerable to a timing attack (for example, a standard “strcmp” or “memcmp” function is not used), or that the functional limits are set to values that prevent utilization of any leaked timing information. This evaluation activity should be focused at relevant, security-critical sections of the source code to provide an optimum balance between use of evaluation …

Modified p. 55 → 63

~~TB8.8~~ For all sensitive services, excluding loading of encrypted key values but including loading of plaintext key value from an external key-loading device, the tester shall confirm that a timer is implemented that will return the POI to a non-sensitive mode after a maximum of 15 minutes, regardless of input or continued activity.

TB6.6 For all sensitive services, excluding loading of encrypted key values but including loading of plaintext key value from an external key-loading device, the tester shall confirm that a timer is implemented that will return the POI to a non-sensitive mode after a maximum of 15 minutes, regardless of input or continued activity.

Modified p. 56 → 64

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

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

Removed p. 57

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.

TB9.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. 57 → 65

The device shall be capable of meeting the statistical tests of NIST SP PUB ~~800-22).~~ See Appendix D.

The device shall be capable of meeting the statistical tests of NIST SP PUB 800-22. See Appendix D.

Modified p. 57 → 65

The scope of this requirement includes random numbers that are generated in connection with meeting requirements ~~in the~~ Open Protocols and Secure Reading and Exchange of ~~Data Modules.~~

The scope of this requirement includes random numbers that are generated in connection with meeting requirements applicable for Open Protocols and Secure Reading and Exchange of Data.

Modified p. 57 → 65

B9 is mandatory for the SCRP approval class in order to provide a source of entropy for the PIN CVM application. It is a requirement that any random numbers used on the COTS device for security purposes must be seeded from a value provided from the RNG on an ~~external~~ SCRP.

B7 is mandatory for the SCRP approval class in order to provide a source of entropy for the PIN CVM application. It is a requirement that any random numbers used on the COTS device for security purposes must be seeded from a value provided from the RNG on an SCRP.

Modified p. 57 → 65

~~TB9.3~~ The tester shall detail the method used by the POI to generate random numbers, including any seed values used, hardware systems, and software-based DRBGs.

TB7.1 The tester shall detail the method used by the POI to generate random numbers, including any seed values used, hardware systems, and software-based DRBGs.

Modified p. 58 → 66

~~TB9.6~~ The tester shall review the source code of each of these services and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

TB7.4 The tester shall review the source code of each of these services and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

Modified p. 58 → 66

~~TB9.7~~ The tester shall obtain at least 128MB of random data from the POI under test. This data may be supplied directly by the vendor. The tester shall detail the method used to generate this data and justify why this sufficiently replicates the way in which the RNG will be used by the POI. The tester shall pass the 128MB of data through the NIST STS test program, and detail the results, indicating pass and fail results and how these …

TB7.5 The tester shall obtain at least 128MB of random data from the POI under test. This data may be supplied directly by the vendor. The tester shall detail the method used to generate this data and justify why this sufficiently replicates the way in which the RNG will be used by the POI. The tester shall pass the 128MB of data through the NIST STS test program, and detail the results, indicating pass and fail results and how these …

Removed p. 59

TB10.1 The tester shall examine the response to Section B10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS POI Security Requirements for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PIN determination. The tester shall summarize the responses.

TB10.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. 59 → 67

• Use of a ~~unique key per transaction~~ technique. (Prevents the attack.)

• Use of a unique-key-per-transaction technique. (Prevents the attack.)

Modified p. 59 → 67

• Preventing the entry of the PIN through other than the keypad, and limiting the rate at which the device will encrypt PINs to the average (for example, over 120 transactions) of one per 30 seconds. (Deters the attack.)

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

Modified p. 59 → 67

• The exclusive use of ISO PIN-block formats ~~1, 3,~~ and/or 4 whereby each PIN is enciphered using a unique except by chance random pad of characters with permissible values ranging from 0000 to 1111 depending on the format may be used to prevent exhaustive PIN determination.

• The exclusive use of ISO PIN-block formats 3 and/or 4 whereby each PIN is enciphered using a unique except by chance random pad of characters with permissible values ranging from 0000 to 1111 depending on the format may be used to prevent exhaustive PIN determination.

Modified p. 59 → 67

~~TB10.3~~ The tester shall note whether the POI only supports key-management methods that ensure a unique key is used for each PIN encryption. If this is the case, the tester shall justify why the methods used to ensure a unique key are sufficient, and no further testing is necessary for this requirement.

TB8.1 The tester shall note whether the POI only supports key-management methods that ensure a unique key is used for each PIN encryption. If this is the case, the tester shall justify why the methods used to ensure a unique key are sufficient, and no further testing is necessary for this requirement.

Modified p. 59 → 67

~~TB10.4~~ The tester shall note whether the POI only supports ISO format 4 or format 3 ~~or ISO format 1~~ PIN blocks. If so, the tester shall review the source code of the POI to confirm that the padding used on these PIN blocks is generated by the random number generator validated under Requirement ~~B9.~~ If this is the case, no further testing is necessary for this requirement.

TB8.2 The tester shall note whether the POI only supports for online PIN ISO format 4 or ISO format 3 PIN blocks. If so, the tester shall review the source code of the POI to confirm that the padding used on these PIN blocks is generated by the random number generator validated under Requirement B7. If this is the case, no further testing is necessary for this requirement.

Modified p. 60 → 68

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

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

Modified p. 60 → 68

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

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

Modified p. 60 → 68

~~TB10.9~~ If the method used to prevent the entry of more than 120 PINs within an hour utilizes the real- time clock of the POI, the tester shall detail what methods are available to change the value of this clock and justify why these methods do not allow for the bypassing of the PIN entry rate limiting.

TB8.7 If the method used to prevent the entry of more than 120 PINs within an hour utilizes the real- time clock of the POI, the tester shall detail what methods are available to change the value of this clock and justify why these methods do not allow for the bypassing of the PIN entry rate limiting.

Removed p. 61

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.

TR-31 support or equivalent must use a key-derivation methodology. The device may optionally support, in addition, the key calculation methodology.

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 generated randomly or pseudo-randomly;

• Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;

• Be used in the appropriate order as specified by the particular mode;

• Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and

• Cannot be unbundled …

Modified p. 61 → 70

~~Devices~~ must ~~support TR-31 or an equivalent methodology~~ for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.

These methods must be used for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual control techniques.

Modified p. 61 → 70

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

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

Removed p. 62

Devices that are “bound” as stated above shall support a technique for decommissioning for unbinding from a specific host. Decommissions, such as sending a new host’s certificate to replace the existing host’s certificate without authentication, are not acceptable. Any remote decommissioning must require cryptographic techniques and be specific per PIN-acceptance device. Acceptable techniques include:

1. The existing bound host can digitally sign an “unbind” command to the PIN-acceptance device, that when validated returns the PIN-acceptance device to its original unbound state. 2. In situations where the bound host’s private key is not available to sign the command, or similar scenarios, a forced decommission may occur. However, any such decommission done remotely requires a cryptographic (digital signature, MAC, etc.) technique and must be unique per PIN-acceptance device. 3. Decommissions may also be done manually directly at the device, using system administration menus that authenticate users via PINs, passphrases, etc.

Other acceptable techniques include …

Modified p. 62 → 71

• Loaded using asymmetric keys of equivalent or greater strength

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

• Loaded using asymmetric keys of equivalent or greater strength

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

Modified p. 62 → 71

• Encrypted by another AES key of equal or greater strength; or

• Encrypted or derived by another AES key of equal or greater strength; or

Modified p. 62 → 71

• Internally generated using a random number generator compliant with ~~B9.~~

• Internally generated using a random number generator compliant with B7.

Removed p. 63

SCRPs shall provide for the use of cryptographic keys stored within the SCRP to provide security to the provisioning process. This process loads cryptographic keys and other data to the PIN CVM application upon initial configuration as described in DTR B8: Secure Provisioning of the PCI Software-based PIN Entry on COTS DTRs.

TB11.1 The tester shall examine the response to Section B11 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B11 of the PCI PTS POI Security Requirements for consistency relating to the method of key management in use in the device. The tester shall summarize the responses.

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

TB11.3 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key …

Removed p. 64

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.

d) Remote key-loading techniques using public key methods requires compliance with PCI defined criteria for key sizes and mutual authentication between host and device. For devices generating their own key values, the generation process must meet the criteria defined in the random number appendix of the DTRs and validation that appropriate key sizes are used. The protocol must meet the criteria stipulated in Annex A of the PCI PIN Security Requirements. See below for further information.

TB11.6 The minimum key sizes and parameters for the algorithm(s) in question that …

Removed p. 65

TB11.13 The tester shall detail any other types of key management or cryptographic keys used by the POI. This should include any keys used for firmware or application authentication, self-testing, boot strapping, remote key injection, local key injection, dual control, etc.

Removed p. 68

Note: The “Size” column must note both the maximum and minimum sizes that can be used for that key.

TB11.15 Using the key table as a reference, the tester shall note which keys are actively erased by the POI during a tamper event, and which keys are not erased but instead rely upon the erasure of a KEK to prevent their subsequent misuse.

TB11.16 Using the key table as a reference, the tester shall confirm that all secret and private keys are unique per device, and what method is used to ensure this is the case.

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:

b) Plaintext cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used …

Removed p. 69

TB11.21 The tester shall detail the method used by the POI to confirm that no one key can take the same value as any other key within the POI. Through source-code review confirm the following:

a) The method used does not provide a potential timing attack on the POI•for example, by using a standard C “memcmp()” function to compare all keys.

b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to values as defined in TB11.22 or they are never output from the POI.

TB11.22 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value except as noted below

Note: Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal …

Removed p. 70

TB11.26 For any methods that rely on the use of full-length key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. For key shares, the tester shall use the same value for all but one share to perform the aforementioned.

TB11.27 The tester shall confirm that if the device supports remote key loading using asymmetric techniques that it utilizes an acceptable method to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices.

TB11.28 The tester shall confirm that for a device supporting remote key loading using asymmetric techniques using a “binding” technique, it supports an acceptable method for unbinding in the event of …

Removed p. 71

The device must support at least one of the following key-management techniques using TDES as described in ANSI X9.24 and ISO/IEC 18033-3:

• Master/Session SCRPs shall not support Fixed key management for TDES.

b) Where the ICC reader is not integrated into the PIN entry device, and PINs are enciphered only for transmission between the PIN entry device and the IC reader, the device shall use one of the PIN-block formats specified in ISO 9564-1. Where ISO format 2 PIN blocks are used, a unique key per transaction method in accordance with ISO 11568 shall be used. Format 2 shall be used only in connection with either offline PIN verification or PIN-change operations in connection with ICC environments.

TB12.1 The tester shall examine the response to Section B12 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS POI Security Requirements for consistency relating to …

Removed p. 72

TB12.4 From the above list of PIN-block formats, the tester shall confirm that the POI supports at least one format that is compliant with ISO 9564 (format 0, 1, 3 or 4 for online PINs if the device supports online PIN, and format 2 for offline PINs if the device supports offline PIN).

TB12.5 The tester shall confirm that SCRPs support the use of a unique-per-transaction, AES PIN- encryption key for conveyance of PINs from the PIN CVM application on the COTS device and detail the methods used to generate this key.

TB12.6 The tester shall detail all methods that the POI supports for external PIN transfer. This will include encryption of PINs for transport to an acquiring financial institution, as well as transfer to any external card readers or other devices/sub-components outside of the area of the POI validated as secure under Requirement A1.

TB12.7 From the above information, the tester shall …

Removed p. 73

The device must enforce that data keys, key-encipherment keys, and PIN-encryption keys have different values.

A secret key used to encrypt a PIN must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose. However, variants of the same key may be used for different purposes. Any key calculated as a variant of another key shall be protected in a manner equivalent to or greater in security as the original key•i.e., under the principles of dual control and split knowledge. E.g., 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.

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 …

Removed p. 74

b) Key-encrypting keys are only used to encrypt keys.

c) PIN keys shall never be used to encrypt keys.

d) Key-encrypting keys shall never be used to encrypt PIN data.

e) Data keys shall never be used to encrypt other keys or PIN data.

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:

TB13.5 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 shall …

Removed p. 75

TB14.1 The tester shall examine the response to Section B14 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement B14 of the PCI PTS POI Security Requirements for consistency relating to the output of clear-text keys and the protection of PINs. The clear-text PIN must never exist in an unprotected environment. The tester shall summarize the responses.

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.

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.4 The tester shall examine any additional documentation (i.e., API programmer’s guide, specifications, block diagrams, etc.) containing information …

Removed p. 76

For devices implementing at the same time a touch screen for PIN entry and a separate keypad, these must have a default entry mode; switching to the other mode requires an explicit operation on the device, which remains valid for one transaction.

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.

TB15.2 The tester shall review the API guide and any other relevant documentation of the POI and note whether it is possible for a PIN entry prompt and a non-PIN entry prompt to be displayed on the screen at the same time.

TB15.3 The tester shall review the source code and detail what protections are provided to ensure that only encrypted data (as verified in Requirement B12) can be …

Removed p. 77

A6 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. B16 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. E3.4 is appropriate for unattended devices that do not meet any of the aforementioned.

B16 applies to both acquirer and vendor-controlled prompts that are updatable.

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

Dual control must be enforced by an SCD. The SCD can be the PED itself or another device. If an SCD other than the PED enforces dual control, the vendor must either provide the SCD to third parties, or describe how an SCD must be used to comply with B16. The description must include an example of a specific, existing SCD that can be purchased and used to comply with B16. …

Removed p. 78

TB16.2 The tester shall examine all possible prompts to determine whether any can be used in conjunction with numeric entry in the clear.

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.

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

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

TB16.6 The tester shall note how …

Removed p. 79

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

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

The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. Specifically, those applications must be validated to ensure that:

• They cannot adversely affect the security features of the product that are relevant to the PCI POI approval.

• They cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.

• The application is authenticated to the POI secure controller by digital signature.

• The application can only work on the keys it alone manages and cannot affect or see any other keys. A mechanism must exist to display the application version upon request.

Focal point is for sensitive data and sensitive functions.

TB17.1 The tester shall examine the …

Removed p. 81

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.

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

Removed p. 83

The intended operation is considered as the functionality relevant to B2, to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access.

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

Vendors should provide configuration lists and software specifications to support answers.

If the OS supports multiple privilege levels or user privileges, the least privileges are assigned according to the “need to have” principle; a single supervisory mode implementation

•e.g., root or equivalent

•is not allowed. The payment application must have less privilege than the …

Removed p. 84

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

TB18.10 The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the POI execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce the functionality of the POI to only those components and services necessary for the intended operation of the device.

Removed p. 85

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.

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.

Removed p. 86

• General Description (DTRs B20.2

• B20.6)

• Installation and Guidance (DTRs B20.7

•B20.18)

• Operation and Maintenance (DTRs B20.19

• B20.27)

• Security (DTRs B20.28

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

See Appendix H for an example of an acceptable Security Policy layout.

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 examine the security policy to verify that the device is properly identified.

Product name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions and the exact approval class and use case of the device. The tester shall check and …

Removed p. 87

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

TB20.6 The tester shall confirm that if the device supports SSL, the security policy must clearly state that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan.

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

TB20.8 The tester shall examine the security policy to verify that it identifies all conditions (for example, voltage, humidity, and temperature) that will cause environmental failure-protection mechanisms to trigger.

TB20.9 The tester shall confirm that the security policy includes all configuration settings necessary to meet the …

Removed p. 88

TB20.19 The tester shall confirm that the security policy includes procedures for the decommissioning of devices that are removed from service, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device. The procedures may differentiate between temporary and permanent removal.

TB20.20 For privacy shielding the tester shall perform the following tests:

TB20.21 The tester shall confirm that the security policy contains information on how the device will indicate a tamper-response event, and any requirements for the return of this device to the vendor for examination following such an event (as required for compliance to DTR A1).

TB20.22 The tester shall examine the security policy and relevant vendor documentation to verify that any periodic maintenance procedures required for the secure operation of the device are included in the security policy.

TB20.23 The tester shall examine the security policy to verify that it identifies all self-tests …

Removed p. 89

TB20.30 The tester shall confirm that the security policy contains specific details on any account data protection schemes employed

•e.g., algorithms used, format-preserving encryption techniques

•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.

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

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

TB20.33 The tester shall examine the security policy to verify that it states that keys should be replaced with new keys whenever the compromise …

Removed p. 90

C1 is not applicable to devices that do not include commands for external key selection or cannot hold multiple key hierarchies related to PIN encryption.

TC1.1 The tester shall examine the response to Section C1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS POI Security Requirements for consistency relating to multiple keys and unauthorized key replacement and key misuse. The tester shall summarize the responses.

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.

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

TC1.4 The tester shall note whether the POI enforces the use of dual control (within the firmware of the POI) to load these keys. The tester shall reference testing of these dual-control …

Removed p. 91

A PIN-disclosing bug shall be prevented from being inserted into the device through the card slot. The volume of space accessible via the card slot that could be utilized by an attacker can vary with the geometry of the space and attack methods. For this reason, the requirement does not prohibit a specific volume. Rather, the feasibility of effective bug placement is to be considered when assessing D1 compliance. Examples of these considerations are:

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.

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.

TD1.3 The tester shall examine the device to verify that …

Removed p. 92

TD1.6 The tester shall develop an attack scenario to enlarge the slot.

TD1.7 The tester shall perform a simulated transaction whilst inserting two unembossed cards into the slot. If it is possible to insert two cards and perform the transaction, then the device does not comply with this requirement. The tester shall measure the IC slot width, height (or different heights), and depth and record these, referring to an image of the IC slot opening location.

TD1.8 The tester shall provide and reference a picture of the area of the POI where the ICC acceptor is located.

TD1.9 The tester shall provide and reference a picture of the ICC acceptor itself. The tester shall note the manufacturer and model of the acceptor used.

TD1.10 The tester shall detail any active detection mechanisms the ICC acceptor utilizes to prevent a “shim” from being left in the slot. Where active protections are not present, the tester …

Removed p. 93

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 signal with a probe, such as a metal pin (either straight or bent) inserted through a hole in the casing of the POI at any point.

TD1.18 From the above description the tester shall explain how the POI is rendered inoperative after a tamper event in the ICC-acceptor area.

TD1.19 The tester shall describe and provide a costing for the most feasible attack to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data. The tester shall detail where costing information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.

If an …

Removed p. 94

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.

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.3 The tester shall provide a picture of the external area view of the customer ICC acceptor. The tester shall justify how this picture shows that the opening is in full view of the customer during a transaction, so that any objects within the slot would be clearly …

Removed p. 95

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.

TD3.2 The tester shall examine a test device to verify vendor assertions that the ICC reader is constructed so that wires running out of the slot can be observed by the cardholder. The reader enclosure shall not have any seams or channels around the slot that would allow the concealment of wires.

TD3.3 The tester shall provide a picture of the external ICC slot. The tester shall note whether the slot is formed as one whole plastic part or is formed within the part line of two or more plastic parts.

TD3.4 If the POI is supplied with any add-on parts, such as privacy shields, stands, additional card readers, etc., …

Removed p. 96

If the device encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:

DTRs A1 and D1 verify the physical protections relevant to DTR D4.

D4 requires that the following be met:

• PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique key per transaction method in accordance with ISO 11568 shall be used.

Removed p. 97

TD4.2 The tester shall note whether the customer ICC acceptor is integrated into a single, secure enclosure with the customer PIN entry mechanism and security processor, or the ICC acceptor is a separate part.

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

TD4.4 If the ICC acceptor is a separate part, the tester shall detail how the customer PIN is encrypted for transmission between the two parts. This encryption must use ISO 9564-compliant PIN blocks and encryption mechanisms (an authenticated encipherment key of the ICC or TDES). The tester shall review the source code that performs the PIN-block formatting and encryption and …

Removed p. 98

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.

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.

Removed p. 99

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.

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.

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.

TE2.1.3 The tester shall examine that the integration of every PCI-approved secure component has been performed strictly according to the component manufacturer recommendations.

TE2.1.4 The tester …

Removed p. 100

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 in this document.

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.

Removed p. 101

Protocol fault injections are covered by Requirement B2, whereas protocol abuses through regular requests are covered by this requirement.

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.

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.

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

Removed p. 102

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.

TE3.2.2 The tester shall visually inspect the device's card reader and/or the device in general to verify the assertions provided by the vendor in response to Section E3.2 PCI PTS POI Evaluation Vendor Questionnaire.

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

TE3.2.4 The tester shall perform suitable test to verify the functionality of the mechanisms.

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 …

Removed p. 103

TE3.3.2 The tester shall visually inspect the PIN entry device as integrated inside the POS Terminal to verify the assertions provided by the vendor in response to Section E3.3 PCI PTS POI Evaluation Vendor Questionnaire.

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

Removed p. 104

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.

TE3.4.1 The tester shall examine the assertions provided by the vendor in response to Section E3.4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.4 of the PCI PTS POI Security Requirements for consistency relating to the control of the device’s operating modes and the corresponding display messages visible to the cardholder. The tester shall summarize the responses.

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.

TE3.4.3 The …

Removed p. 105

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

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.

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 and initial exploitation or less than …

Removed p. 106

A keyboard may be a touch screen if the cardholder can input numeric data to it.

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.

TE3.5.1 The tester shall examine the vendor’s response to Section E3.5 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement E3.5 of the PCI PTS POI Security Requirements to verify that any interface of the device that can be used to accept payment card numeric entry is controlled, and that the device is equipped with only one PIN-accepting keyboard or it is controlled in a manner consistent with A6, B16, or E3.4. The tester shall summarize the responses.

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 …

Removed p. 107

The objective of this section is to assess the device’s ability to protect the device against removal from the cabinet. This protection aims against PIN entry device overlays or chained ICC readers; it also aims at complicating attacks against the PIN entry device and ICC reader. As such, this requirement applies to devices and modules aimed at being mechanically integrated into a compound device, for example, kiosk or AFD.

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.

The intent of the requirement to protect the PIN entry device against removal from the cabinet aims against inserting an overlay between the PIN entry device and the casing/cabinet within which the PIN entry device is installed and to hinder the removal of the PIN entry device from its working location for an attack under …

Removed p. 107

TE4.1.2 The tester shall visually inspect the device to verify the assertions provided by the vendor in response to Section E4.1 of the PCI PTS POI Evaluation Vendor Questionnaire.

TE4.1.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.

TE4.1.4 For secure components previously assessed under A10, the tester shall:

• Review the report(s) covering the removal detection mechanisms of each sub-component.

• Confirm how these removal mechanisms have been implemented in the final form-factor of the device.

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

a) The process provides dual control through use of two or more passwords/authentication codes that are a minimum of seven characters or an equivalent strength and entered through the secure keypad of the POI; or

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.

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

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 …

Removed p. 109

TE4.2.2 The tester shall visually inspect the PIN entry device 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.

TE4.2.3 The tester shall verify that procedures exist for the integration documentation to be shipped or otherwise made available to the customer.

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

TE4.3.2 The tester shall visually inspect the embedded device 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.

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

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 the presence of logical interfaces through methods such as passive monitoring of communications, port/protocol scans, and code review.

• If the module is under the control of the firmware and runs in the same space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for wireless technologies listed above) is provided for and that secure communication is enforced by the interface.

Note: If the device implements an IP stack, the device must support TLS 1.2 or higher. When the TLS protocol is supported, this needs to be evaluated under Section I, “Operational Testing” and corresponding PCI Technical FAQs.

Removed p. 112

TF1.2 The tester shall examine any relevant documentation distributed by the vendor such as schematics, data sheets, and assembly drawings, submitted by the vendor to ensure that the vendor has exhaustively defined all protocols and interfaces supported by the device. The vendor must also identify where they derive their code that is used to implement protocols, as well as document all protocols and which physical interfaces they apply to. When public libraries are used to implement protocols, their versions must be specified.

TF1.3 The tester shall examine the vendor’s Interface diagram to verify that it accurately portrays all interfaces and protocols present on the device.

TF1.4 The tester shall complete a table describing all interfaces and protocols; and for each, identify which component implements the protocol, whether it is a security protocol, and the location from which the software was derived. The tester shall Include all exempted protocols and interfaces and note …

Removed p. 113

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.

TG1.1 The tester shall inspect the vendor vulnerability assessment procedures to verify the assertions provided by the vendor in response to Section G1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s internal policy. The vendor must clearly indicate that their vulnerability assessment is executed for each of the protocols and interfaces defined in Requirement F1. The tester shall summarize the responses.

TG1.2 The tester shall examine any relevant documentation distributed by the vendor to ensure that the vendor has provided for effective detection of vulnerabilities in each of the protocols and interfaces defined in F1. The tester shall list the methods and tools used by the vendor for vulnerability assessment including but not limited to test scripts, practical tests, review of information in …

Removed p. 114

The intent of this requirement is to ensure that the vulnerability assessment process evaluated under Requirement G1 has been followed.

Review the vulnerability assessment for each interface as defined in F1.

TG2.1 The tester shall examine the evidence supplied by the vendor to verify the assertions provided by the vendor in response to Section G2 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s vulnerability assessment. The vendor must clearly indicate that a vulnerability assessment was completed for each of the protocols and interfaces defined in Requirement F1.The tester shall summarize the responses.

TG2.2 The tester shall examine additional relevant documentation, such as scan reports, test reports or vulnerability analysis documentation submitted by the vendor to verify that it supports the vendor responses.

TG2.3 The test shall examine the vendor’s sign-off form specified in Requirement G1 to ensure that it has been completed and signed off by management.

TG2.4 The tester shall …

Removed p. 115

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.

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

TG3.3 The tester shall examine the documentation to verify both the timely creation of mitigation measures for newly found vulnerabilities and that procedures exist to continually update and document all vulnerabilities.

TG3.4 The tester shall perform any additional tests …

Removed p. 116

The vendor must also identify and document all protocols and Interfaces identified in Section F1.

TH1.1 The tester shall inspect the vendor security guidance to verify the assertions provided by the vendor in response to Section H1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s security guidance for the protocols and interfaces addressed to the application developers. The vendor must clearly provide security guidance for each interface and protocol defined in Section F1. The tester shall summarize the responses.

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

TH1.3 The tester shall examine and assess the distribution process of the security guidance. It must ensure that all necessary users are aware of it and have access …

Removed p. 117

The objective of this section is to verify the default configuration for interfaces and communications as defined by the vendor documentation and Section F1.

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, the application developer’s guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify that it supports the vendor claims that each interface is default in a secure or disabled state. …

Removed p. 118

d) Key-management security guidance ensures secure use of keys and certificates, including certificate status (e.g., revoked), secure download, and roll over of keys.

Note: This does not supersede any criteria in B11 or K17 but rather is required for any device implementing protocols evaluated under Open Protocols•i.e., key-related Security Protocols, such as SSL/TLS, SSH, VPN technologies.

This requirement applies to all declared Security Protocols defined in Section F1.

TH3.1 The tester shall inspect the vendor’s key-management security guidance document to verify the assertions provided by the vendor in response to Section H3 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s key-management and certificate security. The vendor must ensure that the key-management security is complete and correct. The tester shall summarize the responses.

TH3.2 The tester shall examine any relevant documentation, such as a user guide, application developer guide, design specifications, the interface specification, the software-design rules and specifications, or the …

Removed p. 119

This DTR must be executed and separately reported, per a security protocol that is indicated to be suitable for financial applications or device management.

TI.11 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I1 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s use of secure protocols. The vendor must ensure that the declared security protocol(s) covers each protocol listed in Section F1. The tester shall summarize the responses.

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

TI1.3 The tester shall assess the physical and logical interfaces of the device to ensure the declared security protocol is present for each interface.

TI1.4 …

Removed p. 120

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

TI2.1 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I2 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s data confidentiality 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.

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

TI2.3 The …

Removed p. 121

TI3.1 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I3 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s data integrity 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.

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

TI3.3 The tester shall verify device behavior when receiving incorrect data packets.

TI3.4 The tester shall perform any additional tests necessary to validate the device’s implementation of security protocol is sufficiently able to provide integrity. The tester should use his or her …

Removed p. 122

a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question as denoted in Appendix E.

TI4.1 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I4 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s security protocols providing mutual authentication. The vendor must ensure that the guidance is complete and correct. The tester shall summarize the responses.

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

TI4.3 In the case when certificates are used for server authentication, the tester shall execute tests to verify device behavior when receiving incorrect certificates, including:

c) Chaining error in certificate TI4.4 The tester shall verify …

Removed p. 123

TI5.1 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I5 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s exception handling and replay detection. 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.

TI5.2 The tester shall examine any relevant documentation, such as a user guide, design specifications, the interface specification, the software-design rules and specifications, or the implementation guidance submitted by the vendor to verify the documentation clearly defines that the declared security protocol for each interface provides exception handling and replay detection TI5.3 Unless it can be shown that by design the used security protocol provides message replay countermeasures (by the usage of counters or nonces, for example) and that there is no publicly known replay attack …

Removed p. 124

TI6.1 The tester shall inspect the vendor’s protocol guidance document to verify the assertions provided by the vendor in response to Section I6 of the PCI PTS POI Evaluation Vendor Questionnaire relating to the vendor’s session management. 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.

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

TI6.3 The tester shall assess each interface of the device to ensure that each interface can provide session management.

TI6.4 The tester shall verify device behavior while attempting to break session management rules• e.g., request to exceed number of simultaneous connections.

TI6.5 The tester …

Removed p. 125

a) The guidance is at the disposal of internal users, and/or of application developers, system integrators, and end-users of the device.

b) The guidance covers the complete device•including firmware, payment and non-payment applications, forms, multimedia files, certificates, configuration files, configuration setting, and keys.

c) The guidance covers the complete life cycle of the device from development, over manufacturing, up to delivery and operation.

d) The security guidance ensures that unauthorized modification is not possible.

e) The security guidance ensures that any modification of a PTS-approved device that impacts security, results in a change of the device identifier.

Due to the device life cycle, it is possible that some parts of the configuration management are under control of the vendor, while others are not. For the parts under control of the vendor, guidance documentation, policies, and procedures are to be submitted as evidence. For the parts that are not under control of the vendor, the vendor …

Removed p. 126

a) The maintenance measures are documented.

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.

c) The maintenance measures ensure timely assessment and classification of newly found vulnerabilities.

d) The maintenance measures ensure timely creation of mitigation measures for newly found vulnerabilities that may impact device security.

TJ2.1 The tester shall examine the vendor’s response to Section J2 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module

• Protocol Declaration Form, and the response to Requirement J2 of the PCI PTS POI Security Requirements to verify that the vendor has clearly documented security maintenance measures. The tester shall summarize the responses.

TJ2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail device-maintenance measure processes and procedures for detecting …

Removed p. 126

TJ2.4 The tester may perform any additional tests necessary to validate the security maintenance measures. 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.

Removed p. 127

The vendor maintains security guidance describing how the update mechanism must be used.

a) The update mechanism ensures security i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol.

b) The vendor puts the security guidance for updating deployed devices at the disposal of application builders, system integrators and end-users of the device as well as third-party device management systems.

c) The security guidance covers the update of firmware, payment and non-payment applications, forms, multimedia files, configuration files, certificates and keys.

The security guidance covers both remote and local device update procedures.

d) The security guidance describes the responsibilities of application developers, system integrators and end-users of the device.

e) The security guidance describes how updates to deployed devices are timely and secure.

f) For the parts that are not under control of the vendor, the vendor must provide sufficient guidance to ensure integrity, mutual authentication, and protection against replay are …

Removed p. 128

TJ4.1 The tester shall examine the vendor’s response to Section J4 the PCI PTS POI Evaluation Vendor Questionnaire, the Open Protocols Module

• Protocol Declaration Form, and the response to Requirement J4 of the PCI PTS POI Security Requirements 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:

• Via the update mechanism, ensure security, i.e., integrity, server authentication, and protection against replay, by using an appropriate and declared security protocol;

• Cover all elements of device maintenance including terminal updates to configuration files, firmware and software, as well statistics pulled from the device; …

Removed p. 129

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

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

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

TK1.3 The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test device when necessary.

Removed p. 130

Note that MSRs and ICCRs must meet the attack potentials stipulated in DTRs A8 and D1 respectively.

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.

DTRs A1.8, A1.11, and A1.13 must be completed for the ICCR where any specific references to “PIN” are to be read as “account data.” TK1.1.1 The tester shall examine the vendor’s response to Section K1.1 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K1.1 of the PCI PTS POI Security Requirements for consistency relevant to K1.1.

TK1.1.2 The tester shall verify that all testing procedures specified for Requirement D1 for chip data and A8 for magnetic-stripe data in the core physical requirements have …

Removed p. 132

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

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

TK2.4 The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test device when necessary.

Removed p. 133

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

The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units) Where a device exclusively supports DUKPT or similar unique key per transaction methodology for the protection of sensitive data, such as PINs, the side-channel analysis does not need to include these keys.

SCA tests shall be performed in accordance with Appendix F.

TK3.1 The tester shall examine the vendor’s response to Section K3 of the PCI PTS POI Evaluation Vendor Questionnaire and the …

Removed p. 134

TK3.8 The tester shall perform preliminary side-channel analysis on the POI to characterize the cryptographic algorithms used to process sensitive data and/or operate with secret keys. Utilizing characterization results and knowledge of the POI physical design and software, the tester shall decide which side-channel attack paths provide the best opportunities for an attacker to compromise high-value assets. The tester shall develop side-channel analysis to explore methodologies most likely to achieve retrieval of an account-data-related cryptographic key or keys derived from initial scoping. The tester shall develop these investigations to derive a demonstrable level of assurance consistent with any reported attack cost rating(s).

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 The tester shall justify the methodologies used and findings in accordance with Appendix F. The tester shall outline why analysis parameters provide a high level of confidence …

Removed p. 135

TK3.12 Referring to the information provided in DTR A3, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the POI cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.

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

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 is not required to perform the attack entirely but may perform …

Removed p. 136

Public keys used for sensitive functions that impact security, such as authenticating firmware update authentication, display prompt control, remote key distribution, data encryption, etc., must be protected against modification and substitution.

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

TK3.1.3 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms to prevent the substitution and/or modification of a public key.

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 …

Removed p. 137

All account data shall be encrypted using only ANSI X9 or ISO approved encryption algorithms (for example, AES, TDES). The encryption algorithm should use a mode of operation described in ISO/IEC 10116:2006 (or equivalent) and follow secure padding guidelines. Any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format- preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (for example, a standards body) and subjected to independent expert review; such methods shall also be implemented following all guidelines of said evaluation and peer review including any recommendations for associated key management.

The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert qualifications are further defined in the glossary.

For devices that allow the enablement …

Removed p. 139

It should not be possible to subvert the key distribution process such that cryptographic keys are exposed. Only legitimate peers may engage in key distribution, legitimacy may be established for example, through a demonstration of knowledge (proof of possession) of a shared secret.

If an identity-based scheme is used, pair-wise keys may be “exchanged” using a non-interactive process.

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.2 The tester shall verify that the device supports mutual authentication of both the sending key distribution host and the receiving device, including, where relevant, assurance that the device actually has the ability to (or actually can) compute a session key which is unique to that device and that no other entity other than the device specifically identified …

Removed p. 140

To prevent an adversary from posing as a legitimate sender to send falsified messages and to allow the tracing of particular actions to a specific device, the device must support data origin authentication on all encrypted messages.

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.2 The tester shall verify that the device supports data origin authentication for all encrypted messages following guidance specified in ISO/IEC 19772:2009 (or equivalent). The tester shall verify that the ordering of how authentication and encryption are applied does not result in a weak authentication scheme.

Removed p. 141

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.

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

Removed p. 142

The device must enforce that account data keys, key-encipherment keys, and PIN-encryption keys have different values.

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.

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.

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.

The intent of …

Removed p. 143

d) Key-encrypting keys shall never be used to encrypt account data.

e) Data keys shall never be used to encrypt other keys.

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 shall detail the results.

Removed p. 144

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.

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

TK9.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to remote access to determine whether it supports the assertions made by the vendor.

TK9.3 The tester shall verify that the device cryptographically authenticates remote access attempts. This will be accomplished, for example, by performing a simulated …

Removed p. 145

• 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.1 The tester shall examine the response to Section K10 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K10 of the PCI PTS POI Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.

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 …

Removed p. 146

TK10.7 The tester shall confirm that

•and summarize how

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

TK10.8 The tester shall confirm that

•and summarize how

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

TK10.9 The tester shall confirm that

•and summarize how

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

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

TK10.11 The tester shall …

Removed p. 147

TK10.17 The tester shall outline the following information. If the firmware is based on a general-purpose operating system (like Linux or Windows CE), the steps described in TK10.15, in particular, hold for this operating system. The documentation provided by the developer shall show that state-of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues (like patch levels; not including unused packages, etc.; not being able 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 …

Removed p. 148

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.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to application loading and application/configuration updates, including remote access, to determine whether it supports the assertions made by the vendor.

TK11.1.3 The tester shall verify that the device rejects unauthorized applications. This will be accomplished, for example, by performing a simulated application load and if applicable, a software and/or configuration update with inadequate or modified authentication information.

TK11.1.4 The tester shall determine by which component the authentication is performed.

TK11.1.5 The tester shall determine the rank of protection strength for the component involved in application …

Removed p. 149

c) Change a single bit in the application block of the image, and confirm that this modified image is rejected when loaded into the POI.

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

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

Removed p. 150

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.2 The tester shall examine any relevant documentation to ensure that it contains secure programming guidance (consistent with PA-DSS) to assist developers in building secure applications for the device in question.

TK11.2.3 The tester shall examine any relevant documentation to ensure that it contains guidance to assist developers in specifying time limits for how long may be retained and often account data should be used before it should be deleted.

TK11.2.4 The tester shall examine any relevant documentation to ensure that it includes guidance for use of the correct API function calls, including sample source code.

If done between physically and logically disparate components it must …

Removed p. 151

Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.The authentication must not be performed by a component of lesser protection strength than the one for which the firmware/software is intended, OR the authentication must be performed by the target component of the firmware/software. For example, in an unattended device software/firmware for the EPP and the cryptographic module must be authenticated by these modules themselves only, while software for the application controller or the ICC reader may be authenticated by itself or by the EPP or by the cryptographic module.

The firmware and application version …

Removed p. 152

TK12.5 The tester shall determine the level of protection for the external component involved in firmware/software updates and that the authentication of software updates is performed by a component of equal or greater strength.

TK12.6 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix E.

TK12.7 For each of the processing elements listed in DTR A3, the tester shall complete the following table. Where different parts of the code (for example, boot code, main firmware, etc.) can be updated independently, or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well.

The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. …

Removed p. 153

TK12.11 If a CBC MAC is used for firmware authentication, the tester shall detail what methods are used to mitigate vulnerabilities in this method when used to authenticate variable-length data.

TK12.12 For each of the methods of authentication the tester shall obtain a correctly authenticated firmware image and:

TK12.13 The tester shall confirm how any public or private/secret keys are loaded into the POI during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the POI) and how it is ensured that these must be changed in deployed devices.

TK12.14 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware and application version numbers, and optionally the hardware version number during startup or on request. This includes all firmware numbers where Core, SRED and OP have different numbering.

All interfaces and associated communication methods of …

Removed p. 154

The Open Protocols Module shall be used to assess any communication method that uses a wireless, local, or wide-area network to transport data. This would include, but is not limited to: Bluetooth, Wi- Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless or through a hub, switch, or other multiport device. In addition, any communication that uses a public domain protocol or security protocol would be assessed with the Open Protocols Module.

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 …

Removed p. 155

TK13.8 If the device includes command-execution interfaces or parsers: The tester shall detail how each of the above interfaces is configured to accept commands•for example, whether a command executive is used, or other methods are used to parse input commands. The tester shall define which common functionalities exist between interfaces to determine which test approaches may be applied in common to more than one interface.

TK13.9 The tester shall detail in an appendix to the evaluation report a complete list of all APIs provided on each of the logical interfaces of the POI.

TK13.10 The tester shall perform a source-code review of each relevant interface and confirm they are handled securely, that only documented commands are implemented and that secure defaults are provided for each interface. The tester shall detail what methods are used to verify the length and content of each command before processing. The tester shall derive and describe vulnerability-analysis …

Removed p. 156

TK13.15 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.

Removed p. 157

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.

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.

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

Encrypting mode is defined to be when the device’s encryption of account data functionality is enabled and operational.

TK15.1 The tester shall examine the response to Section K15 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K15 of the PCI PTS POI Security Requirements for consistency relating to the output of clear-text PANs.

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.

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.

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 …

Removed p. 159

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

TK15.8 If the device allows for a change of modes between encrypting and non-encrypting, the tester shall verify that:

• The authorization implements the principles of dual control,

• Sensitive information required for the authorization (for example, passwords/authentication codes or cryptographic mechanism) is initialized or used in a way, that prevents replay at the same or a different device,

• If changes to the mode of operation can occur remotely, the tester shall verify that a cryptographic authorization mechanism consistent to that used for remote access authentication (per K9) is implemented.

Removed p. 160

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:

• That clear-text account data is only output to authenticated applications;

• How the applications are authenticated.

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.

TK15.1.3 The tester shall verify that the vendor has identified all data that is provided to authenticated applications.

The tester shall summarize the responses.

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:

Removed p. 161

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.

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

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.

TK15.2.3 The tester shall verify that

•and summarize how

•the vendor has …

Removed p. 162

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.

Removed p. 163

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.

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.

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.

Removed p. 164

A cryptographic salt comprises of random bits that can be input into a cryptographic function. Random bits shall be generated such that probability of the same random bits being output is statistically insignificant. A known salt value may compromise the effectiveness of the cryptographic function.

• Salts that are unique per merchant are generated outside the transaction device and require loading to each merchant device. The vendor must supply documentation to the merchant/acquirer processor on how to securely load the salt values and that this loading is treated as a sensitive service in accordance with K22.

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.

TK16.1.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted …

Removed p. 165

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.

TK16.2.3 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms dealing with salt data and functions that interact with salt data, using attack scenarios. 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 scheme depicted …

Removed p. 166

When a check value is generated for a key or key component, it shall be generated by a cryptographic process such that all portions of the key or key component are involved in generating the check value.

Clear keys or clear-key parts must not be loaded using the service module.

A device may include more than one compliant key exchange and storage scheme.

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

TR-31 support or equivalent must use a key-derivation methodology. The device may optionally support, in addition, the key-calculation methodology.

Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a …

Removed p. 167

AES keys can only be:

• Loaded using asymmetric keys of equivalent or greater strength.

• Encrypted by another AES key of equal or greater strength.

• Manually loaded using dual control techniques.

• Internally generated using a random number generator compliant with B9.

Remote key distribution using asymmetric techniques shall employ mechanisms to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices. Acceptable techniques include:

1. For devices under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s root), the PIN-acceptance device can be forced to bind to a specific transaction-processing host’s certificate, and not accept commands digitally signed by any other hosts. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted below.

2. The acquirer KDH public key can be loaded only once and requires a factory return (preceded by a zeroization of acquirer keys function) to …

Removed p. 168

Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (for example, multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized.

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 relating to the method of key management in use in the device. The tester shall summarize the 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.

TK17.3 The tester …

Removed p. 169

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.

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.

TK17.11 The tester shall review the API guide and operational manual of the POI and confirm that this …

Modified p. 169 → 72

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

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

Modified p. 169 → 72

If a public-key technique for the remote distribution of symmetric secret keys is used, it must:

If a public-key technique for the remote distribution of symmetric secret keys related to PIN or account-data encryption is used, it must:

Modified p. 169 → 72

a) Use public and ~~private key~~ lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for ~~RSA.~~

a) Use public and private-key lengths that are deemed acceptable for the algorithm in question (for example, 2048-bits minimum for RSA).

Modified p. 169 → 72

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.

Modified p. 169 → 72

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

TB9.3 The tester shall determine from vendor documentation all storage and usage locations for each key for example, ROM, external RAM, EPROM, processor chip, etc., and list the details in a key summary table. The tester shall reference the relevant aspects of the asset flow in A1.

Modified p. 169 → 72

~~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, sleep mode) and list the details in a key summary table.

TB9.4 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, sleep mode) and list the details in a key summary table.

Modified p. 169 → 72

~~TK17.9~~ The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 ~~DUKPT, Fixed key,~~ or Master/Session key management.

TB9.5 The tester shall note all acquirer-based key-management systems supported by the POI, defining them as one of ANSI X9.24 DUKPT or Master/Session key management.

Modified p. 169 → 72

~~TK17.10~~ For systems that support Master/Session key management, the tester shall define what (if any) standard this key management complies with (for example, where the POI implements country specific key management). The tester shall note the name, version, and authoring party of this standard.

TB9.6 For systems that support Master/Session key management, the tester shall define what (if any) standard this key management complies with (for example, where the POI implements country specific key management). The tester shall note the name, version, and authoring party of this standard.

Modified p. 169 → 73

~~TK17.12~~ The tester shall detail any other types of key management or cryptographic keys used by the POI. This should include any keys used for firmware or application authentication, self-testing, boot strapping, remote key injection, local key injection, dual control, etc.

TB9.9 The tester shall detail any other types of key management or cryptographic keys used by the POI. This should include any keys used for firmware or application authentication, self-testing, boot strapping, remote key injection, local key injection, dual control, etc.

Removed p. 171

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 2005 key bundling (for backwards compatibility).

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

Modified p. 171 → 74

~~TK17.14~~ Using the key table as a reference, the tester shall note which keys are actively erased by the POI during a tamper event, and which keys are not erased but instead rely upon the erasure of a KEK to prevent their subsequent misuse.

TB9.11 Using the key table as a reference, the tester shall note which keys are actively erased by the POI during a tamper event, and which keys are not erased but instead rely upon the erasure of a KEK to prevent their subsequent misuse.

Modified p. 171 → 74

~~TK17.15~~ Using the key table as a reference, the tester shall confirm that all secret and private ~~keys~~ are unique per device, and what method is used to ensure ~~that~~ this is the case.

TB9.12 Using the key table as a reference, the tester shall confirm that all secret and private keys, including those used for account-data encryption, are unique per device, and what method is used to ensure this is the case.

Modified p. 171 → 74

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

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

Modified p. 171 → 74

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

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

Modified p. 171 → 75

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

TB9.15 The tester shall detail any ways in which the POI generates keys from other keys and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.

Modified p. 171 → 75

~~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 are generated using the same process validated under Requirement ~~K9.~~ 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.16 The tester shall note whether the POI generates any keys using an internal random number generator. The tester shall confirm through source-code review that these keys are generated using the same process validated under Requirement B7. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.

Removed p. 172

• Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.

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.

Modified p. 172 → 75

b) If key check values (KCVs) are used for this purpose, the ~~KCV values~~ stored are limited to values as defined in ~~TK17.21~~ or they are never output from the POI.

b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to values as defined in TB9.18 or they are never output from the POI.

Modified p. 172 → 75

c) The method used does not rely on the check digits (e.g., mod 10 calculation) of a ~~(T)DES~~ key as part of the key comparison.

c) The method used does not rely on the check digits (e.g., mod 10 calculation) of a (T) DES key as part of the key comparison.

Modified p. 172 → 75

~~TK17.21~~ Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value except as noted ~~below~~

TB9.18 Referencing the POI API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value except as noted below.

Modified p. 172 → 75

Note: Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for ~~TDES.~~ TDES ~~may optionally use,~~ and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check …

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

Modified p. 172 → 75

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

TB9.19 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.

Modified p. 172 → 75

~~TK17.23~~ The tester shall detail the ~~key-bundling~~ method(s) supported by the POI device, providing details on exact contents of any header, payload, padding, etc. as well as noting which parts are encrypted and which ~~parts~~ are included in any authentication calculation. If ANSI TR-31 ~~2010~~ method is not used, the tester shall justify why the method used provides the same level of security. Specifically, the tester shall note how the ~~key-bundling~~ method supports each of the following properties:

TB9.20 The tester shall detail the key-block method(s) supported by the POI device, providing details on exact contents of any header, payload, padding, etc. as well as noting which parts are encrypted and which are included in any authentication calculation. If ANSI TR-31 key- derivation method or ISO 20038 is not used, the tester shall justify why the method used provides the same level of security. Specifically, the tester shall note how the key-block method supports each of the following …

Modified p. 173 → 76

~~TK11.26~~ The tester shall confirm that if the device supports remote key loading using asymmetric techniques that it utilizes an acceptable method to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices TK11.27 The tester shall confirm that for a device supporting remote key loading using asymmetric techniques using a “binding” technique, it supports an acceptable method for unbinding in the event of decommissioning.

TB9.23 The tester shall confirm that if the device supports remote key loading using asymmetric techniques that it utilizes an acceptable method to protect against man-in-the-middle attacks and the hijacking of payment-acceptance devices.

Modified p. 173 → 76

~~TK11.28~~ The tester shall verify the SCRP contains cryptographic keys and functions that can be used to securely provision cryptographic keys and other data to the PIN CVM application. The tester shall detail the relevant key names, function names, and function behavior.

TB9.25 The tester shall verify the SCRP contains cryptographic keys and functions that can be used to securely provision cryptographic keys and other data to the PIN CVM application. The tester shall detail the relevant key names, function names, and function behavior.

Removed p. 174

• Use of a unique key per transaction technique. (Prevents the attack.)

TK18.1 The tester shall examine the response to Section K18 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K18 of the PCI PTS POI Security Requirements for consistency relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PAN determination.

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.

TK18.3 The tester shall perform functional testing to verify the device characteristics regarding K18.

Removed p. 175

The objective is not to replicate the vendor testing, but instead it is to account for shortcomings within the vendor’s testing of the implementation.

The tester may rely upon vendor testing as appropriate to fulfill the following test steps.

TK19.1 The tester shall examine the response to Section K19 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement K19 of the PCI PTS POI Security Requirements for consistency relevant to Requirement K19. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.

TK19.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 K13 under different environmental conditions. Such information …

Removed p. 176

TK19.7 Using a POI that has been configured by the vendor (using special test code from the vendor which shall be removed from production units) to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table, or the vendor should provide sufficient test reports covering all required tests.

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.

TK19.10 The tester shall develop attack scenarios to compromise …

Modified p. 177 → 89

~~Applications,~~ in this context, are functional entities that execute within the secure boundary of the POI and may or may not provide services external to the POI. Applications are typically processes or tasks that execute under the control of an operating system (OS) or software executive routine.

As defined in Appendix G, applications, in this context, are functional entities that execute within the secure boundary of the POI and may or may not provide services external to the POI. Applications are typically processes or tasks that execute under the control of an operating system (OS) or software executive routine.

Modified p. 177 → 89

~~Applications are considered to be separated by access rights. Applications may share data by design.~~ OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined ~~with K10.~~

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. 177 → 89

The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. ~~Specifically, those applications must be validated to ensure that:~~

The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.

Modified p. 177 → 89

• The application can only work on the keys it alone manages and cannot affect or see any other keys.

• The application can only work on the keys it alone manages and cannot affect or see any other keys. The application must not handle PIN or SRED security-related plaintext keys or key components.

Modified p. 177 → 90

• A mechanism must exist to display the application version upon request.

A mechanism must exist to display the application version upon request.

Modified p. 177 → 90

The vendor must provide clear security guidance for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This guidance must be included in the security policy delineated in DTR ~~B20 Vendors should provide configuration lists and description of the separation mechanism to support answers.~~

The vendor must provide clear security guidance for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized. This guidance must be included in the security policy delineated in DTR B20.

Removed p. 178

• Introducing new primitive cryptographic functions (although it can use these to implement new composite functionality).

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.

TK20.11 The tester shall note whether the firmware processor(s) provide mechanisms to prevent the execution of memory used to hold data objects. Where such mechanisms exist, the tester shall detail whether they are utilized correctly by the firmware.

Modified p. 178 → 90

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

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

Modified p. 178 → 90

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

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

Modified p. 178 → 90

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

TB16.5 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.

Modified p. 178 → 90

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

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

Modified p. 178 → 90

~~TK20.9~~ If the POI allows for different applications to be executed on the same processor, or for the execution of one or more applications on the same processor ~~that~~ is used to execute firmware, the tester shall detail the mechanisms provided to ensure that code and data objects of different applications/firmware are kept separate.

TB16.7 If the POI allows for different applications to be executed on the same processor, or for the execution of one or more applications on the same processor which is used to execute firmware, the tester shall detail the mechanisms provided to ensure that code and data objects of different applications/firmware are kept separate.

Modified p. 178 → 90

~~TK20.10~~ The tester shall review the configuration of the mechanisms described above and confirm that it maintains application separation.

TB16.8 The tester shall review the configuration of the mechanisms described above and confirm that it maintains application separation.

Modified p. 178 → 91

~~TK20.12~~ If the device allows customers or integrators to install additional applications, the tester shall verify that the POI’s design prevents the embedded application from:

TB16.10 If the device allows customers or integrators to install additional applications, the tester shall verify that the POI’s design prevents the embedded application from:

Removed p. 180

• The operating system of the device must contain only the software (components and services) necessary for the intended operation.

• The operating system must be configured securely and run with least privilege.

• The security policy enforced by the device must not allow unauthorized or unnecessary functions.

• API functionality and commands that are not required to support specific functionality must be disabled (and where possible, removed).

For multi-application devices, the intended operation furthermore includes the operation of applications without security impacts.

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.

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 …

Modified p. 180 → 94

The intended operation is considered as the functionality relevant to ~~B2.~~ Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access. The operating system must be configured to prevent all other components and services from gaining access to the sensitive information, functions, and/or peripherals. Therefore, operating-system code is necessarily part of the firmware as defined within K10.

The intended operation is considered as the functionality relevant to D1 to prevent any non-firmware application from gaining access to privileged functionality. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals, be permitted to have such access.

Modified p. 180 → 94

If the OS supports multiple privilege levels or user privileges, the least privileges are assigned according to the “need to have” principle; a single supervisory mode implementation

•e.g., root or equivalent

•is not allowed. ~~The payment~~ application must have less privilege than the firmware.

If the OS supports multiple privilege levels or user privileges, the least privileges are assigned according to the “need to have” principle; a single supervisory mode implementation

•e.g., root or equivalent

•is not allowed. An application must have less privilege than the firmware.

Modified p. 180 → 94

~~TK21.3~~ The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.

TB17.1 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.

Modified p. 180 → 94

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

TB17.2 The tester shall verify that API functionality and commands that are not required to support specific functionality are removed whenever possible or disabled if removal is not feasible.

Modified p. 180 → 94

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

TB17.3 The tester shall examine the methods and tools provided by the vendor that ensure the intended software configuration of the device is maintained, and that updates and release changes do not affect the secure configuration of the OS.

Modified p. 180 → 94

~~TK21.6~~ The tester shall determine whether the OS supports multiple privilege levels or user privileges.

TB17.4 The tester shall determine whether the OS supports multiple privilege levels or user privileges.

Modified p. 180 → 94

If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the ~~firmware.~~

If so, the tester shall verify that the least privilege is assigned according to the “need to have” principle and that the payment application must have less privilege than the firmware privilege level.

Removed p. 181

TK21.9 The tester shall obtain the configuration information for the operating system used in the POI.

Modified p. 181 → 94

~~TK21.8~~ 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).

TB17.6 If the POI uses a commercial operating system, the tester shall review publicly 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).

Modified p. 181 → 95

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.

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

Modified p. 181 → 95

~~TK21.10~~ The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the POI execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce the functionality of the POI to only those components and services necessary for the intended operation of the device.

TB17.8 The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the POI execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce the functionality of the POI to only those components and services necessary for the intended operation of the device.

Removed p. 182

Authentication shall require dual control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material.

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.

Key components entered manually constitute sensitive data during entry and the device shall not differentiate via sound or display the entry of different values.

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.

TK22.2 The tester shall …

Removed p. 183

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 the disabling or alteration of any systems or functions relied upon by the POI to meet the PTS requirements. Examples include but are not limited to: disabling removal detection, changing SRED encryption modes, and alteration of system time that may be used to verify certificate validity (or for other system security services).

TK22.8 The tester shall confirm that•any entry of sensitive information through the keypad of the POI is protected to the same extent as customer account data, conforming …

Modified p. 184 → 102

The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.

• The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.

Removed p. 185

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.

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

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 …

Modified p. 186 → 111

~~TK24.3~~ The tester shall confirm that without a cryptographically secure enablement token being supplied to the SCRP, the SCRP will cease accepting consumer cards within a time no more than twice ~~(i.e.~~ ten minutes) that of the maximum monitor frequency. Re-enablement of the SCRP to accept consumer cards may be performed at any time, with the validation of a fresh monitor token.

TB26.1 The tester shall confirm that without a cryptographically secure enablement token being supplied to the SCRP, the SCRP will cease accepting consumer cards within a time no more than twice (i.e., ten minutes) that of the maximum monitor frequency. Re-enablement of the SCRP to accept consumer cards may be performed at any time, with the validation of a fresh monitor token.

Modified p. 186 → 111

~~TK24.4~~ The tester shall document the features of the monitor token that prevent replay of this value.

TB26.2 The tester shall document the features of the monitor token that prevent replay of this value.

Removed p. 187

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.3 The tester shall review any vendor documentation describing all changes to the software to ensure that changes that rectify errors or faults did not remove, modify, or add additional functionality that impacts security unless they are submitted immediately upon completion for evaluation. This is to validate the process of deferring submissions for evaluation unless all changes are submitted for evaluation immediately upon completion.

Modified p. 187 → 137

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

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

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

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

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

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

Modified p. 187 → 138

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.

The organization must utilize a documented secure change management system, such that all development is traceable and access restricted. All changes should be reviewed and approved by cognizant management 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.

Modified p. 187 → 138

~~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 possible to track the different versions of the items, and including criteria for when changes are submitted for PCI evaluation and details of the vulnerability management process.

TE1.1 The tester shall examine and cite any supporting documentation submitted by the vendor and verify the documentation details 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 possible to track the different versions of the items, and including criteria for when changes are submitted for PCI evaluation and details of the vulnerability management process.

Removed p. 188

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.

Modified p. 188 → 139

~~TL1.5~~ The tester shall interview those responsible for the ~~change control~~ processes

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

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

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

Modified p. 188 → 139

~~TL1.7~~ The tester shall validate that either:

TE1.5 The tester shall validate that either:

Removed p. 189

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.

Modified p. 189 → 143

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

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

Modified p. 189 → 143

~~TL2.3~~ The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail dual control and cryptographic authentication processes and procedures during manufacturing and describe how this shows compliance to this requirement.

TE3.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail dual control and cryptographic authentication processes and procedures during manufacturing and describe how this shows compliance to this requirement.

Modified p. 189 → 143

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

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

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

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

Modified p. 189 → 143

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

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

Modified p. 189 → 143

~~TL2.6~~ If firmware signing is done on site, the tester shall observe the signing process, the signing tools, and ensure they are under dual control and that the signing procedures are followed.

TE3.5 If firmware signing is done on site, the tester shall observe the signing process, the signing tools, and ensure they are under dual control and that the signing procedures are followed.

Modified p. 189 → 143

~~TL2.7~~ The tester shall observe the firmware storage and validation process to ensure that only signed and valid firmware is used during manufacturing.

TE3.6 The tester shall observe the firmware storage and validation process to ensure that only signed and valid firmware is used during manufacturing.

Removed p. 190

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.

Modified p. 190 → 144

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

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

Modified p. 190 → 144

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

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

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

Modified p. 190 → 144

~~TL3.4~~ The tester shall examine the device parts listing and sample components during manufacturing, to ensure the correct components are used.

TE4.4 The tester shall examine the device parts listing and sample hardware components during manufacturing, to ensure the correct components are used.

Modified p. 190 → 144

~~TL3.5~~ The tester shall observe ~~component~~ control to ensure that authorized components are verified prior to manufacturing and that unauthorized substitutions are not made.

TE4.5 The tester shall observe hardware-component control to ensure that authorized components are verified prior to manufacturing and that unauthorized substitutions are not made.

Removed p. 191

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.5 The tester shall examine a sample of documentation for firmware control and storage during manufacturing, including change control logs and firmware validation procedure to ensure the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.

Modified p. 191 → 145

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

TE5.1 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.

Modified p. 191 → 145

~~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 that the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.

TE5.2 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 that the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.

Modified p. 191 → 145

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

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

Modified p. 191 → 145

~~TL4.6~~ The tester shall observe the firmware storage and validation process to ensure that procedures are followed during manufacturing.

TE5.5 The tester shall observe the firmware storage and validation process to ensure that procedures are followed during manufacturing.

Removed p. 192

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.

Modified p. 192 → 146

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

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

Modified p. 192 → 146

~~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 access-controlled area where devices and components are stored prior to shipping.

TE6.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail tamper-evident packaging or the access-controlled area where devices and components are stored prior to shipping.

Modified p. 192 → 146

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

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

Modified p. 192 → 146

~~TL5.5~~ The tester shall examine a sample of documentation for post-production storage, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed.

TE6.4 The tester shall examine a sample of documentation for post-production storage, including inventory logs, shipping documentation, and device-validation procedures to ensure procedures are followed.

Modified p. 192 → 146

~~TL5.6~~ The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.

TE6.5 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.

Modified p. 192 → 146

~~TL5.7~~ The tester shall examine the vendor’s tamper-evident packing or access-controlled area to ensure unauthorized access to devices or their components is not possible.

TE6.6 The tester shall examine the vendor’s tamper-evident packing or access-controlled area to ensure unauthorized access to devices or their components is not possible.

Removed p. 193

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.

Modified p. 193 → 147

Authentication by secret information ~~will become~~ mandatory in POI v6.

Authentication by secret information is mandatory in POI v6.

Modified p. 193 → 147

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

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

Modified p. 193 → 147

~~TL6.3~~ The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the facility of initial deployment by means of secret information placed in the device during manufacturing. The secret information is installed in the device under dual control to ensure that it is not disclosed during installation, or the device may use an authenticated public-key method.

TE7.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that the device will be authenticated at the facility of initial deployment by means of secret information placed in the device during manufacturing. The secret information is installed in the device under dual control to ensure that it is not disclosed during installation, or the device may use an authenticated public-key method.

Modified p. 193 → 147

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

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

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

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

Modified p. 193 → 147

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

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

Modified p. 193 → 147

~~TL6.6~~ The tester shall observe the device secret installation and validation process to ensure that documented and approved procedures are followed subsequent to production. The tester shall verify that if secret information is placed in the device during manufacturing, then this secret information is unique to each device, unknown and unpredictable to any person, and installed in the device under dual control to ensure that it is not disclosed during installation.

TE7.5 The tester shall observe the device secret installation and validation process to ensure that documented and approved procedures are followed subsequent to production. The tester shall verify that if secret information is placed in the device during manufacturing, then this secret information is unique to each device, unknown and unpredictable to any person, and installed in the device under dual control to ensure that it is not disclosed during installation.

Removed p. 194

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.

Modified p. 194 → 148

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

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

Modified p. 194 → 148

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

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

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

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

Modified p. 194 → 148

~~TL7.4~~ The tester shall examine a sample of approved documentation for component control during design and development, including user documentation, and component validation procedures to ensure procedures are followed.

TE8.3 The tester shall examine a sample of approved documentation for component control during design and development, including user documentation, and component validation procedures to ensure procedures are followed.

Modified p. 194 → 148

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

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

Modified p. 194 → 148

~~TL7.6~~ The tester shall verify that the manufacturer maintains approved development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the POI security- related components in their development environment and that this provides evidence that these security measures are followed during the development and maintenance of the POI security-related components.

TE8.5 The tester shall verify that the manufacturer maintains approved development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the POI security- related components in their development environment and that this provides evidence that these security measures are followed during the development and maintenance of the POI security-related components.

Removed p. 195

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.

Modified p. 195 → 149

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

TE9.1 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.

Modified p. 195 → 149

~~TL8.3~~ The ~~tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The approved documentation should detail the~~ inspection process and tamper-evident packaging or the access-controlled area where devices and components are stored prior to shipping.

• The inspection process and tamper-evident packaging or the access-controlled area where devices and components are stored prior to shipping.

Modified p. 195 → 149

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

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

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

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

Modified p. 195 → 149

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

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

Modified p. 195 → 149

~~TL8.6~~ The tester shall observe the device repair, inspection and post-inspection storage process to ensure that procedures are followed subsequent to production.

TE9.5 The tester shall observe the device repair, inspection and post-inspection storage process to ensure that procedures are followed subsequent to production.

Modified p. 195 → 149

~~TL8.7~~ The tester shall examine the vendor’s tamper-evident packing or accessed-controlled area to ensure unauthorized access to devices or their components is not possible.

TE9.6 The tester shall examine the vendor’s tamper-evident packing or accessed-controlled area to ensure unauthorized access to devices or their components is not possible.

Removed p. 196

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

Modified p. 196 → 153

• Evidence of existence

•i.e., that these procedures are implemented. ~~Example: The~~ lab has received procedures from the company that implements the requirement.

• Evidence of existence

•i.e., that these procedures are implemented. For example, the lab has received procedures from the company that implements the requirement.

Modified p. 196 → 153

DTR M1 Shipping Tamper-Protection Documentation The POI should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI.

DTR F1 Shipping Tamper-Protection Documentation The POI should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI.

Modified p. 196 → 153

Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key- loading facility or to the facility of initial deployment and stored ~~en route~~ under auditable controls that can account for the location of every POI at every point in time•such as the use of serialized tamper-evident packing for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.

Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key- loading facility or to the facility of initial deployment and stored enroute under auditable controls that can account for the location of every POI at every point in time•such as the use of serialized tamper-evident packing for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.

Modified p. 196 → 153

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

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

Modified p. 197 → 154

~~TM1.4~~ The tester shall interview those responsible for the shipping control processes

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

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

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

Modified p. 197 → 154

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

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

Modified p. 197 → 154

~~TM1.6~~ The tester shall observe the shipping process to ensure that customers are provided documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI or alternatively, the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored ~~en route~~ under auditable controls.

TF1.6 The tester shall observe the shipping process to ensure that customers are provided documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI or alternatively, the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored enroute under auditable controls.

Removed p. 198

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.

Modified p. 198 → 155

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

TF2.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment. …

Modified p. 198 → 155

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

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

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

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

Modified p. 198 → 155

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

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

Modified p. 198 → 155

~~TM2.5~~ The tester shall observe of the shipping and transfer procedures to ensure that procedures are followed to transfer accountability for the device from the manufacturer to the facility of initial deployment.

TF2.4 The tester shall observe of the shipping and transfer procedures to ensure that procedures are followed to transfer accountability for the device from the manufacturer to the facility of initial deployment.

Modified p. 198 → 155

~~TM2.6~~ The tester shall verify that where the device is shipped via intermediaries such as resellers, accountability is with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment.

TF2.5 The tester shall verify that where the device is shipped via intermediaries such as resellers, accountability is with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment.

Removed p. 199

• Shipped and stored in tamper-evident packaging; and/or

• Shipped and stored containing a secret that:

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.6 The tester shall observe the shipping process to ensure that POI devices are 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.

Modified p. 199 → 156

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

TF3.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence and describe how this shows compliance to this requirement.

Modified p. 199 → 156

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

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

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

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

Modified p. 199 → 156

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

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

Modified p. 199 → 156

~~TM3.5 If the device is shipped with secret keys, the~~ tester shall examine a sample of documentation for tamper protection using secret keys to ensure approved procedures for validation at the ~~key- loading~~ faculty are followed.

TF3.4 The tester shall examine a sample of documentation for tamper protection using secret keys to ensure approved procedures for validation at the key-loading faculty are followed.

Removed p. 200

TM4.1 The tester shall examine the vendor’s response to Section M4 of the PCI PTS POI Evaluation Vendor Questionnaire and the response to Requirement M4 of the PCI PTS POI Security Requirements for consistency relevant to assure the authenticity of the TOE’s security-relevant components at the initial key-loading facility. The tester shall summarize the responses.

Modified p. 200 → 157

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

TF4.1 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 device’s security-relevant components and describe how this shows compliance to this requirement.

Modified p. 200 → 157

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

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

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

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

Modified p. 200 → 157

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

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

Modified p. 200 → 157

~~TM4.5~~ The tester shall observe the secure development component control procedures to ensure security measures are followed during the initial key loading.

TF4.4 The tester shall observe the secure development component control procedures to ensure security measures are followed during the initial key loading.

Removed p. 201

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.

Modified p. 201 → 158

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

TF5.1 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 device’s security relevant components.

Modified p. 201 → 158

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

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

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

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

Modified p. 201 → 158

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

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

Modified p. 201 → 158

~~TM5.5~~ The tester shall observe the initial key-loading procedures to ensure the authenticity of the POI security-related components is verified.

TF5.4 The tester shall observe the initial key-loading procedures to ensure the authenticity of the POI security-related components is verified.

Removed p. 202

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.

Modified p. 202 → 159

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

TF6.1 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 device’s security-relevant components for the initial key- loading facility.

Modified p. 202 → 159

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

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

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

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

Removed p. 203

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.

Modified p. 203 → 160

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

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

Modified p. 203 → 160

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

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

Modified p. 203 → 160

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

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

Removed p. 204

• Hardware version identification

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.

Modified p. 204 → 161

~~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 the POI security-related components and the manner in which those components are integrated into a single POI. The operations management manual must be current and up to date.

TF8.1 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should include instructions for recording the entire life cycle of the POI security-related components and the manner in which those components are integrated into a single POI. The operations management manual must be current and up to date.

Modified p. 204 → 161

~~TM8.3~~ The tester shall interview those responsible for maintaining the operation management manual

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

TF8.2 The tester shall interview those responsible for maintaining the operation management manual

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

Modified p. 204 → 161

~~TM8.4~~ The tester shall examine a sample of the operations management manual to ensure procedures are followed and recorded.

TF8.3 The tester shall examine a sample of the operations management manual to ensure procedures are followed and recorded.

Modified p. 207 → 164

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. 207 → 164

5. The protection is based on viewing angles and does not imply a specific technical implementation like physical shields. If the keypad is implemented as a ~~touch screen,~~ the viewing barrier may be implemented by polarizers (for example, as film embedded within layers of a ~~touch screen),~~ which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.

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 touchscreen, the viewing barrier may be implemented by polarizers (for example, as film embedded within layers of a touchscreen), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.

Removed p. 210

2. A handheld device must by weight, size, and shape encourage its handheld operation. The criteria

c) Sum of width and height at the “5” key should not be more than four (4) inches or 10.16 cm; and

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

Modified p. 210 → 167

1. The requirements differentiate between ~~a handheld device,~~ an attended ~~device~~ or an unattended device. ~~It must be clearly stated what the~~ intended use of the device ~~is.~~

1. The requirements differentiate between an attended device, handheld, touchscreen, or an unattended device. The intended use of the device must be clearly stated.

Modified p. 210 → 167

3. The privacy screen of the device is to be placed horizontally or slightly tilted (0    45°) and shall provide the following protection angles:

The privacy screen of the device is to be placed horizontally or slightly tilted (0    45°) and shall provide the following protection angles:

Modified p. 210 → 167

4. If the device is to be placed vertically or tilted by 45° and more, the requirements under Step 3 will apply accordingly, using the vertical plane instead of the horizontal plane as the reference for the angle .

2. If the device is to be placed vertically or tilted by 45° and more, the requirements under Step 3 will apply accordingly, using the vertical plane instead of the horizontal plane as the reference for the angle .

Modified p. 210 → 167

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.

3. 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 touchscreen, the viewing barrier may be implemented by polarizers (for example, as film embedded within layers of a touchscreen surface), which deter the observation from the sides. The up (clerk) side must be implemented as a physical shield.

Modified p. 211 → 169

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

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

Modified p. 211 → 169

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

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

Modified p. 211 → 169

Other methods are possible as well. The above are examples of some of the methods a vendor can propose to protect PINs during PIN entry. The vendor must provide adequate techniques in the device documentation and also include a matrix showing which techniques should be used to protect against specific observation corridors. An example matrix ~~follows:~~

Other methods are possible as well. The above are examples of some of the methods a vendor can propose to protect PINs during PIN entry. The vendor must provide adequate techniques in the device documentation and also include a matrix showing which techniques should be used to protect against specific observation corridors. Table A1 on the following page shows an example matrix .

Modified p. 213 → 171

d) Equipment required such as instruments, components, IT hardware, and software required for the

d) Equipment required such as instruments, components, IT hardware, and software required for the analysis;

Modified p. 214 → 173

a) Public information about the POI device (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.

a) Public information about the POI device (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor without any control mechanism⎯e.g., to any customer. Examples include open protocol specifications and electronic component datasheets. Information with automated access-control mechanisms (such as online account subscription) without human intervention classifies as Public.

Modified p. 214 → 173

b) Restricted information concerning the POI device (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (for example, like the PCI PTS POI DTRs).

b) Restricted information concerning the POI device (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (for example, like the PCI PTS POI DTRs). Restricted information is distributed upon request and is subject to human-based control mechanisms. Examples of restricted information are mechanical drawings for OEM device integration, external command API specifications, partial Gerber files, and secure processor datasheets available under NDA.

Modified p. 214 → 173

c) Sensitive information about the POI device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).

c) Sensitive information about the POI device (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering). Sensitive information is not intended to be distributed to external entities and is obtained by means such as “social engineering” theft or coercion. Typical examples are terminal schematics and firmware source code.

Modified p. 214 → 173

Distinction must be made between information required to identify the vulnerability and the information required to exploit it, especially in the area of sensitive information. Requiring sensitive information for exploitation would be unusual.

Distinction must be made between information required to identify the vulnerability and the information required to exploit it, especially in the area of sensitive information. Requiring restricted or sensitive information for exploitation would be unusual.

Modified p. 215 → 175

b) Specialized equipment isn’t readily available to the ~~attacker,~~ but could be acquired without undue effort.

b) Specialized equipment isn’t readily available to the attacker but could be acquired without undue effort.

Modified p. 216 → 176

Parts used during the Identification phase that can be used in the initial exploitation must be counted fully in the Exploitation phase to equalize the attack potential value across all exploitations. If it is not readily reusable (the part once used in installation becomes unusable for exploitation because, for example, it is glued with epoxy and difficult to remove), ~~then~~ it can be accounted for ~~twice: once~~ in the Identification phase and again in the Exploitation phase.

Parts used during the Identification phase that can be used in the initial exploitation must be counted fully in the Exploitation phase to equalize the attack potential value across all exploitations. While equipment readily lends itself to reuse for each exploitation, parts are typically a one-time use for each exploitation. Each exploitation should have the same attack potential value. Accounting for parts that are reused in the initial exploitation only in the Identification phase, or even splitting between the Identification …

Modified p. 216 → 177

• Knowledge If several attack scenarios lead to the same potential in ~~total and exploitation,~~ then the one that has the lowest cost in exploitation, exclusive of the items above, must be considered. Attack calculations must allocate ratings that assume the most conservative trade-offs between time, expertise and equipment. Particularly, attack calculations shall not distribute ratings in a way that increases overall and/or exploitation minimum ratings above the most conservative approach.

• Knowledge If several attack scenarios lead to the same potential in total, then the one that has the lowest cost in exploitation, exclusive of the items above, must be considered. Attack calculations must allocate ratings that assume the most conservative trade-offs between time, expertise and equipment. Particularly, attack calculations shall not distribute ratings in a way that increases overall and/or exploitation minimum ratings above the most conservative approach.

Modified p. 217 → 179

Table B2: Attack Potential Factors Identification Exploitation Attack time ≤ 1 hour 0 0 ≤ 2 hours 1 1 ≤ 4 hours 1.5 1.5 ≤ 6 hours 2 2 ≤ 8 hours 3 3 ≤ 12 hours 4 4 ≤ 16 hours 4.5 4.5 ≤ 24 hours 5 5 ≤ 40 hours 5.5 5.5 ≤ 60 hours 6 6 ≤ 100 hours 6.5 6.5 ≤ 160 hours 7 7 Beyond 160 hours 7.5 7.5 Expertise Layman 0 0 Skilled 1 …

Table B2: Attack Potential Factors Factor Range Identification Exploitation Attack time ≤ 1 hour 0 0 ≤ 2 hours 1 1 ≤ 4 hours 1.5 1.5 ≤ 6 hours 2 2 ≤ 8 hours 3 3 ≤ 12 hours 4 4 ≤ 16 hours 4.5 4.5 ≤ 24 hours 5 5 ≤ 40 hours 5.5 5.5 ≤ 60 hours 6 6 ≤ 100 hours 6.5 6.5 ≤ 160 hours 7 7 Beyond 160 hours 7.5 7.5 Expertise Layman 0 0 …

Modified p. 217 → 179

Mechanical sample 1 1 Functional samples without working keys Functional sample with working keys and software Equipment required for the attack None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5 Chip-level attacks 7 7 ~~Specific parts required None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5~~

Mechanical sample 1 1 Functional samples without working keys Functional sample with working keys and software Equipment required for the attack None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5 Chip-level attacks 7 7

Modified p. 218 → 180

Attack Examples In the ~~following,~~ attacks on a very well-designed device are described. The device is very compact and there is limited space inside the device; ~~therefore~~ it is assumed that a bug or its circuit has to be installed into a fake housing that provides more space than the original housing. One attack is targeted on the keypad signals and one on the ICC Reader. The following two attacks are targeted on the MSR reader.

Attack Examples In the following examples, attacks on a very well-designed device are described. These examples are intended to illustrate how attack ratings may be represented. New devices must be rated through direct testing and under no circumstances may have ratings relying on these examples. The device is very compact and there is limited space inside the device; therefore, it is assumed that a bug or its circuit has to be installed into a fake housing that provides more space …

Modified p. 218 → 180

3. The housing has to be opened by removing a part of the backside. The corresponding keypad controller has to be accessed. Therefore, the security mesh must be circumvented without damaging or short-cutting this mesh. For the deactivation of the relevant parts of the security mesh, ~~a functional sample is necessary (the mesh is in most cases reparable in case of a shortcut or damage). The work can be performed by someone who is Proficient.~~

3. The housing has to be opened by removing a part of the backside. The corresponding keypad controller has to be accessed. Therefore, the security mesh must be circumvented without damaging or short-cutting this mesh. For the deactivation of the relevant parts of the security mesh,

Modified p. 225 → 187

Table used for Exploitation

• Attack Example 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Skilled Public Standard Standard 1 functional with working keys and SW 2 Skilled Public Standard Standard Same functional 2 hours 3 Skilled Public None None None 30 minutes Total Skilled Public Standard Standard 1 functional with working keys and SW Combined Attack Potential Rating for MSR Bug replacement

• Attack Example 3 Aspect Identifying Value Exploiting Value Attack time a: ≤ 100 hours b: ≤ 40 …

Modified p. 228 → 190

5. A PIN-disclosing bug is placed into the PED housing of a functional sample. In this example, the keypad matrix lines have to be connected (fixing/gluing) to the additional circuit with thin wires with help of standard equipment. The manipulated device has to be tested. The work has to be performed by a ~~proficient~~ attacker.

5. A PIN-disclosing bug is placed into the PED housing of a functional sample. In this example, the keypad matrix lines have to be connected (fixing/gluing) to the additional circuit with thin wires with help of standard equipment. The manipulated device has to be tested. The work has to be performed by a skilled attacker.

Modified p. 230 → 192

The attack aims at the determination of DES/AES and RSA keys used for various purposes (e.g., ~~account data~~ encryption, key download, MACing, building the TLS session layer etc.) at the device using differential power analysis (DPA).

The attack aims at the determination of DES/AES and RSA keys used for various purposes (e.g., account-data encryption, key download, MACing, building the TLS session layer etc.) at the device using differential power analysis (DPA).

Removed p. 234

• Electron tunneling microscope/Scanning Electron Microscope Note on “parts”: Although this document does not seek to outline all types of parts, it is considered that the vast majority of PIN bugs will be considered as standard parts, including those that use a flexible circuit mat to cover the keypad (as this is very common during PIN attacks).

Modified p. 235 → 197

The following settings are consistent with the SP 800-22 Revision 1a document:

Table C2: Configuration Settings The following settings are consistent with the SP 800-22 Revision 1a document:

Removed p. 238

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.

Modified p. 238 → 201

~~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 size of the modulus. The Elliptic Curve key …

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

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

• Key size in number of bits:

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

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

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

Modified p. 238 → 201

For implementations using ~~Diffie-Hellman (DH)~~ or ~~Elliptic Curve Diffie-Hellman (ECDH):~~

For implementations using FFC or ECC:

Modified p. 238 → 201

• ~~DH implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p -~~ 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity ~~shall~~ generate a private key x and a public key y using the domain parameters (p, q, g).

• 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g).

Modified p. 238 → 201

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

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

Modified p. 238 → 201

• Each private key ~~shall~~ be statistically unique, unpredictable, and created using an approved random number generator as described in this document.

• Each private key must be statistically unique, unpredictable, and created using an approved random number generator as described in this document.

Modified p. 238 → 201

• Entities must authenticate the DH or ~~ECDH~~ public keys using DSA, ECDSA, a certificate, or a ~~symmetric~~ MAC (see ISO 16609

•Requirements for message authentication using symmetric techniques. One of the ~~following:~~ MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method ~~4, should be used.~~

• Entities must authenticate the FFC or ECC public keys using DSA, ECDSA, a certificate, or a MAC (see ISO 16609

•Requirements for message authentication using symmetric techniques. One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4).

Removed p. 239

Note: This appendix is for use in conjunction with the Determining Keys Analysis requirements in Core and SRED.

Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, or may show how a key can be fully exposed but at an acceptable level of difficulty, or may produce a partial result. In every case, a test determining compliance will demonstrate that an attack in the field is infeasible with respect to PTS Security Requirements’ pass/fail thresholds.

This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a feasible method to …

Modified p. 239 → 202

Introduction Side-channel analysis (SCA) is an important activity in PCI PTS evaluations, relevant to tests where the highest levels of confidence in security assurance are needed, ~~as part of Determining Keys Analysis•for~~ example, DTR ~~A5, requiring 35 points rating overall / 15 points minimum in exploitation.~~ In these tests, it is necessary to derive an accurate measure of the effort to defeat a device using SCA techniques, distinctly from any physical penetration/modification.

Introduction Side-channel analysis (SCA) is an important activity in PCI PTS evaluations, relevant to tests where the highest levels of confidence in security assurance are needed, for example, DTR A7. In these tests, it is necessary to derive an accurate measure of the effort to defeat a device using SCA techniques, distinctly from any physical penetration/modification.

Modified p. 240 → 203

PCI SSC expects laboratory hardware equipment and software tools to be fit for purpose for performing SCA. These resources must be sufficiently well developed to enable testers to determine devices’ strengths and/or vulnerabilities, and to be able produce evidence of this. The following list outlines minimum expectations for test resources.

PCI SSC expects laboratory hardware equipment and software tools to be fit for purpose for performing SCA. These resources must be sufficiently well developed to enable testers to determine devices’ strengths and/or vulnerabilities, and to be able to produce evidence of this. The following list outlines minimum expectations for test resources.

Modified p. 241 → 204

• SCA toolsets are updated incrementally ~~to:~~ improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.

• SCA toolsets are updated incrementally to improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.

Modified p. 241 → 204

SCA must not be hindered by lack of basic resources PCI SSC considers to be ~~essential.~~

SCA must not be hindered by lack of basic resources PCI SSC considers to be essential:

Modified p. 241 → 204

• SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary, available tools can overcome straightforwardly. The following non-exhaustive list gives examples of factors related to PCI SSC’s expectations in testing.

SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary, available tools can overcome straightforwardly. The following non-exhaustive list gives examples of factors related to PCI SSC’s expectations in testing.

Removed p. 242

• Alignment: Time synchronization is a crucial step in almost all SCA attacks. For example, DPA attacks can often succeed straightforwardly after a small number of CPU clock cycles (or sample points) have been well synchronized, but not without achieving this. Moreover, many aspects of timing variation in waveforms that outwardly appear to obstruct analysis

•for example, randomly occurring delays

•can in practice be removed straightforwardly. Hence, the evaluation should utilize the types of various alignment techniques available to expert attackers. A single application of alignment processing is often insufficient. In most situations, when a simple, or approximate, or limited-scope alignment test is performed, that approach is insufficient unless highly effective obstructions to alignment can be demonstrated.

Modified p. 242 → 205

• Understanding of the algorithm(s) to be attacked and how they are implemented: Determining the appropriate side channel(s) to acquire, collection method(s), and analysis tools and their configuration. Next, validating that the device behaves as expected before proceeding further; if necessary, gathering additional information and/or reconfiguring the test setup as required. This includes validation ~~of:~~ hardware/software identifiers and claimed countermeasures.

• Understanding of the algorithm(s) to be attacked and how they are implemented: Determining the appropriate side channel(s) to acquire, collection method(s), and analysis tools and their configuration. Next, validating that the device behaves as expected before proceeding further; if necessary, gathering additional information and/or reconfiguring the test setup as required. This includes validation of hardware/software identifiers and claimed countermeasures.

Modified p. 242 → 205

• Characterizing side-channel behavior through approaches such as SPA/SEMA: A critical goal of this phase is to identify events in the algorithm under attack, to localize sensitive operations. Specific checks are necessary for certain test methods

•for example, for EMA the relative location of the EM probe to the device’s components is a highly sensitive variable factor. In many situations no useful features can be determined upon first inspection. In this case, it is necessary to explore either whether there are …

Modified p. 242 → 206

• Correlation: Computations such as (but not restricted to) the Pearson product-moment coefficient are a crucial element in a test’s capability to achieve alignment. Effective correlation capabilities are also crucial for identification of leakage that may often be obscured, for example ~~to:~~ identify ~~security-significant~~ patterns in waveforms, test a device’s relative susceptibility to leak internally processed data, localize sensitive operations for making well-targeted attacks, launch and develop attacks to infer secret data values. The evaluation should use correlation-analysis techniques equivalent …

• Correlation: Computations such as (but not restricted to) the Pearson product-moment coefficient are a crucial element in a test’s capability to achieve alignment. Effective correlation capabilities are also crucial for identification of leakage that may often be obscured, for example to identify security- significant patterns in waveforms, test a device’s relative susceptibility to leak internally processed data, localize sensitive operations for making well-targeted attacks, launch and develop attacks to infer secret data values. The evaluation should use correlation-analysis techniques …

Modified p. 243 → 206

• Signal analysis and processing: All side-channel recordings will contain a certain degree of noise in acquired waveforms

•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: ~~SPA~~ patterns, correlation leakage pinpointing sensitive operations, and ~~key-dependent~~ leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual countermeasures …

• Signal analysis and processing: All side-channel recordings will contain a certain degree of noise in acquired waveforms

•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA/SEMA patterns, correlation leakage pinpointing sensitive operations, and key- dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual …

Modified p. 243 → 206

• Cryptanalysis: Attacks such as DPA succeed by discriminating a few inferences of guessed key values from among many other possible values. One specific algorithm’s key-leakage potential is unlikely to be similar to another algorithm or implementation. Detectable leakage is often highly dependent on the options an attacker pursues. Hence, a simplistic implementation of a published attack, alone, is often insufficient to validate a device’s compliance; and the evaluation should make use of attack-modeling options available to expert attackers. Examples …

Modified p. 243 → 207

• Optimization: There are many approaches that will improve the chance of SCA success, considering the application of critical steps such as those outlined above. Depending on the discoveries made early in analysis, it is likely that some of the steps performed should be adapted, branched, and repeated

•for example, by iteratively re-applying well-chosen processes. Large data size may become problematic in some situations; however expert attackers are skilled in overcoming this unless robust obstacles are present

•for example, analysis time may …

Modified p. 243 → 207

• Validation: It is necessary for evaluations to check that critical steps performed in tests have the potential to succeed. It is often difficult to distinguish between a device’s apparently robust resistance to attacks versus results deriving from a flawed or naive testing approach. For example, the absence of significant correlation leakage may be due to several situations that produce similar outcomes: errors in correlation calculations, bugs in analysis tools, inappropriate choice of analysis

• Validation: It is necessary for evaluations to check that critical steps performed in tests have the potential to succeed. It is often difficult to distinguish between a device’s apparently robust resistance to attacks versus results deriving from a flawed or naive testing approach. For example, the absence of significant correlation leakage may be due to several situations that produce similar outcomes: errors in correlation calculations, bugs in analysis tools, inappropriate choice of analysis parameters, poor alignment, under-sampling or poor …

Removed p. 245

For “System on Chip” type cryptographic implementations, 5 days’ expert-level work and 50,000 traces are required, so long as multiple effective SCA countermeasures are validated and demonstrated through practical testing. It is very likely that a significant part (even the majority) of the test effort will involve processing data (e.g., iteratively collecting, analyzing, filtering, aligning, performing correlation trials) following initial collections, to optimize inputs to key attacks.

Modified p. 245 → 210

Testing from separate evaluations meeting these best practices criteria can be reused, provided that (1) testing is no longer than ~~three years old,~~ and (2) a complete chain of trust is demonstrated validating why previous testing is wholly applicable to a newly evaluated device.

Testing from separate evaluations meeting these best practices criteria can be reused, provided that (1) testing is no longer than from the previous major version of the standard (e.g., v5.x work can be reused if appropriate as part of a v6.x review and (2) a complete chain of trust is demonstrated validating why previous testing is wholly applicable to a newly evaluated device. For “System on Chip” (SoC) type cryptographic implementations, where expert-level work, multiple effective SCA countermeasures, and collection …

Modified p. 246 → 210

Reusing results Since multiple devices commonly use same security processor or System on Chip for cryptographic operations, it can be useful to reuse results from other evaluations to decrease the efforts for side- channel analysis. Nevertheless, to ensure the transferability of results, the following points have to be considered:

Reusing results Tests identifying little or no correlation and/or algorithmic structure are generally insufficient for reuse. Since multiple devices commonly use same security processor or System on Chip for cryptographic operations, it can be useful to reuse results from other evaluations to decrease the efforts for side- channel analysis. Nevertheless, to ensure the transferability of results, the following points have to be considered:

Modified p. 246 → 210

• The identification and configuration of the cryptographic component has to be compared to ensure that the results also apply to the device under evaluation

•e.g., registers for enabling/disabling ~~counter measures,~~ etc.

• The identification and configuration of the cryptographic component has to be compared to ensure that the results also apply to the device under evaluation

•e.g., registers for enabling/disabling countermeasures, etc.

Modified p. 246 → 210

• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the ~~reports, respectively~~ the SCA part of the ~~reports, be~~ provided to the evaluation lab ~~that wants~~ to reuse the results.

• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports

•i.e., the SCA part of the reports

•are provided to the evaluation lab wanting to reuse the results.

Removed p. 248

Applications are any code in the device that cannot impact any of the functionality needed to comply with PCI POI requirements (with the exception of prompt control and SRED applications).

Additional considerations Separation between firmware and applications must be implemented by the firmware (B17). It must be enforced that applications cannot intentionally (or unintentionally because they have been hacked):

• Read keys from or write known keys into the key store provided by the firmware, which can be used for PIN or SRED encryption (which implies that the key store API must be sufficiently hardened so that it does not allow for typical HSM API attacks).

• Have access to a clear-text PIN, which can be used in a payment transaction facilitated by the firmware (which implies that the application must not be able supply a PIN value for encryption to the firmware).

• Have access to any secondary assets relevant for the security …

Removed p. 250

Figure 1: 8-bit Microprocessor + 32-bit SoC with Linux This is assuming that NFC Radio, Encrypting MSR, and GSM module have updateable code. All keys are stored and used only in the 8-bit CPU.

Code Part Scope (only highest level listed), see Table G1 8-bit CPU Core (Keys) NFC Radio SRED (Account Data processing) Encrypting MSR SRED (Keys) 32-bit SoC Core (Public Keys), OP Application(s) Application (Display)

Note: In this case, NFC Radio, Encrypting MSR, and GSM are required to support B1.

Removed p. 251

Figure 2: 32-bit SoC with Linux + 32-bit SoC with Linux This is assuming that all keys are stored in the left SoC. NFC radio code is not updateable. SRED cannot be turned off.

Code Part Scope, see Table G1 Left 32-bit SoC Core (Keys) NFC Radio SRED (Account Data Processing), no B1 Right 32-bit SoC OP Application(s) Application (other)

Removed p. 252

Figure 3: 32-bit SoC with Linux and attached COTS device It is assumed that the guidance and the listing declare that the COTS device has not been assessed.

Code Part Scope, see Table 32-bit SoC Core (Keys) NFC Radio SRED (Account Data Processing), no B1 COTS device and communication interfaces

• Protection Levels Table G1: Required protection levels Scope Hardware Protection against Modification Logical Protection Core (Secret and Private Keys) 35 B1, B2, B4, J4 Core (Public Keys) 26 B1, B2, B4, J4 Core (PIN processing) 26 B1, B2, B4, J4 Core (Prompt control) 18 B1, B2, B4, J4 SRED (Keys) 26 B1, B2, B4, J4 SRED (Account data processing) 16 B1, B2, B4, J4 OP 0 B1, B4, OP, J4 Application (Display) 18 B4.1, B16 Application (Account Data) 16 B4.1, K11.1 Application (Other, no access to display and account data)

Removed p. 255

• and whether it is for attended, unattended, or both.

Modified p. 255 → 235

General Description ~~Product~~ Name and ~~Appearance:~~

General Description Model Name and Appearance

Modified p. 255 → 235

• This should include the name of the ~~product~~ and where to locate the ~~product~~ name. This should also include a picture of the device and the label.

• This should include the name of the model and where to locate the model name. This should also include a picture of the device and the label.

Modified p. 256 → 236

• Additional information should be provided for any device where the required memory ~~re- initialization~~ (security) cycle lasts longer than 24 hours. Specifically, describe how the firmware of the device during the cycle’s adjustment processes does not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours).

• Additional information should be provided for any device where the required memory re-initialization (security) cycle lasts longer than 24 hours. Specifically, describe how the firmware of the device during the cycle’s adjustment processes does not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours).

Removed p. 257

• If the device does not the support removal-detection requirement, its usage is restricted to attended environments, or to semi-attended environments, and any other usage invalidates the approval.

Modified p. 257 → 237

• This section contains references to any software-development guidance required for compliance, if applicable, with ~~the Module 3 (Open Protocol)~~ and ~~Module 4 (SRED)~~ requirements. This documentation must clearly outline which functions, APIs, or modes of operation of cryptographic functions (such as cipher suites) have been evaluated by the PTS laboratory for securing cardholder data.

• This section contains references to any software-development guidance required for compliance, if applicable, with Open Protocols and SRED requirements. This documentation must clearly outline which functions, APIs, or modes of operation of cryptographic functions (such as cipher suites) have been evaluated by the PTS laboratory for securing cardholder data.

Removed p. 258

Account Data Protection

Modified p. 258 → 238

• This section details any ~~account data~~ protection schemes employed

•e.g., algorithms used, ~~format-preserving~~ encryption techniques

•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.

• This section details any account-data protection schemes employed

•e.g., algorithms used, format- preserving encryption techniques

•and whether the device supports the pass-through of clear-text account data using techniques such as whitelisting.

Modified p. 258 → 238

• This section contains specific details on the cryptographic algorithms (TDES, SHA-2, etc.) and ~~key-management~~ methodologies supported by the device. It must detail the specific keys and usages of these keys for all key-management methods exposed to the device operators.

• This section contains specific details on the cryptographic algorithms (TDES, SHA-2, etc.) and key- management methodologies supported by the device. It must detail the specific keys and usages of these keys for all key-management methods exposed to the device operators.

Modified p. 258 → 238

• The section clearly outlines the exact details of the key-management systems supported by the ~~devicei.e.,~~ simply using the term “MK/SK” is not ~~sufficientand~~ specifies that use of the device with different key-management systems will invalidate any PCI PTS POI approval.

• The section clearly outlines the exact details of the key-management systems supported by the device⎯i.e., simply using the term “MK/SK” is not sufficient⎯and specifies that use of the device with different key-management systems will invalidate any PCI PTS POI approval. Include key name, purpose/usage, algorithm, key size, form factor in which key is loaded to the device, number of keys of each usage type supported, etc.

Document Comparison

Content Changes