30 July 2018

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: 
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

No comments:

Post a Comment