FED-1052 to deliver IDEA encrypted HF email (likely Swiss Mil/Diplo)

Interesting transmission heard on 15888.0 KHz/usb at 0734z likely from Swiss Army units (callsigns ZJ1, ZA1) and consisting of a 188-141A "linking protection" handshake followed by 188-110A 300bps/Long. FED-1052 App.B Data Link Protocol (DLP) [1] is used at link layer to deliver an "IDEA" encrypted email file. 

Fig. 1 - the typical 520-bit period of FED-1052 after 188-110 Serial removal

 

Some information can be obtained from the analysis of the email headers (see below and Figure 2): for example, besides FED-1052 DLP, they use Thales TRC-3700 20W HF manpack radio [2] and IDEA (International Data Encryption Algorithm) encryption [3].
IDEA algorithm is developed at ETH in Zurich, Switzerland, and its patents are heald by the Swiss company Ascom-Tech AG. IDEA uses a block cipher with a 128-bit key, and is generally considered to be very secure. It's interesting to notice that in year 2008 Ascom Security Solutions has been commissioned by Armasuisse to deliver telecommunications equipment as part of the 2007 armaments programme: Thales TRC-3700 radio is termed as "SE-240 tactical short-wave radio" in that document: 

https://www.totaltele.com/435984/Ascom-orders-from-Swiss-army

By the way, "Armasuisse" is the Federal Office for Defence Procurement agency for armaments of Switzerland and is affiliated with the Federal Department of Defence, Civil Protection and Sport. 

Fig. 2 - HEX stream after FED-1052 removal

54 52 43 2D 33 37 30 30 20 28 54 68 61 6C 65 73 29
TRC-3700 (Thales)
indication of the HF radio used by ZJ1 (never seen before in HF emails, except in domain names)

5A 4A 31 72 6F 6F 74 40 62 66 7A 6A 31 66 31 2E 69 73 2E 62 66 2E 69 6E 74 72 61 32 2E 61 64 6D 69 6E 2E 63 68
ZJ1 root@bfzj1f1.is.bf.intra2.admin.ch
5A 41 31 73 74 61 74 69 73 74 40 62 66 2E 69 6E 74 72 61 32 2E 61 64 6D 69 6E 2E 63 68
ZA1 statist@bf.intra2.admin.ch
Callsigns of sender and recipient (ZJ1 and ZA1) and their email addresses. The term "intra2" leads to think of a intranet belonging to admin.ch which is a domain hosted by SWISSGOV-ETZ. Notice that ZJ1 is "root" at the hostname bfzj1f1.is (bf zj1 f1).
 
45 6D 61 69 6C 20 49 44 3D 28 22 73 74 61 74 2D 5A 4A 31 2D 32 30 31 38 30 37 33 30 30 37 33 31 30 30 22 20 29
Email ID=("stat-ZJ1-20180730073100" )
email id looks like the email subject:  "stat-ZJ1" followed by timestamp 2018-07-30 07.31.00
The acronym/abbreviation "stat" could mean station, status, or statistics: notice that the recipient is statist@ 

45 6E 63 72 79 70 74 69 6F 6E 4D 6F 64 65 3D 20 43 46 42 36 34
EncryptionMode= CFB64
Cipher feedback (CFB) mode using 64-bit blocks

49 44 45 41 4B 65 79 49 64 3D 20 32 30 31 31 30 34 30 34
IDEAKeyId= 20110404
IDEA Key identifier
 
49 6E 69 74 69 61 6C 56 65 63 74 6F 72 3D 20 35 35 38 32 41 42 42 30 36 41 36 30 34 45 35 34
InitialVector= 5582ABB06A604E54 
128-bit Initialization Vector (IV)

62 65 67 69 6E 20 36 36 36 20 2F 74 6D 70 2F 43 46 42 36 34 30 31 36 33 35 32 35 42 35 45 42 46 30 41 32 45 42 37 42 36 44 34 2E 64 61 74
begin 666 /tmp/CFB640163525B5EBF0A2EB7B6D4.dat
the file being transmitted is stored in the /tmp directory of a Linux/Unix system. Notice the encryption mode (CFB64) at the beginning of the filename.

-- encrypted data follows --

It seems that they always transfer .dat files whose filename is composed of "CFB64" followed by 22 uppercase alphanumeric characters. Maybe the (off-line) encryption procedure stores the encrypted files in the /tmp directory and assigns them a unique filename.

