Document Comparison
PCI_HSM_DTR__V2.pdf
→
PCI_HSM_DTRs_v3_2016_TOC.pdf
43% similar
65 → 140
Pages
23651 → 53462
Words
382
Content Changes
Content Changes
382 content changes. 169 administrative changes (dates, page numbers) hidden.
Added
p. 3
February 2016 3.x PCI RFC version
Added
p. 6
• Core Derived Test Requirements
• Key Loading Devices Derived Test Requirements
• Remote Administration Derived Test Requirements
• The HSM components that were evaluated;
• The security level of the evaluation;
• Key Loading Devices Derived Test Requirements
• Remote Administration Derived Test Requirements
• The HSM components that were evaluated;
• The security level of the evaluation;
Added
p. 7
• Accurately provides the information specified in this document, without any ambiguous or inconsistent information;
• Includes information relevant to any applicable FAQs; and
• Conforms to Laboratory General Requirements and any other related documentation in the PTS Program, such as (but not restricted to) Reporting Guidance and Report Template.
Minimal Contents of Reports and Minimal Test Activities All reports shall include a device summary section at the beginning of the document. This summary shall include the following:
• A device overview that summarizes the device’s design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or functions including (but not restricted to):
• Security processor(s) and other processors and memory, operating system(s), boot-up sequences, firmware modules, software applications, crypto functions, data-loading mechanisms, etc.
• This overview must present all security-relevant features necessary to derive the principal assets, threats, and attacks relevant to Security Requirements, as follows:
- Photographs of the device from different perspectives, …
• Includes information relevant to any applicable FAQs; and
• Conforms to Laboratory General Requirements and any other related documentation in the PTS Program, such as (but not restricted to) Reporting Guidance and Report Template.
Minimal Contents of Reports and Minimal Test Activities All reports shall include a device summary section at the beginning of the document. This summary shall include the following:
• A device overview that summarizes the device’s design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or functions including (but not restricted to):
• Security processor(s) and other processors and memory, operating system(s), boot-up sequences, firmware modules, software applications, crypto functions, data-loading mechanisms, etc.
• This overview must present all security-relevant features necessary to derive the principal assets, threats, and attacks relevant to Security Requirements, as follows:
- Photographs of the device from different perspectives, …
Added
p. 8
The vendor shall make source code available to the lab and provide assistance to make a systematic review of relevant security functions.
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents, such as the Security Policy.
Evidence-based reporting, demonstrating device compliance through robust testing, is the fundamental basis for achieving device approval. For all DTRs, the tester shall provide the following in writing:
• The text of the security requirements and guidance
• Validation of the completed Vendor Questionnaire and other vendor responses by stating:
a) Whether the evidence supports vendor assertions that the device is compliant with this requirement.
i. Where the evidence does support vendor assertions, assign a verdict of “Verified”;
ii. Where it does not, assign a verdict of “Not Verified.”
b) Whether the vendor’s responses appear to be consistent and comply with the relevant PCI Requirement(s).
i. If consistent …
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents, such as the Security Policy.
Evidence-based reporting, demonstrating device compliance through robust testing, is the fundamental basis for achieving device approval. For all DTRs, the tester shall provide the following in writing:
• The text of the security requirements and guidance
• Validation of the completed Vendor Questionnaire and other vendor responses by stating:
a) Whether the evidence supports vendor assertions that the device is compliant with this requirement.
i. Where the evidence does support vendor assertions, assign a verdict of “Verified”;
ii. Where it does not, assign a verdict of “Not Verified.”
b) Whether the vendor’s responses appear to be consistent and comply with the relevant PCI Requirement(s).
i. If consistent …
Added
p. 9
The tester shall justify any deviation from the prescribed routines. The tester is not limited to only presenting information specified by DTR text and should in many cases expand upon that information as necessary to support a conclusion.
In most cases the DTR 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, relevant information clearly discernible in a graph, images capturing displays and other outputs, source-code fragments, etc.
All DTRs must include references to documents and any other relevant sources of information upon which the evaluation relies. References must indicate information sources sufficiently to enable PCI to identify and retrieve test evidence following device approval.
The device is protected against penetration by including features that detect: (i) any feasible attempts to tamper with the device; and (ii) cause immediate …
In most cases the DTR 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, relevant information clearly discernible in a graph, images capturing displays and other outputs, source-code fragments, etc.
All DTRs must include references to documents and any other relevant sources of information upon which the evaluation relies. References must indicate information sources sufficiently to enable PCI to identify and retrieve test evidence following device approval.
The device is protected against penetration by including features that detect: (i) any feasible attempts to tamper with the device; and (ii) cause immediate …
Added
p. 11
If tamper grids are used as a primary mechanism, they meet the following:
• Use a minimum of two layers of internal grids for protection.
• Vias of ”upper grid” must be protected separately to vias of “lower grid”
•for example, the two tamper grids must not be connected by vias that are accessible on both grid layers, or vias must be protected by other tamper mechanisms, such as switches.
• Maximum width/separation (of active traces) must be 6 mil.
• Use “opposing” tamper-responsive traces routed side-by-side on each layer.
TA1.3 The tester shall provide an overview of the device and how it is constructed. The tester shall include an exploded diagram of the device showing how all sub-components are assembled and connected internally•for example, an explanation of processor (secure and unsecure) architectures and where these are located with regard to the internal areas of the device.
TA1.6 If a cover is part of the tamper-detection mechanism, …
• Use a minimum of two layers of internal grids for protection.
• Vias of ”upper grid” must be protected separately to vias of “lower grid”
•for example, the two tamper grids must not be connected by vias that are accessible on both grid layers, or vias must be protected by other tamper mechanisms, such as switches.
• Maximum width/separation (of active traces) must be 6 mil.
• Use “opposing” tamper-responsive traces routed side-by-side on each layer.
TA1.3 The tester shall provide an overview of the device and how it is constructed. The tester shall include an exploded diagram of the device showing how all sub-components are assembled and connected internally•for example, an explanation of processor (secure and unsecure) architectures and where these are located with regard to the internal areas of the device.
TA1.6 If a cover is part of the tamper-detection mechanism, …
Added
p. 13
TA1.13 If the HSM has a keypad, the tester shall describe whether any of the items on the path of the keypad signals are not protected by all tamper-detection mechanism. For example, the tester shall note if a signal via terminates on the same layer as a tamper grid and if any passive components are located outside of the protected area or are connected to vias (including power vias) that terminate outside of the protected area(s).
TA1.14 Using vendor documentation for each tamper grid that is implemented, the tester shall complete the details indicated in the table below, describing, at a minimum:
a) The location of the tamper grid (PCB designation and layer);
b) Its physical implementation
•that is, its composition
•for example, copper on a rigid PCB, conductive ink on plastic, etc.;
c) The size of the conductive traces and the distance between each tamper-detecting trace (not necessarily between each trace) as well as the …
TA1.14 Using vendor documentation for each tamper grid that is implemented, the tester shall complete the details indicated in the table below, describing, at a minimum:
a) The location of the tamper grid (PCB designation and layer);
b) Its physical implementation
•that is, its composition
•for example, copper on a rigid PCB, conductive ink on plastic, etc.;
c) The size of the conductive traces and the distance between each tamper-detecting trace (not necessarily between each trace) as well as the …
Added
p. 14
TA1.18 The tester shall note which tamper-detection mechanisms use active high, active low, dynamic, resistive, or other types of sensors. The tester shall confirm that any guard rings or interspersed traces in tamper grids are at opposing voltages that will activate tamper detection if electronically shorted. The tester shall note what testing has been performed to confirm this.
TA1.19 The tester shall describe any volume-encapsulation methods used in the device•for example, epoxy filling•that are designed to make penetration or reverse engineering more difficult.
TA1.20 The tester shall describe what testing was performed to validate any volume encapsulation.
Testing must include chemical and/or abrasive, and heating methods to bypass this protection.
TA1.21 The tester shall describe any attachment or “forming” methods (such as soldering, elastomeric strips, or adhesive for attachment, and plastic/metal walls for forming the shape of flexible circuits) used as part of the security features of the device. For example, the tester shall …
TA1.19 The tester shall describe any volume-encapsulation methods used in the device•for example, epoxy filling•that are designed to make penetration or reverse engineering more difficult.
TA1.20 The tester shall describe what testing was performed to validate any volume encapsulation.
Testing must include chemical and/or abrasive, and heating methods to bypass this protection.
TA1.21 The tester shall describe any attachment or “forming” methods (such as soldering, elastomeric strips, or adhesive for attachment, and plastic/metal walls for forming the shape of flexible circuits) used as part of the security features of the device. For example, the tester shall …
Added
p. 15
TA1.31 Describe the different attack paths considered. Using the format below, the tester shall generate attack costings, using different attack techniques on the device, and present the two most feasible. The attacks should be dissimilar in approach unless the lab can fully justify the infeasibility of any second divergent approach. The tester shall state explicitly where testing has verified any specific stage of the attack (including the time, equipment, and skill required, and number of mechanisms to bypass), and where assumptions are used in place of testing. The tester shall justify why any assumptions have been used instead of than actual testing. Calculations shall include evidence justifying particular rating levels as being appropriate.
• Attack P1 Identification Stage
• Attack P1 Identification Stage
Added
p. 15
3. Description of Step 3 4. Etc.
3. Description of Step 3 4. Etc.
Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 80 hours 2 Proficient Public Standard None 40 hours 3 Proficient Public Standard None 1 Functional without keys 80 hours
• Attack P1 Exploitation Stage
3. Description of Step 3 4. Etc.
Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 80 hours 2 Proficient Public Standard None 40 hours 3 Proficient Public Standard None 1 Functional without keys 80 hours
• Attack P1 Exploitation Stage
Added
p. 16
• Attack P1 Cost Breakdown Phase Value Description Identification Phase Attack Time 7.5 Beyond 160 hours Expertise 3 Proficient Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 1 Standard (reused in exploitation) Specific Parts 0 None Identification Total 14.5 Exploitation Phase Attack time 3 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 1 Standard (reused equipment from identification) Specific Parts 1 Standard Exploitation Total 9 (FAIL) Grand Total 23.0 (FAIL) Attack “P2”
• Attack P2 Identification Stage
• Attack P2 Identification Stage
Added
p. 17
• Attack P2 Exploitation Stage
3. Description of Step 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 25 hours 2 Proficient Public Standard Standard 1 hour 3 Proficient Public Standard None Functional sample with working keys and software 0.5 hours
• Attack P2 Cost Breakdown Phase Value Description Identification Phase Attack Time 7 ≤ 160 hours Expertise 4 Expert Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 3 Specialized (reused in exploitation) Specific Parts 0 None Identification Total 17.0 Exploitation Phase Attack time 5.5 ≤ 40 hours Expertise 3 Proficient Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 1 Standard (subset of identification equipment, reused) Specific Parts 1 Standard Exploitation Total 14.5 Grand Total 31.5 TA1.34 The tester shall verify that no attack was able to be determined, including those …
3. Description of Step 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 25 hours 2 Proficient Public Standard Standard 1 hour 3 Proficient Public Standard None Functional sample with working keys and software 0.5 hours
• Attack P2 Cost Breakdown Phase Value Description Identification Phase Attack Time 7 ≤ 160 hours Expertise 4 Expert Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 3 Specialized (reused in exploitation) Specific Parts 0 None Identification Total 17.0 Exploitation Phase Attack time 5.5 ≤ 40 hours Expertise 3 Proficient Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 1 Standard (subset of identification equipment, reused) Specific Parts 1 Standard Exploitation Total 14.5 Grand Total 31.5 TA1.34 The tester shall verify that no attack was able to be determined, including those …
Added
p. 19
Maximum Value Minimum Value Detecting Circuitry Response Voltage (Specify type) Configured Value Configured Value Tested Value Tested Value Temperature Configured Value Configured Value Tested Value Tested Value TA2.6 In the maximum/minimum values for each item, the tester shall note what the vendor attests the value is set to in the “Configured Value” cells of the above table.
TA2.7 Using a device that has been configured
•using special test code from the vendor, which shall be removed from production units
•to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.
TA2.8 The tester shall detail whether the self-test program used above is executed correctly at all times during each of the tests above
•within the vendor’s stated minimum and maximum voltage and …
TA2.7 Using a device that has been configured
•using special test code from the vendor, which shall be removed from production units
•to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.
TA2.8 The tester shall detail whether the self-test program used above is executed correctly at all times during each of the tests above
•within the vendor’s stated minimum and maximum voltage and …
Added
p. 21
Sensitive Information Storage Area Method of Protection Plaintext PINs Device Firmware Public keys TA3.5 Using the information from the table above, the tester shall provide details on the different integrated circuits
•memory, processors, programmable logic etc.
•that are used to store, process, or secure sensitive information.
TA3.6 For each of the integrated circuit elements (described above) that may be programmed or configured in some way, the tester shall enumerate the following:
• The different ways in which that element may be programmed or configured (for example, JTAG).
• Any in-circuit testing or debugging features provided by these elements.
TA3.7 The tester shall detail what methods have been implemented to disable all of the programming/testing features outlined above. The tester shall detail the testing performed to validate that these features are indeed disabled. The tester shall justify why these measures are sufficient, and confirm that these features cannot be re-enabled.
TA3.8 If additional memory is implemented and is …
•memory, processors, programmable logic etc.
•that are used to store, process, or secure sensitive information.
TA3.6 For each of the integrated circuit elements (described above) that may be programmed or configured in some way, the tester shall enumerate the following:
• The different ways in which that element may be programmed or configured (for example, JTAG).
• Any in-circuit testing or debugging features provided by these elements.
TA3.7 The tester shall detail what methods have been implemented to disable all of the programming/testing features outlined above. The tester shall detail the testing performed to validate that these features are indeed disabled. The tester shall justify why these measures are sufficient, and confirm that these features cannot be re-enabled.
TA3.8 If additional memory is implemented and is …
Added
p. 22
a) Confirm that the physical protections cover all memory traces, vias, passive elements, or other areas of access. For example, detail whether the vias of the memory bus appear on the same layer as one of the tamper grids.
b) Detail how the memory packages are protected, including access to BGA balls and traces on internal chip carriers of packages.
TA3.12 Where encryption is used as a method of protection of sensitive information, the tester shall:
a) Confirm that the encryption uses approved algorithms and key lengths.
b) Note what mode of operation is used for the encryption.
c) Justify how this prevents the re-location of memory from one area to another.
d) Justify how the method of encryption prevents the exposure of sensitive information through building of a “dictionary” of possible encrypted values.
e) If a key stream mode of encryption is used (for example, OFB), justify how the encryption of different data with the same …
b) Detail how the memory packages are protected, including access to BGA balls and traces on internal chip carriers of packages.
TA3.12 Where encryption is used as a method of protection of sensitive information, the tester shall:
a) Confirm that the encryption uses approved algorithms and key lengths.
b) Note what mode of operation is used for the encryption.
c) Justify how this prevents the re-location of memory from one area to another.
d) Justify how the method of encryption prevents the exposure of sensitive information through building of a “dictionary” of possible encrypted values.
e) If a key stream mode of encryption is used (for example, OFB), justify how the encryption of different data with the same …
Added
p. 24
The tester shall present evidence allowing test methodologies and results to be validated.
The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units).
SCA tests shall be performed in accordance with Appendix E.
TA5.3 The tester shall provide details on the type, location, and accessibility, of the security processor(s) used by the device, and any other elements of the device that have relevance to possible attacks. The tester shall reference information previously supplied in DTRs A1 and A3 where applicable.
TA5.4 The tester shall provide details on how cryptographic keys are stored and managed within the device. The tester shall reference this information to the table provided in DTR A3. The tester shall detail the testing performed to confirm the storage locations …
The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units).
SCA tests shall be performed in accordance with Appendix E.
TA5.3 The tester shall provide details on the type, location, and accessibility, of the security processor(s) used by the device, and any other elements of the device that have relevance to possible attacks. The tester shall reference information previously supplied in DTRs A1 and A3 where applicable.
TA5.4 The tester shall provide details on how cryptographic keys are stored and managed within the device. The tester shall reference this information to the table provided in DTR A3. The tester shall detail the testing performed to confirm the storage locations …
Added
p. 26
TA5.8 The tester shall perform preliminary side-channel analysis on the device to characterize the cryptographic algorithms used to process sensitive data and/or operate with secret keys. Utilizing characterization results and knowledge of the device physical design and software, the tester shall decide which side-channel attack paths provide the best opportunities for an attacker to compromise high-value assets. The tester shall develop side-channel analysis to explore methodologies most likely to achieve retrieval of sensitive data The tester shall develop these investigations to derive a demonstrable level of assurance consistent with any reported attack cost rating(s).
The tester shall describe any assistance provided by the vendor to ensure efficient side-channel testing•for example, command scripts or event triggers.
TA5.9 The tester shall justify the methodologies used and findings, in accordance with Appendix E. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible …
The tester shall describe any assistance provided by the vendor to ensure efficient side-channel testing•for example, command scripts or event triggers.
TA5.9 The tester shall justify the methodologies used and findings, in accordance with Appendix E. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible …
Added
p. 27
TA5.12 Referring to the information provided in DTR A3, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the device cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.
TA5.13 If the device stores plaintext cryptographic keys within external memory, the tester shall detail the physical security methods implemented to protect this memory. Note that PCB-based tamper grids are not considered sufficient to protect plaintext cryptographic keys.
TA5.14 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the device, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.
The tester is not required to perform the attack entirely but may perform …
TA5.13 If the device stores plaintext cryptographic keys within external memory, the tester shall detail the physical security methods implemented to protect this memory. Note that PCB-based tamper grids are not considered sufficient to protect plaintext cryptographic keys.
TA5.14 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the device, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing.
The tester is not required to perform the attack entirely but may perform …
Added
p. 29
• The authenticity checking of firmware
•either internally and according to B4 or externally using appropriate procedures within a secured environment under the vendor’s control•is performed whenever the firmware is established in that secure area; and
• The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, A3, and A5 and meet the respective attack potentials; and
TB1.3 The tester shall describe the boot chain of the device. The tester shall Include how initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are sequenced, loaded, and executed, up to and including software modules used for processing sensitive data.
•either internally and according to B4 or externally using appropriate procedures within a secured environment under the vendor’s control•is performed whenever the firmware is established in that secure area; and
• The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, A3, and A5 and meet the respective attack potentials; and
TB1.3 The tester shall describe the boot chain of the device. The tester shall Include how initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are sequenced, loaded, and executed, up to and including software modules used for processing sensitive data.
Added
p. 30
TB1.7 The tester shall review the source code of the device to confirm what algorithms and keys are used to perform the self-test functions that are implemented by the firmware of the device. The tester shall confirm that any register settings required to activate hardware-based self-test functions are correctly assigned.
TB1.8 The tester shall review the source code of the device to confirm how it is ensured that the self- test process(es) are repeated every 24 hours, or through an automatic continuous error- checking built into the hardware.
TB1.9 The tester shall note what methods are implemented to authenticate the cryptographic keys of the device, to ensure that they have not been modified after loading.
TB1.10 The tester shall detail the processes performed by the device if one or more of the self-test(s) fails. The tester shall confirm this through source-code review.
TB1.11 From the previous descriptions, the tester shall complete the following table …
TB1.8 The tester shall review the source code of the device to confirm how it is ensured that the self- test process(es) are repeated every 24 hours, or through an automatic continuous error- checking built into the hardware.
TB1.9 The tester shall note what methods are implemented to authenticate the cryptographic keys of the device, to ensure that they have not been modified after loading.
TB1.10 The tester shall detail the processes performed by the device if one or more of the self-test(s) fails. The tester shall confirm this through source-code review.
TB1.11 From the previous descriptions, the tester shall complete the following table …
Added
p. 33
TB1.19 The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.
All interfaces and associated communication methods of the device must be assessed. The interfaces must be documented and assessed regardless of whether they are used for or have access to card data. Sufficient evidence must be provided to demonstrate the validity of laboratory assessments.
TB2.2 The tester shall examine and cite any relevant documentation
•such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor
•to verify that it supports the vendor responses.
TB2.4 The tester shall note the programming languages in which the device's firmware source code is written for each of the security processing elements (as detailed in DTR A3).
TB2.5 The tester shall detail the type, version, capabilities, and configuration of the operating system(s) used …
All interfaces and associated communication methods of the device must be assessed. The interfaces must be documented and assessed regardless of whether they are used for or have access to card data. Sufficient evidence must be provided to demonstrate the validity of laboratory assessments.
TB2.2 The tester shall examine and cite any relevant documentation
•such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor
•to verify that it supports the vendor responses.
TB2.4 The tester shall note the programming languages in which the device's firmware source code is written for each of the security processing elements (as detailed in DTR A3).
TB2.5 The tester shall detail the type, version, capabilities, and configuration of the operating system(s) used …
Added
p. 35
The source-code review should be targeted on relevant security-critical functionalities such as (but not restricted to): buffer overflows; unhandled exceptions, read-access violations, and denial-of-service conditions, including factors that are specific to the device’s OS, communications protocols, and source code software language(s).
TB2.10 For systems that are designed to execute non-firmware applications, the vendor shall provide a test application containing a buffer-overflow vulnerability to be run into the device, together with the application’s source code. The tester shall run the application and determine whether the device fails securely.
TB2.11 The tester shall execute a vulnerability assessment, public vulnerability check, and/or testing, to identify vulnerabilities associated with the interfaces and associated communication methods of the device.
TB2.12 The tester shall perform fuzzing of the device’s security-relevant interfaces in order to uncover logical anomalies.
The tester shall describe fuzzing methodologies and tools used, as well as any assistance provided by the vendor in the case of white-box …
TB2.10 For systems that are designed to execute non-firmware applications, the vendor shall provide a test application containing a buffer-overflow vulnerability to be run into the device, together with the application’s source code. The tester shall run the application and determine whether the device fails securely.
TB2.11 The tester shall execute a vulnerability assessment, public vulnerability check, and/or testing, to identify vulnerabilities associated with the interfaces and associated communication methods of the device.
TB2.12 The tester shall perform fuzzing of the device’s security-relevant interfaces in order to uncover logical anomalies.
The tester shall describe fuzzing methodologies and tools used, as well as any assistance provided by the vendor in the case of white-box …
Added
p. 37
TB3.9 The tester shall confirm that
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
TB3.10 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the device firmware.
TB3.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the device code.
TB3.12 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed after every security-relevant change, and before the firmware is released to production.
TB3.13 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable …
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
TB3.10 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the device firmware.
TB3.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the device code.
TB3.12 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed after every security-relevant change, and before the firmware is released to production.
TB3.13 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable …
Added
p. 39
The authentication must not be performed by a component of lesser protection strength than the one for which the firmware/software is intended, OR the authentication must be performed by the target component of the firmware/software.
The firmware and application version numbers must be available via display and/or printing during startup or on request. This shall be illustrated by photographic evidence provided in the evaluation report.
TB4.6 For each of the processing elements listed in DTR A3, the tester shall complete the following table (see Annex A of the Vendor Questionnaire). Where different parts of the code can be updated independently (for example, boot code, main firmware, etc.), or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well.
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information.
The firmware and application version numbers must be available via display and/or printing during startup or on request. This shall be illustrated by photographic evidence provided in the evaluation report.
TB4.6 For each of the processing elements listed in DTR A3, the tester shall complete the following table (see Annex A of the Vendor Questionnaire). Where different parts of the code can be updated independently (for example, boot code, main firmware, etc.), or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well.
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information.
Added
p. 40
In the “Format of Authentication Block Column,” include details on the format and padding of the authentication block (for example X.509 certificate using OAEP padding).
TB4.7 The tester shall review the source code of the device to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the device. This evaluation activity should be focused at relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation goals overall.
TB4.8 If the device allows for loading of multiple types of code (for example, firmware for security processor and application code), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained …
TB4.7 The tester shall review the source code of the device to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the device. This evaluation activity should be focused at relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation goals overall.
TB4.8 If the device allows for loading of multiple types of code (for example, firmware for security processor and application code), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained …
Added
p. 41
Applications are considered to be any code that can be loaded onto the device that is not firmware. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
The authentication must not be performed by a component of lesser protection strength than the one for which the access is intended, OR the authentication must be performed by the target component.
TB4.1.1 The tester shall examine the vendor’s response to Section B4.1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B4.1 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device enforces that only authenticated applications and application/configuration updates can be loaded onto the device. The vendor responses should clearly indicate how software authenticity is assured. The tester shall summarize the responses TB4.1.2 The tester shall examine and cite any additional documentation (i.e., …
The authentication must not be performed by a component of lesser protection strength than the one for which the access is intended, OR the authentication must be performed by the target component.
TB4.1.1 The tester shall examine the vendor’s response to Section B4.1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B4.1 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device enforces that only authenticated applications and application/configuration updates can be loaded onto the device. The vendor responses should clearly indicate how software authenticity is assured. The tester shall summarize the responses TB4.1.2 The tester shall examine and cite any additional documentation (i.e., …
Added
p. 42
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information.
b) Change a single bit in the authentication block of the image, and confirm that this modified image is rejected when loaded into the device.
Processing/ Application Elements Used to Perform Authentication Algorithms and Key Sizes Used for Application Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the application differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of how initial code is loaded into the device.
In the “Format of Authentication Block” column, include details on the format and padding of the authentication block (for example, X.509 certificate using OAEP padding).
TB4.1.7 The tester shall review the source code of the device to confirm that the application authentication methods are implemented correctly as …
b) Change a single bit in the authentication block of the image, and confirm that this modified image is rejected when loaded into the device.
Processing/ Application Elements Used to Perform Authentication Algorithms and Key Sizes Used for Application Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the application differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of how initial code is loaded into the device.
In the “Format of Authentication Block” column, include details on the format and padding of the authentication block (for example, X.509 certificate using OAEP padding).
TB4.1.7 The tester shall review the source code of the device to confirm that the application authentication methods are implemented correctly as …
Added
p. 45
TB6.8 The tester shall perform any additional tests necessary to verify that all data is automatically cleared including when the transaction is completed, the device has timed out, or the device recovers from an error state for instance, by performing a partial simulated transaction to verify the behavior at time-out, or in general by entering the states that have been defined by the vendor under TB6.1.
“CSPs” are critical security parameters, such as cryptographic keys and passwords.
The device’s key-management functions are designed so that no key can be disclosed without collusion amongst individuals. Specifically:
• The device's highest-level keys are manually loaded as at least two components under dual control;
• Any function used to input or output key components does not operate until at least two different passwords have been entered.
It must not be feasible to determine a key or other secret information by the use of diagnostic or special test modes.
The …
“CSPs” are critical security parameters, such as cryptographic keys and passwords.
The device’s key-management functions are designed so that no key can be disclosed without collusion amongst individuals. Specifically:
• The device's highest-level keys are manually loaded as at least two components under dual control;
• Any function used to input or output key components does not operate until at least two different passwords have been entered.
It must not be feasible to determine a key or other secret information by the use of diagnostic or special test modes.
The …
Added
p. 47
• Disablement/enablement of device functionality;
• Configuring or modifying the Security Policy examined in C1 and B11.
TB7.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services TB7.3 The tester shall verify from vendor documentation and summarize that the vendor has identified all sensitive services, data, and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions
•for example, from operational to maintenance
• do not reveal or otherwise affect sensitive information.
TB7.9 The tester shall verify that placing the device into a diagnostic or special test mode does not allow the determination of a secret key or other …
• Configuring or modifying the Security Policy examined in C1 and B11.
TB7.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services TB7.3 The tester shall verify from vendor documentation and summarize that the vendor has identified all sensitive services, data, and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode transitions
•for example, from operational to maintenance
• do not reveal or otherwise affect sensitive information.
TB7.9 The tester shall verify that placing the device into a diagnostic or special test mode does not allow the determination of a secret key or other …
Added
p. 49
TB7.21 The tester shall attempt to load cryptographic keys or components into the device without changing the default values of the passwords. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TB7.22 The tester shall attempt to set the passwords of the device to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
TB7.22 The tester shall attempt to set the passwords of the device to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Added
p. 53
The device output of those numbers cannot be influenced•e.g., by varying environmental conditions of the device such as manipulating the power supply/electro-magnetic injection.
PRNG designs (Deterministic Random Bit Generator, or DRBG) from NIST SP800-90A or ANSI X9.82 shall be used. Specifically, HASH_DRBG, HMAC_DRBG or CTR_DRBG. DEA and 2-key TDEA, as well as DUAL_EC_DRBG are not acceptable for use in a DRBG.
The evaluating lab may require assistance from the vendor to make a systematic review of relevant security functions.
TB9.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor responses.
TB9.3 The tester shall detail the method used by the device to generate random numbers, including any seed values used, hardware systems, and software-based deterministic pseudo random number generators (DPRNG).
The tester shall outline the process used by the vendor to ensure that any secret …
PRNG designs (Deterministic Random Bit Generator, or DRBG) from NIST SP800-90A or ANSI X9.82 shall be used. Specifically, HASH_DRBG, HMAC_DRBG or CTR_DRBG. DEA and 2-key TDEA, as well as DUAL_EC_DRBG are not acceptable for use in a DRBG.
The evaluating lab may require assistance from the vendor to make a systematic review of relevant security functions.
TB9.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor responses.
TB9.3 The tester shall detail the method used by the device to generate random numbers, including any seed values used, hardware systems, and software-based deterministic pseudo random number generators (DPRNG).
The tester shall outline the process used by the vendor to ensure that any secret …
Added
p. 54
TB9.5 The tester shall list all security services implemented within the device that require or rely upon the use of random data. This may include generation of padding data•for example, for use in certificates or key bundles, generation of cryptographic keys, etc.
TB9.6 The tester shall review the source code of each of these services, and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
TB9.7 The tester shall obtain at least 128MB of random data from the device under test. This data may be supplied directly by the vendor. The tester shall detail the method used to generate this data, and justify why this sufficiently replicates the way in which the RNG will be used by the device. The …
TB9.6 The tester shall review the source code of each of these services, and confirm that they correctly utilize the random number generator reviewed in this requirement. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
TB9.7 The tester shall obtain at least 128MB of random data from the device under test. This data may be supplied directly by the vendor. The tester shall detail the method used to generate this data, and justify why this sufficiently replicates the way in which the RNG will be used by the device. The …
Added
p. 55
• Log data protection
• Data authentication
• User authentication
• Software/firmware updates
• Review of algorithm verification certifications (e.g., NIST CMVP)
• Review of algorithm test results submitted by the vendor from an independent accredited testing organization
• Evaluation of sample data or internal testing performed by the vendor
• Data authentication
• User authentication
• Software/firmware updates
• Review of algorithm verification certifications (e.g., NIST CMVP)
• Review of algorithm test results submitted by the vendor from an independent accredited testing organization
• Evaluation of sample data or internal testing performed by the vendor
Added
p. 57
A device may include other key-management schemes not specified below, such as country-specific techniques when operating in PCI mode, as long as their use cannot in any way compromise the security of the PCI-compliant methods. Performing simulated transactions is not required for these key-management techniques.
When a check value is generated for a key or key component, it shall be generated by a cryptographic process such that all portions of the key or key component are involved in generating the check value.
The device must support use of the TR-31 Key Derivation Binding Method or an equivalent key- bundling methodology. The device may optionally support, in addition, the TR-31 Key Variant Binding Method or an equivalent.
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods, including the use of algorithms and key sizes stipulated in Appendix D. Any binding or unbinding of key-usage …
When a check value is generated for a key or key component, it shall be generated by a cryptographic process such that all portions of the key or key component are involved in generating the check value.
The device must support use of the TR-31 Key Derivation Binding Method or an equivalent key- bundling methodology. The device may optionally support, in addition, the TR-31 Key Variant Binding Method or an equivalent.
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods, including the use of algorithms and key sizes stipulated in Appendix D. Any binding or unbinding of key-usage …
Added
p. 60
TB11.11 The tester shall review the API guide and operations manual of the device and confirm that this does not detail any other key-management schemes or methods that the device may use. If the device supports extensible key management for use with non-PIN transactions, the tester shall justify what prevents this from being used with PCI-based PINs, using extracts from the vendor documentation to support this claim. The tester shall provide references to all extracts used.
TB11.12 The tester shall detail any other types of key management or cryptographic keys used by the device. This should include any keys used for firmware or application authentication, self- testing, boot strapping, remote key injection, local key injection, dual control, etc.
TB11.13 Using the table provided in Annex A of the Vendor Questionnaire, the tester shall provide a key table for the device, accurately including all of the keys and key-management methods outlined above. This …
TB11.12 The tester shall detail any other types of key management or cryptographic keys used by the device. This should include any keys used for firmware or application authentication, self- testing, boot strapping, remote key injection, local key injection, dual control, etc.
TB11.13 Using the table provided in Annex A of the Vendor Questionnaire, the tester shall provide a key table for the device, accurately including all of the keys and key-management methods outlined above. This …
Added
p. 61
a) No key is encrypted under a key of lesser strength; and
b) Plaintext cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).
TB11.17 The tester shall detail any ways in which the device generates keys from other keys, specifically:
a) Variants are not used across different levels of the hierarchy•for example, variants of KEKs are not used to produce working keys. The only allowable exception to this requirement is the use of TR-31 2005 key bundling (for backwards compatibility).
b) The tester shall detail any key-generation methods used, and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.
TB11.18 The tester shall note whether the device generates any keys using an internal random number generator. The tester shall confirm through source-code review that these keys are generated using the same process validated under Requirement B9. This evaluation activity should be …
b) Plaintext cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).
TB11.17 The tester shall detail any ways in which the device generates keys from other keys, specifically:
a) Variants are not used across different levels of the hierarchy•for example, variants of KEKs are not used to produce working keys. The only allowable exception to this requirement is the use of TR-31 2005 key bundling (for backwards compatibility).
b) The tester shall detail any key-generation methods used, and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.
TB11.18 The tester shall note whether the device generates any keys using an internal random number generator. The tester shall confirm through source-code review that these keys are generated using the same process validated under Requirement B9. This evaluation activity should be …
Added
p. 62
• Key confidentiality
• Algorithm used for the key
• Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.
TB11.23 The tester shall confirm that any key-bundling key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-bundled key-management scheme.
TB11.24 For any methods that rely on the use of full-length key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. For …
• Algorithm used for the key
• Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.
TB11.23 The tester shall confirm that any key-bundling key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-bundled key-management scheme.
TB11.24 For any methods that rely on the use of full-length key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. For …
Added
p. 68
• Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN Not permitted Permitted for submissions to an IC card Permitted Format 1 Permitted Permitted Permitted for submissions to an IC card Permitted Format 2 Not permitted Not permitted Permitted for submissions to an IC card Not permitted Format 3, 4
• Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN Not permitted Permitted for submissions to an IC card Permitted TB15.4 The tester shall verify the following (as applicable):
TB16.6 The tester shall verify that the device never exports logs that contain clear-text sensitive data.
Applications, in this context, are functional entities that execute within the boundary of the device and may or may not provide services external to the device. Applications are typically processes or tasks that execute under the control of an operating …
• Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN Not permitted Permitted for submissions to an IC card Permitted TB15.4 The tester shall verify the following (as applicable):
TB16.6 The tester shall verify that the device never exports logs that contain clear-text sensitive data.
Applications, in this context, are functional entities that execute within the boundary of the device and may or may not provide services external to the device. Applications are typically processes or tasks that execute under the control of an operating …
Added
p. 72
TB17.9 If the device relies upon the use of different processors to provide for the separation between the firmware and any applications, the tester shall review and briefly describe the method of communications provided between these processors, including any physical interface and API(s).
TB17.10 If the device allows for different applications to be executed on the same processor, or for the execution of one or more applications on the same processor that is used to execute firmware, the tester shall detail the mechanisms provided to ensure that code and data objects of different applications/firmware are kept separate.
TB17.11 The tester shall review the configuration of the mechanisms described above and confirm that it maintains application separation.
TB17.12 The tester shall note whether the firmware processor(s) provide mechanisms to prevent the execution of memory used to hold data objects. Where such mechanisms exist, the tester shall detail whether they are utilized correctly by the …
TB17.10 If the device allows for different applications to be executed on the same processor, or for the execution of one or more applications on the same processor that is used to execute firmware, the tester shall detail the mechanisms provided to ensure that code and data objects of different applications/firmware are kept separate.
TB17.11 The tester shall review the configuration of the mechanisms described above and confirm that it maintains application separation.
TB17.12 The tester shall note whether the firmware processor(s) provide mechanisms to prevent the execution of memory used to hold data objects. Where such mechanisms exist, the tester shall detail whether they are utilized correctly by the …
Added
p. 74
The tester shall verify that the operating system is enforcing least privilege.
TB18.9 If the device uses a commercial operating system, the tester shall review publically available sources of vulnerability information and note whether any vulnerabilities exist for this system. The tester shall note the sources reviewed and any potential vulnerabilities found, and justify why any such vulnerabilities are mitigated by the vendor configuration(s).
TB18.10 The tester shall obtain the configuration information for the operating system used in the device.
The tester shall compare this configuration with the supplied documentation, and note whether they agree or have differences. If differences are detected, it is necessary to address why these occur with regard to compliance to this requirement.
TB18.11 The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the device’s execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce …
TB18.9 If the device uses a commercial operating system, the tester shall review publically available sources of vulnerability information and note whether any vulnerabilities exist for this system. The tester shall note the sources reviewed and any potential vulnerabilities found, and justify why any such vulnerabilities are mitigated by the vendor configuration(s).
TB18.10 The tester shall obtain the configuration information for the operating system used in the device.
The tester shall compare this configuration with the supplied documentation, and note whether they agree or have differences. If differences are detected, it is necessary to address why these occur with regard to compliance to this requirement.
TB18.11 The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the device’s execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce …
Added
p. 79
Product name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions.
Added
p. 80
TC1.23 The tester shall confirm the security policy of the device and confirm that it clearly outlines the exact details of the key-management systems supported by the device
•i.e., simply using the term “MK/SK” is not sufficient
•and specifies that use of the device with different key- management systems will invalidate any PCI approval of this device.
TC1.24 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B7 and assessed by the PTS laboratory.
TC1.25 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords and certificates.
TC1.26 The tester shall confirm that the security policy contains information on how the device will indicate a tamper-response event, and any requirements for the return of this device …
•i.e., simply using the term “MK/SK” is not sufficient
•and specifies that use of the device with different key- management systems will invalidate any PCI approval of this device.
TC1.24 The tester shall confirm that the security policy contains specific details on how key loading must be performed for operation of the device. This must include any requirements for dual control and split knowledge, as required by DTR B7 and assessed by the PTS laboratory.
TC1.25 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords and certificates.
TC1.26 The tester shall confirm that the security policy contains information on how the device will indicate a tamper-response event, and any requirements for the return of this device …
Added
p. 81
For devices that are capable of generating secret or private keys, the secret or private keys or their precursors cannot be visible in clear text at any time during the generation process. The lab must verify that they cannot view the keys at any time during the generation process.
TD1.1 The tester shall examine the vendor’s response to Section D1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D1 of the PCI PTS HSM Modular Security Requirements to verify that the secret or private key or its precursors are not visible in clear text at any time during the generation process.
TD1.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it supports the vendor response that the secret and private key or its …
TD1.1 The tester shall examine the vendor’s response to Section D1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D1 of the PCI PTS HSM Modular Security Requirements to verify that the secret or private key or its precursors are not visible in clear text at any time during the generation process.
TD1.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it supports the vendor response that the secret and private key or its …
Added
p. 82
The device cannot store unused keys, key pairs, or seed elements subsequent to completion of the transfer process. Once the transfer process is completed, the device deletes all related secret information, keys, key pairs and seed elements.
TD2.1 The tester shall examine the vendor’s response to Section D2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D2 of the PCI PTS HSM Modular Security Requirements to verify that the key or key pairs and all related secret and private seed elements are deleted immediately after the transfer process for those keys not used by the device.
TD2.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that the key or key pair and all related secret and private seed elements are deleted immediately after the …
TD2.1 The tester shall examine the vendor’s response to Section D2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D2 of the PCI PTS HSM Modular Security Requirements to verify that the key or key pairs and all related secret and private seed elements are deleted immediately after the transfer process for those keys not used by the device.
TD2.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that the key or key pair and all related secret and private seed elements are deleted immediately after the …
Added
p. 83
This is not intended to preclude the following:
• The use of the KLD for loading multiple HSMs with the same Master File Key (e.g., when the HSMs are used for load sharing with a single key database);
• The use of the KLD to generate unique keys per device, load them into a PED, and later transfer the file of keys to an HSM;
• The use of Base Derivation Keys or similar to generate initial DUKPT keys or similar UKPT schemes;
• The loading of the same public key to multiple devices;
• The use of Key-Encipherment Keys for importing/exporting of cryptograms.
TD3.1 The tester shall examine the vendor’s response to Section D3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D3 of the PCI PTS HSM Modular Security Requirements to verify that after key transfer, there is no information retained by the device that could be used …
• The use of the KLD for loading multiple HSMs with the same Master File Key (e.g., when the HSMs are used for load sharing with a single key database);
• The use of the KLD to generate unique keys per device, load them into a PED, and later transfer the file of keys to an HSM;
• The use of Base Derivation Keys or similar to generate initial DUKPT keys or similar UKPT schemes;
• The loading of the same public key to multiple devices;
• The use of Key-Encipherment Keys for importing/exporting of cryptograms.
TD3.1 The tester shall examine the vendor’s response to Section D3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D3 of the PCI PTS HSM Modular Security Requirements to verify that after key transfer, there is no information retained by the device that could be used …
Added
p. 84
TD4.1 The tester shall examine the vendor’s response to Section D4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS HSM Modular Security Requirements to verify that the vendor has detailed the transfer process of keys, for devices composed of several components.
TD4.2 The tester shall examine the vendor’s response to Section D4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS HSM Modular Security Requirements to verify that the vendor has detailed the protections of each of the components of the solution. The tester shall justify why any such transfer of keys ensures that they remain secure.
TD4.3 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it is …
TD4.2 The tester shall examine the vendor’s response to Section D4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS HSM Modular Security Requirements to verify that the vendor has detailed the protections of each of the components of the solution. The tester shall justify why any such transfer of keys ensures that they remain secure.
TD4.3 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it is …
Added
p. 85
This is not meant to preclude authenticated firmware changes.
TD5.1 The tester shall examine the vendor’s response to Section D5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D5 of the PCI PTS HSM Modular Security Requirements to verify that modification of the device’s functional capabilities either results in the erasure of cryptographic keys stored within the device or is otherwise detected before the device is next used to load a key.
TD5.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it is not possible to modify the device’s functional capabilities without either causing the erasure of cryptographic keys stored within the device or otherwise being detected before the device is next used to load a key.
TD5.3 The tester shall attempt to modify …
TD5.1 The tester shall examine the vendor’s response to Section D5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D5 of the PCI PTS HSM Modular Security Requirements to verify that modification of the device’s functional capabilities either results in the erasure of cryptographic keys stored within the device or is otherwise detected before the device is next used to load a key.
TD5.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it is not possible to modify the device’s functional capabilities without either causing the erasure of cryptographic keys stored within the device or otherwise being detected before the device is next used to load a key.
TD5.3 The tester shall attempt to modify …
Added
p. 86
The remote administration device cannot be put into an operational state until an initialization process has been completed and a secure relationship (i.e., cryptographic) has been established between the remote administration platform and the target device(s).
Remote admin connectivity must be terminated during the initialization sequence and can only be established after the initialization sequence is complete.
TE1.1 The tester shall examine the response to Section E1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement E1 of PCI PTS HSM Modular Security Requirements for consistency.
TE1.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, to verify that it supports the vendor responses.
TE1.3 The tester shall verify that all operational services cease during the initialization processes.
TE1.4 The tester shall verify that no operational services are started until the initialization is complete.
TE1.5 The tester shall verify that remote admin connectivity is terminated …
Remote admin connectivity must be terminated during the initialization sequence and can only be established after the initialization sequence is complete.
TE1.1 The tester shall examine the response to Section E1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement E1 of PCI PTS HSM Modular Security Requirements for consistency.
TE1.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, to verify that it supports the vendor responses.
TE1.3 The tester shall verify that all operational services cease during the initialization processes.
TE1.4 The tester shall verify that no operational services are started until the initialization is complete.
TE1.5 The tester shall verify that remote admin connectivity is terminated …
Added
p. 87
• Disabling or enabling of device functions;
• Change of passwords or other authentication data that enable the device to enter the sensitive state.
The secure operator interface is so designed that entry of more than one password (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
Operator functions need to be controlled and defined. Certain operator functions can only be done when the device is in a sensitive state. A sensitive state is defined as to when the device is under dual or multiple control and that more than one password is required to enter a sensitive state. To activate the secure operator interface, more than one password or equivalent mechanism for dual or multiple control is required.
PINs or passwords used for authentication are at least …
• Change of passwords or other authentication data that enable the device to enter the sensitive state.
The secure operator interface is so designed that entry of more than one password (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
Operator functions need to be controlled and defined. Certain operator functions can only be done when the device is in a sensitive state. A sensitive state is defined as to when the device is under dual or multiple control and that more than one password is required to enter a sensitive state. To activate the secure operator interface, more than one password or equivalent mechanism for dual or multiple control is required.
PINs or passwords used for authentication are at least …
Added
p. 88
TE2.9 The tester shall attempt to exceed the vendor-specified limit on the number of function calls (services) and time limit. Once the limit is exceeded, the tester shall verify that the device has returned to its normal state and requires re-authentication.
Added
p. 89
For devices that manually activate the MAC keys, the identity of the key is displayed on the device to ensure the correct key is used if multiple keys are present in the device.
Plaintext-computed MACs should never be outputted on the denial or confirmation of the MAC.
TF1.1 The tester shall examine the response to Section F1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F1 of the PCI PTS HSM Modular Security Requirements for consistency relating to manual activation and outputs of the message authentication device. The tester shall summarize the responses.
TF1.2 The tester shall examine and cite any relevant documentation such as a user guide or operations manual, submitted by the vendor to verify that it supports vendor responses.
TF1.3 The tester shall determine from vendor documentation that the message authentication device can be manually activated and the identity of the key used is displayed …
Plaintext-computed MACs should never be outputted on the denial or confirmation of the MAC.
TF1.1 The tester shall examine the response to Section F1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F1 of the PCI PTS HSM Modular Security Requirements for consistency relating to manual activation and outputs of the message authentication device. The tester shall summarize the responses.
TF1.2 The tester shall examine and cite any relevant documentation such as a user guide or operations manual, submitted by the vendor to verify that it supports vendor responses.
TF1.3 The tester shall determine from vendor documentation that the message authentication device can be manually activated and the identity of the key used is displayed …
Added
p. 90
One of the following as defined in ISO 16609 must be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.
TF2.1 The tester shall examine the vendor’s response to Section F2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F2 of the PCI PTS HSM Modular Security Requirements for ensuring the MAC being generated or verified meets the ISO 16609. The tester shall summarize the responses.
TF2.2 The tester shall examine and cite any relevant documentation (e.g., design documentation, key- management specification) that describes the MAC length to determine whether it supports the assertions made by the vendor.
TF2.3 The tester shall list the MAC length values used by the device and all values supports.
TF2.4 The tester shall verify and list all MAC generation algorithms used by the device.
TF2.1 The tester shall examine the vendor’s response to Section F2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F2 of the PCI PTS HSM Modular Security Requirements for ensuring the MAC being generated or verified meets the ISO 16609. The tester shall summarize the responses.
TF2.2 The tester shall examine and cite any relevant documentation (e.g., design documentation, key- management specification) that describes the MAC length to determine whether it supports the assertions made by the vendor.
TF2.3 The tester shall list the MAC length values used by the device and all values supports.
TF2.4 The tester shall verify and list all MAC generation algorithms used by the device.
Added
p. 91
One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.
TF3.1 The tester shall examine the response to Section F3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F3 of the PCI PTS HSM Modular Security Requirements for consistency relating to ISO 16609 two key MAC verification and generation techniques. The tester shall summarize the responses TF3.2 The tester shall and cite examine any additional documentation (e.g., design documentation, key-management specification) submitted by the vendor that describes the MAC generation and verification to determine whether it supports the assertions made by the vendor.
TF3.3 The tester shall verify that the MAC generation and verification techniques meet ISO 16609.
TF3.4 The tester shall list the techniques used for MAC generation and verification.
TF3.1 The tester shall examine the response to Section F3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F3 of the PCI PTS HSM Modular Security Requirements for consistency relating to ISO 16609 two key MAC verification and generation techniques. The tester shall summarize the responses TF3.2 The tester shall and cite examine any additional documentation (e.g., design documentation, key-management specification) submitted by the vendor that describes the MAC generation and verification to determine whether it supports the assertions made by the vendor.
TF3.3 The tester shall verify that the MAC generation and verification techniques meet ISO 16609.
TF3.4 The tester shall list the techniques used for MAC generation and verification.
Added
p. 92
MAC keys shall be used for only one function such as verify the MAC of received text or generate and output a MAC for a text being transmitted.
TF4.1 The tester shall examine the vendor’s response to Section F4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F4 of the PCI PTS HSM Modular Security Requirements to ensure unidirectional MAC keys are used for only a single function. The tester shall summarize the responses.
TF4.2 The tester shall examine and cite any additional documentation (e.g., design documentation, key-management specification) that describes unidirectional MAC keys to determine whether it supports the assertions made by the vendor.
TF4.3 The tester shall verify that in the use of unidirectional MAC keys, they are used for one type of MAC function only. The tester shall try multiple functions and document the results.
TF4.4 The tester shall list all MAC functions to ensure …
TF4.1 The tester shall examine the vendor’s response to Section F4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F4 of the PCI PTS HSM Modular Security Requirements to ensure unidirectional MAC keys are used for only a single function. The tester shall summarize the responses.
TF4.2 The tester shall examine and cite any additional documentation (e.g., design documentation, key-management specification) that describes unidirectional MAC keys to determine whether it supports the assertions made by the vendor.
TF4.3 The tester shall verify that in the use of unidirectional MAC keys, they are used for one type of MAC function only. The tester shall try multiple functions and document the results.
TF4.4 The tester shall list all MAC functions to ensure …
Added
p. 93
• The device includes mechanisms such that the removal of the device from its operational location will cause the automatic erasure of the cryptographic keys contained within the device; or
• Removal of the device would be of no benefit because its tamper-resistance or tamper- responsive characteristics ensure that the extraction of cryptographic keys or other secret data is not feasible.
TG1.1 The tester shall examine the vendor’s response to Section G1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G1 of the PCI PTS HSM Modular Security Requirements to verify that the device has protections from unauthorized removal and meets at least one of the outlined requirements. The tester shall summarize the response.
TG1.2 The tester shall examine and cite any relevant documentation
•such as the user guide, specification of the device’s logical structure, installation guide
•submitted by the vendor to verify that it supports the vendor responses.
TG1.3 …
• Removal of the device would be of no benefit because its tamper-resistance or tamper- responsive characteristics ensure that the extraction of cryptographic keys or other secret data is not feasible.
TG1.1 The tester shall examine the vendor’s response to Section G1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G1 of the PCI PTS HSM Modular Security Requirements to verify that the device has protections from unauthorized removal and meets at least one of the outlined requirements. The tester shall summarize the response.
TG1.2 The tester shall examine and cite any relevant documentation
•such as the user guide, specification of the device’s logical structure, installation guide
•submitted by the vendor to verify that it supports the vendor responses.
TG1.3 …
Added
p. 94
• The device requires that at least two passwords (or some equivalent mechanism for dual or multiple control) be correctly entered within a period of no more than five minutes before the device will output a key.
• The device requires that at least two different, physical keys (marked “not to be commercially reproduced”) be concurrently inserted in the unit before it will output a key.
TG2.1 The tester shall examine the vendor’s response to Section G2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G2 of the PCI PTS HSM Modular Security Requirements to ensure the device only exports plaintext key under dual control. The tester shall summarize the vendor’s response.
TG2.2 The tester shall examine and cite any additional documentation (e.g., key-management specification, operator manual) that describes the techniques used to export plaintext keys and whether it supports the assertions made by the vendor.
TG2.3 The …
• The device requires that at least two different, physical keys (marked “not to be commercially reproduced”) be concurrently inserted in the unit before it will output a key.
TG2.1 The tester shall examine the vendor’s response to Section G2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G2 of the PCI PTS HSM Modular Security Requirements to ensure the device only exports plaintext key under dual control. The tester shall summarize the vendor’s response.
TG2.2 The tester shall examine and cite any additional documentation (e.g., key-management specification, operator manual) that describes the techniques used to export plaintext keys and whether it supports the assertions made by the vendor.
TG2.3 The …
Added
p. 95
• Manual input of control data (e.g., key verification code) to enable export, import or use of a key; and
• Permitting movement of the device without activating a key-erasure mechanism.
TG3.1 The tester shall examine the vendor’s response to Section G3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G3 of the PCI PTS HSM Modular Security Requirements to ensure the device is in a sensitive state when using special operator functions. The tester shall summarize the vendor’s response.
TG3.2 The tester shall examine and cite any additional documentation (e.g., key-management specification, operator manual) that describes the special operator functions that place the device into a sensitive state and whether the documentation supports the assertions made by the vendor.
TG3.3 The tester shall verify the device is placed in a sensitive state when permitting movement of the device without activating a key-erasure mechanism as described in vendor …
• Permitting movement of the device without activating a key-erasure mechanism.
TG3.1 The tester shall examine the vendor’s response to Section G3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G3 of the PCI PTS HSM Modular Security Requirements to ensure the device is in a sensitive state when using special operator functions. The tester shall summarize the vendor’s response.
TG3.2 The tester shall examine and cite any additional documentation (e.g., key-management specification, operator manual) that describes the special operator functions that place the device into a sensitive state and whether the documentation supports the assertions made by the vendor.
TG3.3 The tester shall verify the device is placed in a sensitive state when permitting movement of the device without activating a key-erasure mechanism as described in vendor …
Added
p. 96
• Totally equivalent to a series of standard and approved functions; or
• Limited to use only keys that, by virtue of key separation, cannot be used with keys, or modified keys, of non-proprietary functions.
TG4.1 The tester shall examine the vendor’s response to Section G4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G4 of the PCI PTS HSM Modular Security Requirements to ensure that proprietary functions are listed and do not impact security of the device. The tester shall summarize the vendor’s response.
TG4.2 The tester shall examine and cite any additional documentation (e.g., key-management specification, operator manual) that describes any proprietary functions in the device and whether it supports the assertions made by the vendor.
TG4.3 The tester shall verify that any proprietary function is totally equivalent to a series of standard and approved functions or is limited to use only keys that, by virtue …
• Limited to use only keys that, by virtue of key separation, cannot be used with keys, or modified keys, of non-proprietary functions.
TG4.1 The tester shall examine the vendor’s response to Section G4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G4 of the PCI PTS HSM Modular Security Requirements to ensure that proprietary functions are listed and do not impact security of the device. The tester shall summarize the vendor’s response.
TG4.2 The tester shall examine and cite any additional documentation (e.g., key-management specification, operator manual) that describes any proprietary functions in the device and whether it supports the assertions made by the vendor.
TG4.3 The tester shall verify that any proprietary function is totally equivalent to a series of standard and approved functions or is limited to use only keys that, by virtue …
Added
p. 97
• The asymmetric private and public key pair is generated within the digital signature device; and
• The asymmetric private key is only exported outside the original digital signature device under dual control and only for backup and archival purposes; and
• Mechanisms for the control of the use of the private key are provided.
TH1.1 The tester shall examine the vendor’s response to Section H1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement H1 of the PCI PTS HSM Modular Security Requirements for how the device meets the described above. The tester shall summarize the vendor’s response.
TH1.2 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance documents)
•submitted by the vendor to verify that it supports the vendor responses.
TH1.3 The tester shall verify whether the asymmetric private and public key pair is generated within the digital signature device.
TH1.4 The …
• The asymmetric private key is only exported outside the original digital signature device under dual control and only for backup and archival purposes; and
• Mechanisms for the control of the use of the private key are provided.
TH1.1 The tester shall examine the vendor’s response to Section H1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement H1 of the PCI PTS HSM Modular Security Requirements for how the device meets the described above. The tester shall summarize the vendor’s response.
TH1.2 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance documents)
•submitted by the vendor to verify that it supports the vendor responses.
TH1.3 The tester shall verify whether the asymmetric private and public key pair is generated within the digital signature device.
TH1.4 The …
Added
p. 98
• Use of public key certificates, where the public key certificate was obtained from an authorized certificate authority (e.g., the vendor PKI); or
• Use of public key certificates and appropriate certificate management procedures; or
• Use of public key certificates and appropriate certificate management procedures; or
• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.
• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.
TH2.1 The tester shall examine the vendor’s response to Section H2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement H2 of the PCI PTS HSM Modular Security Requirements to ensure the device meets the standard. The tester shall summarize the vendor’s response.
TH2.2 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance document
•submitted by the vendor to verify that it supports …
• Use of public key certificates and appropriate certificate management procedures; or
• Use of public key certificates and appropriate certificate management procedures; or
• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.
• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.
TH2.1 The tester shall examine the vendor’s response to Section H2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement H2 of the PCI PTS HSM Modular Security Requirements to ensure the device meets the standard. The tester shall summarize the vendor’s response.
TH2.2 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance document
•submitted by the vendor to verify that it supports …
Added
p. 99
The organization must utilize a documented and approved, secure change management system, such that all development is traceable and access restricted. All changes should be reviewed and approved prior to release. The change control procedures shall include the unique identification of all configuration items and their developer, including the device, its parts•and its firmware.
Note: Hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Options that cannot be a variable character include those that directly pertain to meeting security requirements.
TI1.1 The tester shall examine the vendor’s response to Section I1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I1 of the PCI PTS HSM Modular Security …
Note: Hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Options that cannot be a variable character include those that directly pertain to meeting security requirements.
TI1.1 The tester shall examine the vendor’s response to Section I1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I1 of the PCI PTS HSM Modular Security …
Added
p. 99
TI1.4 The tester shall interview those responsible for the change control processes
•including engineers and programming staff, supervisory staff, technical management, etc.
•including engineers and programming staff, supervisory staff, technical management, etc.
Added
p. 100
TI1.6 The tester shall validate that either:
• All changes to PCI-approved devices have been submitted for re-evaluation; or
• Only changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality are deferred from submission and not submitted immediately, but are instead submitted on an aggregate basis.
• All changes to PCI-approved devices have been submitted for re-evaluation; or
• Only changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality are deferred from submission and not submitted immediately, but are instead submitted on an aggregate basis.
Added
p. 101
All certified firmware must be signed prior to distribution and signed using dual control. It should be managed such that no single person is able to sign files. If two secrets (passwords or PINs) are required for operation of the signing tool, no single person should know both secrets. All certified firmware must be reviewed against the organization’s coding standards prior to signature.
TI2.1 The tester shall examine the vendor’s response to Section I2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I2 of the PCI PTS HSM Modular Security Requirements for consistency relevant to certified firmware control procedures. The tester shall summarize the responses.
TI2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control and validation processes and procedures for storage during the manufacturing process.
TL2.3 The tester shall examine and cite any supporting documentation submitted …
TI2.1 The tester shall examine the vendor’s response to Section I2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I2 of the PCI PTS HSM Modular Security Requirements for consistency relevant to certified firmware control procedures. The tester shall summarize the responses.
TI2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control and validation processes and procedures for storage during the manufacturing process.
TL2.3 The tester shall examine and cite any supporting documentation submitted …
Added
p. 102
TI3.1 The tester shall examine the vendor’s response to Section I3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I3 of the PCI PTS HSM Modular Security Requirements for consistency relevant to device component control procedures. The tester shall summarize the responses.
TI3.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should detail the components used and the component control processes and procedures for storage and verification during the manufacturing process including components identification verification, with the procedures checked in TI1.2.
TI3.3 The tester shall interview those responsible for component control processes
•including engineers and line staff, supervisory staff, technical management, etc.
TI3.4 The tester shall examine the device parts listing and sample components during manufacturing, to ensure the correct components are used.
TI3.5 The tester shall observe component control to ensure that …
TI3.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should detail the components used and the component control processes and procedures for storage and verification during the manufacturing process including components identification verification, with the procedures checked in TI1.2.
TI3.3 The tester shall interview those responsible for component control processes
•including engineers and line staff, supervisory staff, technical management, etc.
TI3.4 The tester shall examine the device parts listing and sample components during manufacturing, to ensure the correct components are used.
TI3.5 The tester shall observe component control to ensure that …
Added
p. 103
All software (e.g., firmware) loaded into the device must be signed prior to use; and all software (e.g., firmware) needs to be controlled and protected during manufacturing. All software (e.g., firmware) must be validated before each use to prevent unauthorized modifications and/or substitutions.
TI4.1 The tester shall examine the vendor’s response to Section I4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I4 of the PCI PTS HSM Modular Security Requirements for consistency relevant to production firmware control procedures. The tester shall summarize the responses.
TI4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for loading firmware during the manufacturing process.
TI4.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for transporting and storing firmware during the manufacturing …
TI4.1 The tester shall examine the vendor’s response to Section I4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I4 of the PCI PTS HSM Modular Security Requirements for consistency relevant to production firmware control procedures. The tester shall summarize the responses.
TI4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for loading firmware during the manufacturing process.
TI4.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for transporting and storing firmware during the manufacturing …
Added
p. 104
Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an accessed controlled area until shipped. The device or components must be checked prior to shipping to ensure the device has not been modified or tampered.
TI5.1 The tester shall examine the vendor’s response to Section I5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to post-production storage. The tester shall summarize the responses.
TI5.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail documented and approved post-production control processes and procedures for storage and validation of devices or their components subsequent to production but prior to shipping.
TI5.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail tamper-evident packaging …
TI5.1 The tester shall examine the vendor’s response to Section I5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to post-production storage. The tester shall summarize the responses.
TI5.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail documented and approved post-production control processes and procedures for storage and validation of devices or their components subsequent to production but prior to shipping.
TI5.3 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail tamper-evident packaging …
Added
p. 104
TI5.5 The tester shall examine a sample of documentation for post-production storage
•including inventory logs, shipping documentation, and device-validation procedures
•to ensure procedures are followed.
TI5.6 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.
TI5.7 The tester shall examine the vendor’s tamper-evident packing or access-controlled area to ensure unauthorized access to devices or their components is not possible.
•including inventory logs, shipping documentation, and device-validation procedures
•to ensure procedures are followed.
TI5.6 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.
TI5.7 The tester shall examine the vendor’s tamper-evident packing or access-controlled area to ensure unauthorized access to devices or their components is not possible.
Added
p. 105
One example of such information is the private key of an asymmetric key pair with the public key of the device signed by a private key known only to the manufacturer.
Dual control is not required if the device generates the secret information and never outputs it, for example if it generates a public/private key pair and never outputs the private key.
TI6.1 The tester shall examine the vendor’s response to Section I6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I6 of the PCI PTS HSM Modular Security Requirements for consistency relevant to secret information. The tester shall summarize the responses.
TI6.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the key-loading facility or the facility of initial deployment by means of secret information placed in the device during …
Dual control is not required if the device generates the secret information and never outputs it, for example if it generates a public/private key pair and never outputs the private key.
TI6.1 The tester shall examine the vendor’s response to Section I6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I6 of the PCI PTS HSM Modular Security Requirements for consistency relevant to secret information. The tester shall summarize the responses.
TI6.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the key-loading facility or the facility of initial deployment by means of secret information placed in the device during …
Added
p. 106
The PCI Terminal Software Security Best Practices Guidance document can provide additional guidance for software development and testing.
TI7.1 The tester shall examine the vendor’s response to Section I7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to component control procedures during design and development. The tester shall summarize the responses.
TI7.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the design and development processes and procedures to ensure security measures are followed during the development and maintenance of the device’s security-related components. Furthermore, the approved documentation must justify that the security measures provide the necessary level of protection to maintain the integrity of the device’s security-related components Where required to validate via site inspection, the tester shall complete the following additional steps:
TI7.3 The tester …
TI7.1 The tester shall examine the vendor’s response to Section I7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to component control procedures during design and development. The tester shall summarize the responses.
TI7.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the design and development processes and procedures to ensure security measures are followed during the development and maintenance of the device’s security-related components. Furthermore, the approved documentation must justify that the security measures provide the necessary level of protection to maintain the integrity of the device’s security-related components Where required to validate via site inspection, the tester shall complete the following additional steps:
TI7.3 The tester …
Added
p. 106
TI7.4 The tester shall examine a sample of approved documentation for component control during design and development
•including user documentation and component validation procedures
•to ensure procedures are followed.
TI7.5 The tester shall observe the approved component control procedures during design and development to ensure security measures are followed during the development and maintenance of the device’s security-related components.
TI7.6 The tester shall verify that the manufacturer maintains approved development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the device’s security-related components in their development environment and that this provides evidence that these security measures are followed during the development and maintenance of the device’s security-related components.
•including user documentation and component validation procedures
•to ensure procedures are followed.
TI7.5 The tester shall observe the approved component control procedures during design and development to ensure security measures are followed during the development and maintenance of the device’s security-related components.
TI7.6 The tester shall verify that the manufacturer maintains approved development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the device’s security-related components in their development environment and that this provides evidence that these security measures are followed during the development and maintenance of the device’s security-related components.
Added
p. 107
Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an accessed controlled area until shipped. The device or components should be checked prior to shipping to ensure the device has not been modified or tampered.
TI8.1 The tester shall examine the vendor’s response to Section I8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to repair and inspection subsequent to repair. The tester shall summarize the responses.
TI8.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail repair
•including the resetting of tamper mechanisms, inspection, and post-inspection control processes
•and procedures for storage and validation of devices or their components subsequent to repair and inspection but prior to shipping.
TI8.3 The tester shall examine, cite, and reference any supporting documentation …
TI8.1 The tester shall examine the vendor’s response to Section I8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to repair and inspection subsequent to repair. The tester shall summarize the responses.
TI8.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail repair
•including the resetting of tamper mechanisms, inspection, and post-inspection control processes
•and procedures for storage and validation of devices or their components subsequent to repair and inspection but prior to shipping.
TI8.3 The tester shall examine, cite, and reference any supporting documentation …
Added
p. 108
Where this is not possible, the device is shipped from the manufacturer’s facility to the facility of initial deployment and stored en route under auditable controls that can account for the location of every device at every point in time.
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.
The product shall be protected for at all points during the shipping process. Tamper-detection security features, instructions for receiving and inspection, and documentation covering suspected tampering must be provided and used.
Prior to initial financial-key loading, the device should be protected against modification. Such protection shall be a combination of the characteristics of the device (i.e., tamper evidence, resistance, and responsiveness) and device management procedures. If the device has any manufacturer keys loaded, compromise shall be both prevented and detected.
TJ1.1 The tester …
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.
The product shall be protected for at all points during the shipping process. Tamper-detection security features, instructions for receiving and inspection, and documentation covering suspected tampering must be provided and used.
Prior to initial financial-key loading, the device should be protected against modification. Such protection shall be a combination of the characteristics of the device (i.e., tamper evidence, resistance, and responsiveness) and device management procedures. If the device has any manufacturer keys loaded, compromise shall be both prevented and detected.
TJ1.1 The tester …
Added
p. 109
TJ1.6 The tester shall observe the shipping process to ensure that customers are provided documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the device; or alternatively, the device is shipped from the manufacturer’s facility to the facility of initial deployment and stored en route under auditable controls.
Added
p. 110
The product shall be accounted for at all points during the shipping process until transfer of responsibility. Documentation shall be maintained for each device.
TJ2.1 The tester shall examine the vendor’s response to Section J2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J2 of the PCI PTS HSM Modular Security Requirements for device-accountability transfer procedures. The tester shall summarize the responses.
TJ2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment Where required to validate …
TJ2.1 The tester shall examine the vendor’s response to Section J2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J2 of the PCI PTS HSM Modular Security Requirements for device-accountability transfer procedures. The tester shall summarize the responses.
TJ2.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment Where required to validate …
Added
p. 111
• Shipped and stored in tamper-evident packaging; and/or
• Shipped and stored containing a secret that:
• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
• Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
TJ3.1 The tester shall examine the vendor’s response to Section J3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J3 of the PCI PTS HSM Modular Security Requirements for shipping tamper-protection documentation. The tester shall summarize the responses.
TJ3.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence; and describe how this shows compliance to this requirement.
TJ3.3 The tester shall interview those responsible for the shipping control processes
•including engineers, software developers, …
• Shipped and stored containing a secret that:
• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
• Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
TJ3.1 The tester shall examine the vendor’s response to Section J3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J3 of the PCI PTS HSM Modular Security Requirements for shipping tamper-protection documentation. The tester shall summarize the responses.
TJ3.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence; and describe how this shows compliance to this requirement.
TJ3.3 The tester shall interview those responsible for the shipping control processes
•including engineers, software developers, …
Added
p. 112
TJ4.1 The tester shall examine the vendor’s response to Section J4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J4 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the authenticity of the TOE’s security-relevant components at the facility of initial deployment. The tester shall summarize the responses.
TJ4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the device’s development-security documentation to ensure the authenticity of the devices security relevant components and describe how this shows compliance to this requirement.
TJ4.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
TJ4.4 The tester shall examine a sample of documentation for device-development security, including user documentation, and component validation procedures to ensure procedures are followed.
TJ4.5 The tester shall observe the secure development component control …
TJ4.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the device’s development-security documentation to ensure the authenticity of the devices security relevant components and describe how this shows compliance to this requirement.
TJ4.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
TJ4.4 The tester shall examine a sample of documentation for device-development security, including user documentation, and component validation procedures to ensure procedures are followed.
TJ4.5 The tester shall observe the secure development component control …
Added
p. 113
TJ5.1 The tester shall examine the vendor’s response to Section J5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the authenticity of the device security related components. The tester shall summarize the responses.
TJ5.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures for the manufacturer to ensure the authenticity of the devices security relevant components.
TJ5.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
TJ5.4 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.
TJ5.5 The tester shall observe the initial key-loading procedures to ensure the authenticity of the device’s security-related components is verified.
TJ5.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures for the manufacturer to ensure the authenticity of the devices security relevant components.
TJ5.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
TJ5.4 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.
TJ5.5 The tester shall observe the initial key-loading procedures to ensure the authenticity of the device’s security-related components is verified.
Added
p. 114
TJ6.1 The tester shall examine the vendor’s response to Section J6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J6 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the manufacturer provides the means to the facility of initial deployment to assure the authenticity of the device’s security- related components. The tester shall summarize the responses.
TJ6.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures provided by the manufacturer to the initial key-loading facility to assure the authenticity of the devices security relevant components for the initial key- loading facility.
TJ6.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
TJ6.4 The tester shall examine a sample of documentation, including user documentation and component-validation procedures, to ensure procedures are followed at the …
TJ6.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures provided by the manufacturer to the initial key-loading facility to assure the authenticity of the devices security relevant components for the initial key- loading facility.
TJ6.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
TJ6.4 The tester shall examine a sample of documentation, including user documentation and component-validation procedures, to ensure procedures are followed at the …
Added
p. 115
TJ7.1 The tester shall examine the vendor’s response to Section J7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to the manufacturer providing a unique visible identifier for each device. The tester shall summarize the responses.
TJ7.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail how the change control procedures required in I1 are used in compliance with this requirement.
TJ7.3 The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.
TJ7.4 The tester shall sample the devices to ensure that each visible identifier is unique and is consistent with the identifiers checked with the change control procedure in as required in I1.
TJ7.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail how the change control procedures required in I1 are used in compliance with this requirement.
TJ7.3 The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.
TJ7.4 The tester shall sample the devices to ensure that each visible identifier is unique and is consistent with the identifiers checked with the change control procedure in as required in I1.
Added
p. 116
• Data on production and personalization
• Physical/chronological whereabouts
• Repair and maintenance
• Removal from operation
• Loss or theft The operational management manual provides instructions and information concerning the identification, use, repair, updates, and configuration of hardware and firmware components of the device. This manual is in addition to user and application operation and configuration manuals.
TJ8.1 The tester shall examine the vendor’s response to Section J8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the vendor maintains a manual that provides instructions for the operational management of the device. The tester shall summarize the responses.
TJ8.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should include instructions for recording the entire life cycle of the device’s security-related …
• Physical/chronological whereabouts
• Repair and maintenance
• Removal from operation
• Loss or theft The operational management manual provides instructions and information concerning the identification, use, repair, updates, and configuration of hardware and firmware components of the device. This manual is in addition to user and application operation and configuration manuals.
TJ8.1 The tester shall examine the vendor’s response to Section J8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the vendor maintains a manual that provides instructions for the operational management of the device. The tester shall summarize the responses.
TJ8.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should include instructions for recording the entire life cycle of the device’s security-related …
Added
p. 118
b) Skilled persons are skilled in doing or using something and are able to do more complex tasks and attack steps. They have or can demonstrate the ability and training to perform a specific task well.
c) Proficient persons are (highly) competent and have the necessary ability, knowledge, or skill to do something successfully. They are knowledgeable and skilled in that they are familiar with the security functionalities and behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully. Proficient personnel can acquire capabilities equivalent to the skill sets of PTS lab evaluators.
c) Experts are very knowledgeable about or skillful in a particular area. They are very familiar with the underlying algorithms, protocols, hardware components, physical and logical architectures, etc., implemented in the device or system type and the principles and concepts of security employed. Experts are capable of …
c) Proficient persons are (highly) competent and have the necessary ability, knowledge, or skill to do something successfully. They are knowledgeable and skilled in that they are familiar with the security functionalities and behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully. Proficient personnel can acquire capabilities equivalent to the skill sets of PTS lab evaluators.
c) Experts are very knowledgeable about or skillful in a particular area. They are very familiar with the underlying algorithms, protocols, hardware components, physical and logical architectures, etc., implemented in the device or system type and the principles and concepts of security employed. Experts are capable of …
Added
p. 120
• Scanning Electron Microscope If, for one phase (identification or exploitation), equipment from different levels is required, only the highest level shall be retained. Hence, only the highest level of equipment shall be counted in any one phase of an attack calculation.
Parts used during the Identification phase that can be used in the initial exploitation must be counted fully in the Exploitation phase to equalize the attack potential value across all exploitations. If it is not readily reusable
•the part once used in installation becomes unusable for exploitation because, for example, it is glued with epoxy and difficult to remove
•it can be accounted for twice: once in the Identification phase and again in the Exploitation phase.
• Knowledge If several attack scenarios lead to the same potential in total and exploitation, the one that has the lowest cost in exploitation, exclusive of the items above, must be considered. Attack calculations must allocate …
Parts used during the Identification phase that can be used in the initial exploitation must be counted fully in the Exploitation phase to equalize the attack potential value across all exploitations. If it is not readily reusable
•the part once used in installation becomes unusable for exploitation because, for example, it is glued with epoxy and difficult to remove
•it can be accounted for twice: once in the Identification phase and again in the Exploitation phase.
• Knowledge If several attack scenarios lead to the same potential in total and exploitation, the one that has the lowest cost in exploitation, exclusive of the items above, must be considered. Attack calculations must allocate …
Added
p. 125
Table 4: Attack Potentials Example for DPA Analysis Aspect Identifying Value Exploiting Value Attack time Beyond 160h 7.5 ≤ 8 h 3 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to PIN entry device Functional sample with trial keys 2 Functional sample with working keys Equipment Bespoke 5 Specialized 3 Specific parts Standard 1 No further parts Attack potential per phase 21.5 14 Total Attack Potential 35.5 Payment Card Industry PTS HSM Modular Derived Test Requirements, v3.0
Added
p. 126
• Cutting blades (for example, scalpels, X-Acto knives, box cutters, axes, saws, etc.), including both conductive and non-conductive blades
• Dremel tool, attachments, extension cable, holder/mill jig, etc.
• Screwdrivers of any type
•including custom tips, as they can be cut from another type of screwdriver simply enough if not able to be purchased
• Hammers, saws, pliers, clamps (G-type, screw type, and any others)
• Oscilloscope
•up to around 200Mhz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
• Simple milling machine
• Drills and drill press, any drill bits down to 0.1mm
• Conductive and non-conductive ink
• PCB etching equipment
• PCB design software
• Simple side-channel software (able to perform basic sum-of-least-squares alignment and single order correlation attacks)
• Acid of most types used for attacks, including for etching of chips
• Solvents, cleaning materials, plastic working tools
• Low-resolution 3D printers
• Soldering irons of any type, including with heated rework tweezers or temperature-controlled hot-air …
• Dremel tool, attachments, extension cable, holder/mill jig, etc.
• Screwdrivers of any type
•including custom tips, as they can be cut from another type of screwdriver simply enough if not able to be purchased
• Hammers, saws, pliers, clamps (G-type, screw type, and any others)
• Oscilloscope
•up to around 200Mhz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
• Simple milling machine
• Drills and drill press, any drill bits down to 0.1mm
• Conductive and non-conductive ink
• PCB etching equipment
• PCB design software
• Simple side-channel software (able to perform basic sum-of-least-squares alignment and single order correlation attacks)
• Acid of most types used for attacks, including for etching of chips
• Solvents, cleaning materials, plastic working tools
• Low-resolution 3D printers
• Soldering irons of any type, including with heated rework tweezers or temperature-controlled hot-air …
Added
p. 127
• Expensive, high-resolution, high-frequency, deep-buffer oscilloscopes (> 1GS/s, 1GHz, 16 bit, etc.)
• High-resolution 3D printers
• High-resolution milling machines (for example, for chip planing)
• Complex side-channel software, able to perform complex alignment, noise removal, etc.
• It is expected that this will be run on a standard PC (Standard equipment)
• Micro-probes for attachment to die-level features such as bus lines on chips
• EMFI glitching system
• High-frequency/high-bandwidth EM probes
• 16/32 bit high-speed logic analyzer for capture and analysis of bus traffic
• Dedicated electronic cards
• Specialized test benches
• Microprobe workstation
• Laser abrading/cutting Bespoke equipment “Rule of thumb” followed: If it cannot be obtained for less than US$50000 or extensive customization is required for such an attack, it falls under this category. Bespoke equipment is expected to be required only in very rare circumstances.
• Plasma etching equipment
• Automated (“push-button”) side-channel software to be used on a specific PED model to bypass strong countermeasures and leak …
• High-resolution 3D printers
• High-resolution milling machines (for example, for chip planing)
• Complex side-channel software, able to perform complex alignment, noise removal, etc.
• It is expected that this will be run on a standard PC (Standard equipment)
• Micro-probes for attachment to die-level features such as bus lines on chips
• EMFI glitching system
• High-frequency/high-bandwidth EM probes
• 16/32 bit high-speed logic analyzer for capture and analysis of bus traffic
• Dedicated electronic cards
• Specialized test benches
• Microprobe workstation
• Laser abrading/cutting Bespoke equipment “Rule of thumb” followed: If it cannot be obtained for less than US$50000 or extensive customization is required for such an attack, it falls under this category. Bespoke equipment is expected to be required only in very rare circumstances.
• Plasma etching equipment
• Automated (“push-button”) side-channel software to be used on a specific PED model to bypass strong countermeasures and leak …
Added
p. 128
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.
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 …
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 …
Added
p. 131
For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
2. 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).
3. Each private key shall be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
4. Entities must authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques). One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method …
2. 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).
3. Each private key shall be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
4. Entities must authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques). One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method …
Added
p. 132
Note: This appendix is for use in conjunction with Requirement A5
• “Determining Keys Analysis.” Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, may show how a key can be fully exposed but at an acceptable level of difficulty, or may produce a partial result. In every case, a test determining compliance will demonstrate that an attack in the field is infeasible with respect to PTS Security Requirements’ pass/fail thresholds.
This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a feasible method to compromise these assets. This …
• “Determining Keys Analysis.” Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, may show how a key can be fully exposed but at an acceptable level of difficulty, or may produce a partial result. In every case, a test determining compliance will demonstrate that an attack in the field is infeasible with respect to PTS Security Requirements’ pass/fail thresholds.
This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a feasible method to compromise these assets. This …
Added
p. 133
All PCI PTS-recognized Laboratories must be capable of performing SCA with an attack potential that can distinguish compliant from non-compliant devices. This capability relies on a strong foundation of combined competencies that must be available for any test: skills, knowledge, and experience; collection and analysis equipment (both hardware equipment and software tools).
Laboratories’ SCA resources must be maintained at levels consistent with industry “state-of-the-art,” capabilities, including (but not restricted to): cryptanalysis of all relevant algorithms, higher-order DPA, and template attacks. Laboratories’ resources must be improved regularly to reflect updates to the PCI PTS program, for example as version changes occur and/or as new attacks are published. Labs must have available a sufficient volume of personnel and equipment resources to be capable of performing SCA at any capacity of evaluations the lab undertakes.
The best SCA tools, even implementing advanced automation, are useless without a proficient user. PCI SSC expects laboratory personnel to …
Laboratories’ SCA resources must be maintained at levels consistent with industry “state-of-the-art,” capabilities, including (but not restricted to): cryptanalysis of all relevant algorithms, higher-order DPA, and template attacks. Laboratories’ resources must be improved regularly to reflect updates to the PCI PTS program, for example as version changes occur and/or as new attacks are published. Labs must have available a sufficient volume of personnel and equipment resources to be capable of performing SCA at any capacity of evaluations the lab undertakes.
The best SCA tools, even implementing advanced automation, are useless without a proficient user. PCI SSC expects laboratory personnel to …
Added
p. 134
• SCA toolsets are adaptable and extensible according to variable test situations, providing effective user interfaces and user-configurable functionalities.
• SCA toolsets are updated incrementally to: improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.
Laboratory capabilities related to any of the resources outlined above must correspond closely to information expressed in current versions of PTS documents and to information releases from PCI SSC.
Principles and methods for testing
PCI SSC expects that the overall quality and effort required for SCA testing to conclude device compliance is comparable to the criteria described here.
SCA must not be hindered by lack of basic resources PCI SSC considers to be essential. SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary tools can overcome straightforwardly. The following, non-exhaustive list gives examples of factors related to PCI SSC’s expectations in testing.
Factors related to testing expectations
• examples
• Relevant information …
• SCA toolsets are updated incrementally to: improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.
Laboratory capabilities related to any of the resources outlined above must correspond closely to information expressed in current versions of PTS documents and to information releases from PCI SSC.
Principles and methods for testing
PCI SSC expects that the overall quality and effort required for SCA testing to conclude device compliance is comparable to the criteria described here.
SCA must not be hindered by lack of basic resources PCI SSC considers to be essential. SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary tools can overcome straightforwardly. The following, non-exhaustive list gives examples of factors related to PCI SSC’s expectations in testing.
Factors related to testing expectations
• examples
• Relevant information …
Added
p. 135
• Validation of appropriate test methodologies sufficient to give a high degree of confidence that the device cannot be compromised using SCA methods similar to or different than those used in testing.
* Examples of specific attributes of SCA toolsets satisfying these expectations are listed below Critical steps in SCA scenarios Even in straightforward scenarios
•for example, in the absence of SCA countermeasures
•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.
• Understanding of the algorithm(s) to be attacked and how they are implemented: Determining the appropriate side channel(s) to acquire, collection method(s) and analysis tools, and their configuration. Next, validating that the device behaves as expected before proceeding further; if necessary gathering additional information and/or reconfiguring the test setup as required. This includes validation of: hardware/software identifiers and claimed countermeasures.
• Preparing the device: While many of the considerations for the …
* Examples of specific attributes of SCA toolsets satisfying these expectations are listed below Critical steps in SCA scenarios Even in straightforward scenarios
•for example, in the absence of SCA countermeasures
•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.
• Understanding of the algorithm(s) to be attacked and how they are implemented: Determining the appropriate side channel(s) to acquire, collection method(s) and analysis tools, and their configuration. Next, validating that the device behaves as expected before proceeding further; if necessary gathering additional information and/or reconfiguring the test setup as required. This includes validation of: hardware/software identifiers and claimed countermeasures.
• Preparing the device: While many of the considerations for the …
Added
p. 136
• Signal analysis and processing: All side-channel recordings will contain a certain degree of noise in acquired waveforms
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA patterns, correlation leakage pinpointing sensitive operations, and key-dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual countermeasures that obscure sensitive signals can significantly delay or prevent SCA attacks. Combinations of well-implemented countermeasures therefore provide greater defense-in-depth. Nevertheless, unintentional leakage may become straightforwardly detectable when noise is removed. It is possible to utilize design information and source-code review, to some extent, to infer the likely effectiveness of obstructive noise. However, there is always a possibility that obstructions may be removed by analyzing and modifying recordings to reveal hidden …
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA patterns, correlation leakage pinpointing sensitive operations, and key-dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual countermeasures that obscure sensitive signals can significantly delay or prevent SCA attacks. Combinations of well-implemented countermeasures therefore provide greater defense-in-depth. Nevertheless, unintentional leakage may become straightforwardly detectable when noise is removed. It is possible to utilize design information and source-code review, to some extent, to infer the likely effectiveness of obstructive noise. However, there is always a possibility that obstructions may be removed by analyzing and modifying recordings to reveal hidden …
Added
p. 137
• Validation: It is necessary for evaluations to check that critical steps performed in tests have the potential to succeed. It is often difficult to distinguish between a device’s apparently robust resistance to attacks versus results deriving from a flawed or naive testing approach. For example, the absence of significant correlation leakage may be due to several situations that produce similar outcomes: errors in correlation calculations, bugs in analysis tools, inappropriate choice of analysis parameters, poor alignment, under-sampling or poor noise filtering, electronic noise introduced by the collection unintentionally, electronic noise deliberately generated by designed hardware countermeasures, obstructive noise from algorithmic signal-randomizing countermeasures, countermeasures for mathematical masking of specific sensitive data values, etc.. Hence, tests should include processes to differentiate between valid results or null results and demonstrate this.
Testing rationale and reporting The outline information above defines many important aspects of testing. This should not be interpreted as an exhaustive …
Testing rationale and reporting The outline information above defines many important aspects of testing. This should not be interpreted as an exhaustive …
Added
p. 138
• Local key protection (internal and external memory encryption), and
• Authentication (e.g., firmware).
Determining test applicability Valid statements of compliance cannot be made based on documentation/source code alone; applied testing is needed. Therefore, in principle, all algorithms used for protecting the assets listed above must be analyzed using SCA to some extent. At a minimum, this means recording the algorithms’ side-channel profiles and validating that the profiles agree with the algorithms’ expected characteristics.
The evaluation should determine at least one algorithm to analyze thoroughly, based on a rigorous assessment of asset value versus feasible attacks. Reasoning for not testing any algorithm has to be explained. This reasoning should include reliable assumptions made in the vulnerability analysis based on: asset value and attack complexity•for example, limits on collections such as delay insertions or key- usage counters, and any additional countermeasures.
Prerequisites To facilitate testing, the vendor must provide “open” samples (with a wire or …
• Authentication (e.g., firmware).
Determining test applicability Valid statements of compliance cannot be made based on documentation/source code alone; applied testing is needed. Therefore, in principle, all algorithms used for protecting the assets listed above must be analyzed using SCA to some extent. At a minimum, this means recording the algorithms’ side-channel profiles and validating that the profiles agree with the algorithms’ expected characteristics.
The evaluation should determine at least one algorithm to analyze thoroughly, based on a rigorous assessment of asset value versus feasible attacks. Reasoning for not testing any algorithm has to be explained. This reasoning should include reliable assumptions made in the vulnerability analysis based on: asset value and attack complexity•for example, limits on collections such as delay insertions or key- usage counters, and any additional countermeasures.
Prerequisites To facilitate testing, the vendor must provide “open” samples (with a wire or …
Added
p. 139
• SCA results reused from other reports must not contain less information than required by the guidance
• The measurement setup of the reused analysis has to be described in a way that it can be justified that this setup also applies for the device under evaluation.
• The identification and configuration of the cryptographic component has to be compared to ensure that the results also apply to the device under evaluation
•e.g., registers for enabling/disabling counter measures, etc.
• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports, respectively the SCA part of the reports, are provided to the evaluation lab that wants to reuse the results.
• It has to be justified that the results remain valid. For example, no new attacks or measurement techniques are known which could impact on compliance.
• It should never be assumed that the use of …
• The measurement setup of the reused analysis has to be described in a way that it can be justified that this setup also applies for the device under evaluation.
• The identification and configuration of the cryptographic component has to be compared to ensure that the results also apply to the device under evaluation
•e.g., registers for enabling/disabling counter measures, etc.
• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports, respectively the SCA part of the reports, are provided to the evaluation lab that wants to reuse the results.
• It has to be justified that the results remain valid. For example, no new attacks or measurement techniques are known which could impact on compliance.
• It should never be assumed that the use of …
Added
p. 140
• Waveform analysis and filtering capable of producing and plotting frequency spectra derived from time-series waveforms.
• Functions capable of combining, removing, deriving, or otherwise operating on waveforms and spectra within one set and between different sets.
• Waveform and spectrum filters capable of selecting, counting, removing, summing, or otherwise operating on sample points, amplitude ranges, or data values against configurable thresholds.
• Waveform and spectrum filters capable of calculating and plotting statistical analysis of data set, such as variance, standard deviation, average, absolute or values, etc.
• Waveform and spectrum filters capable of producing and plotting frequency-filtered outputs such as: high-pass, low-pass, band-pass/reject, harmonics series pass/reject, etc.
• Compression functions capable of reducing waveform storage size with minimal reduction in SNR.
• Ability to apply processing operations to signals during waveform acquisition.
• Ability to apply operations on signals in batches/sequences, and to parallelize and otherwise automate time-consuming processes efficiently.
• Ability for the user to configure …
• Functions capable of combining, removing, deriving, or otherwise operating on waveforms and spectra within one set and between different sets.
• Waveform and spectrum filters capable of selecting, counting, removing, summing, or otherwise operating on sample points, amplitude ranges, or data values against configurable thresholds.
• Waveform and spectrum filters capable of calculating and plotting statistical analysis of data set, such as variance, standard deviation, average, absolute or values, etc.
• Waveform and spectrum filters capable of producing and plotting frequency-filtered outputs such as: high-pass, low-pass, band-pass/reject, harmonics series pass/reject, etc.
• Compression functions capable of reducing waveform storage size with minimal reduction in SNR.
• Ability to apply processing operations to signals during waveform acquisition.
• Ability to apply operations on signals in batches/sequences, and to parallelize and otherwise automate time-consuming processes efficiently.
• Ability for the user to configure …
Modified
p. 5 → 6
• Device Management Derived Test Requirements Each PCI requirement as stated in the PCI PTS Hardware Security Module (HSM) Modular Security Requirements is represented by a subsection. For example, Requirement A1.1 is represented in this document as:
Modified
p. 5 → 6
• That the existing FIPS certification covers the full HSM functionality for all the related requirements.
Removed
p. 6
“Secret information” is any private or secret cryptographic keys or passwords that the HSM relies on to maintain security characteristics governed by PCI requirements. If any of this secret information is not zeroized, other mechanisms must exist to disable the device.
The attack must take greater than 10 hours during the exploitation phase.
The attack must take greater than 10 hours during the exploitation phase.
Modified
p. 6 → 10
Areas of the HSM that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms. Areas where sensitive information is only present when a human operator is present may be protected solely by tamper evidence mechanisms if the vendor documentation describes an inspection process that must be performed prior to entering sensitive information.
Areas of the device that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms. Areas where sensitive information is only present when a human operator is present may be protected solely by tamper-evidence mechanisms if the vendor documentation describes an inspection process that must be performed prior to entering sensitive information.
Modified
p. 6 → 10
“Immediately inoperable” is defined as immediately ceasing all processing activities involving secure key materials and critical security parameters. Diagnostic functionality such as status information and audit trails may continue to be available following the stoppage of processing activities. The user may have access to utilities to recover the HSM to an operative state. Additionally, the tamper-detection and response mechanisms must result in the automatic and immediate erasure of any sensitive data that may be stored in the HSM, such that …
“Immediately inoperable” is defined as immediately ceasing all processing activities involving secure key materials and critical security parameters. Diagnostic functionality such as status information and audit trails may continue to be available following the stoppage of processing activities. The user may have access to utilities to recover the device to an operative state. Additionally, the tamper-detection and response mechanisms must result in the automatic and immediate erasure of any sensitive data that may be stored in the device, such that …
Modified
p. 6 → 10
“Immediate” is defined as fast enough to ensure that erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.
“Immediate” is defined as fast enough to ensure that erasure occurs before the tamper-detection mechanisms can be disabled using attack methods described in A1.
Modified
p. 6 → 10
For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information”.
For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information.” “Secret information” is any private or secret cryptographic keys or passwords that the device relies on to maintain security characteristics governed by PCI requirements. If any of this secret information is not zeroized, other mechanisms must exist to disable the device.
Modified
p. 6 → 11
Secret or private cryptographic keys that are never used to encrypt or decrypt data; or are not used for authentication, do not need to be considered secret data, and therefore do not need to be erased.
Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered secret data and therefore do not need to be erased•for example, where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.
Modified
p. 6 → 11
TA1.1 The tester shall inspect the tamper-detect mechanism to verify the assertions provided by the vendor in response to Section A1.1 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the tamper-detection mechanism.
TA1.1 The tester shall visually inspect the tamper-detection mechanism to verify the assertions provided by the vendor in response to Section A1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A1 of the PCI PTS HSM Modular Security Requirements for consistency relating to the tamper-detection mechanism. The vendor responses should clearly indicate how tamper-detection mechanisms are effective and robust. The tester shall summarize the responses.
Modified
p. 6 → 11
TA1.2 The tester shall examine additional relevant documentation submitted by the vendor, such as schematics and assembly drawings, to verify that it supports the vendor responses.
TA1.2 The tester shall examine and cite any additional relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses.
Removed
p. 7
TA1.5 If a cover is part of the tamper detection mechanism, the tester shall verify that attempts to remove the cover by removing fasteners, plates, connectors, etc., or by creating a gap between the covers or cover and housing do not allow access to probe critical security circuitry without triggering the tamper-detection mechanisms.
Modified
p. 7 → 11
TA1.5 The tester shall verify that attempts to probe critical security circuitry through any means other than opening the case (such as through vents, fans, or holes) do not allow probing access without triggering the tamper-detection mechanisms.
Modified
p. 7 → 12
If the device is restricted to deployment in Controlled Environments, the following applies: To remove the cover, the tester may open, pry, or disassemble the HSM at cover seams and remove other plates, connectors, etc., to gain access to the tamper-detection mechanisms. Removing shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure. The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover.
If the device is restricted to deployment in controlled environments, the following applies: To remove the cover, the tester may open, pry, or disassemble the device at cover seams and remove other plates, connectors, etc., to gain access to the tamper-detection mechanisms. Removing shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure. The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover.
Modified
p. 7 → 12
TA1.8 The tester shall examine the response to Section A1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to response of the device to tamper detection for consistency with device functionality and documentation, including the key table in the vendor security policy. Any sensitive information that is not erased must be encrypted using accepted algorithms and key sizes according to the table presented in Appendix D.
Modified
p. 7 → 12
TA1.9 The tester shall examine vendor-supplied documentation to determine whether the device employs active or passive (i.e., removal of power) erasure. If the device employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the device and stopping erasure before it is effective. The tester may create an attack scenario, which may be performed in its entirety or in part to verify the theory.
Modified
p. 7 → 12
TA1.10 The tester shall examine any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, to verify that it supports the vendor responses.
Modified
p. 8 → 15
If the device is restricted to deployment in Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Removed
p. 9
In general, techniques may include any combination of tamper-detection methods. Security mechanisms must not rely on insecure services or characteristics provided by the HSM, such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods involving tamper evidence are not considered a security mechanism.
Tamper stickers may be used to provide tamper evidence if the security policy describes inspection procedures that must be performed periodically.
This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.
If the HSM relies on strength of the enclosure as part of its tamper prevention measures, the enclosure is strong such that attempts to penetrate the enclosure will have a high probability of causing serious damage to the module.
The visual protection of sensitive components provided by the vendor in response to the HSM Evaluation Vendor Questionnaire is consistent.
The HSM enclosure is visibly opaque …
Tamper stickers may be used to provide tamper evidence if the security policy describes inspection procedures that must be performed periodically.
This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.
If the HSM relies on strength of the enclosure as part of its tamper prevention measures, the enclosure is strong such that attempts to penetrate the enclosure will have a high probability of causing serious damage to the module.
The visual protection of sensitive components provided by the vendor in response to the HSM Evaluation Vendor Questionnaire is consistent.
The HSM enclosure is visibly opaque …
Removed
p. 10
Areas of the HSM that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms. Areas where plaintext sensitive information is only present when a human operator is present may be protected solely by tamper evidence mechanisms if the vendor documentation describes an inspection process that must be performed prior to entering sensitive information.
“Immediate” is defined as fast enough to ensure that erasure occurs before tamper- detection mechanisms can be disabled.
Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered sensitive data and therefore do not need to be erased e.g., where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.
TA3.1 The tester shall examine the response to Section A2 of the PCI …
“Immediate” is defined as fast enough to ensure that erasure occurs before tamper- detection mechanisms can be disabled.
Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered sensitive data and therefore do not need to be erased e.g., where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.
TA3.1 The tester shall examine the response to Section A2 of the PCI …
Modified
p. 10 → 14
TA1.27 The tester shall describe how the device responds to a tamper-detection event.
Removed
p. 11
TA3.8 The tester shall examine vendor-supplied documentation to determine whether the components employ active or passive (i.e., removal of power) erasure. If the components employ passive erasure, the tester shall verify that it occurs rapidly enough to prevent an attacker from opening the device and stopping erasure before it is effective. The tester may create an attack scenario which may be performed all or in part to verify the theory.
TA4.3 The tester shall verify that the vendor’s stated measures protect against the compromise of the HSM by altering either environmental conditions or operational conditions, and assess the adequateness of the vendor test procedures and reports.
TA4.3 The tester shall verify that the vendor’s stated measures protect against the compromise of the HSM by altering either environmental conditions or operational conditions, and assess the adequateness of the vendor test procedures and reports.
Modified
p. 12 → 18
In order to minimize the destructive testing required, the tester may use the following to generate the assessment: review test results provided by the vendor, utilize subsections of the module for destructive testing (e.g. an epoxy sample), or analyze individual components apart from the HSM.
In order to minimize the destructive testing required, the tester may use the following to generate the assessment: review test results provided by the vendor, utilize subsections of the module for destructive testing (e.g., an epoxy sample), or analyze individual components apart from the device.
Modified
p. 12 → 18
TA2.1 The tester shall examine the response to Section A2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A2 of the PCI PTS HSM Modular Security Requirements for consistency relevant to Requirement A2. The vendor responses should clearly state that the security of the device is not compromised by altering environmental conditions or operational conditions. The tester shall summarize the responses.
Modified
p. 12 → 18
TA2.2 The tester shall examine any additional relevant documentation submitted by the vendor
•such as schematics, data sheets, vendor test procedures, and test reports
•to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions. If the device utilizes sensors that will trigger a tamper response, the tester shall verify the ranges of the sensors via vendor supplied design documentation. Such information must be clearly referenced.
•such as schematics, data sheets, vendor test procedures, and test reports
•to verify that it supports vendor responses. This may include data provided to support Requirement B2 under different environmental conditions. If the device utilizes sensors that will trigger a tamper response, the tester shall verify the ranges of the sensors via vendor supplied design documentation. Such information must be clearly referenced.
Modified
p. 12 → 19
TA2.10 The tester shall develop attack scenarios to compromise the device by altering operational conditions, and consider whether altering environmental conditions may be used to develop attacks.
Modified
p. 12 → 19
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
TA2.11 The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, for demonstrating compliance to this DTR.
Removed
p. 13
TA5.4 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms dealing with sensitive information and functions, using attack scenarios with an attack potential of < 26 per HSM for identification and initial exploitation, or <13 for initial exploitation, as defined in Appendix A.
Modified
p. 13 → 20
The protected area of the device is that area(s) within the boundaries of the tamper- detection and response mechanisms.
The protected area of the device is that area(s) within the boundaries of the tamper-detection and response mechanisms.
Modified
p. 13 → 20
TA3.1 The tester shall examine the response to Section A3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI PTS HSM Modular Security Requirements manual for consistency relevant to Requirement A3. The vendor responses should clearly indicate what sensitive information and functions exists; that sensitive functions or information are only used in the protected area(s) of the device; and that sensitive information and functions dealing with sensitive information are protected from …
Modified
p. 13 → 20
TA3.3 The tester shall verify the completeness of the information regarding sensitive information and functions presented by the vendor.
Modified
p. 13 → 22
If the device is restricted to deployment in Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Modified
p. 13 → 22
The tester may perform any test needed to validate the attack scenario. The tester will use his or her own judgment in determining the appropriate tests and whether the attack will be performed in its entirety or in part to verify the theory.
The tester may perform any test needed to validate the attack scenario.
Modified
p. 13 → 25
TA5.2 The tester shall examine any additional relevant documentation submitted by the vendor, such as assembly drawings and functional specifications, to verify that it supports the vendor responses.
TA5.2 The tester shall examine and cite any relevant documentation, such as assembly drawings or test data, submitted by the vendor to verify that it supports the vendor responses.
Removed
p. 14
TA6.3 The tester shall visually inspect the HSM to verify the assertions provided by the vendor in the PCI PTS HSM Evaluation Vendor Questionnaire relating to protections against the monitoring of electro-magnetic emissions, power consumption, or any other internal or external characteristic available for monitoring. This could include verifying that any components that provide protection are as stated by the vendor.
Modified
p. 14 → 23
If the device is restricted to deployment in Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Modified
p. 14 → 23
TA4.2 The tester shall examine and cite any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS HSM Modular Evaluation Vendor Questionnaire.
Modified
p. 14 → 23
TA4.5 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of electro-magnetic emissions, power consumption, or any other internal or external characteristic available for monitoring, using attack scenarios. If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix A, the vendor assertion cannot be verified. At least …
Modified
p. 14 → 25
TA5.1 The tester shall examine the vendor’s response to Section A5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to A5. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any PCI- security-related cryptographic key resident in the device. The tester shall summarize the responses.
Removed
p. 15
The vendor may need to supply specific test software to the evaluation laboratory to enable rigorous side channel attack analysis to be performed.
TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS HSM Security Requirements for consistency relevant to A7.
TA7.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, test data, etc., to verify that it supports the vendor responses.
TA7.3 The tester shall develop attack scenarios to determine any PCI HSM-related cryptographic key resident in the device, either by penetration or by monitoring emanations from the device. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. The calculation shall be based on the scheme depicted in Appendix A. If an attack scenario …
TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS HSM Security Requirements for consistency relevant to A7.
TA7.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, test data, etc., to verify that it supports the vendor responses.
TA7.3 The tester shall develop attack scenarios to determine any PCI HSM-related cryptographic key resident in the device, either by penetration or by monitoring emanations from the device. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. The calculation shall be based on the scheme depicted in Appendix A. If an attack scenario …
Modified
p. 15 → 25
Keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix C, they do not need to be considered. For purposes of this requirement, this includes transaction or other security-relevant keys that are only temporarily in the device and are not stored in the device.
Keys resident in the device or its components means plaintext secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key- encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered. For purposes of this requirement, this includes transaction or other security-relevant keys that are only temporarily in the device and are not stored in the device.
Modified
p. 15 → 27
If the device is restricted to deployment in Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Modified
p. 16 → 28
Firmware is considered to be any code within the HSM that provides security protections needed to comply with these requirements. In certain instances, the test houses may request copies of source code for review of specific functions.
Firmware is considered to be any code within the device that provides security protections needed to comply with these requirements. In certain instances, the test houses may request copies of source code for review of specific functions.
Modified
p. 16 → 28
Failing in a secure manner involves at least disabling any functionality of the device related to PIN handling and processing, including PIN entry and PIN encryption. More specifically, no sensitive data breach can occur as a consequence of device failure.
Failing in a secure manner involves at least disabling any functionality of the device related to processing sensitive data. More specifically, no sensitive data breach can occur as a consequence of device failure.
Modified
p. 16 → 29
• A periodic integrity check according to Requirement B1 is performed for the firmware, ensuring that random changes will be detected; and if cryptographic authenticity is not performed, the integrity check must be cryptographically based. Although an algorithm using a secret key, such as a keyed hash, can be used, it is not necessary for meeting the integrity criteria.
Modified
p. 16 → 29
When firmware is externally authenticated, the level of security shall be of the same level as for key-injection facilities.
When firmware is externally authenticated, the level of security shall be of the same level as for key- injection facilities.
Removed
p. 17
TB1.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses, including evidence of testing that confirms the relevant component fails securely in the event of self-test failure.
Modified
p. 17 → 29
TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS HSM Security Requirements to verify that the device performs a self-test upon start-up and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised state; and that in …
TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device performs a self-test upon startup and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised …
Modified
p. 17 → 29
TB1.4 The tester shall verify that the device performs self-tests upon startup and on a periodic basis at least once per day to check firmware and security mechanisms for signs of tampering, and whether the device is in a compromised state. The tester shall activate the self-test(s) and look for the result of the self-test(s) as shown by the device.
Modified
p. 17 → 29
TB1.5 The tester shall verify that the device self-tests are able to detect failures and in doing so, fail in a secure manner. The vendor shall provide evidence of testing that confirms the relevant component fails securely in the event of self-test failure.
Modified
p. 17 → 30
TB1.13 The tester shall verify that the device performs the following power up self-tests:
Modified
p. 17 → 31
If a cryptographic module includes two independent implementations of the same cryptographic algorithm, then:
• If the outputs of two implementations are not equal, the cryptographic algorithm test shall fail.
Modified
p. 18 → 31
TB1.14 The tester shall induce the power up self-tests and, if applicable, view any status provided by the device to verify that self-tests executed successfully.
Modified
p. 18 → 31
TB1.15 The tester shall verify that the device automatically performs the following continuous or periodic self-tests:
Modified
p. 18 → 31
e) Other self-tests that are performed at power-up and on demand TB1.8 If applicable, the tester shall induce the periodic self-tests and, if applicable, view any status.
e) Other self-tests that are performed at power-up and on demand TB1.16 If applicable, the tester shall induce the periodic self-tests and, if applicable, view any status.
Modified
p. 18 → 31
TB1.17 The tester shall verify that the device performs the following conditional self-tests where applicable, when the conditions specified exists:
Modified
p. 18 → 31
a) Pairwise consistency tests If a cryptographic module generates public or private keys, the following pair- wise consistency tests for every pair of generated public and private keys shall be performed:
a) Pairwise consistency tests If a cryptographic module generates public or private keys, the following pair-wise consistency tests for every pair of generated public and private keys shall be performed:
Modified
p. 18 → 31
• If the keys are used to perform key transport, the public key shall encrypt a plaintext value. The resulting ciphertext value shall be compared to the original plaintext value. If the two values are equal, the test shall fail. If the two values differ, the private key shall be used to decrypt the ciphertext and the resulting value shall be compared to the original plaintext value. If the two values are not equal, the test shall fail.
Modified
p. 19 → 32
• If the keys are used to perform key agreement, the arithmetic validity of the keys shall be tested by verifying the correct mathematical relationship between the public key and private key values.
Modified
p. 19 → 32
• The cryptographic key or key components shall have an error-detection code (EDC) applied, or shall be entered using duplicate entries.
Modified
p. 19 → 32
• If an EDC is used, the EDC shall be at least 16 bits in length.
Modified
p. 19 → 32
• If the EDC cannot be verified, or the duplicate entries do not match, the test shall fail.
Modified
p. 19 → 32
• An approved authentication technique (e.g., an approved message authentication code, digital signature algorithm, or HMAC) shall be applied to all validated software and firmware components when the components are externally loaded into a cryptographic module.
Modified
p. 19 → 32
• The calculated result shall be compared with a previously generated result. If the calculated result does not equal the previously generated result, the software/firmware load test shall fail.
Modified
p. 19 → 32
• If each call to an RNG produces blocks of n bits (where n > 15), the first n-bit block generated after power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit block to be generated. Each subsequent generation of an n-bit block shall be compared with the previously generated block. The test shall fail if any two compared n-bit blocks are equal.
Modified
p. 19 → 32
• If each call to an RNG produces fewer than 16 bits, the first n bits generated after power-up, initialization, or reset (for some n > 15) shall not be used, but shall be saved for comparison with the next n generated bits. Each subsequent generation of n bits shall be compared with the previously generated n bits. The test fails if any two compared n-bit sequences are equal.
Modified
p. 20 → 33
e) Bypass test If a cryptographic module implements a bypass capability where the services may be provided without cryptographic processing (e.g., transferring plaintext through the module), then the following bypass tests shall be performed to ensure that a single point of failure of module components will not result in the unintentional output of plaintext:
e) Bypass test If a cryptographic module implements a bypass capability where the services may be provided without cryptographic processing (e.g., transferring plaintext through the module), the following bypass tests shall be performed to ensure that a single point of failure of module components will not result in the unintentional output of plaintext:
Modified
p. 20 → 33
• A cryptographic module shall test for the correct operation of the services providing cryptographic processing when a switch takes place between an exclusive bypass service and an exclusive cryptographic service.
Modified
p. 20 → 33
• If a cryptographic module can automatically alternate between a bypass service and a cryptographic service, providing some services with cryptographic processing and some services without cryptographic processing, the module shall test for the correct operation of the services providing cryptographic processing when the mechanism governing the switching procedure is modified (e.g., an IP address source/destination table).
Modified
p. 20 → 33
• Documentation shall specify the mechanism or logic governing the switching procedure.
Modified
p. 20 → 33
TB1.18 The tester shall induce the conditional self-tests and, if applicable, view any status provided by the device to verify that self-tests executed successfully.
Removed
p. 21
TB2.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the HSM’s logical structure, the HSM interface specification, the software design rules and specifications, or the software implementation, to verify that it supports the vendor responses.
Modified
p. 21 → 34
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of the HSM.
Functionality shall be considered as any functionality, via any internal or external interface, that could impact the security of the device.
Modified
p. 21 → 34
TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS HSM Security Requirements to verify that the HSM’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data.
TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the relevant component’s functionality shall not be influenced by logical anomalies such as (but not restricted to): unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying invalid parameters or data that could result in the relevant component’s …
Modified
p. 21 → 34
TB2.3 The tester shall analyze the vendor’s measures that ensure that the HSM’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
TB2.3 The tester shall describe the vendor’s measures that ensure that the device’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified
p. 21 → 35
TB2.14 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.
Modified
p. 22 → 36
Firmware is considered to be any code within the HSM that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Modified
p. 22 → 36
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the firmware documentation and certification process, for consistency.
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS HSM Modular Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
Modified
p. 22 → 36
TB3.2 The tester shall examine the support documentation submitted by the HSM vendor. The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.
TB3.2 The tester shall examine the support documentation submitted by the device vendor. The documents should be representative of configuration control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable configuration control procedure.
Modified
p. 22 → 36
TB3.4 The tester will verify that the device displays or otherwise makes available the firmware revision number.
TB3.4 The tester shall verify and demonstrate that the device displays or otherwise makes available the firmware revision number or numbers when firmware has different numbering for different modules.
Removed
p. 23
TB4.3 The tester shall verify that the HSM cryptographically authenticates the firmware integrity. This will be accomplished, for example, by performing a simulated firmware update.
TB4.4 The tester shall verify that the HSM rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
TB4.4 The tester shall verify that the HSM rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.
Modified
p. 23 → 39
Firmware is considered to be any code within the HSM that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
Modified
p. 23 → 39
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the authentication procedures for remote firmware updates, for consistency.
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI PTS HSM Modular Security Requirements for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
Modified
p. 23 → 39
TB4.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.
TB4.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.
Modified
p. 23 → 39
TB4.5 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix C.
TB4.5 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Modified
p. 23 → 39
Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA- 512. MD5 and SHA-1 are not allowed for use.
Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA-512. MD5 and SHA-1 are not allowed for use.
Removed
p. 24
TB5.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the logical interfaces to determine whether it supports the assertions made by the vendor. Documentation should indicate that the device is designed to distinguish between commands and data input, and status and data output.
Modified
p. 24 → 43
The HSM shall provide for the following four logical interfaces:
The device shall provide for the following four logical interfaces:
Modified
p. 24 → 43
• All data (except control data entered via the control input interface) that is input to and processed by a cryptographic module (including plaintext data, ciphertext data, cryptographic keys and CSPs, authentication data, and status information from another module) shall enter via the "data input" interface.
• All data (except control data entered via the control input interface) that is input to and processed by a cryptographic module (including plaintext data, ciphertext data, cryptographic keys and CSPs, authentication data, and status information from another module) shall enter via the "data input" interface.
Modified
p. 24 → 43
• All data (except status data output via the status output interface) that is output from a cryptographic module (including plaintext data, ciphertext data, cryptographic keys and CSPs, authentication data, and control information for another module) shall exit via the "data output" interface. All data output via the data output interface shall be inhibited when an error state exists and during self-tests.
• All data (except status data output via the status output interface) that is output from a cryptographic module (including plaintext data, ciphertext data, cryptographic keys and CSPs, authentication data, and control information for another module) shall exit via the "data output" interface. All data output via the data output interface shall be inhibited when an error state exists and during self-tests.
Modified
p. 24 → 43
• All input commands, signals, and control data (including function calls and manual controls such as switches, buttons, and keyboards) used to control the operation of a cryptographic module shall enter via the "control input" interface.
• All input commands, signals, and control data (including function calls and manual controls such as switches, buttons, and keyboards) used to control the operation of a cryptographic module shall enter via the "control input" interface.
Modified
p. 24 → 43
• All output signals, indicators, and status data (including return codes and physical indicators such as Light Emitting Diodes and displays) used to indicate the status of a cryptographic module shall exit via the "status output" interface.
• All output signals, indicators, and status data (including return codes and physical indicators such as Light Emitting Diodes and displays) used to indicate the status of a cryptographic module shall exit via the "status output" interface.
Modified
p. 24 → 43
TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI PTS HSM Security Requirements manual for consistency.
TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device provides secure interfaces that are kept logically separate. The tester shall summarize the responses TB5.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the logical interfaces to verify that …
Modified
p. 24 → 43
TB5.3 The tester shall review vendor documentation to verify that the HSM distinguishes between data and control for inputs and also between data and status for outputs. To provide evidence that the HSM distinguishes between commands and data inputs, the tester shall verify that the HSM responds with error messages or ignores inputs when erroneous commands and data are input.
TB5.3 The tester shall review vendor documentation to verify that the device distinguishes between data and control for inputs and also between data and status for outputs. To provide evidence that the device distinguishes between commands and data inputs, the tester shall verify that the device responds with error messages or ignores inputs when erroneous commands and data are input.
Removed
p. 25
The transaction is completed, or The HSM has timed out or The HSM recovers from an error state.
TB6.4 The tester will verify that all sensitive data is automatically cleared prior to reuse of the buffer, including when the transaction is completed, the HSM has timed out, or the HSM recovers from an error state. The tester will determine the appropriate test actions to be taken.
TB6.4 The tester will verify that all sensitive data is automatically cleared prior to reuse of the buffer, including when the transaction is completed, the HSM has timed out, or the HSM recovers from an error state. The tester will determine the appropriate test actions to be taken.
Modified
p. 25 → 44
This applies to sensitive data, such as passwords, plaintext cryptographic keys outside of the crypto-processor, and clear PIN values.
This applies to sensitive data, such as passwords, plaintext cryptographic keys outside of the crypto- processor, and clear PIN values.
Modified
p. 25 → 44
TB6.1 The tester shall examine the vendor’s response to Section B6 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI PTS HSM Security Requirements to verify:
TB6.1 The tester shall examine the vendor’s response to Section B6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI PTS HSM Modular Security Requirements to verify:
Modified
p. 25 → 44
• That sensitive information shall not be present any longer or used more often than strictly necessary; and
Modified
p. 25 → 44
TB6.2 The tester shall examine any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation, to verify that it supports the vendor responses.
TB6.2 The tester shall examine and cite any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation, to verify that it supports the vendor responses.
Modified
p. 25 → 44
TB6.3 The tester will verify that the vendor has identified all data that is automatically cleared prior to reuse of the buffer, including when the transaction is completed, the HSM has timed out, or the HSM recovers from an error state, and that all sensitive data is included. Passwords, plaintext cryptographic keys, and PIN values are considered sensitive data.
TB6.3 The tester will verify that and summarize how the vendor has identified all data that is automatically cleared prior to reuse of the buffer, including when the transaction is completed, the device has timed out, or the device recovers from an error state, and that all sensitive data is included. Passwords, plaintext cryptographic keys, key components outside of the crypto- processor, and PIN values are considered sensitive data.
Removed
p. 26
PINs or passwords used for authentication are at least five characters in length.
TB7.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes dual control procedures to determine whether it supports the assertions made by the vendor.
TB7.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes dual control procedures to determine whether it supports the assertions made by the vendor.
Modified
p. 26 → 46
Authentication shall use dual-control techniques when manually entering unprotected sensitive information into the HSM through a secure user interface, or cryptographic techniques when electronically transferring protected data into the HSM. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. The HSM requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as plaintext or split knowledge of manual CSP loading or …
Authentication shall use dual-control techniques when manually entering unprotected sensitive information into the device through a secure user interface, or cryptographic techniques when electronically transferring protected data into the device. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. The device requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as plaintext or split knowledge of manual CSP loading or …
Modified
p. 26 → 46
A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc. The authority to execute functions that are not available during normal use is controlled through use of a sensitive state or other special authorization that controls the ability to execute these functions. Services not normally available may include CSP loading, CSP output, enabling or disabling HSM security functions, or the modification of authentication …
A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc. The authority to execute functions that are not available during normal use is controlled through use of a sensitive state or other special authorization that controls the ability to execute these functions. Services not normally available may include CSP loading, CSP output, enabling or disabling device security functions, or the modification of authentication …
Modified
p. 26 → 47
• Changing of passwords or data that enable the device to enter a sensitive state;
Modified
p. 26 → 47
TB7.1 The tester shall examine the vendor’s response to Section B7 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI PTS HSM Security Requirements for consistency.
TB7.1 The tester shall examine the vendor’s response to Section B7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B7. The vendor responses should clearly indicate how sensitive services are protected. The tester shall summarize the responses.
Modified
p. 27 → 47
TB7.8 The tester shall attempt to perform any other services listed in this section and verify that each service requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as plaintext or split knowledge of manual CSP loading or CSP output, enabling or disabling HSM security functions, or the modification of authentication data.
TB7.8 The tester shall attempt to perform any other services listed in this section and verify that each service requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as plaintext or split knowledge of manual CSP loading or CSP output, enabling or disabling device security functions, or the modification of authentication data.
Modified
p. 27 → 47
TB7.10 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes authentication procedures for the manual entry or output of enciphered CSPs to determine whether it supports the assertions made by the vendor.
Modified
p. 27 → 47
TB7.11 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes sensitive service limits to determine whether it supports the assertions made by the vendor.
Modified
p. 27 → 48
TB7.13 The tester shall verify the vendor responses to Section B7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and other documentation are consistent and provide sound rationale for the service limits set by the vendor.
Modified
p. 27 → 48
• The vendor has provided a rationale for the value chosen as a limit on the number of actions and the time limits imposed.
Modified
p. 27 → 48
• The vendor has provided a rationale as to how the limits minimize the risks from unauthorized use of sensitive services.
Modified
p. 27 → 48
TB7.14 If access to sensitive services requires input by a secure user interface, the tester shall verify that the protections such as the following are afforded to the data entered while accessing sensitive services:
Modified
p. 27 → 48
• Data inputs cannot be discerned from any displayed characters.
Modified
p. 28 → 48
• Sensitive data is cleared from internal buffers upon exiting the sensitive mode.
Modified
p. 28 → 48
• Entering data while accessing sensitive services.
Modified
p. 28 → 48
TB7.15 If mode transitions require input by a separate interface device, such as a key loader or other vendor-supplied interface device, document the mechanism(s) and methodology used.
Modified
p. 29 → 50
Key Form Manual Direct Network Plaintext keys No Yes No Plaintext key components Yes Yes No Enciphered keys Yes Yes Yes
Key Form Manual Direct Network Plaintext keys No Yes No Plaintext key components Yes Yes No Enciphered keys/components Yes Yes Yes
Modified
p. 29 → 50
c) Network distribution and loading (e.g., remote key transport via a network), including remote key loading using asymmetric techniques Keys loaded using any other mechanism can only be loaded enciphered.
c) Network distribution and loading (e.g., remote key transport via a network), including remote key loading using asymmetric techniques.
Modified
p. 29 → 50
External SCDs (secure key loaders or other interface devices) used for loading plaintext secret or private keys or their components must either be approved against the PCI PTS HSM Security Requirements or be compliant to the requirements for devices with key- transfer and loading functionality as described in ISO 13491-2. The vendor must either provide or describe a specific, existing device that can be used for this functionality.
External SCDs (secure key loaders or other interface devices) used for loading plaintext secret or private keys or their components must either be approved against the PCI PTS HSM Modular Security Requirements or be compliant to the requirements for devices with key-transfer and loading functionality as described in ISO 13491-2. The vendor must either provide or describe a specific, existing device that can be used for this functionality.
Modified
p. 29 → 50
TB8.1 The tester shall examine the vendor’s response to Section B8 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI PTS HSM Security Requirements for consistency relevant to B8.
TB8.1 The tester shall examine the vendor’s response to Section B8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B8. The vendor responses should clearly indicate how key entry is performed using accepted techniques. The tester shall summarize the responses.
Modified
p. 29 → 50
TB8.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the entry of key components to determine whether it supports the assertions made by the vendor.
TB8.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor that describes the entry of keying material to verify that it supports the assertions made by the vendor.
Modified
p. 29 → 51
• Any plaintext keys entered uses direct techniques.
Modified
p. 29 → 51
• Any plaintext keys are directly entered without traveling through any enclosing or intervening systems.
Modified
p. 30 → 51
Plaintext key entry requires dual authentication OR zeroization of pre-existing secret keys within the associated key hierarchy prior to loading of the new key.
Modified
p. 30 → 51
TB8.4 The tester shall verify that the HSM does not allow entry of plaintext keys using manual or network techniques.
TB8.4 The tester shall verify that the device does not allow entry of plaintext keys using manual or network techniques.
Modified
p. 30 → 51
TB8.5 The tester shall verify that an audit log is kept by the HSM and/or the device used to perform the electronic key loading; additionally, it is procedurally specified in the vendor security policy where necessary to track actions to the specific individuals involved (i.e., automated authentication mechanisms are role based and not identity- based). In either case, the electronic log must implement cryptographic mechanisms as specified in B16. The audit log must be able to be used to track …
TB8.5 The tester shall verify that an audit log is kept by the device and/or the device used to perform the electronic key loading; additionally, it is procedurally specified in the vendor security policy where necessary to track actions to the specific individuals involved (i.e., automated authentication mechanisms are role based and not identity-based). In either case, the electronic log must implement cryptographic mechanisms as specified in B16. The audit log must be able to be used to track the …
Modified
p. 30 → 51
• Key components are directly entered without traveling through enclosing or intervening systems or a directly connected SCD is used as key loader.
Modified
p. 30 → 51
• A minimum of two components is required to reconstruct the original key.
Modified
p. 30 → 51
• If knowledge of n components is required to reconstruct the key, knowledge of any n-1 components provides no information about the original key other than the length.
Modified
p. 30 → 51
• Plaintext key-component entry requires the use of dual-control techniques, such that the key is entered as separate key components by the assigned key custodians. Each component requires the use of a separate PIN/password to authenticate the individual entering that specific component OR the zeroization of pre-existing secret keys within the associated key hierarchy prior to the loading of the new key•i.e., the invoking of the key- loading function/command causes the zeroization prior to the actual loading of the new …
Modified
p. 30 → 51
TB8.7 The tester shall verify that the HSM does not allow entry of plaintext key components using network techniques.
TB8.7 The tester shall verify that the device does not allow entry of plaintext key components using network techniques.
Modified
p. 30 → 51
TB8.8 The tester shall verify that an audit log is kept by the HSM, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. The audit log must be able to be used to track the individuals who perform plaintext key component entry.
TB8.8 The tester shall verify that an audit log is kept by the device, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. The audit log must be able to be used to track the individuals who perform plaintext key component entry.
Modified
p. 31 → 52
TB8.9 The tester shall verify that any enciphered key input or output from the HSM is enciphered using an acceptable cryptographic algorithm and key size. KEKs must be at least as strong as the keys they protect.
TB8.9 The tester shall verify that any enciphered key or key component input or output from the device is enciphered using an acceptable cryptographic algorithm and key size. KEKs must be at least as strong as the keys they protect.
Modified
p. 31 → 52
Examples of appropriate algorithms and minimum key sizes are stated in Appendix C.
Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Modified
p. 31 → 52
TB8.10 The tester shall verify that an audit log is kept by the HSM, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. Enforce the keeping of an audit log that can be used to track the individuals who perform enciphered key entry.
TB8.10 The tester shall verify that an audit log is kept by the device, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. Enforce the keeping of an audit log that can be used to track the individuals who perform enciphered key entry.
Removed
p. 32
TB9.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes each implemented RNG(s) and/or PRNG(s) to determine whether it supports the assertions made by the vendor.
TB9.3 The tester shall examine data output from all implemented RNGs and PRNGs to verify that they are capable of passing accepted statistical tests for randomness. The tester shall use a suitable test method (for example, those listed in NIST 800-22). See Appendix B.
TB9.5 The tester shall examine the design specification of the RNG and determine how the RNG is used to protect or produce sensitive data.
TB9.6 The tester shall document in the report the overall design of the random number generator, its randomness sources, and its usage on the device.
TB9.3 The tester shall examine data output from all implemented RNGs and PRNGs to verify that they are capable of passing accepted statistical tests for randomness. The tester shall use a suitable test method (for example, those listed in NIST 800-22). See Appendix B.
TB9.5 The tester shall examine the design specification of the RNG and determine how the RNG is used to protect or produce sensitive data.
TB9.6 The tester shall document in the report the overall design of the random number generator, its randomness sources, and its usage on the device.
Modified
p. 32 → 53
Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the random number generator at start-up cannot be abused to intentionally reproduce a given random value or sequence.
Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the random number generator at startup cannot be abused to intentionally reproduce a given random value or sequence.
Modified
p. 32 → 53
Source code may be required to validate this requirement.
Source code will be required to validate this requirement.
Modified
p. 32 → 53
TB9.1 The tester shall examine the vendor’s response to Section B9 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI PTS HSM Security Requirements for consistency.
TB9.1 The tester shall examine the vendor’s response to Section B9 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B9. The vendor responses should clearly indicate why random number generation is robust. The tester shall summarize the responses.
Modified
p. 32 → 54
The tester shall ensure that initializing and/or seeding of the RNG cannot be abused to intentionally reproduce a given random value or sequence.
Modified
p. 33 → 55
All PCI related algorithms used must be implemented in accordance with standards referenced in the PCI PTS HSM Security Requirements and the PCI PTS Testing and Approval Program Guide.
All PCI related algorithms used must be implemented in accordance with standards referenced in the PCI PTS HSM Modular Security Requirements and the PCI PTS Testing and Approval Program Guide.
Modified
p. 33 → 55
TB10.1 The tester shall examine the response to Section B10 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS HSM Security Requirements manual for consistency.
TB10.1 The tester shall examine the vendor’s response to Section B10 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B10. The vendor responses should clearly indicate the use of accepted cryptographic algorithms, modes, and key sizes. The tester shall summarize the responses.
Modified
p. 33 → 55
• All security protocols Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Modified
p. 33 → 55
Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA- 512. MD5 and SHA-1 are not allowed for use for protocols impacting the HSM’s security, such as firmware updates.
Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA-512. MD5 and SHA-1 are not allowed for use for protocols impacting the device’s security, such as firmware updates.
Modified
p. 34 → 56
TB10.5 The tester shall verify that the mechanism used has been implemented following all guidelines of any security evaluation and independent expert review including any recommendations for associated key management.
TB10.5 The tester shall verify that the mechanism used has been implemented following all guidelines of any security evaluation and independent expert review including any recommendations for associated key management and configuration of the mode of operation.
Modified
p. 34 → 56
TB10.6 For each of the accepted cryptographic algorithms implemented within the HSM, the tester shall verify the correct implementation of the algorithms through any of the following means:
TB10.6 For each of the accepted cryptographic algorithms implemented within the device, the tester shall verify the correct implementation of the algorithms through any of the following means:
Removed
p. 35
Be secret; Be generated randomly or pseudo-randomly; Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source; Be used in the appropriate order as specified by the particular mode; Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and Cannot be unbundled for any purpose.
The device must support use of the TR-31 Key Derivation Binding Method or an equivalent key-bundling methodology. The device may optionally support, in addition, the TR-31 Key Variant Binding Method or an equivalent.
The device must support use of the TR-31 Key Derivation Binding Method or an equivalent key-bundling methodology. The device may optionally support, in addition, the TR-31 Key Variant Binding Method or an equivalent.
Modified
p. 35 → 57
The device must provide support for Master File Keys, whether loaded from components or internally generated, that are equivalent to or greater in strength than triple length TDES keys. The device may optionally provide support for backwards compatibility for double length TDES Master File Keys An HSM may include other key-management schemes not specified below, such as country-specific techniques when operating in PCI mode, as long as their use cannot in any way compromise the security of the PCI-compliant methods. …
The device must provide support for Master File Keys, whether loaded from components or internally generated, that are equivalent to or greater in strength than triple-length TDES keys. The device may optionally provide support for backwards compatibility for double-length TDES Master File Keys.
Modified
p. 35 → 57
A HSM may include more than one compliant key exchange and storage scheme.
A device may include more than one compliant key exchange and storage scheme.
Removed
p. 36
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods, including the use of algorithms and key sizes stipulated in Appendix C. Any binding or unbinding of key-usage information from the key must take place within the secure cryptographic boundary of the device.
TB11.5 The tester shall determine from vendor documentation that the device provides support for a configuration option using TR-31 or an equivalent key-bundling methodology for symmetric key distribution and, optionally, key storage. The tester shall determine that the TR-31 or equivalent configuration uses a key derivation methodology. The device may optionally support, in addition, the key calculation methodology.
TB11.5 The tester shall determine from vendor documentation that the device provides support for a configuration option using TR-31 or an equivalent key-bundling methodology for symmetric key distribution and, optionally, key storage. The tester shall determine that the TR-31 or equivalent configuration uses a key derivation methodology. The device may optionally support, in addition, the key calculation methodology.
Modified
p. 36 → 58
• Loaded using asymmetric keys of equivalent or greater strength.
Modified
p. 36 → 58
• Encrypted by another AES key of equal or greater strength.
Modified
p. 36 → 58
• Manually loaded using dual-control techniques.
Modified
p. 36 → 58
• Internally generated using a random number generator compliant with B9.
Modified
p. 36 → 58
Devices are allowed to have keys that are not unique per device if these keys are used for load- balancing purposes.
Modified
p. 36 → 58
TB11.1 The tester shall examine the response to Section B11 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the method of key management in use in the HSM, for consistency.
TB11.1 The tester shall examine the response to Section B11 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B11 of the PCI PTS HSM Modular Security Requirements for consistency relating to the method of key management in use in the device. The tester shall summarize the responses.
Modified
p. 36 → 58
TB11.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide or the API programmer’s guide, to verify that it supports vendor responses.
TB11.2 The tester shall examine and cite any relevant documentation such as a user guide or the API programmer’s guide, submitted by the vendor to verify that it supports vendor responses.
Modified
p. 36 → 58
TB11.5 The tester shall verify that the loading of private and secret keys uses one or more of the following methods:
Modified
p. 37 → 59
b) For injecting plaintext secret or private keys from a key loader (which has to be some type of secure cryptographic device), either the key loader or the HSM or both must require two or more PINs/passwords before injecting the plaintext key into the HSM. (Note: This may be the entire key•if components, each component requires a separate password). These passwords are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must …
b) For injecting plaintext secret or private keys from a key loader (which has to be some type of secure cryptographic device), either the key loader or the device or both must require two or more PINs/passwords before injecting the plaintext key into the device. (Note: This may be the entire key•if components, each component requires a separate password). These passwords are entered directly through the secure interface of the applicable device or are conveyed encrypted into the device and …
Modified
p. 37 → 59
c) For encrypted values injected into the HSM, either from a key loader or from a network host, or via a secure interface device, the ability of the HSM to successfully decrypt the value and use it is sufficient. In this case, the key- encipherment key is trusted because it was previously loaded under dual control•e.g., in examples a) and b) above or using another secure and trusted method, e.g., loaded encrypted as part of a key hierarchy.
c) For encrypted values injected into the device, either from a key loader or from a network host, or via a secure interface device, the ability of the device to successfully decrypt the value and use it is sufficient. In this case, the key-encipherment key is trusted because it was previously loaded under dual control•e.g., in examples a) and b) above or using another secure and trusted method, e.g., loaded encrypted as part of a key hierarchy.
Modified
p. 37 → 59
TB11.6 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange or establishment are stated in Appendix D:
Modified
p. 37 → 59
If a public key technique for the distribution of symmetric secret keys is used, it must:
If a public key technique for the remote distribution of symmetric secret keys is used, it must:
Modified
p. 37 → 59
c) Provide for mutual device authentication as specified in Annex A of the PCI PIN Security Requirements for both the host and the HSM, including assurance to the host that the HSM actually has obtained or computed (or actually can compute) the key and that no other entity other than the HSM specifically identified can possibly compute the session key.
c) Provide for mutual device authentication as specified in Annex A of the PCI PIN Security Requirements for both the host and the device, including assurance to the host that the device actually has obtained or computed (or actually can compute) the key and that no other entity other than the device specifically identified can possibly compute the session key.
Removed
p. 38
TB11.9 The tester shall determine from vendor documentation the cryptographic keys present or ever used by the device and list the details in a key summary table. This does not include keys temporarily present in the device as part of transaction processing. An example of key types in such a table is:
Key Name Purpose/Usage Algorithm Size (Bits) Generated by:
TB11.11 The tester shall determine from vendor documentation how each key is destroyed (e.g., active or passive erasure) for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.
Key Name Purpose/Usage Algorithm Size (Bits) Generated by:
TB11.11 The tester shall determine from vendor documentation how each key is destroyed (e.g., active or passive erasure) for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.
Modified
p. 38 → 59
TB11.8 The tester shall determine from vendor documentation all storage and usage locations for each key (e.g., ROM, external RAM, EPROM, processor chip, etc.) that is stored within the device and list the details in a key summary table.
Modified
p. 38 → 60
Form Factor Loaded to Device In Number of Available Key Slots (Registers) Unique per device/acquirer/ vendor-specific/ other (describe) Master Key Encryption of working keys (PEK, MAC) for local storage TDES 128 Acquirer 2 or 3 plaintext components One Device Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 2048 Manufacturer Self-signed Public Key Certificate One Vendor-specific Manufacturer Authentication Private Root Private Key Signing firmware updates RSA 2048 Manufacturer Managed at manufacturer’s secure facility under dual control One Vendor-specific KDH …
Key Name Purpose/ Size (Bits) Form Factor Available Key Slots (Registers) Unique per device/ acquirer/ vendor- specific/ other (describe) How the key is identified by the device so that it is used only as Master Key Encryption of working keys (PEK, MAC) for local storage TDES 128 Acquirer 2 or 3 plaintext components One Device Designated Key Register Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 2048 Manufacturer Self-signed Public Key Certificate One Vendor- Designated Key Register Manufacturer …
Modified
p. 38 → 60
Note: Other keys may be loaded to the HSM as components (e.g., a terminal master key) or internally generated for external storage under the HSM’s Master File Key or a variant thereof. If internally stored, the tester shall note this in the summary table.
Note: Other keys may be loaded to the device as components (e.g., a terminal master key) or internally generated for external storage under the device’s Master File Key or a variant thereof. If internally stored, the tester shall note this in the summary table.
Modified
p. 39 → 63
Any unintentional or malicious modification (i.e. corruption) of cryptographic security parameters is detected and the HSM fails in a secure manner.
Any unintentional or malicious modification (i.e., corruption) of cryptographic security parameters is detected and the device fails in a secure manner.
Modified
p. 39 → 63
TB12.1 The tester shall examine the vendor’s response to Section B12 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS HSM Security Requirements for consistency.
TB12.1 The tester shall examine the vendor’s response to Section B12 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS HSM Modular Security Requirements for consistency relating to ensuring the device will fail in a secure manner whenever cryptographic keys are rendered invalid. The tester shall summarize the responses.
Modified
p. 39 → 63
TB12.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the HSM’s behavior when cryptographic keys are lost to determine whether it supports the assertions made by the vendor.
TB12.2 The tester shall examine and cite any relevant documentation (e.g., API reference, design documentation, key-management specification) that describes the device’s behavior when cryptographic keys are lost to determine whether it supports the assertions made by the vendor.
Modified
p. 39 → 63
TB12.3 The tester shall force the HSM to erase its cryptographic keys (e.g. via a command, removal of power, tamper event). The tester shall verify that the HSM fails in a secure manner (e.g., reverts to an un-initialized state and not a normal operational state).
TB12.3 The tester shall force the device to erase its cryptographic keys (e.g., via a command, removal of power, tamper event). The tester shall verify that the device fails in a secure manner (e.g., reverts to an un-initialized state and not a normal operational state).
Modified
p. 40 → 64
PIN-encryption keys used for acquiring shall only be used to encrypt PIN data. Key- encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt PIN data.
PIN-encryption keys used for acquiring shall only be used to encrypt PIN data. Key-encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt PIN data.
Modified
p. 40 → 64
Key-usage information may be changed where the usage is made more restrictive (e.g., made non-exportable).
Key-usage information may be changed where the usage is made more restrictive (e.g., made non- exportable).
Modified
p. 40 → 64
Key variants are only used in devices that possess the original key (e.g., the HSM and the host it communicates with). Key variants are not used at different levels of the key hierarchy (e.g., a variant of a key-encipherment key used for key exchange cannot be used as a working key or as a master file key for local storage).
Key variants are only used in devices that possess the original key (e.g., the device and the host it communicates with). Key variants are not used at different levels of the key hierarchy (e.g., a variant of a key-encipherment key used for key exchange cannot be used as a working key or as a Master File Key for local storage).
Modified
p. 40 → 64
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS HSM Security Requirements manual for consistency.
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS HSM Modular Security Requirements for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses.
Modified
p. 40 → 64
TB13.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the use of cryptographic keys to determine whether it supports the assertions made by the vendor. Examples of “cryptographic function” are: DES and AES.
TB13.2 The tester shall and cite examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor that describes the use of cryptographic keys to determine whether it supports the assertions made by the vendor.
Modified
p. 40 → 64
TB13.3 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the use of cryptographic keys and relating to encryption and decryption of arbitrary data to determine whether it supports the assertions made by the vendor. For example: A public key shall not be used by the HSM for both signature authentication and encryption. Examples of a key’s “cryptographic purpose” are: Data encryption, key encryption, and MAC.
TB13.3 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the use of cryptographic keys and relating to encryption and decryption of arbitrary data to determine whether it supports the assertions made by the vendor. For example: A public key shall not be used by the device for both signature authentication and encryption. Examples of a key’s “cryptographic purpose” are: Data encryption, key encryption, and MAC.
Removed
p. 41
Physical segregation Storing keys enciphered under a KEK dedicated to encipherment of a specific type of key Modifying or appending information to a key as a function of its intended purpose, prior to encipherment of the key for storage, e.g., key tags TB13.5 The tester shall verify the following:
Modified
p. 41 → 65
a) PIN-encryption keys are only used to encrypt PIN data.
Modified
p. 41 → 65
b) Key-encrypting keys are only used to encrypt keys.
Modified
p. 41 → 65
c) PIN keys shall never be used to encrypt keys.
Modified
p. 41 → 65
d) Key-encrypting keys shall never be used to encrypt PIN data.
Modified
p. 42 → 66
Components (shares) of secret and private keys may be output in the clear to key mailers or key-transfer devices.
Components (shares) of secret and private keys may be output in the clear to key mailers or key- transfer devices.
Modified
p. 42 → 66
Clear-text PINs may be output in issuer environments. Clear-text PINs are not allowed to be output under the security policy (see C1 and B15) for HSMs used for PIN processing by an acquirer or its agent.
Clear-text PINs may be output in issuer environments. Clear-text PINs are not allowed to be output under the security policy (see C1 and B15) for devices used for PIN processing by an acquirer or its agent.
Modified
p. 42 → 66
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the output of clear-text keys and protection of PINs for consistency.
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B14 of the PCI PTS HSM Modular Security Requirements for consistency relating to the output of clear-text keys and the protection of PINs. The tester shall summarize the responses.
Modified
p. 42 → 66
TB14.2 The tester shall examine the response to Section B14 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
TB14.2 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
Modified
p. 42 → 66
TB14.3 The tester shall examine the response to Section B14 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the transfer of a key from a high- security component to a lower-security component, for consistency.
TB14.3 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to the transfer of a key from a high-security component to a lower-security component, for consistency.
Removed
p. 43
Standard PIN block formats (e.g. ISO format 0, 1, 2 and 3) shall not be translated into non-standard PIN block formats.
Use of format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.
Translation of PIN block formats that include the PAN to PIN block formats that do not include the PAN, shall not be supported. In particular, ISO PIN block formats 0 and 3 shall not be translated into ISO PIN block format 1 When performing translations between PIN block formats that both include the PAN, a change of PAN shall not be supported except in the following case: where introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN shall only be provided whilst the host security modules are in a sensitive state and under dual control …
Use of format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.
Translation of PIN block formats that include the PAN to PIN block formats that do not include the PAN, shall not be supported. In particular, ISO PIN block formats 0 and 3 shall not be translated into ISO PIN block format 1 When performing translations between PIN block formats that both include the PAN, a change of PAN shall not be supported except in the following case: where introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN shall only be provided whilst the host security modules are in a sensitive state and under dual control …
Modified
p. 43 → 67
TB15.1 The tester shall examine the response to Section B15 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B15 of the PCI PTS HSM Security Requirements manual for consistency.
TB15.1 The tester shall examine the response to Section B15 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B15 of the PCI PTS HSM Modular Security Requirements for consistency relating to PIN Management. The tester shall summarize the responses.
Modified
p. 43 → 67
TB15.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes PIN management to determine whether it supports the assertions made by the vendor.
TB15.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes PIN management to determine whether it supports the assertions made by the vendor.
Modified
p. 43 → 67
Note: If supporting online PIN processing, the HSM must support at least one of the following key-management techniques using TDES as described in ANSI X9.24 and ISO/IEC 18033-3:
Note: If supporting online PIN processing, the device must support at least one of the following key-management techniques using TDES or AES as described in ANSI X9.24 and ISO/IEC 18033-3:
Modified
p. 43 → 67
• Master/Session The device must also support at least one of the following PIN block formats if supporting online PIN processing:
Removed
p. 44
When calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the input encrypted PIN block does not agree with the input PAN, the calculated value shall not be returned except in the following case: where the introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN during calculation of the derived value shall be provided only whilst the host security modules are in a sensitive state and under dual control (see ISO 13491 1:2007, 6.3.6).
Any integrity checks performed on the deciphered PIN block shall rely only on the first byte of the PIN block (control field and PIN length field) and fill digits (to ensure that each digit is a permitted value).
The following illustrates translations from formats 0, 1, 2 and 3:
Translation Translation to ISO Format 0 ISO Format 1 …
Any integrity checks performed on the deciphered PIN block shall rely only on the first byte of the PIN block (control field and PIN length field) and fill digits (to ensure that each digit is a permitted value).
The following illustrates translations from formats 0, 1, 2 and 3:
Translation Translation to ISO Format 0 ISO Format 1 …
Modified
p. 44 → 68
• The device supports the standard PIN block formats.
Modified
p. 44 → 68
• Journaled transaction messages do not contain a PIN.
Modified
p. 44 → 68
• All key-encryption keys must have an appropriate length and are used with an accepted algorithm.
Modified
p. 45 → 69
Logs shall not contain clear-text sensitive data unless those logs are protected in accordance with Requirement A5. Logs exported from the HSM shall never contain clear text sensitive data.
Logs shall not contain clear-text sensitive data unless those logs are protected in accordance with Requirement A3. Logs exported from the device shall never contain clear-text sensitive data.
Modified
p. 45 → 69
TB16.1 The tester shall examine the vendor’s response to Section B16 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B16 of the PCI PTS HSM Security Requirements manual for consistency.
TB16.1 The tester shall examine the vendor’s response to Section B16 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B16 of the PCI PTS HSM Modular Security Requirements for consistency relating to secure logging. The tester shall summarize the responses.
Modified
p. 45 → 69
TB16.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes secure logging to determine whether it supports the assertions made by the vendor.
TB16.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes secure logging to determine whether it supports the assertions made by the vendor.
Modified
p. 45 → 69
TB16.3 The tester shall verify that the HSM provides mechanisms that allow log data stored within the HSM to be protected•e.g., using cryptographic mechanisms that allow log data stored within the HSM to be protected from unauthorized modification and deletion or from modification if output for storage. The vendor security policy must address administrative actions regarding periodic management and archiving of log data.
TB16.3 The tester shall verify that the device provides mechanisms that allow log data stored within the device to be protected•e.g., using cryptographic mechanisms that allow log data stored within the device to be protected from unauthorized modification and deletion or from modification if output for storage. The vendor security policy must address administrative actions regarding periodic management and archiving of log data.
Modified
p. 45 → 69
TB16.4 The tester shall verify that the HSM supports secure logging, including time stamps, of security sensitive commands such as:
TB16.4 The tester shall verify that the device supports secure logging, including time stamps, of security sensitive commands such as:
Modified
p. 45 → 69
d) Enabling and disabling HSM security functions TB16.5 The tester shall verify that the HSM requires dual control to delete secure logs stored internally.
d) Enabling and disabling device security functions TB16.5 The tester shall verify that the device requires dual control to delete secure logs stored internally.
Removed
p. 46
HSMs may allow customers or integrators to install additional applications where the vendor can show that by permitting this:
PCI HSM certification.
Applications, in this context, are functional entities that execute within the boundary of the HSM and may or may not provide services external to the HSM. Applications are typically processes or tasks that execute under the control of an Operating System (OS) or software executive routine.
PCI HSM certification.
Applications, in this context, are functional entities that execute within the boundary of the HSM and may or may not provide services external to the HSM. Applications are typically processes or tasks that execute under the control of an Operating System (OS) or software executive routine.
Modified
p. 46 → 70
a) It cannot adversely affect the security features of the product that are relevant to the
a) It cannot adversely affect the security features of the product that are relevant to the PCI device certification.
Modified
p. 46 → 70
b) It cannot modify any of the cryptographic functionality of the HSM or introduce new primitive cryptographic functionality.
b) It cannot modify any of the cryptographic functionality of the device or introduce new primitive cryptographic functionality.
Modified
p. 46 → 70
c) The application is strongly authenticated to the HSM by digital signature.
c) The application is authenticated to the device by digital signature.
Modified
p. 46 → 70
The vendor must provide clear security guidance in the user available security policy referenced in C1 for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized.
e) The application can only work on the keys it alone manages and cannot affect or see any other keys. The vendor must provide clear security guidance in the user available security policy referenced in C1 for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested and authorized.
Modified
p. 46 → 71
TB17.2 The tester shall examine any relevant documentation, such as the user guide, specification of the device’s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB17.2 The tester shall examine and cite any relevant documentation, such as the user guide, specification of the device’s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 47 → 71
TB17.6 If the OS/firmware and/or any application with security impact are distributed over separate components (i.e., sets of hardware, software, firmware, or some combination thereof that implement cryptographic functions or processes that are contained within independent defined cryptographic boundaries) of the device, the tester will verify that the communication in between separated parts is consistent with the separation mechanisms as described by the vendor. The vendor shall provide evidence concerning the communication between the separated parts and how the communication …
Modified
p. 47 → 71
B17.7 If the device allows customers or integrators to install additional applications, the tester will verify that the device’s design prevents the embedded application from:
Modified
p. 47 → 71
• Having access to the top-level master keys that protect the working keys
•i.e., the application cannot extract or modify the top-level master key.
•i.e., the application cannot extract or modify the top-level master key.
Modified
p. 47 → 71
• Having access to operator or security officer functions, and so cannot change security configurations or change privileges.
Modified
p. 47 → 71
• Introducing new primitive cryptographic functions (although it can use these to implement new composite functionality).
Modified
p. 47 → 71
Additionally, the embedded application is separated from the approved HSM functionality by an internal security boundary that prevents embedded applications from obtaining any elevated privilege or access to any data belonging to other embedded or host-side applications.
Additionally, the embedded application is separated from the approved device functionality by an internal security boundary that prevents embedded applications from obtaining any elevated privilege or access to any data belonging to other embedded or host-side applications.
Modified
p. 48 → 73
The intended operation is considered as the functionality relevant to B2, and is representative of the functionality provided by the HSM. . For multi-application devices, the intended operation furthermore includes the operation of applications without security impacts.
The intended operation is considered as the functionality relevant to B2, and is representative of the functionality provided by the device. For multi-application devices, the intended operation furthermore includes the operation of applications without security impacts.
Modified
p. 48 → 73
OS/firmware modules such as, for example, peripheral drivers, file systems, or inter- process communication protocols shall be regarded as components. Applications responding to external interfaces or communicating with the firmware shall be regarded as services.
OS/firmware modules such as, for example, peripheral drivers, file systems, or inter-process communication protocols shall be regarded as components. Applications responding to external interfaces or communicating with the firmware shall be regarded as services.
Modified
p. 48 → 73
Firmware and software running on the device shall be designed to run with minimal privilege and ensure that no process requires root (or equivalent) privilege following start- up. Additionally, only software necessary for the intended purpose of the HSM shall be present.
Firmware and software running on the device shall be designed to run with minimal privilege and ensure that no process requires root (or equivalent) privilege following startup. Additionally, only software necessary for the intended purpose of the device shall be present.
Modified
p. 48 → 73
TB18.1 The tester shall examine the vendor’s response to Section B18 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS HSM Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation.
TB18.1 The tester shall examine the vendor’s response to Section B18 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS HSM Modular Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation. The tester shall summarize the responses.
Modified
p. 48 → 73
TB18.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB18.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 48 → 73
TB18.5 The tester shall verify that the operating system/firmware is enforcing least privilege.
Modified
p. 48 → 73
TB18.6 The tester will examine the methods and tools provided by the vendor, which ensure, that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the OS.
Modified
p. 49 → 75
Devices must be uniquely identified through acceptable cryptographic methods. Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Modified
p. 49 → 75
TB19.1 The tester shall examine the vendor’s response to Section B19 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B19 of the PCI PTS HSM Security Requirements manual for consistency.
TB19.1 The tester shall examine the vendor’s response to Section B19 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B19 of the PCI PTS HSM Modular Security Requirements for consistency relating to the ability of the device to return its unique device ID.
Modified
p. 49 → 75
TB19.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the unique device ID to determine whether it supports the assertions made by the vendor.
TB19.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the unique device ID to determine whether it supports the assertions made by the vendor.
Modified
p. 49 → 75
TB19.3 The tester shall obtain the unique device ID from the HSM using the methods described in vendor documentation.
TB19.3 The tester shall obtain the unique device ID from the device using the methods described in vendor documentation.
Modified
p. 50 → 76
If the HSM allows the two modes to be selected remotely, the method used must enforce mutual authentication and prevent reply attacks.
If the device allows the two modes to be selected remotely, the method used must enforce mutual authentication and prevent reply attacks.
Modified
p. 50 → 76
Authentication data must include at least five characters.
Authentication data must include at least seven characters.
Modified
p. 50 → 76
The mode indication may be either permanent (e.g., an indicator on the HSM or a prompt on a display) or transitory (e.g. an indication of the mode upon transition from one mode to the other and when querying the current device state), or both.
The mode indication may be either permanent (e.g., an indicator on the device or a prompt on a display) or transitory (e.g., an indication of the mode upon transition from one mode to the other and when querying the current device state), or both.
Modified
p. 50 → 76
TB20.1 The tester shall examine the response to Section 20 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement 20 of the PCI PTS HSM Security Requirements manual for consistency.
TB20.1 The tester shall examine the response to Section 20 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement 20 of the PCI PTS HSM Modular Security Requirements for consistency relating to separation of PCI and non-PCI modes.
Modified
p. 50 → 76
TB20.2 The tester shall examine any additional relevant documentation submitted by the vendor, such as user guides or an API, to verify that it supports vendor responses.
TB20.2 The tester shall and cite examine any additional relevant documentation submitted by the vendor, such as user guides or an API, to verify that it supports vendor responses.
Modified
p. 50 → 76
TB20.3 The tester shall review source code to verify that the HSM zeroizes keys or prevents keys from being shared between the two modes.
TB20.3 The tester shall review source code to verify that the device zeroizes keys or prevents keys from being shared between the two modes.
Modified
p. 50 → 76
TB20.4 The tester shall verify that all conditions, as described above in the guidance, are met if the HSM implements a PCI mode and a non-PCI mode.
TB20.4 The tester shall verify that all conditions, as described above in the guidance, are met if the device implements a PCI mode and a non-PCI mode.
Modified
p. 51 → 77
Devices evaluated in Section A
• Physical Derived Security Requirements where the device will be restricted to deployment inControlled Environments as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.
• Physical Derived Security Requirements where the device will be restricted to deployment in
Devices evaluated in Section A
• Physical Derived Security Requirements where the device will be restricted to deployment in controlled environments as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.
• Physical Derived Security Requirements where the device will be restricted to deployment in controlled environments as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.
Modified
p. 51 → 77
If the roles are user-configurable, the security policy must describe the roles that can be configured in the HSM.
If the roles are user-configurable, the security policy must describe the roles that can be configured in the device.
Modified
p. 51 → 77
Devices may include unapproved functionality. When such functions are in use, the device is considered to be operating in an unapproved mode and must provide a mode indication as described in B20.
Modified
p. 51 → 77
TC1.1 The tester shall examine the vendor’s response to Section C1 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS HSM Security Requirements for consistency.
TC1.1 The tester shall examine the vendor’s response to Section C1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS HSM Modular Security Requirements for consistency.
Modified
p. 51 → 78
TC1.13 The tester shall examine the security policy to verify that all physical interfaces are identified, along with the functionality and type of data that is carried over each interface.
Removed
p. 52
TC1.13 The tester shall examine the security policy to verify that it identifies all roles supported by the HSM and indicates the services and permissions available for each role.
Modified
p. 52 → 77
TC1.2 The tester shall examine the security policy to verify that the device is properly identified. Product name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions.
Modified
p. 52 → 78
TC1.8 The tester shall examine the security policy to verify that it provides guidance on secure key archival storage to protect keys against unauthorized disclosure and substitution and to provide key separation.
Modified
p. 52 → 78
TC1.9 The tester shall examine the security policy to verify that instructions are provided with regard to tamper evidence, inspection frequency and procedures.
Modified
p. 52 → 78
TC1.10 The tester shall examine the security policy to verify that instructions are provided with regard to auditing/log inspection frequency and procedures. The security policy shall include events that are logged as defined in B16, any restrictions on operator access to logs, and procedures for accessing and deleting logs.
Modified
p. 52 → 78
TC1.11 The tester shall examine the security policy and relevant vendor documentation to verify that any periodic maintenance procedures required for the secure operation of the device are included in the security policy.
Modified
p. 52 → 78
TC1.12 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods.
Modified
p. 52 → 78
TC1.16 The tester shall examine the security policy to verify that it identifies all roles supported by the device and indicates the services and permissions available for each role.
Modified
p. 52 → 78
TC1.14 If the device permits access to internal areas, the tester shall examine the security policy to verify that it specifies the internal components and operating procedures requiring access to these internal areas.
Modified
p. 52 → 78
TC1.15 The tester shall examine the security policy to verify that it identifies all self-tests that the module performs, procedures that an operator may need to initiate any self-tests, and the conditions under which each self-test is executed (e.g., power up, periodic, conditional, on operator demand).
Modified
p. 52 → 79
TC1.18 The tester shall examine the security policy to verify that it identifies all conditions (e.g., voltage, humidity, temperature) that will cause environmental failure-protection (EFP) mechanisms to trigger.
Modified
p. 52 → 79
TC1.19 The tester shall examine the security policy and other relevant documentation submitted by the vendor to verify that the security policy identifies any other operational-environment restrictions that must be met for the device to be operated in a secure manner (e.g., ambient-temperature range, support hardware, support software, power conditioning, environmental protections assumed for proper operation).
Removed
p. 53
Standard PIN block formats (e.g. ISO format 0, 1, 2 and 3) shall not be translated into non-standard PIN block formats.
Use of format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.
When calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the input encrypted PIN block does not agree with the input PAN, the calculated value shall not be returned except in the following case: where the introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN during calculation of the derived value shall be provided only whilst the host security modules are in a sensitive state and under dual control (see ISO 13491 1:2007, 6.3.6).
Any integrity checks performed on the deciphered PIN block shall rely only on the …
Use of format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.
When calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the input encrypted PIN block does not agree with the input PAN, the calculated value shall not be returned except in the following case: where the introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN during calculation of the derived value shall be provided only whilst the host security modules are in a sensitive state and under dual control (see ISO 13491 1:2007, 6.3.6).
Any integrity checks performed on the deciphered PIN block shall rely only on the …
Modified
p. 54 → 80
TC1.22 The tester shall confirm that the security policy includes procedures for the decommissioning of devices that are removed from service, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device. The procedures may differentiate between temporary and permanent removal.
Modified
p. 55 → 117
e) HSM specific spare components.
e) HSM-specific spare components.
Modified
p. 55 → 117
e) HSM specific spare components.
e) HSM-specific spare components.
Removed
p. 56
a) Experts are familiar with the underlying algorithms, protocols, hardware, structures, etc. implemented in the product or system type and the principles and concepts of security employed;
b) Proficient persons are knowledgeable in that they are familiar with the security behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully.
b) Proficient persons are knowledgeable in that they are familiar with the security behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully.
Modified
p. 56 → 118
Expertise refers to the level of generic knowledge of the application area or product type (e.g., Unix operation systems, Internet protocols). Identified levels are as follows:
Expertise refers to the level of generic knowledge of the application area or product type (e.g., UNIX operation systems and Internet protocols). Identified levels are as follows:
Modified
p. 56 → 118
a) Layman is a person without professional or specialized knowledge in a particular subject. They are unknowledgeable compared to experts, proficient, or skilled persons, with no particular expertise but capable of implementing simple attack steps, or capable of implementing more complex attack steps under direction. For the purpose of exploitation, they can implement an attack based on a script or a written procedure, without requiring any particular skill.
Modified
p. 56 → 118
If proficient expertise on various areas of technology is required for an attack, e.g., on electrical engineering and cryptography, an expert level of expertise can be assumed.
If proficient expertise on various areas of technology is required for an attack
•for example, on electrical engineering and cryptography
•an expert level of expertise can be assumed. In most attack scenarios, the exploitation level of expertise is less than the required identification level of expertise.
•for example, on electrical engineering and cryptography
•an expert level of expertise can be assumed. In most attack scenarios, the exploitation level of expertise is less than the required identification level of expertise.
Modified
p. 56 → 118
a) Public information about the HSM (or no information): Information is considered public if it can be easily obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer.
a) Public information about the HSM (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. 56 → 118
b) Restricted information concerning the HSM (e.g., as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (e.g., like the PCI PTS HSM DTRs).
b) Restricted information concerning the HSM (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 HSM DTRs.
Modified
p. 56 → 119
c) Sensitive information about the HSM (e.g., knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
c) Sensitive information about the HSM (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
Modified
p. 56 → 119
Specialist expertise and knowledge of the HSM are concerned with the information required for persons to be able to attack an HSM. There is an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this relationship between expertise and …
Specialist expertise and knowledge of the HSM are concerned with the information required for persons to be able to attack an HSM. There is an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this relationship between expertise and …
Removed
p. 57
Table 1: Multiple Samples Factors Number of Devices Factor In the case that more than one sample is accounted for, strong justification must be provided for the use of multiple samples.
Focused Ion Beam Scanning Electron Microscope Abrasive Laser Equipment If, for one phase (identification or exploitation), equipment from different levels is required, only the highest level shall be retained.
Focused Ion Beam Scanning Electron Microscope Abrasive Laser Equipment If, for one phase (identification or exploitation), equipment from different levels is required, only the highest level shall be retained.
Modified
p. 57 → 119
Equipment refers to the equipment that is required to identify or exploit vulnerability.
Table 1: Multiple Samples Factors Number of Devices Factor Equipment refers to the equipment that is required to identify or exploit vulnerability. See Appendix B for details of equipment classification.
Modified
p. 57 → 119
a) Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•e.g., at a nearby store or downloaded from the Internet. The equipment might consist of simple attack scripts, personal computers, card readers, pattern generators, simple optical microscopes, power supplies, or simple mechanical tools.
a) Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•for example, from retail outlets or acquired/downloaded from the Internet.
Modified
p. 57 → 119
b) Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort. This could include purchase of moderate amounts of equipment (e.g., dedicated electronic cards, specialized test bench, protocol analyzers, oscilloscopes, microprobe workstation, chemical workbench, precise milling machines, etc.) or development of more extensive attack scripts or programs.
b) Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort.
Modified
p. 57 → 120
c) Bespoke equipment is not readily available to the public, as it might need to be specially produced (e.g., very sophisticated software), or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered in the exploitation phase.
c) Bespoke equipment is not readily available to the public, as it might need to be specially produced (for example, very sophisticated software), or because the equipment is so specialized that its distribution is controlled (for example, X-ray equipment), possibly even restricted. Bespoke equipment that can be rented must be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment and must not additionally be considered in the exploitation phase.
Modified
p. 57 → 120
d) Chip-level attacks equipment, necessary to implement chip level attacks is generally not widely available on the market and its access is restricted. It is also very expensive, and therefore is considered as a category on its own. Only the following equipment belong to this category:
d) Chip-level attack equipment, necessary to implement chip-level attacks, is generally not widely available on the market and its access is restricted. It is also very expensive, and therefore is considered as a category on its own. Only the following equipment belong to this category:
Removed
p. 58
Equipment Knowledge If several attack scenarios lead to the same potential in total and exploitation, then the one that has the lowest cost in exploitation, exclusive of the items above, must be considered.
Rating Success of an Attack If the difficulty of implementing an attack is sufficiently high, resulting in the attack being likely to succeed on a limited number of targets, multiple devices can be considered, given the following limitations.
To reflect this matter of fact, the number of target devices (i.e. functional samples with working keys in the exploitation phase) can be multiplied using the following factors:
Table 2: Success Rate Multiplying Factor Probability of Success Factor 0.5 > P 0.25 1.5 P < 0.25 2 When determining the probability, each step of the attack must be divided into likely independent phases with a featured probability. The overall probability is obtained by multiplying all factors together.
Proper documentation is …
Rating Success of an Attack If the difficulty of implementing an attack is sufficiently high, resulting in the attack being likely to succeed on a limited number of targets, multiple devices can be considered, given the following limitations.
To reflect this matter of fact, the number of target devices (i.e. functional samples with working keys in the exploitation phase) can be multiplied using the following factors:
Table 2: Success Rate Multiplying Factor Probability of Success Factor 0.5 > P 0.25 1.5 P < 0.25 2 When determining the probability, each step of the attack must be divided into likely independent phases with a featured probability. The overall probability is obtained by multiplying all factors together.
Proper documentation is …
Modified
p. 59 → 121
For a given attack it might be necessary to make several passes through the table for different attack scenarios (e.g., trading off expertise for time or equipment). The lowest value obtained for these passes should be retained. In the case of a vulnerability that has been identified and is in the public domain, the identifying values should be selected for an attacker to uncover that attack scenario in the public domain, rather than to initially identify it.
For a given attack it might be necessary to make several passes through the table for different attack scenarios (for example, trading off expertise for time or equipment). The lowest value obtained for these passes should be retained. In the case of a vulnerability that has been identified and is in the public domain, the identifying values should be selected for an attacker to uncover that attack scenario in the public domain, rather than to initially identify it.
Modified
p. 59 → 121
Table 3: Attack Potential Factors Identification Exploitation Attack time < 1 hour 0 0 ≤ 8 hours 2 2 ≤ 24 hours 3 3 ≤ 40 hours 3.5 3.5 ≤ 80 hours 4 4 ≤ 160 hours 5 5 Beyond 160 hours 5.5 5.5 Expertise Layman 0 0 Proficient 1.5 1.5 Expert 4 4 Knowledge of the HSM Public 0 0 Restricted 2 2 Sensitive 3 4 Access to the HSM per unit required for the attack. Note: If more …
Table 2: Attack Potential Factors Identification Exploitation Attack time ≤ 1 hour 0 0 ≤ 2 hours 1 1 ≤ 4 hours 1.5 1.5 ≤ 6 hours 2 2 ≤ 8 hours 3 3 ≤ 12 hours 4 4 ≤ 16 hours 4.5 4.5 ≤ 24 hours 5 5 ≤ 40 hours 5.5 5.5 ≤ 60 hours 6 6 ≤ 100 hours 6.5 6.5 ≤ 160 hours 7 7 Beyond 160 hours 7.5 7.5 Expertise Layman 0 0 Skilled 1 …
Modified
p. 61 → 123
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with keys P(success) = 0.8
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with keys 12 hours
Modified
p. 61 → 123
Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized Public Standard (bug) 1 working with keys P(success) = 1 As a summary for the exploitation phase, the following would apply:
Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized Public Standard (bug) 1 working with keys 6 hours As a summary for the exploitation phase, the following would apply:
Modified
p. 62 → 124
• The data used for DPA can be acquired at an external interface of the HSM module, e.g., the HSM needs not be further physically attacked to get the required test data; and that
Removed
p. 63
A note on sts versions: Prior to version of 1.7, the Discrete Fourier Transform (Spectral) test was conducted using the incorrect peak height threshold value (called T in Section 2.6.4 of SP 800-22) and calculated the normalized difference (d) incorrectly. In order to use an older version of the sts tool, the corrections described in [Kim 2004] should be implemented for this test. In versions 1.7 and later, these corrections are already included.
All tests other than the Lempel-Ziv test should be run [0] (for later versions of sts, the Lempel-Ziv test is normally inaccessible).
All tests other than the Lempel-Ziv test should be run [0] (for later versions of sts, the Lempel-Ziv test is normally inaccessible).
Modified
p. 63 → 128
The tester should request and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor-supplied data is interpreted correctly by the sts tool (the sts tool assumes that binary data is in big-endian formatting on all platforms).
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. 63 → 128
The sts testing on the data shall be judged as a "pass" if it passes all of 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 of the tests, for both the "Proportion of Sequences Passing a Test" and "Uniform Distribution of P-Values" interpretation approaches. 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 using both the initial data and the additional vendor-supplied data.
Modified
p. 63 → 128
The sts tool should be configured as per guidance provided in SP 800-22, 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. 63 → 128
The following settings are consistent with the SP 800-22 document:
The following settings are consistent with the SP 800-22 Revision 1a document:
Removed
p. 64
[3] For the Block Frequency Test, if n=106, the test block size should be set between 104 and 106. (See SP 800-22 Section 2.2.7.) [4] The two template tests (Non-Overlapping and Overlapping tests) both require selection of a template length of 9 or 10 in order to produce meaningful results. (See SP 800-22 Sections 2.7.7 and 2.8.7.) [5] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP 800-22 Section 2.9.7. For n=106, the only acceptable values are (L=6, Q=640) and (L=7, Q=1280).
(See SP 800-22 Section 2.12.7) [8] The Linear Complexity Test block length is required to be set to between 500 and 5,000 (inclusive), and requires that 200 M n . (See SP 800-22 Section 2.11.7.) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST SP 800-22, revisions …
(See SP 800-22 Section 2.12.7) [8] The Linear Complexity Test block length is required to be set to between 500 and 5,000 (inclusive), and requires that 200 M n . (See SP 800-22 Section 2.11.7.) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST SP 800-22, revisions …
Modified
p. 64 → 129
[7] For the Approximate Entropy (ApEn) test, SP800-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. 64 → 129
[8] The Serial Test block length is also set based on n. If n=106, the block length must be less than 17.
Modified
p. 64 → 129
[Kim 2004] Kim, Song-Ju, et al., "Corrections of the NIST Statistical Test Suite for Randomness".
[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.
Removed
p. 65
DSA/D-H AES Minimum key size in number of bits: 112 1024 160 1024/160
• Minimum key size in number of bits: 168 2048 224 2048/224
• Minimum key size in number of bits:
• 3072 256 3072/256 128 Minimum key size in number of bits:
• 7680 384 7680/384 192 Minimum key size in number of bits:
• 15360 512 15360/512 256 As an exception to the aforementioned, double-length Triple-DES key-encipherment keys may be used to encrypt triple-length Triple-DES keys and 2048-bit RSA keys where the key-encipherment key or the master key protecting it is not used for more than five years.
For Diffie-Hellman implementations:
Entities must authenticate the Diffie-Hellman public keys using either a digital signature (e.g., DSA or RSA, a certificate, or a symmetric MAC (based on TDES
•see ISO 16609
• Requirements for message authentication using symmetric techniques; Method 3 should be used).
• Minimum key size in number of bits: 168 2048 224 2048/224
• Minimum key size in number of bits:
• 3072 256 3072/256 128 Minimum key size in number of bits:
• 7680 384 7680/384 192 Minimum key size in number of bits:
• 15360 512 15360/512 256 As an exception to the aforementioned, double-length Triple-DES key-encipherment keys may be used to encrypt triple-length Triple-DES keys and 2048-bit RSA keys where the key-encipherment key or the master key protecting it is not used for more than five years.
For Diffie-Hellman implementations:
Entities must authenticate the Diffie-Hellman public keys using either a digital signature (e.g., DSA or RSA, a certificate, or a symmetric MAC (based on TDES
•see ISO 16609
• Requirements for message authentication using symmetric techniques; Method 3 should be used).
Modified
p. 65 → 131
Minimum key size in number of bits: 112 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys sizes by row are considered equivalent.
Algorithm DES RSA Elliptic Curve DSA AES Minimum key size in number of bits: 112 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys …
Modified
p. 65 → 131
DES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup.
Algorithm DES RSA Elliptic Curve DSA/D-H AES Minimum key size in number of bits: 112 1024 160 1024/160
• Minimum key size in number of bits: 168 2048 224 2048/224
• Minimum key size in number of bits:
• 3072 256 3072/256 128 Minimum key size in number of bits:
• 7680 384 7680/384 192 Minimum key size in number of bits:
• 15360 512 15360/512 256 DES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the …
• Minimum key size in number of bits: 168 2048 224 2048/224
• Minimum key size in number of bits:
• 3072 256 3072/256 128 Minimum key size in number of bits:
• 7680 384 7680/384 192 Minimum key size in number of bits:
• 15360 512 15360/512 256 DES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the …
Modified
p. 65 → 131
1. 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).
• 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).