Common Criteria Evaluation and Validation Scheme

National Information Assurance Partnership (NIAP)

Title: Retransmission Device

Maintained by: National Information Assurance Partnership (NIAP)

Unique Identifier:

Version: 1.6

Status: draft

Date of issue: 26 June 2024

Approved by:

Supersedes:

Background and Purpose
This document describes a core set of security requirements for 3 different flavors of a Retransmission device. They will be referred to as RD, ERD and HWS-ERD (Retransmission Device, Encrypting Retransmission Device and Hardware Separated Encrypting Retransmission Device respectively). These are small form factor devices to provide isolation, authentication and/or confidentiality for a EUD (End User Device) or set of EUD’s that must interoperate with an Untrusted Domain. The main goal of the RD use case is to provide network transport and simple isolation of the EUD. The ERD use case is intended to provide an independent layer of encryption on top of the existing network transport. The encryption done by an RD as a stand alone device will authenticate the endpoint in addition to adding confidentiality of the traffic. The HWS-ERD use case is intended to provide the most robust isolation between the network transport and EUD on top of the encryption of the ERD. The functionality and requirements are intended to be inherited as the use case moves from RD to HWS-ERD, as much as reasonable. If the RD requires X, then the ERD and HWS-ERD will require X too unless unreasonable or inappropriate.

RD

The basic RD is a lightweight computing device that acts as both a retransmission device and a boundary. The RD sits between a EUD (End User Device) and the untrusted transport network as illustrated in Figure 1. The interconnect IC1 between the EUD and the RD is always a wired connection. The connection IC2 to the transport network can be any media, wired or wireless. IC1 and IC2 may or may not be in the same network address space depending on the use case.

Figure 1:

Figure 2 illustrates the RD as a boundary filter implemented as a stateless firewall. FW2 is filtering untrusted traffic on IC2 and FW1 is filtering EUD traffic on IC1. The FW could be the same application or 2 separate applications. It may filter in one or both directions of IC1 or IC2.

Figure 2:

The RD can be managed through one of the following methods: local management through a dedicated management interface, managed through the WAN interface (IC2) from a trusted management service or from the LAN interface (IC1).

ERD

The ERD is an RD with the additional capability to encrypt all traffic from the EUD through the LAN interface (IC1) to form an encrypted tunnel to another encryption end-point through the ERD’s WAN interface (IC2). This ensures that all traffic from the EUD is encrypted coming from the EUD and is intended to protect this traffic over an untrusted network.

Figure 3 illustrates the ERD as a dedicated encryption layer. The encryption can be link layer oriented (i.e. MACsec), network layer oriented (i.e. IPsec) or may even be the Wi-Fi link itself assuming that it is connecting to a trusted WLAN Access System. It will include firewall configurations from the RD use case.

Figure 3:

HWS-ERD

An HWS-ERD will encrypt traffic between two endpoints while maintaining a defined physical and logical protocol break between the trusted and the untrusted trusted domains. The protocol break will be both physically and logically enforced. This forms the most complete security argument for isolation, authentication and confidentiality of the 3 use cases. Additionally, a HWS-ERD is cryptographically bonded to another HWS-ERD and once bonded they are meant to only work as a pair to create and autonomously manage a point to point encrypted tunnel as illustrated in Figure 4. By only being a pair they will not require functionality typically needed to handle cryptographic nets larger than 2 nodes. Simplicity.

Figure 4:

A more granular view of an HWS-ERD pair is in Figure 5. An HWS-ERD consists of at least 2 physically separate computing units whose functionality is Encryption and Communication respectively. They will be referred to as Encryption Unit (EU) and Communication Unit (CU). The main distinction between HWS-ERD and the ERD is the protocol break between the EU and CU. It is defined and can be soundly defended. The EU interface (IC3) only needs to process a singular frame type and can accurately and safely discard any other frame, unlike the interface connected to the Untrusted Fabric (IC2) which must account for and process the extensive protocol complexity of the transport network in addition to performing cryptography. A bug anywhere in that large stack can bypass the encryption altogether if the IC2 processing and encryption occur on the same machine. In contrast, the EU active software stack at IC3 will be vastly smaller than the software stack at IC2 on the CU thereby reducing the odds of any exploitable condition to the minimum of one. Finally, adding to the binary frame check is a cryptographic operation that cannot be easily spoofed.

Figure 5: HWS-ERD end to end view

The EU and CU are physically independent. They must not share any hardware such as memory, cache, or other internal infrastructure typical of computers. Examples that meet this requirement might be a pair of SoC’s, each running an instance of Operating System, or a microProcessor and a microController, or an FPGA and a microProcessor. A pair of virtual machines running on a single computer does not meet this separation requirement.

