(unid) synchronous transfer protocol over MS-110A & FED-1052 DLP

Durings the last few days I have monitored the frequency 7762.0 KHz/U and collected very interesting recordings of transmissions regarding a (possible) synchronous transfer protocol which sits at a higher layer than the datalink one. All transmissions use MS-110A as the HF waveform and most of them use FED-1052 App.B as Data Link Protocol (DLP)(1): Figure 1 is an example in this regard. Since the use of FED-1052 DLP, the HF waveform could likewise be FED-1052 serial (single-tone) given that the two waveforms are interoperable. Links are performed using 2G-ALE handshakes (MS-141A), logged callsigns are K01, k02, K03, K08, K13, and K14. 

Fig. 1

1. The demodulated bitstreams of the first four Tx segments ("A" in Figure 1) have a common 26-byte (10+16) length initial sequence which may be seen as consisting of the two Hex strings/sequences shown in Figure 2:

[16 16 16 16 16 16 16 16 16 16] [8E 5C 0B AA 97 30 56 E6 93 A2 B3 FB 6D 1A E2 01] 

Fig. 2 - initial Hex sequences

The two initial strings are followed by an apparently random 224-bit/28-byte sequence which is 3 times repeated: that sequence is unique for each Tx segment so that it could be an Initialization Vector (IV): the repetitions are indeed a good clue (Figure 3):

[54 6A 59 86 D8 0D 5E EE 94 AF B7 25 C1 DB 44 A8 BF 4B F9 DF AF F4 BF 1D 94 F9 6D 3F]

[FA D6 B4 C8 3D 50 BA 06 F1 E7 4C 22 02 A5 86 48 F9 6D AA 76 29 3C 0A E0 51 E8 61 FF] 

[58 FC 4A D4 09 C2 82 9B 75 93 16 2D 8A 11 B1 D3 8A DE F1 55 79 2E 52 E1 53 02 E2 B5]
[A7 55 A7 B1 8E E9 68 96 84 DF 57 FA AF A2 09 E9 EA DB D5 53 16 9F 20 E7 93 75 24 86]

Fig. 3 - 28 bytes sequences

The bitstreams end with a 20-byte string of 0x16, just the double of the length of the initial 0x16 sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16]

Fig. 3 - ending Hex sequences

Since these Tx segments are sent using the 2400bps/voice mode, the data blocks between the (presumed) IVs and and the ending sequences could consist of secure digital voice. The Shannon entropy value computed on data blocks (7.792888420337759) could suggest encrypted or compressed files. Just to be thorough, I thought about checking whether the repeated 28-bytes sequences were SHA-224 digests (64 rounds, by default) of the following data blocks, but the results did not confirm this hypothesis.

2. The bitstreams resulting after demodulating the other 12 Tx segments ("B" in Figure 1) are recognized as FED-1052 App. B "DLP Data Link Protocol" frames (also known as HF Data Link Protocol, HFDLP). Quoting FED-1052 standard #50.1.1.1 Frame sync pattern:  Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010" (see Figure 4).

Fig. 4 - FED-1052 DLP sync patterns

Looking at the Source and Destination Address fields (2) in the hexdumps of Figure 5, it's possible to see the exchanges of DLP frames between the addresses 03 (0x3330, ASCII 30) and 01 (0x3130, ASCII 10): forward and reverse directions are due to the ARQ feature of DLP protocol. Notice that the DLP addresses 01 and 03 match the ALE callsigns K01 and K03 used during the link setup process (Figure 5).

Fig. 5 - DEF-1052 DLP frames exchanges

More precisely, each DLP transfer consists of 3 frames (Figure 6):  the first is a data frame (bytes block delimited by 0x16) while the 2nd and 3th are control frames.

Fig. 6

DLP data frames consist of 56-bytes "packages", thus the re-assembly process produces files that have lengths in multiples of 56 (112, 168, 224, ...). By the way, packages are the result of a "fragmentation" of messages received from the user (or from a higher-layer protocol).

The small files resulting after the re-assembly process (and the removal of FED-1052 DLP overhead) are not in clear-text... and here things get interesting. 

The files start with a common 18-byte (10+8) sequence which may be seen as consisting of two Hex strings:

[16 16 16 16 16 16 16 16 16 16] [DF 73 0D 1D 5B 22 53 81]

and term with the 20 bytes Hex sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16] 

Also in this case, the ending 0x16 sequence is the double of the length of the initial 0x16 sequence (Figure 7):

Fig. 7

