2019 PCI PTS POI Security V5技术FAQ全览：关键问题解答

需积分: 15 55 浏览量更新于2024-07-15 收藏 809KB PDF 举报

"PCI认证规范FAQs是Payment Card Industry（PCI）针对Point-of-Interest（POI）设备安全要求的一份技术指南，适用于Version 5。这份文档由2013年至2018年期间的PCI Security Standards Council所有，旨在解答在评估和实施POI设备时遇到的常见问题。它详细列出了多个POI设备的安全要求，包括但不限于： - A系列要求：A1至A10涵盖了涉及数据加密、存储和传输的安全控制，如A1关于设备必须支持PCI Data Security Standard (DSS) Level 1的加密，A3关注设备在处理卡片数据时的完整性和保护措施，A4和A5涉及数据生命周期管理，A6则强调了远程访问和审计功能。 - B系列要求：B1至B20涉及物理安全、网络配置、日志记录和访问控制，例如B1要求设备应有物理防护措施，B4关注设备连接到网络的限制，B11和K17可能涉及灾难恢复计划和应急响应措施。 - C和D系列要求：C1涉及到安全政策和程序，D1至D4则关注日常管理和维护，确保合规性，如D3规定定期进行安全更新和漏洞扫描。这份文档提供了对如何符合PCI POI标准的关键指导，帮助企业在部署和维护POI设备时确保支付卡数据的保护，以避免潜在的数据泄露风险，符合PCI DSS标准，从而维护消费者信任和避免法律罚款。对于任何计划或正在实施PCI POI设备的组织来说，理解和遵守这些技术FAQs是至关重要的。"

PCI PTS POI Evaluation FAQs – Technical – For Use with Version 5 May 2019

Q 34 May 2011: For attack-potential calculations, if the same equipment used for the

identification phase can be reused for exploitation, the equipment cannot be accounted for

twice, but instead must be divided by two and spread equally over the two phases. Does a

similar rational apply where parts are reused?

No. While equipment readily lends itself to reuse for each exploitation, parts are typically a one-

time use for each exploitation. Each exploitation should have the same attack potential value.

Accounting for parts that are reused in the initial exploitation only in the Identification phase, or

even splitting between the Identification and Exploitation phases, will result in the initial

exploitation having a lower attack-potential value than the actual subsequent exploitations.

Therefore, 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.

Q 35 May (update) 2018: PIN entry devices may physically integrate in the same device other

functionality, such as mobile phone, PDA capabilities or POS terminal. Handheld

configurations of PIN entry devices may accommodate the attachment (e.g., via a sled,

sleeve or audio jack) of a mobile phone, PDA or POS terminal, where the attached device

communicates with the PED. Such a configuration appears as a single device, with

separate interfaces for input by the clerk and cardholder. What considerations must be

taken into account for either of these configurations?

For any device where the cardholder is expected to use the same interface for PIN entry as the

clerk would use for phone, PDA, payment application, etc. purposes, or where there are multiple

interfaces in a single integrated device, the integrated device must be physically and logically

hardened in accordance with the PTS POI security requirements.

In a handheld configuration with an attached device, there is a risk that the cardholder enters the

PIN on the wrong interface. Furthermore, the communication interface between the PED and the

attached device may give the latter access to MSR functions without cryptographic controls,

allowing skimming of card account data. In this integration model, then either:

▪ Both devices are assessed and validated as compliant to the PTS POI requirements, or

▪ The PED device, which must also control the card reader(s), must implement and be

validated against the PTS POI SRED module. The PED must enforce SRED functions for

encryption of card data at all times. The PED is only allowed one state, and that is to

encrypt all account data. It cannot be configured to enter a state where account data is not

encrypted.

PCI PTS POI Evaluation FAQs – Technical – For Use with Version 5 May 2019

Q 37 October (update) 2018: Are Bluetooth/Wi-Fi interfaces part of the evaluation?

Bluetooth and/or Wi-Fi, like any other open security protocol declared in the POI Protocol

Declaration form, must be assessed by the laboratory.

If a Bluetooth interface is used, the Bluetooth interface must enforce encryption. This encryption

is in addition to any other encryption the data may have undergone. If PIN or passkey entry is to

be used, the evaluator must validate that vendor default values can be changed. The device

must not support or allow for the use of insecure communication options such as, but not limited

to, security modes 1 &2 and the “Just Works” secure pairing option of security mode 4.

For Bluetooth 4.1 or higher devices that have BR, EDR, and High Speed (HS) features, Security

Mode 4, Level 4 must be used. This requires Secure Connections, which uses authenticated

pairing and encryption using 128-bit strength keys generated using FIPS-approved Advanced

Encryption Standard (AES) encryption. For Bluetooth 2.1 through 4.0 devices, Security Mode 4,

