110-220Bd/330 FSK, TMS-430/TC-535 (Swiss Army)

I56578, cryptomaster

This is the well-known Swiss Army 220Bd/330 FSK system consisting of the Telematik-Set 430 (TMS-430) [1] in combination with the cipher device TC-535 [2], the utilized HF transceiver is most likely the SE-430 [3]. This signal is commonly logged as "TMS-430", although TMS-430 is actually the DTE device, while the modem function is performed by TC-535 in conjunction wih SE-430.

These transmissions can be heard almost every day on 4495 KHz (CF) around 1800 UTC, a list of frequencies (apparently constant) at which this signal was noted is: 3502 4594 5182 and 5202 kHz; old logs also reports the 120Bd waveform. Recordings used in this analysis were made thanks to the Twente WebSDR and refer to the 4495 KHz channel. 

 

Looking carefully at the signal, it's possible to note short initial segments which are sent at the speed of 110Bd (Figure 1):

 

Fig. 1 - initial segment sent at 110Bd

 

This apparently oddity intrigued me and my friend cryptomaster and so we decided to study the demodulated streams in more detail. Since the TC-535 is directly connected to the HF transceiver, from the analysis of the stream it is possible to trace and verify the operating phases of the cipher. It's to be mentioned that, given the two speeds, the streams were obtained by demodulating the signal from time to time at 110 or 220 Baud depending on the bit segment that had to be studied; the demodulation speed used for a given figure is shown in its caption.

TC-535 Synchronization sequence (COMSEC preamble) consists of a PN (Pseudo Noise) sequence termed as "Synchronizing Template" sent at the speed of 220 Baud (Figure 2). In addition to synchronization, the PN sequence is also used for (encrypted) commands transmission.  Grouping the PN sequences into a single stream and analyzing it, turns out the presence of the polynomial x^7+x^3+1: likely this is just the 7-bit LFSR (indicated as C7 in the Control Unit circuit board) which generates the PN (pseudo noise) sequence.

 

Fig. 2 - the initial "sync template" sequence (demod speed: 220Bd)

 

The sync template is then followed by the  so-called "Additional Key" (AK): a time and key-dependent 64-bit block which is tree times repeated and sent in clear-text ASCII 8N2 at the speed of 110 Baud (Figure 3, in opposite polarity). The correct additional key information is obtained by majority decision from the three additional key blocks, which are identical under good transmission conditions, and mixed with the basic key to initialize the cipher generator at the receive TC-535 (thus the AK field may be termed as the Initialization Vector for TC-535).

 

Fig. 3 - the tree 64-bit Additional Key blocks (demod speed: 110Bd)

The sync phase (PN + AKs) is then followed by a 22-bit long alternating sequence of "0"s and "1"s  which separates AK blocks from encrypted data and allows the speed change to 220Bd (Figure 4).
 

Fig. 4 - 22-bit "01" sequence, also visible in Fig. 2, unless some bit in error (demod speed: 220Bd)

An optionally switchable FEC protection is built into the TC-535. If FEC is enabled, additional check bits are added to the data, which increase the data volume by a factor of 1.4 to 2.0 depending on the user code (Baudot/ASCII). In case of ASCII, the inserted check bits reduce the useful bit rate to half and consequently bit rate shall be increased by a factor of 2, thus the 220 Baud since the ASCII operational speed is 110 Baud. This clarifies the initial 110 Baud speed used to send the AK blocks (sent as async, clear-text, no FEC)! Note that the encrypted data are only transmitted in synchronous mode and returned asynchronously to the data sink.
The doubled data volume means that FEC encoder function is accomplished by a rate 1/2 convolutional coder (as indeed confirmed in [2], "Encryption method: Bitstream encryption"). Thus, the 220 Baud speed is a sign that FEC is activated and user data are ASCII coded. 

 

About the canche to trace a check matrix/polynomial in the streams, it should be noted that documentation says "The check bits are obtained from useful bits that have already been sent and added to the data to be sent before encryption", thus FEC encoding happens before the encryption process (!) and unfortunately there will be no interesting signs to look for in the streams. 

However, it can be noted that sometimes a single transmission carries more than one AK blocks (Figure 5), so we think that a single transmission may carry multiple messages/files, each preceded - most likely - by an appropriate an PN sequence.

Fig. 5 (demod speed: 220Bd)

TMS-430 (TelematikSet 430) consists of an NEMP-protected (protection against Nuclear ElectroMagnetic Pulses) device set in a large fiberglass box, consisting of: a notebook computer Toshiba 110CS, Pentium 100 MHz, VGA screen 11.3 inches, an Epson LX 300 matrix printer, two boot disks with DOS - based software.The (in the meantime no longer completely up-to-date) notebook is equipped with a hard drive, but is intended to be started from a boot floppy disk, if necessary any other commercially available IBM-compatible computer can be used. The messages to be transmitted can be recorded directly on the system, but usually a diskette is used to transfer the text message from the command post to the transmission office.
TC-535 (TeleCrypto 535) is more than "just" an encryption device since it also automatically controls the change of direction of the radio stations involved in the link. The most important features are the time and key-dependent initialization sequence, random filler text when in idle and the non-disruptive change of direction. The device is controlled via the TmS-430 keyboard.
As said, the utilized HF transceiver should be the SE-430. The complete communications system consists of a control unit (BE-430), usually connected to a encrypter, and a radioteletype machine. The signal is transferred over field telephone lines to the transmitter site, which can be installed at quite a long distance. The transmitter site equipment consists of the transmitter SE-430, it's power supply SG-430 and the automated antenna tuner AG-510/430.

Fig. 6 - TMS-430 (on the left) and TC-535 (source: Historisches Armeematerial Führungsunterstützung HAMFU)

https://yadi.sk/d/8xDdmoSlMhEJig

[1] https://www.hamfu.ch/de/geraete/geraet.php?id=131

[2] https://www.hamfu.ch/de/geraete/geraet.php?id=130

[3] https://www.hamfu.ch/de/geraete/geraet.php?id=38

 

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

email over hf using FED-1052 DLP and "IDEA" encryption (2)

Yet another interesting catch of an email-over-hf session using FED-1052 Datalink Protocol (DLP, Appendix B) and IDEA encryption. The transmission was recorded on 09187.0 KHz/usb 1357z: encrypted MIL 188-141A 2G-ALE to set up links and switch to MIL 188-110A serial tone waveform for emal traffic via FED-1052 App.B DLP (Data Link Protocol); ASCII-7 data are encrypetd using CFB64 "IDEA" algorithm. Headers are unencoded so you can read both the sender and recipient, in this sample:

sender: ZJ1, root@bfzj1f1.is.bf.intra2.admin.ch

recipient: ZA1, statist@bf.intra2.admin.ch

email ID: "stat-ZJ1-20181113135501" (2018.11.13, time: 135501)

The FQDN (Fully Qualified Domain Name) "intra2.admin.ch" indicated in the e-mail addresses suggests an intranet of the central administration of the Swiss Federation: likely this is the Swiss Army or the Diplo Service.

A more detailed post about such transmissions can be read here.

Fig. 1 - on air signals, MIL 188-110A Serial Tone waveform

Fig. 2 - FED-1052 App.B stream

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

Swiss 2 x 100Bd/170Hz VFT system

fig 1

VFT 2 x FSK 100Bd/170Hz system used by Swiss Air Force, likely the modem is the "Telematik-Set TmS-430". Channels are simply arranged as in fig. 1.

fig. 2

fig. 3

fig. 4