S-4538/110A transfers using 256-bit Initialization Vectors (2)

Recently I analyzed an interesting recording sent me by my friend Mike (mco) some days ago; for clarity, the transmission was recorded on 8006 KHz/USB. As shown in Figure 1, the recording consists of four data segment sent using the 188-110A Serial Tone (at 600bps/S), two 188-141B async call PDUs ("obsoleted", 3G-ALE)(1) and a final FLSU (Fast Link SetUp) PDU that terminates the link, the latter BW5 waveform suggests a STANAG-4538 3G-HF "circuit mode service" transmission, as well as the use of the 141B async call suggests the use of Harris equipments.

Fig. 1

The bitstream after 110A removal (Figure 2) clearly shows the use of encrypted frames which are characterized by the use of 256-bit length Initialization Vectors (IVs), thus the data-link protocol is also encrypted (not the data only). It's to be noticed that each Initialization Vector is 8 times repeated.

 

Fig. 2

The frame structure appears almost the same of the one analyzed in a similar transmission analyzed some times ago [1], in that case the 110A modem was used at 2400 bps/S. Studying more closely the four bitstreams, it's possible to see recurrence of a same COMSEC preamble consisting of 01s sequences for bit phasing, same repeated sequences (probably for frame sync), and obviously the four different 256-bit length Initialization Vectors (Figure 3).

 

Fig. 3

phasing

223-bit sequence sync:
0101101111011010010000100011110110111101110000100100001111000100010111011010001110100101101110111
1011100001001000011110001000101110000100011101001011011101111011100001001000011110001011010001001
00001110111101101000100011110

256-bit Initialization Vectors, each 8 times repeated:
E7 F6 45 FD 63 53 2A 4B 91 0B 0E B7 A8 80 00 00 

63 35 D7 73 64 9B 8D 08 35 3F 26 0D 9D BE 02 F9 

D7 32 3B 83 D0 6F 57 03 A9 65 CA F7 64 64 00 00

9B 32 8E B9 2B D0 9D D6 00 FB 96 53 68 92 BD F5 

87 32 AA F0 9C 3D 03 EE E2 00 26 EF 45 4D 00 00 

82 8F C3 CC BF 2B 36 99 51 27 45 88 9D 83 2E F7 

77 CD 93 E5 EB AF 65 3D B6 2B 1A 47 4E 19 00 00

C6 E1 5C FA 8B 16 57 57 0E 2B 04 C9 65 66 25 F3

phasing

32-bit sequence sync (6 times repeated):
8B 87 84 7B

The COMSEC preamble is followed by encryption, according to the standard MIL 188-220D [2].

Fig. 4

 

For what concerns the encryption, I would speculate the use of "HC-256", a software stream cipher for embedded systems which generates keystream from a 256-bit secret key and a 256-bit Initialization Vector [3], but it's just a guess.

https://disk.yandex.com/d/jVqWadSb-cBevA

 

(1) 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] https://i56578-swl.blogspot.com/2020/09/s-4538110a-transmissions-using-unid-256.html
[2] http://everyspec.com/MIL-STD/MIL-STD-0100-0299/MIL-STD-188-220D_CHG_NOTICE-1_24817/ 
[3] https://www.ecrypt.eu.org/stream/ciphers/hc256/hc256.pdf 

unid 188-110A transmissions... and equally curious bitstreams

Some interesting transmissions were noticed last weekend on 5074.20 KHz/USB, transmissions consisting of continuous blocks of different durations and sent using the standard MS-110A modem with a fixed data rate of 1200 bps/S. Judging by the intensity of the signals and the fading patterns shown in the FFT-Spectrum, the transmissions were one-sided, ie PtP or PtMP (like a broadcast style).

Fig. 1

Analyzing the resulting bitstream after the demodulation of the signals, surprisingly, it can be noted that one bit is replaced by 16 bits during the reversals section (Figure 2).

Fig. 2 - 16-bit stream

However, looking more closely, it can be stated that the 1->8 replacement is adopted during the traffic period, i.e. each data bit is sent 8 times (Figure 3).

Fig. 3 - 1to8 bit replacement during traffic period

In order to get some more information, I reshaped the bitstreams to a 8-bit format and then removed the 7 extra bit columns: as you can see in Figure 4, not all the single transfer sessions have a same period, indeed it may vary from 91 to 111 bit. 

Fig. 4

Also, for some reason that I do not know, there are very few single bits of information, just pairs 11s or 00s; just for a try I arbitrarily replaced the pairs with  single bits of the same value: the resulting stream, after the removal of the reversals sections, shows 60-bit patterns. I also tried the differential decoding but I didn't get any other interesting results about the nature of the data and the used transport protocol. My friend cryptomaster, who too heard and analyzed that transmissions, got the same results.
The working frequency (5074.20 KHz/usb) is not among those known or at least it is not reported on the UDXF logs, and given that the transmissions have not been repeated and the strange characteristic of the bitstreams, it could also be test transmissions.
What is certain is the geographic area where the Tx site is located: all the direction finding tries (TDoA method) point to the state of Lower Saxony, Germany (Figures 5,6).

Fig. 5

Fig. 6

I just want to report that a similar stream has been noted in some STANAG-4285 transmissions [1]: maybe these "expansions" are used to add redundancy and then increase the reliability of the channel, although HF protocols use their own FEC encoding.

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

[1] http://i56578-swl.blogspot.com/2022/01/an-odd-16-times-expanded-5n1-framing-uk.html?m=0

RapidM proprietary WB-LDL & WB-RDL waveforms (2)

Thanks to a nice catch by my friend ANgazu from radiofrecuencias.es, who I thanks, it's now possible to add two other waveforms (#9, #11) to the Table II of the previous post [1]. The waveforms belong to the "120 ms frames" family, respectively 30 KHz bandwidth 24000 Bd (WF #9, Figure 1) and 42 KHz bandwidth 33600 Bd (WF #11, Figure 2).

Fig. 1 - 30KHz/24000Bd waveform

Fig. 2 - 42KHz/33600Bd

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

[1] https://i56578-swl.blogspot.com/2022/12/wale-wideband-traffic-probably-rapidm.html