FLARM z ostatnim firmware może dawać złudne poczucie bezpieczeństwa

[WaldekK]

Na rec.aviation.soaring ukazał się bardzo ciekawy post dotyczący bezpieczeństwa, napisany przez Herberta Khuma z ABB Deutschland, dotyczący wykrytych problemów z FLARM. Ze względu na wagę problemu pozwalam sobie bez zgody autora skopiować jego informacje na naszym forum. Sądzę, że nie będzie miał o to pretensji. Może znajdzie się też ktoś, kto przetłumaczy tekst na język polski, ja niestety nie jestem obecnie w stanie tego zrobić.

W skrócie, najnowszy firmware obecny we FLARMach może zostać błędnie zdekodowany. Dodatkowo w przypadku chwilowej utraty łączności GPS, powstaje okienko czasowe, w którym nie można określić właściwej pozycji statku powietrznego. Okienka czasowe w przypadku wystąpienia tych błędów wynoszą ok. 64 s i w tym czasie nie jest możliwe określenie pozycji szybowca. Problemy te stawiają pod znakiem zapytania konieczność używania tego sprzętu na zawodach z powodów oczywistych.

Tekst skopiowany z w/w forum:

Hello Everybody
I worked for 20 years in ABB Deutschland and I have many colleagues who deal with electronic devices and GPS RF design.
We conducted a study on the operation of FLARM and the latest firmware release. I describe below what we found, and we hope that other competent can confirm our findings.
An Italian friend has translated this my description you will find at the end of the English version.

