Home >> May 2019 Edition >> Enhancing Transmission Security: Protecting critical communications
Enhancing Transmission Security: Protecting critical communications
by Karl Fuchs, Senior Vice President of Technology, iDirect Government, and Senior Columnist

 

The need to protect the flow of communications to wherever the military and government agencies may operate is critical. Wherever this may be, threat actors readily stand by to monitor, exploit or intercept communications with malicious intent.

Thankfully, Transmission Security (TRANSEC) technology and capabilities are available in the marketplace to mitigate this threat. iDirect Government’s (iDirectGov’s) Evolution software is one example with TRANSEC capabilities, and with the release of Evolution 4.2, the company has further enhanced those abilities by extending protection to cover both one-way and two-way networks.

In combatant situations, where even a small “spike” in traffic can be a critical piece of intelligence, the need to mask any communications activity becomes apparent. The National Security Agency (NSA) has outlined the following vulnerabilities inherent in an IP-based Time Division Multiple Access (TDMA) transmission that must be addressed in order to provide true TRANSEC:

• Channel Activity — The ability to secure transmission energy to conceal traffic volumes.
• Control Channel Information — Disguise traffic volumes to secure traffic source and destination.
• Hub and Remote Unit Validation — Ensure remote terminals connected to the network are authorized users.



TRANSEC requires all network control channels and Management & Control (M&C) data to be encrypted, and that any and all traffic engineering information be obfuscated from an adversary. For example, TRANSEC requires a communications channel to appear completely full to an adversary, even if little or no actual data is flowing.

Contrast this with communications security (COMSEC). With COMSEC, the actual communication (e.g., voice, video or data stream) is encrypted, but certain header information is sent in the clear. While the encryption is virtually impenetrable, the information in the IP header including the source address, destination address and, most importantly, the type of service (ToS) field are visible to the enemy if they are intercepted. This gives the adversary critical information and the ability to determine how much of the traffic stream is voice, video or data. More significantly, an adversary could easily see when high-priority flash-override traffic has been initiated and from which location.

In a traditional SCPC (single channel per carrier) satellite network topology, achieving TRANSEC compliance is relatively straightforward. For SCPC connections, a bulk encryptor is employed to decipher any data and control information traversing the network. The IP header of the packet would be encrypted by the bulk encryptor before being transmitted to the satellite. In addition, since an SCPC link is static, always on and no control information needs to be exchanged between the SCPC modems, all TRANSEC requirements are met.

In a TDMA network, TRANSEC compliance is more difficult. A TDMA network dynamically allocates bandwidth to remotes; therefore, there must be some type of control information transmitted to each device in the network. This control data containing traffic engineering information, as well as information available from an encrypted IP packet header, can be exploited by an adversary.

For example, anomalous traffic volume to a specific remote can indicate new activity in that area while varying ratios of voice-to-data traffic can denote the distribution of intelligence (data) compared to lower priority voice traffic.

While there are several solutions to secure vulnerabilities associated with TDMA very small aperture terminal (VSAT) networks, iDirectGov has found solutions to the following scenarios to be the most successful.

Scenario 1
Masking Channel Activity

The first vulnerability that exists in a TDMA network is the availability of traffic engineering information. In an SCPC network, the link is static with no variation in transmission characteristics based on end user communications. An adversary looking at a satellite transponder with a spectrum analyzer will see a constant RF signal.

Contrast this with a TDMA network. A TDMA in-route carrier energizes and de-energizes as traffic flows and stops. The on-and-off nature of a TDMA in-route is the natural extension of the ability to allocate satellite transponder space to remotes that have transient demands.

Although this characteristic makes TDMA networks much more bandwidth efficient, it allows an adversary to determine peak periods of activity, identify unusual or unexpected activity spikes and identify locations of remotes that have remained quiet for a period and suddenly experience increased traffic volumes. The obvious risk in having this information in the hands of an adversary is the potential to extrapolate timing, location and scale of a strategic activity.

