28 October 2020

250Bd/500 FSK embedded channels, likely Ukr nets

Three 250Bd/500 FSK "embedded" channels, 1000 Hz spaced, spotted on 6775.0 KHz (CF) and originating north of Rivne, Ukraine; probably trials or experimental transmissions.

Fig. 1
 It's to notice that the 105-bit streams share the same 43-bit preamble/sequence:


Fig. 2

My friend cryptomaster informed me that he too listened to a similar signal (3 x 250Bd/500 FSK), but spacing between channels was 500 Hz); his analysis can be read here:


24 October 2020

two new 50Bd/850 FSK broadcast channels

It seems that the Turkish friends (or "stars and stripes" friends in Turkey) have activated two new 50Bd/850 FSK broadcast channels on 8788.0 and 8792.0 KHz (cf), or likely 8090.0 KHz in ISB mode. Spotted them on 22th October for the first time. 

Fig. 1

Fig. 2

As expected, since the 50Bd/850 waveform, both the channels are KW-46/KIV-7 secured. The "business card" consists of the pseudo-random sequence generated by the polynomial x^31+x^3+1, those bits replace the stop bits and are used by KW-46 cryptographic equipment to provide synchronization (figure 3).

Fig. 3

Tx site (or Tx sites ?) is in Turkey; unfortunately there are no KiwiSDR in the southern Mediterranean, they would have allowed a more accurate DF.

Fig. 4



21 October 2020

KW-46 secured traffic over 188-110A, MHFCS Townsville

Long 110A Serial transmission heard on 6345.50 KHz/usb and used for KW-46/KIV-7 secured fleet broadcast, task usually performed by S4285/S-4481 in NATO Navy.
The analysis of the frame structure (Figure 1) confirms 110A operations at low datarates: each frame is composed of 40 tribit symbols, or 120 bits, (20 symbols for miniprobe + 20 symbols for data). In low datarate modes, from 150 to 1200 bps, the 480-bit length of the 110A scrambler exactly matches four frames (i.e.: 4 x 120 bits) and so it produces the strong 66.67ms spikes which are visible in the auto-correlation function.

Fig. 1 - MIL 188-110A Serial Tone framing

The most interesting aspect is the use of KW-46/KIV-7 encryption to secure data transfers: its use is revelaed by the presence of the pseudo-random sequence generated by the polynomial x^31+x^3+1 (Figure 2). It's worth noting that, usually, the KW-46 crypto device is used in USN/NATO fleet broadcast with FSK 50Bd/850 or S4285 modems. A similar MHFCS transmission was reported here.

Fig. 2 - x^31+x^3+1 pseudo-random sequence

TDoA runs say Australian MHFCS [1] node at Townsville as the Tx site (Figure 3):

Fig.3 - TDoA results

The Bohle Transmitter Station site [2] is a site of approximately 484 hectares, located 10 kilometres west of Townsville (Figs. 4,5). As said, the station is a communications facility used by Defence and forms part of the Modernised High Frequency Communications System.

Fig. 4 - site of the MHFCS (google earth)
Fig. 5 - https://www.flickr.com/photos/csipete/3055234661/in/photostream/


[1] https://i56578-swl.blogspot

12 October 2020

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., 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:
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:

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].

1 October 2020

3G-ALE synchronous Fast Link Setup (FLSU) failures

Monitoring some US Army MARS frequencies such as 6910 KHz/USB, it happens to see 3G-ALE bursts pairs which are not the usual two-way LQA exchanges, as it happens in 2G-ALE (118-141A), but rather synchronous fast link setup (FLSU) failures: indeed, the bursts are sent by the same station, since the levels (5.64 and 5.28 dB).

Fig. 1
The scenario in figure 1 depicts the case in which an xDL ARQ protocol is unsuccessfully invoked via the original FLSU_Call. Quoting STANAG-4538 "Since the calling PU did not receive the FLSU_Confirm response, it must assume that the response did not propagate properly and that the called PU is prepared for the xDL packet transfer protocol. As such, the called PU is set up to receive either the first xDL forward packet PDU, or an xDL_Terminate PDU. Sending a FLSU_Terminate (ie a BW5 burst) would impose a triple demodulation requirement on the receiving PU! (1).
Thus, the calling PU must send up to “N” bursts carrying the xDL_EOM PDU to abort the ARQ protocol (under the xDL protocol specification, “N” is defined by the number of xDL_EOM PDUs that would fit within the time slot of a forward packet PDU)".

Fig. 2 - synchronous LSU failure scenario (from STANAG-4538 Ed.1)
In this sample PU1 (caller) issues a BW5 FLSU_Request to PU2 (called), requesting LDL ARQ traffic, but it does not detect any response from the called station. PU1 shall assume that PU2 issued a FLSU_Confirm but it's not received by PU1. Since PU2 must only look for at most two waveforms (1), it looks for the LDL Forward Packet waveform (BW3) and the LDL_EOM PDU (BW4).  Thus, in order to terminate the link due to missing the FLSU_Confirm, PU1 sends a LDL_EOM (BW4 PDU).
In that same frequency it's possible to hear also 2G-ALE [T-WAS] calls (figure 3), heard callsigns: 3QH, FHUCLR, NC6CLR, M19, STR,.... Who knows, perhaps they use 3G-ALE in that same way.

Fig. 3 - 3G-ALE FLSU (failed) followed by 2G-ALE call

(6910 KHz could be noised by US-based and Latin America-based freebanders/outbanders chatting in LSB)
(1)  STANAG-4538 #4.6.5 "Dual Demodulation": under no circumstances shall PUs be required to simultaneously demodulate more than two waveforms. Any scenario requiring more than dual-demodulation is either an error in the specification or an error in interpretation. The table below defines the dual-demodulation requirements:
STANAG-4538: TABLE 4.6.5-1 Dual Demodulation States