Document Comparison

PCI_EPP_DTRs_v1-0.pdf PCI_EPP_DTRs_v2-1.pdf
54% similar
38 → 43 Pages
13538 → 14436 Words
190 Content Changes

From Revision History

  • September 2006 2.x Draft published for comment

Content Changes

190 content changes. 58 administrative changes (dates, page numbers) hidden.

Added p. 1
Payment Card Industry (PCI) Encrypting PIN Pad (EPP) Derived Test Requirements Version 2.1

September 2006 2.x Draft published for comment

November 2006 2.x Formatting changes

April 2007 2.x A7, A11, B1, B4, Appendices A and B
Added p. 3
January 2009 2.1 Clarifications and errata In order to provide greater consistency with International Standards and to generalize the calculations, requirements that formerly were based on a dollar threshold for attacks have been converted to a point- based attack potential scheme.

Additional guidance notes have been added for emphasis. These guidance notes exist in the Technical FAQ for the current requirements. The Technical FAQ is available at www.pcisecuritystandardscouncil.org.
Added p. 6
Requirement A7 focuses on determination of secret or private keys. This requirement focuses on tamper-detection and response mechanisms in place to prevent PIN disclosure.

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” is any private or secret cryptographic keys or passwords that the EPP relies on to maintain security characteristics governed by PCI requirements. If any of these keys are not zeroized, then other mechanisms must exist to disable the device and these keys must be protected in accordance with Requirement A7.

Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered secret data, and therefore do not need to be erased, e.g., where the device uses a chip set that automatically generates keys at initialization but the keys …
Added p. 9
“Immediate” is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1. Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered sensitive data and therefore do not need to be erased, e.g., where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.

TA2.4 The tester shall attempt to remove the access cover by disabling or defeating the tamper-detection mechanisms. To remove the cover the tester may open, pry, or otherwise disassemble the EPP at the cover seams and remove other plates, connectors, etc. to gain access to the tamper-detection mechanisms. Removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure. The tester may …
Added p. 15
The intent of the requirement is to protect the EPP against removal from the cabinet. This protection aims against inserting an overlay between the EPP and the casing/cabinet within which the EPP is installed and to hinder the removal of the EPP from its working location for an attack under laboratory conditions.

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

Protection against removal may be implemented as detection of removal and procedures for authorized installation or re-installation. The procedures must:

 Use dual control techniques;  Provide accountability and traceability;  Prevent replay of authorization data; and  Cause the device to not process PIN data until authorized to do so.

TA8.3 The tester shall determine whether the device uses passive or active protection, and assess the method for installation and permanent or temporary removal. An option …
Added p. 18
Firmware is considered to be any code within the EPP that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.

Firmware is considered to be any code within the EPP 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.
Added p. 19
TB4.5 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:

Minimum key size in number of bits DES refers to non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup.

Examples of acceptable hashing algorithms include SHA-1, SHA-256, SHA-384 and SHA-512. MD5 is not allowed for use.

Any value can be output as long as it cannot be used to determine PIN values. Using a different value for different digit numbers or groups of numbers is not …
Added p. 21
The EPP must automatically clear its internal buffers when either:

 The transaction is completed, or  The EPP has timed out waiting for the response from the cardholder or merchant.

Plain-text PINs must not exist for more than one minute maximum from the completion of the cardholder’s PIN entry. In all cases, erasure of the plain-text PIN must occur before the tamper-detection mechanisms can be disabled using attack methods described in A1.1.

 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 EPP automatically clears its internal buffers when either the transaction is completed or the EPP has timed out waiting for the response from the cardholder or merchant.

TB6.3 The tester will verify that the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive …
Added p. 23
This applies to each and any transition to the use of sensitive services.
Added p. 25
The following are examples of techniques that may be used to prevent an exhaustive PIN determination attack, such as one using electromechanical solenoids to depress the keys so as to try all possible PINs until the ciphertext produced equals the ciphertext recorded when the EPP was in operational use:

Offline devices that do not have the EPP and the ICC reader integrated into the same secure module, and which are using ISO format 0 and are not using a unique key per transaction for the conveyance of the PIN from the point of entry to the ICC reader, must comply with this requirement.

TDES key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret sharing scheme, e.g., Shamir. Private key components shall be combined using a recognized secret sharing scheme.

An EPP may include more than one compliant key exchange and storage scheme.

This does …
Added p. 27
a) When entering plain-text secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/PINs. The passwords must be entered through the keypad or else conveyed encrypted into the device. These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally changeable by the acquirer, but this is not required. Passwords/PINs are at least five characters.

