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
 

Harris Citadel II secured transmissions, 12/32 bytes length IVs

Continuing the monitoring and analyzing the receivable signals around 7 MHz band, I am increasingly convinced that the Harris Citadel II is the encryption algorithm used for these transmissions. In the analysis of the bitstreams published in the previous post [1], I have spotted patterns that look like 32 bytes Initialization Vectors:  the 256 bits are split in two 128 bits parts, each 3 times repeated, sent just after the Citadel sync sequence and prepended the ciphertext (Figure 1). 

Fig. 1 - 32 bytes (256 bits) IV

This type of encrypted transmissions occurs when the STANAG-4538 circuit mode service is used, in the packet mode service (L/HDL protocols) - although Citadel is also used there - the bitstreams do not show any repeating pattern: my guess is that in such a case the Citadel I algorithm is being used.
That said, I took care of catching & recording only the circuit mode transmissions, still within the same portion of HF band. Bitstreams analysis turned out to be very useful, especially the transmissions recorded on 6769.5 and 6772.5 KHz/USB; indeed, in these transmissions the used Initialization Vector (IV) is 12 bytes (96 bits) length and it's three times repeated (Figure 2): this is really interesting since I would have expected to see 32 bytes IV as in other similar recordings.

Fig. 2 - 12 bytes (96 bits) IVs after removal of the initial sync sequences

I have verified this characteristic in all transmissions recorded on that frequency, Figure 2 lists only a few for brevity.

Fig. 3

So far, I've observed the following format (related to S-4538 circuit mode services):

16 bytes start/sync sequence 0x1E561E561E561E001A5D1A5D1A5D1A5D (Citadel)
12 bytes IV (3 times rptd) - OR - 32 bytes IV (2×128 bits parts, each 3 times rptd)     
ciphertext
...
8 bytes end sequence 0x1E561E561E561E08 (Citadel)  

The different lengths of the used Initialization Vectors (12 and 32 bytes) suggest that the Citadel II algorithm (if this is the case) can be configured for different block cipher modes with different block lengths; moreover it's backward compatible with its predecessor Citadel I, given the coexistence of circuit/packet modes within the same logical link (see the comment in previous post). Anyway, different configurations of the algorithm in different frequencies make me think about field tests: indeed war theaters are formidable test-beds not only for weapons but also for milcomm technologies, new waveforms and COMSEC.

The few informations I could find by googling the web seem confirm my guess, even if I've still no confirm: "The Citadel II algorithm can be operated using any block cipher traffic mode [...] include Cipher Feedback mode (CFB), Counter Mode and Self Synchronizing Cipher Feedback Mode (SSCFB). The 256-bit Citadel II algorithm provides a configuration that is interoperable with current Citadel I-based applications and a configuration that is fully disclosable" [2]. 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 Harris Falcon II, Falcon III family radios. 

It is still not clear to me why the (presuemed) Citadel II encryption is not used in packet mode transmissions, ie in LDL/HDL protocols: I don't think it's due to problems acquiring the IVs since at the upper layer surely sits a data link protocol like S-5066 which is able to assemble the received packets.

Obviously - as said - these are just a my speculation and comments are welcome: further recordings and bit luck may help...

https://disk.yandex.com/d/2ceYFGyy0LWdJA

[1] https://i56578-swl.blogspot.com/2023/05/harris-citadel-ii-secured-traffic.html
[2] https://www.researchgate.net/...

Harris Citadel II secured traffic?

For some days now I have been dedicating some time to monitoring the 6.8-7.1 MHz band where it is possible to receive several STANAG-4538 (3G-HF) signals and among which also WHARQ wideband activity [1], the latter waveforms developed by Harris (now:L3Harris) [1]. Figure 1 is an example.

Fig. 1 - L3Harris WHARQ traffic [1]

 

What turned out to be very interesting are the S-4538 circuit mode services where MS-110A is used as the traffic waveform (Figure 2), note also that sometimes the packet mode service follows, in the case of Figure 2 using low-latency data link (LDL) protocol and BW3-BW4 waveforms

Fig. 2 - STANAG-4538 traffic using circuit mode and packet mode services

After demodulation of some MS-110A segments, the presence of the well-known sync sequence:
1E 56 1E 56 1E 56 1E 00 1A 5D 1A 5D 1A 5D 1A 5D 
in all the segments indicates that the traffic is secured by the Harris Citadel cryptographic engine [2], so far nothing new (Figure 3).