The CU interface at IC2 could be wireless (Bluetooth, WiFi, 5G, Microwave, etc.) or wired media (ethernet, fiber, USB, serial, etc.) depending on specific use case. There is no restriction. For example, where the Untrusted domain is an Ethernet:IP based network, the CU would need an RJ45 interface. That interface is then assigned an IP address and the destination IP address of its peer CU is assigned to the function that transfers packets to and from the EU. The Untrusted domain (not the CU) will handle the routing between ERD’s. The CU functions as a translation layer between IC3 and IC2 as well as a network interface to IC2.

IC1 and IC3 are always wired media.

The EU-to-EU association is a link layer (layer 2) tunnel and not a layer 3 or higher tunnel. However, a layer 3 (or higher) tunnel can independently exist between CU-to-CU to transport the EU-to-EU frames. The CU-to-CU tunnel is out of scope for this document.

The CU and EU must be managed independently from the untrusted and trusted domain respectively. There is no cryptographic bypass. Thus the network address space of IC1 is independent of the network address space of the IC2. The isolation boundary of IC3 in Figure 5 (intentionally) prevents them from being managed from a common location. Managing the CU from the trusted domain, either through the EU or around the EU is not in scope of this document. Because the association is only between a pair of HWS-ERD’s, they can autonomously manage themselves if that is sufficient for a use case. However, the EU can be manually managed (from the trusted domain) by an additional virtual or physical interface on the EU, depending on the use case requirements. Both ends of the link do not have to be managed. One managed end can be sufficient for the link.

An even more detailed view of a HWS-ERD in Figure 6 illustrates the protocol break between the black and red networks that produces a defined, defendable boundary at interface b and a.

Figure 6:

Use Cases
This technology has many specific use cases. It can serve as an independent filter to restrict traffic flows in either direction to the EUD. For encryption purposes, the basic principle is to agnostically inject an encryption operation transparently between 2 endpoints that already communicate without that encryption operation. For example, a mobile phone (the phone radio is disabled) running a VPN with through an HWS-ERD in a sleeve to a remote enterprise HWS-ERD + VPN + VOIP service. Or a satellite to a ground station. Or a Satellite-to-Satellite link. An IoT edge device (e.g. thermostat) to a server. A substation to the main power station. Factory automation between controller and robot. A UAV to its controller or UAV to UAV. A link between an automobile and the manufacturer for updates and telemetry. Isolation of a subsystem within a system, e.g. separate the audio ECU from the engine ECU’s running on the automobile CAN bus. A branch office to another branch office. The EUD in the trusted domain can be one or many devices. The ERD pair can also act as an additional authentication mechanism since there is a unique cryptographic association with those 2 devices. For example, a service technician can be authenticated when doing remote maintenance merely by having one end of the ERD pair while the other end is at the ingress point to the system being maintained.

It must be noted that as you move from Figure 1 to Figure 6, the level of assurance of the security arguments (i.e. isolation, authentication and confidentiality) moves from marginal to significantly enhanced and preferred. Figure 2 combined with Figure 3 provides good security. Figure 2 and Figure 3 implemented as Figure 5/6 provides better security. With an HWS-ERD the need for patching is less critical because the software stack guarding the trust boundary is very small and very simple, thus won't have the latent risk that fat stacks have and require oversight to compensate for the occaisional bug. With an HWS-ERD, key management is unnecessary because the pair will autonomously take care of it.

However, in formal Common Criteria evaluations we seek evaluation only of solutions designed to: 1) replace commercial networking capability internal to an EUD with an external device (e.g. Ethernet, LTE, Wi-Fi, firewall, etc.) 2) provide an encrypted tunnel to protect data in transit between EUD’s over said external interface.
Resources to be protected
Evaluation Boundary
Referencing Figure 1 and 2 above, the evaluation boundary consists of the applications performing the firewall functions and network functionality.

Referencing Figure 3, the evaluation boundary is expanded to include the encryption and cryptographic link functionality of the ERD which would fall under MACsec, IPsec and WLAN Client.

Referencing Figure 5 and 6 above, the evaluation boundary consists of the hardware/software within the two HWS-ERD modules (HWS-ERD 1 and HWS-ERD 1’) as well as the cryptographic link between the modules. Most critical is the interface infrastructure to process data entering and leaving EU1 and EU1’ within the blue dashed box.

What is not in the evaluation boundary is the EUD or the CU in the case of the HWS-ERD.
Essential Security Requirements

Requirements of each use case are generally inherited by the subsequent use cases. Retransmission Device (RD):

Encrypting Retransmission Device (ERD):

Hardware Separated Encrypting Retransmission Device (HWS-ERD):
Assumptions
An attacker is assumed to attempt attacks from the following vantage points:
Optional Extensions
Objective Requirements
Outside the Scope of Evaluation
The following list contains items that are explicitly out-of-scope for any evaluation against the product PP: