MIL 188-220 App.D (Combat Net Radio) compliant transmissions in HF band

MIL-STD 188-220 suite (here indicated as MS-220D) was developed to meet the requirements for mobile Combat Net Radios (CNR) such as SINCGARS (Single Ground and Airborne Radio System) or more recent JTRS (Joint Tactical Radio System). The radios can handle voice and data communication, both secure and non-secure. SINCGARS radios work in the lower VHF band (30 to 88 MHz), with 25 kHz channel spacing and can operate on a single channel as well as in Frequency Hopping mode (FH). It's therefore rather rare to find transmissions in HF that use this protocol suite, especially in the low HF band (7 MHz)... but it may happen. Indeed, I was lucky enough to catch such transmissions on the same day (1030Z and 1058Z) on 7510 KHz/U (and it's not the first time it occurs).
The transmissions under consideration (Figure 1) are in STANAG-4538 "circuit service" mode, where link setup is performed by FLSU request/confirm exchanges (BW5 bursts) and MIL-STD 188-110A is the used traffic waveform.

Fig. 1 - STANAG-4538 Circuit Service mode

Appendix D of of MIL-STD-188-220 regards Communications Security Standards (COMSEC) and describes the requirements of the transmission frame structure when link encryption is provided by "external COMSEC" (traditional COMSEC) or by "embedded COMSEC" devices. The demodulated bitstreams perfectly fit the COMSEC preamble for external COMSEC (Figs. 2,3), ie when link encryption is provided by external devices.

Fig. 2 - Traditional COMSEC transmission frame structure (FIGURE D-1, MS-220D)

Fig. 3 - The COMSEC preambles of the demodulated bitstreams

Bit Synchronization subfield is used to provide a signal for achieving bit synchronization and for indicating activity on a data link to the receiver.  The  subfield consists of the data-rate clock signal, a string of alternating ones and zeros.

Frame Synchronization subfield is used to provide a framing signal indicating the start of the encoded MI (Message Indicator) to the receiving station. As for MS-220D "this subfield shall be 465 bits long, consisting of 31 Phi-encoded bits (1 encoded bit = 15 bits). The Phi patterns are a method of redundantly encoding data bits, a logical 1 data bit shall be encoded as Phi(l)=111101011001000, and logical 0 data bit shall be encoded as Phi(0)=000010100110111. A simple majority voting process may be performed at the receiver to decode the Phi-encoded frame pattern to its original format". Figure 4 shows the Frame Sync subfield of the demodulated bitstreams: as one can easily verify, the Phi-decoded content matches perfectly the sync pattern indicated in Figure D.2 of MS-220D (#D.5.1.1.2). 

Fig. 4 - Phi-encoded frame sync

Message Indicator subfield contais the COMSEC-provided MI (or Initialization Vector), a stream of 87 random bits that are redundantly encoded using the Phi patterns seen above. Cryptographic synchronization is achieved when the receiver acquires the correct MI. Decoding can be easily achieved (Figure 5).

Fig. 5 - Message Indicator subfield

Since the COMSEC preambles of the analyzed bitstreams match the "external COMSEC" frame structure, likely the encrypted parts (voice/data) are secured by an external crypto unit such as the KY-57 (Vinson) or the more advanced KY-99.
Such uncommon (in HF band) transmissions are maybe a forward from a VHF link, who knows.

https://disk.yandex.com/d/-_3GnxUV_XKN9Q

STANAG-4538 to forward 188-220 App.D (SINCGARS) Tx frames to HF

6898 KHz/USB seems to be a good place to catch transmissions which deal with STANAG-4538 3G-HF and COMSEC. After the 256-bit Initialization Vectors encryption, it happened to hear some STANAG-4538 transmissions that used the LDL protocol: nothing particularly interesting except for the transported datagrams that are certainly attributable to SINCGARS traffic which is usually exchanged, however, between 30 and 88 MHz! Indeed, after the analysis of the LDL bitstreams, it turned out that MIL 188-220 App. D "COMMUNICATIONS SECURITY STANDARDS" (shortly idicated as 188-220/D) exactly describes the structure of the transmitted datagrams.
In short, SINCGARS (Single Channel Ground and Airborne Radio System) [1] is a VHF Combat Net Radio (CNR) [2] WF providing secure voice and data communications; MIL 188-220 [3] is a military standard that governs the use of Combat Net Radios and covers layers 1 through 3 (physical, data link, and network) of the OSI stack.

Fig.1 - STANAG-4538 LDL session

LDL protocol analysys
Each LDLn transfer consists of a TX Frame consisting of one data packet. A data packet is defined as a fixed-length sequence of n-byte data (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused), both added by the LDL protocol. Each TX Frame is sent using burst waveform BW3. During the construction of BW3, a 32-bit CRC is computed across the data bits of each data packet and is then appended to it. Then, 7 flush bits having the value 0 are added to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air LDLn bits are equal to 8n + (17+8+32+7)  or  8n + 64 (n  =  32,64,96,...,512).

That said, we can go back to the original datagram by inspecting the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the four BW3 bursts (Figure 2). In this sample the values of the Packet Number fields are: 0,0,1,1: most likely, each TX Frame is sent twice to improve the reliability of the transfer (the receive station discards the duplicated packets). Correspondly, the values of the single Packet Byte Count fileds are 415 (110011111) and 346 (101011010): this means that LDL416 protocol is used and therefore the original datagram was splitted into two packets each of 416 and 347 bytes (the Packet Byte Count field contains the number of user bytes -1). 

Fig. 2 - LDL overhead bits

Datagram analysis
The original datagram can be retrieved by reshaping the bitstream in a 3392-bit period (ie (8 × 416) + 64),  isolating the four rows, removing either the duplicated packets and the 64 overhead bits: the resulting bitstream is shown in Figure 3.

Fig. 3 - the original 15-bit period datagram

As said, 188-220/D exactly describes the regular patterns which compose the datagram, particularly the COMSEC preamble field that consist of three components: the bit synchronization subfield (it may consists of a string of alternating ones and zeros), the Frame Synchronization subfield, and a Message Indicator (or Initialization Vector, IV) subfield (Figure 4).

Fig. 4 - traditional COMSEC transmission frame structure (MIL 188-220 App.D)

As per 188-220/D #D.5.1.1.2, frame sync subfield, and Message Indicator are encoded using Phi patterns, a method of redundantly encoding data bits :

a logical "1" data bit is encoded as a Phi(1) = 111101011001000
a logical "0" data bit is encoded as a Phi(0) = 000010100110111

A simple majority voting process may be performed at the receiver to decode the Phi-encoded patterns to their origlnal format. 

 

It's to notice that the Phi patterns are generated by the polynomial x^4+x+1 [initial state 1,1,1,1]: this could be misleading if you are looking for a suitable descrambler for the preamble.

I extracted the original datagrams from three STANAG-4538 transmissions heard on 6898 KHz, removed the initial (long) bit sync subfields and placed the bitstreams side by side for better visibility of the COMSEC Frame Sync and IV subfields (Figure 5).

 

Fig. 5 - COMSEC preambles

As you see the Frame Sync subfield is the same in the three datagrams, this subfield is 465 bits long and consists of 31 Phi-encoded bits (as per 188-220/D): 

 

01) 111101011001000 → 1
02) 111101011001000 → 1

03) 111101011001000 → 1 

...

29) 111101011001000 → 1

30) 111101011001000 → 1
31) 000010100110111 → 0 

 

As expected, the pattern resulting after Phi-decoding matches exactly the one reported in 188-220/D:

 

1111111111111111111111111111110

 

The Initialization Vector subfield, a stream of random bits, is redundantly encoded using Phi patterns and is 1305 bits long (87 Phi-encoded bits) in all the three datagrams:

 