Fig. 3

What really surprised me is that once removed the sync sequence (or reshaping the bitstream to to 128-bit length period) a 256-bit pattern, split in 2 parts each 3 times repeated, emerge from the bitstreams... never seen before in such secured transmissions!

74 04 9F 5C 72 1C 0F 51 CB EE 30 AA F6 01 ED 1A 54 F0 CE C2 DA 02 C8 CB 81 91 3C 8A C9 07 67 01
EE 82 FB 12 56 78 A1 2E 75 7F 21 39 26 24 A7 A8 F4 A6 CF CE 56 B0 E4 18 22 E2 F1 C0 1E 8E 17 DA
40 36 4B A6 74 6A 63 05 A5 E8 81 14 A7 65 25 73 43 26 17 13 0D AB 4C F0 90 8D 5B 5A AB A5 4C 9A

Fig. 4 - 256-bit patterns (2x128)

Even more interesting is the fact that the bitstream resulting from the demodulation of one of the BW3 bursts (the same 111-byte packet was sent several times) while indicating Citadel encryption does not show those 2x128 bits patterns (Figure 5).

Fig. 5 - BW3 bitstream (8/128 bits period)

So: 

* since, for example, KG-84/KIV-7 use a 16 bytes length Initialization Vector and it is sent in 2 parts of 64 bits length (each 4 times repeated), 
* given the presence of the well-known Citadel start/stop sequences,
* it's not an AES algorithm since the length of its Initialization Vector is 16 bytes regardless of the key size (12 bytes for AES-GCM) 

It's a mine guess that maybe we see  32 bytes Initialization Vectors, which are sent in 2 parts of 128 bits length, each 3 times repeated, and that these transmissions could be secured by the 256-bit Harris Citadel II algorithm [3] which likely needs such IVs.
Obviously that's just a my speculation, comments are welcome.

Monitoring was possible thanks to KiwiSDRs from Romania (YO8SGV - Dorohoi)  and Russia (radiorubka - Tambov) so they must be using low power and NVIS techniques.

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

[1] https://i56578-swl.blogspot.com/search/label/WHARQ
[2] https://www.cryptomuseum.com/crypto/harris/citadel/index.htm
[3] https://www.cryptomuseum.com/crypto/harris/citadel2/index.htm
 

a MS-110A modem running in ASYNC mode

This is a sample of MIL-STD 188-110A Serial 75bps/L modem working in ASCII ASYNC mode and transporting a Citadel encrypted file. The transmission was heard on 7413.0 KHz/USB following a 188-141A handshake between two Algerian Air Force nodes: CM2 (Algerian Air Force Base - Oran, 2nd Regional Command Centre) and COF (Algerian Air Force HQ - Cheraga). 

In ASCII Asynchronous mode the bitstream consists of a 8N1 structure: one start-bit (0), 8 data-bits and at least one stop-bit (1). Each character is transmitted using a total of 10 bits and the 8 data bits are transmitted with the LSB first.

Fig. 1

Working in the ASYNC part, after removed both the start and the stop bits we get the clean 8-bit data where the characterstic pattern of the Harris "Citadel" encryption is easy to identify (Fig. 2).

Fig. 2

A similar example but related to Asynchronous STANAG-4285 can be read here:
http://i56578-swl.blogspot.it/search/label/Stanag-4285%20Async

You may use the MIL-STD Data Modem Terminal (MS-DMT) [1] to verify how the MS-110A works in ASYNC mode (Figs. 3,4)

Fig. 3 - MS-DMT settings for ASYNC mode

Fig. 4

[1]
http://www.n2ckh.com/MARS_ALE_FORUM/MSDMT.html
The latest MS-DMT test build is available at:  
www.n2ckh.com/MARS_ALE_FORUM/MSDMT32v200B1000TB1002_FI.zip

Thanks to  Steve Hajducek for the update, I suggest to subscribe his group at
https://www.facebook.com/groups/MARS.MIL.STD.TOOLS.LIB/

https://yadi.sk/d/1rw59Z0K3QuToC 
(MS-110 Async from Algerian AF)