Entry of key components without the use of at least two separate passwords/PINs results in the zeroization of pre-existing secret keys, i.e., the invoking of the key loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (e.g., multi-acquirer devices), only the hierarchy (specific TMK and …
Added p. 30
TB11.9 The tester shall determine from vendor documentation how (e.g., active or passive erasure) each key is destroyed for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.

 Master/Session The EPP must also support at least one of the following PIN Block Formats if supporting online PIN Entry:

 ISO Format 0  ISO Format 1  ISO Format 3 For offline PIN:

 The PIN that is submitted by the IC reader to the IC shall be contained in a PIN block conforming to ISO Format 2 PIN block. This applies whether the PIN is submitted in plain text or enciphered using an encipherment key of the IC.

 Where the IC Card reader is not integrated into the EPP, and PINs are enciphered only for transmission between the EPP and the IC reader, the EPP shall use one of the PIN block formats specified …
Added p. 38
Multiple Devices It is intended that the Identification phase of an attack calculation accounts for testing and development of an attack, such that the Exploitation phase of an attack is likely be successful. PCI does not intend multiple devices to be used during the attack phase to account for the probability of success. If multiple devices are included as part of an attack, strong justification must be provided. In all cases, the valid attack scenario(s) with the lowest attack potentials must be presented.
Added p. 39
Table 2: Attack Potential Factors Identification Exploitation < 1 hour 0 0 ≤ 1 day 1 2 ≤ 1 week 2 3 ≤ 1 month 3 4 Attack time > 1 month 5 7 Layman 0 0 Proficient 1 1 Expert 2 3 Multiple Expert 5 6 Public 0 0 Restricted 2 2 Knowledge of the EPP Sensitive 3 4 Mechanical sample 1 1 Functional samples without working keys Access to the EPP per unit required for the attack.

Note: If more than one unit is required, the values must be multiplied by the factors given above.
Added p. 40
4. The sensitive data is collected from the EPP.

We assume that more than one sample of the device is needed for the identification phase but only the target device is required for the exploitation phase of the attack. The skill level required is Expert. The same standard equipment is used and required at identification and exploitation time. The following table consists of references to the attack phases.
Added p. 41
Table 4: Attack Potentials Example for DPA Analysis Aspect Identifying Value Exploiting Value Attack time > 1 month 5 < 1 month 3 Expertise Expert 2 Expert 3 Knowledge of the device Restricted 2 Public 0 Access to EPP Functional sample with trial keys 2 Functional sample with working keys Equipment Bespoke 5 Specialized 4 Specific parts Standard 1 No further parts Attack potential per phase 17 14 Total Attack Potential 31 As can be seen from the table, the attack potential is below the margin of 35 for the attack potential high level. If a key can be attacked which does not require the entry of a PIN at the keypad and the attack time is less than a day, the attack potential is even lower.
Added p. 42
A note on sts versions: Prior to version of 1.7, the Discrete Fourier Transform (Spectral) test was conducted using the incorrect peak height threshold value (called T in Section 2.6.4 of SP 800-22) and calculated the normalized difference (d) incorrectly. In order to use an older version of the sts tool, the corrections described in [Kim 2004] should be implemented for this test. In versions 1.7 and later, these corrections are already included.

The tester should request and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor supplied data is interpreted correctly by the sts tool (the sts tool assumes that binary data is in big-endian formatting on all platforms).

All tests other than the Lempel-Ziv test should be run [0] (for later versions of sts, the Lempel-Ziv test is normally inaccessible).

The sts testing on the data shall be judged as a …
Removed p. 2
March 2005 1.0 New document based on a subset of the PCI PIN Entry Device Security Requirements.
Removed p. 4
For example, the first DTR under A1.1.1 is:
Modified p. 4 → 5
• Physical Security Derived Test Requirements, and
• Physical Security Derived Test Requirements,
Modified p. 4 → 5
• Logical Security Derived Test Requirements Each PCI requirement as stated in the PCI Encrypting PIN Pad Security Requirements manual is represented by a subsection. For example, Requirement A1.1 is represented in this document as:
• Logical Security Derived Test Requirements Each PCI requirement as stated in the PCI Encrypting PIN PAD (EPP) Security Requirements manual is represented by a subsection. For example, Requirement A1.1 is represented in this document as:
Modified p. 4 → 5
DTR A1.1 Tamper-detection Mechanisms Each PCI requirement has been divided into its component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement.
DTR A1.1 Tamper-Detection Mechanisms When appropriate, each PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement.
Removed p. 5
A1.1.2 The tamper-detection mechanisms cause the EPP to become immediately inoperable and results in the automatic and immediate erasure of any secret information, which may be stored in the EPP.

• Attack scenarios should consider keypad removal or replacement associated with vending machines or such like.

TA1.1.2.1a The tester shall open the EPP to activate the tamper-detection mechanisms and then perform tests to support evidence that the EPP is no longer operational. Tests that may be performed could include:
Modified p. 5 → 6
TA1.1.1.1 The tester shall visually inspect the tamper-detect mechanism to verify the assertions provided by the vendor in response to Section A1.1 of the PCI EPP Evaluation Vendor Questionnaire relating to the tamper-detection mechanism.
TA1.1.1 The tester shall visually inspect the tamper-detect mechanism to verify the assertions provided by the vendor in response to Section A1.1 of the PCI EPP Evaluation Vendor Questionnaire relating to the tamper-detection mechanism.
Modified p. 5 → 6
TA1.1.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA1.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 5 → 6
• “Immediate” is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.
Immediate is defined as fast enough to ensure erasure occurs before the tamper-detection mechanisms can be disabled using attack methods described in A1.1.
Modified p. 5 → 7
TA1.1.2.2 The tester shall examine the response to Section A1.1 of the PCI EPP Evaluation Vendor Questionnaire relating to response of the EPP to tamper- detection, for consistency.
TA1.1.4 The tester shall examine the response to Section A1.1 of the PCI EPP Evaluation Vendor Questionnaire relating to response of the EPP to tamper detection, for consistency.
Modified p. 5 → 7
TA1.1.2.3 The tester shall examine vendor-supplied documentation to determine if the EPP employs active or passive (i.e., removal of power) erasure. If the EPP employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the EPP and stopping erasure before it is effective. The tester may create an attack scenario, which may be performed in its entirety or in part to verify the theory.
TA1.1.5 The tester shall examine vendor-supplied documentation to determine if the EPP employs active or passive (i.e., removal of power) erasure. If the EPP employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the EPP and stopping erasure before it is effective. The tester may create an attack scenario, which may be performed in its entirety or in part to verify the theory.
Modified p. 5 → 9
TA1.1.2.1b The tester shall open the EPP to activate the tamper-detection mechanisms and then perform tests to support evidence that the keys and secret data have been erased. Tests that may be performed could include:
TA2.6 The tester shall open the EPP to activate the tamper-detection mechanisms, and then perform tests to support evidence that keys and secret data have been erased. Tests that may be performed could include attempting a transaction to determine if the transaction fails, using a special function of the EPP that allows a user to determine the status of secret data, or using special software to determine if secret data has been erased.
Removed p. 6
TA1.2.1.3 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.
Modified p. 6 → 7
TA1.1.3.1 The tester shall develop attack scenario(s) to disable or defeat the tamper- detection mechanisms and insert a PIN-disclosing bug or gain access to secret information, which costs less than $25,000 per EPP. The cost calculation shall be based on the scheme depicted in Appendix A. The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in …
TA1.1.6 The tester shall develop attack scenario(s) to disable or defeat the tamper-detection mechanisms and insert a PIN-disclosing bug or gain access to secret information, which requires an attack potential of <25 per EPP. The attack potential value shall be based on the scheme depicted in Appendix A.
Modified p. 6 → 8
DTR A1.2 Independent Security Mechanisms A1.2.1 Failure of a single security mechanism does not compromise EPP security. Protection against a threat is based on a combination of at least two independent security mechanisms.
TA1.2.1 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.
Modified p. 6 → 8
In general, techniques may include any combination of tamper detection or tamper evidence. Security mechanisms must not rely on insecure services or characteristics provided by the EPP such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods are not considered security mechanisms This requirement does not imply the need for redundant security mechanisms.
In general, techniques may include any combination of tamper detection or tamper evidence. Security mechanisms must not rely on insecure services or characteristics provided by the EPP such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods involving tamper evidence are not considered security mechanisms.
Modified p. 6 → 8
TA1.2.1.1 The tester shall examine the response to Section A1.2 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A1.2 of the PCI EPP Security Requirements manual for consistency relevant to DTR.A1.2.1. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise EPP security.
TA1.2.1 The tester shall examine the response to Section A1.2 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A1.2 of the PCI EPP Security Requirements manual for consistency relevant to DTR A1.2. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise EPP security.
Modified p. 6 → 8
TA1.2.1.2 The tester shall examine any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA1.2.1 The tester shall examine any additional relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Removed p. 7
A2.1.2 The tamper-detection mechanisms cause the automatic and immediate erasure of all secret information contained in the EPP.

Guidance “Immediate” is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1. Attack scenarios should consider keypad removal or replacement associated with vending machines or such like.

TA2.1.2.1 The tester shall activate the EPP tamper-detection mechanisms and then perform tests to support evidence that keys and secret data have been erased by the action. Tests that may be performed could include:
Modified p. 7 → 6
Guidance Objective of this section is to assess the EPP’s ability to protect clear-text PINs and other sensitive data. Attack scenarios must be in support of compromise of clear-text PINs and other sensitive data.
The objective of this section is to assess the EPP’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.1.
Modified p. 7 → 9
TA2.1.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings submitted by the vendor to verify that it supports the vendor responses.
TA2.2 The tester shall examine any relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 7 → 9
TA2.1.2.2 The tester shall examine the response to Section A2.1 of the PCI EPP Evaluation Vendor Questionnaire relating to the response of the EPP to tamper detection, for consistency.
TA2.1 The tester shall examine the response to Section A2 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A2 of PCI EPP Security Requirements for consistency relevant to A2.
Modified p. 7 → 9
TA2.1.2.3 The tester shall examine vendor-supplied documentation to determine if the EPP employs active or passive (i.e., removal of power) erasure. If the EPP employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the EPP and stopping erasure before it is effective. The tester may create an attack scenario which may be performed all or in part to verify the theory.
TA2.7 The tester shall examine vendor-supplied documentation to determine if the EPP employs active or passive (i.e., removal of power) erasure. If the EPP employs passive erasure, the tester shall verify that it occurs rapidly enough to prevent an attacker from opening the EPP and stopping erasure before it is effective. The tester may create an attack scenario which may be performed all or in part to verify the theory.
Modified p. 7 → 13
TA2.1.1.1 The tester shall visually inspect the tamper-detect mechanisms to verify the assertions provided by the vendor in response to Section A2.1 PCI EPP Evaluation Vendor Questionnaire.
TA6.4 The tester shall perform a sample transaction to verify the assertions provided by the vendor relating to protections against monitoring.
Removed p. 8
TA2.1.3.1 The tester shall develop a detailed attack scenario to disable or defeat the detection or erasure mechanism. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity.

TA2.1.3.2 The tester shall calculate the projected cost of disabling or defeating the tamper- detection mechanisms. The cost calculation shall be based on the scheme depicted in Appendix A.

TA2.1.3.3 The tester shall examine the assertions provided by the vendor in response to Section A2.1 of the PCI EPP Evaluation Vendor Questionnaire to determine whether or not they are consistent with the findings in TA2.1.3.1 and TA2.1.3.2. If an attack scenario can be developed that yields a calculated cost of less than US $25,000 per EPP, the vendor assertion cannot be verified.

DTR A2.2 Tamper Evidence A2.2.1 The implementation of the EPP is such that penetrating and then altering the EPP to disclose …
Removed p. 8
A2.2.2 The implementation of the EPP is such that penetrating and then altering the EPP to disclose future PINs (for example, inserting a PIN-disclosing bug or making PIN- disclosing functional modifications) damages the EPP to the extent that either it becomes inoperative or it has a high probability of detection before the EPP is placed (back) into operational use.

TA2.2.2.1 The tester shall attempt to develop attack scenarios to penetrate and alter the EPP to disclose future PINs without damaging the EPP to the extent that either it becomes inoperative or it has a high probability of detection before the EPP is placed back into operational use. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. If such an attack can be developed, this vendor assertion cannot be verified.
Modified p. 8 → 14
TA2.2.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA7.2 The tester shall examine any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
Removed p. 9
A2.3.2 The implementation of the EPP is such that penetrating and then altering the EPP to disclose future PINs (for example, inserting a PIN-disclosing bug or making PIN- disclosing functional modifications) requires that the EPP be removed from its normal location for at least ten hours, so that there is a high probability that the absence or absence and re-appearance of the EPP will be noted and reported before it is placed back into operational use.

TA2.3.2.1 The tester shall attempt to develop attack scenarios to penetrate and alter the EPP to disclose future PINs without requiring the removal of the EPP from its normal location for at least ten hours. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. If such an attack can be developed, this vendor assertion cannot be verified.
Modified p. 9 → 15
TA2.3.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA8.2 The tester shall examine any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.
Removed p. 10
TA2.4.2.2 The tester shall calculate the projected cost of disabling or defeating the tamper- detection mechanisms. The cost calculation shall be based on the scheme depicted in Appendix A.

TA2.4.2.1 The tester shall attempt to develop attack scenarios to penetrate and alter the EPP to disclose future PINs without damaging the EPP to the extent that either it becomes inoperative or it has a high probability of detection before the EPP is placed back into operational use. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. If such an attack can be developed, this vendor assertion cannot be verified.
Removed p. 10
A2.4.2 The implementation of the EPP is such that penetrating and then altering the EPP to disclose future PINs (for example, inserting a PIN-disclosing bug or making PIN- disclosing functional modifications) requires a per-EPP expenditure of at least US $25,000, which does not make the compromise cost-effective.

TA2.4.2.3 The tester shall examine the assertions provided by the vendor in response to Section A2.4 of the PCI EPP Evaluation Vendor Questionnaire to determine if they are consistent with the findings in TA2.4.2.1 & TA2.4.2.2. If an attack scenario can be developed that yields a calculated cost of less than US $25,000 per EPP, the vendor assertion cannot be verified.
Modified p. 10 → 11
TA2.4.1.2 The tester shall examine additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA4.2 The tester shall examine any additional relevant documentation, such as assembly drawings and functional specifications submitted by the vendor to verify that it supports the vendor responses.
Removed p. 11
A3.2 If the EPP permits access to internal areas (e.g., for service or maintenance), then it is not possible using this access area to insert a PIN-disclosing bug. Immediate access to sensitive information such as PIN or cryptographic data is either prevented by further means (e.g., by enclosing components with sensitive data into tamper- resistant/responsive enclosures), or it has a mechanism so that such access causes the immediate erasure of sensitive data TA3.2.1 The tester shall attempt to remove the access cover by disabling or defeating the tamper-detection mechanisms. To remove the cover the tester may open, pry, or otherwise disassemble the EPP at the cover seams and remove other plates, connectors, etc. to gain access to the tamper-detection mechanisms. Removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure. The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove …
Modified p. 11 → 9
TA3.1.3 The tester shall verify the existence and design of any mechanisms asserted by the vendor to protect any physical access ports and/or to prevent immediate access to sensitive information like PIN and cryptographic data. This will be accomplished by disassembling the device and examining the mechanisms.
TA2.3 The tester shall verify the existence and design of any mechanisms asserted by the vendor to protect any physical access ports and/or to prevent immediate access to sensitive information like PIN and cryptographic data. This will be accomplished by disassembling the device and examining the mechanisms.
Modified p. 11 → 9
TA3.2.2 The tester shall verify that attempts to remove the cover by removing fasteners, plates, connectors, etc. or by creating a gap between the covers or cover and housing does not allow access to probe critical security circuitry without triggering the tamper-detection mechanisms.
TA2.5 The tester shall verify that attempts to remove the cover by removing fasteners, plates, connectors, etc. or by creating a gap between the covers or cover and housing does not allow access to probe critical security circuitry without triggering the tamper-detection mechanisms.
Modified p. 11 → 13
TA3.1.1 The tester shall examine the vendor’s response to Section A3 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI EPP Security Requirements for consistency relevant to A3.1 TA3.1.2 The tester shall examine any relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
TA6.1 The tester shall examine the vendor’s response to Section A6 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A6 of the PCI EPP Security Requirements for consistency relevant to A6.
Removed p. 12
A4.2 The security of the EPP is not compromised by altering environmental conditions or operational conditions (for example subjecting the EPP to temperatures or operating voltages outside the stated operating ranges) Guidance Objective is not to replicate the vendor testing, but instead is to account for shortcomings within the vendor’s implementation TA4.2.1 The tester shall develop attack scenarios to compromise the EPP by altering environmental and or operational conditions.
Modified p. 12 → 10
Guidance The vendor must either provide substantive data to support the security of the product outside normal operating conditions, or show that the product uses sensors that will trigger a tamper response.
The vendor must either provide substantive data to support the security of the product outside normal operating conditions, or show that the product uses sensors that will trigger a tamper response.
Modified p. 12 → 10
TA4.1.1 The tester shall examine the response to Section A4 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI EPP Security Requirements Manual for consistency relevant to requirement A4. The vendor responses should clearly state that the security of the EPP is not compromised by altering environmental conditions or operational conditions.
TA3.1 The tester shall examine the response to Section A3 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI EPP Security Requirements manual for consistency relevant to Requirement A3. The vendor responses should clearly state that the security of the EPP is not compromised by altering environmental conditions or operational conditions.
Modified p. 12 → 10
TA4.1.2 The tester shall examine any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc. submitted by the vendor to verify that it supports vendor responses.
TA3.2 The tester shall examine any additional relevant documentation, such as schematics, data sheets, vendor test procedures and test reports, etc. submitted by the vendor to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions.
Modified p. 12 → 10
TA4.1.3 The tester shall verify that the vendor’s stated measures protect against the compromise of the EPP by altering either environmental conditions or operational conditions, and assess the adequateness of the vendor test procedures and reports.
TA3.3 The tester shall verify that the vendor’s stated measures protect against the compromise of the EPP by altering either environmental conditions or operational conditions, and assess the adequateness of the vendor test procedures and reports.
Removed p. 13
• What sensitive information and functions exist; and

• That sensitive information and functions dealing with sensitive information are protected from modification.

A5.2 Sensitive functions or information are only used in the protected area(s) of the EPP. Sensitive information and functions dealing with sensitive information are protected from modification without the expenditure of at least US $25,000 per EPP.
Modified p. 13 → 11
TA5.1.3 Verify the completeness of the information regarding sensitive information and functions presented by the vendor.
TA4.3 Verify the completeness of the information regarding sensitive information and functions presented by the vendor.
Modified p. 13 → 11
TA5.2.1 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms dealing with sensitive information and functions, using attack scenarios, which costs less than $25,000 per EPP. The cost calculation shall be based on the scheme depicted in Appendix A.
TA4.4 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms dealing with sensitive information and functions, using attack scenarios, with an attack potential of < 25 per EPP. The attack potential calculation shall be based on the scheme depicted in Appendix A.
Modified p. 13
• That sensitive functions or information are only used in the protected area(s) of the EPP; and
Monitoring is to be done outside the protected area of the EPP.
Modified p. 13
TA5.1.2 The tester shall examine any additional relevant documentation, such as assembly drawings and functional specifications submitted by the vendor, to verify that it supports the vendor responses.
TA6.2 The tester shall examine any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI EPP Evaluation Vendor Questionnaire.
Modified p. 13 → 14
TA5.1.1 The tester shall examine the response to Section A5 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI EPP Security Requirements manual for consistency relevant to Requirement A5. The vendor responses should clearly indicate:
TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI EPP Security Requirements for consistency relevant to A7.
Modified p. 14 → 12
TA6.1.2 The tester shall examine any additional information (i.e., specifications, schematics, block diagrams, etc.) that contains information on tone generation during PIN entry to determine if it supports the assertions made by the vendor.
TA5.2 The tester shall examine any additional information (i.e., specifications, schematics, block diagrams, etc.) that contains information on tone generation during PIN entry to determine if it supports the assertions made by the vendor.
Modified p. 14 → 12
TA6.1.3 The tester shall verify that any audible tones accompanying PIN entry are indistinguishable by listening to the tones while entering a PIN number.
TA5.3 The tester shall verify that any audible tones accompanying PIN entry are indistinguishable e.g., by listening to the tones while entering a PIN number or by otherwise analyzing or measuring the tone/tone generation circuitry. .
Modified p. 14 → 15
TA6.1.1 The tester shall examine the vendor’s response to Section A6 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A6 of the PCI EPP Security Requirements for consistency relevant to A6.1.
TA8.1 The tester shall examine the vendor’s response to Section A8 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A8 of the PCI EPP Security Requirements for consistency relevant to A8.
Removed p. 15
TA7.1.1 The tester shall examine the vendor’s response to Section A7 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI EPP Security Requirements for consistency relevant to A7.1.

TA7.1.2 The tester shall examine any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI EPP Evaluation Vendor Questionnaire.

TA7.1.4 The tester shall perform a sample transaction to verify the assertions provided by the vendor relating to protections against monitoring.

A7.2 There is no feasible way to determine any entered PIN digit by monitoring sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring, even with the cooperation of the terminal operator or sales clerk without the expenditure of at least US $25,000 per EPP to defeat or circumvent.

Guidance Monitoring is to be done outside the protected area of the EPP.

Monitoring …
Modified p. 15 → 13
Guidance For A7, “monitoring sound” refers to other audible sounds apart from the beep generated by the EPP when a key is pressed.
For A6 monitoring sound refers to other audible sounds apart from the beep generated by the EPP when a key is pressed.
Modified p. 15 → 13
TA7.1.3 The tester shall visually inspect the EPP to verify the assertions provided by the vendor in the PCI EPP Evaluation Vendor Questionnaire relating to protections against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring. This could include verifying that any components that provide protection are as stated by the vendor. .
TA6.3 The tester shall visually inspect the EPP to verify the assertions provided by the vendor in the PCI EPP Evaluation Vendor Questionnaire relating to protections against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring. This could include verifying that any components that provide protection are as stated by the vendor.
Modified p. 15 → 13
TA7.2.1 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 which costs less than $25,000 per EPP. The cost calculation shall be based on the scheme depicted in Appendix A.
TA6.5 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of sound, electro-magnetic emissions, power consumption or any other external characteristic available for monitoring, using attack scenarios which require an attack potential of <25 per EPP for identification and initial exploitation. The attack potential calculation shall be based on the scheme depicted in Appendix A.
Removed p. 16
TA8.1.1 The tester shall examine the vendor’s response to Section A8 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement A8 of the PCI EPP Security Requirements for consistency relevant to A8.1.

TA8.1.2 The tester shall examine any relevant documentation, such as assembly drawings, test data, etc., submitted by the vendor to verify that it supports the vendor responses.

A8.2 The cost of determining any PIN-security-related cryptographic key resident in the EPP, either by penetration of the EPP or by monitoring emanations from the EPP (including power fluctuations) exceeds US $35,000.

TA8.2.2 The tester shall calculate the projected cost of determining any PIN-security- related cryptographic key resident in the EPP by either by penetration or by monitoring emanations. The cost calculation shall be based on the scheme depicted in Appendix A.

TA8.2.3 The tester shall examine the assertions provided by the vendor in response to Section A8 of the PCI EPP …
Modified p. 16 → 14
Guidance The vendor may need to supply specific test software to the evaluation laboratory to enable rigorous DPA analysis to be performed.
The vendor may need to supply specific test software to the evaluation laboratory to enable rigorous side channel attack analysis to be performed.
Modified p. 16 → 14
TA8.2.1 The tester shall attempt to develop attack scenarios to determine any PIN- security-related cryptographic key resident in the EPP either by penetration or by monitoring emanations from the EPP. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity.
TA7.3 The tester shall attempt to develop attack scenarios to determine any PIN-security- related cryptographic key resident in the EPP either by penetration or by monitoring emanations from the EPP. The attack potential calculation shall be based on the scheme depicted in Appendix A. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. If an attack scenario can be developed that requires an attack potential of <35 …
Removed p. 17
TB1.1.4 The tester will verify that the EPP 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 EPP fails securely in the event of self-test failure.
Modified p. 17 → 16
TB1.1.1 The tester shall examine the vendor’s response to Section B1 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI EPP Security Requirements to verify that the EPP performs a self-test upon start up and at least once per day to check firmware and security mechanisms for signs of tampering, and whether the EPP is in a compromised state.
TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI EPP Security Requirements to verify that the EPP performs a self-test upon start-up and at least once per day to check firmware and security mechanisms for signs of tampering, and whether the EPP is in a compromised state.
Modified p. 17 → 16
TB1.1.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses.
TB1.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 17 → 16
TB1.1.3 The tester will verify that the EPP 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 EPP is in a compromised state. The tester will activate the self-test(s) and look for the result of the self-test(s) as shown by the EPP.
TB1.3 The tester will verify that the EPP 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 EPP is in a compromised state. The tester will activate the self-test(s) and look for the result of the self-test(s) as shown by the EPP.
Removed p. 18
B2.2 The EPP’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data which could result in the EPP outputting the clear text PIN or other sensitive information.
Modified p. 18 → 17
Guidance Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of the EPP. Vendors should provide software design rules and specifications to support answers.
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of the EPP.
Modified p. 18 → 17
TB2.1.1 The tester shall examine the vendor’s response to Section B2 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI EPP Security Requirements to verify that the EPP’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data.
TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI EPP Security Requirements to verify that the EPP’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data.
Modified p. 18 → 17
TB2.1.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the EPPs logical structure, the EPP interface specification, the software design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB2.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the EPP’s logical structure, the EPP interface specification, the software design rules and specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 18 → 17
TB2.1.3 The tester shall analyze the vendor’s measures that ensure, that the EPP’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data.
TB2.3 The tester shall analyze the vendor’s measures that ensure that the EPP’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified p. 18 → 17
TB2.2.1 The tester may perform tests needed to validate the device’s property. The evaluator should use his or her own judgment in determining appropriate tests. Test support shall be provided by the vendor as needed to access and use the interfaces under test.
TB2.4 The tester may perform tests needed to validate the device’s property. The evaluator should use his or her own judgment in determining appropriate tests. Test support shall be provided by the vendor as needed to access and use the interfaces under test.
Modified p. 19 → 18
The EPP must display or otherwise make available the revision number.
TB3.4 The tester will verify that the device displays or otherwise makes available the revision number.
Modified p. 19 → 18
TB3.1.1 The tester shall examine the response to Section B3 of the PCI EPP Evaluation Vendor Questionnaire relating to the firmware documentation and certification process, for consistency.
TB3.1 The tester shall examine the response to Section B3 of the PCI EPP Evaluation Vendor Questionnaire relating to the firmware documentation and certification process, for consistency.
Modified p. 19 → 18
TB3.1.2 The tester shall examine the support documentation submitted by the EPP vendor. The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.
TB3.2 The tester shall examine the support documentation submitted by the EPP vendor. The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.
Modified p. 19 → 18
TB3.1.3 The tester shall examine details provided by the vendor that the documented process explicitly addresses how testing/ auditing has been carried out to check for unauthorized and undocumented functions DTR B4 Remote Firmware Updates B4.1 If the EPP implements remote firmware updates, the software integrity is cryptographically authenticated by the device. If the authenticity of a firmware update is not confirmed, either the software update is rejected or all secret cryptographic keys are erased.
TB3.3 The tester shall examine details provided by the vendor that the documented process explicitly addresses how testing/ auditing has been carried out to check for unauthorized and undocumented functions.
Modified p. 19
TB4.1.1 The tester shall examine the response to Section B4 of the PCI EPP Evaluation Vendor Questionnaire relating to the authentication procedures for remote firmware updates, for consistency.
TB4.1 The tester shall examine the response to Section B4 of the PCI EPP Evaluation Vendor Questionnaire relating to the authentication procedures for firmware updates, for consistency.
Modified p. 19
TB4.1.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to remote firmware updates to determine if it supports the assertions made by the vendor.
TB4.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine if it supports the assertions made by the vendor.
Modified p. 19
TB4.1.3 The tester shall verify that the EPP cryptographically authenticates the software integrity. This will be accomplished for example by performing a simulated firmware update.
TB4.3 The tester shall verify that the EPP cryptographically authenticates the firmware integrity. This will be accomplished, for example, by performing a simulated firmware update.
Modified p. 19
TB4.1.4 The tester shall verify that the EPP rejects unauthorized Firmware. This will be accomplished for example by performing a simulated firmware update with inadequate or modified authentication information.
TB4.4 The tester shall verify that the EPP rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
Removed p. 20
B5.2 The EPP never outputs information to another component (e.g., a display or a device controller) allowing the differentiation of the PIN digits entered.

DTR B6 Clearing of Internal Buffers B6.1 Sensitive information shall not be present any longer or used more often than strictly necessary.

TB6.1.3 The tester will verify that the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included. Passwords, plaintext cryptographic keys outside of the crypto-processor and PIN values are considered sensitive data.
Modified p. 20
TB5.1.2 The tester shall examine any relevant documentation, such as an API user guide, submitted by the vendor to verify that supports the vendor responses.
TB5.2 The tester shall examine any relevant documentation, such as an API user guide, submitted by the vendor to verify that supports the vendor responses.
Modified p. 20
TB5.2.1 The tester shall perform a test in which a PIN number is entered to verify that the EPP does not output any digits of the PIN value. The tester shall note and report any characters, signals or tones that are outputted.
TB5.3 The tester shall perform a transaction in which a PIN number is entered to verify that the EPP does not output any digits of the PIN value. The tester shall note and report any characters, signals, or tones that are outputted.
Modified p. 20
TB5.2.2 If the EPP does not directly control the display, it must supply a suitable signal to indicate, that a numeric key has been pressed and the value is stored inside the EPP. The tester shall examine the response to Section B5 of the PCI EPP Evaluation Vendor Questionnaire to determine the kind of signaling and to verify that the signal information is not related to the digit entered.
TB5.4 If the EPP does not directly control the display, it must supply a suitable signal to indicate that a numeric key has been pressed and the value is stored inside the EPP. The tester shall examine the response to Section B5 of the PCI EPP Evaluation Vendor Questionnaire to determine the kind of signaling and to verify that the signal information is not related to the digit entered.
Modified p. 20 → 21
Guidance Vendor shall provide documentation of test results for inspections of internal buffers.
The vendor shall provide documentation of test results for inspections of internal buffers.
Modified p. 20 → 21
TB6.1.1 The tester shall examine the vendor’s response to Section B6 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI EPP Security Requirements to verify that sensitive information shall not be present any longer or used more often than strictly necessary.
TB6.1 The tester shall examine the vendor’s response to Section B6 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI EPP Security Requirements to verify:
Modified p. 20 → 21
TB6.1.2 The tester shall examine any relevant documentation, including vendor test results for inspections of internal buffers submitted by the vendor to verify that it supports the vendor responses.
TB6.2 The tester shall examine any relevant documentation, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified p. 20 → 22
TB5.1.1 The tester shall examine the vendor’s response to Section B5 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI EPP Security Requirements for consistency relevant to B5.1.
TB7.1 The tester shall examine the vendor’s response to Section B7 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI EPP Security Requirements for consistency relevant to B7.
Removed p. 21
DTR B7 Protection of Sensitive Services B7.1 Access to sensitive services requires authentication. Sensitive services provide access to the underlying sensitive functions. Sensitive functions are those functions that process sensitive data such as Cryptographic Keys, PINs, and Passwords. Entering or exiting sensitive services shall not reveal or otherwise affect sensitive information.

TB7.1.3 The tester shall verify from vendor documentation that the vendor has identified all sensitive services, data and secure modes. Sensitive functions are those functions that process sensitive data such as Cryptographic Keys, Pins and Passwords.
Modified p. 21
TB6.2.3 The tester will verify that all data that is automatically cleared when either the transaction is completed or the EPP has timed-out waiting for the response from the cardholder or merchant. The tester will determine the appropriate test actions to be taken. For instance, by performing a partial simulated transaction to verify the behavior at time-out.
TB6.4 The tester will verify that all data is automatically cleared when either the transaction is completed or the EPP has timed out waiting for the response from the cardholder or merchant. The tester will determine the appropriate test actions to be taken. For instance, by performing a partial simulated transaction to verify the behavior at time- out.
Modified p. 21 → 22
Guidance Authentication shall be considered as 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 be considered as 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.
Modified p. 21 → 22
TB7.1.2 The tester shall examine any relevant documentation (such as an API user guide) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services.
TB7.2 The tester shall examine 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. 21 → 22
TB7.1.4 The tester shall verify from vendor documentation and from functional testing that sensitive services require authentication.
TB7.4 The tester shall verify from vendor documentation and from functional testing that sensitive services require authentication.
Modified p. 21 → 22
TB7.1.5 The tester shall verify from vendor documentation and from functional testing that entering and exiting sensitive services does not reveal or otherwise affect sensitive information.
TB7.5 The tester shall verify from vendor documentation and from functional testing that entering and exiting sensitive services does not reveal or otherwise affect sensitive information.
Modified p. 21 → 23
TB6.2.1 The tester shall examine the vendor’s response to Section B6 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI EPP Security Requirements to verify that the EPP automatically clears its internal buffers when either the transaction is completed or the EPP has timed- out waiting for the response from the cardholder or merchant.
TB8.1 The tester shall examine the vendor’s response to Section B8 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI EPP Security Requirements for consistency relevant to B8.
Modified p. 21 → 23
TB6.2.2 The tester shall examine any relevant documentation, such as the user guide, the software specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB8.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses.
Modified p. 21 → 24
TB7.1.1 The tester shall examine the vendor’s response to Section B7 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI EPP Security Requirements for consistency relevant to B7.1.
TB9.1 The tester shall examine the vendor’s response to Section B9 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI EPP Security Requirements for consistency relevant to B9.
Removed p. 22
• Data inputs cannot be discerned from any displayed characters.

• Data inputs cannot be discerned by monitoring audible or electro-magnetic emissions.

• Sensitive data is cleared from internal buffers upon exiting the sensitive mode.

• Entering data while accessing sensitive services.

TB7.2.5 If mode transitions require input by a separate interface device, such as a key loader, the tester will verify that the physical and logical security level of the device is equal to or greater than that of the EPP. The testing shall include:

• Entering data while accessing sensitive services,

• Document review, and

• Physical examination of the interface device.
Modified p. 22 → 20
TB7.2.1 The tester shall examine the vendor’s response to Section B7 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI EPP Security Requirements for consistency relevant to B7.2.
TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI EPP Security Requirements for consistency relevant to B5.1.
Modified p. 22
TB7.2.3 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.
TB7.6 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified p. 22
TB7.2.4 If access to sensitive services requires input by the keypad, the tester shall verify that the protections for PIN data, such as the following, are also afforded to data entered while accessing sensitive services:
TB7.7 If access to sensitive services requires input by the keypad, the tester shall verify that the protections for PIN data, such as the following, are also afforded to data entered while accessing sensitive services:
Modified p. 22 → 26
TB7.2.2 The tester shall examine any relevant documentation (such as an API user guide) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services.
TB11.2 The tester shall examine any relevant documentation such as a user guide, submitted by the vendor to verify that it supports vendor responses.
Removed p. 23
B8.2 To minimize the risks from unauthorized use of sensitive services, limits on the number of actions that can be performed and a time limit shall be imposed, after which the EPP is forced to return to its normal mode.
Modified p. 23
TB8.1.3 The tester shall examine the rationale provided by the vendor in Section B8 of the PCI EPP Evaluation Vendor Questionnaire to verify the following:
TB8.3 The tester shall examine the rationale provided by the vendor in Section B8 of the PCI EPP Evaluation Vendor Questionnaire to verify the following:
Modified p. 23
The vendor has provided a rationale for the value chosen as a limit on the number of actions and the time limits imposed.
The vendor has provided a rationale for the value chosen as a limit on the number of actions and the time limits imposed.
Modified p. 23
The vendor has provided a rationale as to how the limits minimize the risks from unauthorized use of sensitive services.
The vendor has provided a rationale as to how the limits minimize the risks from unauthorized use of sensitive services.
Modified p. 23
TB8.2.1 The tester shall verify the limits placed on the number of actions by causing the EPP to access sensitive services and attempting to exceed the limit. Once the limit is exceeded the tester will verify that the EPP has returned to its normal mode.
TB8.4 The tester shall verify the limits placed on the number of actions by causing the EPP to access sensitive services and attempting to exceed the limit. Once the limit is exceeded the tester will verify that the EPP has returned to its normal mode.
Modified p. 23
TB8.2.2 The tester shall verify that a time limit is imposed such that after one minute of inactivity while accessing sensitive services, the EPP returns to its normal state. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded.
TB8.5 The tester shall verify that a time limit is imposed such that after one minute of inactivity while accessing sensitive services, the EPP returns to its normal state. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded.
Modified p. 23
TB8.2.3 The tester shall verify that a time limit is imposed such that fifteen (15) minutes after accessing sensitive services, the EPP returns to its normal mode. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded. To prevent the EPP from reaching a limit of inactivity, sensitive functions will be used throughout the fifteen minutes.
TB8.6 The tester shall verify that a time limit is imposed such that fifteen (15) minutes after accessing sensitive services, the EPP returns to its normal mode. This will be accomplished by attempting to use sensitive functions after the time limit has been exceeded. To prevent the EPP from reaching a limit of inactivity, sensitive functions will be used throughout the fifteen minutes.
Modified p. 23 → 26
TB8.1.1 The tester shall examine the vendor’s response to Section B8 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI EPP Security Requirements for consistency relevant to B8.1.
TB11.1 The tester shall examine the response to Section B11 of the PCI EPP Evaluation Vendor Questionnaire relating to the method of key management in use in the EPP, for consistency.
Modified p. 23 → 32
TB8.1.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses.
TB13.2 The tester shall examine any additional documentation such as the API Programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Removed p. 24
Applicable whenever random numbers are generated by the EPP in connection with security over sensitive data.

DTR B10 PIN Encryption Immediately After Entry B10.1 The PIN is encrypted within the EPP immediately after PIN entry is complete and has been signified as such by the cardholder. The clear text PIN must be immediately erased after encryption is complete.

TB10.1.2 The tester shall examine any additional documentation (i.e., the interface specification, the functional specification, the software specification, the software implementation, etc.) that contains information on the PIN encryption to determine if it supports the assertions made by the vendor.
Modified p. 24 → 21
Guidance “Immediate” is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1. The EPP may support the encipherment of the PIN multiple times as part of a transaction series, however, the PIN shall only be enciphered with the same PIN encipherment key, and not different keys. See B6 regarding clearing of internal buffers.
The EPP may support the encipherment of the PIN multiple times as part of a transaction series; however, the PIN shall only be enciphered with the same PIN-encipherment key, and not different keys.
Modified p. 24
TB9.1.2 The tester shall compare the vendor supplied, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor 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. 24
TB9.1.3 The tester shall verify test information provided by the vendor to assess whether the random numbers are sufficiently unpredictable. The tester shall use a suitable test method (for example, those listed in NIST PUB 800-22). See Appendix B.
TB9.3 The tester shall verify test information provided by the vendor to assess whether the random numbers are sufficiently unpredictable. The tester shall use a suitable test method (for example, those listed in NIST PUB 800-22). See Appendix B.
Modified p. 24 → 32
TB9.1.1 The tester shall examine the vendor’s response to Section B9 of the PCI EPP Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI EPP Security Requirements for consistency relevant to B9.1.
TB13.1 The tester shall examine the response to Section B13 of the PCI EPP Evaluation Vendor Questionnaire relating to encryption and decryption of arbitrary data, for consistency.
Modified p. 24 → 33
TB10.1.1 The tester shall examine the response to Section B10 of the PCI EPP Evaluation Vendor Questionnaire relating to the immediate encryption of PIN data, for consistency.
TB14.2 The tester shall examine the response to Section B14 of the PCI EPP Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
Modified p. 25
 Use of a unique key per transaction technique. (Prevents the attack.)  Preventing the entry of the PIN through other than the keypad, and limiting the rate at which the EPP will encrypt PINs to the average (for example, over 120 transactions) of one per 30 seconds. (Deters the attack.) TB11.1.1 The tester shall examine the response to Section B11 of the PCI EPP Evaluation Vendor Questionnaire relating to characteristics that prevent or significantly deter the use of a …
 Use of a unique key per transaction technique. (Prevents the attack.)  Preventing the entry of the PIN through other than the keypad, and limiting the rate at which the EPP will encrypt PINs to the average (for example, over 120 transactions) of one per 30 seconds. (Deters the attack.) The device is exclusively used for offline PIN and the ICC reader is integrated into the EPP.
Modified p. 25
TB11.1.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 PIN determination to determine if it supports the assertions made by the vendor.
TB10.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 PIN determination to determine if it supports the assertions made by the vendor.
Modified p. 25
TB11.1.3 The tester shall perform functional testing to verify the EPP characteristics regarding B11.
TB10.3 The tester shall perform functional testing to verify the EPP characteristics regarding B10.
Removed p. 26
• Master/Session B12.2 The PIN-encryption technique implemented in the EPP is a technique included in ISO 9564.
Modified p. 26 → 31
TB12.1.1 The tester shall examine the response to Section B12 of the PCI EPP Evaluation Vendor Questionnaire relating to the TDES PIN encryption implementation in the EPP, for consistency and compliance with ISO 9564.
TB12.1 The tester shall examine the response to Section B12 of the PCI EPP Evaluation Vendor Questionnaire relating to the TDES PIN-encryption implementation in the EPP, for consistency and compliance with ISO 9564.
Modified p. 26 → 31
TB12.1.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to the PIN-encryption technique implemented in the EPP.
TB12.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to the PIN- encryption technique implemented in the EPP.
Modified p. 26 → 31
Note: The EPP must support at least one of the following key management techniques using TDES as described in ANSI X9.24 and ANSI X9.52:
Note: The EPP must support at least one of the following key-management techniques using TDES as described in ANSI X9.24 and ANSI X9.52:
Modified p. 26 → 31
TB12.2.1 The tester shall perform a transaction with a known encryption key. The tester shall use this key to create an encrypted PIN block with a test system, using the Primary Account Number, and PIN with the format (the format must be either ISO format 0, 1 or 3) specified by the vendor. The corresponding encrypted PIN block shall be generated by the EPP with a simulated transaction. If both encrypted PIN blocks are identical, the EPP is using the …
TB12.3 The tester shall perform a transaction with a known encryption key. The tester shall use this key to create an encrypted PIN block with a test system, using the Primary Account Number, and PIN with the format (the format must be either ISO format 0, 1, or 3, specified by the vendor. The corresponding encrypted PIN block shall be generated by the EPP with a simulated transaction. If both encrypted PIN blocks are identical, the EPP is using the …
Removed p. 27
TB13.1.4 The tester shall verify that the EPP will not allow the entry of a single component plaintext key. If possible attempt to load a plaintext single component key either manually or electronically (does not include initial keys for DUKPT). The vendor may alternately provide user documentation detailing the management of cryptographic keys following the principles of dual control and split knowledge and implementing the use of a secure cryptographic device for management of these keys. That is, the process exists upstream of the EPP.

Examples of appropriate algorithms and key sizes are:

Algorithm DES RSA Elliptic Curve DSA Min Key size 112 1024 160 1024/160 DES refers to non-parity bits, The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA …
Modified p. 27 → 26
TB13.1.3 The tester shall determine from vendor documentation the key management technique used for Firmware and Application updates. Symmetric key techniques must include the use of Unique Key per Device.
TB11.3 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of Unique Key(s) per Device.
Modified p. 27 → 28
Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 1024-bits minimum for RSA).
Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 1024-bits minimum for RSA).
Modified p. 27 → 28
Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified p. 27 → 28
Provide for mutual device authentication for both the host and the EPP, including assurance to the host that the EPP actually has (or actually can) compute the session key and that no other entity other than the EPP specifically identified can possibly compute the session key.
Provide for mutual device authentication for both the host and the EPP, including assurance to the host that the EPP actually has (or actually can) compute the session key and that no other entity other than the EPP specifically identified can possibly compute the session key.
Modified p. 27 → 34
TB13.1.1 The tester shall examine the response to Section B13 of the PCI EPP Evaluation Vendor Questionnaire relating to the method of key management in use in the EPP, for consistency.
TB15.1 The tester shall examine the response to Section C1 of the PCI EPP Evaluation Vendor Questionnaire relating to multiple keys and unauthorized key replacement and key misuse, for consistency.
Modified p. 27 → 34
TB13.1.2 The tester shall examine any relevant documentation, such as a user guide, submitted by the vendor to verify that it supports vendor responses.
TB15.2 The tester shall examine any additional documentation such as a user’s manual or the API Programmer’s guide submitted by the vendor to verify that it supports vendor responses.
Removed p. 28
Guidance PIN-encryption keys shall only be used to encrypt PIN data. Key-encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key- encrypting keys shall never be used to encrypt PIN data.

