Document Comparison
PCI_PTS_POI_SRs_v3_1.pdf
→
PCI_PTS_POI_SRs_v4-1b-Sept_2015.pdf
56% similar
51 → 60
Pages
12793 → 16001
Words
150
Content Changes
Content Changes
150 content changes. 78 administrative changes (dates, page numbers) hidden.
Added
p. 2
February 2013 4.x RFC version
June 2013 4.0 Public release
July 2015 4.1a Updates for errata and new core section J
June 2013 4.0 Public release
July 2015 4.1a Updates for errata and new core section J
Added
p. 5
Version 3 introduced significant changes in how PCI will be evaluating PIN and non-PIN acceptance POI terminals. PCI no longer maintains three separate security evaluation programs (point-of-sale PIN entry device (PED), encrypting PIN pad (EPP), and unattended payment terminal (UPT)). Instead PCI provides and supports one set of modular requirements, which covers all product options.
This change was reflected in our renaming of this document to be the Modular Security Requirements.
This version 4 additionally provides for:
Submission by the vendor for assessment and publication on the PCI website of a user-available security policy addressing the proper use of the POI in a secure fashion, as further delineated in requirement B20.
Greater granularity and robustness of the underlying PCI-recognized laboratory test procedures for compliance validation of a device to these requirements as detailed in the Derived Test Requirements.
The addition of a new Core Module section that applies to all POI device …
This change was reflected in our renaming of this document to be the Modular Security Requirements.
This version 4 additionally provides for:
Submission by the vendor for assessment and publication on the PCI website of a user-available security policy addressing the proper use of the POI in a secure fashion, as further delineated in requirement B20.
Greater granularity and robustness of the underlying PCI-recognized laboratory test procedures for compliance validation of a device to these requirements as detailed in the Derived Test Requirements.
The addition of a new Core Module section that applies to all POI device …
Added
p. 9
PCI PTS POI DTRs PCI SSC
Added
p. 15
The POS Terminal integration Evaluation Module ensures that the integration of previously approved components does not impair the overall security as stated in the security requirements. This module also supports the cost-effective maintenance of components.
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario. All attacks shall include a minimum of ten hours’ attack time for exploitation.
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario. All attacks shall include a minimum of ten hours’ attack time for exploitation.
Added
p. 17
A7 The unauthorized alteration of prompts for non-PIN data entry into the PIN entry key pad such that PINs are compromised, i.e., by prompting for the PIN entry when the output is not encrypted, cannot occur without requiring an attack potential of at least 18 per device for identification and initial exploitation with a minimum of 9 for exploitationC.
Added
p. 18
A11 If PIN entry is accompanied by audible tones, the tone for each entered PIN digit is indistinguishable from the tone for any other entered PIN digit.
B4.1 The firmware must support the authentication of applications loaded onto the terminal consistent with B4. If the device allows software application and/or configuration updates, the device cryptographically authenticates updates consistent with B4.
B4.2 The vendor must provide a defined and documented process containing specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with the management of display prompts, or any mechanisms used for authenticating any application code. This must ensure:
The signing process is performed under dual control.
All executable files are signed.
Software is only signed using a secure cryptographic device provided by the terminal vendor.
B16 All prompts for non-PIN data entry are under the control of the cryptographic unit of the device. …
B4.1 The firmware must support the authentication of applications loaded onto the terminal consistent with B4. If the device allows software application and/or configuration updates, the device cryptographically authenticates updates consistent with B4.
B4.2 The vendor must provide a defined and documented process containing specific details on how any signing mechanisms must be implemented. This must include any “turnkey” systems required for compliance with the management of display prompts, or any mechanisms used for authenticating any application code. This must ensure:
The signing process is performed under dual control.
All executable files are signed.
Software is only signed using a secure cryptographic device provided by the terminal vendor.
B16 All prompts for non-PIN data entry are under the control of the cryptographic unit of the device. …
Added
p. 23
If the device encrypting the PIN and the ICC reader are not integrated into the same secure module, and the cardholder verification method is determined to be:
A plaintext PIN, the PIN block shall be enciphered from the device encrypting the PIN to the ICC reader (the ICC reader will then decipher the PIN for transmission in plaintext to the IC card) in accordance with ISO 9564.
If the device encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:
An enciphered PIN, the PIN block shall be enciphered using an authenticated encipherment key of the IC card.
The POS Terminal Integration Evaluation Module ensures that the integration of previously approved components does not impair the overall security as stated in the security requirements. This module also supports the cost effective maintenance of components.
An overlay attack must require an …
A plaintext PIN, the PIN block shall be enciphered from the device encrypting the PIN to the ICC reader (the ICC reader will then decipher the PIN for transmission in plaintext to the IC card) in accordance with ISO 9564.
If the device encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:
An enciphered PIN, the PIN block shall be enciphered using an authenticated encipherment key of the IC card.
The POS Terminal Integration Evaluation Module ensures that the integration of previously approved components does not impair the overall security as stated in the security requirements. This module also supports the cost effective maintenance of components.
An overlay attack must require an …
Added
p. 28
This table must be completed considering the vulnerability assessment in its entirety. Answer “Yes” if all the options declared in the Open Protocols Module
• Protocol Declaration Form meet these security requirements.
Number Description of Requirement Yes No N/A G1 The device vendor has internal policies and procedures that ensure that the vendor maintains an effective process for detecting vulnerabilities that may exist within their device. This process is expected to be robust enough to include all interfaces defined in requirement F1. This process must be effective enough to detect vulnerabilities which may have not been publicly known during the last vulnerability assessment.
G3 The device vendor has vulnerability disclosure measures in place for the device.
a) The vulnerability-disclosure measures are documented.
b) The vulnerability-disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description, and assessment of the vulnerabilities.
c) The vulnerability-disclosure measures ensure a timely distribution of mitigation …
• Protocol Declaration Form meet these security requirements.
Number Description of Requirement Yes No N/A G1 The device vendor has internal policies and procedures that ensure that the vendor maintains an effective process for detecting vulnerabilities that may exist within their device. This process is expected to be robust enough to include all interfaces defined in requirement F1. This process must be effective enough to detect vulnerabilities which may have not been publicly known during the last vulnerability assessment.
G3 The device vendor has vulnerability disclosure measures in place for the device.
a) The vulnerability-disclosure measures are documented.
b) The vulnerability-disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description, and assessment of the vulnerabilities.
c) The vulnerability-disclosure measures ensure a timely distribution of mitigation …
Added
p. 29
Table H: Vendor Guidance in its Entirety Number Description of Requirement Yes No N/A H1 The device has security guidance that describes how protocols and services must be used for each interface that is accessible by the device applications.
H2 The device has guidance that describes the default configuration for each protocol and services for each interface that is available on the device. Each interface and protocol on the device should default to secure settings. If the interface has the ability to be configurable to non-secure settings, vendor guidance should strongly recommend against configuring to non-secure settings.
This table must be completed considering the operational testing in its entirety. Answer “Yes” if all the open protocols and interfaces declared in the Open Protocols Module
• Protocol Declaration Form meet the security requirement.
Table I: Operational Testing in their Entirety Number Description of Requirement Yes No N/A I1 The device has all the security protocols …
H2 The device has guidance that describes the default configuration for each protocol and services for each interface that is available on the device. Each interface and protocol on the device should default to secure settings. If the interface has the ability to be configurable to non-secure settings, vendor guidance should strongly recommend against configuring to non-secure settings.
This table must be completed considering the operational testing in its entirety. Answer “Yes” if all the open protocols and interfaces declared in the Open Protocols Module
• Protocol Declaration Form meet the security requirement.
Table I: Operational Testing in their Entirety Number Description of Requirement Yes No N/A I1 The device has all the security protocols …
Added
p. 38
Number Description of Requirement Yes No N/A L1 Change-control procedures are in place so that any intended change to the physical or functional capabilities of the POI causes a re- certification of the device under the Physical Security Requirements or the Logical Security Requirements of this document. Immediate re- certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality. Approval of delta submissions is contingent on evidence of the ongoing change control and vulnerability management process.
L7 Security measures are taken during the development and maintenance of POI security-related components. The manufacturer must maintain development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the POI security-related components in their development environment. The development-security documentation …
L7 Security measures are taken during the development and maintenance of POI security-related components. The manufacturer must maintain development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the POI security-related components in their development environment. The development-security documentation …
Added
p. 50
Accountability The property that ensures that the actions of an entity may be traced uniquely to that entity.
Active Erasure The intentional clearing of data from storage through a means other than simply removing power (e.g. zeroization, inverting power).
Advanced Encryption Algorithm (AES) The Advanced Encryption Standard (AES), also known as Rijndael, is a block cipher adopted as an encryption standard by the U.S. government. It has been analyzed extensively and is now used worldwide, as was the case with its predecessor, the Data Encryption Standard (DES).
Application Application is considered to be any code in the device that does not impact compliance to these security requirements.
Authentication The process for establishing unambiguously the identity of an entity, process, organization, or person.
Authorization The right granted to a user to access an object, resource, or function.
Authorize To permit or give authority to a user to communicate with or make use of an object, resource, or …
Active Erasure The intentional clearing of data from storage through a means other than simply removing power (e.g. zeroization, inverting power).
Advanced Encryption Algorithm (AES) The Advanced Encryption Standard (AES), also known as Rijndael, is a block cipher adopted as an encryption standard by the U.S. government. It has been analyzed extensively and is now used worldwide, as was the case with its predecessor, the Data Encryption Standard (DES).
Application Application is considered to be any code in the device that does not impact compliance to these security requirements.
Authentication The process for establishing unambiguously the identity of an entity, process, organization, or person.
Authorization The right granted to a user to access an object, resource, or function.
Authorize To permit or give authority to a user to communicate with or make use of an object, resource, or …
Added
p. 51
DES Data Encryption Standard (see Data Encryption Algorithm). The National Institute of Standards and Technology Data Encryption Standard, adopted by the U.S. government as Federal Information Processing Standard (FIPS) Publication 46, which allows only hardware implementations of the data encryption algorithm.
Digital Signature The result of an asymmetric cryptographic transformation of data that allows a recipient of the data to validate the origin and integrity of the data and protects the sender against forgery by third parties or the recipient.
Double-Length Key A cryptographic key having a length of 112 active bits plus 16 parity bits, used in conjunction with the TDES cryptographic algorithm.
DTR Derived Test Requirement DUKPT Derived Unique Key Per Transaction: A key-management method that uses a unique key for each transaction, and prevents the disclosure of any past key used by the transaction originating TRSM. The unique transaction keys are derived from a base-derivation key using only non-secret data …
Digital Signature The result of an asymmetric cryptographic transformation of data that allows a recipient of the data to validate the origin and integrity of the data and protects the sender against forgery by third parties or the recipient.
Double-Length Key A cryptographic key having a length of 112 active bits plus 16 parity bits, used in conjunction with the TDES cryptographic algorithm.
DTR Derived Test Requirement DUKPT Derived Unique Key Per Transaction: A key-management method that uses a unique key for each transaction, and prevents the disclosure of any past key used by the transaction originating TRSM. The unique transaction keys are derived from a base-derivation key using only non-secret data …
Added
p. 52
Encrypted Key (Ciphertext Key) A cryptographic key that has been encrypted with a key-encrypting key, a PIN, or a password in order to disguise the value of the underlying plaintext key.
Encrypting PIN Pad (EPP) A device for secure PIN entry and encryption in an unattended PIN- acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device. An EPP is typically used in an ATM or other unattended device (e.g., an unattended kiosk or automated fuel dispenser) for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant or tamper-evident shell.
Encrypting PIN pads require integration into UPTs or ATMs.
Encryption See Encrypt.
Entropy The uncertainty of a random variable.
Firmware For purposes of these requirements, firmware is considered to be any code within the device that provides …
Encrypting PIN Pad (EPP) A device for secure PIN entry and encryption in an unattended PIN- acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device. An EPP is typically used in an ATM or other unattended device (e.g., an unattended kiosk or automated fuel dispenser) for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant or tamper-evident shell.
Encrypting PIN pads require integration into UPTs or ATMs.
Encryption See Encrypt.
Entropy The uncertainty of a random variable.
Firmware For purposes of these requirements, firmware is considered to be any code within the device that provides …
Added
p. 53
Approved hash functions satisfy the following properties:
1) One-way: It is computationally infeasible to find any input that maps to any pre-specified output.
2) Collision-resistant: It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
It may be used to reduce a potentially long message into a “hash value” or “message digest” sufficiently compact to be input into a digital-signature algorithm. A “good” hash is such that the results of applying the function to a (large) set of values in a given domain will be evenly (and randomly) distributed over a smaller range.
Independent Expert An Independent Expert possesses all of the following qualifications:
Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA).
Has published extensively in peer-reviewed publications on the relevant subject.
Has years of experience …
1) One-way: It is computationally infeasible to find any input that maps to any pre-specified output.
2) Collision-resistant: It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
It may be used to reduce a potentially long message into a “hash value” or “message digest” sufficiently compact to be input into a digital-signature algorithm. A “good” hash is such that the results of applying the function to a (large) set of values in a given domain will be evenly (and randomly) distributed over a smaller range.
Independent Expert An Independent Expert possesses all of the following qualifications:
Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA).
Has published extensively in peer-reviewed publications on the relevant subject.
Has years of experience …
Added
p. 54
Joint Interpretation Library (JIL) A set of documents agreed upon by the British, Dutch, French, and German Common Criteria Certification Bodies to provide a common interpretation of criteria for composite evaluations, attack paths, attack quotations, and methodology.
KEK See Key-Encrypting Key.
Key See Cryptographic Key.
Key Agreement A key-establishment protocol for establishing a shared secret key between entities in such a way that neither of them can predetermine the value of that key. That is, the secret key is a function of information contributed by two or more participants.
Key Archive Process by which a key no longer in operational use at any location is stored.
Key Backup Storage of a protected copy of a key during its operational use.
Key Bundle The three cryptographic keys (K1, K2, K3) used with a TDEA mode.
Key Component See Cryptographic Key Component.
Key Deletion Process by which an unwanted key, and information from which the key may be reconstructed, is …
KEK See Key-Encrypting Key.
Key See Cryptographic Key.
Key Agreement A key-establishment protocol for establishing a shared secret key between entities in such a way that neither of them can predetermine the value of that key. That is, the secret key is a function of information contributed by two or more participants.
Key Archive Process by which a key no longer in operational use at any location is stored.
Key Backup Storage of a protected copy of a key during its operational use.
Key Bundle The three cryptographic keys (K1, K2, K3) used with a TDEA mode.
Key Component See Cryptographic Key Component.
Key Deletion Process by which an unwanted key, and information from which the key may be reconstructed, is …
Added
p. 55
Key Replacement Substitution of one key for another when the original key is known or suspected to be compromised or the end of its operational life is reached.
Key (Secret) Share One of at least two parameters related to a cryptographic key generated in such a way that a quorum of such parameters can be combined to form the cryptographic key but such that less than a quorum does not provide any information about the key.
Key Storage Holding of the key in one of the permissible forms.
Key Termination Occurs when a key is no longer required for any purpose and all copies of the key and information required to regenerate or reconstruct the key have been deleted from all locations where they ever existed.
Key Transport A key-establishment protocol under which the secret key is determined by the initiating party and transferred suitably protected.
Manual Key Entry The entry of cryptographic keys into …
Key (Secret) Share One of at least two parameters related to a cryptographic key generated in such a way that a quorum of such parameters can be combined to form the cryptographic key but such that less than a quorum does not provide any information about the key.
Key Storage Holding of the key in one of the permissible forms.
Key Termination Occurs when a key is no longer required for any purpose and all copies of the key and information required to regenerate or reconstruct the key have been deleted from all locations where they ever existed.
Key Transport A key-establishment protocol under which the secret key is determined by the initiating party and transferred suitably protected.
Manual Key Entry The entry of cryptographic keys into …
Added
p. 56
Opaque Impenetrable by light (i.e., light within the visible spectrum of wavelength range of 400nm to 750nm); neither transparent nor translucent within the visible spectrum.
PAN Acronym for “primary account number” and also referred to as “account number.” Payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
Password A string of characters used to authenticate an identity or to verify access authorization.
Personal Identification Number (PIN) A numeric personal identification code that authenticates a cardholder in an authorization request that originates at a terminal with authorization only or data capture only capability. A PIN consists only of decimal digits.
PIN Entry Device (PED) A complete terminal that can be provided to a merchant “as is” to undertake PIN-related transactions. This may include either attended or unattended POS POI terminals.
Plaintext The intelligible form of an encrypted text or of its elements.
Plaintext Key An unencrypted cryptographic key, …
PAN Acronym for “primary account number” and also referred to as “account number.” Payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
Password A string of characters used to authenticate an identity or to verify access authorization.
Personal Identification Number (PIN) A numeric personal identification code that authenticates a cardholder in an authorization request that originates at a terminal with authorization only or data capture only capability. A PIN consists only of decimal digits.
PIN Entry Device (PED) A complete terminal that can be provided to a merchant “as is” to undertake PIN-related transactions. This may include either attended or unattended POS POI terminals.
Plaintext The intelligible form of an encrypted text or of its elements.
Plaintext Key An unencrypted cryptographic key, …
Added
p. 57
Public Key A cryptographic key, used with a public-key cryptographic algorithm, uniquely associated with an entity, and that may be made public.
In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key that is “publicly known” is not necessarily globally available. The key may only be available to all members of a pre-specified group.
Public Key (Asymmetric) Cryptography A cryptographic technique that uses two related transformations•a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is not computationally feasible to derive the private transformation.
A system based on asymmetric cryptographic techniques can be an encipherment system, a signature system, a combined encipherment and signature system, or a key agreement system.
With asymmetric cryptographic …
In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key that is “publicly known” is not necessarily globally available. The key may only be available to all members of a pre-specified group.
Public Key (Asymmetric) Cryptography A cryptographic technique that uses two related transformations•a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is not computationally feasible to derive the private transformation.
A system based on asymmetric cryptographic techniques can be an encipherment system, a signature system, a combined encipherment and signature system, or a key agreement system.
With asymmetric cryptographic …
Added
p. 58
Secret Key (Symmetric) Cryptographic Algorithm A cryptographic algorithm that uses a single, secret key for both encryption and decryption.
Secure Cryptographic Device A physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic processes, or both, including cryptographic algorithms.
Secure Cryptoprocessor A secure cryptoprocessor is a dedicated computer on a chip or microprocessor for carrying out cryptographic operations, embedded in a packaging with multiple physical security measures that give it a degree of tamper resistance.
Secure Key Loader A self-contained unit that is capable of storing at least one plaintext or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.
Security Policy A description of how the specific module meets these security requirements, including the rules derived from this standard and additional rules imposed by the …
Secure Cryptographic Device A physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic processes, or both, including cryptographic algorithms.
Secure Cryptoprocessor A secure cryptoprocessor is a dedicated computer on a chip or microprocessor for carrying out cryptographic operations, embedded in a packaging with multiple physical security measures that give it a degree of tamper resistance.
Secure Key Loader A self-contained unit that is capable of storing at least one plaintext or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.
Security Policy A description of how the specific module meets these security requirements, including the rules derived from this standard and additional rules imposed by the …
Added
p. 59
SHA-1 Secure Hash Algorithm. SHA-1 produces a 160-bit message digest.
SHA-2 A set of cryptographic hash functions (SHA-224, SHA-256, SHA-384, SHA- 512). SHA-2 consists of a set of four hash functions with digests that are 224, 256, 384 or 512 bits.
Shared Secret The secret information shared between parties after protocol execution. This may consist of one or more session key(s), or it may be a single secret that is input to a key-derivation function to derive session keys.
Single-Length Key A cryptographic key having a length of 56 active bits plus 8 parity bits used in conjunction with the DES cryptographic algorithm.
SK Session key Split Knowledge A condition under which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.
Symmetric (Secret) Key A cryptographic key that is used in symmetric cryptographic algorithms. The same symmetric key that is used for encryption is also used …
SHA-2 A set of cryptographic hash functions (SHA-224, SHA-256, SHA-384, SHA- 512). SHA-2 consists of a set of four hash functions with digests that are 224, 256, 384 or 512 bits.
Shared Secret The secret information shared between parties after protocol execution. This may consist of one or more session key(s), or it may be a single secret that is input to a key-derivation function to derive session keys.
Single-Length Key A cryptographic key having a length of 56 active bits plus 8 parity bits used in conjunction with the DES cryptographic algorithm.
SK Session key Split Knowledge A condition under which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.
Symmetric (Secret) Key A cryptographic key that is used in symmetric cryptographic algorithms. The same symmetric key that is used for encryption is also used …
Added
p. 60
Tampering The penetration or modification of an internal operation and/or insertion of active or passive tapping mechanisms to determine or record secret data or to alter the operation of the device.
TDEA See Triple Data Encryption Algorithm.
TDES See Triple Data Encryption Standard.
TLS Transport Layer Security TOE Target of Evaluation Triple Data Encryption Algorithm (TDEA) The algorithm specified in ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation.
Triple Data Encryption Standard (TDES) See Triple Data Encryption Algorithm.
Triple-Length Key A cryptographic key having a length of 168 active bits plus 24 parity bits, used in conjunction with the TDES cryptographic algorithm.
Variant of a Key A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key.
Working Key A key used to cryptographically process the transaction. A working …
TDEA See Triple Data Encryption Algorithm.
TDES See Triple Data Encryption Standard.
TLS Transport Layer Security TOE Target of Evaluation Triple Data Encryption Algorithm (TDEA) The algorithm specified in ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation.
Triple Data Encryption Standard (TDES) See Triple Data Encryption Algorithm.
Triple-Length Key A cryptographic key having a length of 168 active bits plus 24 parity bits, used in conjunction with the TDES cryptographic algorithm.
Variant of a Key A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key.
Working Key A key used to cryptographically process the transaction. A working …
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements Version 3.1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements Version 4.1b
Removed
p. 5
This Version 3.x introduces significant changes in how PCI will be evaluating PIN and non-PIN acceptance POI terminals. PCI will no longer maintain three separate security evaluation programs (point- of-sale PIN entry device (PED), encrypting PIN pad (EPP), and unattended payment terminal (UPT)). Instead it will provide and support one set of modular requirements, which will cover all product options.
Modified
p. 5
The layout of the document was also changed to enable vendors to select the appropriate requirements that match the product they are submitting for evaluation.
Modified
p. 5
PED or UPT POI devices: Complete terminals that can be provided to a merchant ―as-is‖ to undertake PIN-related transactions. This includes attended and unattended POS PIN-acceptance devices.
PED or UPT POI devices: Complete terminals that can be provided to a merchant “as-is” to undertake PIN-related transactions. This includes attended and unattended POS PIN-acceptance devices.
Removed
p. 6
A single evaluation to address the diversity of POI device architectures and integration models (dedicated PIN pads, dedicated stand-alone POS devices, vending machines, kiosks, etc.) The segmentation of requirements into two main evaluation modules (Device Integration Requirements and POI Device Core Requirements) to facilitate components integration and evaluation maintenance The addition of the following set of requirements and corresponding evaluation modules Open Protocols (To address the interface of POI terminals to open networks using open protocols) Secure Reading and Exchange of Data (Optional: To support secure encryption of account data in the terminal) The addition of non-PIN acceptance devices and secure (encrypting) card readers as approval classes.
Modified
p. 8
Evaluation Domains Device characteristics are those attributes of the device that define its physical and its logical (functional) characteristics. The physical security characteristics of the device are those attributes that deter a physical attack on the device, for example, the penetration of the device to determine its key(s) or to plant a sensitive data-disclosing ―bug‖ within it. Logical security characteristics include those functional capabilities that preclude, for example, allowing the device to output a clear-text PIN-encryption key.
Evaluation Domains Device characteristics are those attributes of the device that define its physical and its logical (functional) characteristics. The physical security characteristics of the device are those attributes that deter a physical attack on the device, for example, the penetration of the device to determine its key(s) or to plant a sensitive data-disclosing “bug” within it. Logical security characteristics include those functional capabilities that preclude, for example, allowing the device to output a clear-text PIN-encryption key.
Modified
p. 8
This document is only concerned with the device management for POI devices up to the point of initial key loading. Subsequent to receipt of the device at the initial key-loading facility, the responsibility for the device falls to the acquiring financial institution and its agents (e.g., merchants and processors), and is covered by the operating rules of the participating PCI payment brands and the PCI PIN Security Requirements.
This document is only concerned with the device management for POI devices up to the point of initial key loading for payment transaction keys (keys used by the acquiring organization) or at the facility of initial deployment. Subsequent to receipt of the device at the initial key-loading facility or at the facility of initial deployment, the responsibility for the device falls to the acquiring financial institution and its agents (e.g., merchants and processors), and is covered by the operating rules …
Removed
p. 9
PCI DSS v1.2.1 PCI SSC
Removed
p. 10
Device or component photo* (If applicable):
Please attach a photo of the terminal under evaluation, 320x320 pixels.
Please attach a photo of the terminal under evaluation, 320x320 pixels.
Modified
p. 10
Dedicated PIN pad Stand-alone POS terminal Vending, AFD, Kiosk Other Encrypting PIN pad (for ATM Vending, AFD or Kiosk) Secure component for PIN entry device Non-PED POI device Secure (encrypting) card reader Manufacturer*: Marketing Model Name/Number*:
Dedicated for PIN entry only Stand-alone POS terminal UPT (Vending, AFD, Kiosk) Other Encrypting PIN pad (for ATM, Vending, AFD or Kiosk) Secure (encrypting) card reader Other secure component for PIN entry device Non-PED POI device Manufacturer*: Marketing Model Name/Number*:
Modified
p. 10
Hardware Version Number*A: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Firmware/Software Version Number*: Application Version Number*: (if applicable) Version of PCI PTS POI Security Requirements: V3 FAQ version:
Hardware Version Number*A: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Firmware/Software Version Number*: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 …
Modified
p. 10
Yes No N/A POS terminal Integration Core PIN Entry Security Open Protocols Secure Reading and Exchange of Data Previously Approved Components Used* (if applicable) Summary Description/Function Vendor Name Marketing Name
Yes No N/A Core PIN Entry Security POS Terminal Integration Open Protocols Secure Reading and Exchange of Data Previously Approved Components Used* (if applicable) Vendor Name Device Marketing/Model
Modified
p. 10
PCI PTS Approval Number Expiry Date FAQ Version (if applicable) * Fields marked with an asterisk (*) will be used in the PCI SSC Approved PIN Transaction Security Devices Approval List. A See ―Optional Use of Variables in the Identifier,‖ following page.
PCI PTS Approval Product Type per PCI SSC Website Other Continued on next page * Fields marked with an asterisk (*) will be used in the PCI SSC Approved PIN Transaction Security Devices Approval List. A See “Optional Use of Variables in the Identifier,” following page.
Modified
p. 15
Evaluation Module Requirements Set Remarks Requirements Physical and logical Security The core logical and physical requirements of PIN-acceptance POI devices 2: POS Terminal Integration POS Terminal Integration The PCI PTS POI approval framework is oriented to the evaluation of integrated PIN entry devices (i.e., device where PIN entry functionality is in a secure logical and physical perimeter). However, it allows the re-use of previously approved individual components or their combinations (card readers, display, keypads, or secure processors) into the approval …
Evaluation Module Requirements Set Remarks Requirements Physical and logical Security The core logical and physical requirements of PIN-acceptance POI devices 2: POS Terminal Integration POS Terminal Integration The PCI PTS POI approval framework is oriented to the evaluation of integrated PIN entry devices (i.e., device where PIN entry functionality is in a secure logical and physical perimeter).
Removed
p. 16
Note: In the following requirements, the device under evaluation is referred as the “device.” Number Description of Requirement Yes No N/A A1 All parts of A1 must be met if A1 is applicable:
A2 If the device permits access to internal areas (e.g., for service or maintenance), it is not possible using this access area to insert a bug that would disclose sensitive data. Immediate access to sensitive data such as PIN or cryptographic data is either prevented by the design of the internal areas (e.g., by enclosing components with sensitive data into tamper-resistant/responsive enclosures), and/or it has a mechanism so that accessing internal areas causes the immediate erasure of sensitive data.
A2 If the device permits access to internal areas (e.g., for service or maintenance), it is not possible using this access area to insert a bug that would disclose sensitive data. Immediate access to sensitive data such as PIN or cryptographic data is either prevented by the design of the internal areas (e.g., by enclosing components with sensitive data into tamper-resistant/responsive enclosures), and/or it has a mechanism so that accessing internal areas causes the immediate erasure of sensitive data.
Modified
p. 16
Note: In the following requirements, the device under evaluation is referred to as the “device.” Number Description of Requirement Yes No N/A A1 The device uses tamper-detection and response mechanisms that cause it to become immediately inoperable and result in the automatic and immediate erasure of any sensitive data that may be stored in the device, such that it becomes infeasible to recover the sensitive data. These mechanisms protect against physical penetration of the device by means of (but not …
Modified
p. 16
A2 Failure of a single security mechanism does not compromise device security. Protection against a threat is based on a combination of at least two independent security mechanisms.
Removed
p. 17
Note: If the POI device has a keypad that can be used to enter non-PIN data, the device must meet at least one of the following: A8, B16.1, B16.2, or E3.4. (Statements A8 and B16.1 are intended to be met by the vendor controlling the means of authorizing prompt changes. Statement B16.2 is an option that allows third parties to control the means of authorization. E3.4 is for all other unattended POI devices not meeting one of the aforementioned.) A8 The unauthorized alteration of prompts for non-PIN data entry into the PIN entry key pad such that PINs are compromised, i.e., by prompting for the PIN entry when the output is not encrypted, cannot occur without requiring an attack potential of at least 18 per device for identification and initial exploitation with a minimum of 9 for exploitationC.
A11 Secure components intended for unattended devices contain an anti- removal mechanism to …
A11 Secure components intended for unattended devices contain an anti- removal mechanism to …
Modified
p. 17
A6 Determination of any PIN-security-related cryptographic key resident in the device, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 35 for identification and initial exploitation with a minimum of 15 for exploitation.
Modified
p. 17
A8 The device provides a means to deter the visual observation of PIN values as they are being entered by the cardholder.
Modified
p. 17
A9 It is not feasible to penetrate the device to make any additions, substitutions, or modifications to the magnetic-stripe reader and associated hardware or software, in order to determine or modify magnetic-stripe track data, without requiring an attack potential of at least 16 per device, for identification and initial exploitation, with a minimum of 8 for exploitationC.
Modified
p. 19
Note: In the following requirements, the device under evaluation is referred as the “device.” Number Description of Requirement Yes No N/A B1 The device performs a self-test, which includes integrity and authenticity tests as addressed in B4, upon start-up and at least once per day to check firmware, security mechanisms for signs of tampering, and whether the device is in a compromised state. In the event of a failure, the device and its functionality fail in a secure manner.
Note: In the following requirements, the device under evaluation is referred to as the “device.” Number Description of Requirement Yes No N/A B1 The device performs a self-test, which includes integrity and authenticity tests upon start-up and at least once per day to check whether the device is in a compromised state. In the event of a failure, the device and its functionality fail in a secure manner. The device must reinitialize memory at least every 24 hours.
Modified
p. 19
B3 The firmware, and any changes thereafter, have been inspected and reviewed using a documented and auditable process, and certified as being free from hidden and unauthorized or undocumented functions.
B3 The firmware and any changes thereafter have been inspected and reviewed using a documented and auditable process, and certified as being free from hidden and unauthorized or undocumented functions.
Modified
p. 19 → 20
B11 The key-management techniques implemented in the device conform to ISO 11568 and/or ANSI X9.24. Key-management techniques must support the ANSI TR-31 key derivation methodology or an equivalent methodology for maintaining the TDEA key bundle.
B11 The key-management techniques implemented in the device conform to ISO 11568 and/or ANSI X9.24. Key-management techniques must support the ANSI TR-31 key-derivation methodology or an equivalent methodology for maintaining the TDEA key bundle.
Removed
p. 20
Note: If the POI device has a keypad that can be used to enter non-PIN data, the device must meet at least one of the following: A8, B16.1, B16.2, or E3.4. (Statements A8 and B16.1 are intended to be met by the vendor controlling the means of authorizing prompt changes. Statement B16.2 is an option that allows third parties to control the means of authorization. E3.4 is for all other unattended POI devices not meeting one of the aforementioned.) B16.1 All prompts for non-PIN data entry are under the control of the cryptographic unit of the device and requiring an attack potential of at least 18 per device for identification and initial exploitation with a minimum of 9 for exploitationD to circumvent. If the prompts are stored inside the cryptographic unit, they cannot feasibly be altered without causing the erasure of the unit’s cryptographic keys. If the prompts are stored …
Modified
p. 20
B13 It is not possible to encrypt or decrypt any arbitrary data using any PIN- encrypting key or key-encrypting key contained in the device. The device must enforce that data keys, key-encipherment keys, and PIN-encryption keys have different values.
B13 It is not possible to encrypt or decrypt any arbitrary data using any PIN- encrypting key or key-encrypting key contained in the device.
Modified
p. 20 → 21
B17 If the device supports multiple applications, it must enforce the separation between applications. It must not be possible that one application interferes with or tampers with another application or the OS of the device including, but not limited to, modifying data objects belonging to another application or the OS.
Modified
p. 21
B19 The vendor must provide adequate documented security guidance for the integration of any secure component into a PIN entry POI Terminal.
B19 The vendor must provide adequate documented security guidance for the integration of any secure component into a PIN entry POI terminal.
Removed
p. 22
F When the cardholder verification method is determined to be an enciphered PIN, the encipherment must occur within the PED itself or a secure component of the terminal. The PIN must be enciphered in accordance with ISO 9564 for secure transport between the PED and the secure component.
Modified
p. 22
D
• Offline PIN Security Requirements Number Description of Requirement Yes No N/A D1 It is neither feasible to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data, without requiring an attack potential of at least 20 for identification and initial exploitation, with a minimum of 10 for exploitationE, nor is it possible for both anICC card and any other foreign …
• Offline PIN Security Requirements Number Description of Requirement Yes No N/A D1 It is neither feasible to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data, without requiring an attack potential of at least 20 for identification and initial exploitation, with a minimum of 10 for exploitationE, nor is it possible for both an
D
• Offline PIN Security Requirements Number Description of Requirement Yes No N/A D1 It is neither feasible to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data, without requiring an attack potential of at least 20 for identification and initial exploitation, with a minimum of 10 for exploitationE, nor is it possible for both an IC card and any other foreign …
• Offline PIN Security Requirements Number Description of Requirement Yes No N/A D1 It is neither feasible to penetrate the ICC reader to make any additions, substitutions, or modifications to either the ICC reader’s hardware or software, in order to determine or modify any sensitive data, without requiring an attack potential of at least 20 for identification and initial exploitation, with a minimum of 10 for exploitationE, nor is it possible for both an IC card and any other foreign …
Modified
p. 22 → 23
An enciphered PIN, the PIN block shall be enciphered between the device encrypting the PIN and the ICC reader using either an authenticated encipherment key of the IC card, or in accordance with ISO 9564.
Removed
p. 23
G A plain-text PIN from the PED to the ICC reader is never permitted except when the PED and ICC reader are integrated in a single tamper-resistant device (secure module).
Modified
p. 23
A plaintext PIN, then encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the plaintext PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.
Modified
p. 24
However it also allows the re-use of previously approved individual components or their combinations (card readers, display, keypads, or secure processors) into the approval process of integrated PIN entry devices The POS Terminal Integration Evaluation Module ensures that the integration of previously approved components does not impair the overall security as stated in the security requirements. This module also supports the cost effective maintenance of components This module includes security management requirements applicable to the integrated device and is applicable …
However it also allows the re-use of previously approved individual components or their combinations (card readers, display, keypads, or secure processors) into the approval process of integrated PIN entry devices.
Modified
p. 24
Note: In the following requirements, the device under evaluation is referred as the “device.” Number Description of Requirement Yes No N/A Configuration Management E1 Any secure component integrated into a PIN entry POI terminal submitted for evaluation has a clearly identified physical and logical security perimeter (related to PIN entry and card-reading functions).
Note: In the following requirements, the device under evaluation is referred to as the “device.” Number Description of Requirement Yes No N/A Configuration Management E1 Any secure component integrated into a PIN entry POI terminal submitted for evaluation has a clearly identified physical and logical security perimeter (related to PIN entry and card-reading functions).
Modified
p. 24
E2.2 The PIN pad (PIN entry area) and the surrounding area must be designed and engineered in such a way that the complete device does not facilitate the fraudulent placement of an overlay over the PIN pad. An overlay attack must require an attack potential of at least 18 for identification and initial exploitation, with a minimum of 9 for exploitationH.
E2.2 The PIN pad (PIN entry area) and the surrounding area must be designed and engineered in such a way that the complete device does not facilitate the fraudulent placement of an overlay over the PIN pad.
Modified
p. 24 → 25
G As defined in Appendix B of the PCI PTS POI DTRs.
Removed
p. 25
Note: If the POI device has a keypad that can be used to enter non-PIN data, the device must meet at least one of the following: A8, B16.1, B16.2, or E3.4. (Statements A8 and B16.1 are intended to be met by the vendor controlling the means of authorizing prompt changes. Statement B16.2 is an option that allows third parties to control the means of authorization. E3.4 is for all unattended POS or other POI devices not meeting one of the aforementioned.) E3.4 The POI (application) must enforce the correspondence between the display messages visible to the cardholder and the operating state (i.e., secure or non-secure mode) of the PIN entry device, e.g., by using cryptographic authentication. If commands impacting the correspondence between the display messages and the operating state of the PIN entry device are received from an external device (e.g., a store controller), the commands enabling data entry must …
Modified
p. 25
E3.5 The PIN-accepting POI terminal must be equipped with only one payment card PIN-acceptance interface, e.g., a keyboard. If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry, e.g., it must not have numeric keys, or it is not possible to use it otherwise for numeric entry or it is controlled in a manner consistent with B16.
E3.5 The PIN-accepting POI terminal must be equipped with only one payment card PIN-acceptance interface, e.g., a keyboard. If another interface is present which can be used as a keyboard, a mechanism must exist to prevent its use for PIN entry•e.g., it must not have numeric keys, or it is not possible to use it otherwise for numeric entry, or it is controlled in a manner consistent with B16.
Modified
p. 25 → 26
H As defined in Appendix B of the PCI PTS POI DTRs.
Removed
p. 26
Number Description of Requirement Yes No N/A F1 The platform vendor has clearly identified all the link layer options that are available on the platform in the Open Protocols Module
•Protocol Declaration Form.
The platform vendor maintains security guidance, describing how the IP and link layer must be used.
•Protocol Declaration Form.
The platform vendor maintains security guidance, describing how the IP and link layer must be used.
Modified
p. 26 → 27
This table must be completed considering the IP and link layer in its entirety. Answer ―Yes‖ if all the options declared in the Open Protocols Module
• Protocol Declaration Form are meet these security requirements.
• Protocol Declaration Form are meet these security requirements.
This table must be completed considering all open protocol interfaces in its entirety. Answer “Yes” if all the options declared in the Open Protocols Module
• Protocol Declaration Form are meet these security requirements.
• Protocol Declaration Form are meet these security requirements.
Modified
p. 26 → 28
The platform vendor has executed a vulnerability assessment, to ensure that the IP and link layer do not contain exploitable vulnerabilities.
G2 The device has undergone a vulnerability assessment to ensure that the protocols and interfaces list in F1 do not contain exploitable vulnerabilities.
Modified
p. 26 → 28
a) The vulnerability assessment is supported by a documented analysis describing the security of the IP and link layer.
a) The vulnerability assessment is supported by a documented analysis describing the security of the protocols and interfaces.
Modified
p. 26 → 29
a) The platform vendor puts the security guidance at the disposal of application developers, system integrators, and end-users of the platform.
a) The key-management guidance is at the disposal of internal users and/or of application developers, system integrators, and end- users of the device.
Modified
p. 26 → 29
d) Key-management security guidance ensures secure use of keys and certificates.
Removed
p. 27
Number Description of Requirement Yes No N/A G1 The platform vendor has clearly identified all the IP protocols that are available on the platform in the Open Protocols Module
• Protocol Declaration Form.
G2 The platform vendor has executed a vulnerability assessment, to ensure that the IP protocols do not contain exploitable vulnerabilities.
a) The vulnerability assessment is supported by a documented analysis describing the security of the IP protocols.
b) The vulnerability assessment is supported by a vulnerability survey of information available in the public domain.
c) The vulnerability assessment is supported by testing.
G3 The platform vendor maintains security guidance, describing how the IP protocols have to be used.
b) The security guidance ensures secure use of the IP protocols.
G4 The default configuration of the IP protocols is in line with the security guidance. If the device allows configuration updates, the device cryptographically authenticates the update and if the authenticity is not confirmed, the update …
• Protocol Declaration Form.
G2 The platform vendor has executed a vulnerability assessment, to ensure that the IP protocols do not contain exploitable vulnerabilities.
a) The vulnerability assessment is supported by a documented analysis describing the security of the IP protocols.
b) The vulnerability assessment is supported by a vulnerability survey of information available in the public domain.
c) The vulnerability assessment is supported by testing.
G3 The platform vendor maintains security guidance, describing how the IP protocols have to be used.
b) The security guidance ensures secure use of the IP protocols.
G4 The default configuration of the IP protocols is in line with the security guidance. If the device allows configuration updates, the device cryptographically authenticates the update and if the authenticity is not confirmed, the update …
Modified
p. 27 → 29
This table must be completed considering the IP protocols in their entirety. Answer ―Yes‖ if all the options declared in the Open Protocols Module
• Protocol Declaration Form meet these security requirements.
• Protocol Declaration Form meet these security requirements.
This table must be completed considering the vendor guidance in its entirety. Answer “Yes” if all the open protocols and interfaces declared in the Open Protocols Module
• Protocol Declaration Form meet these security requirements.
• Protocol Declaration Form meet these security requirements.
Modified
p. 27 → 29
c) Key-management security guidance describes the responsibilities of the device vendor, application developers, system integrators, and end-users of the device.
Removed
p. 28
b) The vulnerability assessment is supported by a vulnerability survey of information available in the public domain.
c) The vulnerability assessment is supported by testing.
b) The security guidance ensures secure use of the IP protocols.
Table H1 must be completed considering the security protocols in their entirety. Answer ―Yes‖ if all the security protocols declared in the Open Protocols Module
• Protocol Declaration Form meet these security requirements.
Table H1: Security Protocol in its Entirety Number Description of Requirement Yes No N/A H1 The platform vendor has clearly identified all the security protocols that are available on the platform in the Open Protocols Module
• Protocol Declaration Form.
H2 The platform vendor has executed a vulnerability assessment, to ensure that the security protocols do not contain exploitable vulnerabilities.
a) The vulnerability assessment is supported by a documented analysis describing why the vendor is convinced of the security protocols not jeopardizing platform security.
H3 The platform vendor maintains security …
c) The vulnerability assessment is supported by testing.
b) The security guidance ensures secure use of the IP protocols.
Table H1 must be completed considering the security protocols in their entirety. Answer ―Yes‖ if all the security protocols declared in the Open Protocols Module
• Protocol Declaration Form meet these security requirements.
Table H1: Security Protocol in its Entirety Number Description of Requirement Yes No N/A H1 The platform vendor has clearly identified all the security protocols that are available on the platform in the Open Protocols Module
• Protocol Declaration Form.
H2 The platform vendor has executed a vulnerability assessment, to ensure that the security protocols do not contain exploitable vulnerabilities.
a) The vulnerability assessment is supported by a documented analysis describing why the vendor is convinced of the security protocols not jeopardizing platform security.
H3 The platform vendor maintains security …
Removed
p. 29
Answer ―Yes‖ if the security protocol specified in the table meets the security requirement.
Table H2: Specified Security Protocol Security Protocol Name:
a) The platform vendor puts the key management security guidance at the disposal of internal users, and/or of application developers, system integrators and end-users of the platform.
c) Key management security guidance describes the responsibilities of the platform vendor, application developers, system integrators and end-users of the platform.
d) Key management security guidance ensures secure use of keys and certificates.
H10 The security protocol makes use of a random generator that has been validated against NIST SP 800-22 or equivalent.
Table H2: Specified Security Protocol Security Protocol Name:
a) The platform vendor puts the key management security guidance at the disposal of internal users, and/or of application developers, system integrators and end-users of the platform.
c) Key management security guidance describes the responsibilities of the platform vendor, application developers, system integrators and end-users of the platform.
d) Key management security guidance ensures secure use of keys and certificates.
H10 The security protocol makes use of a random generator that has been validated against NIST SP 800-22 or equivalent.
Modified
p. 29
H3 The device has guidance for key management describing how keys and certificates must be used.
Modified
p. 29
b) Key management security guidance describes the properties of all keys and certificates that can be used by the platform.
b) Key-management security guidance describes the properties of all keys and certificates that can be used by the device.
Modified
p. 29 → 30
I2 The device is able to provide confidentiality of data sent over a network connection.
Modified
p. 29 → 30
b) Encryption is provided by using keys that are established in a secure manner using appropriate key management procedures, such as those listed in NIST SP800-21, Guidelines for Implementing Cryptography.
b) Encryption is provided by using keys that are established in a secure manner using appropriate key-management procedures, such as those listed in NIST SP800-21, Guidelines for Implementing Cryptography in the Federal Government and ISO 11568 Banking
• Key Management (Retail).
• Key Management (Retail).
Modified
p. 29 → 30
I3 The device is able to provide the integrity of data that is sent over a network connection.
Modified
p. 29 → 30
a) Integrity is provided by a MAC or by a digital signature.
a) Integrity is provided by a MAC as defined in ISO 16609, or by a digital signature.
Modified
p. 29 → 30
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384 and SHA-512.
b) Hashing can be provided by at least one of the following algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.
Modified
p. 29 → 30
I4 The device uses a declared security protocol to authenticate the server.
Modified
p. 29 → 30
c) The device is able to verify the validity of the public keys it receives.
Modified
p. 29 → 30
d) The device is able to verify the authenticity of the public keys it receives.
Modified
p. 29 → 31
I5 The device is able to detect replay of messages and enables the secure handling of the exceptions.
Removed
p. 30
Table I1 must be completed considering the IP services in their entirety. Answer ―Yes‖ if all the IP services declared in the Open Protocols Module
• Protocol Declaration Form meet the security requirement.
Table I1: IP Services in their Entirety Number Description of Requirement Yes No N/A I1 The platform vendor has clearly identified all the IP services that are available on the platform in the Open Protocols Module
• Protocol Declaration Form.
I2 The platform vendor has executed a vulnerability assessment, to ensure that the IP services do not contain exploitable vulnerabilities.
a) The assessment is supported by a documented analysis describing why the vendor is convinced of the IP services not jeopardizing platform security.
b) The assessment is supported by a vulnerability survey of information available in the public domain.
c) The assessment is supported by testing.
I3 The platform vendor maintains security guidance, describing how the IP services have to be used.
b) The security guidance …
• Protocol Declaration Form meet the security requirement.
Table I1: IP Services in their Entirety Number Description of Requirement Yes No N/A I1 The platform vendor has clearly identified all the IP services that are available on the platform in the Open Protocols Module
• Protocol Declaration Form.
I2 The platform vendor has executed a vulnerability assessment, to ensure that the IP services do not contain exploitable vulnerabilities.
a) The assessment is supported by a documented analysis describing why the vendor is convinced of the IP services not jeopardizing platform security.
b) The assessment is supported by a vulnerability survey of information available in the public domain.
c) The assessment is supported by testing.
I3 The platform vendor maintains security guidance, describing how the IP services have to be used.
b) The security guidance …
Modified
p. 30 → 31
I6 The device implements session management.
Modified
p. 30 → 31
a) The platform keeps track of all connections and restricts the number of sessions that can remain active on the platform to the minimum necessary number.
a) The device keeps track of all connections and restricts the number of sessions that can remain active on the device to the minimum necessary number.
Modified
p. 30 → 31
b) The platform sets time limits for sessions and ensures that sessions are not left open for longer than necessary.
b) The device sets time limits for sessions and ensures that sessions are not left open for longer than necessary.
Modified
p. 30 → 32
a) The platform vendor puts the security guidance at the disposal of application developers, system integrators and end-users of the platform.
a) The guidance is at the disposal of internal users, and/or of application developers, system integrators and end-users of the device.
Removed
p. 31
Answer ―Yes‖ if the IP Service specified in the table meets the security requirement.
Table I2: Specified IP Service IP Service:
Table I2: Specified IP Service IP Service:
Modified
p. 31 → 32
Number Description of Requirement Yes No N/A I6 The IP Service is able to ensure confidentiality, integrity, server authentication and protection against replay by using an appropriate, and declared, security protocol.
Number Description of Requirement Yes No N/A J1 The device vendor maintains guidance describing configuration management for the device.
Removed
p. 32
a) The platform vendor puts the security guidance at the disposal of internal users, and/or of application developers, system integrators and end-users of the platform.
J3 The platform vendor has put in place vulnerability disclosure measures.
a) The vulnerability disclosure measures are documented.
b) The vulnerability disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description and assessment of the vulnerabilities.
c) The vulnerability disclosure measures ensure a timely distribution of mitigation measures.
J3 The platform vendor has put in place vulnerability disclosure measures.
a) The vulnerability disclosure measures are documented.
b) The vulnerability disclosure measures ensure a timely distribution of information about newly found vulnerabilities. This information includes identification, description and assessment of the vulnerabilities.
c) The vulnerability disclosure measures ensure a timely distribution of mitigation measures.
Modified
p. 32
b) The security guidance covers the complete platform; including firmware, applications, certificates and keys.
b) The guidance covers the complete device•including firmware, payment and non-payment applications, forms, multimedia files, certificates, configuration files, configuration setting, and keys.
Modified
p. 32
c) The security guidance covers the complete life cycle of the platform from development, over manufacturing, up to delivery and operation.
c) The guidance covers the complete life cycle of the device from development, over manufacturing, up to delivery and operation.
Modified
p. 32
e) The security guidance ensures that any modification of a PTS-approved platform that impacts platform security, results in a change of the platform identifier.
e) The security guidance ensures that any modification of a PTS- approved device that impacts device security, results in a change of the device identifier.
Modified
p. 32
J2 The platform vendor has put in place security maintenance measures.
J2 The device vendor has maintenance measures in place.
Modified
p. 32
a) The security maintenance measures are documented.
a) The maintenance measures are documented.
Modified
p. 32
b) The security maintenance measures ensure timely detection of vulnerabilities that apply to the device by periodical execution of a vulnerability assessment that includes activities such as: analysis, survey of information available in the public domain, and testing.
b) The maintenance measures ensure timely detection of vulnerabilities that apply to the device by periodic execution of a vulnerability assessment that includes activities such as: analysis, survey of information available in the public domain, and testing.
Modified
p. 32
c) The security maintenance measures ensure timely assessment and classification of newly found vulnerabilities.
c) The maintenance measures ensure timely assessment and classification of newly found vulnerabilities.
Modified
p. 32
d) The security maintenance measures ensure timely creation of mitigation measures for newly found vulnerabilities that may impact platform security.
d) The maintenance measures ensure timely creation of mitigation measures for newly found vulnerabilities that may impact device security.
Removed
p. 33
a) The update mechanism ensures confidentiality, integrity, server authentication and protection against replay by using an appropriate, and declared, security protocol. If the device allows software and/or configuration updates, the device cryptographically authenticates the update and if the authenticity is not confirmed, the update is rejected and deleted.
b) The platform vendor puts the security guidance for updating deployed platforms at the disposal of application builders, system integrators and end-users of the platform.
c) The security guidance covers the update of firmware, applications, certificates and keys.
d) The security guidance describes the responsibilities of application developers, system integrators and end-users of the platform.
e) The security guidance ensures that deployed platforms are timely and securely updated.
b) The platform vendor puts the security guidance for updating deployed platforms at the disposal of application builders, system integrators and end-users of the platform.
c) The security guidance covers the update of firmware, applications, certificates and keys.
d) The security guidance describes the responsibilities of application developers, system integrators and end-users of the platform.
e) The security guidance ensures that deployed platforms are timely and securely updated.
Removed
p. 34
K3.1 Public keys must be stored and used in a manner that protects against unauthorized modification or substitution. Unauthorized modification or substitution requires an attack potential of at least 26 for identification and initial exploitation with a minimum of 13 for exploitationJ.
Modified
p. 34
Account Data Protection Number Description of Requirement Yes No N/A Generic Security Requirements K1 All account data is either encrypted immediately upon entry or entered in clear-text into a secure device and processed within the secure controller of the device.
K
• Account Data Protection Number Description of Requirement Yes No N/A Generic Security Requirements K1 All account data is either encrypted immediately upon entry or entered in clear-text into a secure device and processed within the secure controller of the device.
• Account Data Protection Number Description of Requirement Yes No N/A Generic Security Requirements K1 All account data is either encrypted immediately upon entry or entered in clear-text into a secure device and processed within the secure controller of the device.
Modified
p. 34
K1.1 The device protects all account data upon entry (consistent with A10 for magnetic stripe data and D1 for Chip data), and there is no method of accessing the clear-text account data (using methods described in A1) without defeating the security of the device. Defeating or circumventing the security mechanism requires an attack potential of at least 16 for identification and initial exploitation, with a minimum of 8 for exploitationJ.
K1.1 The device protects all account data upon entry (consistent with A9 for magnetic stripe data and D1 for Chip data), and there is no method of accessing the clear-text account data (using methods described in A1) without defeating the security of the device. Defeating or circumventing the security mechanism requires an attack potential of at least 16 for identification and initial exploitation, with a minimum of 8 for exploitationI.
Modified
p. 34
K2 The logical and physical integration of an approved secure card reader into a PIN entry POI terminal does not create new attack paths to the account data. The account data is protected (consistent with A2) from the input component to the secure controller of the device.
K2 The logical and physical integration of an approved secure card reader into a PIN entry POI terminal does not create new attack paths to the account data. The account data is protected from the input component to the secure controller of the device•i.e., it is not possible to insert a bug that would disclose sensitive data.
Modified
p. 34
K3 Determination of any cryptographic keys used for account data encryption, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 26 for identification and initial exploitation with a minimum of 13 for exploitationJ.
K3 Determination of any cryptographic keys used for account-data encryption, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 26 for identification and initial exploitation with a minimum of 13 for exploitation.I K3.1 Public keys must be stored and used in a manner that protects against unauthorized modification or substitution. Unauthorized modification or substitution requires an attack potential of at least 26 for identification and initial exploitation …
Modified
p. 34 → 35
K5 If remote key distribution is used, the device supports mutual authentication between the sending key distribution host and receiving device.
K5 If remote key distribution is used, the device supports mutual authentication between the sending key-distribution host and receiving device.
Modified
p. 34 → 35
K7 Secret and private keys which reside within the device to support account data encryption are unique per device.
K7 Secret and private keys that reside within the device to support account data encryption are unique per device.
Removed
p. 35
K11 The device performs self-tests consistent with B1.
K14 The security requirements specified in sections H and J of the Open Protocols module have been met.
K14 The security requirements specified in sections H and J of the Open Protocols module have been met.
Modified
p. 35
That it is not possible for applications to be influenced by logical anomalies which could result in clear-text data being outputted whilst the terminal is in encrypting mode.
Modified
p. 35
K13 The device’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 device outputting clear-text account data.
K13 The device’s functionality shall not be influenced by logical anomalies consistent with B2.
Modified
p. 35
K14 If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), then requirements specified in DTR Module 3: Open Protocols Requirements have been met.
Modified
p. 35 → 36
K15.1 When operating in encrypting mode, the secure controller can only release clear-text account data to authenticated applications executing within the device.
Modified
p. 35 → 36
K15.2 Account data (in either clear-text or encrypted form) shall not be retained any longer, or used more often, than strictly necessary.
Removed
p. 36
K20 If the device permits access to internal areas (e.g., for service or maintenance), it is not possible using this access area to insert a bug that would disclose any secret or private keys or account data. Immediate access to secret or private keys or account data is either prevented by the design of the internal areas (e.g., by enclosing components with such data into tamper-resistant/responsive enclosures), and/or it has a mechanism so that accessing internal areas causes the immediate erasure of secret and private keys and account data.
K23 The following features of the device’s operating system must be in place: The operating system of the device must contain only the software (components and services) necessary for the intended operation. The operating system must be configured securely and run with least privilege. The security policy enforced by the device must not allow unauthorized or unnecessary functions. …
K23 The following features of the device’s operating system must be in place: The operating system of the device must contain only the software (components and services) necessary for the intended operation. The operating system must be configured securely and run with least privilege. The security policy enforced by the device must not allow unauthorized or unnecessary functions. …
Modified
p. 36
K16.1 If using a hash function to generate surrogate PAN values, input to the hash function must use a salt with minimum length of 64 bits.
Modified
p. 36
K16.2 If using a hash function to generate surrogate PAN values, the salt is kept secret and appropriately protected. Disclosure of the salt cannot occur without requiring an attack potential of at least 16 per device for identification and initial exploitation with a minimum of 8 for exploitationJ.
Modified
p. 36
K17 The key-management techniques implemented in the device are consistent with B11.
Modified
p. 36
K18 The device has characteristics that prevent or significantly deter the use of the device for exhaustive PAN determination.
Modified
p. 36
K19 Environmental or operational conditions cannot be altered to compromise the security of the device, or cause the device to output clear-text account data.
Modified
p. 36
J As defined in Appendix B of the PCI PTS POI DTRs.
Modified
p. 37
K23 Sensitive services are protected from unauthorized use consistent with B8.
Removed
p. 38
Number Description of Requirement Yes No N/A L1 Change-control procedures are in place so that any intended security- relevant change to the physical or functional capabilities of the device causes a re-certification of the device under the Core PIN Entry and/or POS Terminal Integration Security Requirements of this document.
Modified
p. 38
Note: In the following requirements, the device under evaluation is referred as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories do not currently validate this information; however, the vendor is still required to complete these forms and the information will be reported to PCI for review and, if necessary, corrective action:
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews. Any variances to these requirements will be reported to PCI for review. However, this information will only be used for analyses at this time and will not impact whether a device receives an approval. Site inspections shall not begin until subsequent …
Modified
p. 38
L2 The certified firmware is protected and stored in such a manner as to preclude unauthorized modification, e.g., using dual control or standardized cryptographic authentication procedures.
L2 The certified firmware is protected and stored in such a manner as to preclude unauthorized modification during its entire manufacturing life cycle•e.g., by using dual control or standardized cryptographic authentication procedures.
Modified
p. 38
L4 Production software that is loaded to devices at the time of manufacture is transported, stored, and used under the principle of dual control, preventing unauthorized modifications and/or substitutions.
L4 Production software (e.g., firmware) that is loaded to devices at the time of manufacture is transported, stored, and used under the principle of dual control, preventing unauthorized modifications and/or substitutions.
Modified
p. 38
L5 Subsequent to production but prior to shipment from the manufacturer’s facility, the device and any of its components are stored in a protected, access-controlled area or sealed within tamper- evident packaging to prevent undetected unauthorized access to the device or its components.
L5 Subsequent to production but prior to shipment from the manufacturer’s or reseller’s facility, the device and any of its components are stored in a protected, access-controlled area or sealed within tamper-evident packaging to prevent undetected unauthorized access to the device or its components.
Modified
p. 39
L8 Controls exist over the repair process and the inspection/testing process subsequent to repair to ensure that the device has not been subject to unauthorized modification.
L8 Controls exist over the repair process, including the resetting of tamper mechanisms, and the inspection/testing process subsequent to repair to ensure that the device has not been subject to unauthorized modification.
Removed
p. 40
Number Description of Requirement Yes No N/A M1 The device is shipped from the manufacturer’s facility to the initial key-loading facility, and stored en route, under auditable controls that can account for the location of every PED at every point in time.
M2 Procedures are in place to transfer accountability for the device from the manufacturer to the initial key-loading facility.
M2 Procedures are in place to transfer accountability for the device from the manufacturer to the initial key-loading facility.
Modified
p. 40
Note: In the following requirements, the device under evaluation is referred as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories do not currently validate this information; however, the vendor is still required to complete these forms and the information will be reported to PCI for review, and if necessary corrective action.
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories do not currently validate this information; however, the vendor is still required to complete these forms and the information will be reported to PCI for review, and if necessary corrective action. Site inspections shall not begin until subsequent to the publication of POI v5.
Modified
p. 40
M4 The development security documentation must provide means to the initial key-loading facility to assure the authenticity of the TOE security relevant components.
M4 The device’s development-security documentation must provide means to the initial key-loading facility to assure the authenticity of the TOE’s security relevant components.
Modified
p. 42 → 43
Model Name and Number: I, (Name) Am an officer of the above company, authorized to verify compliance of the referenced equipment. Am an officer of the designated laboratory, authorized by the manufacturer to verify compliance of the referenced equipment.
Model Name and Number: I, (Name) Am an officer of the above company, authorized to verify compliance of the referenced equipment.
Modified
p. 42 → 43
Not in full compliance with the standards set forth above in the Manufacturer Self-Assessment Form as indicated in the attached Exception Form (Form C).
Modified
p. 42 → 43
Signature Date Printed Name Title Attach to this form a device-specification sheet that highlights the device characteristics, including a photo of the device. These photos are to include both external and internal pictures of the device. The internal pictures are to be sufficient to show the various components of the device.
Signature Date Printed Name Title Attach to this form a device-specification sheet that highlights the device characteristics, including photos of the device. These photos are to include both external and internal pictures of the device. The internal pictures are to be sufficient to show the various components of the device.
Modified
p. 44 → 45
Card Reader This functionality applies whenever a device under evaluation has the capability to capture card data, irrespective of the technology being used (i.e., it encompasses both the magnetic stripe and smart card readers).
Card Reader This functionality applies whenever a device under evaluation has the capability to capture card data, irrespective of the technology being used (i.e., it encompasses both the magnetic stripe and smart card readers). This is further broken down into ICCR and MSR functionality.
Modified
p. 44 → 45
Terminal is a module If the device under evaluation is designed to be integrated into equipment, then it applies for ―terminal is a module‖ functionality. Modules are also referred as OEM equipment.
Terminal is a module If the device under evaluation is designed to be integrated into equipment, then it applies for “terminal is a module” functionality. Modules are also referred to as OEM equipment.
Modified
p. 44 → 45
Terminal is compound A device under evaluation is said to be compound whenever it incorporates one or more modules, in order to cover one or several of the aforementioned functionalities. Being a compound device does not preclude the applicability of ―terminal is a module‖ functionality. Both functionalities are independent.
Terminal is compound A device under evaluation is said to be compound whenever it incorporates one or more modules, in order to cover one or several of the aforementioned functionalities. Being a compound device does not preclude the applicability of “terminal is a module” functionality. Both functionalities are independent.
Modified
p. 45 → 46
2. For each of the supported functionalities, report any marking ―x‖ from the functionality column to the baseline column. ―x‖ stands for ―applicable,‖ in which case the requirement must be considered for vendor questionnaire and possibly evaluation.
2. For each of the supported functionalities, report any marking “x” from the functionality column to the baseline column. “x” stands for “applicable,” in which case the requirement must be considered for vendor questionnaire and possibly evaluation.
Removed
p. 49
Hashing A (mathematical) function, which is a non-secret algorithm that takes any arbitrary length message as input and produces a fixed length hash result. It must have the property that it is computationally infeasible to discover two messages that produce the same hash result. It may be used to reduce a potentially long message into a ―hash value‖ or ―message digest‖. A ―good‖ hash is such that the results of applying the function to a (large) set of values in a given domain will be evenly (and randomly) distributed over a smaller range.
Modified
p. 49 → 52
Evaluation Laboratory Independent entity that performs a security evaluation of the POS terminal against the PCI Security Requirements.
Modified
p. 49 → 52
Evaluation Module Evaluation package corresponding to a well defined set of requirements.
Evaluation Module Evaluation package corresponding to a well-defined set of requirements.
Modified
p. 49 → 52
Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware.
Modified
p. 49 → 54
Key-encrypting (encipherment or exchange) key (KEK) A cryptographic key that is used for the encryption or decryption of other keys.
Key-encrypting (encipherment or exchange) Key (KEK) A cryptographic key that is used for the encryption or decryption of other keys.
Modified
p. 49 → 55
Key variant A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key.
Key Usage Employment of a key for the cryptographic purpose for which it was intended Key variant A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key.
Modified
p. 50 → 56
Point of Interaction (POI) An electronic-transaction-acceptance product. A POI consists of hardware and software and is hosted in an acceptance equipment to enable a cardholder to perform a card transaction. Thereby the POI may be attended or unattended. POI transactions are IC and/or magnetic-stripe card-based payment transactions. For these requirements, a POI device is a PIN- acceptance device.
Point of Interaction (POI) An electronic-transaction-acceptance product. A POI consists of hardware and software and is hosted in acceptance equipment to enable a cardholder to perform a card transaction. Thereby the POI may be attended or unattended. POI transactions include IC, magnetic-stripe, and contactless payment card-based payment transactions.
Modified
p. 50 → 56
POS POI Terminal A general description of any terminal used to perform a card-based payment transaction when a PIN is required to confirm cardholder authentication.
POS POI Terminal A general description of any terminal used to perform a card-based payment transaction. This may or may not require a PIN to confirm cardholder authentication.
Modified
p. 50 → 58
Secure Components (for POI Terminals) Products which incorporate security mechanisms for PIN and account data handling and processing, and require integration into a complete terminal, such as OEM PIN entry devices and IC card readers.
Secret Share See Key (Secret) Share Secure Components (for POI Terminals) Products which incorporate security mechanisms for PIN and account data handling and processing, and require integration into a complete terminal, such as OEM PIN entry devices and IC card readers.
Modified
p. 50 → 58
Sensitive Authentication Data Security-related information (card validation codes/values, full track data from the magnetic stripe, magnetic-stripe image on the chip or elsewhere, PINs, and PIN blocks) used to authenticate cardholders, appearing in plaintext or otherwise unprotected form.
Modified
p. 50 → 59
Service Module A module providing for non-cardholder activities and oriented towards service or maintenance related functions and may consist of: A service keyboard (SK), A service display (SD), and A service data exchange support (SDE), which may consist of a card reader, a floppy disk drive, a USB interface or the like.
Service Module A module providing for non-cardholder activities and oriented towards service or maintenance related functions and may consist of:
Modified
p. 50 → 59
Surrogate PAN A unique, non-PCI relevant replacement value for a PAN. It must not be possible (except by chance) to recover the original PAN knowing only the surrogate value.
SSL Secure Sockets Layer Surrogate PAN A unique, non-PCI relevant replacement value for a PAN. It must not be possible (except by chance) to recover the original PAN knowing only the surrogate value.
Modified
p. 51 → 60
Automated fuel dispensers Kiosks Self-service devices
• ticketing/vending or car parking terminals
• ticketing/vending or car parking terminals
Automated fuel dispensers Self-service devices
• ticketing/vending or car parking terminals Unprotected Memory Data retained within components, devices, and recording media that reside outside the cryptographic boundary of a secure cryptographic device.
• ticketing/vending or car parking terminals Unprotected Memory Data retained within components, devices, and recording media that reside outside the cryptographic boundary of a secure cryptographic device.