MHFCS FSK 600Bd/850 with KW-46 encryption

Quite good FSK 600Bd/850 signal centered on 10405 KHz, from Australian MHFCS, heard some days ago around 1630z using iw2nke KiwiSDR (center Italy). As reported in UDXF logs by Eddy Waters [1] [2], Australian Defence Force (ADF) has changed the previous dual channel system (ISB) to two single channel with 4 KHz spacings: the lower of the 2 frequencies has a speed of 600 baud, while the higher is 50 baud. The shift in both cases is 850 Hz. As in the waterfall above, I did not hear the 50bd FSK signal 4 KHz above (i.e. on 10409 KHz): maybe it's missing? Eddy also logged 10405 KHz frequency reporting ADF MHFCS Humpty Doo as location of the Tx.

Fig. 1 - main parameters

 

After arranged the demodulated stream into a 7-bit format, it's possible to detect the presence of the sequence called "Fibonacci bits" originated by the polynomial x^31+x^3+1 and which reveals the use of KW-46 crypto device (Fig. 2) as per STANAG-5065 Annex-A.
 

Fig. 2 - 7-bit frame delimited by KW-46 sync bit

Sometimes an FSK 50Bd/340Hz transmission has been seen within the 600Bd/340Hz signal so in these cases they operate in ISB mode: according Eddy Waters from UDXF, the USB side is called "Rockwell 700B" while the LSB side is called "Rockwell CPU100" (Fig. 3). 

 

Fig.3

Just a tip: in order to identify the MHFCS transmissions, in addition to the dial frequencies listed  here (remember that they use a 1500Hz offset above the indicated carrier) and to the shift and speed parameteres (tipically 600Bd/340Hz), think that these MSK signals exhibit a quite unique sign when inspecting the harmonics  using the SA 'involutions' tool. In this case, you will see the presence of several spectral lines in the 7^ power (Fig. 4).

Fig. 4

[1] https://groups.io/g/UDXF/message/85118

[2] https://groups.io/g/UDXF/message/85361

https://yadi.sk/d/bW0grViPPif1KA

 

Australian MHFCS

Australian Defence Force (ADF) Modernised High Frequency Communications System (MHFCS) is a managed, long-range strategic communications system that enables the secure exchange of information, such as voice, e-mail, facsimile, interactive data and organizational messages, between fixed and mobile stations using one integrated system. MHFCS features automated priority messaging, an assured delivery system, extensive geographic coverage that includes2,000 nautical miles offshore, and automated frequency-management and traditional-operator tasks.

The fixed network comprises four remotely located radio stations referred to as Nodes. The Nodes are situated in the Townsville, Darwin and North West Cape areas; and the Riverina region (see Figure 1):

 

NORTH WEST CAPE, WA (S22.20 E114.30)
DARWIN, NT (S12.22 E130.59)
TOWNSVILLE, QLD (S19.28 E146.25)
RIVERINA, NSW (S35.01 E146.25)

Fig. 1 - MHFCS nodes

 

Each Node comprises two sites, a Receive site and a Transmit site situated approximately 50 kilometres apart, with a Local Management Facility located at one of these sites. The Local Management Facility within a Node manages the radio assets located at the Receive and Transmit sites. Inter-Site Links connect the Transmit site to the Receive site within a Node.  The Nodes are connected by Inter-Node Links to the Network Management Facility that acts as the control access point for all communication traffic to and from external and mobile users.

Harris WB operations and UK MoD XMPP over HF: interesting confirmations

Reading the Harris and Isode-Babcock presentations at the recent HFIA Meeting in San Diego, CA (February 14, 2019) I had an interesting feedbacks which could confirm the guess I did about:

1) new wideband HF waveforms tested by Harris (the analysis is posted here)

2) XMPP chat over HF by UK MoD (the analysis is posted here).

1) In the Harris presentation "Summary of Harris on-air testing of WBHF systems 2010-2018" you can read that since 2015 Harris began development of a WBHF Hybrid Automatic Repeat Request (ARQ) waveform for use on HF (WHARQ). It supports 3, 6, 9, 12, 15, 18, 21, 24 kHz. WHARQ is bundled in a new radio mode called 3G Wideband IP (3GWBIP) which has been tested extensively on the bench and over the air. On-air 3GWBIP testing took place on november-december 2018 using NVIS link and 150 Watt power.

As posted here, me and some friend of mine saw 3-24 Khz bandwith waveforms with modulations from PSK-8 to QAM-64 and data rates from 75 to 120,000 bps. Although the characteristics such as BWs, modulations and speeds are the same as those indicated in Appendix D of MIL-STD 188-110D (WBHF), these adaptive waveforms definitely do not belong to that standard. 
Maybe we just hear those WHARQ/3GWBIP waveforms?


2) in the Isode-Babcock presentation "UK Mod XMPP over HF Pilot" you find that UK MoD Funded Babcock to run an XMPP over HF trial using Isode XMPP Software. “Group Chat” provided by XMPP Multi-User Chat (MUC) is the core service Highly desirable to use Real Time Chat for Naval and Airborne communication when HF is the only available bearer. In the paper they presentred the trials run to evaluate viability of providing this service over STANAG 5066 ARQ.

 Well, I'm happy to see that this paper matches the results posted here.

use of uuencode for email attachments (Swiss-Mil)

This post is an update, mostly a deepening, of the posts published here and here with regards to the way of sending email used by Swiss-Mil. The idea came from a hint from my friend Mike "mco", whom I thank here.

