Guest User


a guest
Nov 5th, 2012
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  2. *******************************
  4. *******************************
  5. courtesy of Hiram Yaeger
  7. Document Release: 1.0
  12. 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.
  13. 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.
  17. The flarm unit is transmitting data blocks of 24 bytes.
  18. Each block contains all of the informations that a remote plane need to know about a possible danger: plane identification, position, altitude.
  19. Other non-essential information are transmitted.
  21. Since version 4 of the firmware, the essential information are partially obscurated.
  23. 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".
  25. Flarm uses ATM128 by AVR as a CPU (microprocessor), running at 8-16 Mhz.
  26. These CPUs are of RISC type which means that can only do simple operations as instructions.
  27. For example: they cannot multiply or divide numbers, except if very short (0-256).
  28. 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.
  30. Using an encryption method on such a slow microprocessor (and for every radio packet!) was not so obvious because of performance problems.
  31. 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.
  32. 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.
  34. So, Google search for "AVR crypt" and you will find the very first link to a real AVR microprocessor.
  35. 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.
  38. TEA was the only one fitting for a small 24 bytes block (in fact even less).
  39. Other methods are suitable only for larger chunk of data, and they are even slower than TEA.
  40. TEA in fact means: Tiny Encryption Algorithm, not subject to any patent (free to use) since 1994.
  41. There are several ready-to-use implementations of TEA for AVR processors on the internet, for free!
  43. Guess what Flarm is using. The only possible method for a slow processor is TEA.
  44. TEA shuffles bytes for "n" times, where "n" can be a minimum of 6 times for effective encryption.
  45. Flarm encrypts with TEA using 6 iterations, THE SIMPLEST WAY.
  47. 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.
  48. Do an exaustive attempt on any possible combination of 128 bit, and you will find the password.
  51. 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?
  52. By the way, how do you think it is possible to "predict" without doing some heavy calculations?
  53. Do you really believe there are complex calculations beyond such a "prediction" ?
  58. 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.
  60. This chip can operate in different RF bands simply changing the internal PLL programming.
  62. All the timing is done with a single 16 Mhz quartz crystal (but other frequencies can be used, software selectable).
  64. 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.
  66. The device initialization in this application (for the V4 protocol) is, in Hex:
  68. 75 0e 33 18 18 93 9a 0c ff d8
  70. For the RX / TX operations, refer to the data sheet of the Nordic chip.
  72. The transmission is done randomly between 0.8 and 2.0 seconds.
  74. The data packet exchanged, that has the length of 24 bytes, contains the data as described below.
  76. Legenda:
  77. - the fix bits are marked with 0/1
  78. - the known fields are marked with letters and explained
  79. - the unknown bits are marked with x
  81. Note that for basic use, the x bits are not necessary, especially for the operation of sole reading of the radio packets received.
  82. 16 bytes are encrypted, in two blocks of 8, with the encryption algorithm explained below.
  84. Below follows the meaning of the bits, AFTER the decoding process.
  86. Byte n. contained bits
  88. 0 AAAA AAAA
  89. 1 AAAA AAAA
  90. 2 AAAA AAAA
  91. 3 x x 1 x 0 0 0 0
  92. 4 LLLL LLLL 1st byte of the 1st chunk of coded data (see later)
  93. 5 LLLL LLLL 2nd byte of the 1st chunk of coded data
  94. 6 NNNN NNNN 3rd byte of the 1st chunk of coded data
  95. 7 NNNN NNNN 4th byte of the 1st chunk of coded data
  96. 8 HHHH HHHH (7..0) 5th byte of the 1st chunk of coded data
  97. 9 VVVH HHHH (2..0)(12..8) 6th byte of the 1st chunk of coded data
  98. 10 1VVV VVVV (9..3) 7th byte of the 1st chunk of coded data
  99. 11 ZZTT TTxx 8th byte of the 1st chunk of coded data
  100. 12 SSSS SSSS 1st byte of the 2nd chunk of coded data (see later)
  101. 13 ssss ssss 2nd byte of the 2nd chunk of coded data
  102. 14 KKKK KKKK 3rd byte of the 2nd chunk of coded data
  103. 15 kkkk kkkk 4th byte of the 2nd chunk of coded data
  104. 16 EEEE EEEE 5th byte of the 2nd chunk of coded data
  105. 17 eeee eeee 6th byte of the 2nd chunk of coded data
  106. 18 PPPP PPPP 7th byte of the 2nd chunk of coded data
  107. 19 pppp pppp 8th byte of the 2nd chunk of coded data
  108. 20 xxxx xxxx (Gps status data)
  109. 21 FF xx xxxx
  110. 22 xxxx xxxx
  111. 23 xxxx xxxx
  114. Bits explanation:
  116. AA... address bits. Different for each device. The byte n. 2 is fixed to DD
  117. (but it works with any number)
  119. LL.., Latitude, 0000..FFFF is a square around the actual position: because the
  120. device tx range is limited, it is enough to transmit only the less significant
  121. part of the position.
  123. NN.. Longitude, same as before. The dimension of the square changes with the latitude.
  125. HH.. altitude, in meters.
  126. The altitude is given by the GPS, NOT by the pressure sensor
  127. Note that the maximum height can be 8192 meters
  129. VV.. vertical speed. Signed. If positive, see FF bits.
  131. ZZ 00: free mode. 10: stealth mode. Note that the position and movement data are
  132. radio transmitted correctly, with highest available precision, regardless of this setting.
  135. TTTT plane type. Starting from 0000 follows the list as described in the manual.
  137. SS
  138. ss
  139. KK
  140. kk Horizontal (N/S) speed, signed. The four bytes are different depending on speed.
  141. Used for collision forecast
  143. EE
  144. ee
  145. PP
  146. pp Horizontal (E/W) speed, signed. The four bytes are different depending on speed.
  147. Used for collision forecast
  149. FF multiplying factor for vertical speed. Meaningful only if the vertical speed is
  150. positive. 00: leave as it is. 01: multiply x2. 10: multiply x4. 11: multiply x8
  155. The two chunks of data are encrypted with the TEA algorithm, with the following parameters:
  157. common data
  159. Delta value: 9e 37 79 b9 (standard, i.e. the default delta in every TEA document)
  161. Encryption iteration loop: 6 times
  163. Keys:
  165. 1st chunk:
  166. ---------
  167. DB62
  168. 62B9
  169. A579
  170. 5664
  171. 7C97
  172. 90A0
  173. 27D6
  174. FCCE
  177. 2nd chunk:
  178. ---------
  179. A2BE
  180. C3AC
  181. D193
  182. 51E1
  183. 0801
  184. 774F
  185. 9074
  186. 262E
  189. Each iteration loop uses 2 keys.
  190. At each iteration loop the word changes. See a TEA description for any doubt.
  195. 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).
  196. There is no such method around simply because there is no prediction, unless considering simple linear projections and extrapolations, a "prediction"!
  198. 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.
  199. 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.
  201. 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.
  205. SIGNED: HP2814A01996
  206. SIGNED: JAPANS679677
RAW Paste Data