If you are working on building a CSfC approved solution for Mobile Access, you’ve probably run into the term “retransmission device” on your journey.
This article will break down what a retransmission device is, when you need it, and alternatives to retransmission devices that still satisfy the CSfC Mobile Access Capability Package.
Depending upon your goals and your desired architecture, you may or may not need a retransmission device.
What is a CSfC retransmission device?
In CSfC Mobile Access deployments, retransmission devices (RDs) are used to protect communications across untrusted networks by providing a layer of obfuscation between the components of your CSfC solution and components that control communication across untrusted networks like Wi-Fi, LTE, 4G or 5G networks.
The retransmission device will have an internal connection to your solution infrastructure, via the Black network, and on the external side, can be connected to any type of medium like cellular, Wi-Fi, SATCOM, or Ethernet to gain network access.
Why do I need a retransmission device in my CSfC MACP solution?
The reason for requiring an RD when on untrusted networks is to ensure that by the time any cellular modems (or components that are responsible for transmitting data) touch the data, it has already been encrypted twice.
Commonly referred to within the DoD as the "baseband problem", cellular chips allow external control, or access, from the cell towers that connect them to the network.
For instance, when your phone connects to a cell tower, your carrier has access to configure and tune settings on the cellular chip to enhance call quality and connection. This means that, in some form, external parties are able to execute changes, and potentially hijack the cellular chip.
In order to ensure that data is protected in the event this happens, it is very important to separate the functions of the cellular chip from other functions that involve accessing data, or controlling the CSfC solution like major CPU functions or direct memory access.
Additionally, with an RD, any data that is to be transmitted will have already been encrypted twice, thus being able to safely traverse over black networks, by the time the cellular chip touches it.
At this point, there is no longer risk to the data, so access from an outside party is not an issue.
When do I need a CSfC retransmission device?
You need a retransmission device in your CSfC architecture if you are building a solution based on the Mobile Access Capability Package and you do not have a dedicated outer encryption component.
Essentially, if you are using a combination of two software-based VPNs to create your inner and outer encryption tunnels, you will need a retransmission device.
Alternatives to CSfC retransmission devices
You do not need a retransmission device if you are using a dedicated outer encryption component, like Attila’s GoSilent hardware VPN.
A hardware-based VPN that obfuscates the CSfC solution and all of its components from the networks it is transmitting through serves the same purpose as a retransmission device, and can provide the same layer of obfuscation between the components of your CSfC solution and untrusted networks like Wi-Fi, LTE, 4G or 5G networks.
Choosing the right hardware VPN instead of a software VPN for your outer encryption tunnel means that the endpoint devices never actually touch the networks they connect to. For example, Attila's GoSilent device acts as a firewall between the device it is connected to and the outside world. No other devices on the same network can even see that the device itself exists. Instead, their view ends at the GoSilent Cube.
Essentially, choosing the right hardware VPN for your outer encryption tunnel eliminates the need to have an RD in your architecture, but affords all the same abilities to connect to a wide variety of untrusted networks.
If you’re building a Mobile Access CSfC solution, it is important to know how your architecture and component choices affect your need for a retransmission device. If you have questions or want to discuss potential CSfC solution architectures, we are happy to help!