Flarm Version 4. Danger ??

[JMC]

Lisez attentivement le message au lien suivant (attention, comme il semble qu'il sera éliminé demain, je joins le texte au bout de ce message):

 

http://groups.google.com/group/rec.aviatio...d3d08230da2c76#

 

Si ce que son auteur affirme est vrai, j'ai l'impression que les utilisateurs de FLARM ont été convenablement bernés (et j'utilise un langage diplomatique, ce que je pense commence aussi par b et se termine par s en 6 lettres) par ces messieurs de Zurich, qui, pour satisfaire exclusivement le besoin d'em…er la concurrence, ont mis nos vies en danger par l'introduction d'un facteur d'insécurité, en se (nous) compliquant inutilement la vie (nous en sommes à la 4ème mise à jour en 3 mois). Je m'explique.

 

Il semblerait que le processeur utilisé soit d'une capacité extrêmement limitée (10.000 fois moindre qu'un PC), utilisé par exemple dans les machines à café.

 

Il semblerait que la seule différence de transmission entre la version 3 et la version 4 réside dans le cryptage des 3 données fondamentales que sont l'altitude, la longitude et la latitude, et que rien d'autre ne soit transmis. Comme la puissance de calcul de ce processeur est ridiculement faible, l'auteur n'a eu aucune difficulté à identifier la méthode de cryptage, d'ailleurs publique, et à en identifier les clés.

 

Jusque là, nous pouvons penser que dans le commerce tous les coups sont permis, mais en réalité c'est nous qui en faisons les frais.

 

Pourquoi? Parce que comme ce processeur est incapable de crypter les données sortantes et décrypter celles entrantes à la vitesse demandée, il "saute" des cycles pour rattraper son retard, lequel pourrait atteindre plusieurs secondes.

 

Autrement dit, FLARM a sacrifié la sécurité sur l'autel de sa guerre commerciale avec la concurrence, laquelle a déjà tout compris et a rendu en deux mois ses produits compatibles avec la version 4. Mais nous allons payer le fonctionnement "dégradé" pendant des années. En outre, l'auteur explique bien que le principe du FLARM est ultra connu depuis longtemps, qu'il n'est protégé par aucun brevet et qu'il n'est pas brevetable, pas plus que n'est protégeable le cryptage des données d'une transmission radio.

 

De plus, selon d'autres informations confirmées par des essais, il semblerait que l'altitude utilisée pour les calculs soit mesurée exclusivement par le GPS. Le capteur barométrique serait utilisé uniquement pour l'enregistrement du fichier IGC. Or il n'y a rien de plus aléatoire que ce type de calcul, et les essais menés par l'IGC (Lausanne 2006) avaient démontré des erreurs ponctuelles et imprévisibles dépassant 300 mètres en quelques secondes, soit 600 m pour deux planeurs, ce qui peut effectivement fausser totalement toute prédiction.

 

Comme cette donnée est fondamentale pour le calcul du volume potentiel de trajectoire, autant dire que si ces faits s'avèrent exacts, nous sommes dans le flou le plus total et cet appareil perdrait totalement de son intérêt.

 

Si tout cela est vrai, j'estime que l'attitude de FLARM est scandaleuse, et il serai temps d'envisager une action de masse contre FLARM pour les convaincre:

1) à ne pas transmettre de données cryptées

2) d'utiliser obligatoirement le capteur de pression pour TOUS les boîtiers

3) de cesser ces actions stupides pour freiner inutilement la concurrence qui ne représente aujourd'hui, selon les dires mêmes de FLARM, que 1% de leurs ventes.

 

En conclusions, avec la version 4, autant ne pas compter sur cet instrument et regarder dehors, encore plus qu'auparavant!

 

PS: j'ai entendu dire que DSX avait rendu son système compatible avec FLARM version 4, et que de plus cet outil est homologué logger IGC sans restriction. Quelqu'un peut-il confirmer?

 

Bons vols à tous,

JMC

-----------------------------------------------------------------------

 

Fritz Wuehler

Newsgroup: rec.aviation.soaring

From: Fritz Wuehler <fr...@spamexpire-200807.rodent.frell.theremailer.net>

Date: Thu, 31 Jul 2008 00:17:07 +0200

Subject: Flarm Hidden Protocol

 

 

*******************************

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

---------------------------------------------------------------

[Bravo Papa]

JMC,

 

Peut-être certains éléments du texte sont vrais, mais le fait qu'il n'y aurait pas de brevets semble être faux.

Une petite recherche sur internet m'as menée sur cette page de Onera.

Des brevets existent donc.

 

Quant a la technicité du Flarm en interne: Un ingénieur électronique devrait se pointer dessue pour investiguer les paroles de l'auteur.

Même si un fond est vrai, Comment convaincre la société Flarm?

Ce ne sera certainement pas en postant un message pendent 24 heures sur un groupe de discutions.

 

Légalement Flarm joue très bien au cache-cache, car ils semblent avoir les droit sur un brevet existant et le cachent effectivement derrière un chiffrage des donnez. Celui qui veut les faire changer d'avis, aura du mal.

