This is the third time I have encountered these transmissions [1] and, given the good number of recordings made over a few days on the frequency 6964.5 KHz/USB, it is now possible to draw a more definitive "picture".
Transmissions normally occur each 5 minutes and last 1.5 - 2 minutes average. STANAG-4538 (3G-HF) "circuit mode service" is used, where MS-110A (usually in 75bps/Long Interleaver mode) is the used traffic waveform; sometimes a transmission may consist of two or more distinct data transfer sessions (Figure 1).
Links are established using the FLSU (Fast Link SetUp) Asynchronous scanning call, using BW5 and an "optimized" waveform which provides no repetition of the initial TLC section (used for transmitter level control and receiver AGC settling). Such a scanning call is exactly described in paragraph C.5.2.4.5.2 of MIL 188-141B Appendix C: "The LE_Scanning_Call PDU shall be sent repeatedly to capture scanning receivers [...] During a scanning call, only the first LE_Scanning_Call PDU shall include TLC. All succeeding LE_Scanning_Call PDUs and the LE_Call PDU shall omit TLC, and include only the BW0 preamble and data portions" (1)(2). So, we look at a STANAG-4538 FLSU Async call (since the use of BW5 waveform) which is 188-141B compliant for what regards its formation (since the omission of the TLC sections): ie, a sort of 188-141B/STANAG-4538 mixed implementation most likely implemented by L3Harris [2][3]. That "formation" of the Async call clarifies why decoders recognize only the "first" BW5 PDU.
 | |
| Fig. 1 |
Looking at the asynchronous scan calls, at first glance it seems that Linking Protection (LP) is not used: in fact, as you can see, the decoded strings are identical. This should not happen since when operating in encrypt mode, the LP algorithm takes as inputs the PDU to be scrambled, a key variable, and a “seed” that contains Time of Day (TOD) and the frequency that carries the protected transmission.
2024-08-21T09_54_32Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-21T09_56_17Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-21T10_01_54Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-22T07_46_52Z BW-5 00010110100000110011111110111010101110111100000110
2024-08-22T07_51_52Z BW-5 00010110100000110011111110111010101110111100000110
Anyway, it's to note that when the protection against spoofing offered by LP is not required, LP may be used without a key variable or seed to provide only scrambling based on the network number as described in STANAG-4538 4.1.2 (in this regard, note that the scanning calls of 2024-08-22, for example, do not have the expected value "001" in the first three bits).
The analysis of the MS-110A decoded bitstreams show initial 100 bytes length headers which have some parts common to all the bitstreams, the header "format" is more evident after the removal of the initial "10"s sequence (Figures 2,3).
 |
| Fig. 2 |
 |
| Fig. 3 |
In my opinion, headers are made up of the following structure (Figure 4):
1) common initial sequence
1100000100011100101001 (maybe 001100000100011100101001, 0x0CE294)
2) common 193 bits length "01"s sequence, (phasing?). Boundaries are marked by two consecutive logical "1"
3) common 160 bits / 20 bytes length sequence (sync sequence for the receive crypto device?)
10001011010001111000010010000111
01111011101101001011100010000111
01000100011110000100100001110111
10111011010010111000101101110100
01000111100001001000011101111011
4) 256 bits / 32 bytes length sequence which is different in every bitstream (Initialization Vector?)
5) common 5×32 bits / 4 bytes repeated sequence (frame sync?). Note that the sequence can't be an Initialization Vector since it's always the same in every bitstream.
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
Also note that the 4 bytes repeated sequence is used in the first 4 bytes of the 160 bits sequence.
 |
| Fig. 4 - the common blocks in the headers of the bitstreams |
According to the results of the "Shannon Entropy" and "Statistical" tests, the ansferred data are most probably encrypted (Figure 5).
The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5 The statistical test below determines the randomness, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: if the information is not systematic, the adjacent columns should be half the size of the previous ones. Both the test shows good encryption quality.
 |
| Fig. 5 - Shannon Entropy and Statistical tests on the data portions |
The transmissions are fairly receivable only in the northern regions of Europe, likely a low power transmitter is used or a local/domestic area shall be served. Just about the site of the transmitter, all my direction finding attempts point to a quite large area in Norway (Figure 6): maybe a Royal Norwegian Navy Tx? Anyway, it's to notice that the DF results "suffer" from the lack of detection points west of Norway.
 |
| Fig. 6 - Direction finding attempts (TDoA algorithm) |
Monitoring & recordings thanks to the remote KiwiSDRs SM0KOT (Sweden) and OZ1AEF (Denmark) [4][5].
https://disk.yandex.com/d/AcwncUTKxXlQ_A (decoded bitstreams)
(1) MIL 188-141B refers to BW0 as the waveform to convey "LE_Scanning_Call PDU" and "LE_Call PDU" (LE stands for Link Establishment): FLSU, and consequently the BW5 waveform, were not yet defined at that time.
(2) 188-141B (released on March 1999!) was superseded by 188-141C (December 2011), in its turn superseded by 188-141D (December 2017): the last two standards no longer have the Appendix C but only some short paragraphs, among them the #C.6 says "The specifications previously contained in this appendix have been replaced with reference to the essentially identical NATO STANAG 4538".
[1] http://i56578-swl.blogspot.com/search/label/P%3D32
[2] http://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call.html
[3] http://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call-2.html
[4] http://aspliden.kostet.se:8074/
[5] http://85.191.35.22:8073/
No comments:
Post a Comment