When files, especially email attachments, are transmitted over links that do not support other than simple ASCII data, non-printable characters (for example, control characters) might be interpreted as commands, telling the network to do something. In general, therefore, it is not safe to transmit a file if it contains such characters. UUEncode (Unix to Unix Encoding) is a symmetric encryption based on conversion of binary data (split into 6-bit blocks) into 65 ASCII printable characters (from 32 to 96) and is just used to transmit binary files. 
A message encrypted by uuencode is easily identifiable: it begins with the line 
begin <mode> <name> 
where <mode> is the value of the access rights to the Unix file and <name> is the name of the file that will be created at decoding; the message ends with a line containing only "end". 
An example of the use of uuencode can be seen by analyzing some Swiss-Mil transmissions.
Figure 1 shows the data from a transmission, recorded on 09187.0 KHz/usb, as they appear after the removal of 188-110A overhead (the HF waveform) and the FED-1052 App.B DLP encapsulation (the Data Link protocol).
 

Fig. 1 - email inline attachment sent using UUEncode

Some data of the email are in clear text, in this sample:
ZJ1 root@bfzj1f1.is.bf.intra2.admin.ch, ZJ1 sender
ZA1 statist@bf.intra2.admin.ch, ZA1 recipient
email ID: "stat-ZJ1-20181113135501" (2018.11.13, time: 135501)

The contents are encrypetd using the "IDEA" algorithm (1) [1]:
EncryptionMode=CFB64, Cipher feedback (CFB) mode using 64-bit blocks
IDEAKeyId=20110404
InitialVector=10A2B70A51AACF17, 128-bit Initialization Vector (IV)

The email attachment consists of the (encrypted) block between the lines:
begin 666 /tmp/CFB640250215BEAD7EF13EFAE90.dat
end
that clearly indicate that uuencoding is being used. More precisely, at receive side will create a file named CFB640250215BEAD7EF13EFAE90.dat with access rights 666 in /tmp directory. 

Since in all my samples the uuencoded filenames start with the cipher feedback mode CFB64 (see here) I tend to think that those files are first encrypted using IDEA algorithm then encoded by uuencode, according to the layers shown in Fig. 2.

 

Fig. 2

 
As ending note, it's interesting to notice that this method of message formatting is suggested for any email client or gateway that does not  support MIME and that long before the MIME format  there was just UUEncode. Maybe do they use old not-MIME Unix systems? Do they need to be compatible in all their networks?


(1) IDEA algorithm is developed at ETH in Zurich, Switzerland, and its patents are heald by the Swiss company Ascom-Tech AG. In year 2008 Ascom Security Solutions has been commissioned by Armasuisse (Federal Office for Defence Procurement agency for armaments of Switzerland) to deliver telecommunications equipment as part of the 2007 Armaments Programme.

[1] https://en.wikipedia.org/wiki/International_Data_Encryption_Algorithm

STANAG-5030/MIL-188-140 VLF/LF multichannel broadcast to submarines (2)

(this is a follow-up of the post published here)

The narrow 200Hz bandwidth for VLF/LF submarine broadcast and the low efficiency of the aerials are limiting factors, but the use of MSK (a form of QPSK) can allow optimum use of that narrow bandwidth. Indeed, using MSK it is possible to transmit two 100 Baud channels X and Y, each on a pair of phase, and each channel can consists of 2x50 Baud multiplexed channels. Thus, MSK can provide a TDM multi-channel broadcast of  up to 4x50 Baud within the 200Hz assigned band. These transmissions are easy to hear, either locally or, better, using remote SDRs such as the ones provided by Kiwi and thanks to the MSK demodulator coded by my friend Christoph [1] it is possible to study the bitstreams and verify their characteristics. 
The vast majority of users transmit four VALLOR channels (X1, X2, Y1, Y2), i.e. four 50 Baud channels which use KW-46 encryption system. In each channel, data are arrangend in the format defined by STANAG-5065 in which frames are delimited by the pseudo-random sequence generated by the polynomial x^31+x^3+1 ("Fibonacci bits") which also serves to sync the receive KW-46 devices. Error Correction And Detection (EDAC) is performed using (13,12) Wagner coding.

One of the examples of four VALLOR broadcast is the DHO38 station (Fig. 1): a VLF transmitter on 24.3 KHz used by the German Navy to transmit orders to submarines and navies of Germany and other NATO countries. Figure 2 shows the four X1, X2, Y1, and Y2 14-bit streams: the marked columns are the Fibonacci bits generated by x^31+x^3+1.

Fig. 1 - DHO38 constellation

Fig. 1 - the four 14-bit streams from DHO38

The most interesting subComm station is FUE French-Ny on 65.8 KHz from Kerlouan.

Fig. 3 - FUE constellation

As shown in Fig. 4, X1 and X2 channels use the same format of the French-Ny FSK 50/850 broadcast [2]. That format exhibits a characteristic 21-bit frame and, in a way similar to STANAG-5065, two/three sub-frames which are delimited by the bits of two LFSR markers M1 and M2 and a logical "1" value bit (1-bit). The sequences for the two markers are generated by the polynomials x^6+x^5+1 and x^7+x^6+1.
The other two channels Y1 and Y2 are sent using the 14-bit frames with KW-46 encryption.

Fig. 4 - the four streams from FUE

Don't know if it is their normal way to operate or it's just a coincidence, perhaps they use two channels for the shore-to-sub broadcasts (Y1 Y2) while the other twos (X1 X2) are connected to the shore-to-ship broadcast, maybe to forward these messages to subs, who knows?

[1] https://github.com/hcab14/signal-analysis/blob/master/m/demod_msk.m 
[2] http://i56578-swl.blogspot.com/2015/06/french-navy-broadcast-fsk-50bd850.html