To keep critical information from falling into the enemy’s hands, iDirectGov has implemented free slot allocation in its TDMA bandwidth distribution algorithm. This method basically builds a wall of data keeping adversaries from getting critical data regardless of traffic profiles. As the name implies, free slot allocation keeps the in-routes active despite actual traffic flows. It preserves the efficiencies of a TDMA system while obfuscating actual traffic volumes, negating the risk of using transmission activity as an intelligence gathering mechanism.

Scenario 2
Obfuscating Acquisition Activity

The rate at which remotes get into a network can give critical information to an adversary about troop activities. All TDMA networks provide a dedicated channel for remote acquisition activity. If adversaries monitor the activity in this channel, they will be alerted to troop movements by a flurry of acquisition activity.

To counter this problem, iDirectGov goes beyond TRANSEC requirements by addressing the acquisition activity vulnerability. This acquisition algorithm inserts dummy bursts from remotes already in the network and intentionally skips acquisition bursts at times of high activity, ensuring an adversary sees only a random distribution of acquisition activity.

Taking it a step further, the algorithm randomly varies the dummy burst’s frequency, timing and power. This randomization makes sure an adversary cannot distinguish between a dummy burst and actual acquisition activity.

Scenario 3
Control Channel Information

A great deal of traffic volume and priority information can be gleaned by examining the in-band or out-of-band control information within an encrypted TDMA network.

As previously discussed, the IP header of a packet contains source, destination and priority information. For a TDMA network to provide the quality of service (QoS) needed to support real-time traffic, data quantities and prioritization information must be gathered. Because it is specific enough to delineate between general communications such as email and web traffic versus tactical communications, this information could be more useful to an adversary than channel activity data.

The only solution available for this vulnerability is to completely encrypt all Layer 2 information plus any control information disseminated to the remotes. The encryption methodology must be secure enough to thwart an adversary long enough that the data becomes old and unusable.



Once again, iDirectGov has implemented Federal Information Processing Standard (FIPS) 140-2 certified 256-bit keyed Advanced Encryption Standard (AES) for all Layer 2 and control information. The encryption of the Layer 2 frames has a side benefit of re-encrypting the data payload. Therefore, the transmitted IP header itself is AES-encrypted. Additionally, the iDirectGov TRANSEC TDMA slot is a fixed size, again to obfuscate any traffic characteristics. This Layer 2 encryption solution solves all existing control channel vulnerabilities.

The iDirectGov Layer 2 encryption method goes a step beyond to feature over-the-air (OTA) key updates and a unique Layer 2 frame format, including an Initialization Vector that ensures randomization of repetitive data streams. The net result is that adversaries are precluded from detecting any repetitive pattern, which can aid in deciphering encryption algorithms.

Scenario 4
Hub and Remote Authentication

Another vulnerability of a TDMA VSAT system is the concept of hub and remote validation. In traditional SCPC architectures, a link remains active for very long periods of time when it is established. Because these connections are fixed and there is a significant level of coordination between personnel commissioning the SCPC, a high degree of confidence exists that an adversary is not trying to assume the identity of a trusted entity.

In TDMA networks, remotes are routinely coming into and dropping out of the network. This is especially true of networks with mobile or itinerant terminals where terminals are located in moving vehicles, aircraft and maritime vessels.

This type of dynamic environment gives an adversary a greater opportunity to obtain a VSAT remote through licit or illicit channels, spoof the device ID and insert a rogue remote into a secure network. Equally feasible is an adversary acquiring a VSAT hub terminal and coaxing a “blue force” remote into the adversary’s network.

To mitigate this risk, iDirectGov has implemented X.509 digital certificates on TRANSEC remotes. An X.509 certificate uses RSA public key cryptosystem. With this cryptosystem, two related keys are generated: One private key and one public key. Here’s how the keys work — anything encrypted with the public key can only be decrypted with the private key, and anything encrypted with the private key can only be decrypted with the public key.