Level 3 must be used.

If a Wi-Fi interface is used, the Wi-Fi interface must enforce encryption. This encryption is in

addition to any other encryption the data may have undergone. Security must be enabled. WEP

cannot be used or configured at any time, and WPA and/or WPA2 must be

supported. If passkey is used, it must not be a vendor default. The evaluator must validate that

default values can be changed on the target of evaluation.

Where the interface is supplied by an OEM module:

• If the module is under the control of the firmware and runs in the same space as the

firmware, the OEM interface module must still be assessed to ensure secure pairing (for

wireless technologies listed above) is provided for and that secure communications is

enforced by the interface.

• If an independent OEM module is used:

▪ The protocol and the pairing mechanism must be assessed and

▪ The security of the link between the module and the firmware must be assessed

• If the OEM module shares resources with the rest of the device then a vulnerability

assessment is required to ensure that the OEM module cannot adversely impact the function

of the device.

OEM modules that are found to have unaddressed exploitable vulnerabilities may result in the

removal of the entire POI device approval.

PCI PTS POI Evaluation FAQs – Technical – For Use with Version 5 May 2019

Q 38 December 2011: Specific requirements are identified in the Core and SRED modules that

Secure Card Readers must be validated against. Are there any other requirements that

must be considered?

Yes, all of the non-designated SRED requirements should be considered for applicability. In

most cases they will not be applicable and will not require any assessment beyond that

determination.

Q 39 June 2012: If a device supports multiple IP enabled interfaces, does testing need to be

performed on all IP enabled interfaces by the laboratory during the evaluation?

If a device supports multiple IP enabled interfaces and the IP stack (including all IP Protocols, IP

Services and IP Security Protocols) are identical for all interfaces, testing is only required to be

performed on one of the IP enabled interfaces.

Q 40 June 2012: During an evaluation, it is determined that a new device includes the identical IP

stack that was previously evaluated and approved under the most recent version of the

Open Protocols Requirements module. Is it required to redo all Open Protocols testing?

If the vendor is able to provide evidence that supports the assertion that the IP stack is 100%

identical, including the same version of various components and identical IP Protocols, IP

Services and IP Security Protocols, no new testing needs to be performed. The report should

document how it was verified that the IP stack is identical and shall include the IP stack

information including the component version, the IP Protocols, IP Services and IP Security

Protocols supported.

Q 41 June 2012: The approval requirements for an SCR or Non-PIN device do not include PCI

PTS DTR A1, which requires active tamper-response mechanisms. Is it possible to meet the

physical security requirements of an SCR or Non-PIN device using only tamper resistance

and tamper evident characteristics, if the attack costing can be shown to exceed the

minimum levels required for each of the physical security testing requirements?

No, it is a requirement that all devices implement active tamper detection mechanisms to meet

the physical security requirements of PCI PTS. SCR and Non-PIN devices must have

permanently active tamper detection mechanisms that monitor for intrusion and respond to such

events with the immediate erasure of sensitive information within the device, rendering the

device inoperative.

Q 42 September 2012: Vendors may provide application toolkits for third parties to develop

applications that cannot impact any of the functionality needed to comply with PCI

requirements. The exceptions to this are for alteration of display prompts by third parties

and for SRED applications developed by third parties, subject to controls stipulated in the

PTS POI Derived Test Requirements and these FAQs. Can a vendor provide a toolkit that

allows third parties to implement applications that supplant the cryptographic processing

of PCI Payment Brand PIN data that is provided for in the approved vendor firmware?

No, the addition of applications that replace or disable the PCI evaluated firmware functionality

invalidates the device approval for each such implementation unless those applications are

validated for compliance to PTS POI Security Requirements and listed as such in the approval

listings. Specifically, those applications must be validated to ensure that:

▪ It cannot adversely affect the security features of the product that are relevant to the PCI

POI approval.

剩余72页未读，继续阅读

holly_huang

粉丝: 111
资源: 98

2019 PCI PTS POI Security V5技术FAQ全览：关键问题解答

PCI_PTS_PO__DTRs_v5-1.pdf

POI技术文档

auto pts_vec = pts_vector_queue.front()

``` gw._LiDAR2LiDARPerception_Required.s.set_queue(&pts_vector_queue);```请编写c++代码应用上述代码示例

``` auto pts_vec = pts_vector_queue.front();```如果将这行原本写在主函数的主循环中的代码放到主函数外一个自定义的void函数中，应该如何修改，结合具体c++代码

pts_3d_ori = pm[pts_2d_ori[:, 0], pts_2d_ori[:, 1], :]

at pts_4d; cv::triangulatePoints(T1, T2, pts_1, pts_2, pts_4d);

最新资源