Document Comparison
P2PE_Technical_FAQs_1x_July_2014.pdf
→
P2PE_Technical_FAQs_1x.pdf
68% similar
14 → 17
Pages
5243 → 6329
Words
44
Content Changes
Content Changes
44 content changes. 24 administrative changes (dates, page numbers) hidden.
Added
p. 4
• Regarding the third party and the QSA (P2PE), using Section 1.1 as a reference.
Added
p. 5
• Requested in Sections 1.2 and 1.3 regarding the date and timeframe of the assessment, as well as the version of the P2PE Standard utilized.
• Requested in Section 2.4 regarding the P2PE decryption environment(s).
• Requested in Section 3.5 regarding key management.
• Requested in Table 1.1 and 1.2 in Domain 1 regarding the POI devices used. Exclude information regarding payment applications, as they are not relevant to third-party P2PE services applicable to this attestation.
• Requested in Tables 1.3 and 1.4 in Domain 1 regarding SCDs used to generate, load, or encrypt cryptographic keys. Examples include HSMs, key-injection/loading devices (KLDs) and other devices that generate or load keys.
• Requested in Tables 5.1 and 5.2 in Domain 5 regarding HSMs used in the decryption environment.
• Requested in Table 5.3 in Domain 5 regarding Host Systems used in the decryption environment (HW/Hybrid ONLY).
• Requested in Tables 6.1 and 6.2 (Domain 6), as well as …
• Requested in Section 2.4 regarding the P2PE decryption environment(s).
• Requested in Section 3.5 regarding key management.
• Requested in Table 1.1 and 1.2 in Domain 1 regarding the POI devices used. Exclude information regarding payment applications, as they are not relevant to third-party P2PE services applicable to this attestation.
• Requested in Tables 1.3 and 1.4 in Domain 1 regarding SCDs used to generate, load, or encrypt cryptographic keys. Examples include HSMs, key-injection/loading devices (KLDs) and other devices that generate or load keys.
• Requested in Tables 5.1 and 5.2 in Domain 5 regarding HSMs used in the decryption environment.
• Requested in Table 5.3 in Domain 5 regarding Host Systems used in the decryption environment (HW/Hybrid ONLY).
• Requested in Tables 6.1 and 6.2 (Domain 6), as well as …
Added
p. 9
Q 4 July 2015
• For P2PE solutions, can you use PCI approved POI devices with SRED, where the PTS listing indicates "Non CTLS"? A A PCI PTS-approved POI device with SRED where the PTS listing indicates “Non CTLS” (indicating that the contactless interface was not included in the SRED evaluation) is eligible for use in a PCI P2PE solution only if one of the following applies:
1. All contactless interfaces are disabled (and cannot be enabled by the merchant) at all times while deployed in the PCI P2PE solution.
2. The PCI PTS approved POI device:
(a) Was validated under PTS POI v3.0, including the SRED module, prior to release of criteria for evaluating contactless (CTLS) interfaces in PTS POI v3.1, and (b) Successfully completes required annual supplemental contactless evaluations (“SCE”) by the originating PTS lab, validating compliance with a subset of PTS POI requirements relating to vulnerability to common logical security attacks.
PCI …
• For P2PE solutions, can you use PCI approved POI devices with SRED, where the PTS listing indicates "Non CTLS"? A A PCI PTS-approved POI device with SRED where the PTS listing indicates “Non CTLS” (indicating that the contactless interface was not included in the SRED evaluation) is eligible for use in a PCI P2PE solution only if one of the following applies:
1. All contactless interfaces are disabled (and cannot be enabled by the merchant) at all times while deployed in the PCI P2PE solution.
2. The PCI PTS approved POI device:
(a) Was validated under PTS POI v3.0, including the SRED module, prior to release of criteria for evaluating contactless (CTLS) interfaces in PTS POI v3.1, and (b) Successfully completes required annual supplemental contactless evaluations (“SCE”) by the originating PTS lab, validating compliance with a subset of PTS POI requirements relating to vulnerability to common logical security attacks.
PCI …
Added
p. 10
See also FAQ entitled “Are POI devices with only the PTS-approved firmware (i.e., no additional software) eligible for use in a PCI P2PE solution?”
Q 2 July 2015
• Are POI devices with only the PTS-approved firmware (i.e., no additional software) eligible for use in a PCI P2PE solution? A Yes. However, while it may be possible for a PCI POI device to implement all the necessary functionality for use in a P2PE solution solely within its existing PTS-approved firmware, generally the POI device will contain additional software. Any software (whether it has access to cardholder data or not) that is present or intended to be present on the POI device within the P2PE solution that was not included in the PTS-approval of the POI's firmware must be assessed in accordance with the PCI P2PE standard. Note that it may be possible for additional (non-firmware) software to be present on the POI …
Q 2 July 2015
• Are POI devices with only the PTS-approved firmware (i.e., no additional software) eligible for use in a PCI P2PE solution? A Yes. However, while it may be possible for a PCI POI device to implement all the necessary functionality for use in a P2PE solution solely within its existing PTS-approved firmware, generally the POI device will contain additional software. Any software (whether it has access to cardholder data or not) that is present or intended to be present on the POI device within the P2PE solution that was not included in the PTS-approval of the POI's firmware must be assessed in accordance with the PCI P2PE standard. Note that it may be possible for additional (non-firmware) software to be present on the POI …
Added
p. 17
• Testing procedures 6E-4.1.c and d specify unique POI keys
•does this mean that unique public encryption keys must exist for each POI? A The intent of this requirement is that all secret and private cryptographic keys used in transaction- originating POI devices for any function directly or indirectly related to account-data protection are unique per POI device. The intent is not that each individual POI must have its own public encryption keys, but that where a POI does have its own public/private key pairs (for example, for authentication or key conveyance), the private key(s) owned by the POI and its associated public key(s) must be unique per POI. Therefore, the focuses of the test at 6E-4.1.c and d are, IF POIs have their own public/private key pairs, to confirm that each individual POI has a unique public key(s), and thereby confirm the uniqueness of each POI’s private key(s).
•does this mean that unique public encryption keys must exist for each POI? A The intent of this requirement is that all secret and private cryptographic keys used in transaction- originating POI devices for any function directly or indirectly related to account-data protection are unique per POI device. The intent is not that each individual POI must have its own public encryption keys, but that where a POI does have its own public/private key pairs (for example, for authentication or key conveyance), the private key(s) owned by the POI and its associated public key(s) must be unique per POI. Therefore, the focuses of the test at 6E-4.1.c and d are, IF POIs have their own public/private key pairs, to confirm that each individual POI has a unique public key(s), and thereby confirm the uniqueness of each POI’s private key(s).
Modified
p. 3
The solution provider has overall responsibility for ensuring that all P2PE requirements are met, including ensuring that P2PE requirements are met by any third-party organizations that perform P2PE functions on behalf of the solution provider, such as Certification Authorities and key-injection facilities.
The solution provider has overall responsibility for ensuring that all P2PE requirements are met, including ensuring that P2PE requirements are met by any third-party organizations that perform P2PE functions on behalf of the solution provider, such as Certification Authorities and key- injection facilities.
Modified
p. 4
The date the P2PE statement is signed for the third-party’s P2PE assessment (whether assessed as part of a full P2PE solution or in isolation) must be less than one year before the date of any subsequent solutions provider’s P2PE assessment completion date (i.e., the statement described herein is only valid for one year).
The date the P2PE statement is signed for the third party’s P2PE assessment (whether assessed as part of a full P2PE solution or in isolation) must be less than one year before the date of any subsequent solutions provider’s P2PE assessment completion date (i.e., the statement described herein is only valid for one year).
Modified
p. 4
This statement, as stated above, must be prepared by the QSA (P2PE) who assessed the third- party. The statement must be signed and dated by both the third-party and the QSA (P2PE), and must attest to the fact that the third-party entity is compliant with all applicable P2PE requirements. The statement must also contain [at a minimum] the following information, as applicable to the third-party. Note that the statement is not required to contain any sensitive information.
This statement, as stated above, must be prepared by the QSA (P2PE) who assessed the third party. The statement must be signed and dated by both the third party and the QSA (P2PE), and must attest to the fact that the third-party entity is compliant with all applicable P2PE requirements. The statement must also contain (at a minimum) the following information, as applicable to the third party. Note that the statement is not required to contain any sensitive information.
Modified
p. 4
A summary of services being offered by the third party.
Modified
p. 4
Information per the following bullets, which reference sections and tables present in the Solution P-ROV Template v1.1.1. Please refer to that document as applicable. Provide all information:
Modified
p. 5
List each high-level P2PE requirement assessed and indicate whether the requirement was assessed in full (i.e., inclusive of all its sub-requirements), partially, or deemed not applicable. Provide a justification for all applicable requirements only tested partially or deemed not applicable. “Not applicable” in this context implies the requirement may apply but was deemed not applicable via the assessment process and the review of relevant information. For example, applicable in this context would not refer to Domain 2 requirements that …
Modified
p. 5
Include an explicit confirmation attesting to the fact the third-party entity’s prior P2PE assessment includes all services, processes, and systems appropriate to the services the third party offers to P2PE solution providers. At any time during the one-year period of the statement’s validity, if any services, processes, or systems were changed or added, the third party must document any additions or changes and provide that documentation to applicable current and potential P2PE solution providers.
Removed
p. 7
Cover all deployed devices Address all applicable P2PE requirements Result in devices being brought into compliance Are complete Deployed devices must be updated to the identical application and device configuration that was verified by the P2PE assessor during lab testing (per Domain 2).
Modified
p. 7 → 6
Q 1 May 2013
• Can apreviously-deployed POI be included in a P2PE solution? A Solution providers wishing to validate their solutions to the P2PE Hardware/* Standards may include POI devices that are already deployed, as long as all P2PE Requirements are followed during the process of bringing the devices into compliance, and all applicable requirements are verified as being in place for each deployed device. This applies only to deployed POI devices that have already been validated to PTS …
• Can a
Q 1 May 2013
• Can a previously deployed POI be included in a P2PE solution? A Solution providers wishing to validate their solutions to the P2PE Hardware/* Standards may include POI devices that are already deployed, as long as all P2PE Requirements are followed during the process of bringing the devices into compliance, and all applicable requirements are verified as being in place for each deployed device. This applies only to deployed POI devices that have already been validated to …
• Can a previously deployed POI be included in a P2PE solution? A Solution providers wishing to validate their solutions to the P2PE Hardware/* Standards may include POI devices that are already deployed, as long as all P2PE Requirements are followed during the process of bringing the devices into compliance, and all applicable requirements are verified as being in place for each deployed device. This applies only to deployed POI devices that have already been validated to …
Modified
p. 7 → 6
Option 1: The solution provider has sufficient evidence to verify that all POIs were deployed in accordance with all applicable P2PE requirements (Domains 1, 2, 3, 6 and applicable Annexes) Option 2: If there is insufficient evidence to support Option 1, deployed POI devices must be reset and all firmware, cryptographic keys, configurations and software must be reloaded in accordance with P2PE requirements. Cryptographic keys may be loaded either by remote key distribution (Annex A) or by returning …
Option 1: The solution provider has sufficient evidence to verify that all POIs were deployed in accordance with all applicable P2PE requirements (Domains 1, 2, 3, 6 and applicable Annexes).
Modified
p. 7 → 6
The P2PE assessor would verify that all currently-deployed POIs were implemented according to P2PE requirements. The P2PE assessor would rely on documented evidence (e.g. records of key loading activities, device configuration records, pre-installation test results, chain of custody records, etc.) and interviews with appropriate personnel. The P2PE assessor would not observe POIs already deployed to merchant environments.
The P2PE assessor would verify that all currently deployed POIs were implemented according to P2PE requirements. The P2PE assessor would rely on documented evidence (e.g., records of key loading activities, device configuration records, pre-installation test results, chain of custody records, etc.) and interviews with appropriate personnel. The P2PE assessor would not observe POIs already deployed to merchant environments.
Modified
p. 7 → 6
The P2PE assessor would verify that all currently-deployed POIs are reset and that all firmware, cryptographic keys, configurations and software are reloaded. The P2PE assessor would observe processes for bringing deployed devices into compliance (sampling may be used), and would verify that the processes:
The P2PE assessor would verify that all currently deployed POIs are reset and that all firmware, cryptographic keys, configurations, and software are reloaded. The P2PE assessor would observe processes for bringing deployed devices into compliance (sampling may be used), and would verify that the processes:
Modified
p. 7
Applicable P2PE requirements will depend on whether the devices are updated remotely or are returned to the solution provider, for example:
(continued on next page) Applicable P2PE requirements will depend on whether the devices are updated remotely or are returned to the solution provider, for example:
Modified
p. 7
If POI devices are returned to the solution provider for reloading, applicable P2PE requirements include ensuring the secure return of devices to the solution provider (Domains 1, 3), device integrity checks and secure key-loading (Domains 1, 6, and Annex B), secure installation/ configuration of applications (Domain 2), and secure deployment of devices (Domains 1, 3).
If POI devices are returned to the solution provider for reloading, applicable P2PE requirements include ensuring the secure return of devices to the solution provider (Domains 1, 3), device integrity checks and secure key-loading (Domains 1, 6, and Annex B), secure installation/configuration of applications (Domain 2), and secure deployment of devices (Domains 1, 3).
Modified
p. 8 → 7
Where devices are being reset and reloaded remotely, the process for device integrity checks prior to key loading may be performed by the merchant (as instructed by solution provider by phone, via PIM, etc.). Device integrity checks and verification of device serial numbers (per Domain 3) must take place before any remote key-loading is initiated.
Where devices are being reset and reloaded remotely, the process for device integrity checks prior to key loading may be performed by the merchant (as instructed by solution provider by phone, via PIM, etc.). Device integrity checks and verification of device serial numbers (per Domain 3) must take place before any remote key loading is initiated.
Modified
p. 8
1A.1.1.1 SRED capabilities must be enabled and active.
1A.1.1.1 • SRED capabilities must be enabled and active.
Modified
p. 8
5D-2.1 Implement controls to detect encryption failures and provide immediate notification.
5D-2.1 • Implement controls to detect encryption failures and provide immediate notification.
Modified
p. 9 → 11
Q 1 July 2014
• Is it expected that applications on a hardened P2PE device be assessed according to Domain 2 requirements (for example, 2A-1.2.c) if forensics tools are not able to observe any data stored locally by the P2PE application due to operating system or firmware constraints, CPU access restrictions, or tamper-resistance mechanisms? A It is the expectation of PCI SSC that a P2PE assessor conducting an application vendor assessment is given sufficient access to both the device and application …
• Is it expected that applications on a hardened P2PE device be assessed according to Domain 2 requirements (for example, 2A-1.2.c) if forensics tools are not able to observe any data stored locally by the P2PE application due to operating system or firmware constraints, CPU access restrictions, or tamper-resistance mechanisms? A It is the expectation of PCI SSC that a P2PE assessor conducting an application vendor assessment is given sufficient access to both the device and application …
Q 3 July 2014
• Is it expected that applications on a hardened P2PE device be assessed according to Domain 2 requirements (for example, 2A-1.2.c) if forensics tools are not able to observe any data stored locally by the P2PE application due to operating system or firmware constraints, CPU access restrictions, or tamper-resistance mechanisms? A It is the expectation of PCI SSC that a P2PE assessor conducting an application vendor assessment is given sufficient access to both the device and application …
• Is it expected that applications on a hardened P2PE device be assessed according to Domain 2 requirements (for example, 2A-1.2.c) if forensics tools are not able to observe any data stored locally by the P2PE application due to operating system or firmware constraints, CPU access restrictions, or tamper-resistance mechanisms? A It is the expectation of PCI SSC that a P2PE assessor conducting an application vendor assessment is given sufficient access to both the device and application …
Modified
p. 9 → 11
2A-1.2.c Use forensics tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the application and verify that, by following the Implementation Guide instructions, the methodology or process provided by the application vendor renders all PAN and SAD data irrecoverable.
2A-1.2.c • Use forensics tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the application and verify that, by following the Implementation Guide instructions, the methodology or process provided by the application vendor renders all PAN and SAD data irrecoverable.
Modified
p. 9 → 11
2A-2.1.a …the application only exports PAN or SAD that has been encrypted by the approved SRED functions of the PCI-approved POI device.
2A-2.1.a • …the application only exports PAN or SAD that has been encrypted by the approved SRED functions of the PCI-approved POI device.
Modified
p. 10 → 12
Q 3 July 2014
• Is there an exception to the requirement that the application can only export PAN or SAD encrypted by the firmware of the PCI-approved POI device for those areas where there is a legal or regulatory obligation to print the full PAN on merchant receipts? A See 3B-3.1, “Merchant cannot view full PAN,” in Domain 3 below.
• Is there an exception to the requirement that the application can only export PAN or SAD encrypted by the firmware of the PCI-approved POI device for those areas where there is a legal or regulatory obligation to print the full PAN on merchant receipts? A See 3B-3.1, “Merchant cannot view full PAN,” in Domain 3 below.
Q 5 July 2014
• Is there an exception to the requirement that the application can only export PAN or SAD encrypted by the firmware of the PCI-approved POI device for those areas where there is a legal or regulatory obligation to print the full PAN on merchant receipts? A See 3B-3.1, “Merchant cannot view full PAN,” in Domain 3 below.
• Is there an exception to the requirement that the application can only export PAN or SAD encrypted by the firmware of the PCI-approved POI device for those areas where there is a legal or regulatory obligation to print the full PAN on merchant receipts? A See 3B-3.1, “Merchant cannot view full PAN,” in Domain 3 below.
Modified
p. 10 → 12
2A-2.1 The application only exports PAN or SAD data that has been encrypted by the firmware of the PCI-approved POI device, and does not export clear-text PAN or SAD outside of the device.
2A-2.1 • The application only exports PAN or SAD data that has been encrypted by the firmware of the PCI-approved POI device, and does not export clear-text PAN or SAD outside of the device.
Modified
p. 10 → 12
Q 4 July 2014
• Can a P2PE PCI-approved POI device have a “separation layer” that is assessed once in a P2PE assessment and thereafter relied upon to provide sufficient separation that applications on the device with no access to cardholder data can be excluded from review? A PCI SSC believes there may be security risks that won’t be addressed if these applications are excluded from further assessment and maintenance requirements. In general, the only requirement that applies to applications that …
• Can a P2PE PCI-approved POI device have a “separation layer” that is assessed once in a P2PE assessment and thereafter relied upon to provide sufficient separation that applications on the device with no access to cardholder data can be excluded from review? A PCI SSC believes there may be security risks that won’t be addressed if these applications are excluded from further assessment and maintenance requirements. In general, the only requirement that applies to applications that …
Q 6 July 2014
• Can a P2PE PCI-approved POI device have a “separation layer” that is assessed once in a P2PE assessment and thereafter relied upon to provide sufficient separation that applications on the device with no access to cardholder data can be excluded from review? A PCI SSC believes there may be security risks that won’t be addressed if these applications are excluded from further assessment and maintenance requirements. In general, the only requirement that applies to applications that …
• Can a P2PE PCI-approved POI device have a “separation layer” that is assessed once in a P2PE assessment and thereafter relied upon to provide sufficient separation that applications on the device with no access to cardholder data can be excluded from review? A PCI SSC believes there may be security risks that won’t be addressed if these applications are excluded from further assessment and maintenance requirements. In general, the only requirement that applies to applications that …
Modified
p. 10 → 12
2A-3 All applications without a business need do not have access to account data.
2A-3 • All applications without a business need do not have access to account data.
Removed
p. 11
• for example, it is a handheld or wireless device
Modified
p. 11 → 13
3A-2.4 Physically secure POI devices in transit, including:
3A-2.4 • Physically secure POI devices in transit, including:
Modified
p. 11 → 13
Packing devices in tamper-evident packaging prior to transit.
Modified
p. 11 → 13
Implementing procedures for determining whether device packaging has been tampered with.
Modified
p. 11 → 13
Use of a defined secure transport method, such as bonded carrier or secure courier.
Modified
p. 11 → 14
Q 2 July 2014
• Are POI devices required to be physically secured(e.g. bolted to a counter-top or tethered with a cable) in the merchant environment? How does this requirement apply to handheld/wireless POI devices? A The intent of this requirement is for the solution provider to provide instructions in the PIM about how to physically secure the POI device
• for example, if the device has a cable connection or a fixed bracket, the PIM should describe how to use …
• Are POI devices required to be physically secured
• for example, if the device has a cable connection or a fixed bracket, the PIM should describe how to use …
Q 2 July 2014
• Are POI devices required to be physically secured (e.g., bolted to a counter-top or tethered with a cable) in the merchant environment? How does this requirement apply to handheld/wireless POI devices? A The intent of this requirement is for the solution provider to provide instructions in the PIM about how to physically secure the POI device
• for example, if the device has a cable connection or a fixed bracket, the PIM should describe how to use …
• Are POI devices required to be physically secured (e.g., bolted to a counter-top or tethered with a cable) in the merchant environment? How does this requirement apply to handheld/wireless POI devices? A The intent of this requirement is for the solution provider to provide instructions in the PIM about how to physically secure the POI device
• for example, if the device has a cable connection or a fixed bracket, the PIM should describe how to use …
Modified
p. 11 → 14
If a POI device is not intended to be secured in one place
•for example, it is a handheld or wireless device
•the solution provider is expected to provide merchants with instructions for how to implement process controls to protect the device. Examples of process controls could include storing the device in an area inaccessible to the public when the device is not in use, assigning responsibility to specific personnel for supervising use of the device, and so on. Again, the solution …
•for example, it is a handheld or wireless device
•the solution provider is expected to provide merchants with instructions for how to implement process controls to protect the device. Examples of process controls could include storing the device in an area inaccessible to the public when the device is not in use, assigning responsibility to specific personnel for supervising use of the device, and so on. Again, the solution …
Modified
p. 11 → 14
3A-4.2 Provide instructions via the P2PE Instruction Manual for the merchant to physically secure deployed devices to prevent unauthorized removal or substitution, including examples of how devices can be physically secured.
3A-4.2 • Provide instructions via the P2PE Instruction Manual for the merchant to physically secure deployed devices to prevent unauthorized removal or substitution, including examples of how devices can be physically secured.
Modified
p. 11 → 14
3A-4.2.1 Provide instructions via the P2PE Instruction Manual for the merchant to implement procedures to prevent unauthorized removal or substitution of devices that cannot be physically secured (such as wireless or handheld devices).
3A-4.2.1 • Provide instructions via the P2PE Instruction Manual for the merchant to implement procedures to prevent unauthorized removal or substitution of devices that cannot be physically secured (such as wireless or handheld devices).
Modified
p. 12 → 14
3B-1 The solution provider securely maintains devices being returned, replaced, or disposed of, and provides related instructions to merchants.
3B-1 • The solution provider securely maintains devices being returned, replaced, or disposed of, and provides related instructions to merchants.
Modified
p. 13 → 15
SRED passes the clear-text PAN to an application that transmits the PAN internally within the device for printing. Since this application sees clear-text PAN, it must be assessed to Domain 2 and listed on the PCI SSC website. The application can only transmit clear-text PAN to an integrated printer•this printer is part of the PCI-approved POI device itself and is not attached via cabling or other networking mechanisms. This application cannot transmit PAN to any other device, process, …
Modified
p. 13 → 15
3B-3.1 The solution provider ensures merchant has no administrative access to the device and cannot change anything on the device that could impact the security settings of the device. Merchant access if needed, must meet the following:
3B-3.1 • The solution provider ensures merchant has no administrative access to the device and cannot change anything on the device that could impact the security settings of the device. Merchant access if needed, must meet the following:
Modified
p. 13 → 15
…Cannot view or access full PAN.
Removed
p. 14
• Testing procedures 6E-4.1.c & d specify unique POI keys
• does this mean that unique public encryption keys must exist for each POI? The intent of this requirement is that all secret and private cryptographic keys used in transaction-originating POI devices for any function directly or indirectly related to account data protection are unique per POI device. The intent is not that each individual POI must have its own public encryption keys, but that where a POI does have its own public/private key pairs (for example, for authentication or key conveyance), the private key(s) owned by the POI and its associated public key(s) must be unique per POI. Therefore, the focus of the test at 6E-4.1.c & d are, IF POIs have their own public/private key pairs, to confirm that each individual POI has a unique public key(s), and thereby confirm the uniqueness of each POI’s private key(s).
• does this mean that unique public encryption keys must exist for each POI? The intent of this requirement is that all secret and private cryptographic keys used in transaction-originating POI devices for any function directly or indirectly related to account data protection are unique per POI device. The intent is not that each individual POI must have its own public encryption keys, but that where a POI does have its own public/private key pairs (for example, for authentication or key conveyance), the private key(s) owned by the POI and its associated public key(s) must be unique per POI. Therefore, the focus of the test at 6E-4.1.c & d are, IF POIs have their own public/private key pairs, to confirm that each individual POI has a unique public key(s), and thereby confirm the uniqueness of each POI’s private key(s).
Modified
p. 14 → 17
6E-4.1.d Compare all POI public keys, if used, across all decryption points as well as for every POI connection, to ensure there are no duplicates across POI devices.
6E-4.1.d • Compare all POI public keys, if used, across all decryption points as well as for every POI connection, to ensure there are no duplicates across POI devices.