Document Comparison
SPoC_Test__Requirements_v1.0.pdf
→
SPoC_TestRequirements-v1.1.pdf
95% similar
102 → 101
Pages
38484 → 37768
Words
421
Content Changes
Content Changes
421 content changes. 116 administrative changes (dates, page numbers) hidden.
Added
p. 6
The testing requirements and security requirements have been developed for specific audiences, therefore it should be noted that there is not a one-to-one mapping between the documents. The two documents should be read in combination to fully understand the requirements and the methods for evaluation.
Added
p. 10
• Attestation Processes attestation health-check data from the PIN CVM application and enforces pre- established security policies
• Monitoring Monitors and provisions security controls to detect, alert and mitigate suspected or actual threats and attacks against the SCRP, PIN CVM application, and the COTS device
• Monitoring Monitors and provisions security controls to detect, alert and mitigate suspected or actual threats and attacks against the SCRP, PIN CVM application, and the COTS device
Added
p. 14
• Accurately provides information specified in this document, without ambiguous or inconsistent information
• Includes information relevant to any applicable FAQs
• Conforms to Laboratory General Requirements and any other related documentation in the PTS Program, such as (but not restricted to) Reporting Guidance and Templates
• Includes information relevant to any applicable FAQs
• Conforms to Laboratory General Requirements and any other related documentation in the PTS Program, such as (but not restricted to) Reporting Guidance and Templates
Added
p. 17
Deterministic Random Number Generator (DRNG) A deterministic algorithm that generates a sequence of numbers with little or no discernible pattern in the numbers, except for broad statistical properties, which uses a seed value provided by a Non-deterministic Random Number Generator.
Added
p. 21
OS store A digital distribution service operated by the COTS OS vendor or by the COTS device manufacturer.
Added
p. 23
Sensitive authentication data Security-related information
•including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs and PIN blocks
•used to authenticate cardholders and/or authorize payment card transactions.
•including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs and PIN blocks
•used to authenticate cardholders and/or authorize payment card transactions.
Added
p. 33
• Encrypted by a key of equal or greater strength
• Stored within a SCD
• Managed as two or more full-length components
• Standalone (e.g., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);
• Dedicated to only the white-box generation function (i.e., there must not be any other application software installed); and
• Located in a physically secure room that is dedicated to the white-box generation activities.
• Stored within a SCD
• Managed as two or more full-length components
• Standalone (e.g., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);
• Dedicated to only the white-box generation function (i.e., there must not be any other application software installed); and
• Located in a physically secure room that is dedicated to the white-box generation activities.
Added
p. 38
• Examine provided application installation files where the protection methods have been applied, and through review of these (and comparison to files where protections have not yet been applied) comment on the validity of the vendor attestations and documentation regarding protection methods implemented
• Comment on the comparative file sizes between unprotected and protected application samples, as well as the relative compression ratio of each file type when standard compression functions are applied (directly to each obfuscated code segment)
• Attempt extraction of data objects (such as ASCII strings and symbols) and functional linking/interface tables (such as PLT/GOT), and note any differences between code sets before and after the obfuscation process
• Analyze and comment on the comparative code flow and linkage between the code before and after the obfuscation process
• Note and comment on any areas of non-traditional execution, where the obfuscation relies on virtualized/interpreted commands, non-deterministic operations or polymorphic processes, etc. …
• Comment on the comparative file sizes between unprotected and protected application samples, as well as the relative compression ratio of each file type when standard compression functions are applied (directly to each obfuscated code segment)
• Attempt extraction of data objects (such as ASCII strings and symbols) and functional linking/interface tables (such as PLT/GOT), and note any differences between code sets before and after the obfuscation process
• Analyze and comment on the comparative code flow and linkage between the code before and after the obfuscation process
• Note and comment on any areas of non-traditional execution, where the obfuscation relies on virtualized/interpreted commands, non-deterministic operations or polymorphic processes, etc. …
Added
p. 44
Where purely software methods are used for the protection of these keys - for example, through use of “white-box” cryptography − the specific instance used in a PIN CVM application must be regularly changed within a period shorter than the expected time required to reverse engineer the software protections. At a minimum, changes to the white-box instance must occur at least once per month. It is acceptable to have two sets of keys during the changeover period but all "old" keys must be invalidated once the new keys are installed. This requirement does not imply that different implementations, or different algorithms, must be used each month.
• Whether any public vulnerabilities exist for the protection mechanism
• Whether the protection mechanism has undergone any formal certification or validation process
• Which platforms have been explicitly tested by the test laboratory as part of this evaluation process
• How the software protection method is implemented, …
• Whether any public vulnerabilities exist for the protection mechanism
• Whether the protection mechanism has undergone any formal certification or validation process
• Which platforms have been explicitly tested by the test laboratory as part of this evaluation process
• How the software protection method is implemented, …
Added
p. 46
• Manipulation of the execution environment through an interface to hardware features such as clock/voltage settings, direct/indirect memory access (using "RowHammer-" like attacks), etc.
Added
p. 47
Disabling of software-based PIN entry for magnetic-stripe transactions must be at the level of the PIN CVM application.
• Disabling all network connections
• Deactivating data connectivity for a cellular network
The authenticity of the PIN CVM application is a paramount concern in the security of PIN entry. Loading of applications from the OS store provides a level of confidence that the application has not been tampered with before being installed on the merchant system. The tester must validate that there are no public vulnerabilities for the stores used.
The scope of this requirement is for the authentication of the application by the base OS. Additional authenticity checks are expected to be applied and checked by the monitoring system or applied as part of the obfuscation methods, but these are not in scope of this requirement.
• The transaction terminated for any reason (including success or failure); or
• The PIN CVM application has timed out …
• Disabling all network connections
• Deactivating data connectivity for a cellular network
The authenticity of the PIN CVM application is a paramount concern in the security of PIN entry. Loading of applications from the OS store provides a level of confidence that the application has not been tampered with before being installed on the merchant system. The tester must validate that there are no public vulnerabilities for the stores used.
The scope of this requirement is for the authentication of the application by the base OS. Additional authenticity checks are expected to be applied and checked by the monitoring system or applied as part of the obfuscation methods, but these are not in scope of this requirement.
• The transaction terminated for any reason (including success or failure); or
• The PIN CVM application has timed out …
Added
p. 54
• Stealing focus during PIN entry, to capture the customer data as it is entered
• Stealing focus at any other time during the foreground execution of the PIN CVM application to maliciously prompt for (and thereby capture) PIN entry
• The data is not passed or otherwise made available/accessible to any other application
• The values entered by the customer are not displayed on the merchant screen (even temporarily). Only non-deterministic values, such as an asterisk, may be displayed.
• Any tones provided during the PIN entry are not identifiable to the value entered (e.g., not DTMF tones or other sounds that can be correlated to the (virtual) button pressed by the customer)
• An enforcing mandatory access control framework
• A "trusted boot" mechanism that validates the OS authenticity from a hardware root of trust. This mechanism must either prevent the loading of unauthentic OS code or allow for detection of such code by …
• Stealing focus at any other time during the foreground execution of the PIN CVM application to maliciously prompt for (and thereby capture) PIN entry
• The data is not passed or otherwise made available/accessible to any other application
• The values entered by the customer are not displayed on the merchant screen (even temporarily). Only non-deterministic values, such as an asterisk, may be displayed.
• Any tones provided during the PIN entry are not identifiable to the value entered (e.g., not DTMF tones or other sounds that can be correlated to the (virtual) button pressed by the customer)
• An enforcing mandatory access control framework
• A "trusted boot" mechanism that validates the OS authenticity from a hardware root of trust. This mechanism must either prevent the loading of unauthentic OS code or allow for detection of such code by …
Added
p. 64
• At initialization/initial installation of the PIN CVM application
• Whenever the SCRP is physically or logically disconnected or re-connected to the PIN CVM application
• On execution of the PIN CVM application, to be completed at least immediately prior to the entry of the first PIN
• If initiated by the monitoring system, back-end server or other component of the overall solution (including the PIN CVM application itself)
• Randomly through PIN CVM application operation, but no less than every 5 minutes of operation (if not otherwise activated by one of the events above during that time)
• Any time the PIN CVM application either loses focus or regains focus
• After changes have been made to any component of the solution TC2.4 The tamper-response mechanisms must be able to detect and determine the validity of the SCRP being used. At a minimum, this must confirm:
• That a valid SCRP is being used (e.g., the …
• Whenever the SCRP is physically or logically disconnected or re-connected to the PIN CVM application
• On execution of the PIN CVM application, to be completed at least immediately prior to the entry of the first PIN
• If initiated by the monitoring system, back-end server or other component of the overall solution (including the PIN CVM application itself)
• Randomly through PIN CVM application operation, but no less than every 5 minutes of operation (if not otherwise activated by one of the events above during that time)
• Any time the PIN CVM application either loses focus or regains focus
• After changes have been made to any component of the solution TC2.4 The tamper-response mechanisms must be able to detect and determine the validity of the SCRP being used. At a minimum, this must confirm:
• That a valid SCRP is being used (e.g., the …
Added
p. 69
As the security landscape changes, platforms or OSs that may be acceptable under the system baseline may become vulnerable. A documented policy and procedure for assessing these changes must exist and must provide details on how decisions are made to remove previously acceptable platforms from the system baseline. Such changes will affect merchants using these platforms, so the documentation must also include how merchant communication is handled in these cases.
• How to assess whether newly exposed vulnerabilities pose a risk to platforms
• The need to reassess all supported platforms at least every year and the method used for reassessment
• How to assess whether newly exposed vulnerabilities pose a risk to platforms
• The need to reassess all supported platforms at least every year and the method used for reassessment
Added
p. 72
• The version of TLS used
• Whether the TLS code is implemented in the PIN CVM application itself, or whether the platform is relied upon to establish this connection. Where the PIN CVM application implements the TLS connection itself, the tester shall note the source and version of the TLS code used.
• The cipher suites supported for use;
• Whether the TLS code is implemented in the PIN CVM application itself, or whether the platform is relied upon to establish this connection. Where the PIN CVM application implements the TLS connection itself, the tester shall note the source and version of the TLS code used.
• The cipher suites supported for use;
Added
p. 87
3. The monitoring system is not able to consistently detect rooted COTS device.
Added
p. 94
• PCs/workstations, data storage and data backup facilities
• Virtualization environments for dynamic analysis
• Tools for code disassembly and decompilation
• Signal analysis and signal processing software, capable of filtering, compressing, synchronizing or otherwise effectively operating on acquired signals
• Side-channel analysis test tools including effective UIs and configurable collection and analysis components
• Fault injection resources such as perturbation source and glitch control tools for these sources, for example: pulse generators, lasers, etc.
• NRNG analysis software
• Familiarity with mobile execution environments and their security models; for example, Android and iOS
• Familiarity with software protection tools and their analysis, including obfuscation and white-box cryptography
• Familiarity with hooking techniques
• Device physical components: structure and materials, how multiple components combine to realize security objectives and how flaws can be identified and/or exploited
• Device security-critical components design and functionality, such as (but not restricted to): keypads, displays and cases
• Schematic representations of hardware and logic, for example, …
• Virtualization environments for dynamic analysis
• Tools for code disassembly and decompilation
• Signal analysis and signal processing software, capable of filtering, compressing, synchronizing or otherwise effectively operating on acquired signals
• Side-channel analysis test tools including effective UIs and configurable collection and analysis components
• Fault injection resources such as perturbation source and glitch control tools for these sources, for example: pulse generators, lasers, etc.
• NRNG analysis software
• Familiarity with mobile execution environments and their security models; for example, Android and iOS
• Familiarity with software protection tools and their analysis, including obfuscation and white-box cryptography
• Familiarity with hooking techniques
• Device physical components: structure and materials, how multiple components combine to realize security objectives and how flaws can be identified and/or exploited
• Device security-critical components design and functionality, such as (but not restricted to): keypads, displays and cases
• Schematic representations of hardware and logic, for example, …
Added
p. 97
• Protection of cryptographic keys or cryptographic APIs (against misuse)
• Analysis of white-box cryptography-protected implementation (to obtain the WBC key) If the tools have been provided by a third party and applied to the PIN CVM application by the application vendor, the laboratory may establish whether there is any available and applicable assurance for the tool.
• A description of any restrictions that were placed upon the laboratory by the vendor and prevented the evaluation from being fully white-box − for example, restricted access to source code or documentation.
• Analysis of white-box cryptography-protected implementation (to obtain the WBC key) If the tools have been provided by a third party and applied to the PIN CVM application by the application vendor, the laboratory may establish whether there is any available and applicable assurance for the tool.
• A description of any restrictions that were placed upon the laboratory by the vendor and prevented the evaluation from being fully white-box − for example, restricted access to source code or documentation.
Modified
p. 6 → 5
Mobile payment acceptance enables the processing of payment transactions − e.g., using a smartphone or tablet − that performs the functions of an electronic point-of-sale terminal. Software-based PIN entry solutions allow for the processing of mobile payment- acceptance transactions with a cardholder’s PIN.
Modified
p. 6 → 5
Software-based cardholder authentication provides an alternative for chip and PIN markets by providing a software application interface on a merchant’s COTS device to capture and process a cardholder’s PIN. These solutions rely on a combination of mechanisms and security controls including but not limited to device hardware, application software, and independent management and oversight of the entire process to ensure the security of the transaction and PIN data.
Modified
p. 6 → 5
The following figure highlights the security model differences (and reliance on controls) between a traditional PED implementation (hardware PIN) and a software-based PIN entry solution (software PIN) for the protection of PIN data.
The following figure highlights the security model differences (and reliance on controls) between a traditional PED implementation (hardware PIN) and a software-based PIN entry solution (software PIN) for the protection of PIN data.
Modified
p. 7 → 6
Figure 1: Example of PIN CVM Solution Architecture This document is designed to provide more granularity and visibility into the testing processes performed by the evaluation laboratories that will perform the validation testing of the Software-based PIN CVM Solutions.
Figure 1: Example of PIN CVM Solution Architecture This document is designed to provide more granularity and visibility into the testing processes performed by the evaluation laboratories that will perform the validation testing of the software-based PIN CVM solutions.
Modified
p. 7 → 6
A separate document, Software-based PIN Entry on COTS Security Requirements, is available to define the security requirements for entities developing PIN CVM Applications, organizations managing and deploying PIN CVM Solutions, testers and assessors. The testing requirements and security requirements have been developed for specific audiences, therefore it should be noted that there is not a one-to-one mapping between the documents. The two documents should be read in combination to fully understand the requirements and the methods for evaluation.
A separate document, Software-based PIN Entry on COTS Security Requirements, is available to define the security requirements for entities developing PIN CVM applications, organizations managing and deploying PIN CVM solutions, testers, and assessors. Solutions may optionally include magnetic-stripe readers that meet the security and testing requirements detailed in Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex.
Modified
p. 8 → 7
Figure 2: Software-based PIN Entry Solution
Figure 2: Software-based PIN Entry Solution
Modified
p. 8 → 7
1. PIN CVM Application and SCRP are initialized with their financial keys (this may be asynchronous with the transaction).
1. PIN CVM application and SCRP are initialized with their financial keys (this may be asynchronous with the transaction).
Modified
p. 8 → 7
2. A secure communication channel between the PIN CVM Application and the back-end monitoring system is established.
2. A secure communication channel between the PIN CVM application and the back-end monitoring system is established.
Modified
p. 8 → 7
3. The back-end monitoring system determines the security status of the mobile payment-acceptance platform (SCRP, COTS platform and PIN CVM Application) using the attestation component.
3. The back-end monitoring system determines the security status of the mobile payment-acceptance platform (SCRP, COTS platform, and PIN CVM application) using the attestation component.
Modified
p. 8 → 7
4. An EMV card, contact or contactless or an NFC-enabled mobile EMV payment device is presented to the SCRP.
4. An EMV card, contact or contactless or an NFC-enabled mobile EMV payment device is presented to the SCRP.
Modified
p. 8 → 7
5. The PIN CVM Application PIN entry component renders a PIN entry screen on the COTS platform and the cardholder enters their PIN using the rendered PIN pad from the PIN CVM Application. The resulting information is enciphered and sent to the SCRP by the PIN CVM Application.
5. The PIN CVM application PIN entry component renders a PIN entry screen on the COTS platform and the cardholder enters their PIN using the rendered PIN pad from the PIN CVM application. The resulting information is enciphered and sent to the SCRP by the PIN CVM application.
Modified
p. 8 → 7
6. The SRED component of the SCRP enciphers the account data using preloaded data- encryption keys according to either Figure 3 (online PIN verification) or Figure 4 (offline PIN verification) below.
6. The SRED component of the SCRP enciphers the account data using preloaded data- encryption keys according to either Figure 3 (online PIN verification) or Figure 4 (offline PIN verification) below.
Modified
p. 9 → 8
Figure 3: Online PIN Verification - An enciphered PIN block is generated by the SCRP component (online PIN processing, contact and contactless EMV) using preloaded PIN-encryption keys.
Figure 3: Online PIN Verification − An enciphered PIN block is generated by the SCRP component (online PIN processing, contact and contactless EMV) using preloaded PIN-encryption keys.
Modified
p. 9 → 8
− The SRED data and enciphered PIN block (online PIN processing only) are transmitted to an HSM within the back-end payment processing system.
Modified
p. 9 → 8
Figure 4: Offline PIN Verification - The SCRP performs offline PIN verification (contact EMV only).
Figure 4: Offline PIN Verification − The SCRP performs offline PIN verification (contact EMV only).
Modified
p. 9 → 8
− The SRED data is transmitted to an HSM within the back-end payment processing system.
Modified
p. 10 → 9
In a software-based PIN entry security model, the device where the PIN is entered and initially protected remains an important component. In addition, mechanisms that support attestation (to ensure the security mechanisms are intact and operational), detection (to notify when anomalies are present) and response (controls to alert and take action), play an equally significant role in the overall software-based PIN entry solution security model. Furthermore, having the device connected online provides opportunities to extend these capabilities to back-end monitoring …
In a software-based PIN entry security model, the device where the PIN is entered and initially protected remains an important component. In addition, mechanisms that support attestation (to ensure the security mechanisms are intact and operational), detection (to notify when anomalies are present) and response (controls to alert and take action), play an equally significant role in the overall software-based PIN entry solution security model. Furthermore, having the device connected online provides opportunities to extend these capabilities to back-end monitoring …
Modified
p. 10 → 9
Figure 5: Hardware- and Software-based PIN Entry There are, however, individual components of a software solution where there is limited control•for example, the underlying mobile device hardware platform and operating system. Given that these are COTS devices, there is an assumption that these components (e.g., COTS operating system, configuration of hardware components of a phone, etc.) are unknown or untrusted.
Figure 5: Hardware-based and Software-based PIN Entry There are, however, individual components of a software solution where there is limited control•for example, the underlying mobile device hardware platform and Operating System (OS). Given that these are COTS devices, there is an assumption that these components (e.g., COTS OS, configuration of hardware components of a phone, etc.) are unknown or untrusted.
Modified
p. 11 → 10
1. An SCRP device that supports The Solution. The SCRP is SRED-enabled and connected to the COTS device. The SCRP provides: a. Protection of cardholder data sourced from the payment instrument b. Decryption of encrypted PIN data received from the PIN CVM Application c. Translation of PIN data into required PIN-block format (This would only apply to online PIN verification processing.) d. Re-encryption of PIN data
1. An SCRP device that supports the solution. The SCRP is SRED-enabled and connected to the COTS device. The SCRP provides: a. Protection of cardholder data sourced from the payment instrument b. Decryption of encrypted PIN data received from the PIN CVM application c. Translation of PIN data into required PIN-block format (This would only apply to online PIN verification processing.) d. Re-encryption of PIN data
Modified
p. 11 → 10
2. A PIN CVM Application that resides on the COTS device and: a. Provides a secure user interface for PIN entry b. Performs initial encryption of the PIN c. Passes attestation health-check data about the SCRP, COTS platform and PIN CVM Application to the monitoring environment d. Contains software protection mechanisms to maintain its own integrity against attack e. Delivers the encrypted PIN to the SCRP to be decrypted/re-encrypted for it to be passed to the back-end monitoring and attestation …
2. A PIN CVM application that resides on the COTS device and: a. Provides a secure User Interface (UI) for PIN entry b. Performs initial encryption of the PIN c. Passes attestation health-check data about the SCRP, COTS platform, and PIN CVM application to the monitoring environment d. Contains software protection mechanisms to maintain its own integrity against attack e. Delivers the encrypted PIN to the SCRP to be decrypted/re-encrypted for it to be passed to the back-end monitoring and …
Modified
p. 11 → 10
3. A commercial off-the-shelf (COTS) device that is operated by the merchant to run the PIN CVM Application as well as the SCRP. The COTS may have a Trusted Execution Environment (TEE) built in but it is not a requirement.
3. A Commercial Off-The-Shelf (COTS) device that is operated by the merchant to run the PIN CVM application as well as the SCRP. The COTS may have a Trusted Execution Environment (TEE) built in but it is not a requirement.
Modified
p. 11 → 10
4. A set of back-end systems that perform functions for the PIN CVM Solution such as:
4. A set of back-end systems that perform functions for the PIN CVM solution such as:
Modified
p. 13 → 12
1. Merchant payment processing application(s), referred to as the software PIN acceptance application(s), which are involved in PIN payment acceptance and/or may influence the security of payment data processing. These applications may be in part or as a whole executed on a COTS system or executed remotely and rendered on the COTS system through other means. 2. Secure Card Reader-PIN (SCRP), which is able to accept EMV-based payment cards. 3. A back-end monitoring system (monitor) that cannot be entirely (logically) …
1. Merchant payment processing application(s), referred to as the software PIN acceptance application(s), which are involved in PIN payment acceptance and/or may influence the security of payment data processing. These applications may be in part or as a whole executed on a COTS system or executed remotely and rendered on the COTS system through other means. 2. Secure Card Reader-PIN (SCRP), which is able to accept EMV-based payment cards. Optionally, in accordance to Software-based PIN Entry on COTS™ Magnetic Stripe …
Modified
p. 14 → 13
3. Back-end Systems
• Monitoring/Attestation
• Monitoring/Attestation
3. Back-end Systems
• Monitoring/Attestation
• Monitoring/Attestation
Modified
p. 14 → 13
5. Back-end Systems
• Processing Core requirements are items that may apply to all areas and components that are being assessed. For example, the random numbers requirement will apply to all parts of the TOE where random numbers are generated for security functions. These core requirements must therefore be assessed against all parts of theTOE¾the PIN CVM Application, SCRP, backend-end monitoring/attestation and back-end systems processing. However, they may be assessed separately, depending on the area(s) of the TOE that are …
• Processing Core requirements are items that may apply to all areas and components that are being assessed. For example, the random numbers requirement will apply to all parts of the TOE where random numbers are generated for security functions. These core requirements must therefore be assessed against all parts of the
5. Back-end Systems
• Processing Core requirements are items that may apply to all areas and components that are being assessed. For example, the random numbers requirement will apply to all parts of the TOE where random numbers are generated for security functions. These core requirements must therefore be assessed against all parts of the TOE − the PIN CVM application, SCRP, backend-end monitoring/attestation and back-end systems processing. However, they may be assessed separately, depending on the area(s) of the TOE …
• Processing Core requirements are items that may apply to all areas and components that are being assessed. For example, the random numbers requirement will apply to all parts of the TOE where random numbers are generated for security functions. These core requirements must therefore be assessed against all parts of the TOE − the PIN CVM application, SCRP, backend-end monitoring/attestation and back-end systems processing. However, they may be assessed separately, depending on the area(s) of the TOE …
Modified
p. 14 → 13
PIN CVM Application requirements and back-end monitoring and attestation system requirements apply only to those sections of the TOE and may be assessed against those components without considering the entire solution.
PIN CVM application requirements and back-end monitoring and attestation system requirements apply only to those sections of the TOE and may be assessed against those components without considering the entire solution.
Modified
p. 14 → 13
Solution integration requirements are a combination of requirements that must be assessed against the entire solution and parts of The Solution that involve back-end payment processing and ownership of system risk analysis. It should be noted that some parts of these requirements presuppose functions (such as the creation and use of secure channels between disparate components) in parts of the solution that may be otherwise separately assessed (such as the monitoring system or PIN CVM Application).
Solution integration requirements are a combination of requirements that must be assessed against the entire solution and parts of the solution that involve back-end payment processing and ownership of system risk analysis. It should be noted that some parts of these requirements presuppose functions (such as the creation and use of secure channels between disparate components) in parts of the solution that may be otherwise separately assessed (such as the monitoring system or PIN CVM Application).
Modified
p. 14 → 13
Lastly, the back-end systems processing requirements apply only to solution components that perform decryption of cardholder account data and PIN.
Lastly, the back-end systems processing requirements apply only to solution components that perform decryption of cardholder account data and PIN.
Modified
p. 14 → 13
Structure of the TRs Each PCI requirement as stated in the PCI Software-based PIN on COTS Test Requirements is represented by a subsection. For example, Requirement A1 is represented in this document as:
Structure of the TRs Each PCI requirement as stated in the PCI Software-based PIN on COTS Test Requirements is represented by a subsection. For example, Requirement A1 is represented in this document as:
Modified
p. 15 → 14
• Conforms to documentation listed in the SPOC Program Guide Minimal Contents of Reports and Minimal Test Activities All reports shall include an overview and summary section at the beginning of the document. This summary shall include the following at a minimum. Refer to the SPOC Program Guide for additional information:
Modified
p. 15 → 14
• A system overview that summarizes the design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or functions including (but not restricted to):
Modified
p. 15 → 14
• Any back-end or "cloud-based” components that are used as part of the system
• Any back-end or "cloud-based” components that are used as part of the system
Modified
p. 15 → 14
• Test COTS devices that were used in the evaluation of the system § A summary list of TRs with verdicts on whether tested and whether compliant § A summary of any assistance provided by the vendor to the laboratory In support of applicable test procedures, as directed by the test laboratory, the vendor must support the laboratory in various tasks (such as, but not restricted to: code review, fuzzing interfacing, analysis of white-box cryptographic implementations, etc.) to avoid prohibitively …
• A summary of any assistance provided by the vendor to the laboratory In support of applicable test procedures, as directed by the test laboratory, the vendor must support the laboratory in various tasks (such as, but not restricted to: code review, fuzzing interfacing, analysis of white-box cryptographic implementations, etc.) to avoid prohibitively lengthy test activities.
Modified
p. 15 → 14
The Solution vendor shall make source code available to the lab and help make a systematic review of relevant security functions.
The solution vendor shall make source code available to the lab and help make a systematic review of relevant security functions.
Modified
p. 15 → 14
The evaluation report document shall demonstrate compliance to Security Requirements. For all Test Requirements (TRs), the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid¾i.e., considering TRs, FAQs, Program Guide and any other related documents. Every TR should be supported by sufficient …
The evaluation report document shall demonstrate compliance to Security Requirements. For all TRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid − i.e., considering TRs, FAQs, Program Guide and any other related documents. Every TR should be supported by sufficient …
Modified
p. 16 → 15
In most cases, the TR text is insufficient without combining photographs and/or other graphic illustrations that explain the evaluation. Images shall be of sufficient quality for relevant details to be viewed¾for example, clear identification of a hardware component (such as an SCRP), relevant information clearly discernible in a graph, images capturing displays and other outputs, source code fragments, etc.
In most cases, the TR text is insufficient without combining photographs and/or other graphic illustrations that explain the evaluation. Images shall be of sufficient quality for relevant details to be viewed − for example, clear identification of a hardware component (such as an SCRP), relevant information clearly discernible in a graph, images capturing displays and other outputs, source code fragments, etc.
Modified
p. 17 → 16
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 techniques, there are four elementary transformations: sign and verify for signature systems, and encipher and decipher for encipherment systems. The signature and the decipherment transformation 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 …
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 techniques, there are four elementary transformations: sign and verify for signature systems, and encipher and decipher for encipherment systems. The signature and the decipherment transformation 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 …
Modified
p. 17 → 16
Attestation The act of attestation in this standard is the interaction between a verifier (possibly server-based) and a prover (possibly client-based) to determine the current security state/behavior of the prover based on predefined measurements and thresholds provided by the prover.
Attestation The act of attestation in this standard is the interaction between a verifier (possibly server-based) and a prover (possibly client-based) to determine the current security state/behavior of the prover based on predefined measurements and thresholds provided by the prover.
Modified
p. 17 → 16
Attestation system The set of components that perform attestation processing for the PIN CVM Solution. Its components include the PIN CVM Application attestation component and the back-end attestation component•the latter works in close association with the back-end monitoring system.
Attestation system The set of components that perform attestation processing for the PIN CVM solution. Its components include the PIN CVM application attestation component and the back-end attestation component•the latter works in close association with the back-end monitoring system.
Modified
p. 17 → 16
Attestation component An element of the PIN CVM Solution that performs attestation processing.
Attestation component An element of the PIN CVM solution that performs attestation processing.
Modified
p. 17 → 16
Back-end systems The set of systems providing the server-side functionality of the PIN CVM solution. These functionalities include monitoring, attestation, and transaction processing. In addition, the back-end systems include the IT environments necessary to support the functionalities of the PIN CVM solution.
Modified
p. 17
CDE Acronym for “cardholder data environment.” The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data.
Removed
p. 18
CDE Acronym for “cardholder data environment.” The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data.
Deterministic Random Number Generator (DRNG) See Pseudo Random Number Generator (PRNG).
Deterministic Random Number Generator (DRNG) See Pseudo Random Number Generator (PRNG).
Modified
p. 18 → 17
Cardholder data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.
Cardholder data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date, and/or service code.
Modified
p. 18 → 17
See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.
See sensitive authentication data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.
Modified
p. 18 → 17
Cardholder Verification Method (CVM) A method of authenticating a cardholder during a transaction. Common CVMs include signature, PIN and biometrics.
Cardholder Verification Method (CVM) A method of authenticating a cardholder during a transaction. Common CVMs include signature, PIN, and biometrics.
Modified
p. 18 → 17
Commercial off-the- shelf (COTS) Device A mobile device (e.g., smartphone or tablet) that is designed for mass-market distribution and is not designed specifically for payment processing.
Commercial Off-The- Shelf (COTS) device A mobile device (e.g., smartphone or tablet) that is designed for mass-market distribution.
Modified
p. 18 → 17
Compiling Translation of computer code from one format into another format. Usually used to take human-readable “source” code and transform this into a format that can be executed by a specific platform or execution environment.
Compiling Translation of computer code from one format into another format. Usually used to take human-readable “source” code and transform this into a format that can be executed by a specific platform or execution environment.
Modified
p. 18 → 17
Examples might include time and date stamps, device identifying information and loyalty program identifiers.
Examples might include time and date stamps, device identifying information, and loyalty program identifiers.
Modified
p. 18 → 17
COTS Platform The hardware of the COTS device.
COTS platform The hardware of the COTS device.
Modified
p. 18 → 17
Dual Control A process of using two or more separate entities (usually persons), operating in concert, to protect sensitive functions or information. Each entity is equally responsible for the physical protection of materials involved in vulnerable processes. No single person must be able to access or to use the materials (e.g., cryptographic key). For manual key generation, conveyance, loading, storage and retrieval, dual control requires split knowledge of the key among the entities. No single person can gain control of …
Dual control A process of using two or more separate entities (usually persons), operating in concert, to protect sensitive functions or information. Each entity is equally responsible for the physical protection of materials involved in vulnerable processes. No single person must be able to access or to use the materials (e.g., cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires split knowledge of the key among the entities. No single person can gain control of …
Modified
p. 19 → 18
EMVCo A privately-owned corporation. The current members of EMVCo are JCB International, American Express, Mastercard, China UnionPay, Discover Financial and Visa Inc.
EMVCo A privately owned corporation. The current members of EMVCo are JCB International, American Express, Mastercard, China UnionPay, Discover Financial, and Visa Inc.
Modified
p. 19 → 18
Endpoint An interface exposed by a communicating entity or channel, i.e. a node originating or accepting a transaction session.
Endpoint An interface exposed by a communicating entity or channel, i.e., a node originating or accepting a transaction session.
Modified
p. 19 → 18
Environment The IT environment supporting one or more functionalities of the PIN CVM Solution•such as the IT environment hosting the back-end monitoring system.
Environment The IT environment supporting one or more functionalities of the PIN CVM solution•such as the IT environment hosting the back-end monitoring system.
Modified
p. 19 → 18
Full screen mode Where the PIN CVM Application that is currently executing is in control of the primary display and input mechanism(s) of the COTS device. A full screen mode may still include display features that are controlled and/or managed by the COTS Operating System but may not include any display from other applications. It is assumed by this standard that full screen mode mitigates the use of any separately controlled or managed displays or input mechanisms to display prompts …
Full screen mode Where the PIN CVM application that is currently executing is in control of the primary display and input mechanism(s) of the COTS device. A full screen mode may still include display features that are controlled and/or managed by the COTS operating system but may not include any display from other applications. It is assumed by this standard that full screen mode mitigates the use of any separately controlled or managed displays or input mechanisms to display prompts …
Modified
p. 19 → 18
Graphical user interface (GUI) A user interface that is provided through images and text.
Graphical User Interface (GUI) A User Interface that is provided through images and text.
Modified
p. 19 → 18
Hash A (mathematical) function that is a non-secret algorithm, which takes any arbitrary-length message as input and produces a fixed-length hash result.
Hash A (mathematical) function that is a non-secret algorithm, which takes any arbitrary-length message as input and produces a fixed-length hash result.
Modified
p. 19 → 18
a) One-way
• It is computationally infeasible to find any input that maps to anypre-specified output.
• It is computationally infeasible to find any input that maps to any
a) One-way
• It is computationally infeasible to find any input that maps to any pre-specified output.
• It is computationally infeasible to find any input that maps to any pre-specified output.
Modified
p. 19 → 18
b) Collision-resistant
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
b) Collision-resistant
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
Modified
p. 19 → 18
It may be used to reduce a potentially long message into a “hash value” or “message digest” that is 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.
It may be used to reduce a potentially long message into a “hash value” or “message digest” that is 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.
Modified
p. 20 → 19
Integrity Ensuring consistency of data;; in particular, preventing unauthorized and undetected creation, alteration or destruction of data.
Integrity Ensuring consistency of data; in particular, preventing unauthorized and undetected creation, alteration or destruction of data.
Modified
p. 20 → 19
Just-In-Time (JIT) compilation Compiling of code immediately prior to the execution of that code.
Modified
p. 20 → 19
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 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.
Modified
p. 20 → 19
Key generation Creation of a cryptographic key either from a random number generator or through a one-way process utilizing another cryptographic key.
Key generation Creation of a cryptographic key either from a Random Number Generator or through a one-way process utilizing another cryptographic key.
Modified
p. 20 → 19
Key installation Loading of a key that is protected with white-box cryptography, usually embedded within an application.
Key installation Loading of a key that is protected with white-box cryptography, usually embedded within an application.
Modified
p. 20 → 19
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 and use, deletion, destruction and archiving.
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, and use, deletion, destruction, and archiving.
Modified
p. 20 → 19
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 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. 20 → 19
Key check value (KCV) A value used to identify a key without revealing any bits of the actual key itself. Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result;; where n is at most 24 bits (6 hexadecimal digits/3 bytes TDEA and 5 bytes AES). This method may be used for TDEA. TDEA may optionally use, and AES uses a technique where the KCV …
Key Check Value (KCV) A value used to identify a key without revealing any bits of the actual key itself. Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes TDEA and 5 bytes AES). This method may be used for TDEA. TDEA may optionally use, and AES uses a technique where the KCV …
Modified
p. 21 → 20
Man-In-The-Middle (MITM) attack An attack method where a malicious third party interposes between two other communicating parties and modifies the data sent between them.
Modified
p. 21 → 20
Manual key loading Loading of a cryptographic key using two or more full-length components or use m-of-n shares, entered directly through a secure physical mechanism.
Manual key loading Loading of a cryptographic key using two or more full-length components or use m-of-n shares, entered directly through a secure physical mechanism.
Modified
p. 21 → 20
Minor OS version A minor OS version is where further customization has been performed by the device manufacturer or distributor, such that the operating system has been modified beyond the major version. A minor OS version includes only modifications where the underlying operations have not been modified, and not modifications that are made solely at the “application” level¾such as simple “skinning” of a common operating system base so it appears unique.
Minor OS version A minor OS version is where further customization has been performed by the device manufacturer or distributor, such that the operating system has been modified beyond the major version. A minor OS version includes only modifications where the underlying operations have not been modified, and not modifications that are made solely at the “application” level − such as simple “skinning” of a common operating system base so it appears unique.
Modified
p. 21 → 20
Mobile device In the context of this standard, see COTS.
Mobile device In the context of this standard, see COTS device.
Modified
p. 21 → 20
M of N An m-of-n scheme is a component or share allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone.
M of N An m-of-n scheme is a component or share allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone.
Modified
p. 21 → 20
Monitor In this standard, the “monitor” is an implementation that may be shared across different execution environments, which provides a level of validation and assurance of the execution environment in which the PIN CVM Application executes, providing a level of software-based tamper detection and response. The monitor must be capable of being regularly updated to detect and respond to new threats.
Monitor In this standard, the “monitor” is an implementation that may be shared across different execution environments, which provides a level of validation and assurance of the execution environment in which the PIN CVM application executes, providing a level of software-based tamper detection and response. The monitor must be capable of being regularly updated to detect and respond to new threats.
Removed
p. 22
PIN CVM Application All parts of the code, regardless of execution environment, that are installed and executed on the merchant COTS device for the purposes of accepting and processing the cardholder’s PIN. The client-side monitor and/or a payment application may be incorporated into the PIN CVM Application or may be a separate application.
Modified
p. 22 → 21
Offline payment transaction In an offline EMV transaction, the card and terminal communicate and use issuer-defined risk parameters that are set in the card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online connectivity
•e.g., at a ticket kiosk
•or in countries where telecommunications costs are high.
•e.g., at a ticket kiosk
•or in countries where telecommunications costs are high.
Offline payment transaction In an offline EMV transaction, the card and terminal communicate and use issuer-defined risk parameters that are set in the card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online connectivity
•e.g., at a ticket kiosk
•or in countries where telecommunications costs are high.
•e.g., at a ticket kiosk
•or in countries where telecommunications costs are high.
Modified
p. 22 → 21
Operating system (OS) System software that manages the underlying hardware and software resources and provides common services for programs. Common operating systems in a COTS environment include, but are not limited to, Android and iOS.
Operating System (OS) System software that manages the underlying hardware and software resources and provides common services for programs. Common operating systems in a COTS environment include, but are not limited to, Android and iOS.
Modified
p. 22 → 21
PCI PIN A PCI standard that contains a complete set of requirements for the secure management, processing and transmission of personal identification number (PIN) data during online and offline payment card transaction processing at automated teller machines (ATMs) and attended and unattended point-of- sale (POS) terminals.
PCI PIN A PCI standard that contains a complete set of requirements for the secure management, processing and transmission of Personal Identification Number data during online and offline payment card transaction processing at automated teller machines (ATMs) and attended and unattended point-of- sale (POS) terminals.
Modified
p. 22 → 21
Personal identification number (PIN) A numeric personal identification code that authenticates a cardholder. A PIN consists only of decimal digits.
Personal Identification Number (PIN) A numeric personal identification code that authenticates a cardholder. A PIN consists only of decimal digits.
Modified
p. 22
PIN CVM Solution (“The Solution”) The set of components and processes that support the entry of PIN data in to a COTS device. At a minimum, The Solution includes SCRP, PIN CVM Application and the back-end systems and environments that perform attestation, monitoring and payment and online PIN processing.
PIN CVM solution (“the solution”) The set of components and processes that support the entry of PIN data into a COTS device. At a minimum, the solution includes SCRP, PIN CVM application, and the back-end systems and environments that perform attestation, monitoring and payment and online PIN processing.
Removed
p. 23
Pseudo Random Number Generator (PRNG) A deterministic algorithm to generate a sequence of numbers with little or no discernible pattern in the numbers, except for broad statistical properties.
Secure reading and exchange of data (SRED) Module 4 of the PCI PTS POI Standard, detailing the requirements for devices that protect account data.
Secure reading and exchange of data (SRED) Module 4 of the PCI PTS POI Standard, detailing the requirements for devices that protect account data.
Modified
p. 23 → 22
Public key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and may be made public.
Public key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and may be made public.
Modified
p. 23 → 22
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.
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.
Modified
p. 23 → 22
Public key cryptography See Asymmetric Encryption.
Public key cryptography See asymmetric encryption.
Modified
p. 23 → 22
Random Number Generator (RNG) The process of generating values with a high level of entropy and that 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 Number Generator (RNG) The process of generating values with a high level of entropy and that 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.
Modified
p. 23 → 22
RSA An asymmetric encryption algorithm that was defined by the cryptographers Rivest, Shamir and Aldeman.
RSA An asymmetric encryption algorithm that was defined by the cryptographers Rivest, Shamir, and Aldeman.
Modified
p. 23 → 22
Secure Boot See Trusted Boot.
Secure boot See trusted boot.
Modified
p. 23 → 22
Secure card reader
• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website.
• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website.
Secure Card Reader
• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website.
• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website.
Modified
p. 23 → 22
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. Examples include ANSI X9.24 part 1 or ISO 13491.
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. Examples include ANSI X9.24 part 1 or ISO 13491.
Modified
p. 24 → 23
Sensitive Data For the purposes of this standard, sensitive data is cryptographic materials• e.g., keys, certificates, cardholder PINs or cardholder data.
Sensitive data For the purposes of this standard, sensitive data is cryptographic materials• e.g., keys, certificates, cardholder PINs, or cardholder data.
Modified
p. 24 → 23
Sensitive Services Those functions that affect underlying processes that support the protection of sensitive data•e.g., cryptographic keys, PINs and cardholder data.
Sensitive services Those functions that affect underlying processes that support the protection of sensitive data•e.g., cryptographic keys, PINs and cardholder data.
Modified
p. 24 → 23
Split Knowledge A condition under which two or more entities separately have key components or key shares that individually convey no knowledge of the resultant cryptographic key. The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed.
Split knowledge A condition under which two or more entities separately have key components or key shares that individually convey no knowledge of the resultant cryptographic key. The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed.
Modified
p. 24 → 23
Software Protection Mechanisms Methods and implementations used to prevent the reverse engineering and modification of software. See Obfuscation and White-box cryptography as examples of commonly used software protection mechanisms.
Software protection mechanisms Methods and implementations used to prevent the reverse engineering and modification of software. See obfuscation and white-box cryptography as examples of commonly used software protection mechanisms.
Modified
p. 24 → 23
Solution Provider An entity that develops, manages and/or deploys PIN CVM Solutions.
Solution provider An entity that develops, manages and/or deploys PIN CVM solutions.
Modified
p. 24 → 23
Supported Platform The most current operating system supported by the operating system vendor.
Supported platform The current operating system supported by the operating system vendor.
Modified
p. 24 → 23
Symmetric encryption A cryptographic key that is used in symmetric cryptographic algorithms. The same symmetric key that is used for encryption is also used for decryption. Also known as “secret key.” Tamper-detection The automatic determination by a cryptographic module that an attempt has been made to compromise the security of the module.
Symmetric encryption A cryptographic key that is used in symmetric cryptographic algorithms. The same symmetric key that is used for encryption is also used for decryption. Also known as “secret key.” Tamper detection The automatic determination by a cryptographic module that an attempt has been made to compromise the security of the module.
Modified
p. 24 → 23
Tamper responsive A characteristic that provides an active response to the detection of an attack, thereby preventing a success.
Modified
p. 24 → 23
TDES An algorithm specified in ISO/IEC 18033-3: Information technology
TDES An algorithm specified in ISO/IEC 18033-3: Information technology
Modified
p. 24 → 23
The Solution See PIN CVM Solution.
The solution See PIN CVM solution.
Modified
p. 24 → 23
Third-party app stores App stores that are not supported by the COTS OS vendor and are not pre- installed by the device manufacturer.
Modified
p. 25 → 24
User interface (UI) The set of the human-machine interfaces that allows for interaction between a person and a computerized system.
User Interface (UI) The set of the human-machine interfaces that allows for interaction between a person and a computerized system.
Modified
p. 25 → 24
White-box cryptography A method used to obfuscate a cryptographic algorithm and key with the intent that the determination of the key value is computationally complex.
Modified
p. 26 → 25
PCI SSC Standards https://www.pcisecuritystandards.org/document_library DSS Data Security Standard DESV Designated Entities Supplemental Validation (Appendix A3 in PCI DSS v3.2) HSM PIN Transaction Security (PTS) Hardware Security Module Security Requirements PIN PTS PIN Security Requirements POI PTS Point of Interaction Module Security Requirements Other Industry Security References ANSI X9.24 Retail Financial Services Key Management FIPS 140-2 Federal Information Processing Standard, Security Requirements for Cryptographic Modules FIPS 186-4 Federal Information Processing Standard, Digital Signature Standard (DSS) FIPS 198-1 Federal Information Processing Standard, …
PCI SSC Standards https://www.pcisecuritystandards.org/document_library DSS Data Security Standard DESV Designated Entities Supplemental Validation (Appendix A3 in PCI DSS v3.2) HSM PIN Transaction Security (PTS) Hardware Security Module Security Requirements PIN PIN Security Requirements POI PTS Point of Interaction Modular Security Requirements Other Industry Security References ANSI X9.24 Retail Financial Services Key Management FIPS 140-2 Federal Information Processing Standard, Security Requirements for Cryptographic Modules FIPS 186-4 Federal Information Processing Standard, Digital Signature Standard (DSS) FIPS 198-1 Federal Information Processing Standard, The …
Modified
p. 28 → 27
Operations that involve secret or private cryptographic keys must be performed using split knowledge. Split knowledge requires that no one person is able to determine any single bit of a secret or cryptographic key. Split knowledge can be provided by storing keys on Secure Cryptographic Devices that will not output the plaintext key, or through use of two or more full-length components during key loading or a valid m-of-n secret-sharing scheme. Use of smartcards for storing full cryptographic keys is …
Operations that involve secret or private cryptographic keys must be performed using split knowledge. Split knowledge requires that no one person is able to determine any single bit of a secret or cryptographic key. Split knowledge can be provided by storing keys on SCDs that will not output the plaintext key, or through use of two or more full-length components during key loading or a valid m-of-n secret-sharing scheme. Use of smartcards for storing full cryptographic keys is not considered …
Modified
p. 28 → 27
TA1.1 The tester shall confirm that vendor documentation exists, is followed and updated at least annually and details all sensitive services implemented by the system. At a minimum, this shall include key loading (for all in-scope areas), signing of firmware and applications and modifications to the monitor functionality or configuration.
TA1.1 The tester shall confirm that vendor documentation exists, is followed and updated at least annually and details all sensitive services implemented by the system. At a minimum, this shall include key loading (for all in-scope areas), signing of firmware and applications and modifications to the monitor functionality or configuration.
Modified
p. 28 → 27
TA1.2 Referencing the key table produced in TR A4: Key Management, the tester shall provide details on each of the key-loading methods and procedures used in the system. This will include, but may not be limited to, loading of keys into back-end HSMs, use of white-box cryptography keys, loading of keys into the SCRP and initial provisioning of keys into the PIN CVM Application. The creation of white-box keys is an exception to the requirements in this TR.
TA1.2 Referencing the key table produced in TR A4: Key Management, the tester shall provide details on each of the key-loading methods and procedures used in the system. This will include, but may not be limited to, loading of keys into back-end HSMs, use of white-box cryptography keys, loading of keys into the SCRP and initial provisioning of keys into the PIN CVM application. The creation of white-box keys is an exception to the requirements in this TR.
Modified
p. 28 → 27
TA1.3 For each of the above key-loading methods, the tester shall confirm that it enforces dual control across the entire process, such that no one person is ever solely responsible (or can be held liable) for the security of the cryptographic key-loading or key-injection operation.
TA1.3 For each of the above key-loading methods, the tester shall confirm that it enforces dual control across the entire process, such that no one person is ever solely responsible (or can be held liable) for the security of the cryptographic key-loading or key-injection operation.
Modified
p. 28 → 27
TA1.4 Where any of the above key-loading methods involve secret or private cryptographic keys, the tester shall confirm that the process ensures split knowledge, such that no one person is ever able to determine any single bit of the actual cryptographic key.
TA1.4 Where any of the above key-loading methods involve secret or private cryptographic keys, the tester shall confirm that the process ensures split knowledge, such that no one person is ever able to determine any single bit of the actual cryptographic key.
Modified
p. 28 → 27
TA1.5 The tester shall confirm how modifications and/or updates to the monitoring system are performed and confirm that this requires dual control prior to the update "going live" in the production environment and any changes follow a formal change-control procedure.
TA1.5 The tester shall confirm how modifications and/or updates to the monitoring system are performed and confirm that this requires dual control prior to the update "going live" in the production environment and any changes follow a formal change-control procedure.
Modified
p. 29 → 28
TA1.7 For PIN CVM Applications that rely in part on security provided by a TEE, the tester shall confirm that any code or data loaded into the TEE requires a signature that is created using procedures that are compliant to the requirements for a sensitive service.
TA1.7 For PIN CVM applications that rely in part on security provided by a TEE, the tester shall confirm that any code or data loaded into the TEE requires a signature that is created using procedures that are compliant to the requirements for a sensitive service.
Modified
p. 30 → 29
Random numbers are relied upon by many security processes and secure communications methods. Generation of random numbers with insufficient entropy has been the cause of many high- profile vulnerabilities, and therefore the quality of the random numbers generated by the system is vital. Because this standard allows for the use of COTS devices that may not have a good source of entropy, it is a requirement that any random numbers used on the COTS device for security purposes must be …
Random numbers are relied upon by many security processes and secure communications methods. Generation of random numbers with insufficient entropy has been the cause of many high- profile vulnerabilities, and therefore the quality of the random numbers generated by the system is vital. Because this standard allows for the use of COTS devices that may not have a good source of entropy, it is a requirement that any random numbers used on the COTS device for security purposes must be …
Modified
p. 30 → 29
Random numbers that are not directly relied upon for security of the customer PIN, cardholder data or monitor/attestation data¾e.g. random values used in TLS sessions, where the data being transmitted is otherwise protected using application level cryptography¾do not need to meet this requirement.
Random numbers that are not directly relied upon for security of the customer PIN, cardholder data or monitor/attestation data - e.g., random values used in TLS sessions, where the data being transmitted is otherwise protected using application level cryptography - do not need to meet this requirement.
Modified
p. 30 → 29
TA2.1 The tester shall detail the implementation of all random number generation functions used in the implementation. This must include random numbers generated on all platforms supported by The Solution (assessed under TR B12: Supported Platforms), as well as random numbers generated in any back-end systems (where these random numbers are used for the purposes of providing security to the system). The intent is not to check the NRNG process used by the Operating System of each supported platform, but …
TA2.1 The tester shall detail the implementation of all random number generation functions used in the implementation. This must include random numbers generated on all platforms supported by the solution (assessed under TR B12: Supported Platforms), as well as random numbers generated in any back-end systems (where these random numbers are used for the purposes of providing security to the system). The intent is not to check the NRNG process used by the OS of each supported platform, but to …
Modified
p. 30 → 29
These details shall include any seed values used, hardware systems and software-based deterministic pseudo random number generators (DRNG).
These details shall include any seed values used, hardware systems and software-based DRNGs.
Modified
p. 30 → 29
TA2.2 The tester shall confirm that generation of random numbers on the PIN CVM Application requires input of random data (of at least 256 bits) from the SCRP using its NRNG approved through PCI PTS testing. The tester shall ensure that initializing and/or seeding of the DRNG from the SCRP in this way cannot be abused to intentionally reproduce a given random value or sequence.
TA2.2 The tester shall confirm that generation of random numbers on the PIN CVM application requires input of random data (of at least 256 bits) from the SCRP using its NRNG approved through PCI PTS testing. The tester shall ensure that initializing and/or seeding of the DRNG from the SCRP in this way cannot be abused to intentionally reproduce a given random value or sequence.
Modified
p. 30 → 29
TA2.4 The tester shall review the source code of each of these services and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
TA2.4 The tester shall review the source code of each of these services and confirm that they correctly utilize the RNG reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 30 → 29
TA2.5 The tester shall confirm that the NRNG implementation in the back-end monitoring system environment is implemented using a random number implementation approved to FIPS140-2 L3 or PCI PTS approved HSM. Where approval to FIPS140-2 L3 is used, the tester shall validate from the approval that the entropy is not externally supplied.
TA2.5 The tester shall confirm that the NRNG implementation in the back-end monitoring system environment is implemented using a random number implementation approved to FIPS140-2 L3 or PCI PTS approved HSM. Where approval to FIPS140-2 L3 is used, the tester shall validate from the approval that the entropy is not externally supplied.
Modified
p. 31 → 30
TA2.7 The tester shall obtain at least 128MB of random data from each of the DRNG implementations used in the system. This data may be supplied directly by the vendor for testing. The tester shall detail the method used to generate this data and justify why this sufficiently replicates the way in which the DRNG will be used by the system. The tester shall pass the 128MB of data through the NIST STS test program (as defined in SP 800-22) …
TA2.7 The tester shall obtain at least 128MB of random data from each of the DRNG implementations used in the system. This data may be supplied directly by the vendor for testing. The tester shall detail the method used to generate this data and justify why this sufficiently replicates the way in which the DRNG will be used by the system. The tester shall pass the 128MB of data through the NIST STS test program (as defined in NIST SP …
Modified
p. 32 → 31
The PIN must be encrypted on the COTS device for transport to the SCRP, where it is then translated under a cryptographic key shared between the SCRP and the back-end systems.
The PIN must be encrypted on the COTS device for transport to the SCRP, where it is then translated under a cryptographic key shared between the SCRP and the back-end systems .
Modified
p. 32 → 31
Encryption used to protect PIN or tamper-detection data must be performed using a key that is unique per transaction or communication session and per PIN CVM Application instance.
Encryption used to protect PIN or tamper-detection data must be performed using a key that is unique per transaction or communication session and per PIN CVM application instance.
Modified
p. 32 → 31
Customer PINs transmitted from the SCRP to the PCI PIN-compliant processing host may be encrypted using TDES as the only exception to these requirements.
Customer PINs transmitted from the SCRP to the PCI PIN-compliant processing host may be encrypted using TDES as the only exception to these requirements.
Modified
p. 32 → 31
TA3.1 The tester shall provide a list of all cryptographic operations used by the system for security services and note the cryptographic algorithm used for each of these cryptographic operations. This must include (but not be limited to) any cipher suites or other cryptographic algorithms implemented within transport layer protocols that are used for Secure Channels (as assessed under TR D2: Secure Channels).
TA3.1 The tester shall provide a list of all cryptographic operations used by the system for security services and note the cryptographic algorithm used for each of these cryptographic operations. This must include (but not be limited to) any cipher suites or other cryptographic algorithms implemented within transport layer protocols that are used for secure channels (as assessed under TR D2: Secure Channels).
Modified
p. 32 → 31
TA3.2 Given the above, the tester shall confirm that these algorithms meet the minimum requirements outlined in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved AlgorithmsAppendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. Where key derivation methods are used for creating the transaction unique key, the tester shall verify that the method is not reversible and provides perfect forward secrecy.
TA3.2 Given the above, the tester shall confirm that these algorithms meet the minimum requirements outlined in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. Where key derivation methods are used for creating the transaction unique key, the tester shall verify that the method is not reversible and provides perfect forward secrecy.
Modified
p. 32 → 31
TA3.3 The tester shall confirm that the PIN CVM Application and SCRP ensure that PIN data is encrypted with a unique key for each transaction, and detail the methods used to generate this key.
TA3.3 The tester shall confirm that the PIN CVM application and SCRP ensure that PIN data is encrypted with a unique key for each transaction, and detail the methods used to generate this key.
Modified
p. 32 → 31
TA3.4 The tester shall confirm that the monitoring system ensures that any tamper-detection or response messages are communicated between the COTS and back-end monitoring systems using a unique key per session.
TA3.4 The tester shall confirm that the monitoring system ensures that any tamper-detection or response messages are communicated between the COTS and back-end monitoring systems using a unique key per session.
Modified
p. 33 → 32
This requirement applies to components of The Solution, including back-end components, the PIN CVM Application, the monitoring system and the SCRP. Where software encryption is used
•e.g.,white-box cryptography •key-management practices must adhere to requirements specified in Module 2: PIN CVM Application Requirements.
•e.g.,
This requirement applies to components of the solution, including back-end components, the PIN CVM application, the monitoring system and the SCRP. Where software encryption is used
•e.g., white-box cryptography •key-management practices must adhere to requirements specified in Module 2: PIN CVM Application Requirements.
•e.g., white-box cryptography •key-management practices must adhere to requirements specified in Module 2: PIN CVM Application Requirements.
Modified
p. 33 → 32
Additional information on PKI can be found in X9.79-4.
Additional information on PKI can be found in X9.79-4.
Modified
p. 33 → 32
TA4.1 The tester shall provide a separate "key table" for each of the in-scope areas of the current assessment¾i.e., relevant PIN CVM Application(s), SCRP, back-end monitoring/attestation system¾that outlines all cryptographic keys used in the system that are relied upon for the security of the PIN or overall system security. This key table shall have at least the following columns: key name, key purpose, key size, key location¾e.g., device/system/memory location, as appropriate¾algorithm, method used to load/generate key, whether the key is …
TA4.1 The tester shall provide a separate "key table" for each of the in-scope areas of the current assessment − i.e., relevant PIN CVM application(s), SCRP, back-end monitoring/attestation system − that outlines all cryptographic keys used in the system that are relied upon for the security of the PIN or overall system security. This key table shall have at least the following columns: key name, key purpose, key size, key location − e.g., device/system/memory location, as appropriate − algorithm, method …
Modified
p. 33 → 32
Key purpose Key location Algorithm How loaded/ generated/ TA4.2 The tester shall detail any key-generation or key-agreement processes that are used by the system and confirm that they ensure that keys are generated with equivalent entropy¾e.g., a 128-bit key is generated with 128 bits of entropy input.
Key purpose Key location Algorithm How loaded/ generated/ TA4.2 The tester shall detail any key-generation or key-agreement processes that are used by the system and confirm that they ensure that keys are generated with equivalent entropy − e.g., a 128-bit key is generated with 128 bits of entropy input.
Modified
p. 33 → 32
TA4.3 Where padding is used prior to/during encryption methods, the tester shall detail the padding methodology implemented and confirm that asymmetric encryption always implements industry- standard padding methods.
TA4.3 Where padding is used prior to/during encryption methods, the tester shall detail the padding methodology implemented and confirm that asymmetric encryption always implements industry- standard padding methods.
Modified
p. 34 → 33
• Managed under a valid m-of-n secret-sharing scheme TA4.5 The tester shall confirm that no reversible key calculation modes (such as key variants) are used to directly create new keys from an existing key. All key-generation functions must implement One-way Functions or other irreversible key-generation processes.
Modified
p. 34 → 33
TA4.8 The tester shall confirm that security is not provided to any key by a key of lesser strength (e.g., by encrypting a 256-bit AES key with a 128-bit AES key).
TA4.8 The tester shall confirm that security is not provided to any key by a key of lesser strength (e.g., by encrypting a 256-bit AES key with a 128-bit AES key).
Modified
p. 34 → 33
TA4.9 For any public keys used by the system, the tester shall confirm how the authenticity of that public key is maintained. Use of public keys that are not signed or MAC’d, or that are maintained in self-signed certificates, is prohibited unless the authenticity of the key is ensured through use of an SCD instead. Self-signed certificates that exist as part of the base COTS platform on which the PIN CVM Application is executed are excluded from this requirement. However, …
TA4.9 For any public keys used by the system, the tester shall confirm how the authenticity of that public key is maintained. Use of public keys that are not signed or MAC’d, or that are maintained in self-signed certificates, is prohibited unless the authenticity of the key is ensured through use of an SCD instead. Self-signed certificates that exist as part of the base COTS platform on which the PIN CVM application is executed are excluded from this requirement. However, …
Modified
p. 34 → 33
TA4.11 The tester shall confirm that each key has a single unique purpose and that no keys are used for multiple purposes (such as both signing and encrypting data), and that keys used to encrypt PIN data are not used for any other operation (such as general-purpose data encryption or monitor message encryption, etc.).
TA4.11 The tester shall confirm that each key has a single unique purpose and that no keys are used for multiple purposes (such as both signing and encrypting data), and that keys used to encrypt PIN data are not used for any other operation (such as general-purpose data encryption or monitor message encryption, etc.).
Modified
p. 34 → 33
TA4.13 The tester shall confirm that, with the exception of any white-box keys, secret cryptographic keys are stored and maintained using key wrapping techniques.
TA4.13 The tester shall confirm that, with the exception of any white-box keys, secret cryptographic keys are stored and maintained using key wrapping techniques.
Modified
p. 34 → 33
TA4.14 The tester shall confirm that, with the exception of any white-box keys, all secret and private keys are unique to each COTS device, PIN CVM Application instantiation or SCRP. Use of a single asymmetric key pair across multiple devices is acceptable where the public key resides on one or more COTS devices and the private key is secured within an HSM on the back-end system.
TA4.14 The tester shall confirm that, with the exception of any white-box keys, all secret and private keys are unique to each COTS device, PIN CVM application instantiation or SCRP. Use of a single asymmetric key pair across multiple devices is acceptable where the public key resides on one or more COTS devices and the private key is secured within an HSM on the back-end system.
Modified
p. 34 → 33
TA4.15 The tester shall note where public or white-box keys are not unique per COTS device, PIN CVM Application instantiation or SCRP and confirm that methods and procedures to revoke and/or replace such keys (or key pairs) if compromised exist.
TA4.15 The tester shall note where public or white-box keys are not unique per COTS device, PIN CVM application instantiation or SCRP and confirm that methods and procedures to revoke and/or replace such keys (or key pairs) if compromised exist.
Removed
p. 35
§ Standalone (e.g., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);; § Dedicated to only the white-box generation function (i.e., there must not be any other application software installed);; and § Located in a physically secure room that is dedicated to the white-box generation activities.
Modified
p. 35 → 34
TA4.17 The tester shall verify that a mechanism exists for generation of audit logs for all key- management activities and all activities involving clear-text key components. The tester shall verify the audit log mechanism includes integrity protections against unauthorized modifications or deletions.
TA4.17 The tester shall verify that a mechanism exists for generation of audit logs for all key- management activities and all activities involving clear-text key components. The tester shall verify the audit log mechanism includes integrity protections against unauthorized modifications or deletions.
Modified
p. 35 → 34
TA4.19 The tester shall confirm that cryptographic keys to which customer PINs are translated within the SCRP are controlled by the payment acquirer and generated/managed within the PCI PIN- compliant environment (as assessed under TR E2: PCI PIN Compliance).
TA4.19 The tester shall confirm that cryptographic keys to which customer PINs are translated within the SCRP are controlled by the payment acquirer and generated/managed within the PCI PIN- compliant environment (as assessed under TR E2: PCI PIN Compliance).
Modified
p. 36 → 35
This requirement covers the development of software for all aspects of The Solution, including the PIN CVM Application, SCRP code and back-end monitoring system.
This requirement covers the development of software for all aspects of the solution, including the PIN CVM application, SCRP code and back-end monitoring system.
Modified
p. 36 → 35
TA5.1 The tester shall confirm that all software is developed according to the development process and to the development requirements outlined in the PCI Software-based PIN Entry on COTS Security Requirements, Appendix D
• Application Security Requirements.
• Application Security Requirements.
TA5.1 The tester shall confirm that all software is developed according to the development process and to the development requirements outlined in the PCI Software-based PIN Entry on COTS Security Requirements, Appendix D
• Application Security Requirements.
• Application Security Requirements.
Modified
p. 37 → 36
Processes for detecting security vulnerabilities must include confirming the security of the system baseline, as well as any vendor-developed code. Penetration tests may be performed by internal staff, but any penetration testers must be able to demonstrate skill and knowledge in the art through formal accreditation to standards such as CREST and/or OSCP. System vendors must have an active vulnerability-reporting and management program that is commensurate with industry best practice and must be able to demonstrate remediation of security vulnerabilities …
Processes for detecting security vulnerabilities must include confirming the security of the system baseline, as well as any vendor-developed code. Penetration tests may be performed by internal staff, but any penetration testers must be able to demonstrate skill and knowledge in the art through formal accreditation to standards such as CREST and/or OSCP. System vendors must have an active vulnerability-reporting and management program that is commensurate with industry best practice and must be able to demonstrate remediation of security vulnerabilities …
Modified
p. 37 → 36
The scope of any vulnerability-reporting programs must include all consumer accessible systems, including the PIN CVM Application itself as well as the protocols used to communicate between the PIN CVM Application, SCRP and back-end monitoring systems.
The scope of any vulnerability-reporting programs must include all consumer-accessible systems, including the PIN CVM application itself as well as the protocols used to communicate between the PIN CVM application, SCRP and back-end monitoring systems.
Modified
p. 37 → 36
Penetration testing must include the PIN CVM Application and back-end monitoring environment.
Penetration testing must include the PIN CVM application and back-end monitoring environment.
Modified
p. 37 → 36
The requirement to institute a vulnerability-management program does not replace the requirement to perform penetration testing. Both must be implemented for compliance to this TR.
The requirement to institute a vulnerability-management program does not replace the requirement to perform penetration testing. Both must be implemented for compliance to this TR.
Modified
p. 37 → 36
TA6.1 The tester shall confirm that if a vulnerability-reporting program exists for the system, there is evidence of accepting and remediating security vulnerabilities found through this program. The vendor must be able to demonstrate that any such vulnerabilities are processed through its risk and update process and patched accordingly.
TA6.1 The tester shall confirm that if a vulnerability-reporting program exists for the system, there is evidence of accepting and remediating security vulnerabilities found through this program. The vendor must be able to demonstrate that any such vulnerabilities are processed through its risk and update process and patched accordingly.
Modified
p. 37 → 36
TA6.3 The tester shall confirm that a penetration test has been performed on the system. The scope of the penetration test(s) must include all devices and operating systems within the system baseline. The tester shall further confirm that a documented policy exists to require the repeat of the penetration test at least every year. Where sampling is performed, the tester shall validate the sampling is appropriate.
TA6.3 The tester shall confirm that a penetration test has been performed on the system. The scope of the penetration test(s) must include all devices and OSs within the system baseline. The tester shall further confirm that a documented policy exists to require the repeat of the penetration test at least every year. Where sampling is performed, the tester shall validate the sampling is appropriate.
Modified
p. 37 → 36
TA6.5 The tester shall confirm that there is a public-facing procedure for the reporting of vulnerabilities in The Solution. This procedure must implement methods to ensure the confidentiality of the vulnerability as it is reported (e.g., a process that requires the reporting of a vulnerability to a shared "info@[company]" e-mail address, without additional encryption, would be non-compliant to this requirement). Use of a specific web portal secured with TLS (using acceptable cipher suites) and/or e-mails secured with strong cryptography are …
TA6.5 The tester shall confirm that there is a public-facing procedure for the reporting of vulnerabilities in the solution. This procedure must implement methods to ensure the confidentiality of the vulnerability as it is reported (e.g., a process that requires the reporting of a vulnerability to a shared "info@[company]" e-mail address, without additional encryption, would be non-compliant to this requirement). Use of a specific web portal secured with TLS (using acceptable cipher suites) and/or e-mails secured with strong cryptography are …
Modified
p. 37 → 36
TA6.6 The tester shall obtain a list of vulnerabilities reported through the vulnerability-management program and penetration testing and validate that these have been addressed as per the vendor’s documented vulnerability-management program.
TA6.6 The tester shall obtain a list of vulnerabilities reported through the vulnerability-management program and penetration testing and validate that these have been addressed as per the vendor’s documented vulnerability-management program.
Modified
p. 38 → 37
Obfuscation must reduce the efficacy of common tools that may be used for decompilation of the code. Obfuscation methods may include, but not be limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, API renaming, etc. Where the application is provided as a number of files (i.e., libraries) note what protections are provided for the calls between the libraries.
Obfuscation must reduce the efficacy of common tools that may be used for decompilation of the code. Obfuscation methods may include, but not be limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, API renaming, etc. Where the application is provided as a number of files (i.e., libraries) note what protections are provided for the calls between the libraries.
Modified
p. 38 → 37
These protections are not required across all code, but must be implemented to protect all code that provides PIN CVM Application security features, such that code complexity can be demonstrated to be significantly increased, or execution can be shown to be possible only on un-modified environments¾e.g., through use of a device Physically Unclonable Function to encrypt data/execution, or by implementing the PIN application code in a trustlet that can be executed only in a secure TEE.
These protections are not required across all code, but must be implemented to protect all code that provides PIN CVM application security features, such that code complexity can be demonstrated to be significantly increased, or execution can be shown to be possible only on un-modified environments - e.g., through use of a device Physically Unclonable Function to encrypt data/execution, or by implementing the PIN application code in a trustlet that can be executed only in a secure TEE.
Modified
p. 38 → 37
This requirement is not intended to cover any tamper-detection or response features that may be provided by the combination of the PIN CVM Application and the system monitor, or inherently provided by the platform itself (e.g., a tamper-responsive SCRP or when the platform on which the PIN CVM Application executes provides some forms of tamper-responsive features). Such requirements are covered under TR C2: System Tamper Response. This B1 requirement covers only tamper-resistance features that are wholly integrated and incorporated into …
This requirement is not intended to cover any tamper-detection or response features that may be provided by the combination of the PIN CVM application and the system monitor, or inherently provided by the platform itself (e.g., a tamper-responsive SCRP or when the platform on which the PIN CVM application executes provides some forms of tamper-responsive features). Such requirements are covered under TR C2: System Tamper Response. This B1 requirement covers only tamper-resistance features that are wholly integrated and incorporated into …
Modified
p. 38 → 37
The tester is required to develop costings for the most feasible attack for this requirement. Although minimum costing point values are not specified in this version of the standard, the quality and efficacy of the monitoring system is considered vital for the security of the overall Software-based PIN Entry on COTS solution. Therefore, it is to be considered a non-compliance if values of “low” are assigned to any of the monitor items in the costing produced.
The tester is required to develop costings for the most feasible attack for this requirement. Although minimum costing point values are not specified in this version of the standard, the quality and efficacy of the monitoring system is considered vital for the security of the overall Software-based PIN Entry on COTS solution. Therefore, it is to be considered a non-compliance if values of “low” are assigned to any of the monitor items in the costing produced.
Removed
p. 39
§ Examine provided application installation files where the protection methods have been applied, and through review of these (and comparison to files where protections have not yet been applied) comment on the validity of the vendor attestations and documentation regarding protection methods implemented § Comment on the comparative file sizes between unprotected and protected application samples, as well as the relative compression ratio of each file type when standard compression functions are applied (directly to each obfuscated code segment) § Attempt extraction of data objects (such as ASCII strings and symbols) and functional linking/interface tables (such as PLT/GOT), and note any differences between code sets before and after the obfuscation process § Analyze and comment on the comparative code flow and linkage between the code before and after the obfuscation process § Note and comment on any areas of non-traditional execution, where the obfuscation relies on virtualized/interpreted commands, non-deterministic operations …
Modified
p. 39 → 38
TB1.4 Where cryptography is applied to the code for the purposes of obfuscation and anti-tamper, the tester shall note what areas are protected, what protection is provided by the cryptography (confidentiality, integrity or both) and what algorithms are used, and confirm that these meet the requirements of TR A3: Acceptable Cryptography. The tester shall further note how any keys used for these cryptographic operations are protected. Any such keys must be referenced in the key table of this report (see …
TB1.4 Where cryptography is applied to the code for the purposes of obfuscation and anti-tamper, the tester shall note what areas are protected, what protection is provided by the cryptography (confidentiality, integrity or both) and what algorithms are used, and confirm that these meet the requirements of TR A3: Acceptable Cryptography. The tester shall further note how any keys used for these cryptographic operations are protected. Any such keys must be referenced in the key table of this report (see …
Modified
p. 39 → 38
The intent of this test item is for the tester to detail the security features of the obfuscation as implemented within the code of the PIN CVM Application, so that this information may be used during the analysis attempt to break the obfuscation.
The intent of this test item is for the tester to detail the security features of the obfuscation as implemented within the code of the PIN CVM application, so that this information may be used during the analysis attempt to break the obfuscation.
Modified
p. 39 → 38
• Confirm that the supported platforms (as assessed in TR B12: Supported Platforms) provide the required tamper-resistance features and can be used for the PIN CVM application
Modified
p. 40 → 39
The intent of this test item is for the tester to detail the security features of the PIN CVM Application tamper resistance as implemented and relied upon by the operating environment, so that this information may be used during the analysis attempt to break the obfuscation.
The intent of this test item is for the tester to detail the security features of the PIN CVM application tamper resistance as implemented and relied upon by the operating environment, so that this information may be used during the analysis attempt to break the obfuscation.
Modified
p. 40 → 39
TB1.7 The tester shall document any additional protections provided by the application;; such protections may include, but may not be limited to, compile-time protection options used, virtualized execution or other hardware level abstraction to the application operation, etc. The tester shall confirm that these protections apply across supported platforms (as assessed under TR B12: Supported Platforms) or detail where any gaps exist in coverage of these protections and justify why this does not increase the risk posed by those platforms.
TB1.7 The tester shall document any additional protections provided by the application; such protections may include, but may not be limited to, compile-time protection options used, virtualized execution or other hardware level abstraction to the application operation, etc. The tester shall confirm that these protections apply across supported platforms (as assessed under TR B12: Supported Platforms) or detail where any gaps exist in coverage of these protections and justify why this does not increase the risk posed by those platforms.
Modified
p. 40 → 39
TB1.8 The tester shall attempt to circumvent the tamper-resistance properties and subvert the normal operation of the PIN CVM Application for the purposes of capturing or compromising the PIN entry and processing. This must be done without tamper-detection and response features of the monitor environment active, to demonstrate entirely and solely the protection provided by the tamper-resistance features alone. It is expected that the tester shall consider use of state- of-the-art techniques used in the reverse engineering of malware and …
TB1.8 The tester shall attempt to circumvent the tamper-resistance properties and subvert the normal operation of the PIN CVM application for the purposes of capturing or compromising the PIN entry and processing. This must be done without tamper-detection and response features of the monitor environment active, to demonstrate entirely and solely the protection provided by the tamper-resistance features alone. It is expected that the tester shall consider use of state- of-the-art techniques used in the reverse engineering of malware and …
Modified
p. 40 → 39
TB1.9 Based on the above testing and information, the tester shall provide a costing of an attack to bypass the tamper-resistance properties of the PIN CVM Application, using the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework. This costing should not consider the monitor aspect of the solution, only the tamper-resistance features of the local PIN CVM Application.
TB1.9 Based on the above testing and information, the tester shall provide a costing of an attack to bypass the tamper-resistance properties of the PIN CVM application, using the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework. This costing should not consider the monitor aspect of the solution, only the tamper-resistance features of the local PIN CVM application.
Modified
p. 41 → 40
Without additional protections, it may be possible for another application executing within the COTS device to recover information about the PIN through monitoring of on-device sensors. The movement of the COTS device during the entry of the PIN can be directly correlated to the location of the customer data entry (and therefore the PIN value). Similar recovery may be performed by using the device camera or microphone to capture the movement of the customer's hands or use of the device …
Without additional protections, it may be possible for another application executing within the COTS device to recover information about the PIN through monitoring of on-device sensors. The movement of the COTS device during the entry of the PIN can be directly correlated to the location of the customer data entry (and therefore the PIN value). Similar recovery may be performed by using the device camera or microphone to capture the movement of the customer's hands or use of the device …
Modified
p. 41 → 40
TB2.1 The tester shall document the features implemented by the PIN CVM Application to mitigate the use of on-device sensors to determine the value of the PIN during entry.
TB2.1 The tester shall document the features implemented by the PIN CVM application to mitigate the use of on-device sensors to determine the value of the PIN during entry.
Modified
p. 41 → 40
TB2.2 Where the system vendor claims that the PIN used is not vulnerable to exposure through use of on-device sensors, the tester shall justify and provide test evidence to support whether this is considered to be correct¾if so, no further testing is required for this TR. For all systems, PIN entry must meet the provisions of this TR.
TB2.2 Where the system vendor claims that the PIN used is not vulnerable to exposure through use of on-device sensors, the tester shall justify and provide test evidence to support whether this is considered to be correct − if so, no further testing is required for this TR. For all systems, PIN entry must meet the provisions of this TR.
Modified
p. 41 → 40
TB2.5 Where the mitigation features involve the disabling of on-device sensors during PIN entry, the tester shall confirm that this covers all sensors defined in the testing requirement above. The tester shall use this definition of the sensors and vendor mitigation measures to define a test plan to assess the effectiveness of these mitigations. The tester should also consider sensors that the vendor states are disabled or otherwise mitigated and perform tests to assess the efficacy of this mitigation. The …
TB2.5 Where the mitigation features involve the disabling of on-device sensors during PIN entry, the tester shall confirm that this covers all sensors defined in the testing requirement above. The tester shall use this definition of the sensors and vendor mitigation measures to define a test plan to assess the effectiveness of these mitigations. The tester should also consider sensors that the vendor states are disabled or otherwise mitigated and perform tests to assess the efficacy of this mitigation. The …
Modified
p. 41 → 40
TB2.6 Where the mitigation features involve the disabling of on-device sensors during PIN entry, the tester shall attempt to access sensors that may leak this data during the PIN entry process. If the sensors can be accessed and no further mitigations are applied, this requirement must be marked as non-compliant.
TB2.6 Where the mitigation features involve the disabling of on-device sensors during PIN entry, the tester shall attempt to access sensors that may leak this data during the PIN entry process. If the sensors can be accessed and no further mitigations are applied, this requirement must be marked as non-compliant.
Modified
p. 42 → 41
TB2.9 Based on the above testing and information, the tester shall provide a costing of an attack to use the on-device sensors to extract the customer PIN. This attack must consider the protections provided by all security features, including any tamper-resistance or monitor features which may protect against such attacks. The tester must use the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework for this costing.
TB2.9 Based on the above testing and information, the tester shall provide a costing of an attack to use the on-device sensors to extract the customer PIN. This attack must consider the protections provided by all security features, including any tamper-resistance or monitor features which may protect against such attacks. The tester must use the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework for this costing.
Modified
p. 43 → 42
To allow for the widest applicability of this standard, an exhaustive list of sensitive data is not provided, and this must be determined by the assessor during the evaluation. However, at all times, this list will include the customer PAN, sensitive account data, any cryptographic keys used or stored by the PIN CVM Application (even if encrypted) and the code for the PIN CVM Application and attestation component on the COTS device.
To allow for the widest applicability of this standard, an exhaustive list of sensitive data is not provided, and this must be determined by the assessor during the evaluation. However, at all times, this list will include the customer PAN, sensitive account data, any cryptographic keys used or stored by the PIN CVM application (even if encrypted) and the code for the PIN CVM application and attestation component on the COTS device.
Modified
p. 43 → 42
The security of COTS-based PIN entry is largely based on the separation of the PIN from the customer card data, using physical or cryptographic means. Although multiple layers of protection are provided to the PIN itself through compliance to this standard, a fundamental defense against fraud is provided by ensuring that the PIN and customer card data are kept separate.
The security of COTS-based PIN entry is largely based on the separation of the PIN from the account data, using physical or cryptographic means. Although multiple layers of protection are provided to the PIN itself through compliance to this standard, a fundamental defense against fraud is provided by ensuring that the PIN and account data are kept separate.
Modified
p. 43 → 42
This requirement covers the protection of the customer card data on the COTS device only, and therefore as provided by the PIN CVM Application. Protection within the SCRP or back-end monitoring systems is covered under separate TRs. Specifically, customer PIN requirements for the SCRP are covered as an approval class within the PTS POI Security Requirements, and the card data must never be exposed (or available) in plaintext outside this PCI PTS approved SCRP or payment processing environment.
This requirement covers the protection of the account data on the COTS device only, and therefore as provided by the PIN CVM application. Protection within the SCRP or back-end monitoring systems is covered under separate TRs. Specifically, customer PIN requirements for the SCRP are covered as an approval class within the PTS POI Security Requirements, and the card data must never be exposed (or available) in plaintext outside this PCI PTS approved SCRP or payment processing environment.
Modified
p. 43 → 42
TB3.1 The tester shall confirm that the full PAN and expiry date, as well as track data or track equivalent data, are not available (or required for processing) in clear text nor in encrypted form under any encryption key ever available to the PIN CVM Application outside the SCRP.
TB3.1 The tester shall confirm that the full PAN and expiry date, as well as track data or track equivalent data, are not available (or required for processing) in clear text nor in encrypted form under any encryption key ever available to the PIN CVM application outside the SCRP.
Modified
p. 43 → 42
TB3.3 The tester shall provide a block diagram that indicates where all sensitive data is available in plaintext on the merchant-side systems. This shall include, but may not be limited to, the Card Reader, the COTS rich execution environment and any TEE or physically separate security processing elements used. This diagram shall indicate the flow of sensitive data through the various elements.
TB3.3 The tester shall provide a block diagram that indicates where all sensitive data is available in plaintext on the merchant-side systems. This shall include, but may not be limited to, the Card Reader, the COTS rich execution environment and any TEE or physically separate security processing elements used. This diagram shall indicate the flow of sensitive data through the various elements.
Modified
p. 43 → 42
TB3.4 The tester shall confirm that there is no method, function, processing requirement or potential for the correlatable data to be decrypted in some other area of the in-scope systems and returned to the PIN CVM Application or COTS rich execution environment in plaintext.
TB3.4 The tester shall confirm that there is no method, function, processing requirement or potential for the correlatable data to be decrypted in some other area of the in-scope systems and returned to the PIN CVM application or COTS rich execution environment in plaintext.
Modified
p. 43 → 42
TB3.5 The tester shall confirm that the PIN CVM Application never has access to the cardholder data in plaintext, and that any reliance on, processing or authentication of the cardholder data occurs in systems that are protected from being accessed by the PIN CVM Application or COTS rich execution environments.
TB3.5 The tester shall confirm that the PIN CVM application never has access to the cardholder data in plaintext, and that any reliance on, processing or authentication of the cardholder data occurs in systems that are protected from being accessed by the PIN CVM application or COTS rich execution environments.
Modified
p. 43 → 42
TB3.6 The PIN CVM Application must protect against attacks designed to expose data in storage or memory and deploy appropriate controls including minimizing such storage post transaction completion or application time out.
TB3.6 The PIN CVM application must protect against attacks designed to expose data in storage or memory and deploy appropriate controls including minimizing such storage post transaction completion or application time out.
Modified
p. 44 → 43
TB3.8 Where the protection relies upon a TEE, security processor or other security feature of the COTS devices used, the tester shall confirm that these areas do not have access to the customer plaintext card data or any cryptographic keys that may be used to decrypt the customer card data.
TB3.8 Where the protection relies upon a TEE, security processor or other security feature of the COTS devices used, the tester shall confirm that these areas do not have access to the customer plaintext card data or any cryptographic keys that may be used to decrypt the account data.
Removed
p. 45
Where purely software methods are used for the protection of these keys¾for example, through use of "white-box" cryptography¾the specific instance used in a PIN CVM Application must be regularly changed within a period shorter than the expected time required to reverse engineer the software protections. At a minimum, changes to the white-box instance must occur at least once per month. It is acceptable to have two sets of keys during the changeover period but all "old" keys must be invalidated once the new keys are installed. This requirement does not imply that different implementations, or different algorithms, must be used each month.
Modified
p. 45 → 44
This requirement covers the security of the cryptographic keys used for protecting the PIN. This includes not only keys used to directly encrypt the PIN, but also keys used to provide a secure channel to disparate components of the system (such as the SCRP or monitor), or to provide security services to the application itself¾e.g., encrypting sections of the code for the purposes of code obfuscation.
This requirement covers the security of the cryptographic keys used for protecting the PIN. This includes not only keys used to directly encrypt the PIN, but also keys used to provide a secure channel to disparate components of the system (such as the SCRP or monitor), or to provide security services to the application itself - e.g., encrypting sections of the code for the purposes of code obfuscation.
Modified
p. 45 → 44
This requirement is not intended to cover the security of cryptographic keys in the SCRP or monitor¾these items are covered under separate requirements in the approval class for SCRP in PTS POI and TR E2: PCI PIN Compliance.
This requirement is not intended to cover the security of cryptographic keys in the SCRP or monitor − these items are covered under separate requirements in the approval class for SCRP in PTS POI and TR E2: PCI PIN Compliance.
Modified
p. 45 → 44
Use of protection mechanisms that are inherent to the platform on which the PIN CVM Application runs (e.g., hardware-backed keystore) may be acceptable in place of white-box cryptography. However, where such device-dependent security is relied upon, testing must be performed on all different types of protection provided. For example, where protection by a TEE is claimed for key security, each platform on which the PIN CVM Application runs must be confirmed to provide a secure TEE implementation. Combined approaches that …
Use of protection mechanisms that are inherent to the platform on which the PIN CVM application runs (e.g., hardware-backed keystore) may be acceptable in place of white-box cryptography. However, where such device-dependent security is relied upon, testing must be performed on all different types of protection provided. For example, where protection by a TEE is claimed for key security, each platform on which the PIN CVM application runs must be confirmed to provide a secure TEE implementation. Combined approaches that …
Modified
p. 45 → 44
TB4.1 The tester shall provide a list of the locations and protection methods provided to all cryptographic keys in the PIN CVM Application, where those keys are used for the protection of the PIN or security of the PIN CVM Application operation. This must include keys that are used for the security (encryption) of the PIN, as well as keys that are used for establishing secure channels (as per TR D2: Secure Channels), generating or whitening random data and validating …
TB4.1 The tester shall provide a list of the locations and protection methods provided to all cryptographic keys in the PIN CVM application, where those keys are used for the protection of the PIN or security of the PIN CVM application operation. This must include keys that are used for the security (encryption) of the PIN, as well as keys that are used for establishing secure channels (as per TR D2: Secure Channels), generating or whitening random data and validating …
Modified
p. 46 → 45
TB4.4 Where software protections (such as white-box cryptography) are used to protect the cryptographic keys, the tester shall confirm that these code areas/functions are integrated into the overall PIN CVM Application and are protected by the tamper-resistance features to prevent easy extraction of the code and/or use of this code as an encryption oracle.
TB4.4 Where software protections (such as white-box cryptography) are used to protect the cryptographic keys, the tester shall confirm that these code areas/functions are integrated into the overall PIN CVM application and are protected by the tamper-resistance features to prevent easy extraction of the code and/or use of this code as an encryption oracle.
Modified
p. 46 → 45
TB4.5 Where software protections (such as white-box cryptography) are used to protect the cryptographic keys, the tester shall obtain and review the full source code for the implementation. The tester shall use this to confirm that the implementation is robust and shall use this analysis as input to the attack and analysis processes required throughout this TR.
TB4.5 Where software protections (such as white-box cryptography) are used to protect the cryptographic keys, the tester shall obtain and review the full source code for the implementation. The tester shall use this to confirm that the implementation is robust and shall use this analysis as input to the attack and analysis processes required throughout this TR.
Modified
p. 46 → 45
TB4.6 For each protection method that relies upon features provided by the platform, the tester shall confirm that all the devices and operating system versions of the supported platforms (defined in TR B12: Supported Platforms) provide these features. For each instance, the tester shall note:
TB4.6 For each protection method that relies upon features provided by the platform, the tester shall confirm that all the devices and OS versions of the supported platforms (defined in TR B12: Supported Platforms) provide these features. For each instance, the tester shall note:
Modified
p. 46 → 45
• What protections are provided against side-channel analysis to recover the cryptographic keys (where the side channel may be timing-, power-, EM-based, etc.) TB4.7 For each protection method that relies on software-based protections, the test laboratory shall note:
Modified
p. 46 → 45
• How the protection method prevents side-channel and algebraic attacks (such as DCA or BGE). This must include consideration of the use of virtualized environments, monitoring of program address/data access and execution flow using methods such as statistical analysis, code lifting and exploitation of cryptographic oracles/APIs, to recover information about the cryptographic key(s).
Modified
p. 47 → 46
TB4.9 The tester shall confirm what physical test, debug or in-circuit emulation features exist on the supported platforms and consider these in any attack methods and costings produced.
TB4.9 The tester shall confirm what physical test, debug or in-circuit emulation features exist on the supported platforms and consider these in any attack methods and costings produced.
Modified
p. 47 → 46
TB4.10 Based on the above testing and information, the tester shall provide a costing of an attack to determine, extract or modify the cryptographic keys used by the PIN CVM Application for security services. The tester shall perform this costing using the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework. This costing should consider the difficulty in bypassing all tamper-resistance and monitor features of the solution, where applicable.
TB4.10 Based on the above testing and information, the tester shall provide a costing of an attack to determine, extract or modify the cryptographic keys used by the PIN CVM application for security services. The tester shall perform this costing using the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework. This costing should consider the difficulty in bypassing all tamper-resistance and monitor features of the solution, where applicable.
Removed
p. 48
Disabling of MSR transactions must be at the level of the PIN CVM Application;; and it is not compliant for a PIN CVM Application to support two external readers where one is used for PIN- based transactions and one allows for MSR.
TB5.1 The tester shall confirm that the SCRP(s) that are used for card acceptance do not contain, or allow for the use of, a magnetic-stripe reader (MSR). Disabling of MSR functions in the firmware of the SCRP alone is not acceptable.
TB5.2 The tester shall confirm that the PIN CVM Application does not support the use of multiple SCRPs or other card accepting mechanisms at any one time. The PIN CVM Application must be bound to a single SCRP device (not device type) upon install, and replacement of this SCRP with another SCRP must require a new secure provisioning process, as tested under TR8.
TB5.1 The tester shall confirm that the SCRP(s) that are used for card acceptance do not contain, or allow for the use of, a magnetic-stripe reader (MSR). Disabling of MSR functions in the firmware of the SCRP alone is not acceptable.
TB5.2 The tester shall confirm that the PIN CVM Application does not support the use of multiple SCRPs or other card accepting mechanisms at any one time. The PIN CVM Application must be bound to a single SCRP device (not device type) upon install, and replacement of this SCRP with another SCRP must require a new secure provisioning process, as tested under TR8.
Modified
p. 48 → 47
All transactions must be processed online. The SCRP must not be physically capable of accepting magnetic-stripe cards.
All transactions must be processed online.
Modified
p. 48 → 47
TB5.1 The tester shall confirm that the PIN CVM application establishes a secure channel to the back- end monitoring and attestation systems prior to prompting for the PIN entry in each transaction.
Modified
p. 48 → 47
TB5.2 The tester shall disable network connectivity on the system and attempt to perform a transaction. For compliance to this requirement, the transaction must not be permitted. Disabling of the network connectively must include at least the following:
Modified
p. 48 → 47
• Connecting to a local network (such as Wi-Fi) that is not connected to the Internet TB5.3 The tester shall start a transaction where network connectivity is available but disable this connectivity during PIN entry and detail the outcome of the transaction for more than 60 seconds. The PIN CVM application must reverse and/or cancel the transaction and erase all customer data. Any time-out period implemented to wait for reconnection of the network must not exceed 1 minute after PIN …
Removed
p. 49
The authenticity of the PIN CVM Application is a paramount concern in the security of PIN entry. Loading of applications from the operating system store provides a level of confidence that the application has not been tampered with before being installed on the merchant system. The tester must validate that there are no public vulnerabilities for the stores used.
The scope of this requirement is for the authentication of the application by the base Operating System. Additional authenticity checks are expected to be applied and checked by the monitoring system or applied as part of the obfuscation methods, but these are not in scope of this requirement.
The scope of this requirement is for the authentication of the application by the base Operating System. Additional authenticity checks are expected to be applied and checked by the monitoring system or applied as part of the obfuscation methods, but these are not in scope of this requirement.
Modified
p. 49 → 48
Where the PIN CVM Application allows or requires download of additional data from the back-end monitoring systems, such data must also be cryptographically signed and authenticated by the PIN CVM Application prior to use or execution. Reliance upon the secure channel that exists between the PIN CVM Application and the back-end monitoring systems is not sufficient. This requirement implies that each datagram sent from the device to the back-end server, or vice-versa, has an individual signature or (H)MAC applied. The …
Where the PIN CVM application allows or requires download of additional data from the back-end monitoring systems, such data must also be cryptographically signed and authenticated by the PIN CVM application prior to use or execution. Reliance upon the secure channel that exists between the PIN CVM application and the back-end monitoring systems is not sufficient. This requirement implies that each datagram sent from the device to the back-end server, or vice-versa, has an individual signature or (H)MAC applied. The …
Modified
p. 49 → 48
TB6.1 The tester shall detail all supported methods for loading the PIN CVM Application onto the acceptable baseline systems (as assessed under TR C1: COTS System Baseline). This may include multiple online stores, but the tester shall confirm for each instance that only the official store of the baseline operating system(s) is used for PIN CVM Application deployment.
TB6.1 The tester shall detail all supported methods for loading the PIN CVM application onto the acceptable baseline systems (as assessed under TR C1: COTS System Baseline). This may include multiple online stores, but the tester shall confirm for each instance that only the official store of the baseline OS(s) is used for PIN CVM application deployment.
Modified
p. 50 → 49
TB6.4 The tester shall document any additional scripts, data, executable files, interpreted commands or other information that is downloaded by the PIN CVM Application after installation. In each case, the tester shall confirm that data is cryptographically authenticated and the authentication is validated prior to use of the data. The tester shall further confirm that any datagrams sent from the PIN CVM Application to the back-end monitoring system are cryptographically signed or MAC’d prior to transmission. The validation of the …
TB6.4 The tester shall document any additional scripts, data, executable files, interpreted commands or other information that is downloaded by the PIN CVM application after installation. In each case, the tester shall confirm that data is cryptographically authenticated and the authentication is validated prior to use of the data. The tester shall further confirm that any datagrams sent from the PIN CVM application to the back-end monitoring system are cryptographically signed or MAC’d prior to transmission. The validation of the …
Modified
p. 50 → 49
TB6.5 The tester shall confirm that signing of the PIN CVM Application must be performed using a dual controlled process, using cryptographic keys that are secured within an HSM formally approved to PCI HSM or FIPS140-2 Level 3 (or above). This requirement does not apply to signatures that can only be generated by a third party, such as the OS store itself. However, all signatures that are generated by the PIN CVM Application vendor must meet this requirement (even if …
TB6.5 The tester shall confirm that signing of the PIN CVM application must be performed using a dual controlled process, using cryptographic keys that are secured within an HSM formally approved to PCI HSM or FIPS140-2 Level 3 (or above). This requirement does not apply to signatures that can only be generated by a third party, such as the OS store itself. However, all signatures that are generated by the PIN CVM application vendor must meet this requirement (even if …
Modified
p. 51 → 50
The PIN CVM Application must automatically clear the internal buffers it controls when one of the following occurs:
The PIN CVM application must automatically clear the internal buffers it controls when one of the following occurs:
Modified
p. 51 → 50
• A tamper-detection event has been signaled by the monitoring system, or the PIN CVM application is halted, loses focus or otherwise is moved to background processing.
Modified
p. 51 → 50
The vendor shall provide documentation of test results for inspections of internal buffers. It is understood that clearing of buffer data from high-level languages can be complex, but the implementation must perform a rigorous effort to achieve this. Solely relying on "garbage collection" functions for clearing buffer data is not considered compliant.
The vendor shall provide documentation of test results for inspections of internal buffers. It is understood that clearing of buffer data from high-level languages can be complex, but the implementation must perform a rigorous effort to achieve this. Solely relying on "garbage collection" functions for clearing buffer data is not considered compliant.
Modified
p. 51 → 50
The device will support the encipherment of the PIN multiple times as part of a transaction series;; transferring it between the PIN CVM Application and SCRP, then from the SCRP to back-end payment system. Each merchant-side instance must be implemented to clear the buffer as soon as practical after use. Labs must evaluate the methodology used to clear temporary variables, heap, stack and other memory sub-systems of plaintext PIN data to prevent memory dumps from revealing sensitive customer data.
The device will support the encipherment of the PIN multiple times as part of a transaction series; transferring it between the PIN CVM application and SCRP, then from the SCRP to back-end payment system. Each merchant-side instance must be implemented to clear the buffer as soon as practical after use. Labs must evaluate the methodology used to clear temporary variables, heap, stack and other memory sub-systems of plaintext PIN data to prevent memory dumps from revealing sensitive customer data.
Modified
p. 51 → 50
It is expected that lab testing, and vendor evidence will be based on unobfuscated code;; although evidence from "production ready" code that has undergone obfuscation compliant with requirement B1 is ideal, it is expected that this will greatly complicate the validation of the buffer clearing functions. The intent of this requirement is to confirm that significant attempts are made at clearing the buffers and use of unobfuscated code is considered to provide the best path to validation.
It is expected that lab testing, and vendor evidence will be based on unobfuscated code; although evidence from "production ready" code that has undergone obfuscation compliant with requirement B1 is ideal, it is expected that this will greatly complicate the validation of the buffer clearing functions. The intent of this requirement is to confirm that significant attempts are made at clearing the buffers and use of unobfuscated code is considered to provide the best path to validation.
Modified
p. 52 → 51
TB7.3 The tester shall verify that¾and summarize how¾the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included. Passwords, plaintext PIN values, plaintext cryptographic keys, customer identifiable data such as e-mail address and phone number, or key components are considered sensitive data.
TB7.3 The tester shall verify that − and summarize how − the vendor has identified all data that is automatically cleared when the transaction is completed and that all sensitive data is included. Passwords, plaintext PIN values, plaintext cryptographic keys, customer identifiable data such as e-mail address and phone number, or key components are considered sensitive data.
Modified
p. 52 → 51
TB7.4 The tester shall review the source code of the PIN CVM Application and confirm that¾and summarize how¾sensitive information is cleared from all storage locations after use, including local variables (before exiting the function) and other locations. The tester shall detail the methods used to perform the erasure;; and where clearing of these memory locations cannot be 100% confirmed, the tester shall document his or her attempts to validate the erasure of sensitive information and provide justification that the methods …
TB7.4 The tester shall review the source code of the PIN CVM application and confirm that − and summarize how − sensitive information is cleared from all storage locations after use, including local variables (before exiting the function) and other locations. The tester shall detail the methods used to perform the erasure; and where clearing of these memory locations cannot be 100% confirmed, the tester shall document his or her attempts to validate the erasure of sensitive information and provide …
Modified
p. 52 → 51
TB7.5 The tester shall detail the method used by the vendor to mitigate the potential that this buffer- clearing code/function cannot be removed by compiler optimizations or other means of code optimization, if employed by the vendor. Special note shall be made where the supported platforms include on-device compilation methods.
TB7.5 The tester shall detail the method used by the vendor to mitigate the potential that this buffer- clearing code/function cannot be removed by compiler optimizations or other means of code optimization, if employed by the vendor. Special note shall be made where the supported platforms include on-device compilation methods.
Modified
p. 52 → 51
TB7.6 The tester shall detail the testing performed to verify that buffer-clearing code/function is robust. This requires assistance from the vendor and may involve, for example:
TB7.6 The tester shall detail the testing performed to verify that buffer-clearing code/function is robust. This requires assistance from the vendor and may involve, for example:
Modified
p. 52 → 51
• Confirmation that any compiler flags to ensure optimization are functioning as expected TB7.7 The tester shall review vendor software-development practices documentation to confirm that and indicate how:
Modified
p. 52 → 51
• The requirement for buffer clearing is documented including specific notes that buffer clearing should be performed to prevent removal by compiler optimization; and
Modified
p. 52 → 51
TB7.8 The tester shall perform any additional tests necessary to verify that all data is automatically cleared when either the transaction is completed, or the device has timed out waiting for the response from the cardholder or merchant¾for instance, by performing a partial simulated transaction to verify the behavior at time-out.
TB7.8 The tester shall perform any additional tests necessary to verify that all data is automatically cleared when either the transaction is completed, or the device has timed out waiting for the response from the cardholder or merchant − for instance, by performing a partial simulated transaction to verify the behavior at time-out.
Modified
p. 52 → 51
TB7.9 The tester shall force a tamper-detection event and confirm that this results in the clearing of all customer data from the PIN CVM Application. This may require assistance from the PIN CVM Application vendor. A summary of the results is to be provided with details on which areas rely on vendor testing, and which have been directly tested by the assessor. The tester must document the testing and validation process, providing evidence of the erasure of sensitive data.
TB7.9 The tester shall force a tamper-detection event and confirm that this results in the clearing of all customer data from the PIN CVM application. This may require assistance from the PIN CVM application vendor. A summary of the results is to be provided with details on which areas rely on vendor testing, and which have been directly tested by the assessor. The tester must document the testing and validation process, providing evidence of the erasure of sensitive data.
Modified
p. 53 → 52
As the PIN CVM Application is downloaded from a single instance in an OS store, each application install is initially identical to all others. The system must implement methods to immediately upon install ensure that instance is unlike any other and can be uniquely identified and secured through communication with the back-end monitoring and attestation systems.
As the PIN CVM application is downloaded from a single instance in an OS store, each application install is initially identical to all others. The system must implement methods to immediately upon install ensure that instance is unlike any other and can be uniquely identified and secured through communication with the back-end monitoring and attestation systems.
Modified
p. 53 → 52
TB8.3 The tester shall install the PIN CVM Application and monitor the provisioning process (e.g., through a network monitor observing traffic from the device) and confirm that a secure channel is used to prevent oversight or manipulation of the provisioning process.
TB8.3 The tester shall install the PIN CVM application and monitor the provisioning process (e.g., through a network monitor observing traffic from the device) and confirm that a secure channel is used to prevent oversight or manipulation of the provisioning process.
Modified
p. 53 → 52
TB8.4 Where white-box cryptography is used, the tester shall outline how cryptographic keys that are unique per application installation instance are conveyed and secured using this method, such that use of the common white-box keys is minimized after the secure provisioning process. The details provided must include how each white-box key is used, how they are involved in the secure provisioning process and what use the white-box keys have (if any) after the secure provisioning process is completed.
TB8.4 Where white-box cryptography is used, the tester shall outline how cryptographic keys that are unique per application installation instance are conveyed and secured using this method, such that use of the common white-box keys is minimized after the secure provisioning process. The details provided must include how each white-box key is used, how they are involved in the secure provisioning process and what use the white-box keys have (if any) after the secure provisioning process is completed.
Modified
p. 53 → 52
TB8.5 Where white-box cryptography is used, the tester shall detail the process used for updating the white-box cryptographic keys in the application. The tester shall detail how any method used for ensuring that current working keys are not erased or rendered inoperative during this process provides for the confidentiality and integrity of these keys.
TB8.5 Where white-box cryptography is used, the tester shall detail the process used for updating the white-box cryptographic keys in the application. The tester shall detail how any method used for ensuring that current working keys are not erased or rendered inoperative during this process provides for the confidentiality and integrity of these keys.
Modified
p. 53 → 52
TB8.6 The tester shall confirm that no secret or sensitive data is transferred prior to the secure establishment of cryptographic keys unique to each PIN CVM Application installation, and that any key-generation or key-agreement methods used in the secure provisioning are implemented securely and have been assessed against the key-management requirements of this standard.
TB8.6 The tester shall confirm that no secret or sensitive data is transferred prior to the secure establishment of cryptographic keys unique to each PIN CVM application installation, and that any key-generation or key-agreement methods used in the secure provisioning are implemented securely and have been assessed against the key-management requirements of this standard.
Modified
p. 54 → 53
Areas of the PIN CVM Application that are not directly involved in the processing or handling of the PIN or providing security services and interface to the monitoring system must be able to be updated without affecting the PIN CVM Application secure code. This isolation may be achieved in many ways, but simply having different functions within the same body of code for security and non- security functions is not considered sufficient isolation.
Areas of the PIN CVM application that are not directly involved in the processing or handling of the PIN or providing security services and interface to the monitoring system must be able to be updated without affecting the PIN CVM application secure code. This isolation may be achieved in many ways, but simply having different functions within the same body of code for security and non- security functions is not considered sufficient isolation.
Modified
p. 54 → 53
TB9.1 The tester shall detail how the code of the PIN CVM Application is structured and confirm that methods are provided to logically separate the PIN processing code (or code that provided security to the PIN processing code) from other parts of the code. This must include data-flow diagrams that show how the PIN is entered, processed, encrypted and validated within the PIN CVM Application, where the data is transmitted outside of the scope of the PIN CVM Application and …
TB9.1 The tester shall detail how the code of the PIN CVM application is structured and confirm that methods are provided to logically separate the PIN processing code (or code that provided security to the PIN processing code) from other parts of the code. This must include data-flow diagrams that show how the PIN is entered, processed, encrypted and validated within the PIN CVM application, where the data is transmitted outside of the scope of the PIN CVM application and …
Modified
p. 54 → 53
TB9.2 The tester shall justify how this separation allows for easy isolation of code segments, and therefore ensures that changes made to one area of the code do not affect areas that are isolated from this. Where the testers cannot provide this justification, or where code isolation is provided through simple use of different functions or code files, this requirement must be marked as non-compliant.
TB9.2 The tester shall justify how this separation allows for easy isolation of code segments, and therefore ensures that changes made to one area of the code do not affect areas that are isolated from this. Where the testers cannot provide this justification, or where code isolation is provided through simple use of different functions or code files, this requirement must be marked as non-compliant.
Modified
p. 55 → 54
Where secure data is entered into the system, such as customer PINs, the "keyboard" or standard data entry functions of the Operating System must not be used (i.e., touch location data alone must be collected and then translated into PIN values within the PIN CVM Application).
Where secure data is entered into the system, such as customer PINs, the "keyboard" or standard data entry functions of the OS must not be used (i.e., touch location data alone must be collected and then translated into PIN values within the PIN CVM application).
Modified
p. 55 → 54
This requirement is to be assessed against all Operating System types and variants that exist under the supported platforms (as assessed under TR B12: Supported Platforms). The scope of this assessment should not consider malicious modification of these supported platforms to enable such features specifically for the collection of customer PIN data. However, modifications to a "standard" operating system that may be performed by a COTS vendor, distributor or carrier that are not necessarily specifically designed for PIN capture, but …
This requirement is to be assessed against all OS types and variants that exist under the supported platforms (as assessed under TR B12: Supported Platforms). The scope of this assessment should not consider malicious modification of these supported platforms to enable such features specifically for the collection of customer PIN data. However, modifications to a "standard" OS that may be performed by a COTS vendor, distributor or carrier that are not necessarily specifically designed for PIN capture, but which may …
Modified
p. 55 → 54
PIN entry must only be allowed for an EMV-based contact or contactless transaction.
PIN entry must only be allowed for an EMV-based contact or contactless transaction.
Modified
p. 55 → 54
• Screen capture during PIN entry TB10.2 The tester shall confirm that the PIN CVM application does not allow for the entry of the PIN unless there has been a non-magnetic-stripe card read through the attached SCRP for that transaction. The tester shall note any other transaction types supported by the PIN CVM application, and for each type that does not involve a fully compliant EMV-based transaction, confirm that PIN entry is not supported or able to be performed.
Modified
p. 55 → 54
TB10.3 The tester shall confirm through testing of representative samples of the supported platforms that switching context from the PIN CVM Application to another application during PIN entry results in the termination of the PIN entry process and deletion of any partially entered PIN data. Tests shall include both manually changing focus (e.g., switching to another application) and automatic changes of focus (e.g., during an incoming phone call or text message).
TB10.3 The tester shall confirm through testing of representative samples of the supported platforms that switching context from the PIN CVM application to another application during PIN entry results in the termination of the PIN entry process and deletion of any partially entered PIN data. Tests shall include both manually changing focus (e.g., switching to another application) and automatic changes of focus (e.g., during an incoming phone call or text message).
Modified
p. 56 → 55
TB10.5 Where the baseline systems support windowed environments, where multiple applications can be displayed on the screen at any one time, the tester shall confirm that the PIN CVM Application does not allow for PIN entry unless it is running in full-screen mode.
TB10.5 Where the baseline systems support windowed environments, where multiple applications can be displayed on the screen at any one time, the tester shall confirm that the PIN CVM application does not allow for PIN entry unless it is running in full-screen mode.
Modified
p. 56 → 55
• The PIN CVM application does not use the "standard" OS keyboard or other entry methods that directly return alphanumeric data that reveals the PIN provided (i.e., by collecting only touch location data that is then processed into customer PIN values)
Modified
p. 56 → 55
• No part of the PIN is transmitted outside the COTS system prior to the entry being completed by the customer and the entire PIN encrypted as per the requirements of this standard. Touch locations, individual data elements, images, etc. of the PIN must not be transmitted externally to the COTS device unless these constitute the entirety of the PIN entry.
Modified
p. 56 → 55
• Localized indications of customer interaction (such as button "highlights" when pressing an area of the screen, localized haptic feedback, etc.) must not be used.
Modified
p. 56 → 55
TB10.8 Based on the above testing and information, the tester shall provide a costing of an attack to determine the value of the customer PIN. This attack must consider the protections provided by all security features, including any tamper-resistance or monitor features that may protect against such attacks. The tester must use the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework for this costing.
TB10.8 Based on the above testing and information, the tester shall provide a costing of an attack to determine the value of the customer PIN. This attack must consider the protections provided by all security features, including any tamper-resistance or monitor features that may protect against such attacks. The tester must use the methodology outlined in Appendix B: Software Tamper-responsive Attack Costing Framework for this costing.
Modified
p. 57 → 56
It is a fundamental security tenet of this standard that the PIN data remains logically isolated from the customer card data. However, collection of customer card data may occur in other systems or locations, and then be correlated with the PIN later using information about the customer, such as name or e-mail address. Therefore, it is important that all identifiable customer data be prevented from being exposed on the COTS system.
It is a fundamental security tenet of this standard that the PIN data remains logically isolated from the account data. However, collection of account data may occur in other systems or locations, and then be correlated with the PIN later using information about the customer, such as name or e-mail address. Therefore, it is important that all identifiable customer data be prevented from being exposed on the COTS system.
Modified
p. 57 → 56
The customer PAN may be provided to a maximum of the last four digits, and customer phone numbers must display, at a maximum, only the last 4 digits, and e-mail addresses must display, at a maximum, only the first two characters of the address and first two and last two of the domain (e.g., anxxxxxxxxxxxx@gmxxx.xom or jkxxxxx@soxxxxxxx.xxx.au ). Additional privacy controls may be required by regional/country regulations.
The customer PAN may be provided to a maximum of the last four digits, and customer phone numbers must display, at a maximum, only the last 4 digits, and e-mail addresses must display, at a maximum, only the first two characters of the address and first two and last two of the domain (e.g., anxxxxxxxxxxxx@gmxxx.xom or jkxxxxx@soxxxxxxx.xxx.au ). Additional privacy controls may be required by regional/country regulations.
Modified
p. 57 → 56
TB11.1 The tester shall confirm what customer data is accepted and used by the system, either in the merchant environment or on any back-end server systems. For each item of customer data, the tester shall identify how this data is provided.
TB11.1 The tester shall confirm what customer data is accepted and used by the system, either in the merchant environment or on any back-end server systems. For each item of customer data, the tester shall identify how this data is provided.
Modified
p. 57 → 56
TB11.2 Where customer data (such as e-mail address) can be provided into the PIN CVM Application, the tester shall confirm how this data is erased after being transmitted from the application, such that it is irrecoverable on the merchant systems.
TB11.2 Where customer data (such as e-mail address) can be provided into the PIN CVM application, the tester shall confirm how this data is erased after being transmitted from the application, such that it is irrecoverable on the merchant systems.
Modified
p. 57 → 56
TB11.5 The tester shall review any logs produced by the system and confirm that they do not store un- truncated customer data.
TB11.5 The tester shall review any logs produced by the system and confirm that they do not store un- truncated customer data.
Modified
p. 57 → 56
TB11.6 Where customer data is entered into the PIN CVM Application, the tester shall confirm that the entry methods implemented do not allow for the caching or storage of the customer data into the COTS operating system (e.g., dictionaries, contact database, Operating System "clipboards," etc.).
TB11.6 Where customer data is entered into the PIN CVM application, the tester shall confirm that the entry methods implemented do not allow for the caching or storage of the customer data into the COTS OS (e.g., dictionaries, contact database, OS "clipboards," etc.).
Removed
p. 58
§ An enforcing Mandatory Access Control framework § A "trusted boot" mechanism that validates the operating system authenticity from a hardware root of trust. This mechanism must either prevent the loading of unauthentic operating system code or allow for detection of such code by the monitoring system.
§ Ability to prevent all other applications other than the foreground application from accessing touch-event details § Validation of an application signature upon loading and execution of that application. This signature must be calculated with strong cryptography and no known bypass measures may exist for the acceptable baseline systems.
§ Ability to prevent all other applications other than the foreground application from accessing touch-event details § Validation of an application signature upon loading and execution of that application. This signature must be calculated with strong cryptography and no known bypass measures may exist for the acceptable baseline systems.
Modified
p. 58 → 57
Although these requirements are designed to allow for the entry of a PIN on a commercial off-the- shelf platform that has not been directly assessed for security, it is expected that the system will have criteria for which platforms are considered acceptable for PIN use, and which are not. For example, it is expected that systems using older COTS operating systems that may contain unpatched vulnerabilities will not be deemed acceptable for PIN entry. The PIN CVM Application vendor must …
Although these requirements are designed to allow for the entry of a PIN on a COTS platform that has not been directly assessed for security, it is expected that the system will have criteria for which platforms are considered acceptable for PIN use, and which are not. For example, it is expected that systems using older COTS OSs that may contain unpatched vulnerabilities will not be deemed acceptable for PIN entry. The PIN CVM application vendor must provide a clear …
Modified
p. 58 → 57
There are two requirements in this standard that address the suitability of devices/operating systems on which the PIN CVM Application may be executed. This "supported platforms" requirement addresses the need for the PIN CVM Application to be targeted to a limited subset of all available devices, and that the PIN CVM Application developer must have undertaken some risk analysis and mitigation steps to identify which platforms are suitable and secure.
There are two requirements in this standard that address the suitability of devices/OSs on which the PIN CVM application may be executed. This "supported platforms" requirement addresses the need for the PIN CVM application to be targeted to a limited subset of all available devices, and that the PIN CVM application developer must have undertaken some risk analysis and mitigation steps to identify which platforms are suitable and secure.
Modified
p. 58 → 57
The "system baseline" requirement (TR C1: COTS System Baseline) addresses the need for the monitoring system to dynamically assess the security of all devices/platforms on which the PIN CVM Applications are executed and determine whether they are vulnerable to attack. It is expected that the system baseline will change more rapidly than the supported platforms to address the changing threat landscape.
The "system baseline" requirement (TR C1: COTS System Baseline) addresses the need for the monitoring system to dynamically assess the security of all devices/platforms on which the PIN CVM applications are executed and determine whether they are vulnerable to attack. It is expected that the system baseline will change more rapidly than the supported platforms to address the changing threat landscape.
Modified
p. 58 → 57
TB12.1 The PIN CVM Application vendor must maintain a defined list of supported platforms. The tester shall confirm that this list exists and detail the methodology for determining whether a platform is acceptable or not. The tester shall specifically identify what security process is involved in the identification of supported platforms, and the method used for platform selection (whitelist, blacklist, etc.).
TB12.1 The PIN CVM application vendor must maintain a defined list of supported platforms. The tester shall confirm that this list exists and detail the methodology for determining whether a platform is acceptable or not. The tester shall specifically identify what security process is involved in the identification of supported platforms, and the method used for platform selection (whitelist, blacklist, etc.).
Modified
p. 58 → 57
TB12.2 The supported platforms must only include products and operating systems that provide the following features:
TB12.2 The supported platforms must only include products and OSs that provide the following
Modified
p. 59 → 58
• Whenever white-box cryptography or obfuscation methods, implementations or instantiations are updated TB12.4 The tester shall attempt to install the PIN CVM application and perform PIN entry on a COTS device that is not within the supported platforms. This device should be selected to be a "close fail" − that is, a device that is common in the market but "just" falls outside of the acceptability criteria (or a device that was initially within the acceptability criteria but has been …
Modified
p. 59 → 58
TB12.5 The vendor shall provide to the lab a document that indicates all security features of the Supported Platforms that are relied upon for the secure operation of the PIN CVM Application, including variances in any minor OS versions or device manufacturer implementations. The tester shall validate that this list is complete and that all such security features are present, operational and provide the required security on the Supported Platforms.
TB12.5 The vendor shall provide to the lab a document that indicates all security features of the supported platforms that are relied upon for the secure operation of the PIN CVM application, including variances in any minor OS versions or device manufacturer implementations. The tester shall validate that this list is complete and that all such security features are present, operational and provide the required security on the supported platforms.
Modified
p. 60 → 59
Customer PINs must be encrypted using PIN blocks approved under ISO 9564. ISO format 4 must be used when transferring customer PINs between the PIN CVM Application and SCRP. ISO formats 0, 3 or 4 may be used when transferring the customer PIN from the SCRP to the back-end payment system. ISO Format 1 is forbidden from use.
Customer PINs must be encrypted using PIN blocks approved under ISO 9564. ISO format 4 must be used when transferring customer PINs between the PIN CVM application and SCRP. ISO formats 0, 3 or 4 may be used when transferring the customer PIN from the SCRP to the back-end payment system. ISO Format 1 is forbidden from use.
Modified
p. 60 → 59
ISO Format 2 may only be used to transfer the customer PIN from the SCRP to the customer ICC. ISO format 2 must not be used to convey customer PINs from the SCRP to the back-end payment system, or between this system and the SCRP.
ISO Format 2 may only be used to transfer the customer PIN from the SCRP to the customer ICC. ISO format 2 must not be used to convey customer PINs from the SCRP to the back-end payment system, or between this system and the SCRP.
Modified
p. 60 → 59
For systems that use a "split" or partially cloud-based kernel, details must be provided on where the customer PIN is handled at all points, and systems where the customer PIN is transferred from the merchant device to the remote kernel for processing must use ISO format 4 for transfer of the customer PIN.
For systems that use a "split" or partially cloud-based kernel, details must be provided on where the customer PIN is handled at all points, and systems where the customer PIN is transferred from the merchant device to the remote kernel for processing must use ISO format 4 for transfer of the customer PIN.
Modified
p. 60 → 59
TB13.1 The tester shall confirm that the customer PIN is encrypted using ISO format 4 for transport between the PIN CVM Application and the SCRP, where it must be translated into ISO format 0, 3 or 4. The use of TDES for encryption of the customer PIN on the SCRP is the only exception allowing the use of TDES in this standard.
TB13.1 The tester shall confirm that the customer PIN is encrypted using ISO format 4 for transport between the PIN CVM application and the SCRP, where it must be translated into ISO format 0, 3 or 4. The use of TDES for encryption of the customer PIN on the SCRP is the only exception allowing the use of TDES in this standard.
Modified
p. 60 → 59
TB13.2 For PIN blocks generated within the PIN CVM Application, the tester shall confirm that only ISO format 4 may be used, and that the PAN value is supplied by the SCRP as a secure PAN token, using the SCRP PAN token generation feature.
TB13.2 For PIN blocks generated within the PIN CVM application, the tester shall confirm that only ISO format 4 may be used, and that the PAN value is supplied by the SCRP as a secure PAN token, using the SCRP PAN token generation feature.
Modified
p. 61 → 60
The vendor must supply documentation to allow the merchant to understand the context of the approval of the PIN CVM Application, to ensure that it does not deploy or use the system in a non- compliant way. In this context, the security policy informs the merchant both how to use and maintain the system securely and also of any assumptions made by the laboratory during the PIN CVM Solution evaluation (e.g., that the device is handheld).
The vendor must supply documentation to allow the merchant to understand the context of the approval of the PIN CVM application, to ensure that it does not deploy or use the system in a non- compliant way. In this context, the security policy informs the merchant both how to use and maintain the system securely and also of any assumptions made by the laboratory during the PIN CVM solution evaluation (e.g., that the device is handheld).
Modified
p. 61 → 60
TB14.1 The tester shall confirm that a security policy exists for the system, and that this is provided to all users of the system and required to be read and accepted as part of the PIN CVM Application EULA.
TB14.1 The tester shall confirm that a security policy exists for the system, and that this is provided to all users of the system and required to be read and accepted as part of the PIN CVM application EULA.
Modified
p. 61 → 60
TB14.2 The tester shall confirm that the security policy provides details on all additional components required for the use of the PIN CVM Application, including all SCRPs approved for use. A picture must be provided of each SCRP, along with any guidance required for the secure use of that SCRP. Each SCRP must be identified by model, hardware version and firmware version to allow for unique validation of each device on the PCI SSC PTS approval listing.
TB14.2 The tester shall confirm that the security policy provides details on all additional components required for the use of the PIN CVM application, including all SCRPs approved for use. A picture must be provided of each SCRP, along with any guidance required for the secure use of that SCRP. Each SCRP must be identified by model, hardware version and firmware version to allow for unique validation of each device on the PCI SSC PTS approval listing.
Modified
p. 61 → 60
TB14.4 The tester shall confirm that the security policy informs the merchant that it is responsible for the security of the installed environment and use of the PIN CVM Application and COTS device on which it is executed.
TB14.4 The tester shall confirm that the security policy informs the merchant that it is responsible for the security of the installed environment and use of the PIN CVM application and COTS device on which it is executed.
Modified
p. 62 → 61
The system baseline is a subset of the supported platforms (assessed against the PIN CVM Application under TR B12: Supported Platforms). The monitoring system is required to define which of those supported platforms may be secure for use by the PIN CVM Application, based on data about current attack methods, new vulnerabilities, etc.
The system baseline is a subset of the supported platforms (assessed against the PIN CVM application under TR B12: Supported Platforms). The monitoring system is required to define which of those supported platforms may be secure for use by the PIN CVM application, based on data about current attack methods, new vulnerabilities, etc.
Modified
p. 62 → 61
TC1.3 The tester shall verify that validation of the system baseline is performed regularly¾at a minimum, during each of the back-end monitoring system checks¾and that it is always performed upon the execution of the PIN CVM Application.
TC1.3 The tester shall verify that validation of the system baseline is performed regularly − at a minimum, during each of the back-end monitoring system checks − and that it is always performed upon the execution of the PIN CVM application.
Modified
p. 62 → 61
TC1.4 The tester shall attempt to install the PIN CVM Application and perform PIN entry on a COTS device that is not within the baseline acceptability criteria. This device should be selected to be a "close fail"¾that is, a device that is common in the market and listed in the supported platforms (as assessed under TR B12: Supported Platforms ) but "just" falls outside of the acceptability criteria (or a device that was initially within the acceptability criteria, but has …
TC1.4 The tester shall attempt to install the PIN CVM application and perform PIN entry on a COTS device that is not within the baseline acceptability criteria. This device should be selected to be a "close fail" − that is, a device that is common in the market and listed in the supported platforms (as assessed under TR B12: Supported Platforms ) but "just" falls outside of the acceptability criteria (or a device that was initially within the acceptability criteria, …
Modified
p. 62 → 61
TC1.6 The tester shall confirm that the system baseline does not include devices that are "rooted" or "jailbroken." The tester shall outline what protections are provided to detect rooted or jailbroken environments. The tester shall detail how effective this is expected to be and perform tests to attempt to bypass the detections and note the results.
TC1.6 The tester shall confirm that the system baseline does not include devices that are rooted or jailbroken. The tester shall outline what protections are provided to detect rooted or jailbroken environments. The tester shall detail how effective this is expected to be and perform tests to attempt to bypass the detections and note the results.
Modified
p. 64 → 63
The system must maintain processes to detect and respond to attempts to modify the PIN entry functions or the security thereof. This response must ensure that further attempts to modify or analyze the code execution are prevented;; for example, by preventing any further connections or acceptance of data from the device by the host system or sending a "disable" command that erases sensitive data such as cryptographic keys from the application and prevents further of PIN entry.
The system must maintain processes to detect and respond to attempts to modify the PIN entry functions or the security thereof. This response must ensure that further attempts to modify or analyze the code execution are prevented; for example, by preventing any further connections or acceptance of data from the device by the host system or sending a "disable" command that erases sensitive data such as cryptographic keys from the application and prevents further of PIN entry.
Modified
p. 64 → 63
Tamper response should prevent simple bypass methods such as clearing the application data, re- installing the application or changing merchant details such as (e-mail) address and name. Where multiple devices may be utilized as part of an attempt to attack the system, the tester shall outline what protections are provided to complicate the use of knowledge gained from one device set (COTS device and reader) in furthering an attack on another device set.
Tamper response should prevent simple bypass methods such as clearing the application data, re- installing the application or changing merchant details such as (e-mail) address and name. Where multiple devices may be utilized as part of an attempt to attack the system, the tester shall outline what protections are provided to complicate the use of knowledge gained from one device set (COTS device and reader) in furthering an attack on another device set.
Modified
p. 64 → 63
Tamper detection shall not rely on any single feature or response from the operational environment, but instead must be based on checking of multiple features. Where possible these features must include intrinsic, hard-to-copy features of the operational environment (e.g., by using hardware-based information such as processor/GPU/memory speed, thermal response under load, memory utilization, etc.).
Tamper detection shall not rely on any single feature or response from the operational environment, but instead must be based on checking of multiple features. Where possible these features must include intrinsic, hard-to-copy features of the operational environment (e.g., by using hardware-based information such as processor/GPU/memory speed, thermal response under load, memory utilization, etc.).
Modified
p. 64 → 63
The system tamper response must be an evolving process that is designed to detect and adapt to new threats. This process of adaptation must specifically address threats to the PIN CVM Application and the PIN, and although this requirement does not prevent the use of "generic" platform attestation methods that may be implemented to detect the presence of malware and Potentially Unwanted Programs, it is expected that such methods will not be sufficient in and of themselves to meet the …
The system tamper response must be an evolving process that is designed to detect and adapt to new threats. This process of adaptation must specifically address threats to the PIN CVM application and the PIN, and although this requirement does not prevent the use of "generic" platform attestation methods that may be implemented to detect the presence of malware and Potentially Unwanted Programs, it is expected that such methods will not be sufficient in and of themselves to meet the …
Modified
p. 64 → 63
As part of this tamper detection and response, it is a requirement that the application is only ever able to function and accept PIN entry when it can connect and authenticate to the remote server. Each PIN-based transaction must result in full communication with the remote host, either as a finalized transaction or as a transaction where a reversal process has been initiated and completed due to communication errors. This ensures that each transaction can be monitored and validated by …
As part of this tamper detection and response, it is a requirement that the application is only ever able to function and accept PIN entry when it can connect and authenticate to the remote server. Each PIN-based transaction must result in full communication with the remote host, either as a finalized transaction or as a transaction where a reversal process has been initiated and completed due to communication errors. This ensures that each transaction can be monitored and validated by …
Modified
p. 64 → 63
TC2.2 A documented system tamper-response policy must exist that defines health-check rules for SCRP, COTS device platform and monitor mechanisms. This policy must include detailed response procedures for successful or non-successful results. The policy must be maintained and communicated to applicable personnel.
TC2.2 A documented system tamper-response policy must exist that defines health-check rules for SCRP, COTS device platform and monitor mechanisms. This policy must include detailed response procedures for successful or non-successful results. The policy must be maintained and communicated to applicable personnel.
Removed
p. 65
§ At initialization/initial installation of the PIN CVM Application § Whenever the SCRP is physically or logically disconnected or re-connected to the PIN CVM Application § On execution of the PIN CVM Application, to be completed at least immediately prior to the entry of the first PIN § If initiated by the monitoring system, back-end server or other component of the overall solution (including the PIN CVM Application itself) § Randomly through PIN CVM Application operation, but no less than every 5 minutes of operation (if not otherwise activated by one of the events above during that time) § Any time the PIN CVM Application either loses focus or regains focus § After changes have been made to any component of the solution TC2.4 The tamper-response mechanisms must be able to detect and determine the validity of the SCRP being used. At a minimum, this must confirm:
§ That a valid …
§ That a valid …
Modified
p. 65 → 64
• Merchant physical and logical location identifiers (e.g., GPS location, IP address) The tester shall detail what information is used for this merchant identification and determine whether there are any publicly available methods to bypass or subvert these identifiers.
Removed
p. 66
§ Modification of or to the COTS operating system such that it deviates from the Supported Platforms defined in TR B12: Supported Platforms § Operation of the PIN CVM Application whilst the COTS system is in developer, debug, accessibility or other privileged modes that may lead to leakage of sensitive information § Execution of the PIN CVM Application within an emulated, virtualized or modified environment § Use of "hooking" or other data interception frameworks § Modification, tamper or other methods for altering the normal execution flow of the PIN CVM Application (including unexpected delays or errors in processing) § Use of the PIN CVM Application code, or part thereof, within another (valid and/or invalid) operational environment (e.g., through "code lifting" of the entire, or partial, PIN CVM Application to another COTS system after initialization and personalization of the PIN CVM Application for a specific merchant) § Changes to system configuration …
Modified
p. 66 → 65
• Hardware-based information such as processor/GPU/memory speed, thermal response under load, memory utilization, etc.
Modified
p. 66 → 65
• Software-based information such as memory layout/mapping features, process linking, versions/fingerprints of software libraries and OS modules, etc.
Modified
p. 66 → 65
TC2.7 The tamper-detection system shall provide features to detect and respond to at least the following:
TC2.7 The tamper-detection system shall provide features to detect and respond to at least the following:
Modified
p. 66 → 65
TC2.8 The tester shall confirm that the any tamper-detection code implemented in the PIN CVM Application is protected by the tamper-resistance features assessed under TR B1: PIN CVM Application Tamper Resistance.
TC2.8 The tester shall confirm that the any tamper-detection code implemented in the PIN CVM application is protected by the tamper-resistance features assessed under TR B1: PIN CVM Application Tamper Resistance.
Modified
p. 66 → 65
TC2.9 The tester shall note whether it is possible to perform "relay" attacks on the PIN entry, by performing or enabling remote screen display and data input capture of the PIN CVM Application on another device (which is therefore not running the system tamper-response code) or another application. The intent of this requirement is to confirm whether this is possible on any of the Supported Platforms, and if so, the tester must detail what features of the monitor or PIN …
TC2.9 The tester shall note whether it is possible to perform "relay" attacks on the PIN entry, by performing or enabling remote screen display and data input capture of the PIN CVM application on another device (which is therefore not running the system tamper-response code) or another application. The intent of this requirement is to confirm whether this is possible on any of the supported platforms, and if so, the tester must detail what features of the monitor or PIN …
Modified
p. 66 → 65
TC2.10 The tester shall note whether changes to the operational environment of the PIN CVM Application are detected if made in between checks performed by the tamper-response system. For example, the tester shall enable a high-privileged mode (such as "root") on the system when the PIN CVM Application is not executing and revert these changes prior to execution of the PIN CVM Application. Where such changes are not detected, the tester shall justify why (or why not) the security of …
TC2.10 The tester shall note whether changes to the operational environment of the PIN CVM application are detected if made in between checks performed by the tamper-response system. For example, the tester shall enable a high-privileged mode (such as "root") on the system when the PIN CVM application is not executing and revert these changes prior to execution of the PIN CVM application. Where such changes are not detected, the tester shall justify why (or why not) the security of …
Modified
p. 67 → 66
TC2.12 The tester shall attempt to install the PIN CVM Application on another device of the same model and version of that used to initially install and provision the application. It may be necessary to receive specific assistance from the vendor to facilitate this testing, to disable any non-monitor features that prevent extraction of the application and installation on a different device. The tester shall note whether the application and/or monitor is able to use its unique identification features to …
TC2.12 The tester shall attempt to install the PIN CVM application on another device of the same model and version of that used to initially install and provision the application. It may be necessary to receive specific assistance from the vendor to facilitate this testing, to disable any non-monitor features that prevent extraction of the application and installation on a different device. The tester shall note whether the application and/or monitor is able to use its unique identification features to …
Modified
p. 67 → 66
• That written procedures for these events exist and are demonstrably in use. These procedures must cover events where staff members relied upon for such determinations are unavailable.
Modified
p. 67 → 66
• Events must be escalated for manual review immediately. The maximum time that any such event can go un-actioned does not exceed 48 hours. Automated systems must be in place to disable any further payment processing from systems when this happens.
Modified
p. 67 → 66
• Staff members involved in the tamper-response functions are trained and knowledgeable in the security of all systems covered by the system baseline (as defined under TR C1: COTS System Baseline. Evidence of staff competence must be provided − e.g., through documented output of staff testing (not just training) performed at least annually, acceptance of senior member of staff to speak at well-known security conferences (about security of the platforms used), etc. TC2.14 The tester shall review the terms of …
Modified
p. 67 → 66
TC2.15 The tester shall confirm that the system monitor performs an integrity and version check on the PIN CVM Application as part of the tamper-detection process. Integrity checks must implement only approved algorithms, as per Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
TC2.15 The tester shall confirm that the system monitor performs an integrity and version check on the PIN CVM application as part of the tamper-detection process. integrity checks must implement only approved algorithms, as per Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
Modified
p. 67 → 66
TC2.16 The tester shall attempt to perform a PIN transaction using a previous version of the PIN CVM Application and confirm that the PIN entry process is not permitted until the PIN CVM Application is updated.
TC2.16 The tester shall attempt to perform a PIN transaction using a previous version of the PIN CVM application and confirm that the PIN entry process is not permitted until the PIN CVM application is updated.
Modified
p. 67 → 66
TC2.17 The tester shall confirm that the PIN CVM Application version identifier is protected by the tamper-resistance features of the application. The tester shall attempt to change the version identifier of a previous version of the PIN CVM Application and confirm that this does not allow for the execution of the PIN entry process.
TC2.17 The tester shall confirm that the PIN CVM application version identifier is protected by the tamper-resistance features of the application. The tester shall attempt to change the version identifier of a previous version of the PIN CVM application and confirm that this does not allow for the execution of the PIN entry process.
Modified
p. 68 → 67
The tester shall attempt to replay the monitor token and confirm that this does not allow for the continued operation, or re-enablement, of the SCRP.
The tester shall attempt to replay the monitor token and confirm that this does not allow for the continued operation, or re-enablement, of the SCRP.
Modified
p. 69 → 68
The integrity of the COTS system relies upon the ability of the monitoring system to detect malicious changes or modifications to that system beyond the acceptable baseline criteria. Any changes to the system must be managed through a dual-controlled process to ensure that a malicious insider is not capable of subverting this system.
The integrity of the COTS system relies upon the ability of the monitoring system to detect malicious changes or modifications to that system beyond the acceptable baseline criteria. Any changes to the system must be managed through a dual-controlled process to ensure that a malicious insider is not capable of subverting this system.
Modified
p. 69 → 68
TC3.2 The tester shall confirm that file integrity monitoring is used to protect configuration files, executables and public keys/certificates used for security services on any back-end components of the monitoring/attestation system.
TC3.2 The tester shall confirm that file integrity monitoring is used to protect configuration files, executables and public keys/certificates used for security services on any back-end components of the monitoring/attestation system.
Modified
p. 69 → 68
TC3.5 The tester shall confirm the monitor operations staff are adequately trained on the administration and operation of back-end monitoring system.
TC3.5 The tester shall confirm the monitor operations staff are adequately trained on the administration and operation of back-end monitoring system.
Modified
p. 69 → 68
TC3.6 The tester shall confirm that any back-end components of the monitoring system are maintained in an environment compliant to the requirements of Appendix AMonitoring Environment Basic Protections. The tester shall review the assessor reports output of this section and confirm that it covers all parts of the monitoring system, that the audit has been performed by a PCI SSC-qualified assessor and that the audit report was based on work performed, and signed by this assessor, no more than 12 …
TC3.6 The tester shall confirm that any back-end components of the monitoring system are maintained in an environment compliant to the requirements of Appendix A: Monitoring Environment Basic Protections. The tester shall review the assessor reports output of this section and confirm that it covers all parts of the monitoring system, that the audit has been performed by a PCI SSC-qualified assessor and that the audit report was based on work performed, and signed by this assessor, no more than …
Modified
p. 69 → 68
TC3.7 The tester shall confirm that any parts of the monitoring system that exist on the COTS device are protected by the tamper-resistance properties tested under TR B1: PIN CVM Application Tamper Resistance, or shall perform a separate evaluation of the monitor code against these requirements.
TC3.7 The tester shall confirm that any parts of the monitoring system that exist on the COTS device are protected by the tamper-resistance properties tested under TR B1: PIN CVM Application Tamper Resistance, or shall perform a separate evaluation of the monitor code against these requirements.
Modified
p. 69 → 68
TC3.8 The tester shall confirm what mechanisms exist for full traceability of changes and for the system to be reverted to a known-good state in the case of failure, malicious manipulation or other corruption of its correct operation.
TC3.8 The tester shall confirm what mechanisms exist for full traceability of changes and for the system to be reverted to a known-good state in the case of failure, malicious manipulation or other corruption of its correct operation.
Removed
p. 70
As the security landscape changes, platforms or operating systems that may be acceptable under the system baseline may become vulnerable. A documented policy and procedure for assessing these changes must exist and must provide details on how decisions are made to remove previously acceptable platforms from the system baseline. Such changes will affect merchants using these platforms, so the documentation must also include how merchant communication is handled in these cases.
Modified
p. 70 → 69
TC4.1 The tester shall obtain and review the vendor's risk-assessment policy and update procedure documents and confirm that they contain information on:
TC4.1 The tester shall obtain and review the vendor's risk-assessment policy and update procedure documents and confirm that they contain information on:
Modified
p. 70 → 69
• How and when updates to the system baseline are performed TC4.2 Where possible, the tester shall compare the information in the policy with actual changes made to the system baseline to confirm that the policy is being correctly followed.
Modified
p. 71 → 70
It can be expected that attacks against software-based PIN CVM Solutions will include the attempt to bypass security in the SCRP. Such attempts may not be initially successful, and therefore changing between different components by a single merchant, or changing of the same component between different merchants, may be an indication of attempted system compromise. It is not a requirement that detecting changing of these devices or merchants automatically results in the blocking of that merchant account, but documented procedures …
It can be expected that attacks against software-based PIN CVM solutions include the attempt to bypass security in the SCRP. Such attempts may not be initially successful, and therefore changing between different components by a single merchant, or changing of the same component between different merchants, may be an indication of attempted system compromise. It is not a requirement that detecting changing of these devices or merchants automatically results in the blocking of that merchant account, but documented procedures must …
Modified
p. 71 → 70
The connection between system components must be secured through use of cryptography. This connection must be implemented to prevent man-in-the-middle and replay attacks on data, as well as preventing traffic analysis to determine the type or content of data communicated between the components.
The connection between system components must be secured through use of cryptography. This connection must be implemented to prevent MITM and replay attacks on data, as well as preventing traffic analysis to determine the type or content of data communicated between the components.
Modified
p. 71 → 70
TD1.1 The tester shall confirm that mechanisms exist to uniquely identify and validate the SCRP and PIN CVM Application as authorized. The tester shall detail these mechanisms, as well as the criteria used to authorize their use.
TD1.1 The tester shall confirm that mechanisms exist to uniquely identify and validate the SCRP and PIN CVM application as authorized. The tester shall detail these mechanisms, as well as the criteria used to authorize their use.
Modified
p. 71 → 70
TD1.2 The tester shall confirm that the system implements and enforces methods for the PIN CVM Application to validate the SCRP prior to communication of any sensitive data with that SCRP, or performance of any payment transactions.
TD1.2 The tester shall confirm that the system implements and enforces methods for the PIN CVM application to validate the SCRP prior to communication of any sensitive data with that SCRP, or performance of any payment transactions.
Modified
p. 71 → 70
TD1.4 The tester shall note what methods are implemented to prevent traffic analysis for the purposes of determining sensitive information on each of the paired interfaces present in The Solution. It is expected that this will require monitoring of the interface during operation.
TD1.4 The tester shall note what methods are implemented to prevent traffic analysis for the purposes of determining sensitive information on each of the paired interfaces present in the solution. It is expected that this will require monitoring of the interface during operation.
Modified
p. 72 → 71
A secure channel is a communications connection between two points that is secured using cryptographic techniques. Separate secure channels, using unique cryptographic keys, must be established between the SCRP and PIN CVM Application, as well as the PIN CVM Application and monitor, and PIN CVM Application and payment network.
A secure channel is a communications connection between two points that is secured using cryptographic techniques. Separate secure channels, using unique cryptographic keys, must be established between the SCRP and PIN CVM application, as well as the PIN CVM application and monitor, and PIN CVM application and payment network.
Modified
p. 72 → 71
TD2.1 The tester shall outline logical connections between the PIN CVM Application and other components of the system, using diagrams where appropriate. For each connection, the tester shall detail the method used to provide a secure channel between the PIN CVM Application and that component.
TD2.1 The tester shall outline logical connections between the PIN CVM application and other components of the system, using diagrams where appropriate. For each connection, the tester shall detail the method used to provide a secure channel between the PIN CVM application and that component.
Removed
p. 73
§ The version of TLS used § Whether the TLS code is implemented in the PIN CVM Application itself, or whether the platform is relied upon to establish this connection. Where the PIN CVM Application implements the TLS connection itself, the tester shall note the source and version of the TLS code used.
Modified
p. 73 → 72
• What method is used to enforce only authentic connections and use of authentic certificates (e.g., "certificate pinning" or similar) TD2.7 The tester shall confirm that no secret or sensitive data is transferred between the devices prior to the establishment of the secure channel. This must include any aspects of the provisioning process assessed under the Secure Provisioning requirement.
Modified
p. 74 → 73
Storage areas for customer data must be logically isolated from the back-end processing environments, using different network segments with access controls that prevent direct connections between the two areas.
Storage areas for customer data must be logically isolated from the back-end processing environments, using different network segments with access controls that prevent direct connections between the two areas.
Modified
p. 74 → 73
TD3.3 The tester shall verify that customer data entered into the PIN CVM Application is cleared after being sent to the back-end processing systems and that customer data is never stored on the merchant device.
TD3.3 The tester shall verify that customer data entered into the PIN CVM application is cleared after being sent to the back-end processing systems and that customer data is never stored on the merchant device.
Modified
p. 74 → 73
TD3.4 The tester shall confirm that cardholder data decryption must only occur in the back-end processing environment.
TD3.4 The tester shall confirm that cardholder data decryption must only occur in the back-end processing environment.
Modified
p. 75 → 74
Anomaly-detection systems must monitor multiple data points for determining patterns in potentially fraudulent activity. These may include, but may not be limited to, data such as merchant ID, SCRP ID and keysets, PIN CVM application ID and keysets, geographical location of the merchant, merchant phone number and (e-mail) addresses, merchant relationships with other merchants who may use the system, historical data about merchant operations such as chargebacks, merchant type, transaction volume and velocity, etc.
Modified
p. 75 → 74
TD4.1 The tester shall detail how the anomaly-detection system is implemented and maintained by the vendor. This must include how potential fraudulent activity is escalated and what the response to such activity may be.
TD4.1 The tester shall detail how the anomaly-detection system is implemented and maintained by the vendor. This must include how potential fraudulent activity is escalated and what the response to such activity may be.
Modified
p. 75 → 74
• Merchant level transactional velocities that are statistically inconsistent with historical transaction volumes associated with PIN-based transactions • Anomalous merchant activity related to area of geographical use inconsistent with historical activity associated with PIN-based transactions • Individual PAN usage velocities for PIN-based transactions that may be associated with probing or testing detection capabilities in an attempt to circumvent such controls • Suspicious activity associated with multiple transactions originating from individual PANs for PIN-based transactions within time frames inconsistent with merchant …
Modified
p. 75 → 74
TD4.4 The tester shall confirm that the anomaly-detection system operates “out of band”¾that is, it must monitor transactions but not be an integral part of payment processing.
TD4.4 The tester shall confirm that the anomaly-detection system operates “out of band” − that is, it must monitor transactions but not be an integral part of payment processing.
Modified
p. 76 → 75
Back-end systems include the payment processing environment, as well as the monitoring systems. PCI DSS compliance must include the PIN acceptance solution in the scope of assessment, including, but not necessarily limited to, all equipment, software, procedures and personnel.
Modified
p. 76 → 75
If PAN or SAD is present anywhere in the back-end monitoring environment, a full PCI DSS plus DESV Assessment is required.
If PAN or SAD is present anywhere in the back-end monitoring environment, a full PCI DSS plus DESV Assessment is required.
Modified
p. 76 → 75
TE1.1 The tester shall obtain and review the Attestation of Compliance (AoC) outlining compliance of the vendor environment to the PCI DSS requirements. This AoC must cover the scope of the back-end attestation/monitoring environment and payment processing environment (although it may not cover non-payment-related functions such as the monitoring system).
TE1.1 The tester shall obtain and review the Attestation of Compliance (AoC) outlining compliance of the vendor environment to the PCI DSS requirements. This AoC must cover the scope of the back-end attestation/monitoring environment and payment processing environment (although it may not cover non-payment-related functions such as the monitoring system).
Modified
p. 76 → 75
TE1.2 Where the monitoring system is included in the scope of the PCI DSS assessment, the tester shall confirm that the monitoring environment has been assessed to the additional controls outlined in Appendix A3 of PCI DSS, “Designated Entities Supplemental Validation.” TE1.3 Where areas of the vendor system are not covered by the AoC (for example, because they do not store, process or transmit customer card data), but are considered important for the security of the PIN acceptance system, the …
TE1.2 Where the monitoring system is included in the scope of the PCI DSS assessment, the tester shall confirm that the monitoring environment has been assessed to the additional controls outlined in Appendix A3 of PCI DSS, “Designated Entities Supplemental Validation.” TE1.3 Where areas of the vendor system are not covered by the AoC (for example, because they do not store, process or transmit account data), but are considered important for the security of the PIN acceptance system, the tester …
Modified
p. 76 → 75
TE1.4 The tester shall confirm that the AoC was signed by a PCI SSC-qualified QSA within the last 12 months.
TE1.4 The tester shall confirm that the AoC was signed by a PCI SSC-qualified QSA within the last 12 months.
Modified
p. 76 → 75
TE1.5 The tester shall confirm that the back-end monitoring systems have been assessed to the requirements contained in Appendix A: Monitoring Environment Basic Protections. If the assessment has been performed by a separate entity, the tester shall have access to the report output and shall validate that it included in scope all areas of the back-end monitoring systems and that it was performed by an approved entity.
TE1.5 The tester shall confirm that the back-end monitoring systems have been assessed to the requirements contained in Appendix A: Monitoring Environment Basic Protections. If the assessment has been performed by a separate entity, the tester shall have access to the report output and shall validate that it included in scope all areas of the back-end monitoring systems and that it was performed by an approved entity.
Modified
p. 77 → 76
The scope of any PCI PIN audit must include the PIN on COTS PIN methods and equipment. It is understood that use of these systems may result in some areas of non-compliance due to required changes to the PCI PTS SCRP and entry of PINs on non-PTS-approved systems, but such instances should be noted and may be dismissed.
The scope of any PCI PIN audit must include the PIN on COTS PIN methods and equipment. It is understood that use of these systems may result in some areas of non-compliance due to required changes to the PCI PTS SCRP and entry of PINs on non-PTS-approved systems, but such instances should be noted and may be dismissed.
Modified
p. 77 → 76
TE2.1 The tester shall confirm that the back-end payment processing system has been assessed as compliant to the PCI PIN requirements by a PIN auditor approved by one of the PCI SSC brands.
TE2.1 The tester shall confirm that the back-end payment processing system has been assessed as compliant to the PCI PIN requirements by a PIN auditor approved by one of the PCI SSC brands.
Removed
p. 78
SCRPs evaluated to PCI PTS may not have been confirmed to protect cryptographic keys and prevent penetration attacks to the level required of this standard. Where a device cannot be confirmed to meet these requirements (through examination of the approved PCI PTS report), the assessor shall require further evaluation of the system by an approved PCI PTS laboratory.
TF1.2 The tester shall confirm, either through direct review of the PCI PTS test report or communication with the testing laboratory, that all the SCRP devices that may be used with the system have been assessed to provide secret key protection to 35 PCI points, with 15 points for exploitation. The tester shall further verify that all secret and private keys used by the SCRP are secured to this level (that is, no keys are stored in a manner that was not assessed to this level during the PCI PTS evaluation).
TF1.3 The tester …
TF1.2 The tester shall confirm, either through direct review of the PCI PTS test report or communication with the testing laboratory, that all the SCRP devices that may be used with the system have been assessed to provide secret key protection to 35 PCI points, with 15 points for exploitation. The tester shall further verify that all secret and private keys used by the SCRP are secured to this level (that is, no keys are stored in a manner that was not assessed to this level during the PCI PTS evaluation).
TF1.3 The tester …
Modified
p. 78 → 77
For compliance to these requirements, SCRPs used must have been evaluated to the PCI PTS v4 requirements or above.
For compliance to these requirements, SCRPs used must be an approved PCI PTS device that is listed on the PCI SSC Approved Device website with an SCRP Approval Class.
Modified
p. 78 → 77
TF1.1 The tester shall confirm that the only method of entry for the customer card data or PAN value is an SCRP that is approved under the PCI PTS requirements, version 4 or above. The tester shall list all SCRPs used for the acceptance of card data by the system and shall provide the PCI PTS approval number for each.
TF1.1 The tester shall confirm that the only method of entry for the account data read from chip-based transactions is an approved PCI PTS device that is listed on the PCI SSC Approved Device website with an SCRP Approval Class. The tester shall list all SCRPs used for the acceptance of card data by the system and shall provide the PCI PTS approval number for each.
Modified
p. 78 → 77
TF1.2 For each of the SCRP devices used by the system, the tester shall review the Security Policy document and confirm that the cryptography used by the SCRP, as assessed throughout this standard, is listed within the document. Where this cryptography is not listed in the security policy, compliance to this requirement must involve re-assessment of the changes to the SCRP by an approved PCI PTS laboratory.
Modified
p. 78 → 77
TF1.3 For each of the SCRP devices used by the system, the tester shall review the Security Policy document and confirm that the SCRP was approved for use with PINs and to provide PIN translation. Where these functions are not listed in the security policy, compliance to this requirement must involve re-assessment of the changes to the SCRP by an approved PCI PTS laboratory.
Modified
p. 80 → 79
1. Physical, Attacker Present vs. Non-Physical, Attacker Remote Attacking a hardware tamper-responsive system such as a PCI PTS POI device generally requires an attacker to be physically present with the attack target. Hardware security controls are implemented to both detect and respond to a physical attack against the system. Once detected, the typical response of a hardware tamper-responsive system is to delete all sensitive assets with no means to recover.
1. Physical, Attacker Present vs. Non-Physical, Attacker Remote Attacking a hardware tamper-responsive system such as a PCI PTS POI device generally requires an attacker to be physically present with the attack target. Hardware security controls are implemented to both detect and respond to a physical attack against the system. Once detected, the typical response of a hardware tamper-responsive system is to delete all sensitive assets with no means to recover.
Modified
p. 80 → 79
Attacking a software-tamper-responsive system, on the other hand, does not generally require the attacker to be physically present with the attack target. While some attack vectors would require physical access to the system, software attack vectors are usually executed remotely. For example, attacks may be executed with a piece of code or an application under a different execution or privilege context•e.g., an app with root privileges attacking the system in user mode. Hence, detection of the attack attempt may not …
Attacking a software-tamper-responsive system, on the other hand, does not generally require the attacker to be physically present with the attack target. While some attack vectors would require physical access to the system, software attack vectors are usually executed remotely. For example, attacks may be executed with a piece of code or an application under a different execution or privilege context•e.g., an app with root privileges attacking the system in user mode. Hence, detection of the attack attempt may not …
Modified
p. 80 → 79
2. Standalone Detection vs. Distributed Detection Detection mechanisms of a hardware tamper-responsive system are typically self-contained within the device, relying on a change in a physical property (e.g., temperature or voltage) to detect an attack. The available data for the attack detection engine is typically well defined. The decision- making process of the detection engine is therefore binary in its conclusion as to whether the system is under some form of attack.
2. Standalone Detection vs. Distributed Detection Detection mechanisms of a hardware tamper-responsive system are typically self-contained within the device, relying on a change in a physical property (e.g., temperature or voltage) to detect an attack. The available data for the attack detection engine is typically well defined. The decision- making process of the detection engine is therefore binary in its conclusion as to whether the system is under some form of attack.
Modified
p. 80 → 79
Software tamper-responsive systems are typically implemented with tamper-detection capabilities distributed between both the mobile application and the back-end monitoring system where the attack detection engine is located. The mobile application may also be used to gather local system data that is then sent to the back-end, where it is used by anomaly-detection algorithms to decide whether an actual attack has happened on the local system. The back-end monitoring system will then make a corresponding response decision. As a result, the …
Software tamper-responsive systems are typically implemented with tamper-detection capabilities distributed between both the mobile application and the back-end monitoring system where the attack detection engine is located. The mobile application may also be used to gather local system data that is then sent to the back-end, where it is used by anomaly-detection algorithms to decide whether an actual attack has happened on the local system. The back-end monitoring system will then make a corresponding response decision. As a result, the …
Modified
p. 80 → 79
3. Individually vs. Collectively Due to the nature of the attacks against hardware-tamper mechanisms, such attacks have to be conducted individually, one device at a time, by the attacker. Each device under attack is physically subjected to the same exploitation process in an attempt to compromise the hardware-based protection.
3. Individually vs. Collectively Due to the nature of the attacks against hardware-tamper mechanisms, such attacks have to be conducted individually, one device at a time, by the attacker. Each device under attack is physically subjected to the same exploitation process in an attempt to compromise the hardware-based protection.
Modified
p. 80 → 79
On the other hand, exploits against software tamper-responsive systems may target the entire collection of similar systems using a malware or virus as the distribution medium. Hence, attack 1 This Appendix assumes that the reader is familiar with the concepts captured within Appendix B: Physical Attack Potential Formula covered within the PCI PTS POI Derived Test Requirements document.
On the other hand, exploits against software tamper-responsive systems may target the entire collection of similar systems using a malware or virus as the distribution medium. Hence, attack 1 This Appendix assumes that the reader is familiar with the concepts captured within Appendix B: Physical Attack Potential Formula covered within the PCI PTS POI Derived Test Requirements document.
Modified
p. 81 → 80
The objective of this framework is to model attack vectors that deployed solutions may potentially encounter. The cost model will not include attack vectors that are not also considered by this standard¾for example, direct hardware attack on the device during the exploitation stages.
The objective of this framework is to model attack vectors that deployed solutions may potentially encounter. The cost model will not include attack vectors that are not also considered by this standard − for example, direct hardware attack on the device during the exploitation stages.
Modified
p. 81 → 80
Additional Considerations for Attack Cost Calculations From the above differences, we derive the following factors that are considered when developing the attack cost framework for a software tamper-responsive system. The attack cost factors are grouped into Attacker Present, Attacker Remote and Back-end Monitoring:
Additional Considerations for Attack Cost Calculations From the above differences, we derive the following factors that are considered when developing the attack cost framework for a software tamper-responsive system. The attack cost factors are grouped into Attacker Present, Attacker Remote and Back-end Monitoring:
Modified
p. 81 → 80
Attacker Present Attackers typically have full access to the PIN CVM Application downloaded from the web store and the COTS device on which the application is running. With the device in front of him/her, the attacker can proceed to identify and exploit both the PIN CVM Application and COTS device. Factors below consider the attack cost where an attack vector requires physical access to the PIN CVM Application and COTS device:
Attacker Present Attackers typically have full access to the PIN CVM application downloaded from the web store and the COTS device on which the application is running. With the device in front of him/her, the attacker can proceed to identify and exploit both the PIN CVM application and COTS device. Factors below consider the attack cost where an attack vector requires physical access to the PIN CVM application and COTS device:
Modified
p. 81 → 80
a) Remote, no user interaction: The attack is executed remotely on a target device and no user interaction is expected by the user for the attack to be successful. Example of such an attack vector is when malicious code is injected into the PIN CVM Application.
a) Remote, no user interaction: The attack is executed remotely on a target device and no user interaction is expected by the user for the attack to be successful. Example of such an attack vector is when malicious code is injected into the PIN CVM application.
Modified
p. 82 → 81
a) Identification Costing As part of calculating the attack cost of attacking the solution, the lab should take into consideration reliance by the PIN CVM Application on native COTS security features as well as any other security controls that the vendor has integrated into the solution like obfuscation, white-box crypto, etc.
a) Identification Costing As part of calculating the attack cost of attacking the solution, the lab should take into consideration reliance by the PIN CVM application on native COTS security features as well as any other security controls that the vendor has integrated into the solution like obfuscation, white-box crypto, etc.
Modified
p. 82 → 81
At the same time, the lab should also take into consideration the four factors above (Scalability, Expertise to Execute the Attack Vector, Quality of Attestation Data and Knowledge of the Back-end Monitoring System) in the estimation of the attack time for the identification phase.
At the same time, the lab should also take into consideration the four factors above (Scalability, Expertise to Execute the Attack Vector, Quality of Attestation Data and Knowledge of the Back-end Monitoring System) in the estimation of the attack time for the identification phase.
Modified
p. 82 → 81
b) Exploitation Costing In calculating the attack time exploitation cost, the operational quality of the back-end monitoring system must be factored into it. The lab will be required to have access to the back-end monitoring system as it assesses the exploitation attack time factor. This is required to ensure that the attack exploitation time takes into consideration how the back-end monitoring system will respond to the specific attack vector. The lab is expected to evaluate the operational quality of the …
b) Exploitation Costing In calculating the attack time exploitation cost, the operational quality of the back-end monitoring system must be factored into it. The lab will be required to have access to the back-end monitoring system as it assesses the exploitation attack time factor. This is required to ensure that the attack exploitation time takes into consideration how the back-end monitoring system will respond to the specific attack vector. The lab is expected to evaluate the operational quality of the …
Modified
p. 83 → 82
5. Scalability Factor While the time and resources required to identify and exploit a vulnerability are the same for both hardware and software tamper-responsive systems, we have to take into consideration that a software attack on a solution running on a COTS platform may be scalable to impact a population of similar systems within a very short timeframe. The same exploit can be optimized to apply to different system configurations. Customization would then include consideration and identification of the deployment …
5. Scalability Factor While the time and resources required to identify and exploit a vulnerability may be the same for both hardware and software tamper-responsive systems, we have to take into consideration that a software attack on a solution running on a COTS platform may be scalable to impact a population of similar systems within a very short timeframe. The same exploit can be optimized to apply to different system configurations. Customization would then include consideration and identification of the …
Modified
p. 84 → 83
a) Identification Costing As part of calculating the attack cost of attacking the solution, the lab should take into consideration reliance by the PIN CVM Application on native COTS security features as well as any other security controls that the vendor has integrated into the solution like obfuscation, white-box crypto, etc.
a) Identification Costing As part of calculating the attack cost of attacking the solution, the lab should take into consideration reliance by the PIN CVM application on native COTS security features as well as any other security controls that the vendor has integrated into the solution like obfuscation, white-box crypto, etc.
Modified
p. 84 → 83
7. Quality of Attestation Data To bypass the monitoring system, the attacker has to suppress or simulate the attestation data sent by the PIN CVM Application to the back-end monitoring system. Hence, the ability of the PIN CVM Application to send the attestation data and the quality of the attestation data are important in determining the effort required to simulate this data to subvert the back-end monitoring system. The levels of the attestation data can be differentiated as:
7. Quality of Attestation Data To bypass the monitoring system, the attacker has to suppress or simulate the attestation data sent by the PIN CVM application to the back-end monitoring system. Hence, the ability of the PIN CVM application to send the attestation data and the quality of the attestation data are important in determining the effort required to simulate this data to subvert the back-end monitoring system. The levels of the attestation data can be differentiated as:
Modified
p. 84 → 83
a) Low quality, where the data is easily suppressed or can be easily simulated by another application with the intent of fooling the back-end monitoring system that the system has not been modified. Examples of such data known to be easily spoofed include but are not limited to geolocation data and the device’s IP address.
a) Low quality, where the data is easily suppressed or can be easily simulated by another application with the intent of fooling the back-end monitoring system that the system has not been modified. Examples of such data known to be easily spoofed include but are not limited to geolocation data and the device’s IP address.
Modified
p. 84 → 83
b) Medium quality, where the data provides a high level of assurance that the information is authentic and has not been spoofed. An example is the integrity information from white-box crypto solutions.
b) Medium quality, where the data provides a high level of assurance that the information is authentic and has not been spoofed. An example might be the integrity information from a software-based protection mechanism, such as white-box cryptography solutions.
Modified
p. 84 → 83
c) High quality, where the data cannot be easily spoofed or simulated. Examples are cryptographically based attestation data or attestation data that contains information obtained from the underlying hardware. Examples of such data include information from hardware- based modules like secure elements or security processors.
c) High quality, where the data cannot be easily spoofed or simulated. Examples are cryptographically based attestation data or attestation data that contains information obtained from the underlying hardware. Examples of such data include information from hardware- based modules like secure elements or security processors.
Modified
p. 84 → 83
The quality of the attestation data does not apply to any individual datum, but to the sum of all the attestation data provided by the PIN CVM Application to the back-end monitoring system by which attack detection decisions are made. It is the responsibility of the lab to determine the rating of the quality of the combined set of attestation data.
The quality of the attestation data does not apply to any individual datum, but to the sum of all the attestation data provided by the PIN CVM application to the back-end monitoring system by which attack detection decisions are made. It is the responsibility of the lab to determine the rating of the quality of the combined set of attestation data.
Modified
p. 84 → 83
8. Knowledge of the Back-end Monitoring Systems This refers to the information of the back-end monitoring systems. It includes information on its capabilities and behavior, possibly including the anomaly detection algorithms used to interpret the various attestation data that comes from the application. Identified levels are as follows:
8. Knowledge of the Back-end Monitoring Systems This refers to the information of the back-end monitoring systems. It includes information on its capabilities and behavior, possibly including the anomaly detection algorithms used to interpret the various attestation data that comes from the application. Identified levels are as follows:
Modified
p. 84 → 83
a) Public information about the back-end monitoring system (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.
a) Public information about the back-end monitoring system (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.
Modified
p. 84 → 83
b) Restricted information concerning the back-end monitoring system (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered•for example, like the PCI PTS POI DTRs.
b) Restricted information concerning the back-end monitoring system (for example, as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered•for example, like the PCI PTS POI DTRs.
Modified
p. 84 → 83
c) Sensitive information about the back-end monitoring system•for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering.
c) Sensitive information about the back-end monitoring system•for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering.
Modified
p. 85 → 84
b) Exploitation Costing In calculating the attack time exploitation cost, the operational quality of the back-end monitoring system must be factored into the cost. The lab will be required to have access to the back-end monitoring system as it assesses the exploitation attack time factor. This is required to ensure that the attack exploitation time takes into consideration how the back-end monitoring system will respond to the specific attack vector. The lab is expected to evaluate the operational quality of …
b) Exploitation Costing In calculating the attack time exploitation cost, the operational quality of the back-end monitoring system must be factored into the cost. The lab will be required to have access to the back-end monitoring system as it assesses the exploitation attack time factor. This is required to ensure that the attack exploitation time takes into consideration how the back-end monitoring system will respond to the specific attack vector. The lab is expected to evaluate the operational quality of …
Modified
p. 85 → 84
Back-end Monitoring The back-end monitoring system is a critical component of the overall software tamper-responsive system. This component is especially critical in a software-based PIN entry solution where depending on security and risk management policies, the monitoring system may immediately terminate the PIN entry capability of any COTS where there are signs that the device may be compromised.
Modified
p. 85 → 84
10. Operational Quality of Back-end Monitoring System It is important that the various rules used for anomaly detection, processes to update the monitoring systems, detection data from the PIN CVM Application, etc. are constantly updated based on the latest information available. This will in a large part depend on proficient personnel trained to identify attack signatures and provide the relevant updates to the back-end monitoring systems.
10. Operational Quality of Back-end Monitoring System It is important that the various rules used for anomaly detection, processes to update the monitoring systems, detection data from the PIN CVM application, etc. are constantly updated based on the latest information available. This will in a large part depend on proficient personnel trained to identify attack signatures and provide the relevant updates to the back-end monitoring systems.
Modified
p. 85 → 84
a) Low operational quality, where the rules, policies, processes and personnel involved in operating the back-end monitoring system are not able to demonstrate the proficiency required to ensure the timely identification of attacks attempts.
a) Low operational quality, where the rules, policies, processes and personnel involved in operating the back-end monitoring system are not able to demonstrate the proficiency required to ensure the timely identification of attack attempts.
Modified
p. 85 → 84
b) Medium operational quality, where the lab was able to establish a level of comfort where the rules, policies, processes and personnel operating the back-end monitoring system understand their roles and will ensure that the majority of attack attempts identified.
b) Medium operational quality, where the lab was able to establish a level of comfort where the rules, policies, processes and personnel operating the back-end monitoring system understand their roles and will ensure that the majority of attack attempts are identified.
Modified
p. 85 → 84
c) High operational quality, where the rules, policies, processes and personnel involved in operating the back-end monitoring system demonstrate a high level of proficiency that provide the assurances to the lab that any attack attempts will be promptly identified and the system updated to respond appropriately to any future attempts.
c) High operational quality, where the rules, policies, processes and personnel involved in operating the back-end monitoring system demonstrate a high level of proficiency that provide the assurances to the lab that any attack attempts will be promptly identified and that the system will be updated to respond appropriately to any future attempts.
Modified
p. 85 → 84
It is expected that the lab provides an initial identification of the operational quality of the back- end monitoring system as the solution is first presented for testing. Since the solution would not have been in production, the initial identification costing of the quality would only provide a baseline cost. Subsequent periodic testing will then be required to determine the exploitation attack cost of the quality of the back-end monitoring system.
It is expected that the lab provides an initial identification of the operational quality of the back- end monitoring system as the solution is first presented for testing. Since the solution would not have been in production, the initial identification costing of the quality would only provide a baseline cost. Subsequent periodic testing will then be required to determine the exploitation attack cost of the quality of the back-end monitoring system.
Modified
p. 85 → 84
Given the nature and importance placed on back-end monitoring systems, vendor solutions that are rated Low either during the initial evaluation or during subsequent periodic testing will immediately fail the evaluation.
Given the nature and importance placed on back-end monitoring systems, vendor solutions that are rated Low either during the initial evaluation or during subsequent periodic testing will immediately fail the evaluation.
Modified
p. 87 → 86
Operational Quality of Back-end Monitoring Systems
• Exploitation Unlike ahardware-based responsive system that has limited opportunity to be updated in the field, a software-based tamper-responsive system with a back-end monitoring component has continued opportunity and expectation for the solution to be constantly updated and patched in response to newly discovered vulnerabilities. Hence, when evaluating the cost to exploit software-based tamper- responsive systems, it is important to also include an ongoing evaluation of the operational quality of the back-end monitoring system …
• Exploitation Unlike a
Operational Quality of Back-end Monitoring Systems
• Exploitation Unlike a hardware-based responsive system that has limited opportunity to be updated in the field, a software-based tamper-responsive system with a back-end monitoring component has continued opportunity and expectation for the solution to be constantly updated and patched in response to newly discovered vulnerabilities. Hence, when evaluating the cost to exploit software-based tamper- responsive systems, it is important to also include an ongoing evaluation of the operational quality of the back-end monitoring system …
• Exploitation Unlike a hardware-based responsive system that has limited opportunity to be updated in the field, a software-based tamper-responsive system with a back-end monitoring component has continued opportunity and expectation for the solution to be constantly updated and patched in response to newly discovered vulnerabilities. Hence, when evaluating the cost to exploit software-based tamper- responsive systems, it is important to also include an ongoing evaluation of the operational quality of the back-end monitoring system …
Modified
p. 87 → 86
Therefore, it is expected that a periodic testing of the back-end monitoring system be conducted to ensure its operational quality is being maintained. This testing will be executed in production like the current quarterly scan requirement under PCI DSS. The objective of this ongoing assessment is to ensure operational quality for the back-end monitoring system and how it has been updated to respond to newly identified attack vectors and vulnerabilities and provide in-field update of the PIN CVM Application.
Therefore, it is expected that a periodic testing of the back-end monitoring system be conducted to ensure its operational quality is being maintained. This testing will be executed in production like the current quarterly scan requirement under PCI DSS. The objective of this ongoing assessment is to ensure operational quality for the back-end monitoring system and how it has been updated to respond to newly identified attack vectors and vulnerabilities and provide in-field update of the PIN CVM application.
Removed
p. 88
3. The monitoring system is of low quality (will not detect if other apps are running as root).
Modified
p. 88 → 87
1. Provide tester with vendor information on the various attestation data and events that would result in back-end monitoring system alerts.
1. Provide tester with vendor information on the various attestation data and events that would result in back-end monitoring system alerts.
Modified
p. 88 → 87
4. Taking the actual merchant distribution of the various COTS platform into consideration, calculate the exploitation cost by evaluating the operational quality of the back-end monitoring system.
4. Taking the actual merchant distribution of the various COTS platform into consideration, calculate the exploitation cost by evaluating the operational quality of the back-end monitoring system.
Modified
p. 88 → 87
2. The obfuscation is sufficient to confuse IDA Pro and require manual reverse engineering but is not applied at the OS/app level for interface to the touch-event data.
2. The obfuscation is sufficient to confuse IDA Pro and require manual reverse engineering but is not applied at the OS/app level for interface to the touch-event data.
Modified
p. 90 → 89
Factor Range Identification Exploitation Access to the COTS device Remote, user interaction required NA 1 Equipment Required Standard/software only 0 0 Expertise to Execute the Attack Skilled NA 1 Attack Time NA NA NA Scalability Factor Customized for each minor OS variant 8 NA Expertise to Optimize the Attack Vector for Scalability Expert NA 4 Quality of Attestation Data (bypassing automated monitoring) Knowledge of the Back-end Monitoring System Public 0 0 Attack Time ≤ 12 hours NA 0* Beyond 1 …
Factor Range Identification Exploitation Access to the COTS Device Remote, user interaction required NA 1 Equipment Required Standard/software only 0 0 Expertise to Execute the Attack Skilled NA 1 Attack Time NA NA NA Scalability Factor Customized for each minor OS variant 8 NA Expertise to Optimize the Attack Vector for Scalability Expert NA 4 Quality of Attestation Data (bypassing automated monitoring) Knowledge of the Back-end Monitoring System Public 0 0 Attack Time ≤ 12 hours NA 0* Beyond 1 …
Modified
p. 91 → 90
2. This means that the attack is not scalable¾it requires full physical and logical access to the attack device and must be developed and installed on that device only
2. This means that the attack is not scalable − it requires full physical and logical access to the attack device and must be developed and installed on that device only
Modified
p. 91 → 90
Factor Range Identification Exploitation Present Access to the COTS Device Local unlocked NA 6 Equipment Required Standard/software Expertise to Execute the Attack Expert NA 4 Attack Time ≤ 12 hours NA 0* Beyond 1 month 8 NA Scalability Factor Customized for each instance 13 NA Expertise to Optimize the Attack Vector for Scalability Expert NA 4 Quality of Attestation Data (bypassing automated monitoring) High 10 10 Knowledge of the Back-end Monitoring System Public 0 0 Attack Time ≤ 12 hours …
Factor Range Identification Exploitation Access to the COTS Device Local unlocked NA 6 Equipment Required Standard/software Expertise to Execute the Attack Expert NA 4 Attack Time ≤ 12 hours NA 0* Beyond 1 month 8 NA Scalability Factor Customized for each instance 13 NA Expertise to Optimize the Attack Vector for Scalability Expert NA 4 Quality of Attestation Data (bypassing automated monitoring) High 10 10 Knowledge of the Back-end Monitoring System Public 0 0 Attack Time ≤ 12 hours NA …
Modified
p. 92 → 91
1. The COTS systems are using a secret/private cryptographic system on the COTS device where the key storage is vulnerable to some remote side-channel extraction¾such as through a cache timing or speculative execution timing vulnerability.
1. The COTS systems are using a secret/private cryptographic system on the COTS device where the key storage is vulnerable to some remote side-channel extraction − such as through a cache timing or speculative execution timing vulnerability.
Modified
p. 92 → 91
Factor Range Identification Exploitation Attacker Present Access to the COTS Device Remote, no user interaction Equipment Required Standard/software only 0 0 Expertise to Execute the Attack Skilled NA 1 Attack Time ≤ 12 hours NA 0* Beyond 1 month 8 NA Attacker Remote Scalability Factor Customized for each Expertise to Optimize the Attack Vector for Scalability Expert NA 4 Quality of Attestation Data (bypassing automated monitoring) Knowledge of the Back-end Monitoring System Public 0 0 Attack Time ≤ 12 hours …
Factor Range Identification Exploitation Attacker Present Access to the COTS Device Remote, no user interaction Equipment Required Standard/software only 0 0 Expertise to Execute the Attack Skilled NA 1 Attack Time ≤ 12 hours NA 0* Beyond 1 month 8 NA Attacker Remote Scalability Factor Customized for each Expertise to Optimize the Attack Vector for Scalability Expert NA 4 Quality of Attestation Data (bypassing automated monitoring) Knowledge of the Back-end Monitoring System Public 0 0 Attack Time ≤ 12 hours …
Modified
p. 93 → 92
Minimum key size in number of bits: 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and key sizes by row are considered equivalent.
Minimum key size in number of bits: 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and key sizes by row are considered equivalent.
Modified
p. 93 → 92
• Minimum key size in number of bits: 3072 256 3072/256 128 Minimum key size in number of bits: 7680 384 7680/384 192 Minimum key size in number of bits: 15360 512 15360/512 256 The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic
DSA/D-H AES Minimum key size in number of bits: 2048 224 2048/224
• Minimum key size in number of bits: 3072 256 3072/256 128 Minimum key size in number of bits: 7680 384 7680/384 192 Minimum key size in number of bits: 15360 512 15360/512 256 The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller …
• Minimum key size in number of bits: 3072 256 3072/256 128 Minimum key size in number of bits: 7680 384 7680/384 192 Minimum key size in number of bits: 15360 512 15360/512 256 The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller …
Modified
p. 93 → 92
For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
Modified
p. 93 → 92
• DH implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity shall generate a private key x and a public key y using the domain parameters (p, q, g).
• DH implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity shall generate a private key x and a public key y using the domain parameters (p, q, g).
Modified
p. 93 → 92
• ECDH implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity shall generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS186-4 for methods of generating d and Q.)
• ECDH implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity shall generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS186-4 for methods of generating d and Q.)
Modified
p. 93 → 92
• Each private key shall be statistically unique, unpredictable and created using an approved random number generator as described in this document.
• Each private key shall be statistically unique, unpredictable and created using an approved RNG as described in this document.
Removed
p. 95
§ Signal analysis and signal processing software, capable of filtering, compressing, synchronizing or otherwise effectively operating on acquired signals § Side-channel analysis test tools including effective user interfaces and configurable collection and analysis components § Fault injection resources such as perturbation source and glitch control tools for these sources, for example: pulse generators, lasers, etc.
Modified
p. 95 → 94
• Interfaces for equipment and devices under test, for example: cables, communications software, smart card reader, etc.
Modified
p. 95 → 94
• Environmental chambers for variable temperatures, etc.
Modified
p. 95 → 94
• Electronics testing tools, for example: variable voltage supplies, signal generators, amplifiers, digital storage oscilloscope, etc.
Modified
p. 95 → 94
• Signal acquisition equipment, for example: antennae, probes, EM coils, microphones, etc.
Modified
p. 95 → 94
• Tools and interfaces capable of communicating with devices over various protocols to investigate logical anomalies and error-exploitation attacks such as fuzzing, for example: protocol analyzers and sniffers, configuration and analysis software, test scripts, etc.
Modified
p. 95 → 94
• Use of web proxies and traffic interception tools for client server traffic analysis The laboratory must have effective arrangements for utilizing vendor test tools when necessary, for device-specific testing.
Removed
p. 96
§ Familiarity with mobile execution environments and their security models;; for example, Android and iOS § Familiarity with software protection tools and their analysis, including obfuscation and white-box cryptography § Familiarity with hooking techniques § Device physical components: structure and materials, how multiple components combine to realize security objectives and how flaws can be identified and/or exploited § Device security-critical components design and functionality, such as (but not restricted to): keypads, displays and cases § Schematic representations of hardware and logic, for example, Gerber files and block diagrams;; and the ability to detect flaws or weaknesses from these § Device logical components: architecture functions, of how multiple components interact to realize security objectives and how flaws can be identified and/or exploited § Formulation and analysis of all aspects of monitoring, penetration or modification attacks;; for example, but not restricted to: device modification (electronic, mechanical and chemical), side- channel analysis and …
Removed
p. 97
§ Supporting documentation that will aid the evaluation, such as block diagrams, schematics and flowcharts § Any necessary hardware and software accessories required to perform software-based PIN CVM Application functionality § Documentation that relates to the development process that can be audited by the laboratory. Examples of such documentation include:
Modified
p. 97 → 96
• Change-control logs
• Change-control logs
Modified
p. 97 → 96
• Change records § The user guidance provided by the vendor that includes a description of system level security mechanisms that mitigate vulnerabilities that may be present in the PIN CVM Application and mobile device Laboratory Evaluation of Product and Monitoring Environment Basic Protections The magnitude and scope of the evaluation of the PIN acceptance solution will vary depending upon the solution architecture. The evaluation includes a threat and vulnerability assessment of identified security assets. The vulnerability analysis should include …
• The user guidance provided by the vendor that includes a description of system level security mechanisms that mitigate vulnerabilities that may be present in the PIN CVM application and mobile device Laboratory Evaluation of Product and Monitoring Environment Basic Protections The magnitude and scope of the evaluation of the PIN acceptance solution will vary depending upon the solution architecture. The evaluation includes a threat and vulnerability assessment of identified security assets. The vulnerability analysis should include currently known logical …
Modified
p. 97 → 96
Evaluation may include physical testing of product samples, assessment of the design documentation or auditing of the vendor’s development processes. See section "Documentation and Materials.” Laboratory Review of Software Protection Tools When the PIN CVM Application is protected using software protection tools, the laboratory should apply evaluation techniques that are appropriate to those tools and try to bypass them or determine their effectiveness in protecting PIN CVM Application assets, including:
Evaluation may include physical testing of product samples, assessment of the design documentation or auditing of the vendor’s development processes. See section "Documentation and Materials.” Laboratory Review of Software Protection Tools When the PIN CVM application is protected using software protection tools, the laboratory should apply evaluation techniques that are appropriate to those tools and try to bypass them or determine their effectiveness in protecting PIN CVM application assets, including:
Modified
p. 98 → 97
Note: The laboratory will have to be able to justify any re-use of assurance within the context of the PIN CVM Application evaluation if the tool has a number of parameterization options.
Note: The laboratory will have to be able to justify any re-use of assurance within the context of the PIN CVM application evaluation if the tool has a number of parameterization options.
Modified
p. 98 → 97
If the PIN CVM Application solution delegates functionality to open source libraries, these must also form part of the code review.
If the PIN CVM application solution delegates functionality to open source libraries, these must also form part of the code review.
Modified
p. 98 → 97
If the (third-party) vendor of such tools can provide independent assurance for their integration with the PIN CVM Application, it may be useful for the laboratory assessment;; however, if the tool is configurable, the final assurance will be qualified by the level of configuration of the tools rather than the assurance provided by the tool itself.
If the (third-party) vendor of such tools can provide independent assurance for their integration with the PIN CVM application, it may be useful for the laboratory assessment; however, if the tool is configurable, the final assurance will be qualified by the level of configuration of the tools rather than the assurance provided by the tool itself.
Modified
p. 98 → 97
Laboratory Review of Source Code Development Processes The integrity of the PIN CVM Application solution software development process contributes to the assurance provided by the final product. The laboratory will establish that the vendor has implemented a software development methodology that includes quality controls and change controls.
Laboratory Review of Source Code Development Processes The integrity of the PIN CVM application solution software development process contributes to the assurance provided by the final product. The laboratory will establish that the vendor has implemented a software development methodology that includes quality controls and change controls.
Modified
p. 98 → 97
Server-based Security Mechanisms The PIN CVM application relies on server-based mechanisms as part of its security support. For example, rooting detection may be implemented by a server that samples the runtime environment of the mobile device, or WB components may be implemented at the server. It is expected that the laboratory includes a full analysis of these mechanisms as they provide a major part of the system security.
Modified
p. 98 → 97
Residual Risk If at the end of the evaluation there remain any unevaluated proprietary components that contribute to the PIN CVM Application’s solution security functionality, then these will be listed as a Residual Risk to the system.
Residual Risk If at the end of the evaluation there remain any unevaluated proprietary components that contribute to the PIN CVM application’s solution security functionality, then these will be listed as a Residual Risk to the system.
Modified
p. 98 → 97
1. The security evaluation report of both the PIN CVM Application and the Monitoring Environment Basic Protections and its associated user guidance
1. The security evaluation report of both the PIN CVM application and the Monitoring Environment Basic Protections and its associated user guidance
Modified
p. 99 → 98
• A description of what was provided to the evaluation laboratory by the vendor • A description of any existing assurance that was used to support the evaluation • Whether a full, delta or other type of evaluation was performed • A description of the product architecture with accompanying diagrams • For the PIN CVM application on the COTS device
Modified
p. 99 → 98
• Detail of any residual vulnerabilities § Sufficient reporting of penetration testing to prove that the tests were completed, as appropriate, in order to reach the conclusions on the assurance level § A description of any restrictions that were placed upon the laboratory by the vendor and prevented the evaluation from being fully white-box¾for example, restricted access to source code or documentation.
• Sufficient reporting of penetration testing to prove that the tests were completed, as appropriate, in order to reach the conclusions on the assurance level
Modified
p. 99 → 98
• Conclusions of the evaluation should be modelled on the PCI PTS assurance rating methodology where vulnerabilities are rated in terms of their attack potential.
Modified
p. 99 → 98
• The report should contain a summary identifying:
Modified
p. 99 → 98
• A list of identified highest-risk, complete, attack paths,
• A list of identified highest-risk, complete, attack paths,
Modified
p. 100 → 99
The tester shall use NIST's STS tool, version 2.1.2 or later, or its mathematical equivalent. The tester shall verify that the compiled instance of the STS tool is operating correctly on the testing device by testing the NIST-provided sample data and comparing the results with those found in NIST SP 800-22 Revision 1a (SP800-22r1a), Appendix B. This configuration guidance is for use with STS version 2.1.2, though it will likely continue to be applicable to future versions.
The tester shall use NIST's STS tool, version 2.1.2 or later, or its mathematical equivalent. The tester shall verify that the compiled instance of the STS tool is operating correctly on the testing device by testing the NIST-provided sample data and comparing the results with those found in NIST SP 800-22 Revision 1a (SP800-22r1a), Appendix B. This configuration guidance is for use with STS version 2.1.2, though it will likely continue to be applicable to future versions.
Modified
p. 100 → 99
A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014] and the “Proportion of Sequences Passing a Test” …
A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014] and the “Proportion of Sequences Passing a Test” …
Modified
p. 100 → 99
The tester should request and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor-supplied data is interpreted correctly by the STS tool (the STS tool assumes that binary data is in big-endian formatting on all devices).
The tester should request and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor-supplied data is interpreted correctly by the STS tool (the STS tool assumes that binary data is in big-endian formatting on all devices).
Modified
p. 100 → 99
The STS testing on the data shall be judged as a "pass" if it passes all the tests, for both the "Proportion of Sequences Passing a Test" interpretation approach and "Uniform Distribution of P-Values" interpretation approach. If the data does not pass all tests, and the failure is marginal, the tester should acquire additional data from the vendor and repeat the testing, including both the initial data and the additional vendor-supplied data.
The STS testing on the data shall be judged as a "pass" if it passes all the tests, for both the "Proportion of Sequences Passing a Test" interpretation approach and "Uniform Distribution of P-Values" interpretation approach. If the data does not pass all tests, and the failure is marginal, the tester should acquire additional data from the vendor and repeat the testing, including both the initial data and the additional vendor-supplied data.
Modified
p. 100 → 99
The STS tool should be configured as per guidance provided in SP 800-22 Revision 1a, which is summarized below.
The STS tool should be configured as per guidance provided in SP 800-22 Revision 1a, which is summarized below.
Modified
p. 100 → 99
The following settings are consistent with the SP 800-22 Revision 1a document:
The following settings are consistent with the SP 800-22 Revision 1a document:
Removed
p. 101
§ [Kim 2004] Kim, Song-Ju, et al., "Corrections of the NIST Statistical Test Suite for Randomness." § [Hill 2004] Hill, Joshua (InfoGard Labs), "ApEn Test Parameter Selection." § [Hamano 2007] Hamano, K. and Kaneko, T., “Correction of Overlapping Template Matching Test Included in NIST Randomness Test Suite,” IEICE Trans. Fundamentals, vol. E90-A, no. 9, pp. 1788-1792, Sept. 2007.
Modified
p. 101 → 100
[3] For the Block Frequency test, if n=106, the test block size should be set between 104 and 106. (See SP 800-22r1a Section 2.2.7.) [4] The Non-Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. (See SP 800-22r1a Sections 2.7.7 and 2.8.7.) For a template length of 10, the MAXNUMOFTEMPLATES constant (in defs.h) should be set to at least 284 prior to compiling STS, otherwise most 10-bit aperiodic templates with a …
[3] For the Block Frequency test, if n=106, the test block size should be set between 104 and 106. (See SP 800-22r1a Section 2.2.7.) [4] The Non-Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. (See SP 800-22r1a Sections 2.7.7 and 2.8.7.) For a template length of 10, the MAXNUMOFTEMPLATES constant (in defs.h) should be set to at least 284 prior to compiling STS, otherwise most 10-bit aperiodic templates with a …
Modified
p. 101 → 100
[5] The Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. When n=106, the template size of 9 comes closest to fulfilling the parameter selection criteria. (See SP 800-22r1a Section 2.8.7.) [6] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP 800-22r1a Section 2.9.7. For n=106, the only acceptable values are (L=6, Q=640) and (L=7, Q=1280). Note: any parameters passed into this …
[5] The Overlapping test requires selection of a template length of 9 or 10 in order to produce meaningful results. When n=106, the template size of 9 comes closest to fulfilling the parameter selection criteria. (See SP 800-22r1a Section 2.8.7.) [6] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP 800-22r1a Section 2.9.7. For n=106, the only acceptable values are (L=6, Q=640) and (L=7, Q=1280).
Modified
p. 101 → 100
[7] For the Approximate Entropy (ApEn) test, SP 800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for large scale testing.
[7] For the Approximate Entropy (ApEn) test, SP 800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for large scale testing.
Modified
p. 101
• [Rukhin 2010] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP 800-22, Revision 1a.
Modified
p. 101
• [Hamano 2009] Hamano, Kenji, “Analysis and Application of the T-complexity.” Ph.D. thesis, The University of Tokyo.