23 March 2019

Aus ADF/ MHFCS FSK 600Bd/850 with KW-46 encryption

updated

Quite good FSK 600Bd/850 signal centered on 10405 KHz from Australian Defence Force (ADF/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 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
As reported here, the lower signal in ISB mode was called "Rockwell CPU100", don't know if such nickname is still valid.

Humpty  Doo  Transmitting  Station  is  situated  on  an  almost  800 hectare parcel of land near Middle Point and is located approximately 50 kilometres east/ south east of Darwin. Run and point google Earth to 12°36'39"S   131°17'28"E.

Fig. 3 - Humpty  Doo  Transmitting  Station


https://yadi.sk/d/bW0grViPPif1KA 


26th March, update

ADF/MHFCS paradigm (signal recorded by my friend ANgazu, credits to SWLOI33 Jakarta, KiwiSDR owner). As you see, the spacing between the signals matches the expected 4 KHz. The FSK 50Bd too uses the KW-46 crypto device.



https://yadi.sk/d/_2iDRMQ9kedWeg
demod-50Bd.txt
 

15 March 2019

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
.

13 March 2019

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 (Message Indicator, MI)


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

2 March 2019

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"). Error Correction And Detection (EDAC) is performed using 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.

Fig. 1 - DHO38 constellation
Fig. 1 - the four VALLOR 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 S5030 VALLOR format (14-bit frames, KW-46 and Wagner coding).

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 VALLOR boadcasts (Y1 Y2) while the other twos (X1 X2) are connected to the shore-to-ship broadcast, 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