As shown in Figure 3, the email text and the .dat file are coded in the standard ASCII 8-bit format but since the first bit is "0" they use the ASCII-7 code, ie none of the additional character combinations (128-255) is used.

Fig. 3

It's noticeable that - at least in my catches - the IDEAKeyId field has always the same value "20110404" (April 4th, 2011 ?).

https://yadi.sk/d/Pl3QYEoD3ZiHVe

[1] Sending files using MS188-110A and FED-STD 1052 App.B
[2] https://www.thalesgroup.com/en/worldwide/defence/hf-3000-skyfst
[3] http://www.quadibloc.com/crypto/co040302.htm

the unid Kongsfjord OFDM (1)

If you open the Norwegian Kongsfjord kiwiReceiver and tune to 468 kHz/usb you will find a continous signal 12 kHz wide with a carrrier at +1,5 kHz from the lower edge and two smaller carriers at the signal's midband. 
I suspect this signal (and 3 other signals found a bit lower in the same band) to be Russian maritime broadcasts. My assumption is based on the fact that it was announced a couple of years ago that Russia intended to build a chain of MF broadband stations along the North Eastern Sea route [1], and that Russia had shown interest in the NAVDAT MF broadband system developed by Kenta, France, and adopted by ITU [2]. Anyway, it could also belong to a Narrowband (Under 500 kHz) Power Line Communications (NB-PLC) system used not only for smart metering but also for many other Smart Grid applications.

After waveform analysis by me and AngazU (1), the strong 12 KHz wide signal (cf at 474 KHz) turns out to be a OFDM 95-tone, 125 Hz spaced, using a mix of QAM-16, QAM-32, and QAM-64 modulations at the same time, ie in different subcarriers, with a symbol-rate of 116.8 baud (Fig. 1)

Fig. 1 - signal spectrum

The signal seem structured as follows (Figs. 2,3):
- 2 groups of 46 (data) subcarriers,
- 2 unmodulated pilot subcarriers, 
- 1 empty place (exactly at center band), although - according to the SA OFDM module - it seems actually a modulated tone:

Fig. 2 - main parameters of the OFDM waveform

Fig. 3 - different constellations: QAM-16, QAM-32, and QAM-64

It's worth noting that the QAM-64 constellation is ~9.75 degrees rotated (Figs.4,5). A smilar feature is offered by DVB-T2 specification (tilt angle is 16,8 degr in this case) to establish a form of diversity. Also noteworthy is that DVB-T2 uses concatenated BCH and LDPC coding for FEC as does the Russian system for the Northern Sea Route. It seems that this system has borrowed features from DVB-T2. 

Fig. 4 - QAM-64 rotation in consecutive subcarriers

Fig. 5 - using GIMP software to measure the tilt angle after six rotations

This system seems operate in a “permanent mode”, stations are transmitting continously, rather than a "sequential mode" (based on time slots). As you see in the title figure, the spectrogram shows other three similar signals with lower SNR at 378, 414 KHz and 438 KHz (central frequencies), notice in Fig. 6 that the four signals are separated by intervals which are related to the 12 KHz bandwidth (3x12 and 2x12 KHz).

Fig. 6 - up to four transmitters ?

Kongsfjord SDR seems to be the only SDR which receives these signals, probably it's due to the propagation limits in this band and the power levels used since the radiated power from the regional coast station transmitter should be what is sufficient to cover the intended service area of that coast station. If you look at the map at page 3 in the cited document about a Russian Arctic MF communication system [1], below in Figure 7, you will notice the chain of stations are plotted and that one (service zone 2) covers the position in Norway where the Kongsfjord SDR is located. Also a transmitter in zone 6 (there is no service circle on the map), likely Murmansk or Severomorsk port, probably could be received at the same location in Norway. Signal's levels in Figure 6 could be a confirm of the Tx sites. 

Fig. 7 - Approximate position of the local service zones. Zone radius is 200 km.

Me and friends who collaborate to this analysis emailed Mr. Bjarne, Kongsfjiord SDR admin and arcticdx.blogspot.com owner, asking his opinion: he kindly replied by also sending  two jpgs which show the regional and local layout of the power grid. He tends to exclude the PLC option for political/strategic reasons and also for tech reasons ("the signal is also strong 14 km away from the KongSDR location", Bjarne says).