TB14.1.2 The tester shall examine any additional documentation such as the API Programmer’s guide, submitted by the vendor to verify that it supports vendor responses.

DTR B15 Key Substitution B15.1 If the EPP can hold multiple encryption keys and the key to be used to encrypt the PIN can be externally selected, then the EPP prohibits unauthorized key replacement and key misuse.

TB15.1.2 The tester shall examine any additional documentation, such as a user’s manual or the API Programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified p. 28 → 32
TB14.1.3 The tester shall verify the following:
TB13.3 The tester shall verify the following:
Modified p. 28 → 32
PIN-encryption keys are only used to encrypt PIN data.
PIN-encryption keys are only used to encrypt PIN data.
Modified p. 28 → 32
Key-encrypting keys are only used to encrypt keys.
Key-encrypting keys are only used to encrypt keys.
Modified p. 28 → 32
PIN keys shall never be used to encrypt keys.
PIN keys are never used to encrypt keys.
Modified p. 28 → 32
Key-encrypting keys shall never be used to encrypt PIN data.
Key-encrypting keys are never used to encrypt PIN data.
Modified p. 28 → 33
TB14.1.1 The tester shall examine the response to Section B14 of the PCI EPP Evaluation Vendor Questionnaire relating to encryption and decryption of arbitrary data, for consistency.
TB14.3 The tester shall examine the response to Section B14 of the PCI EPP Evaluation Vendor Questionnaire relating to the transfer of a key from a high-security component to a lower-security component, for consistency.
Modified p. 28 → 33
TB15.1.1 The tester shall examine the response to Section B15 of the PCI EPP Evaluation Vendor Questionnaire relating to multiple keys and unauthorized key replacement and key misuse, for consistency.
TB14.1 The tester shall examine the response to Section B14 of the PCI EPP Evaluation Vendor Questionnaire relating to the output of clear-text keys and the protection of PINs for consistency. The clear-text PIN must never exist in an unprotected environment.
Removed p. 29
B16.2 There is no mechanism in the EPP that would allow the encryption of a key or PIN under a key that might itself be disclosed.

