PSD v5.0: USB audio output through an analog isolation boundary

Allowing USB hubs and composite devices does not, by itself, define how a PSD can securely support their audio functions.
Improtant note: This proposal supports digital audio interfaces while retaining an analog security boundary. It should not authorize an unrestricted, entirely digital audio path.

PSD v5.0 should explicitly permit USB audio output where the TOE terminates the USB protocols and transfers the permitted audio through a unidirectional, band-limited analog boundary. This would support USB-connected speakers and the playback function of headsets or sound bars without permitting transparent USB forwarding between protected computers and the shared peripheral.

This is a narrowly scoped functional extension, not merely an editorial clarification.

Proposed approach

Permit an optional USB audio-output implementation using the following arrangement where both external interfaces are USB:

Host USB → TOE audio emulation/DAC → filtered analog isolation path → TOE ADC/USB interface → USB audio peripheral

All conversion, filtering, switching, and protocol-termination components relied upon for isolation shall be inside the TOE boundary.

The implementation shall:

• Provide an independently isolated host-facing audio interface for each protected computer.
• Transfer only the selected host’s permitted audio through the analog path.
• Terminate USB enumeration, control transactions, and any required feedback locally on their respective sides; these shall not become a digital bypass across the isolation boundary.
• Prevent peripheral-originated traffic or another host’s data from reaching a protected computer through the shared audio function.
• Prevent unauthorized microphone, storage, HID, vendor-specific, or firmware-update functions from being exposed through this audio-output option.
• Prevent buffered audio or retained peripheral state from creating a cross-domain path during selection changes, reset, or reconnection.

Directly switching a shared USB audio codec between protected computers shall not satisfy this option.

Mandatory analog filtering

Analog band-limiting shall remain mandatory. The amendment should retain applicable audio-output attenuation limits and specify the required passband, transition region, and stopband behavior.

The TOE shall implement reconstruction filtering after digital-to-analog conversion and anti-alias filtering before analog-to-digital conversion. Digital filtering alone shall not substitute for the required analog protection.

These controls limit unwanted signal propagation; they do not claim to eliminate information encoded within the permitted audio band.

Evaluation considerations
The CCTL should:

1. Review the architecture and verify that no USB forwarding, shared memory, or uncontrolled control path bypasses the analog isolation boundary.
2. Exercise supported USB functions and attempt unauthorized interfaces, control requests, and alternate configurations to verify local termination and enforcement.
3. Measure the analog frequency response and attenuation, including out-of-band modulation and potential aliasing, across the supported operating modes.
4. Verify reverse-direction isolation and leakage between host channels, using independently justified worst-case physical paths.
5. Test domain switching, reset, disconnect/reconnect, and buffered-audio handling for cross-domain leakage and incorrect association.

Requested change and scope
Add the optional USB audio-output requirements and corresponding Evaluation Activities directly to the applicable audio-output PP Module, amending any conflicting interface restrictions.

This issue does not authorize microphone input, simultaneous multi-host audio mixing, camera functions, or unrestricted USB peripheral sharing. Those capabilities require separate consideration.

Start with the applicable audio-output PP Module and its existing interface restrictions, attenuation limits, and Evaluation Activities. Map the proposed USB audio-output requirements and analog filtering checks against those sections, then verify that conflicting restrictions are identified and that the scope exclusions remain explicit. Done means the module contains the optional requirements and corresponding evaluation activities.