******************************* FLARM PROTOCOL VERSION 4 (2008) ******************************* courtesy of Hiram Yaeger Document Release: 1.0 INTRODUCTION For some time there has been a discussion about the correctness of using a secret radio protocol for a safety device in aeronautics. This fact was never seen before and has led the FAI/IGC to PUSH for an open standard for data transmission between gliders and light planes. In a completely opposite direction, from the latest Flarm update, not only the radio protocol is secret, but part of it has also been encrypted. DESCRIPTION OF TRANSMISSION The flarm unit is transmitting data blocks of 24 bytes. Each block contains all of the informations that a remote plane need to know about a possible danger: plane identification, position, altitude. Other non-essential information are transmitted. Since version 4 of the firmware, the essential information are partially obscurated. The fact that all of the data is changing even for very small horizontal or vertical movements, lets you understand that the content is encrypted and not simply "shuffled". Flarm uses ATM128 by AVR as a CPU (microprocessor), running at 8-16 Mhz. These CPUs are of RISC type which means that can only do simple operations as instructions. For example: they cannot multiply or divide numbers, except if very short (0-256). It is clear THAT in order to multiply or divide a number, and do mathematic functions, this processor needs to be over-programmed. Normally these processors are very good for programming Elevators, Coffe Machines, anything that does not need math or that does not need speed while doing math. Using an encryption method on such a slow microprocessor (and for every radio packet!) was not so obvious because of performance problems. Compared to other processors, the Flarm is ten or hundred times slower when doing number crunching, because calculations are not its original job by design. Much surprise to discover that an already overloaded processor, starting from version 4 of the firmware, was even more loaded by an encryption routine in action every time a packet is sent or received. So, Google search for "AVR crypt" and you will find the very first link to a real AVR microprocessor. Select the "8051&AVR Cryptolibrary" and read about three algorithms: Skipjack, Sea and Tea. All of them compared in term of performance on AVR processors. http://www.cix.co.uk/~klockstone/tea.pdf TEA was the only one fitting for a small 24 bytes block (in fact even less). Other methods are suitable only for larger chunk of data, and they are even slower than TEA. TEA in fact means: Tiny Encryption Algorithm, not subject to any patent (free to use) since 1994. There are several ready-to-use implementations of TEA for AVR processors on the internet, for free! Guess what Flarm is using. The only possible method for a slow processor is TEA. TEA shuffles bytes for "n" times, where "n" can be a minimum of 6 times for effective encryption. Flarm encrypts with TEA using 6 iterations, THE SIMPLEST WAY. TEA is available of course even for PC, where Intel processors have also very powerful floating point units for math operations. A single PC is roughly 10 thousands faster than a flarm processor. Do an exaustive attempt on any possible combination of 128 bit, and you will find the password. One important issue has to be cleared out: using encryption on Flarm's CPU does in fact slow down operations. On a slow processor such as AVR Atmel is, this slowness becomes a critic factor for the overall result. Flarm could have been using this "extra" CPU load for their "prediction" algorithms? By the way, how do you think it is possible to "predict" without doing some heavy calculations? Do you really believe there are complex calculations beyond such a "prediction" ? TECHNICAL DETAILS The RF link is built around a standard chip, the Nordic nrf 905. Its microprocessor interface is a standard SPI connection, plus some status lines (mirrored into a status register) and an IRQ line. This chip can operate in different RF bands simply changing the internal PLL programming. All the timing is done with a single 16 Mhz quartz crystal (but other frequencies can be used, software selectable). The device initialization includes the chosen frequency, the packet length, the sync word (VERY important: without the right word the RF stream will be ignored), the type of transmission, and other parameters. The device initialization in this application (for the V4 protocol) is, in Hex: 75 0e 33 18 18 93 9a 0c ff d8 For the RX / TX operations, refer to the data sheet of the Nordic chip. The transmission is done randomly between 0.8 and 2.0 seconds. The data packet exchanged, that has the length of 24 bytes, contains the data as described below. Legenda: - the fix bits are marked with 0/1 - the known fields are marked with letters and explained - the unknown bits are marked with x Note that for basic use, the x bits are not necessary, especially for the operation of sole reading of the radio packets received. 16 bytes are encrypted, in two blocks of 8, with the encryption algorithm explained below. Below follows the meaning of the bits, AFTER the decoding process. Byte n. contained bits 0 AAAA AAAA 1 AAAA AAAA 2 AAAA AAAA 3 x x 1 x 0 0 0 0 4 LLLL LLLL 1st byte of the 1st chunk of coded data (see later) 5 LLLL LLLL 2nd byte of the 1st chunk of coded data 6 NNNN NNNN 3rd byte of the 1st chunk of coded data 7 NNNN NNNN 4th byte of the 1st chunk of coded data 8 HHHH HHHH (7..0) 5th byte of the 1st chunk of coded data 9 VVVH HHHH (2..0)(12..8) 6th byte of the 1st chunk of coded data 10 1VVV VVVV (9..3) 7th byte of the 1st chunk of coded data 11 ZZTT TTxx 8th byte of the 1st chunk of coded data 12 SSSS SSSS 1st byte of the 2nd chunk of coded data (see later) 13 ssss ssss 2nd byte of the 2nd chunk of coded data 14 KKKK KKKK 3rd byte of the 2nd chunk of coded data 15 kkkk kkkk 4th byte of the 2nd chunk of coded data 16 EEEE EEEE 5th byte of the 2nd chunk of coded data 17 eeee eeee 6th byte of the 2nd chunk of coded data 18 PPPP PPPP 7th byte of the 2nd chunk of coded data 19 pppp pppp 8th byte of the 2nd chunk of coded data 20 xxxx xxxx (Gps status data) 21 FF xx xxxx 22 xxxx xxxx 23 xxxx xxxx Bits explanation: AA... address bits. Different for each device. The byte n. 2 is fixed to DD (but it works with any number) LL.., Latitude, 0000..FFFF is a square around the actual position: because the device tx range is limited, it is enough to transmit only the less significant part of the position. NN.. Longitude, same as before. The dimension of the square changes with the latitude. HH.. altitude, in meters. The altitude is given by the GPS, NOT by the pressure sensor Note that the maximum height can be 8192 meters VV.. vertical speed. Signed. If positive, see FF bits. ZZ 00: free mode. 10: stealth mode. Note that the position and movement data are radio transmitted correctly, with highest available precision, regardless of this setting. TTTT plane type. Starting from 0000 follows the list as described in the manual. SS ss KK kk Horizontal (N/S) speed, signed. The four bytes are different depending on speed. Used for collision forecast EE ee PP pp Horizontal (E/W) speed, signed. The four bytes are different depending on speed. Used for collision forecast FF multiplying factor for vertical speed. Meaningful only if the vertical speed is positive. 00: leave as it is. 01: multiply x2. 10: multiply x4. 11: multiply x8 ENCRYPTION The two chunks of data are encrypted with the TEA algorithm, with the following parameters: common data Delta value: 9e 37 79 b9 (standard, i.e. the default delta in every TEA document) Encryption iteration loop: 6 times Keys: 1st chunk: --------- DB62 62B9 A579 5664 7C97 90A0 27D6 FCCE 2nd chunk: --------- A2BE C3AC D193 51E1 0801 774F 9074 262E Each iteration loop uses 2 keys. At each iteration loop the word changes. See a TEA description for any doubt. LEGAL ASPECTS While it is not possible for Flarm to "protect" an air protocol by law, they maybe could register and protect a method for predicting a flight collision by the use of calculations (if this was possible at all: pilots, especially soaring pilots, are unpredictable). There is no such method around simply because there is no prediction, unless considering simple linear projections and extrapolations, a "prediction"! You can implement your own radio protocol, even modifying the Flarm one, but you will not be able to protect it in any way, legally, since the law does not allow you to copyright or patent any radio protocol. You can propose a standard out of a protocol, but that's all about it. Anything you transmit can be used by others, without any restriction, and they can transmit like you do, on public frequencies, like the one used by Flarm. Just a quick look on the public servers that report the patents, searching for anticollision systems, will show you the amount of work that was done in this field during the end of past century. Also in this field, there is no patent assigned to Flarm. The radio transmission and use of the coordinates of a vehicle for traffic control purposes is anything but legally protectable, since it's a simple, basic concept, implemented in different fields since years. SIGNED: HP2814A01996 SIGNED: JAPANS679677