short bit-analysis of a STANAG-4538 LDLn transfer (BW3 bursts)

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 segment (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 Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet (8n+25 bits) and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the data packet with CRC (8n+57 bits) to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air length of a LDLn burst is given by:

total on-air LDLn bits (n = 32,64,96,...,512) = 8n + 64

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 ten BW3 bursts  (Fig. 1):

Fig. 1

 Some aspects must be first considered:

a) the 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder;
b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;
c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

In this sample the values of the Packet Number fields are: 0,0,1,1,2,2,3,3,4,4: maybe the destination station requested a retransmissions or, most likely, each TX Frame is sent twice so to improve the reliability of the transfer (also note the values of the CRC fields). Correspondly, the Packet Byte Count fileds are: 128,128,...,67,67, this means it's a LDL128 transfer.
Note that the bytes contained in the packet #4 is less than 128 bytes because it includes the last data byte of the original datagram (the remaining 128-67 bytes are filled with "0" value bytes). That said, the original datagram of this sample is composed of the single packet numbers 0,1,2,3,4 (ie BW3 #0, #2, #4, #6, #8) and its length is (128 x 4) + 67 = 579 bytes (Fig. 2); the receive station shall discard the duplicated packet numbers.
It's worth noting that in this sample there are no BW4 ACK bursts returned back: it could be an MDL (Multicast Data Link protocol) transmission or maybe I did not heard these bursts!

Fig. 2

Back to the whole bitstream, once structured in a 1088-bit period ((8 x 128) + 64), the original datagram can be extracted by isolating the firts 4 rows and removing the overhead bytes: the resulting is an HARRIS "Citadel" encrypted file (Fig. 3).

 

Fig. 3

The ten LDL128 bursts, the retransmitted packets, and the "0" value bytes fillers can be noted looking at the whole bitstream in Figure 4.

Fig. 4

https://yadi.sk/d/P0BIYELb3Lg5ex

xDL PDUs, BW2 & BW3 waveforms, and Harris 'Citadel' encryption

I spent some time to understand where and when the 'Citadel' encryption is applied to a message in the STANAG-4538 xDL implementation by Harris, eg in the RF-5800H transceiver, regardless of whether the message came from STANAG-4406 P-MUL or HMTP/CFTP and at least (!) in my copies.

HDL and LDL protocols exist in different variants, and a number n (eg xDLn) specifies the size of one forward transmission. For HDL the number n (24, 12, 6, or 3) should be multiplied by 233 bytes plus a 17-bit sequence number added by the protocol to give the total number of bytes in one forward Tx frame.  If the data segment is of length less than 233 bytes,  a sequence of null data bytes (of value zero) is appended to the data segment so as to extend it to length 233 in constructing the data packet.
In case the datagram is emptied and not all data packet positions have been filled with new packets, the remaining data packet positions are filled with repetitions of packets already residing in other positions. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets.  Note: Whenever a packet is retransmitted, it is always placed in the same packet position within the Tx frame that it occupied in the previous transmission.
Fig. 1 shows the formation of two HDL3 forward transmissions.

Fig. 1 (not in scale)

For LDL, the number n (32, 64, 96,…,512) gives the number of bytes explicitly in a tx frame plus 25 bits due to LDL overhead, ie 17-bit sequence number plus 8-bit data reserved for future use. As for HDL, the tx frame length of the LDL protocol has discrete values, so that a data segment will be padded with 0 value bits if ist length is less than the packet length established for the current LDL transfer (32, 64, 96,…,512). Fig. 2 shows the formation of two LDL512 forward transmissions.

Fig. 2 (not in scale)

Now assume that a STANAG-4406 message shall be encrypted and transferred. P-MUL protocol segments a message into UDP/IP packets with a maximum length of the IP packet of 1500 bytes. If the length of the message to be transferred is 15 kbytes, a total of 11 IP consecutive packets are required for the message transfer. Consider now how the STANAG-4538 protocols operate when transferring one IP packet. At the arrival of the first IP packet at the sender station, a link to the destination node is set up by FLSU PDUs. Then, a 1500 byte datagram containing the first IP packet is transferred for example by using two HDL6 Data PDUs or three LDL512 Data PDUs, each related to one segment of the datagram and followed by an ACK in the reverse direction. 

The Citadel engine works on each datagram before to construct the xDL PDU, in case of the incoming datagram matches the length established for the current xDL transfer then the encryption could be seen as directly applied to the xDL PDU. Since the encryption adds overhead bits, the length of the datagram segments is chosen accordingly.

