22 July 2025

Tunisian Navy using L3Harris Citadel encryption

Prompted by some logs posted on the UDXF group, I started monitoring the USB frequency 12354.4 KHz, operated by the Tunisian Navy (Marine Nationale Tunisienne), hoping to capture something interesting. To be precise, I used the two KiwiSDRs located in central-eastern Italy, operated by IZ6BYY and IK7FMO [1], whom I obviously thank.
The frequency is quite "busy" with 2G-ALE (MS-141) exchanges between tactical callsigns, as RF05 and CT12 in the given sample; once the link is established, message exchange usually occurs via MS-110A using adaptive speed and interleaver (Figure 1). Still in this sample, it is interesting to note that the request to establish a link is transmitted from RF05 (caller node) to CT12 (called node) and after the exchange of messages the link is closed by the called node, as if to signify that there are no other messages to send in the opposite direction (a bit like what happens in 3G-ALE).

Fig. 1

The bistream after demodulation of the three message blocks shows the characteristic 16 bytes start/sync sequence of the L3Harris "Citadel" cipher (Figure 2).

Fig. 2 - Citadel start/sync sequence in the MS-110A demodulated bitstream

After removing the start/sync sequences, the presence of Initialization Vectors (IV) is noted: these are 16-byte/96-bit long, each repeated three times (Figure 3).

79 19 08 E9 61 C4 B1 01 A5 24 9A B7
87 A9 45 4F 28 22 A7 15 33 88 F8 EB
91 1E 71 15 D2 FA FF D3 51 68 6B D0

This is characteristic of the Citadel II "format":
- 16 bytes start/sync sequence 0x1E561E561E561E001A5D1A5D1A5D1A5D (Citadel)
- 12 bytes IV (each 3 times rptd) - OR - 32 bytes IV (2×128 bits parts, each 3 times rptd)     
- ciphertext
- 8 bytes end sequence 0x1E561E561E561E08 (Citadel)

 

Fig. 3 - 12-bytes/96-bits Initialization Vectors

Some comments

"Citadel II" generally refers to a hardware-based cryptographic solution (cryptographic engine) developed by Harris Corporation (now L3Harris) in 2004, designed for military-grade encryption in "non-Type 1" applications. This means it's approved for secure communications but not for the highest classification levels of US government information (which use "Type 1" ciphers endorsed by the NSA). One might wonder why this encryption is used by a country like Tunisia, which is notoriously not a member of NATO (1): the answer is because it is not a Type 1 device, the Citadel II is approved for export from the United States, making it available to international users.

Citadel II is used in various communication products, including the L3Harris Falcon II range of military radios (such as RF-5800H). Given L3Harris's extensive portfolio and the strong military ties between the US and Tunisia, it is highly probable that the Tunisian Army runs L3Harris equipment, particularly in areas like communications, night vision, and potentially some avionics or electronic systems on US-supplied platforms [2]. However, exact details of specific L3Harris models in Tunisian service are not always publicly disclosed.

The short duration makes one think of "informal messages", perhaps SMTP emails: the encryption unfortunately obscures the data-link protocol sitting at the upper layer, probably STANAG-5066. Considering the use of L3Harris encryption (and probably Falcon radios), one might think that the L3Harris' RF-67x0W Wireless Gateway/Message Terminal is used... but that's just my speculation!

https://disk.yandex.com/d/23rAAmgmk9AiAQ

(1) Since 2015, Tunisia has been granted non-NATO "major ally" status, a status granted by Washington to allied countries that have strategic relations with the American armed forces but are not members of the organization.

[1] https://iz6byy.k1fm.us/  http://ik7fmo.ddns.net:8073/
[2] https://adf-magazine.com/2025/04/tunisian-navy-adds-to-patrol-fleet/

 

15 July 2025

unid QPSK 2400 Bd Link-22 waveform

A few days ago my friend linkz sent me an interesting recording of a signal spotted on 11166.0 KHz/USB, in addition to the recording he also sent me an excellent "direction finding" work that - in my opinion - allowed a definitive identification of the waveform.
The modulation used is PSK4 at a speed of 2400 Baud (Figure 1).

Fig. 1 - PSK4 2400 Bd modulation