Leur solution n'est pas imposé, donc libre a tout le monde de l'acheter ou pas. En plus ils disent eux même de ne pas se fier sur leur système.

Entre temps nous sommes plus que 11000 a l'avoir acheté et une grande majorité de nous est content de son fonctionnement.

 

Vraiment si notre communauté ne dit pas NON en bloc, rien ne va se passer. Et encore, si nous mettons la pression, dis-moi ce qui les empêche d'arrêter tout simplement. En 4 ans ils ont déjà gagné suffisamment d'argent pour partir en retraite.

 

Dur-dur cette situation

 

Bart

[Robert Ehrlich]

...

De plus, selon d'autres informations confirmées par des essais, il semblerait que l'altitude utilisée pour les calculs soit mesurée exclusivement par le GPS. Le capteur barométrique serait utilisé uniquement pour l'enregistrement du fichier IGC. Or il n'y a rien de plus aléatoire que ce type de calcul, et les essais menés par l'IGC (Lausanne 2006) avaient démontré des erreurs ponctuelles et imprévisibles dépassant 300 mètres en quelques secondes, soit 600 m pour deux planeurs, ce qui peut effectivement fausser totalement toute prédiction.

...

Juste sur ce point, je ne suis pas convaincu que l'utilisation de l'altitude GPS soit une erreur. Certes les points aberrants, ça existe et pas seulement pour l'altitude. Je me souviens d'avoir emmené mon Garmin 12 au ski, parce que j'étais curieux de connaitre ma vitesse maximale, et consultant l'enregistrement du "vol" avec CouTraCi, j'ai eu la surprise de trouver une pointe à 300 km/h provoquée par un point aberrant manifestement hors trajectoire (sans ça ma vitesse de pointe réelle était de 70 km/h). Je ne saurais dire si ce genre de points aberrants est dû au signal GPS ou à un bug du traitement de ce signal par le Garmin 12. Toujours est-il que de tels points aberrants sont faciles à détecter (accélérations impossibles) et à ignorer subséquemment. Pour les autres, même si l'altitude GPS n'a pas une précision meilleure que l'altitude pression, je pense que la différence d'altitude GPS entre deux planeurs proches calculée par deux systèmes identiques a, elle, une meilleure précision que la différence d'altitude pression, et pour éviter les collisions, seule cette différence est importante. Pour l'altitude GPS on est à peu près dans les conditions du GPS différentiel, les perturbations du signal affectant de la même façon les 2 planeurs proches, par contre pour l'altitude pression, les deux capteurs sont différents, ils ont donc une erreur propre différente, de plus c'est une pression cabine qu'on mesure qui est perturbée par des tas de facteurs différents d'un planeur à l'autre (aération ouverte ou non, vitesse du planeur, étanchéité ou non de la communication avec d'autres parties du planeur en surpression ou dépression, et j'en oublie sûrement).

[5 X]