The 0 value bytes are padding bytes added to the last package to obtain the 56-byte size: it can easily be verified for each packet by subtracting the "data" bytes from the "received" ones. Quoting FED-1052 standard #50.4.3.1.2: All data frames shall be of the same size [...] this implies that the last data frame of a message may need to be padded with fill bits. The receive terminal will use the transmit message size information to determine where the message is to be truncated in order to remove the fill bits from its output data stream. The 16-bit graphic rapresentations are shown in Figure 8.

Fig. 8

 

Data consist of a few bytes, I do not think they are compatible with digital voice or "informal messages", maybe they are numerical data even if some format does not emerge.

3. I know that 0x16 is the <SYN> "Synchronous Idle" (TC9) ASCII control character. It is used in synchronous transmission systems to provide a signal from which synchronous correction may be achieved between data terminal equipments, particularly when no other character is being transmitted. The SYNC char was also used in syncrhonous modems at start and end of info blocks. So, the initial sequences of SYNC make me think of a kind of "synchronous transfer protocol" sitting at higher-layer.
Moreover, from the bitstreams analysis, it seems to me that the protocol is used to send different type of data and in different modalities: some types of data (Tx segments "A" in Figure 1) are forwarded directly to the MS-110A/FS-1052 modem, other types of data (Tx segments "B" in Figure 1) are first managed by FED-1052 DLP and then forwarded to the MS-110A/FS-1052 modem. Maybe the two initial strings announce the type of the following data blocks, but it's only a my guess.

By the way, the long durations of the 2G-ALE scanning call provide some indications about the number of the available channels: assuming full compatibility(!) with MS-141, the collected scan lists should be >= 20 channels (3). User should be Dutch MIL... but it's not confirmed.

Fig. 9 - 2G-ALE MS-141 scan call

 

https://disk.yandex.com/d/CrXu2QY4-AP9vQ 

(1) The HFDLP is a selective repeat ARQ protocol with the ability to adaptively vary several parameters in response to changing channel conditions. A transmission usually consists of a data series, containing several data frames, or a single control frame. Every frame contains a CRC. Before data transfer commences, HFDLP terminals exchange control frames to negotiate the number of data bytes per data frame (56 to 1023), the number of data frames per data series (1 to 255), and a few other characteristics of the data transfer procedure.

(2) As per FED-1052 standard, Source Address and Destination Address fields are restricted to two bytes each, LSB first. 

(3) 188-141 A.5.5.3.1 "If the called station (JOE) is known to be listening on the chosen channel (not scanning), the calling station (SAM) shall transmit a single-channel call that contains only a leading call and a conclusion (see upper frame in figure A-29). Otherwise, it (SAM) shall send a longer calling cycle that precedes the leading call with a scanning call of sufficient length to capture the called station’s receiver as it scans (lower frame in figure A-29). The duration of this scanning call shall be 784ms for each channel that the called station is scanning.

KW-46 secured fleet broadcast over S-4285 in ISB mode (Humpty Doo, MHFCS)

Interesting fleet broadcast from the MHFCS (Modernised High Frequency Communications System) site in Humpty Doo, Northern Territory - Australia. The transmissions use STANAG-4285 600bps/L in ISB mode and are audible on 11145.0 KHz (Figure 1).

Fig. 1

Bitstream of the LSB channel (Figure 2) is a "classic" broadcast which is encrypted using KW-46 (or compatible) cipher device given the presence of the m-sequence generated by the polinomyal x^31 + x^3 +1 (KW-46T uses that M-sequences to synch the KW-46R receive devices).

Fig. 2 - bitstream of the LSB channel

The bitstream of the USB channel is more interesting since it consists of 12-bit strings where all the bits have the same logical value, likely originated by the GA-205 12-channel time division multiplexer: I already met such signal some years ago [1] but that time from the "Naval Communication Station Harold E. Holt" (NCS HEH) 6 km north of Exmouth. USB channel too transports a KW-46 secured traffic: as shown in Figure 3, I filtered out 11 channels and reshaped a single "column" into a 7-bit pattern then I successfully checked the presence of the x^31 + x^3 +1 m-sequence.

Fig. 3 - bitstream of the USB channel

As said, in this case the transmission is source by a Tx located in Humpty Doo, Northern Territory Australia.

Fig. 4 - DirectionFinding results (TDoA algorithm)

 

https://disk.yandex.com/d/cd6YKgpc18NPrw

[1] http://i56578-swl.blogspot.com/2019/05/kw-46kiv-7m-secured-fleet-broadcast.html

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