TB16.2.1 The tester shall examine the response to Section B16 of the PCI EPP Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.

TB16.2.2 The tester shall examine any additional documentation (i.e., API Programmer’s guide, specifications, block diagrams, etc.) that contains information that relates to encryption of a key or PIN to determine if it supports the assertions made by the vendor.

B16.3 There is no mechanism in the EPP that would allow the transfer of a clear-text key from a component of high security into a component of lesser security.

TB16.3.1 The tester shall examine the response to Section B16 of the PCI EPP Evaluation Vendor Questionnaire relating to the transfer of a key from …
Modified p. 29 → 25
TB16.1.1 The tester shall examine the response to Section B16 of the PCI EPP Evaluation Vendor Questionnaire relating to the output of clear-text keys, for consistency.
TB10.1 The tester shall examine the response to Section B10 of the PCI EPP Evaluation Vendor Questionnaire relating to characteristics that prevent or significantly deter the use of a stolen device for exhaustive PIN determination.
Modified p. 29 → 33
TB16.1.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 outputting of clear-text keys to determine if it supports the assertions made by the vendor.
TB14.4 The tester shall examine any additional documentation (i.e., API Programmer’s guide, specifications, block diagrams, etc.) that contains information that relates to any of the aforementioned to determine if it supports the assertions made by the vendor.
Modified p. 30 → 35
Identification and exploitation For an attacker wanting to exploit a vulnerability the vulnerability must first be identified. This may appear to be a trivial separation, but it is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert and a simple attack method published on the Internet. Compare this to a vulnerability that is well known but requires enormous expenditure of time and resources to exploit. Of course factors such …
Identification and Exploitation For an attacker wanting to exploit a vulnerability, the vulnerability must first be identified. This may appear to be a trivial separation, but it is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert, and a simple attack method published on the Internet. Compare this to a vulnerability that is well known but requires enormous expenditure of time and resources to exploit. Of course, factors such …
Modified p. 30 → 35
Factors to be considered The following cost factors should be considered for the analysis of the attack costs required to exploit a vulnerability:
Factors to be Considered The following factors should be considered for the analysis of the attack potentials required to exploit vulnerability:
Modified p. 30 → 35
1. Attack time labor costs for the various levels of expertise;
a) Attack time for the various levels of expertise;
Modified p. 30 → 35
1. Attack time labor costs for the various levels of expertise;
a) Attack time for the various levels of expertise;
Modified p. 30 → 35
2. Costs to acquire the required knowledge of the EPP design and operation;
b) Potential to acquire the required knowledge of the EPP’s design and operation;
Modified p. 30 → 35
2. Costs to acquire the required knowledge of the EPP design and operation;
b) Potential to acquire the required knowledge of the EPP’s design and operation;
Modified p. 30 → 35
3. Cost for the access to the EPP;
c) Potential for the access to the EPP;
Modified p. 30 → 35
3. Cost for the access to the EPP;
c) Potential for the access to the EPP;
Modified p. 30 → 35
4. Equipment costs like instruments, components, IT hardware, software required for the analysis;
d) Equipment required like instruments, components, IT hardware, software required for the
Modified p. 30 → 35
4. Equipment costs like instruments, components, IT hardware, software required for the analysis;
d) Equipment required like instruments, components, IT hardware, software required for the
Modified p. 30 → 35
5. Costs of EPP specific spare components.
e) EPP specific spare components.
Modified p. 30 → 35
5. Costs of EPP-specific spare components.
e) POS EPP specific spare components.
Removed p. 31
a) No information about the EPP, other than its general purpose;