It's very interesting to notice in Fig. 8 that only 2 signals were visible on September 2017 (vs. the 4 which are visible today) during ALA1530LF Loop and Longwire comparative tests at KongSDR site: maybe other systems/sources were set in operation after September?
https://app.box.com/s/2hj8ep8j7dvv5r1rnqxgr6tbjauk6rl1

Fig. 8 - LF spectrum at Kongsfjord on September 2017

It will be interesting to follow these signals after the summer and look if they will be received in some other close SDRs as the one located in Haparanda (Sweden), the reason is the high latitude and the propagation mechanisms in the low portion of MF: as you know, in this month (July) in that Arctic region the sun comes up for more than 20 hours.
 

(next post here)

---

(1) Since the 11968 KHz bandwidth available for IQ recording, limited by the KiwiSDR itself, the analysis could return some inaccurate estimates, anyway we resampled the recordings to 48 KHz. 

[1] https://www.sciencedirect.com/.../S1877705815015611

[2] https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.2010-0-201203-I!!PDF-E.pdf
     https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-M.2201-2010-PDF-E.pdf 

LINK-11 CLEW, conventional waveform

The 16 tone frequencies used by CLEW are 605 Hz (used for Doppler correction), 2915 Hz (used for data and synchronization) and 935, 1045, 1155, 1265, 1375, 1485, 1705, 1815, 1925, 2035, 2145, 2255, and 2365 Hz. All information is conveyed by DQPSK modulation at symbol rate of 75 or 45.45 Baud of the 15 data subcarriers tones (Doppler tone remains unmodulated), each of the tone represents 2 data bits and then resulting in a total of 30 data bits consisting of Control Code frames and Data Message frames(M-series messages). The tone at 935 Hz corresponds to bit locations 0 and 1, last tone at 2915 corresponds to bit locations 28 and 29.

Sometimes you may see CLEW using simultaneously the USB and LSB (ISB): indeed, identical signals are transmitted on in ISB and at the receiver both the sidebands will be separately and independently deodulated.  A means is provided to allow operator selection of USB, LSB or the diversity operation (DIV) modes:

• DIV: data words derived from the diversity combination of the USB and LSB will be provided to the tactical computer. This mode of operation is used to help combat multipath interference.
• Automatic: the receiving station automatically selects the version that represents the best information available from the USB, LSB or DIV version of the received data word.

When the criteria do not establish a clear choice, the DIV version is selected.  

The three control codes which are used to operate a Link-11 net are the Start Code, Stop Code, and Address Code, each consisting of two encoded 30-bit frames. The Start Code is the first two frames of the transmitted data message while the two frames Stop Code immediately follows the last message frame to signify the end of the data. There are two stop codes according to the transmitting station: Control Stop Code (transmission from the data net control station, or DNCS) is a 2 frames consisting of all "zeros", and Picket Stop Code (transmission from a picket station) which consists of a 2 frames consisting of all "ones". 

The Start Code is the first two frames of the transmitted data message while the two frames Stop Code immediately follows the last message frame to signify the end of the data. There are two unique stop codes according to the transmitting station:

• Control Stop Code (transmission from the data net control station, or DNCS) is a 2 frames consisting of all "zeros",
• Picket Stop Code (transmission from a picket station) is a 2 frames consisting of all "ones".

Each net partecipating unit is identified by the Address Code which immediately follows the Control Stop Code if the DNCS transmits data.

Fig. 1 - Link-11 data segment

The Data Message frames (Figure 2) follow the Start Code and contain tactical information. Each Data Message frame consists of 30 bits composed of a 24-bit word provided by the tactical computer and 6 Hamming parity bits (bit locations 24 through 29) provided by the modem. The Hamming parity bits are used by the receiver modem for error detection and correction, for this reason they are also refferred to as EDAC bits. Only Data Messages contain Hamming parity bits: Start, Stop, and Address codes are not Hamming parity encoded.
Notice that the 24-bit words may be optionally encrypted using KG-40 crypto device which just sits in midlle between tactical computer and modem. 

Fig. 2 - Link-11 Data Message frames

The six EDAC bits are encoded as follows:

• Bit 29 is set such that when added to bits locations in 11 through 23, the number of ones will be an odd number;
• Bit 28 is set such that when added to bits locations in 4 through 10 and 18 through 23, the number of ones will be an odd number;
• Bit 27 is set such that when added to bits in locations 1,2,3,7,8,9,10,14,15,16,17,22, and 23, the number of ones will be an odd number;
• Bit 26 is set such that when added to bits in locations 0,2,3,5,6,9,10,12,13,16,17,20, and 21, the number of ones will be an odd number;
• Bit 25 is set such that when added to bits in locations 0,1,3,4,6,8,10,11,13,15,17,19,21, and 23,the number of ones will be an odd number;
• Bit 24 is set such that when all the bits of the frame are added, the number of ones will be an odd number. Bit 24 is called the overall parity bit. 