The ACF value is 37.5 ms, which corresponds to a period of 90 symbols (di-bit symbols, given the type of modulation used) or 180 bits (Figure 2): the framing consists of 31 mini-probe known symbols followed by 59 unknown symbols (data block).

Fig. 2 - 90 di-bit symbols framing
 
Regardless of the symbol values (1) the mini-probes appear to be formed using a repeated sequence of 16 symbols, to be precise 16+15, which is similar to that used in the mini-probes of MS-110D (Figs. 3,4) [1].

Fig. 3 - mini-probes symbols of the analyzed PSK4 waveform
Fig. 4 - mini-probes symbols of MS-110D waveform

Direction finding by linkz (TDoA algorithm) returns to Cholet, a French city where Thales has its Telecommunication R&D department (Figure 5).

Fig. 5 - TDoA results (thanks to linkz)

Initially, this clue led me to think of the High Data Rate Single Tone modem built into the Thales TRC-3600/3700 ​​family, which in this example runs the PSK4 waveform. 

Then, my good friend Karapuz commented the post: "Hello, my old friend! Ten years ago I first encountered a similar signal, and it seemed to me then that these packets were used in the TDMA LINK 22 channel"; my friend ANgazu too thinks of a data-link waveform and I have to say they could be right! The ACF value of 37.5 ms is somewhat misleading as it is due to a single "section" of a bit complex waveform: by enlarging the ACF window it is in fact possible to see the classic value of 112.5 ms (270 symbols) which is typical of the Link-22 Media Code Frame (Figure 6).

Fig. 6 - data-link Media Code Frames

The 270 symbols of the Media Code Frame in this sample are arranged according to a QPSK Traffic Waveform consisting of 3 sections with 31/32 symbols mini-probes and 58/59 symbols data blocks (Figs. 7,8). This also explains the mini-probe symbols in Figure 4.

Fig. 7 - the analyzed QPSK data-link  traffic waveform
 

Fig. 8 - the 3 sections of the analyzed QPSK data-link traffic waveform

This is quite unusual since, at least(!) the QPSK traffic waveforms specified in STANAG-4539 Edition 1 (TDMA waveforms, Annex D), have sections with the same number of symbols used for data while the number of symbols used for mini-probes is variable (Figure 9).

Fig. 9 -QPSK traffic waveforms specified STANAG-4539 Edition 1

From web searches, the recent edition of STANAG-4539 (February 22, 2019) provides 18 traffic waveforms, briefly listed in Figure 10, among which there are seven QPSK modulations: unfortunately I don't have this document so I don't know number and framings of the related MP/Data "sections".

Fig. 10 - TDMA STANAG-4539 traffic waveforms

Another interesting point concerns the preamble of the analyzed signal: as can be seen in Figure 11 it uses the same symbols as the Link-22 waveforms. 

Fig. 11 - Link-22 preamble (above) and analyzed signal (below)

However, looking more carefully, the preamble of the Link-22 waveforms (at least of the first three) and that of the signal in question has a duration of about 70 ms and is in contrast with what is specified in Stanag-4539 Annex D #2.3.1, ie "The preamble consists of 203 Symbols transmitted in QPSK at the modulation rate of 2400 baud. The preamble duration is ≈ 84.58 ms": until now I had never noticed this peculiarity.

Fig. 12- preamble durations

The discrepancy between the reported 70 ms and 84.58 ms for the TDMA preamble duration in STANAG-4539 can be attributed to several factors: it's possible that the preamble duration varies slightly between the TDMA waveforms and the ones actually used for Link-22 (!), or even different operational modes within them. Furthermore, there can be different interpretations or implementations of the standard by various manufacturers or research groups, leading to minor variations in reported figures.

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

(1) SA is a signal analyzer and not a decoder, therefore its phase-plane demodulator does not sync  any particular protocol. Working with phase keyed signals, the SA phane-plane demodulator produces right interpretations and views (number of phases, angles, modulation speed, carrier frequency,...) but it may return wrong demodulated streams due to the possible phase-offset errors. 

[1] http://i56578-swl.blogspot.com/2024/07/ms-110d-appd-wbhf-transmissions-collins.html