b) Public information concerning the EPP (e.g., as gained from user guides);
Modified p. 31 → 36
Knowledge of the EPP costs refers to obtaining specific expertise in relation to the EPP. This is different from generic expertise but not unrelated to it. Identified levels are as follows:
Knowledge of the EPP refers to obtaining specific expertise in relation to the POS EPP. This is different from generic expertise but not unrelated to it. Identified levels are as follows:
Modified p. 31 → 36
c) Sensitive information about the EPP (e.g., knowledge of internal design, which may have to be obtained by ‘social engineering’ or exhaustive reverse engineering).
c) Sensitive information about the EPP (e.g., knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
Removed p. 32
Spare part costs refer to components required to hide the signs of an attack or to otherwise replace components that have been broken during an attack, like a case part, a display or a printer.

Specialist expertise and knowledge of the EPP are concerned with the information required for persons to be able to attack an EPP. There is an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this 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 …
Modified p. 32 → 37
a) Standard equipment is equipment that is readily available to the attacker, either for the identification of a vulnerability or for an attack. This equipment can be readily obtained, e.g., at a nearby store or downloaded from the Internet. The Equipment might consist of simple attack scripts, personal computers, card readers, pattern generators, simple optical microscopes, power supplies or simple mechanical tools.
a) Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•e.g., at a nearby store or downloaded from the Internet. The equipment might consist of simple attack scripts, personal computers, card readers, pattern generators, simple optical microscopes, power supplies, or simple mechanical tools.
Modified p. 32 → 37
c) Bespoke equipment is not readily available to the public as it might need to be specially produced (e.g., very sophisticated software) or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Alternatively the equipment may be very expensive (e.g., Focused Ion Beam, Scanning Electron Microscope, and Abrasive Laser Equipment). Bespoke Equipment, which can be rented, might have to be treated as specialized equipment.
c) Bespoke equipment is not readily available to the public as it might need to be specially produced (e.g., very sophisticated software) or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Alternatively, the equipment may be very expensive (e.g., Focused Ion Beam, Scanning Electron Microscope, and Abrasive Laser Equipment). Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered …
Modified p. 32 → 38
a) Standard parts are readily available to the attacker, either by purchasing it from a supply store or by re-using parts from a mechanical sample of the same device.
a) Standard parts are readily available to the attacker, either by purchasing them from a supply store or by re-using parts from a mechanical sample of the same device.
Removed p. 34
4. The sensitive data is collected from the EPP We assume, that more than one sample of the device is needed for the identification phase and the exploitation phase of the attack. The skill required is proficient skill. The same equipment is used and required at identification and exploitation time. The following table is references to the attack phases.
Modified p. 34 → 40
First attack cost example The attack aims to insert a PIN-disclosing bug into an EPP. The bug is placed at a position in the device, where the PIN is handled in clear, for instance at the keypad or at the ICC reader interface. It is assumed that such an attack is possible. A generic attack consists of the following steps:
First Attack Example The attack aims to insert a PIN-disclosing bug into an EPP. The bug is placed at a position in the device where the PIN is handled in clear, for instance at the keypad or at the ICC reader interface. It is assumed that such an attack is possible. A generic attack consists of the following steps:
Modified p. 34 → 40
1. Reverse-engineer the device and develop the attack models. This step requires professional knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The modules will break during that phase. It is assumed, that the device is protected by tamper-response circuits, which prevent undetected opening of the device, but the point of interest are not covered by a tamper-responsive envelope.
1. Reverse-engineer the device and develop the attack models. This step requires professional knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The modules will break during that phase. It is assumed that the device is protected by tamper-response circuits, which prevent undetected opening of the device, but the points of interest are not covered by a tamper-responsive envelope.
Modified p. 34 → 40
3. A PIN-disclosing bug is to be developed and tested (Identification phase) or placed into the EPP (exploitation phase).
3. A PIN-disclosing bug is placed into the EPP (Exploitation Phase).
Removed p. 35
Table 2: Attack Costs for Inserting a PIN-Disclosing Bug Identifying Exploiting 1a Reverse-engineering 40 hours / proficient skill at the identification phase. Cost factor Elapsed time * Expertise 1b Access to target, 1 mechanical sample and 1 functional sample 2 Modifying EPP Elapsed time, 80 hours at identifying time, 8 hours at exploitation time / Proficient skill Cost factor Elapsed time * Expertise 2 Access to target, functional sample with working key 2 Sensitive knowledge of the EPP, since reverse engineering is assumed to be required. During exploitation time, no further knowledge is required 2 / 3 Specialized equipment 3000 4000 3 Development/attachment of PIN-disclosing bug, 40 hours at identification time, 8 hours at exploitation time, proficient skill Cost factor Elapsed time * Expertise 3 Camouflage of the modification using spare parts from a mechanical sample 4 Collecting the sensitive data from the EPP. 4 hours at identification and exploitation …
Modified p. 35 → 41
The attack aims at the determination of a DES key used for encryption at the device using differential power analysis (DPA). It is assumed, that  A function of the EPP is used which requires to a PIN to be entered for every execution of the cryptographic action with the key under attack,  The data used for DPA can be acquired at an external interface of the EPP, e.g., the EPP has not further to be physically attacked to …
 A function of the EPP is used which requires a PIN to be entered for every execution of the cryptographic action with the key under attack;  The data used for DPA can be acquired at an external interface of the EPP, e.g., the EPP need not be further physically attacked to get the required test data; and that  The EPP does not have effective countermeasures against DPA.
