Document Comparison
PCI_PTS_POI_SRs_v6.2.pdf
→
PCI_PTS_POI_SRs_v7.0.pdf
81% similar
55 → 58
Pages
16451 → 17166
Words
162
Content Changes
Content Changes
162 content changes. 73 administrative changes (dates, page numbers) hidden.
Added
p. 5
• Cryptography used for device security purposes implements an effective key strength of 128 bits or stronger.
• Modified non-invasive attacks for cryptographic keys, to include an attack potential for both PIN and account-data protection keys.
• Added new requirement for biometric readers.
• Added new requirement for third-party applications.
• Specification that the operating system must implement mandatory access controls in an enforcing mode.
• Specification that if a device implements an IP stack, it must support TLS 1.3 or higher.
• Modified non-invasive attacks for cryptographic keys, to include an attack potential for both PIN and account-data protection keys.
• Added new requirement for biometric readers.
• Added new requirement for third-party applications.
• Specification that the operating system must implement mandatory access controls in an enforcing mode.
• Specification that if a device implements an IP stack, it must support TLS 1.3 or higher.
Added
p. 9
For security-related positions, all options must be exhaustively defined.Device Details (continued) Validation modules required (where applicable, please see Yes No N/A * Fields marked with an asterisk (*) will be used in the PCI SSC Approved PIN Transaction Security Devices List. A See “Details of the Use of Variables in the Identifier,” page 8.
Added
p. 15
4: Life Cycle Device management During Manufacturing, and Between Manufacturer and Facility of Initial Key Loading or Facility of Initial Deployment Life cycle requirements for POIs and their components up until the point of initial key loading. The PCI test laboratories will validate this information via documentation reviews and by means of evidence that procedures are properly implemented and used.
Added
p. 20
B2.1 The firmware must enforce the authentication of payment applications loaded onto the terminal security processor and must support authentication of applications loaded onto the application processors for non-third-party applications, consistent with Requirement B2.
• Compliant signatures are generated and attached to all non-third- party executable files.
B2.3 Third-party applications must not be able to be loaded or executed in execution environments that have access to cleartext account data.
Third-party applications must be signed.
B15 Cryptographic mechanisms must exist to ensure the authenticity and proper use of the display, and that modification of the prompts or improper use of the device display is prevented.
Cleartext account data must never be available to execution environments that are able to execute third-party applications, even through the use of whitelists.
Devices supporting third-party applications must not pass cleartext account data to the execution environment executing the third-party application, even through the use of whitelists.
• Compliant signatures are generated and attached to all non-third- party executable files.
B2.3 Third-party applications must not be able to be loaded or executed in execution environments that have access to cleartext account data.
Third-party applications must be signed.
B15 Cryptographic mechanisms must exist to ensure the authenticity and proper use of the display, and that modification of the prompts or improper use of the device display is prevented.
Cleartext account data must never be available to execution environments that are able to execute third-party applications, even through the use of whitelists.
Devices supporting third-party applications must not pass cleartext account data to the execution environment executing the third-party application, even through the use of whitelists.
Added
p. 38
Biometric Sensor The device subcomponent(s) that take the analog biometric data and convert this into a digitized form. This includes camera and fingerprint sensors.
Added
p. 45
1. Payment application that is used to accept payments (B2.1);
2. Application used as part of firmware⎯i.e., bootcode, IP stack, etc.;
3. Third-party application unrelated to payments.
Biometric Reader A device that includes one or more biometric sensors.
Biometric Sensor The device subcomponents that perform the capture and digitization of the biometric data. Examples include a fingerprint reader module or camera module Certificate For purposes of these requirements, a certificate is any digitally signed value containing a public key, signed with a key by a trusted entity/certification authority.
Cryptographic Key (Key) A parameter used in conjunction with a cryptographic algorithm that determines:
• The transformation of cleartext data into ciphertext data,
• The transformation of ciphertext data into cleartext data,
• A digital signature computed from data,
• The verification of a digital signature computed from data,
• An authentication code computed from data, or
• An exchange agreement of a shared secret.
Dual Control A process of utilizing two or more …
2. Application used as part of firmware⎯i.e., bootcode, IP stack, etc.;
3. Third-party application unrelated to payments.
Biometric Reader A device that includes one or more biometric sensors.
Biometric Sensor The device subcomponents that perform the capture and digitization of the biometric data. Examples include a fingerprint reader module or camera module Certificate For purposes of these requirements, a certificate is any digitally signed value containing a public key, signed with a key by a trusted entity/certification authority.
Cryptographic Key (Key) A parameter used in conjunction with a cryptographic algorithm that determines:
• The transformation of cleartext data into ciphertext data,
• The transformation of ciphertext data into cleartext data,
• A digital signature computed from data,
• The verification of a digital signature computed from data,
• An authentication code computed from data, or
• An exchange agreement of a shared secret.
Dual Control A process of utilizing two or more …
Added
p. 48
External Memory External memory is memory where cleartext keys are exposed outside of the die of the processing element, including on multi-die BGA packages.
Format-preserving Encryption (FPE) Format-preserving encryption encrypts a cleartext of some specified format into ciphertext of the same format.
Hardware-Management Device (HMD) A non-SCD device used to provide cryptographic services, but which requires usage restrictions and additional controls to address inherent security limitations. Examples of HMDs include, but are not limited to:
1. Smart cards used for components that share transport or storage
2. Smart cards containing public/private key pair(s) used to facilitate management of Hardware Security Modules (HSMs)
Key Management The activities involving the handling of cryptographic keys and other related security parameters⎯e.g., initialization vectors, counters⎯during the entire life cycle of the keys, including their generation, storage, distribution, loading, use, deletion, destruction, and archiving.
Key Usage Employment of a key for the cryptographic purpose for which it was intended.
Format-preserving Encryption (FPE) Format-preserving encryption encrypts a cleartext of some specified format into ciphertext of the same format.
Hardware-Management Device (HMD) A non-SCD device used to provide cryptographic services, but which requires usage restrictions and additional controls to address inherent security limitations. Examples of HMDs include, but are not limited to:
1. Smart cards used for components that share transport or storage
2. Smart cards containing public/private key pair(s) used to facilitate management of Hardware Security Modules (HSMs)
Key Management The activities involving the handling of cryptographic keys and other related security parameters⎯e.g., initialization vectors, counters⎯during the entire life cycle of the keys, including their generation, storage, distribution, loading, use, deletion, destruction, and archiving.
Key Usage Employment of a key for the cryptographic purpose for which it was intended.
Added
p. 54
RNG Random-number generator.
ROM Read-only memory.
Secure Components (for POI Terminals) Products that incorporate security mechanisms for PIN and accountdata handling and processing, and require integration into a complete terminal, such as OEM PIN entry devices and IC card readers.
Secure Memory Secure memory is memory that is protected to a certain attack potential. For cryptographic keys that require at least 35 points, that would include security processor memory, memory encrypted by the security processor, and memory that is physically protected (e.g., by tamper grids, if they meet the right attack potential).
• The cardholder PIN,
• Biometric data used in connection with Requirement A15,
• All secret-keying material,
• Design characteristics,
• Status information, and
• Other functions that allow access to secure areas within the terminal.
ROM Read-only memory.
Secure Components (for POI Terminals) Products that incorporate security mechanisms for PIN and accountdata handling and processing, and require integration into a complete terminal, such as OEM PIN entry devices and IC card readers.
Secure Memory Secure memory is memory that is protected to a certain attack potential. For cryptographic keys that require at least 35 points, that would include security processor memory, memory encrypted by the security processor, and memory that is physically protected (e.g., by tamper grids, if they meet the right attack potential).
• The cardholder PIN,
• Biometric data used in connection with Requirement A15,
• All secret-keying material,
• Design characteristics,
• Status information, and
• Other functions that allow access to secure areas within the terminal.
Added
p. 56
Split Knowledge A condition under which two or more entities have separate information⎯e.g., key components⎯that individually convey no knowledge of the resultant combined information⎯e.g., a cryptographic key.
SSL Secure Sockets Layer.
Third-party applications An application that is restricted by the POI to operate in either a non-secure processor or in an isolated memory-space (i.e., virtual machine), segmenting the application from access to both input channels and plaintext sensitive data. Such applications are permitted to use output channels (e.g., an advertising application showing videos on a display) for cardholder engagement.
These applications are not signed in accordance with Requirement B2.2.
TLS Transport Layer Security.
TOE Target of Evaluation.
SSL Secure Sockets Layer.
Third-party applications An application that is restricted by the POI to operate in either a non-secure processor or in an isolated memory-space (i.e., virtual machine), segmenting the application from access to both input channels and plaintext sensitive data. Such applications are permitted to use output channels (e.g., an advertising application showing videos on a display) for cardholder engagement.
These applications are not signed in accordance with Requirement B2.2.
TLS Transport Layer Security.
TOE Target of Evaluation.
Modified
p. 2
July 2015 4.1a Updates for errata and new core section J.
July 2015 4.1a Updates for errata and new core Section J.
Removed
p. 4
This version 6 additionally provides for:
• The restructuring of the modules into:
• The addition of new appendices in the Derived Test Requirements for:
• Domain-Based Asset Flow Analysis
• Evaluation Guidance for CPUs
• The migration of technical FAQs into either the Derived Test Requirements or the Device Testing and Approval Program Guide.
• The restructuring of the modules into:
• The addition of new appendices in the Derived Test Requirements for:
• Domain-Based Asset Flow Analysis
• Evaluation Guidance for CPUs
• The migration of technical FAQs into either the Derived Test Requirements or the Device Testing and Approval Program Guide.
Modified
p. 4
• Non-PIN acceptance POI devices evaluated for account data protection.
• Non-PIN acceptance POI devices evaluated for account-data protection.
Modified
p. 4
• Secure components for POS terminals: These products also require integration into a final solution to provide PIN transactions. Examples are OEM PIN entry devices, secure (encrypting) card readers (SCRs), and secure card readers
• Secure components for POS terminals: These products also require integration into a final solution to provide PIN transactions. Examples are Original Equipment Manufacturer (OEM) PIN entry devices, secure (encrypting) card readers (SCRs), and secure card readers
Removed
p. 5
• Restructured modules into Physical, Logical, Communications and Interfaces, and Life Cycle while retaining the Integration Module.
• POI v6 firmware expires three years from the date of approval but shall not expire past the overall approval expiration of the device.
• POI v6 chipsets must provide support for ECC.
• Eliminated Removal Detection Requirements.
• Split requirement A1 into two separate requirements: 1) Tamper Detection Mechanisms 2) Protection of Sensitive Keypad Inputs.
• Split requirement A6 into two separate requirements: 1) Invasive Attacks for Cryptographic Keys 2) Non-invasive Attacks for Cryptographic Keys.
• Allow the inclusion of MSRs in SCRPs for use in SPoC solutions.
• Added tracking of Key Management for Account Data Encryption.
• POI v6 firmware expires three years from the date of approval but shall not expire past the overall approval expiration of the device.
• POI v6 chipsets must provide support for ECC.
• Eliminated Removal Detection Requirements.
• Split requirement A1 into two separate requirements: 1) Tamper Detection Mechanisms 2) Protection of Sensitive Keypad Inputs.
• Split requirement A6 into two separate requirements: 1) Invasive Attacks for Cryptographic Keys 2) Non-invasive Attacks for Cryptographic Keys.
• Allow the inclusion of MSRs in SCRPs for use in SPoC solutions.
• Added tracking of Key Management for Account Data Encryption.
Modified
p. 6
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 cleartext PIN-encryption key.
Modified
p. 6
The evaluation of physical security characteristics is relative to attack potential. Virtually any physical barrier can be defeated with sufficient time and effort. Therefore, many of the requirements have minimum attack calculation values for the identification and initial exploitation of the device based upon factors such as attack time, expertise, and equipment required. Given the evolution of attack techniques and technology, PCI will periodically review these amounts for appropriateness.
The evaluation of physical security characteristics is relative to attack potential. Virtually any physical barrier can be defeated with sufficient time and effort. Therefore, many of the requirements have minimum attack calculation values for the identification and initial exploitation of the device based upon factors such as attack time, expertise, and equipment required. Given the evolution of attack techniques and technology, the PCI will periodically review these amounts for appropriateness.
Modified
p. 6
• In modular approvals, where a PIN entry device may be approved taking in consideration previously approved components.
• In modular approvals, where a PIN entry device may be approved, taking into consideration previously approved components.
Removed
p. 7
Note: ASC X9 TR 31: Interoperable Secure Key Exchange Key Block Specification has been classified as ‘historical’ by ANSI and X9.143 Retail Financial Services: Interoperable Secure Key Block Specification is the newer version. All references to TR-31 are updated to X9.143.
Modified
p. 8
• Part 5: Identity Based Ciphers ISO/IEC 18033-5 Guidelines on Triple DES Modes of Operation ISO TR 19038 Banking and related financial services − Key wrap using AES ISO 20038 Guideline for Implementing Cryptography in the Federal Government NIST SP 800-21 A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST SP 800-22 Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication NIST SP 800-38B Recommendation for Key Management, Part 1: General NIST …
• Part 5: Identity Based Ciphers ISO/IEC 18033-5 Guidelines on Triple DES Modes of Operation ISO TR 19038 Banking and related financial services − Key wrap using AES ISO 20038 Guideline for Implementing Cryptography in the Federal Government NIST SP 800-21 A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST SP 800-22 Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication NIST SP 800-38B Recommendation for Key Management, Part 1: General NIST …
Removed
p. 9
* 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,” page 8.
A See “Optional Use of Variables in the Identifier,” page 8.
Modified
p. 9
Application Version Number*: (if applicable) Version of PCI PTS POI Security Requirements: v6 FAQ version:
Application Version Number*: (if applicable) Version of PCI PTS POI Security Requirements: V7 FAQ version:
Modified
p. 10
Integration Communications and Interfaces Life Cycle Always Applicable Previously Approved Components Used* (if applicable) Vendor Name Device Marketing/Model
Modified
p. 10
PCI SSC Website Other Device Photos Photo(s) of device or component (if applicable) * * Photos must show information for a Device Form Factor as noted in the Program Guide Please attach a photo(s) of the terminal under evaluation, 320x320 pixels.
PCI SSC Website Other Device Photos Photo(s) of device or component (if applicable) ** ** Photos must show information for a Device Form Factor as noted in the Program Guide. Please attach a photo(s) of the terminal under evaluation, 320x320 pixels.
Modified
p. 11
Note: The firmware version number may also be subject to the use of variables in a manner consistent with hardware version numbers. See the PCI PTS Testing and Approval Program Guide for more information.
Note: The firmware version number may also be subject to the use of variables in a manner consistent with hardware version numbers. See the PCI PTS Device Testing and Approval Program Guide for more information.
Removed
p. 15
4: Life Cycle Device Management (Manufacturing and initial key loading) Life cycle requirements for POIs and their components up until the point of initial key loading. The information is not currently validated but is still required for vendors to complete.
Modified
p. 15
Evaluation Module Requirements Set Remarks 1: Physical and Logical Requirements Physical and Logical Security The logical and physical requirements of 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.
Evaluation Module Requirements Set Remarks 1: Physical and Logical Requirements Physical and Logical Security The logical and physical requirements of POI devices.
Modified
p. 15
However, it 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.
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 process of integrated PIN entry devices.
Modified
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.
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.
Modified
p. 15
This module includes security management requirements applicable to the integrated device.
This module includes security-management requirements applicable to the integrated device.
Modified
p. 15
3: Communications and Interfaces All Protocols and all interfaces on the device A set of requirements that ensures POI devices using communication protocols and interfaces are secure, including determination that those using open security protocols and open communication protocols to access public networks and services do not have public domain vulnerabilities.
3: Communications and Interfaces All protocols and all interfaces on the device A set of requirements that ensures POI devices using communication protocols and interfaces are secure, including determination that those using open security protocols and open communication protocols to access public networks and services do not have public domain vulnerabilities.
Modified
p. 15
An “N/A” response to a requirement is acceptable in two cases:
An “N/A” response to a requirement is acceptable in either of two cases:
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 results 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 …
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 impractical to recover the sensitive data. These mechanisms protect against physical penetration of the device by means of (but not …
Modified
p. 16
Keypads used for PIN entry require an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for initial exploitation, exclusive of the IC card reader, as defined in Appendix B.
Keypads used for PIN entry require an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for initial exploitation, exclusive of the integrated circuit (IC) card reader.
Modified
p. 16
• Environmental conditions
• Environmental conditions, nor
Modified
p. 16
• Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) A4 Sensitive functions or data are only used in the protected area(s) of the device. Sensitive data and functions dealing with sensitive data are protected from unauthorized modification without requiring an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for initial exploitation, exclusive of the IC card reader, for identification and initial exploitation.B …
• Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) A4 Sensitive functions or data are only used in the protected area(s) of the device. Sensitive data, and functions dealing with sensitive data, are protected from unauthorized modification without requiring an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for initial exploitation, exclusive of the IC card reader or the biometric reader, for …
Removed
p. 17
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 initial exploitation.C A9 The device provides a means to deter the visual observation of PIN values as they are being entered by the cardholder.
Modified
p. 18
A11 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.
A11 All account data is either encrypted immediately upon entry or entered in cleartext into a secure device and processed within the secure controller of the device.
Modified
p. 18
A12 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.
A12 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 by the secure controller of the device•i.e., it is not possible to insert a bug that would disclose sensitive data.
Modified
p. 18
A13 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 initial exploitation,D nor is it possible for both an IC card and any other foreign object to reside within the card-insertion slot.
A13 It is neither practical 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 initial exploitation,D nor is it possible for both an IC card and any other foreign object to reside within the card-insertion slot simultaneously.
Removed
p. 19
B2.1 The firmware must support the authentication of applications loaded onto the terminal consistent with B2.
• All executable files are signed.
• All executable files are signed.
Modified
p. 19 → 20
B2.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:
B2.2 The vendor must provide a defined and documented process containing specific details on how any signing mechanisms used for meeting Requirements B2 and B2.1 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:
Modified
p. 19 → 20
• Software is only signed using a secure cryptographic device⎯e.g., smartcard⎯provided by the terminal vendor.
• Software is only signed using a secure cryptographic device or hardware-management devices (HMDs)⎯e.g., smartcards⎯provided by the terminal vendor.
Modified
p. 19 → 20
B3 The device never displays the entered PIN digits. Any array related to PIN entry displays only non-significant symbols⎯e.g., asterisks. 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.
B3 The device neither displays nor otherwise provides an indication of the value of the entered PIN digits. Any array related to PIN entry displays only non-significant symbols⎯e.g., asterisks. 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.
Modified
p. 19 → 21
The device must automatically clear its internal buffers of full track data (or chip equivalent) and sensitive authentication data is cleared when either:
The device must automatically clear its internal buffers of full track data (or chip equivalent), and sensitive authentication data is cleared when either:
Modified
p. 20 → 21
B7 If random numbers are generated by the device in connection with security over sensitive data, the random number generator has been assessed to ensure it is generating numbers sufficiently unpredictable.
B7 If random numbers are generated by the device in connection with security over sensitive data, the random-number generator has been assessed to ensure it is generating numbers that are sufficiently unpredictable.
Modified
p. 20 → 21
B10 All account data shall be encrypted using only ANSI X9 or ISO- approved encryption algorithms⎯e.g., AES, TDES⎯and should use ANSI X9 or ISO-approved modes of operation.
B10 All account data shall be encrypted using only ANSI X9 or ISO- approved encryption algorithms (for example, AES, TDES) and should use ANSI X9 or ISO-approved modes of operation.
Modified
p. 20 → 21
B12 It is not possible to encrypt or decrypt any arbitrary data using any PIN- encrypting key, account data encryption, data-encrypting key, or key- encrypting key contained in the device.
B12 It is not possible to encrypt or decrypt any arbitrary data using any PIN- encrypting key, account-data encryption, data-encrypting key, or key- encrypting key contained in the device.
Modified
p. 20 → 21
The device must enforce that PIN encryption, account data encryption, data-encryption keys, and key-encipherment keys have different values.
The device must enforce that PIN encryption, account-data encryption, data-encryption keys, and key-encipherment keys have different values.
Removed
p. 21
B15 All prompts for non-PIN data entry are under the control of the cryptographic unit of the device. 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 outside the cryptographic unit, cryptographic mechanisms must exist to ensure the authenticity and the proper use of the prompts, and that modification of the prompts or improper use of the prompts is prevented.
Modified
p. 21 → 22
B16 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 either another application or the OS.
B16 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 → 22
B16.2 The vendor must provide clear security guidance consistent with D2 and B4 to all application developers to ensure:
B16.2 The vendor must provide clear security guidance consistent with Requirements D2 and B4 to all application developers to ensure:
Modified
p. 21 → 22
• That it is not possible for applications to be influenced by logical anomalies which could result in clear-text data being outputted while the terminal is in encrypting mode. • That account data is not retained any longer, or used more often, than strictly necessary.
• That SRED functions, where provided, are correctly implemented.
• That SRED functions, where provided, are correctly implemented.
• That it is not possible for applications to be influenced by logical anomalies that could result in cleartext data being outputted while the terminal is in encrypting mode.
Modified
p. 22 → 23
Note: Regardless of integration, both enciphered and clear-text PINs must be provided for.
Note: Regardless of integration, both enciphered and cleartext PINs must be provided for.
Modified
p. 22 → 23
• A clear-text 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 clear text to the IC card) in accordance with ISO 9564.
• A cleartext 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 cleartext to the IC card) in accordance with ISO 9564.
Modified
p. 22 → 23
• A clear-text PIN, encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the clear-text PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.
• A cleartext PIN, encipherment is not required if the PIN block is transmitted wholly through a protected environment (as defined in ISO 9564). If the cleartext PIN is transmitted to the ICC reader through an unprotected environment, the PIN block shall be enciphered in accordance with ISO 9564.
Removed
p. 23
• Input to the hash function must use a salt with minimum length of 64 bits.
• The salt is kept secret and appropriately protected.
• Disclosure of the salt cannot occur without requiring an attack potential of at least 16 per device for identification and initial exploitation with a minimum of 8 for initial exploitation, as defined in Appendix B.
• 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 initial exploitation, as defined in Appendix B.
Modified
p. 23 → 24
B23.1 When operating in encrypting mode, the secure controller can only release clear-text account data to authenticated applications executing within the device.
B23.1 When operating in encrypting mode, the security processor can only release cleartext account data (excluding PINs) to applications authenticated under the requirements of B2.1.
Modified
p. 23 → 24
If the device is capable of generating surrogate PAN values to be outputted outside of the device, it is not possible to determine the original PAN knowing only the surrogate value. Where a hash function is used to generate surrogate PAN values:
If the device is capable of generating surrogate PAN values to be outputted outside of the device, it is not possible to determine the original PAN knowing only the surrogate value. Where a hash function is used to generate surrogate PAN values, a keyed-hash function must be implemented.
Modified
p. 23 → 24
B26 Secure enablement tokens are required from the attestation and monitoring system for the SCRP to accept and/or process payments. .
B26 Secure enablement tokens are required from the attestation and monitoring system for the SCRP to accept and/or process payments.
Modified
p. 24 → 25
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.
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.
Modified
p. 24 → 25
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.
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 → 25
This module includes security management requirements applicable to the integrated device and is applicable anytime previously approved components are combined that will result in a device meeting a PTS approval class.
This module includes security-management requirements applicable to the integrated device and is applicable anytime previously-approved components are combined that will result in a device meeting a PTS approval class.
Modified
p. 25 → 26
The alteration of the correspondence between the display messages visible to the cardholder and the operating state of the PIN entry device cannot occur without requiring an attack potential of at least 18 per POI for identification and initial exploitation with a minimum of 9 for initial exploitationF.
The alteration of the correspondence between the display messages visible to the cardholder and the operating state of the PIN entry device cannot occur without requiring an attack potential of at least 18 per POI for identification and initial exploitation, with a minimum of 9 for initial exploitationF.
Modified
p. 25 → 26
C2.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 B15.
C2.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 Requirement B15.
Modified
p. 26 → 27
D2 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 the clear-text PIN or other sensitive data.
D2 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 the cleartext PIN or other sensitive data.
Modified
p. 26 → 27
D3 The device has security guidance that describes how protocols and services must be used for each interface that is accessible by the device applications.
D3 The device has security guidance that describes how protocols and interfaces must be used for each interface that is accessible by the device applications.
Modified
p. 26 → 27
D4 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 be configured with secure default settings.
D4 The device has guidance that describes the default configuration for each protocol relevant to each interface that is available on the device. Each interface and protocol on the device should be configured with secure default settings.
Modified
p. 26 → 27
d) Key-management security guidance ensures secure use of keys and certificates, including certificate status ⎯e.g., revoked ⎯secure download, and roll-over of keys.
d) Key-management security guidance ensures secure use of keys and certificates, including certificate status⎯e.g., revoked ⎯secure download, and roll-over of keys.
Modified
p. 26 → 27
D6 The device has all the security protocols that are available on the device clearly identified in the Open Protocols
• Protocol Declaration Form. The device vendor provides documentation that describes the implementation and use of the security protocols that are available on the device.
• Protocol Declaration Form. The device vendor provides documentation that describes the implementation and use of the security protocols that are available on the device.
D6 The device has all the security protocols that are available on the device clearly identified in the Open Protocols Module
• Protocol Declaration Form. The device vendor provides documentation that describes the implementation and use of the security protocols that are available on the device.
• Protocol Declaration Form. The device vendor provides documentation that describes the implementation and use of the security protocols that are available on the device.
Modified
p. 27 → 28
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).
b) Encryption is provided by using keys that are established in a secure manner using appropriate key-management procedures, such as those listed in NIST SP800-21, Guideline for Implementing Cryptography in the Federal Government, and ISO 11568 Banking
• Key Management (Retail).
• Key Management (Retail).
Modified
p. 27 → 28
D8 As defined in the asset flow diagrams, the device is able to provide the integrity of data that is sent over a network connection.
D8 As defined in the Asset Flow Analysis, the device is able to provide the integrity of data that is sent or received over a network connection.
Modified
p. 27 → 28
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, or SHA-512.
Modified
p. 27 → 28
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, or SHA-512.
Modified
p. 27 → 28
D9 As defined in the asset flow diagrams, the device uses a declared security protocol to authenticate the server.
D9 As defined in the Asset Flow Analysis, the device uses a declared security protocol and supports mutual authentication.
Modified
p. 27 → 28
a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question.
a) Server authentication utilizes key sizes appropriate for the algorithm(s) in question, as denoted in Appendix E of the PCI PTS POI DTRs.
Modified
p. 27 → 28
e) The device’s trusted root certificate store shall contain only public key certificates from trusted CAs or else self-signed certificates verified by the acquirer.
e) The device’s trusted root certificate store shall contain only public-key certificates from trusted CAs or else self-signed certificates verified by the acquirer.
Modified
p. 27 → 28
D10 As defined in the asset flow diagrams, the device is able to detect replay of messages and enables the secure handling of the exceptions.
D10 As defined in the Asset Flow Analysis, the device is able to detect replay of messages and enables the secure handling of the exceptions.
Modified
p. 28 → 29
Note: If Bluetooth is used, D14 may alternatively be used.
Note: If Bluetooth is used, Requirement D14 may alternatively be used.
Modified
p. 28 → 29
Note: If Wi-Fi is used, D14 may alternatively be used.
Note: If Wi-Fi is used, Requirement D14 may alternatively be used.
Modified
p. 28 → 29
D14 Wireless communication interfaces which do not have specific security requirements, or have not met those requirements as listed, must be physically or cryptographically isolated.
D14 Wireless communication interfaces which do not have specific security requirements, or have not met those requirements as listed, must be physically and cryptographically isolated.
Modified
p. 28 → 29
Note: Where the security requirements in D12 and/or D13 for Bluetooth or Wi-Fi are not met, D14 must be met.
Note: Where the applicable security Requirements D12 and/or D13 for Bluetooth or Wi-Fi are not met, D14 must be used.
Modified
p. 29 → 30
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to Participating Payment Brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews, and by means of evidence that procedures are properly implemented and used. This information shall be included in the evaluation report to PCI.
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to Participating Payment Brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews, and by means of evidence that procedures are properly implemented and used. This information shall be included in the evaluation report to the PCI.
Modified
p. 29 → 30
Number Description of Requirement Yes No N/A E1 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 impacted security requirements of this document. 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 that impacts security. Approval of delta submissions …
Number Description of Requirement Yes No N/A E1 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 impacted security requirements of this document. 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 that impacts security.
Modified
p. 29 → 30
E2 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.
E2 The firmware and any changes thereafter have been inspected and reviewed using a documented and auditable process and verified by the vendor as being free from hidden and unauthorized or undocumented functions.
Removed
p. 30
Authentication by secret information is mandatory in POI v6.
Modified
p. 30 → 31
E8 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 shall provide evidence that these security measures are followed during the development and maintenance of the POI security-related components. The evidence shall justify that the security …
E8 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 its development environment. The development-security documentation shall provide evidence that these security measures are followed during the development and maintenance of the POI security-related components. The evidence shall justify that the security …
Modified
p. 30 → 31
E10 The device vendor has internal policies and procedures that ensure the vendor maintains an effective process for detecting vulnerabilities that may exist within its device. This process is expected to be robust enough to include all interfaces defined in Requirement D1 and to detect vulnerabilities which may have not been publicly known during the last vulnerability assessment.
E10 The device vendor has internal policies and procedures that ensure the vendor maintains an effective process for detecting vulnerabilities that may exist within its device. This process is expected to be robust enough to include all interfaces defined in Requirement D1 and to detect vulnerabilities which may not have been publicly known during the last vulnerability assessment.
Modified
p. 30 → 31
E11 The device has undergone a vulnerability assessment to ensure that the protocols and interfaces list in D1 do not contain exploitable vulnerabilities.
E11 The device has undergone a vulnerability assessment to ensure that the protocols and interfaces listed in Requirement D1 do not contain exploitable vulnerabilities.
Modified
p. 31 → 32
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.
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.
Removed
p. 32
F3 While in transit from the manufacturer’s facility to the initial key- loading facility, the device is shipped and stored containing a secret that:
Modified
p. 32 → 33
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored enroute under auditable controls that can account for the location of every POI at every point in time•such as the use of serialized tamper-evident packing for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key-loading facility (where transactional (acquirer) keys are loaded) or to the facility of initial deployment and stored en-route under auditable controls that can account for the location of every POI at every point in time•such as the use of serialized tamper-evident packaging for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.
Modified
p. 32 → 33
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage it is managing is compliant with this requirement. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Modified
p. 32 → 33
F2 Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
F2 Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which it receives the device until the time it is received by the next intermediary or the point of initial deployment. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Modified
p. 33 → 34
F6 If the manufacturer is not in charge of initial key loading, the manufacturer must provide the means to the initial key-loading facility to assure the verification of the authenticity of the POI security-related components.
F6 If the manufacturer is not in charge of initial key loading, the manufacturer must provide the means to the initial key-loading facility to ensure the verification of the authenticity of the POI security- related components.
Modified
p. 35 → 36
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.
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 must be sufficient to show the various components of the device.
Modified
p. 37 → 38
Functionality Description PIN Entry This is the functionality present for any device under test that captures the PIN from the cardholder and turns it into information. No assumption is made upon the format; this could be a PIN block, but also cover partial PIN information such as a digit, if this partial information is going to form a PIN during a legitimate transaction.
Functionality Description PIN Entry This is the functionality present for any device under test that captures the PIN from the cardholder and turns it into information. No assumption is made upon the format; this could be a PIN block, but could also cover partial PIN information such as a digit, if this partial information is going to form a PIN during a legitimate transaction.
Modified
p. 37 → 38
Keys This functionality is considered whenever the device under evaluation contains
•even temporarily
•keys involved in PINsecurity. Under the scope of this functionality are the secret keys of symmetric algorithms, the private keys of asymmetric algorithms, and the public keys of asymmetric algorithms (with the limitation of scope to their integrity and authenticity). The tamper-detection mechanisms must protect all PIN digits.
•even temporarily
•keys involved in PIN
Keys This functionality is considered whenever the device under evaluation contains
•even temporarily
•keys involved in PIN security or protecting account data as part of an SRED assessment. Under the scope of this functionality are the secret keys of symmetric algorithms, the private keys of asymmetric algorithms, and the public keys of asymmetric algorithms (with the limitation of scope to their integrity and authenticity). The tamper-detection mechanisms must protect all PIN and/or account digits.
•even temporarily
•keys involved in PIN security or protecting account data as part of an SRED assessment. Under the scope of this functionality are the secret keys of symmetric algorithms, the private keys of asymmetric algorithms, and the public keys of asymmetric algorithms (with the limitation of scope to their integrity and authenticity). The tamper-detection mechanisms must protect all PIN and/or account digits.
Modified
p. 37 → 38
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 contactless, magnetic-stripe, and smart card readers. This is further broken down into CTLS, ICCR, and MSR functionality.
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 contactless, smart-card, and magnetic-stripe readers. This is further broken down into CTLS, ICCR, and MSR functionality.
Modified
p. 37 → 38
Feedback to cardholder Each time a device under evaluation implements any way of possibly giving feedback to the cardholder during its PIN-based transaction, it applies to this functionality. This includes but is not limited to auditory and visible feedback⎯i.e., displays.
Feedback to Cardholder Each time a device under evaluation implements any way of possibly giving feedback to the cardholder during its PIN-based transaction, it applies to this functionality. This includes, but is not limited to, auditory and visible feedback⎯i.e., displays.
Modified
p. 37 → 38
Device is a module If the device under evaluation is designed to be integrated into equipment, it applies for “terminal is a module” functionality. Modules are also referred to as OEM equipment.
Device is a Module If the device under evaluation is designed to be integrated into equipment, it applies for “terminal is a module” functionality. Modules are also referred to as OEM equipment.
Modified
p. 37 → 38
Device 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.
Device 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.
Removed
p. 38
For compound devices, it is possible that these requirements are met or exceeded by the relevant module(s), if the corresponding requirements are fully covered; however, it remains up to the testing house’s judgment to evaluate on a case-by-case basis whether supplementary testing is required.
Modified
p. 38 → 40
2. For each of the supported functionalities, report any marking “X” corresponding to the listed requirement. “X” stands for “applicable,” in which case the requirement must be considered for both the vendor questionnaire and evaluation. In all cases, if a security requirement is impacted, the device must be assessed against it.
2. For each of the supported functionalities, report any marked “X” corresponding to the listed requirement. “X” stands for “applicable,” in which case the requirement must be considered for both the vendor questionnaire and evaluation. In all cases, if a security requirement is impacted, the device must be assessed against it.
Modified
p. 38 → 40
In addition to other applicable requirements, devices implementing open protocols⎯e.g., Bluetooth, Wi-Fi and TLS⎯must be validated against the requirements noted in Implements Open Protocols. Devices implementing SRED must be validated against the requirements in Protects Account Data.
In addition to other applicable requirements, devices implementing open protocols⎯e.g., Bluetooth, Wi-Fi and TLS⎯must be validated against the requirements noted in the Implements Open Protocols column. Devices implementing SRED must be validated against the requirements in the Protects Account Data column.
Modified
p. 38 → 40
The SCRP column is used as an example of applicability for a specific POI approval class. In general, requirements applicable to SCRs are the same as SCRPs. However, by definition SCRPs will always handle the PIN, and those requirements will always be applicable, whereas an SCR will not necessarily handle the PIN.
The SCRP column is used as an example of applicability for a specific POI approval class. In general, requirements applicable to SCRs are the same as SCRPs. However, by definition, SCRPs will always handle the PIN, and those requirements will always be applicable, whereas an SCR will not necessarily handle the PIN.
Modified
p. 38 → 40
SCRP includes all Physical and Logical requirements except those specific to PIN entry, display prompt control, and unattended usage.
SCRP includes all Physical and Logical Requirements except those specific to PIN entry, display prompt control, and unattended usage.
Modified
p. 38 → 40
This delineation is the expected applicability but should not be regarded as definitive. In all cases, device functionality determines applicability of requirements.
This delineation is the expected applicability but should not be regarded as definitive. In all cases, device functionality determines the applicability of requirements.
Modified
p. 38 → 40
1. In order to receive the “Open Protocols” designation devices must meet all applicable requirements in the Implements Open Protocols column.
1. In order to receive the “Open Protocols” designation, devices must meet all applicable requirements in the Implements Open Protocols column.
Modified
p. 38 → 40
2. In order to receive the “SRED” designation devices must meet all applicable requirements in the Protects Account Data column.
2. In order to receive the “SRED” designation, devices must meet all applicable requirements in the Protects Account Data column.
Removed
p. 39
Non-Invasive Attacks − Determining Keys Analysis
• For SCRP applicable whenever reader handles PINs, either offline or online, and has clear-text secret or private PIN-security-related cryptographic keys resident in the device.
Physical Security of Display Prompts − If keypad can be used to enter non-PIN data.
• For SCRP applicable whenever reader handles PINs, either offline or online, and has clear-text secret or private PIN-security-related cryptographic keys resident in the device.
Physical Security of Display Prompts − If keypad can be used to enter non-PIN data.
Modified
p. 44 → 45
Note: Encrypted, truncated, masked, and hashed PAN data (with salt) may be outputted outside of the device.
Note: Encrypted, truncated, masked, and hashed PAN data (with salt) may be output outside of the device.
Modified
p. 44 → 45
Application Application is considered to be any code in the device that does not impact compliance to these security requirements (with the exception of prompt control and SRED applications).
Application Application is considered to be any code in the device that does not impact compliance to these security requirements (with the exception of prompt control and SRED applications). Applications can be the following:
Modified
p. 44 → 45
Authentication The process for establishing unambiguously the identity of an entity, process, organization, or person.
Authentication The process for unambiguously establishing the identity of an entity, process, organization, or person.
Modified
p. 44 → 46
Check Value A computed value which is the result of passing a data value through a non- reversible algorithm. A value used to identify a key without revealing any bits of the actual key itself. TDEA must support its use, and AES shall only use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of …
Check Value A computed value which is the result of passing a data value through a non- reversible algorithm. A value used to identify a key without revealing any bits of the actual key itself. TDEA must support its use, and AES shall only use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of …
Modified
p. 45 → 46
Cleartext The intelligible form of an encrypted text or its elements.
Modified
p. 45 → 46
Cleartext Key An unencrypted cryptographic key used in its current form.
Modified
p. 45 → 46
A violation of the security of a system such that an unauthorized disclosure of sensitive information may have occurred. This includes the unauthorized disclosure, modification, substitution, or use of sensitive data (including clear-text cryptographic keys and other keying material).
A violation of the security of a system such that an unauthorized disclosure of sensitive information may have occurred. This includes the unauthorized disclosure, modification, substitution, or use of sensitive data (including cleartext cryptographic keys and other keying material).
Modified
p. 45 → 47
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.
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.
Modified
p. 45 → 47
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 transmitted as part of each transaction.
Modified
p. 46 → 48
Encipher See Encrypt.
Modified
p. 46 → 48
Encrypt The (reversible) transformation of data by a cryptographic algorithm to produce ciphertext•i.e., the process of transforming clear text into ciphertext to hide the information content of the data.
Encrypt The (reversible) transformation of data by a cryptographic algorithm to produce ciphertext•i.e., the process of transforming cleartext into ciphertext to hide the information content of the data.
Modified
p. 46 → 48
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 clear-text key.
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 cleartext key.
Modified
p. 46 → 48
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 …
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, card or biometric reader, or rely upon external displays or card or biometric 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 …
Modified
p. 46 → 48
Encrypting PIN pads require integration into UPTs or ATMs.
Encrypting PIN pads requires integration into UPTs or ATMs.
Modified
p. 46 → 48
Firmware For purposes of these requirements, firmware is considered to be any code within the device that provides security protections needed to comply with device security requirements or can impact compliance to these security requirements. Firmware may be further segmented by code necessary to meet subsets of requirements.
Firmware For purposes of these requirements, firmware is considered to be any code within the device that provides security protections needed to comply with device security requirements, or can impact compliance with these security requirements. Firmware may be further segmented by code necessary to meet subsets of requirements.
Modified
p. 47 → 49
Independent Expert An Independent Expert possesses all the following qualifications:
3. Devices used to authorize or enable key-management functions Independent Expert An Independent Expert possesses all the following qualifications:
Modified
p. 47 → 49
• Is recognized by his/her peers in the field⎯e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body⎯e.g., ACM, BCS, IEEE, IET, IACR.
• Is recognized by their peers in the field⎯e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body⎯e.g., ACM, BCS, IEEE, IET, IACR.
Modified
p. 48 → 50
Key Archive Process by which a key no longer in operational use at any location is stored.
Key Archive Process that stores a key that is no longer in operational use at any location.
Modified
p. 48 → 50
Key Establishment The process of making available a shared secret key to one or more entities. Key establishment includes key agreement and key transport.
Key Establishment The process of making available a shared secret key to one or more entities. Key establishment includes a key agreement and key transport.
Modified
p. 49 → 51
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 (Secret) Share One of at least two parameters related to a cryptographic key that is 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.
Modified
p. 49 → 51
Key Variant A new TDEA key formed by a reversible process (which need not be secret) with the original TDEA 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 → 52
Monitor Token A cryptographically signed value provided by the monitoring system to the SCRP and cryptographically authenticated by the SCRP to enable its operation for a period not to exceed ten minutes. The value and its usage must have properties⎯e.g., time/date stamps⎯that ensure the prevention of replay, pre-calculation, or other attacks to allow improper continued operation or re-enablement of the SCRP.
Monitor Token A cryptographically-signed value provided by the monitoring system to the SCRP and cryptographically authenticated by the SCRP to enable its operation for a period not exceeding ten minutes. The value and its usage must have properties⎯e.g., time/date stamps⎯that ensure the prevention of replay, pre-calculation, or other attacks that allow improper continued operation or re-enablement of the SCRP.
Modified
p. 50 → 52
OEM Card Reader A self-contained, secure chip, or hybrid card reader, which requires integration into UPTs.
OEM Card Reader A self-contained secure chip, or hybrid card reader that requires integration into UPTs.
Modified
p. 50 → 52
OEM PED A self-contained point-of-sale POI device containing a PIN pad, display, and/or card reader, which requires integration into a final casing. Generally used in UPTs.
OEM PED A self-contained POS device containing a PIN pad, display, and/or card reader, which requires integration into a final casing. Generally used in UPTs.
Modified
p. 50 → 52
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.
Opaque Impenetrable by light⎯i.e., light within the visible spectrum of wavelength range of 400nm to 750nm⎯and is neither transparent nor translucent within the visible spectrum.
Modified
p. 50 → 52
Overlay Any additional covering, including a fake keypad, placed by fraudsters on top of a genuine PIN entry keypad and generally similar in shape and color. The placement of an overlay may also serve the purpose of concealing other attacks.
Overlay Any additional covering, including a fake keypad, placed by fraudsters on top of a genuine PIN entry keypad and is generally similar in shape and color. The placement of an overlay may also serve the purpose of concealing other attacks.
Modified
p. 50 → 53
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.
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.
Modified
p. 51 → 53
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 Integrated Circuit (IC) and magnetic- stripe contact cards, and contactless payment card-based payment transactions.
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 Integrated Circuit (IC) and magnetic- stripe contact cards, as well as contactless payment card-based payment transactions.
Modified
p. 51 → 53
Private Key A cryptographic key, used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public.
Private Key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public.
Modified
p. 51 → 53
Public Key A cryptographic key, used with a public-key cryptographic algorithm uniquely associated with an entity, and that may be made public.
Public Key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity, and that may be made public.
Modified
p. 52 → 54
With asymmetric cryptographic techniques, such as RSA, there are four elementary transformations: sign and verify for signature systems and encipher and decipher for encipherment systems. The signature and the decipherment transformations are kept private by the owning entity, whereas the corresponding verification and encipherment transformations are published. There exist asymmetric cryptosystems⎯e.g., RSA⎯where the four elementary functions may be achieved by only two transformations: one private transformation suffices for both signing and decrypting messages, and one public transformation suffices for both …
With asymmetric cryptographic techniques, such as RSA, there are four elementary transformations: sign and verify for signature systems, and encipher and decipher for encipherment systems. The signature and the decipherment transformations are kept private by the owning entity, whereas the corresponding verification and encipherment transformations are published. There exist asymmetric cryptosystems⎯e.g., RSA⎯where the four elementary functions may be achieved by only two transformations: one private transformation suffices for both signing and decrypting messages, and one public transformation suffices for both …
Modified
p. 52 → 54
Random The process of generating values with a high level of entropy and which satisfy various qualifications, using cryptographic and hardware-based “noise” mechanisms. This results in a value in a set that has equal probability of being selected from the total population of possibilities, hence unpredictable.
Random The process of generating values with a high level of entropy and which satisfy various qualifications, using cryptographic and hardware-based “noise” mechanisms. This results in a value in a set that has equal probability of being selected from the total population of possibilities, hence is unpredictable.
Modified
p. 52 → 54
RSA Public Key Cryptography Public-key cryptosystem that can be used for both encryption and authentication.
Modified
p. 52 → 54
Secret Key A cryptographic key, used with a secret-key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. A secret-key (symmetrical) cryptographic algorithm uses a single secret key for both encryption and decryption. The use of the term “secret” in this context does not imply a classification level; rather the term implies the need to protect the key from disclosure or substitution.
Secret Key A cryptographic key, used with a secret-key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. A secret-key (symmetrical) cryptographic algorithm uses a single secret key for both encryption and decryption. The use of the term “secret” in this context does not imply a classification level; rather, the term implies the need to protect the key from disclosure or substitution.
Modified
p. 52 → 54
Secret-Key (Symmetric) Cryptographic Algorithm A cryptographic algorithm that uses a single secret key for both encryption and decryption.
Modified
p. 53 → 55
Secure Controller A secure microprocessor or security protected microprocessor within the terminal, used to manage cardholder data among other functions.
Secure Controller A secure microprocessor or security-protected microprocessor within the terminal, used to manage cardholder data among other functions.
Modified
p. 53 → 55
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 Cryptographic Device (SCD) 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.
Modified
p. 53 → 55
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 Cryptoprocessor A secure cryptoprocessor is a dedicated computer on a chip or microprocessor that carries out cryptographic operations, and is embedded in a packaging with multiple physical security measures that give it a degree of tamper-resistance.
Modified
p. 53 → 55
Secure Key Loader A self-contained unit that is capable of storing at least one clear-text or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.
Secure Key Loader A self-contained unit that is capable of storing at least one cleartext or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.
Modified
p. 53 → 55
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 clear text or otherwise unprotected form.
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 cleartext or otherwise unprotected form.
Modified
p. 53 → 55
Sensitive (Secret) Data (Information) Sensitive data includes but is not restricted to the cardholder PIN, all secret keying material, design characteristics, status information, and other functions that allow access to secure areas within the terminal.
Sensitive (Secret) Data (Information) Sensitive data includes but is not restricted to:
Modified
p. 53 → 56
Service Module A module providing for non-cardholder activities and oriented towards service or maintenance related functions and may consist of:
Service Module A module that provides for non-cardholder activities and is oriented towards service or maintenance-related functions and may consist of:
Modified
p. 53 → 56
• A service data exchange support (SDE), which may consist of a card reader, a floppy disk drive, a USB interface or the like.
• A service data exchange support (SDE), which may consist of a card reader, a USB interface, or the like.
Removed
p. 54
SK Session key Split Knowledge A condition under which two or more entities separately have information⎯e.g., key components⎯that individually convey no knowledge of the resultant combined information⎯e.g., a cryptographic key.
Modified
p. 54 → 56
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.
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.
Modified
p. 54 → 56
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.
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.
Modified
p. 54 → 56
SPoC Software-based PIN Entry on Commercial off-the-shelf (COTS) Devices. A payment solution that encompasses the set of components and processes that support the entry of PIN data into a COTS device. At a minimum, this includes a SCRP, PIN CVM Application, and the back-end systems and environments that perform attestation, monitoring, and payment and online PIN processing.
SPoC Software-based PIN Entry on Commercial off-the-shelf (COTS) Devices. A payment solution that encompasses the set of components and processes that support the entry of PIN data onto a COTS device. At a minimum, this includes an SCRP, PIN CVM Application, and the back-end systems and environments that perform attestation, monitoring, and payment and online PIN-processing.
Modified
p. 54 → 56
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. 55 → 57
Terminal Vendor Organization that submits for evaluation a POI device to the PCI PTS framework.
Terminal Vendor Organization that submits a POI device to the PCI PTS framework for evaluation.
Modified
p. 55 → 57
Triple Data Encryption Algorithm (TDEA) The algorithm specified in ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation.
Modified
p. 55 → 58
• 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 resides outside the cryptographic boundary of a secure cryptographic device.
Modified
p. 55 → 58
Zeroize The degaussing, erasing, or overwriting of electronically stored data so as to prevent recovery of the data.
Zeroize The degaussing, erasing, or overwriting of electronically-stored data so as to prevent recovery of the data.