Citadel II encryption in sync/async MS-110A transmissions (Algerian AF)

Altought it was introduced in 2004 [1], so far I had always seen the Citadel II encryption algorithm occur in 3G-ALE/STANAG-4538 contexts which use the circuit mode service [2][3]; conversely, in 3G-ALE/S-4538 packet mode service (xDL protocols), and just few times in async S-4285 and MS-110A transmissions, I met the Citadel I algorithm. Of course this doesn't mean that Citadel II is only used in S-4538 circuit mode: it's just a commentary on my experiences. Finally, after almost one year since the last "Citadel detection", some interesting recordings show the use of Citadel II also in a 2G-ALE/MS-110A context (1).
Transmissions were recorded a few days ago on 11480.0 KHz/USB thanks to the EA5JGN KiwiSDR located in Hondon Valley (Spain) [4]: that frequency - as is known - is largely used by the Algerian Air Defence/Territorial Air Defence (say Algerian AF), as confirmed by the decoding of the 2G-ALE 188-141A exchanged messages (2).

Fig. 1

Figures 2,3 show the decoded bitstreams of the first two MS-110A segments of Figure 1 (T08_02_07Z recording) before and after the removal of the well-known sync sequence

0x [1E 56 1E 56 1E 56 1E 00 1A 5D 1A 5D 1A 5D 1A 5D]

In both the cases, 12-byte/96-bit length Initialization Vectors (3 times repeated) are used.

Fig. 2

Fig. 3

The 3d MS-110A segment in Figure 1 is the most interesting one since - curiously - its decoded bitstream shows an async 8N1 framing: perhaps the related file comes from a different workstation of the network, also connected to the same messaging server. Figure 4 shows the 12-byte Initialization Vector after start/stop bits and sync sequence were removed.

Fig. 4

As I mentioned before, Algerian AF network (in this example nodes CNC and CM3) usually uses this frequency as well as MS-110A asynchronous transmissions; for this reason I went to search for similar transmissions in my files and found - right in the blog - a post dated December 2017 [5]. The analysis of the bitstream shows that Citadel II encryption was already used since then in that network. At that time I was a bit less experienced and probably I focused on the particular 8-bit pattern, neglecting to search for other possible sequences.

Fig. 5

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

(1) please note that although Citadel I and II  are referred to as algorithms, they are actually ASIC chips (Application-Specific Integrated Circuit), ie algorithms rendered in hardware, which are embedded - for example - in L3Harris Falcon II, Falcon III family radios.  

(2) collected ALE Address
BLD: [Air Defense] Blida
TDF: [Air Defense] Tinduf
COF: [Air Defense] Cheraga
ANB: [Air Defense] Annaba
CM5: Commandement de la 5e Région Militaire, Constantine
CM3: Commandement de la 3e Région Militaire, Bechar
CNC: Commandement des Forces Aériennes d'Alger, Cherage 

[1] https://www.cryptomuseum.com/crypto/harris/citadel2/
[2] http://i56578-swl.blogspot.com/2023/05/harris-citadel-ii-secured-traffic.html
[3] http://i56578-swl.blogspot.com/2023/06/harris-citadel-ii-secured-transmissions.html
[4] http://ei2hh.proxy.kiwisdr.com:8073/
[5] http://i56578-swl.blogspot.com/2017/12/a-ms-110a-modem-running-in-async-mode.html
 

about the unid 32-bit protocol used in S-4538 + MS-110A transfers

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/