Removed p. 36
Table 3: Attack Costs Example for DPA Analysis Identifying Exploiting 1 Reverse-engineering of the EPP operation mode 40 hours/ Proficient skill 2 Develop Attack set-up, 160 hours/ Proficient skill 4800 0 3 Perform measurement, 166/3 hours identifying, 166/3 hours exploitation 3 Access to target, functional sample at identification time, functional sample with working keys at exploitation time 2 and 3 Sensitive knowledge of target at exploitation time, public knowledge at identification time 2 Bespoke equipment at identification time, which is re-used in step 3 3 Specialized equipment at exploitation time 0 4000 4 Analysis of the data, 160 hours at exploitation time, 40 hours at identification time Attack Costs per Phase 25500 10900 Total Attack Costs 36400 As can be seen from the table, the attack costs are close to the margin of US $35,000 for the attack model. If the PIN is:

a) Entered manually in the attack, or b) …
Modified p. 36 → 41
2. Develop the attack set-up including the control to run the EPP in a automated way. Since a large number of PIN entries is required, which can hardly be performed manually, a special mechanics has to be developed which performs the PIN entries. This is bespoke equipment, developed specially for this attack, which will be reused at Identification time.
2. Develop the attack set-up including the control to run the EPP in an automated way. Since a large number of PIN entries are required, which can hardly be performed manually, special mechanics must be developed to perform the PIN entries. This is bespoke equipment, developed specially for this attack, which will be reused at Identification time.
Modified p. 36 → 41
3. Get an EPP and perform the measurement. We expect, that at least 20,000 PIN entry steps and the following encryption have to be observed. In the identification phase, this may have to be repeated several times. Due to the exhaustive PIN search countermeasure, 20,000 PIN entries need at least 7 days. Since such an amount of transactions cannot be performed in a real live environment, it must be possible to run the device off-line with an simulated host.
3. Get an EPP and perform the measurement. We expect that at least 20,000 PIN entry steps and the following encryption have to be observed. In the identification phase, this may have to be repeated several times. Due to the exhaustive PIN search countermeasure, 20,000 PIN entries need at least 7 days. Since such an amount of transactions cannot be performed in a real live environment, it must be possible to run the device off-line with a simulated host.
Modified p. 36 → 41
The attack costs are estimated by the following table:
The attack potentials are estimated within the following table:
Removed p. 37
In order to support these settings, the tester should request and obtain an initial sample of 230 bits from the vendor.