Figure 3 shows a check of the first six 30-bit frames of the Data Message in Fig.2

Fig. 3

MFSK-32 & OFDM 60-tone, a new "Serdolik" waveform ?

Interesting transmissions centered on 7659.0 KHz (7657.0/usb as tuning frequency) and picked up with a  KiwiSDR located in Northen Norway (Kongsdr).

Transmissions consist of MFSK-32 87Bd/97Hz and OFDM 60-tone 40Bd BPSK bursts, start and initial bursts likely act as  SOM/EOM and use a QPSK/PSK-8 2400 Bd modulation with 20ms ACF (ie 48 symbols). Both MFSK and OFDM bursts  are separated by 1900 ms and last 6000ms; the occupied bandwidth is about 3200Hz.

The OFDM bursts use the same MFSK-32 waveform as preamble and exhibit a clear 100ms CCF. Note the lack  of the usual 3300 Hz pilot tone. 
Likely it's a new waveform belonging to "Serdolik" family.

Fig. 1- MFSK-32 burts

Fig. 2 - OFDM 60-tone bursts

Fig. 3 - initial/final burst (SOM/EOM?)

The OFDM segment was observed also using QPSK modulation with a 225ms ACF

Fig. 4

Run a TDoA multilateration which showed Moscow area as the origin.

Fig.5

↓ https://yadi.sk/d/MqRF9KKs3Z6QXP

110A & S4539 data transfers

06690.0/usb 0627z: two unid stations in simplex exchanging KG-84 encrypted msgs using 188-110A  and S4539 waveforms. The exchanges were repeated several times during the morning w/out ALE handshake neither voice-comms before the init of transfers.

Fig. 1

Fig. 2

Probably a modems set-up like the one in Figure 3 was used

Fig. 3

CIS-12 & CIS Selcall FSK 150Bd/200 ("Vishnya")

Interesting and quite rare CIS-12 & CIS Selcall FSK 150Bd/200 - aka "Vishnya" - picked up by my friend AngazU using northern Europe KiwiSDRs in the 5 MHz band. Also thanks to friends cryptomaster and KarapuZ for pointing  out the name of the FSK signal and some interesting links: actually I met only single CIS "Vishnya" selcalls some months ago (November 2017) but I forgot it
http://i56578-swl.blogspot.com/2017/11/cis-selcall-vishnya-fsk-150bd200.html

CIS selcall is mentioned here in radioscanner:
http://signals.radioscanner.ru/base/signal106/
http://signals.radioscanner.ru/base/signal251/

It's notice that:
a) before the moment of transfer of CIS-12 signal, the equipment correctly stops transmission and also correctly restarts it after transferring the selcall;
b) since CIS-12 has a pilot tone at 3300Hz, the FSK insertions are centered on the suppressed carrier (zero offset from the nominal frequency);
c) after demodulation, CIS selcall exhibits a 45-bit period.

Fig. 1

Fig. 2

Fig. 3

UTE listeners frequently refer to a waveform using the name of the source equipment: in this case the nickname "Vishnya" comes from R-016V "Вишня" equipment, or R-016V "Vishnya" using the latin alphabet, which stands for the English "Cherry"  (Fig. 4).

Fig. 4 - R-016V "Вишня"

http://www.russianarms.ru/forum/index.php?topic=10775.0

http://window.edu.ru/catalog/pdf2txt/042/48042/23756?p_page=8
 

TDoA howto (tested on Ubuntu Linux 12.04)

howto compute TDoA maps with GPS enabled KiwiSDR servers around the world using Christoph Mayer TDoA scripts and his forked "kiwiclient" python stuff https://github.com/hcab14/TDoA

00=00

prerequisites:
GNU Octave (>= 4.2.2)  https://www.gnu.org/software/octave/download.html
python 2.x (mine is version 2.7.3)
git

After downloaded/installed octave and git, use git to clone TDoA repository
#cd <your_octave_directory>
#git clone --recursive https://github.com/hcab14/TDoA.git
#git pull --recurse-submodules