01001101001000000010001010110011110110110011

0111010010000110001011111010001111101000011
 

11100011100001100011110000110000101100111111

1100101101010111010101011111110100000000011

11101011101000001110101100100000000001001100

0110101100101010101001001010110101110010001

 

The ecrypted data block follows the Initialization Vector subfield, the external crypto device is presumably KY-57 [4] or the more advanced KY-99.

 

The same frame structure, and the same subfields lengths, was found in

- SINCGARS transmissions heard on 33 MHz (low VHF, GFSK 16000 Baud) (Figure 6)

- SATCOM transmission heard on 261.5 MHz (UHF, FM 16000 Baud) [5]

Fig. 6 - frame structure of a SINCGARS transmission

 

i.e. just where do you expect to find it (V/UHF).

 

Conclusions are hard to draw from such observations: since the LDL packets transport whole 188-220/D frames "as is", STANAG-4538 appears to be used as a kind of "bridge or relay" between V/UHF and HF (Figure 7).

 

Fig. 7

 

It sounds quite weird and unusual but however this is what was on-air. What is it, then? 

Since this type of transmission occurred several times and for some days, I tend to exclude that it was an operator mistake or a malfunction of the equipment: both would have been noticed and perhaps fixed. Maybe some kind of tests? Anyway, I find it difficult to think that such a mix is possible by using a "traditional" setup. Indeed, I think that using a SCA-based Software Defined Radio a skilled operator could instantiate a 188-220/D + S4538 session, but... why? Using a such SDRs configuration would be possible outrun the transmission range of (VHF line-of-sight) SINCGARS, but honestly such a solution seems rather crude and impractical. Maybe it was just occasional needs to forward 188-220/D frames to a certain HF endpoint.

In conclusion, at present I don't have a clear explanation and comments will be greatly appreciated. For completeness, it should be added that in these days I have tried some sporadic monitoring but I have not been able to hear these transmissions anymore (at least on 6898 KHz).

 

A big thank to my friend KC9FFV Marco (Forney, TX USA) who allowed me to use his KiwiSDR beyond the 120 minute time limit [6].
 

 

https://yadi.sk/d/uXodd0sc6oiLLw 

 

[1] https://en.wikipedia.org/wiki/SINCGARS

[2] https://en.wikipedia.org/wiki/Combat-net_radio

[3] https://yadi.sk/i/pauZfUz63Nxs-g

[4] https://www.cryptomuseum.com/crypto/usa/ky57/

[5] http://www.radioscanner.ru/forum/../msg335301

[6] http://marcocam.selfip.com:8073

 

KG-84, KW-46, ...

In this blog I often use terms like "KG-84", "KW-46", "BID",..., as well as the names of other cryptographic devices, but this does not necessarily mean that those devices are physically used ashore or on aboard of ships! Rather than to the equipments, those names must be understood as referring to the used "algorithms", since - unless few exceptions - many of those devices are now obsolete and no longer used. Actually, the algorithms are emulated by interoperable and more compact devices such as - for example - the KIV-7M Programmable Multi-Channel Encryptor that can be used for communicating with a KIV-7 family device and the older KG-84/BID family of devices, or the KY-99 that is the more advanced version of the KY-57 unit.

In general:
KG means Key Generator which could be used with any digital input device;

KI is for data transmission;
KW is the prefix for a Teletype encryption device;
KY stands for a voice encryption device. 
Also note that these products are only used by the US Government, their contractors, and federally sponsored non-US Government activities, in accordance with the International Traffic in Arms Regulations (ITAR), as well as by NATO and by the administrations of some NATO countries.

MIL 188-220 Appendix D, standards for COMSEC transmissions

A recent post in radioscanner (my nickname is "ansanto" there), and some interesting discussions with a friend of mine, gave me the opportunity to study that signal and deepen the theme that is dealt with by MIL 188-220. In particular, the signal in question (courtesy by KarapuZ) concerns a transmission with link encryption provided by external COMSEC devices, in accordance with what is reported in the Appendix D of the cited standard, ie "transmission frame structure in either external and embedded COMSEC modes".