In the iDirectGov system, X.509 certificates can be generated via the network management system (NMS) server. Certificates are placed on all TRANSEC line cards and protocol processors as well as on the remotes. The hub system keeps the public keys of each remote configured to operate on the hub, and the remotes have the public keys of each hub device. During network acquisition, the remote encrypts its X.509 certificate with its private key, and the hub verifies by decrypting the certificate with the remote’s public key and vice versa. This process ensures a remote is not only authorized to operate in the network, but that the hub is a trusted entity

Scenario 5
Operational Implementation

Implementing security and ensuring all security policies are followed can be a burden to the soldier in the field. Implementing TRANSEC and performing key management are no exception.

Challenges faced in operating a TRANSEC network include creation, distribution and revocation of X.509 certificates; ACQ and data channel key generation, distribution and management; and zeroizing modems.

A robust TRANSEC network also requires the use of at least two network-wide keys: The ACC key for acquisition, and the DCC key for the data channel. A long-lived, user-generated passphrase is used to protect the keys during initial commissioning. The use of front-panel displays to enter the passphrase and external key fill mechanisms places an undue burden on the warfighter and introduces security vulnerabilities.

iDirectGov has implemented a FIPS-approved software method of key generation and automatic, OTA key distribution protocol. Not only does the software-based key generation and key distribution mechanism make TRANSEC operation simpler and more convenient for the warfighter, it makes the system much more secure by removing a human from key distribution.

Another advantage of automatic key generation and distribution is that it seamlessly enables a global Communications-On-The-Move (COTM) TRANSEC network. By automatically generating and distributing new acquisition passphrases, a single, dynamic passphrase can be used across global networks.

Enhancing TRANSEC and Security with the 9-Series and DLCs
iDirectGov has expanded its existing FIPS 140-2 certification from Level 2 to Level 3 in its 9-Series Satellite Routers and Defense Line Cards, as opposed to FIPS 140-2 Level 2 in its 8-Series products and eMxDx line cards.

As part of the effort, iDirectGov developed a TRANSEC module designed to meet the stringent FIPS 140-2 Level 3 requirements as defined by the National Institute of Standards and Technology. Through hardware and software development, the embedded yet independent TRANSEC module on the 9-Series and DLCs operates through a separate and trusted path from all other interfaces on the product.

The module also features a strong physical security measure for tamper prevention and the capability to zeroize the security keys or critical security parameters (CSPs) stored on the module itself. If required, the revocation or zeroization of the keys can be accomplished either OTA by the hub operator or locally on the remote by authorized personnel.

One-Way Networks
iDirectGov has further enhanced its TRANSEC capabilities by securing one-way broadcast transmissions. Based on its encapsulation method, lightweight encapsulation generic stream (LEGS), the iDirectGov platform can provide the same level of security for one-way networks to that of two-way networks as described earlier.

The 900 and 9350, with dual-demodulator support, are capable of dual-domain TRANSEC; the ability to establish two independent chains of trust (sets of X.509s) between two different certificate authorities (CA).

An example use case of this feature would be one demodulator on a two-way TRANSEC network while the second demodulator receives a separate one-way TRANSEC-secured broadcast. Elliptical Curve Cryptography (ECC) is used for key generation along with X.509 certificates for authentication in each security domain.
www.idirectgov.com/

Karl Fuchs is Senior Vice President of Technology of iDirect Government (iDirectGov). Fuchs joined iDirectGov in 2004 as the director of sales engineering, just as the satellite-based IP communications company was expanding its very small aperture satellite (VSAT) market presence into the federal government and international Internet Protocol (IP) networking world. With more than 20 years of experience in technology and with the federal government, Fuchs leads iDirect Government’s team of federal systems engineers and serves as chief architect for new product integration. Active in the satellite industry for more than 15 years, Fuchs has contributed editorial to publications including Federal Computer Week, Institute for Defense and Government Advancement, COTS Journal, Military Information Technology, Via Satellite, MILSATMagazine and Satellite Evolution Global. He is also a senior contributor to MilsatMagazine. Fuchs holds a Bachelor of Science degree in electrical engineering from George Mason University, Fairfax, Virgina., and an MBA from Averett University, Danville, Virginia.