PSD v5.0: Port-equivalence evaluation activities

Issue

Repeating detailed security tests across every port-to-port combination can substantially increase evaluation effort where channels share the same security-relevant design.

PSD v5.0 should permit representative testing, subject to a documented developer rationale and independent CCTL assessment. The approach must distinguish between logical equivalence and physical/analog-leakage equivalence.

This proposal changes the testing methodology, not the security requirements or pass/fail criteria.

1. Logical equivalence

For protocol handling, filtering, domain selection, and other logical security functions, ports may be grouped into test-specific equivalence classes where the CCTL confirms equivalent:

• Security-relevant hardware and firmware/software;
• Port configuration, addressing, and enforcement policy;
• Peripheral functions and protocol handling; and
• State transitions, shared-resource interactions, and residual-data handling.

Identical connectors or a common firmware version alone are insufficient. Port-specific configuration and implementation differences must be considered.

The full applicable logical tests may then be performed on representative members of each class. Basic port mapping, selection, and isolation checks shall still exercise every physical port.

Equivalent individual ports do not automatically establish equivalent port-to-port paths. Different switching boundaries, traffic directions, or selected/unselected relationships may require separate coverage.

2. Physical isolation and analog leakage

Logical equivalence shall not, by itself, justify reducing electrical-isolation, crosstalk, or analog-leakage testing.

For these tests, the CCTL shall independently identify and assess the potentially worst-case source/destination port combinations using design evidence, physical inspection, and targeted screening measurements.

The assessment should consider, as applicable:

• Physically neighbouring connectors and connector pins;
• Adjacent or overlapping PCB traces, their parallel routing length, and layer arrangement;
• Channels sharing switching components, packages, power supplies, or return paths;
• Internal cable proximity, shielding, and enclosure arrangements; and
• Differences in filtering, isolation components, loading, and operating states.

Neighbouring external ports are candidates for worst-case testing, not an automatic substitute for examining the internal implementation.

The worst-case pair may differ by frequency, signal type, direction, or operating state. The CCTL shall therefore identify a set of worst-case combinations where one pair cannot represent all relevant conditions.

3. Evaluation approach
The proposed Evaluation Activity should require the CCTL to:

1. Assess logical and physical coverage separately. Identify the tests eligible for logical representative sampling and those requiring a physical-leakage assessment.
2. Select and validate worst-case physical paths. Review the developer’s evidence, inspect the implementation, and use screening measurements sufficient to challenge the proposed selection and investigate alternative coupling paths.
3. Perform the full applicable measurements on the selected paths. Retain the prescribed frequency ranges, signal levels, loading, operating states, measurement sensitivity, and acceptance limits. Where relevant, include concurrent activity on other ports.
4. Justify omitted combinations. Explain why the tested cases adequately cover the untested paths. An absence of detected leakage is not sufficient unless the measurement sensitivity can demonstrate compliance with the applicable limit.
5. Expand testing when necessary. If results contradict the equivalence rationale, reveal unexpected coupling, or do not support a defensible worst-case selection, test additional combinations up to the full applicable set.

Required documentation
The evaluation report shall include a coverage matrix mapping each affected test to its tested and represented ports, paths, directions, and states.

For logical tests, record the equivalence rationale. For physical-leakage tests, record the worst-case selection rationale, supporting screening results, measurement conditions, and justification for omitted combinations.

Requested change
Add this bounded testing option directly to the relevant Evaluation Activities in the base PP and applicable PP Modules.

The option should reduce repeated logical testing while requiring CCTL-led, evidence-based worst-case selection for physical leakage. Where either justification is insufficient, the existing full test coverage remains applicable.

Locate the relevant Evaluation Activities in the base PP and applicable PP Modules, then compare their existing full test coverage with this proposed bounded option. Done means the documents separately address logical equivalence and physical leakage, require the stated coverage matrix and rationales, and retain full coverage when justification is insufficient.