In short, in external COMSEC transmission frame the clear-text (not encrypted) part of the transmission frame is the "COMSEC Preamble", depicted below, which consists of the subfields: 
a. COMSEC Bit Synchronization
b. COMSEC Frame Synchronization
c. Message Indicator - MI or, better, Initialization Vector - IV (1)

The COMSEC Frame Synchronization subfield is used to provide a framing signal indicating the start of the encoded MI to the receiving station. This subfield is 465 bits long, consisting of 31 Phi-encoded bits. The Phi patterns are a method of redundantly encoding data bits. The logical data bits 1 and 0 are encoded as shown in figure. 

The Message Indicator subfield (MI) contains the COMSEC-provided MI, a stream of random bits that are redundantly encoded using Phi patterns.

Alternatively, in the embedded COMSEC transmission frame the clear-text part, depicted below, is composed of the following components:
a. Phasing
b. Frame synchronization (Standard Frame Sync or Robust Frame Sync)
c. Robust Frame Format (RCP only)
d. Message Indicator/ Initialization Vector
 

Back to the signal, it was heard by KarapuZ in the 33 MHz band and it is a GFSK modulation at a rate of 16000 Baud that can be easily processed using SA (Fig. 1).

Fig. 1

Once demodulated it turns out to be an encrypted transmission with the COMSEC Preamble that is easily identified  and consisting of the initial phasing part followed by two 15-bit encoded blocks: likely the encoded frame sync and Message Indicator (Fig. 2).

 

Fig. 2

Since 188-220 is based on the VINSON algorithm, the used encryption is presumably KY-57 and taking into account the band where it was listened... everything points to the SINCGARS radio (Single Channel Ground and Airborne Radio System) [1]. 

 

By the way, a dear friend of mine sent me a recording but once demodulated it uses 16 bits encoding patterns frames instead of 15 bits ones (Fig. 3). "I guess it is some modern crypto using a backwards compatibility mode, the clue is that it could be KY-99 that is the replacement for KY-57 in SINCGARS, but that point is unconfirmed. More signals and work will be necessary to clarify these points", my friend says. 

Fig.3

 

It is interesting to see how NATO KG-84 encryption relates to 188-220 Appendix D (Fig. 4).
KG-84 is similar to the emebedded COMSEC transmission frame, although the 64-bit pattern of KG-84 Standard Frame sync 

1111101111001110101100001011100011011010010001001100101010000001

is different from the patterns reported in Appendix D for Standard and Robust Frame sync. Moreover, the Message Indicator is not encoded using the Phi 15 bits, although it is redundantly encoded. That's probably ok since KG-84 is based on SAVILLE algorithm and 188-220 is VINSON based. Note as in some KG-84 "detectors" the Standard Frame sync is termed as "SYNC" and the MI data as "Initialization vectors".

Fig. 4 - NATO KG-84 encryption and 188-220 embedded COMSEC

 

The Turkish-Mil FSK, also using KG-84, deserves aside consideration (Fig. 5). Perhaps they encode the Mesage Indicator field using Golay and do not use redundant n-bit encoding, but it's only IMO. However "the encoding with Phi patterns is used for backward compatibility", 188-220 says.

Fig. 5 - Turkish-Mil FSK and 188-220 embedded COMSEC

(1) An Initialization Vector (IV) or starting variable (SV) is a block of bits that is used by several modes to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times, without the need for a slower re-keying process. An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key.[2] [3]

Please notice that just starting with this post I will use the term "Initialization Vector" to indicate the (repeated) pseudo-random sequence that is used to synch the receive crypto equipment. 

[1] http://www.cryptomuseum.com/radio/sincgars/

[2] https://en.wikipedia.org/wiki/Initialization_vector

[3] https://en.wikipedia.org/.../Initialization_vector_(IV)