The Lempel-Ziv test should not be run. [0] The SP800-22 document (section 4.2) requires that the results be interpreted as a "pass" if it passes all of the executed tests using both the "Proportion of Sequences Passing a Test" and the "Uniform Distribution of P-Values" interpretation approaches. The SP800-22 document further requires that if the results are inconclusive (e.g., if a small number of the tests fail, but only marginally) the tester should acquire additional data from the vendor and continue testing in order to determine if the original failure was the result of a statistical anomaly.
Removed p. 38
[2] The number of bit sequences (sample size) must be 1,000 or greater in order for the "Proportion of Sequences Passing a Test" result to be meaningful. (See SP800-22 section 4.2.1 and 4.3 f). This value will be 1,073 for the first test, but if further testing is required, this parameter will be larger.
Modified p. 38 → 43
[1] n must be selected to be consistent with the requirements all of the tests to be run. The Overlapping Template Matching Test, Linear Complexity Test, Random Excursions Test, and Random Excursions Variant Test all require n to be greater than or equal to 106 in order to produce meaningful results. The Non-Overlapping Template Matching Test and the Lempel-Ziv Compression test require n to equal 106. (See SP800-22 sections 2.7.7, 2.8.7, 2.10.7, 2.11.7, 2.15.7, and 2.16.7) The Lempel-Ziv code in …
[1] n must be selected to be consistent with the requirements all of the tests to be run. The Overlapping Templates, Linear Complexity, Random Excursions, and Random Excursions Variant tests all require n to be greater than or equal to 106 in order to produce meaningful results. The Non-Overlapping Templates test requires n to equal 106. (See SP800-22 Sections 2.7.7, 2.8.7, 2.10.7, 2.11.7, 2.15.7, and 2.16.7) [2] The number of bit sequences (sample size) must be 1,000 or greater in …
Modified p. 38 → 43
[3] For the Frequency Test within a Block, if n=106, the test block size should be set between 104 and 106. (See SP800-22 section 2.2.7) [4] The two template tests (Non-Overlapping Template Test and Overlapping Template Test) both require selection of a template length of 9 or 10 in order to produce meaningful results. (See SP800- 22 section 2.7.7 and 2.8.7) [5] Maurer's Universal Statistical Test block length (L) and initialization steps (Q) must be consistent with the table in …
[3] For the Block Frequency Test, if n=106, the test block size should be set between 104 and 106. (See SP800-22 Section 2.2.7.) [4] The two template tests (Non-Overlapping and Overlapping tests) both require selection of a template length of 9 or 10 in order to produce meaningful results. (See SP800-22 Sections 2.7.7 and 2.8.7.) [5] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP800-22 Section 2.9.7. For n=106, the only …
Modified p. 38 → 43
[6] SP800-22 section 2.13.7 requires the block length to be less than 2 log 2 n ! " # $ % , however the sts tool warns if the block size is greater than 2 log 5 n ! " # $ % (which is consistent with the information in section 4.3 f). Other analysis ([Hill 2004]) has shown that for n=1,000,000 setting the block length to 8 is more reasonable, as it is large enough to be meaningful while …
[6] For the Approximate Entropy (ApEn) test, SP800-22 Section 2.13.7 requires the block length to be less than 2 log 2 n ! " # $ % , however the sts tool warns if the block size is greater than 2 log 5 n ! " # $ % (which is consistent with the information in Section 4.3 f). Other analysis [Hill 2004] has shown that for n=1,000,000 values block lengths greater than 8 can cause failures more often than …
Modified p. 38 → 43
(See SP800-22 section 2.12.7) [8] The Linear Complexity block length is required to be set to between 500 and 5,000, inclusive. (See SP800-22 section 2.11.7) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST SP800-22, revisions dated May 15, 2001.
(See SP800-22 Section 2.12.7) [8] The Linear Complexity Test block length is required to be set to between 500 and 5,000 (inclusive), and requires that 200 ! M n . (See SP800-22 Section 2.11.7.) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST SP800-22, revisions dated May 15, 2001.