encryption in a HDL formation

The insertion of the encryption is more clear looking at xDL bitstreams from the real world. An HDL12 transfer is shown in Fig. 3: the presence of the Citadel "business card" is well visible just at the beginning of the PDU (Fig. 5).

Fig.3 - Citadel encrypted 1 x HDL12 transfer

Fig.4 - Citadel encrypted 1 x HDL12 transfer

An LDL32 transfer is shown in Figs. 5,6 : the presence of the Citadel pattern is well visible just in the first packet of the datagram.
 

Fig. 5 - Citadel encrypted 2 x LDL32 transfer

Fig. 6 - Citadel encrypted 2 x LDL32 transfer

Looking at Fig.2, the correspondence 1 LDL PDU = 1 data packet could wrongly lead to think to an encryption applied on data packet basis: the encryption insertion is more clear looking at HDLn, where 1 HDLn PDU = n data packets (Figs. 3,4).

Now look carefully at Fig. 5: each packet is indicated with its index followed by the dimension of the data segment, 32 bytes in this case (LDL32). That said, why five 8-byte rows, ie 40 bytes, are printed ? The same incongruity is verifiable in HDL packets: 240 bytes printed instead of the expected 233 (fig. 7)
 

Fig.7

LDL use burst waveform BW3 to transmit its PDUs. The number of payload bits is of the form 8n+25, where n = 32, 64, 96,..., 512 and the additional 25 bits are the overhead consisting of 17 bits of the sequence number + 8 bits for future use. A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC. In the example of Fig. 7 (LDL32) we obtain (8 x 32) + 57 + 7 = 320 bits that make the 40 bytes.

For what concerns HDL PDUs, these are transmitted by BW2 burst waveform. Each data packet is composed of a 1864 bits data-segment (233 bytes) + 17 bits of the sequence number. A 32-bit CRC value is computed across the 1881 payload data bits in each data packet, and is appended to the data packet. Then, seven encoder flush bits with values of zero are appended to the 1913 payload and CRC bits of each data packet to produce an Extended Data Packet (EDataPkt) of 1920 bits or just 240 bytes.

Juts another way to say that HDL is not BW2, and LDL is not BW3: xDL are protocols while BWn are waveforms.

For what concerns MDL protocol, it seems that the Citadel encryption is applied on the incoming datagram before its segmentation (Fig. 8).

Fig.8 -  MDL transfer using 3 x LDL32

Behavior of STANAG-4538 depends on vendor implementation as well as on its configurable parameters, so this post does not aim to show a sort of  fixed rule but just some cases of  transmissions that happened to hear.

 

STANAG-4285 running in ASYNC mode

Although a bitstream analyzer recognizes physical or data-link layer protocols by matching known patterns and sequences, it isn't source-coding aware then  in order to get something that makes sense is important to know if we face a synchronous or asynchronous mode. For example, my friend AngazU sent me a STANAG-4285 transmission which transports a Citadel encrypted file: 75bps speed and long interleave are the settings for its right decoding into an ASCII-bits file.

Looking at the graphic representation of the stream it's possible identify something like the characteristic pattern of Citadel... but  it isn't: there are some bits more. The reason is that that STANAG-4285 was in asynchronous mode (or better in asynchronous operation) with 8N1 framing: eight data bits, no parity bit, one start bit and one stop bit and then each character will be transmitted using a total of 10 bits. This framing could be guessed looking at the period back from the analyzer: just ten bits (pic. 1).

Pic. 1

After removed both the start and the stop bits we get the clean 8-bit data and the Citadel pattern. It is worth nothing that processing the new stream, the analyzer easily detect the encryption (pic. 3).

Pic. 2

Pic. 3

The same issue may occur analyzing a Baudot (ITA-2) coded stream: five data bits, no parity bit, one start bit and two stop bit. The example is related to a STANAG-4285 transmission in clear text (no encryption and no re-protocolled) from French Navy FUG8. The bit analyzer correctly returns an 8-bit period and after removed the extra bits added by ITA-2 (1 bit start + 2 bits stop) we get the well-known text "VOYEZ VOUS LE BRICK..."

Pic. 4

Pic. 5

Then a big help comes from the period returned back from the analyzer: not always a stream is encrypted or looks not identifiable, sometimes it's only processed as synchronous when it's coded in async mode.