make a copy of TDoA procedure and symlink to kiwiSDRs positions:
#cd TDoA
#cp proc_tdoa_DCF77.m proc_tdoa.m
#cd kiwiclient
#ln -s ../gnss_pos/ gnss_pos

in kiwiclient subdirectory there should be the file read_kiwi_iq_wav.oc, if not tryto compile:
#mkoctfile kiwiclient/read_kiwi_iq_wav.cc
check if read_kiwi_iq_wav.oc has been produced then leave the directory and back home:
#cd

run octave from <your_octave_directory>:
#cd <your_octave_directory>
#octave --no-gui

install some needed packages

>pkg install -forge control;
>pkg install -forge signal;

and run the example:

>cd TDoA
>[tdoa,input]=proc_tdoa_DCF77;
this should produce two files in the png and pdf subdirectories
exit from octave:
>exit

== now you are ready==

From kiwiSDR map https://sdr.hu/map select the better SDRs for your target ( >=3 SDRs), check if they receive the target and if they are GPS'ed. Write down their URL (without the port 8073 indication) and their station-name, eg:
hsouthwest.ddns.net G8JNJ
sdr.telcosol.gr SV3EXP
sm2byc.ddns.net SM2BYC
(you have to give each station a name, I just use the KiwiDSDR name).
Also write down the central frequency in KHz of the target signal, eg: 5200.20

Now cd to kiwiclient and run the command to start the IQ recorders
the command has the format:
python kiwirecorder.py -s sdr1,sdr2,...,sdrn -f fc -w --station= S1,S2,...,Sn --log_level info -m iq -L -f1 -H f2
where:
sdr<n> = URL of the KiwiSDR #<n>
fc = central frequency of the target signal
S<n> = station name of KiwiSDR #<n>
f1 =  lower limit of the bandwidth to record in KHz
f2 =  upper limit of the bandwidth to record in Khz

so in our example, using 10 KHz badwidth (center 5200.20 KHz):

#cd <your_octave_directory>/TDoA/kiwiclient
#python kiwirecorder.py -s hsouthwest.ddns.net,sdr.telcosol.gr,sm2byc.ddns.net \
-f 5200.20 -w --station= G8JNJ,SV3EXP,SM2BYC --log_level info -m iq -L -5000 -H 5000

Stop the n-recorders using CTRL-C (it should be enough to record 30sec to 2 min). You will get three wav files (as the number of the used KiwiSDRs) with different filenames which you have to move to the 'iq/' folder !!! and three new files in 'gnss_pos/' folder which contain the coordinates of the used KiwiSDRs.

Now you have to edit the TDoA/proc_tdoa.m file and change the filenames to process, eg:
  ...
  ...
  input(1).fn    = 'iq/20180703T074355Z_8022000_G8JNJ_iq.wav';
  input(2).fn    = 'iq/20180703T074355Z_8022000_SV3EXP_iq.wav';
  input(3).fn    = 'iq/20180703T074356Z_8022000_SM2BYC_iq.wav';
if you used five KiwiSDRs you will add new lines as:
  input(4).fn    = 'iq/..._iq.wav';
  input(5).fn    = 'iq/..._iq.wav';

then edit the titles of the plots (title) and jpg/pdf output files (plotname), as well as the limits of the maps and a known-location coordinates:
  ...
  ...
  plot_info = struct('lat', [ 30:0.05:70],
                     'lon', [ -5:0.05:70],
                     'plotname', 'TDoA_8020',
                     'title', '8020 kHz 20180703T072736Z',
                     'known_location', struct('coord', [55.751244 37.618423],
                                              'name',  'MOSCOW')
                    );

save the edited file and run it in octave (as the example above):
#cd <your_octave_directory>
#octave --no-gui
>cd TDoA
>[tdoa,input]=proc_tdoa;

if everything went well you will have results files in the png and pdf subdirectories, exit from octave and browse the results.
>exit
Repeat from == now you are ready== for a new TDoA multilateration.


You might also try hf_linkz directTDoA, a python GUI interface to TDoA
http://81.93.247.141/~linkz/directTDoA/

 Have fun!

unid FSK 75Bd/250

Unusual noncoherent FSK 75Bd/250 system spotted on 14116.0 (CF), apparently coming from North-West Russia, with a 14-bit period bitstream. It's not sourced from T-107 equipment neither successfully descrambled but certainly encrypted.

 

↓ https://yadi.sk/d/lVWPp5sY3Ye7LN