As is already well known to all users pilots,  FLARM introducing the new coding xxtea present in the latest versions of firmware released, has largely complicated life to all of us and to itself.
With the new release the whole package of 24 bytes used for the data is encrypted (the length of the data packet is actually 32 bytes, but the first 8 bytes are left in clear because they include the name of the station as well as the meaning of the content of rest of the data packet ).
With this letter we want to bring to the attention of all users as well as the competent aeronautical authorities the weak points of this new solution, but especially the incredible risks to which this technical choice of Flarm is  exposesing all of us. These risks were detected after very accurate tests performed in private laboratories in consequence to the release of the current firmware adopted. FLARM very hardly will admit the existence of these bugs and failures that we are exposing  in detail.
The following data are explained in such a way so that people have the skills and the instruments can verify the truth of what is below reported.
This subject is independent from the Flarm decision to encrypt the protocol in order to protect themselves from potential and possible competitors.
It is obvious that the encryption has been introduced for this protectionist purpose, because from a merely technical point the integrity of the data transmission was already well protected by natively incorporated algorithms within the Nordic chip used in the Flarm hardware. For those that desire more technical information on this chip, is possible to click the following link http://www.nordicsemi.com/eng/content/download/2452/29528/file/Product_Specification_nRF905_v1.5.pdf
ALL manufacturers (except one) who claim to be "Flarm compatible" have inside EXACTLY the same hardware required by FLARM and they use the firmware released by FLARM (under payment of expensive license fee).
This behavior that we know from long time, is contrary to the principle of "development for competition" than in other fields has always given excellent results in technological development.
This behavior  is especially contrary to the competition's principle that is mandatory by European rules for the sale of products to the public, it means that once people purchase products they should be functional and usable by the owner independently by firmware update. It's enough to think about Window as well as OS operating systems, that are fully compatible with earlier versions of software and operating systems used before.
But we want to come back to the description of the technical problems/issues , that is the main focus  of this information.
The data package, which we have mentioned above, is broadcasted  by FLARM units (it doesn't matter  the licensed manufacturer) 2 times every second based on the internal clock of the  GPS; the first transmission takes place in the first half of the "second", the second transmission in the second half.
For this reason, when the FLARM unit is receiving in  RF (radio frequency) transmissions of  FLARM installed on gliders nearby, and in addition these gliders are a lot, the available bandwidth in reception is saturated very quickly.
According to this situation   when there are more traffic to be controlled/monitored, and thus the potential danger situations is increasing, the FLARM  operates in the worst and most unreliable manner.
But unfortunally  this is not the only technical problem source of malfunctioning . We've found a far more dangerous firmware bug we're going to  detail below.
In order to complicate a possible decryption by third parties, the encryption key used by FLARM  is not fixed anymore (as it was  for the older version of the firmware) but is built with the code of the transmitting station and as well as with  the GPS time of the first transmission moment ,and is changed every 64 seconds.
In addition  to this during the 64 second interval, the data string transmitted change every second, because of the GPS position data updated is inside it.
The creator of the encryption code  XXTEA  says, and it is also reported by other cryptanalysts (see the articles by John Kelsey, Bruce Schneier, and David Wagner from 2002 to 2004), that exist certain combinations of DATA and  KEYS in  the encryption code XXTEA that, for some coding schemes, are producing  results that WILL NOT BE PROPERLY  decrypted also using THE CORRECT KEY.
This means in simple terms that there could be the possibility that some gliders nearby, whose code was not  properly decoded , remain invisible to the system for at least 64 seconds, in other words until the next creation  of the encryption key.
Of course it could happen the opposite case to be ourselves in the glider that at that moment is not properly decrypted   by nearby gliders ; so we are invisible to others for at least 64 seconds.
This behavior has been detected with precise laboratory instruments by simply recording the exchange of data between three FLARM units for 48 hours.
Another unreliability detected comes from the fact that when a glider flies underneath thick clouds and  is  at high bank angles , may occasionally lose the connection to the GPS network. In this situation, the firmware should transmit only the last certain position detected by the GPS,  waiting to transmit the new one as soon as the GPS hangs up the signal. The new version of the firmware without  the GPS signal stops transmitting and receiving. It is easy to understand this by disconnecting the GPS antenna of a FLARM unit in operation  and observing  the lights that indicate the transmission and reception are turning off. Moreover , it is clearly understood  by the evidence that a second FLARM device stops receiving the signal of the first device.
For the reason that the current firmware version in the absence of GPS signal stops transmitting and receiving, if ,at the time  of losing GPS signal  while change of  encryption key , that glider  will again be invisible for 64 seconds .
We report and highlight  all this, a technical denial evidence based on irrefutable arguments, to loudly state that the decision of  FLARM to encode the data packet using the encrypting code XXTEA, is generating  flying situations that will put even more in danger OUR SAFETY, instead of protecting it, as it should be with the use of such a device.
At this point it is quite easy to say that the decision of FLARM is  exclusively oriented to maintain an unlawful monopoly, for personal gain, in absolute disregard of the safety of FLARM  users.
We affirm that  is impossible to think the FLARM when issuing the new firmware version with the new encryption in March 2015, did not know what risks and unreliability exposed his system.
We say in all honesty that a collision avoidance system such as the one  created by  FLARM was certainly a great  idea for the increased safety of pilots , but the search for more profit   and the defense of its own unsustainable monopoly on the market through the continuous evolution of firmware  only for protectionist purposes has brought  today, with the latest firmware, to a situation in which this security is certainly not guaranteed, even though  the FLARM devices   are installed properly and working fine.
In light of these information, which we submit to the whole world of pilots, we wonder how could the relevant national and international aviation bodies (EASA first, then the French and other federations)  push for the adoption of the current Flarm monopoly systems in  everyday use and especially in competitions.
This information is therefore intended to attract interest for institutions, authorities and personalities involved in the flight's regulation , in order to arrive to the imposition of a public non-encrypted protocol.
This solution guarantee an excellent and reliable operation of FLARM units produced up to now, because  no longer burdened by unnecessary decryption calculations, would guarantee in terms of competition the possibility of diversify the quality of the different vendors' solutions through different software developments management of traffic information received with the public protocol.
The aforementioned technical info are absolutely replicable and verifiable by anyone who has available the appropriate equipment and technical skills.
We hope with this letter ,we made a contribution to the safety growth of the flying community

Herbert Khum
ABB Deutschland
+41 43 317 71 22

[pjalocha]

Wydaje mi się, ze post jest niestety bardzo "polityczny" i wywołany bardziej na wywołanie reakcji emocjonalnej niż na przekazanie konkretnych informacji. Pełno w nim górnolotnych formułek ale nie ma w zasadzie żadnego konkretu, choćby wyniku jakiegokolwiek pomiaru.

Fakt, że FLARM jest taką czarną skrzynką, i brak jakikolwiek konkretnych i powtarzalnych testów tego systemu, ale do porządnej krytyki wypadałoby naprawdę coś konkretnego pomierzy o podać więcej konkretów.

[WaldekK]

Wydaje mi się, ze post jest niestety bardzo "polityczny" i wywołany bardziej na wywołanie reakcji emocjonalnej niż na przekazanie konkretnych informacji. Pełno w nim górnolotnych formułek ale nie ma w zasadzie żadnego konkretu, choćby wyniku jakiegokolwiek pomiaru.

Fakt, że FLARM jest taką czarną skrzynką, i brak jakikolwiek konkretnych i powtarzalnych testów tego systemu, ale do porządnej krytyki wypadałoby naprawdę coś konkretnego pomierzy o podać więcej konkretów.

Tak chyba rzeczywiście jest. Jeśli nikt tego nie potwierdzi, należy to zignorować.

[kk]

Co to zmienia? Używanie FLARMu i tak nie zwalnia pilota z odpowiedzialności i obowiązku obserwowania przestrzeni dookoła niego. Nawet jeśli urządzenie jest niedoskonałe i wykryje tylko część (śmiem twierdzić, że jednak sporą część) potencjalnych zagrożeń to i tak chyba lepiej? Nikt normalny nie montuje tego w swoim szybowcu z myślą, że jest idealne i od tej pory nie trzeba się martwić o kolizję tak długo, jak nic nie pika...

[pjalocha]

Tak, z tego punktu widzenia FLARM w każdej sytuacji będzie miał wymówkę: pilot powinien był obserwować przestrzen wokol siebie.

Z drugiej strony jest psychologia pilota, który nie zawsze jednak obserwuje, może się zagapić, może oświetlenie być takie, ze nie zauważy, itd.
W tym celu piloci jednak używają FLARM-u w nadziei, ze może w takiej sytuacji zmniejszy ryzyko kolizji.
W tymże celu system ten staje się obowiązujący na np. zawodach.

Dobrze wiec byłoby, gdyby system jednak działał i był możliwie optymalnie zaprojektowany i wykonany.

Dochodzi tez czynnik psychologiczny fałszywego poczucia bezpieczeństwa: pilot, który zainstalował FLARM
będzie nawet na poziomie podświadomym czul sie bezpieczniej i może juz nie tak uważnie obserwować przestrzeń wokół siebie.
jesli wiec urzadzenie jest zawodne, to w efekcie podniesie sie ryzyko zderzenia.

Z tego powodu wielu pilotów niechętnie patrzy na FLARM, ktory jest systemem trudno weryfikowalnym, wiadomo jedynie ze czasem pika, ale wlasciwie nic po za tym.
Jezeli zaobserwuje sie ewidentnie nieadekwatne zachowanie tego systemu, a przecież takie obserwacje zostaly poczynione i udokumentowane,
to nie sposob jest sprawdzić, co tak naprawdę się dzieje, bo system jest zmonopolizowany przez jedna firme, ktora robi co moze aby ukryc wszelkie szczegoly jego funkcjonowania.

Wiadomo np. ze wiekszosc urzadzen pracuje na procesorach 8-bitowych klasy AVR z bardzo ograniczona predkoscia wykonywania kodu (rzedu 10MHz) oraz niewielka pamiecia RAM (rzedu 4kB).
Jesli wiec firma wprowadza nowy firmware, ktory wprowadza nowy, bardziej zawiły sposób szyfrowania, to mozna miec uzasadnione obawy,
ze 8-bitowy AVR po prostu nie da rady odszyfrowac wszystkich pakietow i system zacznie efektywnie ignorowac wiele sygnalow.
Szyfrowanie to pracuje na wielu slowach 32-bitowych, wiec 8-bitowy procesor wiadomo, ze bedzie mial z tym spore problemy.
Sam bym chcial sprawdzic, jak dlugo zajmuje odszyfrowanie pojedynczego pakietu, ale nie znalazlem na to po prostu czasu.

Według mnie obawy sa wiec uzasadnione, ale trzeba do tego podejsc bardziej konkretnie przedstawiajac konkretne wyniki badan.
Jeżeli autor podnosi temat, ze algorytm szyfrowania moze byc nieodwracalny w pewnych sytuacjach, to powinien napisac, jak czesto to sie moze zdarzac.
Jeśli pisze, ze obserwowal trafik przez 48 godzin, to powinien napisac, co tam zmierzyl i ilu pakietow np. nie dalo sie odcyfrowac, itd.

Nie ignorowałbym wiec tematu, ale zmobilozowalbym sie do konkretnych badan zagadnienia, szczegolnie jesli ten system jest zalecany lub wrecz obowiazkowy w szybownictwie.

[jaclen]

Na flarm.com w News pojawiło się oświadczenie,  ustosunkowujące się do cytowanych wyżej informacji i podważające istnienie inżyniera z ABB.

[J]

  Każdy ma swojego "BELZEBUBA " czy jak mu tam było ?
Teraz piłeczka po stronie piekła :-)

[pjalocha]

Na flarm.com w News pojawiło się oświadczenie,  ustosunkowujące się do cytowanych wyżej informacji i podważające istnienie inżyniera z ABB.

Inżynier nie istnieje, ale argumenty wciąż istnieją :-)

Odpowiedz FLARM niestety nic nie wnosi, bo zawiera jedynie ogólnikowe stwierdzenia, ze "firmware jest testowany" i zupełnie nie odnosi się do argumentów.
Gdyby cokolwiek napisali, w jaki sposób testują, jakie środowisko jest symulowane (jeżeli w ogóle jest), ile szybowców, ile pakietów nie dociera, jaki to ma wpływ na detekcję potencjalnych zagrożeń, itd.

Może coś na temat kryteriów wykrywania zagrożenia, np. jak blisko mogą się szybowce do siebie zbliżyć, cokolwiek.