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).
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.
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