Lisez attentivement le message au lien suivant (attention, comme il semble qu'il sera éliminé demain, je joins le texte au bout de ce message):

 

http://groups.google.com/group/rec.aviatio...d3d08230da2c76#

 

Si ce que son auteur affirme est vrai, j'ai l'impression que les utilisateurs de FLARM ont été convenablement bernés (et j'utilise un langage diplomatique, ce que je pense commence aussi par b et se termine par s en 6 lettres) par ces messieurs de Zurich, qui, pour satisfaire exclusivement le besoin d'em…er la concurrence, ont mis nos vies en danger par l'introduction d'un facteur d'insécurité, en se (nous) compliquant inutilement la vie (nous en sommes à la 4ème mise à jour en 3 mois). Je m'explique.

 

---------------------------------------------------------------

 

Quel acharnement contre Flarm ....

[jeannot1]

Bonjour,

Encore une polémique ??? Youppeee !! :lol:

Trêve de plaisanterie combien y a-t-il eu de mort (ou même de blessé) A CAUSE du FLARM ? je pense -sans trop me tromper- que l'on doit tangeanter le 0. C'est vrai que ce n'est pas un système fiable à 100% (d'ailleurs y en a-t-il un ?), mais personnellement je ne suis pas d'accord pour tirer sur l'ambulance, même si elle roule avec des pneus crevés...

Au club nous utilisons tous le FLARM et nous pilotons les yeux dehors. Qu'on se le dise !

A+

PS : seul reproche, le prix un peu du FLARM"fort"...

[SVE]

PS : seul reproche, le prix un peu du FLARM"fort"...

 

 

C'est sur moins cher serais mieux surtout pour les petits clubs, mais en gros c'est le prix d'un logger FAI, que maintenant tu as en plus de la fonction Flarm anti collision

SVE

[EricP]

... combien y a-t-il eu de mort (ou même de blessé) A CAUSE du FLARM ? je pense -sans trop me tromper- que l'on doit tangeanter le 0.

 

 

Mais le nombre d'accident est il pour autant inférieur à celui des années précédentes ?

Malheureusement j'ai l'impression que les stats n'indiquent pas non plus une réelle amélioration de la sécurité depuis la généralisation du flarm.

Alors tout cela pour ne pas améliorer le rapport accident/heure de vol

Modifié le 7 août 2008 par EricP

[Fred]

... combien y a-t-il eu de mort (ou même de blessé) A CAUSE du FLARM ? je pense -sans trop me tromper- que l'on doit tangeanter le 0.

 

 

Mais le nombre d'accident est il pour autant inférieur à celui des années précédentes ?

Malheureusement j'ai l'impression que les stats n'indiquent pas non plus une réelle amélioration de la sécurité depuis la généralisation du flarm.

Alors tout cela pour ne pas améliorer le rapport accident/heure de vol

Il faudrait disposer des chiffres sur l'Europe (au moins France, Suisse, Allemagne, Italie, ...) concernant les collisions en vol entre planeur depuis une dizaine d'annee (et non pas le nb d'accident en général .... qui peut tres bien augmenter) pour pouvoir se prononcer sur une "modification" de la tendance

 

Instinctivement j'ai l'impression qu'il y a moins de collision (cette annee j'ai rien entendu par exemple ..... corrigez moi si necessaire)

 

A+

[Yvan de Chivré]

Mais le nombre d'accident est il pour autant inférieur à celui des années précédentes ?

Malheureusement j'ai l'impression que les stats n'indiquent pas non plus une réelle amélioration de la sécurité depuis la généralisation du flarm.

Alors tout cela pour ne pas améliorer le rapport accident/heure de vol

 

Le nombre d'accidents ces derniers jours semble important; c'est un fait mais le nombre de COLLISION EN L'AIR me parait en forte diminution pour ne pas dire nul. Et ça ça pourrait bien venir de la géneralisation du Flarm malgré ses défauts.

Yvan.

[Yurek]

Mes amitiés, Yvan !

 

Même si cela reste toujours à prouver (scientifiquement, j'entends), personnellement je n'ai aucun doute : la généralisation des Flarm ne peut qu'aider à la prévention des collisions en vol. :rolleyes:

Et ceci pour une raison très simple : la vigilance en vol n'est efficace que lorsque l'on peut voir ! Lorsque l'autre planeur n'est pas visible (le cas classique d'un face à face, dans un endroit, où on a pas besoin de spiraler), la vigilance peut ne pas suffire...

 

Mais pour ce qui est de son prix, ne vous faites pas d'illusions : on a jamais vu un monopoliste baisser ses prix sans y être contraint !

Cette bataille, elle a été perdue d'avance, dès lors que la majorité des vélivoles français reprochait à un concurrent de faire de la concurrence...

 

Pour Bart : il vaut mieux indiquer plutôt un lien pour le brevet. Comme cela, chacun pourra se faire une opinion sur les brevets d'Onera, lequel Onera apparemment, ne demande qu'à vendre des licences... pour la prédiction des trajectoires !

Ce qui confirme par la même occasion que la société Flarm-Technology n'a jamais eu de brevets qu'elle prétendait avoir...

Et surtout, nulle part dans la description du FR-2780701, il n'y la moindre trace de criptage des données. Ce n'est pas étonnant : il suffit d'y réfléchir deux secondes pour comprendre que c'est une pure ineptie, lorsque l'on parle de prévention d'abordage...

 

Volez bien, les yeux dehors !

Modifié le 8 août 2008 par Yurek

[Junior]

sinon juste pour revenir au pb du flarm on a énormément de flarm qui ne fonctionne pas! idem chez vous? pas de détection!

 

Vincent P

[Bert]

sinon juste pour revenir au pb du flarm on a énormément de flarm qui ne fonctionne pas! idem chez vous? pas de détection!

 

Vincent P

 

Vous avez fait reviser les Flarms cet hiver (il y avait un offre de revision pour une vingtaine d'euros, y inclus une extension de la garantie) ?

[Junior]

on les a surtout acheté cette hiver!

 

Vincent P

[Bert]

on les a surtout acheté cette hiver!

 

Vincent P

 

Il faudrait d'abord vérifier si l'antenne RF est bien installé - facile avec le tool sur la page web de Flarm.

[Junior]

je vais regarder ça! mais le pb est que certains n'enregistrent même pas!

 

Vincent P

[Bert]

je vais regarder ça! mais le pb est que certains n'enregistrent même pas!

 

Vincent P

 

Il faudrait peut-être aussi passer par une réinitialision du boîtier. Et si rien ne marche - achetés cet hiver, il y a encore la garantie du fabricant, non ?

[jeannot1]

sinon juste pour revenir au pb du flarm on a énormément de flarm qui ne fonctionne pas! idem chez vous? pas de détection!

 

Vincent P

 

Bonjour,

Désolé de répondre avec tant de retard, mais avez vous la bonne version ? (4... quelques choses...).

Si oui, est-ce que les antennes sont bien visibles vers le haut (satellite) ? Nous avons eu ce genre de problème à l'installation car les antennes n'étaient pas fixées au bon endroit ! :rolleyes: (je parle bien de l'antenne GPS et non pas de la petite antenne de réception fixée sur le boitier)

Si non, bonjour le SAV...

En attendant vu la MTO, vous pouvez toujours potasser votre livre bleu ou vos cartes de nav !...

A+ et bons vols