Re: Flarm hidden protocol, II
jpg...@googlemail.com
Manufacturer that states its protocols are proprietary keeps its
protocols confidential!!! Where will it all end? And it all happens
without the user being aware of it. And sometimes there are bugs in
the software.
This can only be some sort of attempt to:
take over the world
abduct us from our beds and experiment on us
subject us to mind control
(delete according to your particular obsession or paranoia)
John Galloway
On Aug 7, 3:50 am, Nomen Nescio <nob...@dizum.com> wrote:
> Dear Krystoph,
>
> glad to know that you live in Switzerland like Flarm's people.
> (193.247.250.1 is a Swisscom wi-fi gateway. Ouch! ).
>
> So you say you had a look at the new protocol and "also" found that
> every while and then it is changing.. that's kind of magic!
>
> I mean, it seems that only *your* flarm protocol automagically changes
> randomly, not mine or others'. But that's not a new issue: I tell you
> another magic story. Some months ago Flarm declared that 3.11 firmware would have stopped
> functioning in February, then in April and finally in March, ... and then I gave up. In fact it never expired
> because "apparently" there was no expiring date in the 3.11 firmware around, since the systems kept on working normally.
> As a matter of fact, in Spain and other countries there are still lots of
> clubs using the 3.11 firmware that works as usual.
> "Apparently" only when Flarm introduced the 4.00 firmware they also added a time bomb to
> change the protocol on a specific date.
>
> What a joke! Think about it: forcing 10 thousands people to update their firmware
> in order to install a time bomb on it, by telling them that their devices are "expiring".
> We (users-customers) are all still laughing at this joke. We spent some time doing useless "upgrades",
> since the 4.00 was faulty and we had to install successive versions, but boys we really had
> some good time while doing it drinking a beer or two in the hangars.
>
> Both of us, "Krystoph", perfectly know that the protocol is NOT changing and it will NOT change until
> Flarm will force again all of its customers to "upgrade" again, with the risk of having units that keep on with the previous version, like it is with the 3.11 firmware.
> By the way, in order to add the new "prediction" and encryption routines, Flarm ran out of memory space
> on some old hardware version, and they had to pull out "useless" functions like .. the data logger!
> It's written here:http://flarm.invisionzone.com/index.php?showtopic=324
>
> Now talking seriously, let's clear one thing, once and forever.
>
> WHERE is the patent for using an RF transmission on a PUBLIC frequency?
> Which law allows for patenting a radio protocol? Since Flarm declared that "FLARM applies for the radio communication between the units a proprietary patent- and copyright-protected protocol.", where is the legal basis for that? I am still looking for it ...
>
> WHERE is the patent for transmission / reception / display of position data?
>
> The ONERA patent you mention covers basically a "prediction" engine, which is kind of magic
> again since Flarm has been working so hard on it in the last years.
> Personally, I think that a POSITION data sent by EVERYBODY is far much safer than a "prediction"
> data that V3 flarms, V4 flarm and next V4bis flarms will NOT even be able to UNDERSTAND, talking
> different protocols each other!
>
> So where in the world are these "patents" you are talking about?
> You have to know them since you got a "cease-and-desist" letter which normally contains these information. Patents numbers, please.
>
> The simple transmitting and displaying position data is not coverable by patents. There is some room in the area of protecting movement prediction algorythms, where some patents exist. Flarm moves in this area, where some intellectual properties can exist. Stay out of this area, and no intellectual properties will interfere with your applications.
>
> Fortunately, this game is close to the end, since FAI/IGC wants a public open protocol.
> I want a public open protocol too. I want an open market for safety technologies, were paragliders,deltas,
> light planes, baloons, and even gliders will all be free to purchase products from different brands, talking the same
> protocol, because we're all flying in the same space.
> I don't want a new Microsoft-like Swiss factory that holds a monopoly for safety in the air, based on the fact that they tell that
> they are able to "predict" were I go with a glider.
>
> So long, Krystoph.
>
> > Subject: Re: Flarm Hidden Protocol
> > Date: Mon, 4 Aug 2008 22:58:08 -0700 (PDT)
> > NNTP-Posting-Host: 193.247.250.1
> >When we looked at the new protocol we also found that the encryption
> >key and some of the data processing will change at irregular
> >intervals, based on GPS date.
> >Unfortunately we could not pursue this any further as we got a "cease
> >and desist" letter from Onera (the French research organization).
> >Apparently any FLARM-like functionality is covered by their patents
> >and we don=92t have the $$$ to pay the license fees...
> >Krystoph
>
> Original:
>
> 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
Bruce
Any sufficiently advanced technology is indistinguishable from magic.
as oner of his three laws.
So - Any technologically advanced society will use things that are indistinguishable from magic. (poor paraphrase but
there you have it)
If the proprietory bits bother you I suggest you think of FLARM as magic - it's easier.
Then it goes along the lines of - I am here doing this, and other people are nearby doing other things, and when we
become potentially dangerous to each other it warns us. Magic.
While the technical details are interesting, they are not particularly any of our business.
Now if the developers start making bad choices, and the product usability is impaired, they will be in good company with
the likes of IBM and Microsoft and Apple. In time honoured process they will antagonise customers and legislators (like
the FAI and EASA). Consequently they will lose sales, be forced to reconsider and hopefully improve the offering. Once a
product has critical mass, it takes a real effort to break it completely...
Am I missing something?
Cheers
Bruce
Big Wings
development. It reduces the likelihood that persons with malicious intent
can compromise the security of the system by making a device which
transmits data intended to cause spurious alerts - making FLARM
worthless.
With all devices, in effect, made by one company one can have greater
confidence (or at least know who to blame) pending an agreed public
standard.
A standard protocol might well have to include encryption.
Marc Ramsey
of various RTCA and FAA documents. The standard requires esoteric
knowledge of various software and hardware encoding techniques, rigorous
design processes, extensive certification testing, and manufacturing
according to strict standards. Among other things, all of this is
required to make reliable inter-operation possible for proprietary
hardware and firmware, independently developed by various manufacturers.
Of course, it then ends up costing each of them a few million US
dollars to design, certify, and start up manufacturing for a new device.
An alternative is to standardize the behavior of the transceivers by
ensuring that each unit uses a specific type of microcontroller, GPS
receiver, and pressure sensor, while running the same or proven
compatible firmware. All of the algorithms, calculation biases, time
latencies, etc., will be identical, so it is relatively easy (compared
to ADS-B) to implement a useful traffic warning function. Other
companies can be "certified" to manufacture compatible devices, by
licensing and requiring use of the specific hardware design and firmware.
If someone then makes a protocol compatible unit using differing
hardware and firmware, "certified" behavior of all units in the field
can no longer be guaranteed, which will affect the overall reliability
of the system. If this interferes with reliability of the traffic
warning function, the logical thing to do at that point is to encrypt
portions of the protocol, thus allowing traffic data from
"non-certified" units to be identified, and as necessary, discounted or
ignored.
So, you can spend US$15000 for a certified (but only in the US) Garmin
installation, or less than US$1500 for a "certified" (outside of the US)
FLARM compatible unit, and oddly enough, FLARM works better in gliders,
in those places where the glider traffic density justifies use.
====
DISCLAIMER: I know and communicate with individuals associated with
FLARM. The above is simply opinion and speculation based on public
information. Please ignore anything I post. Thank you.
Marc
Don Johnstone
>Spooky!!
>
>Manufacturer that states its protocols are proprietary keeps its
>protocols confidential!!! Where will it all end? And it all happens
>without the user being aware of it. And sometimes there are bugs in
>the software.
>
>This can only be some sort of attempt to:
>
>take over the world
>abduct us from our beds and experiment on us
>subject us to mind control
>
>(delete according to your particular obsession or paranoia)
>
>John Galloway
>
builders of FLARM. What does it tell us, it tells us that the company are
more interested in making money than they are in flight safety which in
many ways is good business practice. The problem is they have also
discouraged other organisations from researching an improved system as any
subsequent system cannot be compatible with FLARM.
I already had concerns over the quality of the product and the more I hear
of the methods and obstruction to competitive new devices, the more I
become concerned.
If FLARM were truly interested in flight safety over making money out of
people buying their flawed product they would be keen to encourage
widespread research and building of compatible products.
J a c k
> Now if the developers start making bad choices, and the product
> usability is impaired, they will be in good company with the likes of
> IBM and Microsoft and Apple. In time honoured process they will
> antagonise customers and legislators (like the FAI and EASA).
> Consequently they will lose sales, be forced to reconsider and hopefully
> improve the offering. Once a product has critical mass, it takes a real
> effort to break it completely...
>
> Am I missing something?
Only in lumping Apple in with the others.
Jack
Andrew Warbrick
You have loads of third party applications loaded on your iPhone then?
J a c k
> You have loads of third party applications loaded on your iPhone then?
iPhone? Yes, there is an example of an unsuccessful product. I just
can't imagine how the market could be so blind as to put money into a
product that does what it claims to do, does it well, and costs
relatively little. Did somebody mislead you WRT to the iPhone's specs?
Of course I only know what I read in the papers, since I don't own an
iPhone. I spent all my money on a glider.
Jack
Andrew Warbrick
Strange, I don't recall saying anything about the iPhone's success, the
discussion wasn't about success or otherwise it was about developers
deliberately impairing the functionality of their products for profit.
You're the one who took issue with Bruce when he said "Now if the
developers start making bad choices, and the product usability is
impaired, they will be in good company with the likes of IBM and Microsoft
and Apple".
As far as I can see Apple fully deserve to be in that list. The iPhone is
a nice product spoilt by bad choices: No non Apple approved applications
and locked to a phone service provider which provides precisely zero
service (at least where I live, that's why I don't own one). Perfect
example of what Bruce was saying.
Actually, IBM these days are much more friendly to open standards than
either Apple or Microsoft.
J a c k
> As far as I can see Apple fully deserve to be in that list. The iPhone is
> a nice product spoilt by bad choices: No non Apple approved applications
> and locked to a phone service provider which provides precisely zero
> service (at least where I live, that's why I don't own one). Perfect
> example of what Bruce was saying.
When profitability declines choices will improve. Be patient.
I would not mind having an iPhone, but it won't happen until I get a
wide choice of service providers. I am now in the process of extricating
myself from the clutches of a cell phone service provider with an
inflated idea of the value of their services, and an extremely
frustrating approach to customer service.
Now, if we could just do that with government bureaucracy....
Jack
Don Johnstone
An Iphone does not purport to be a vital item of safety equipment. Secrecy
is fine for non "vital" equipment although it stifles competition and
compatability. The frequency and data transmission protocols for a PLB are
not kept secret. Can we be sure that FLARM works as it should when we only
have the word of the manufacturer and no independent assessment. Someone
might have to die to find out that FLARM does not work as it should. It
might "appear" to work but who really knows. Do we really trust a
manufacturer who wraps his product in secrecy, what are they trying to
hide?
Lars Peder Hansen
"Don Johnstone" <gpn...@okbloggs.co.uk> wrote in message
news:6g6sjoF...@mid.individual.net...
>
> An Iphone does not purport to be a vital item of safety equipment.
Neither does FLARM. It is a lookout HELP, that's all. -This is surely
something the FLARM folks make no secret of in their manuals.
>Do we really trust a
> manufacturer who wraps his product in secrecy, what are they trying to
> hide?%
No, and why should we? I've flown with FLARM for a year now, and it has
saved me a couple of near-misses in both Denmark and the Alps. It seems to
work exactly as described, but that is not the point. It is ME as pilot in
command that tells my glider where to go, and all decisions are MINE.
If FLARM works correctly 95% of the time and can help me with some
maneuver-to-avoid decisions, then that is great.
Be careful out there,
Lars Peder
DG-600 EE, Denmark
PS: Why do they call it near-miss? Near-hit would make more sense, wouldn't
it?
FLARM
and throwing dirt. As anyone knows, IP addresses, email accounts and
names can easily be faked. It is quite likely that all the recent
anonymous postings originate from the same well known source, just to
stir up a fake or misleading controversy.
Flarm has always communicated openly and transparently, see our
website for up to date information on technical and business
developments, including IP:
http://www.flarm.com/news/index_en.html
In particular we have argued in detail why publishing the RF protocol
is currently impossible:
http://www.flarm.com/product/Compatibility_Considerations_1_1.pdf
The explanations in that document are widely supported by independent
experts.
The changes (and underlying motivations) to the v4 version are
described since many months here:
http://www.flarm.com/support/updates/index_en.html
and yes, they do contain significant enhancements to the RF protocol
which did not allow backwards compatibility, see
http://www.flarm.com/support/updates/index_en.html#_Toc192870771
The release of a mandatory version update is not a short-term
reaction, but consistent with our product strategy and adjacent
communication since beginning in 2004. It was clear and communicated
that v4 will come in spring 2008, and requires everybody to upgrade.
The next one is early 2011.
The users are very happy with the performance of version 4,
unnecessary alarms are significantly reduced and the new "Info Alert"
helps to generally increase situation awareness.
Our online range and installation analysis tool easily allows anyone
to check the installation and performance of FLARM
http://www.flarm.com/support/analyze/index_en.html
All of this is free, of course.
The hardware inside Flarm products is by far powerful enough to take
care of the various tasks around the full functionality our products
offer. Check the block schemata on hard- and software on
http://www.flarm.com/product/flarm_block_diagrams.pdf
as published in gpsworld.com in August 2005.
We have refused to collaborate with a few individuals of questionable
character and everybody can see today how well judged that decision
has been. Those individuals are now doing what they have threatened to
do if we don’t give in to their demands: slander our reputation
through spreading of false information, some of it anonymously.
Urs + Andrea
Founders of FLARM Technology
Don Johnstone
>through spreading of false information, some of it anonymously.
>
>Urs + Andrea
>Founders of FLARM Technology
Firstly I am not an anonymous poster. I view with concern that your
instrument has not been independently tested or certified, the quality of
your components have not been independently verified and most of all you
use an unlicensed, unregulated radio frequency to transmit data in a
proprietary format which is encoded. This makes sure that your instrument
can never be compatible with any other simular instrument and is a
restriction on competitive reasearch. Submit your instrument for proper
certification to EASA/CAA/FAA so that everyone can be sure of the
reliability of your claims and much of the critisism will be withdrawn. If
your instrument had the seal of approval from such an organisation my
critisism would cease.
I repeat, the makers of PLBs do not see the need to keep their protocols
secret, neither do the makers of Mode S units. What is your reason for
doing so other than to maintain a total monopoly and justify your stance
of not allowing independent test and evaluation.
Despite your claims you admit that there have been problems with false
reporting, what of course is unknown are the number of near misses that
you instrument has failed to report, where the pilot(s) have been unaware
as well.
>
u...@flarm.com
> instrument has not been independently tested or certified
Dear Don,
We appreciate your honest criticism and above comments about
misinformation were not targeted at you.
For a list of over a dozen independent tests of FLARM please go to:
http://www.flarm.com/news/index_en.html (on the right side of the
window)
Most tests were not done by EASA of FAA, but by pilots and flight
instructors. As a pilot and engineer, my job is to make other pilots
safe and happy first, then the government (they seem to like it,
too...).
The FLARM system undoubtedly has its limitations, but it is here, it
works and it is affordable.
For genuine technical concerns or suggestions, please contact us
directly in one of the FLARM forums http://www.flarm.com/forum or at
info [at] flarm.com, we are eager to further improve the system.
To stay updated on FLARM news, join the Email list by sending an empty
mail to user-li...@flarm.com The list is moderated, we will not
give your mail address away for non FLARM purposes and we will keep
the number of sent mails to a minimum.
Urs - FLARM
Look outside! Never rely on FLARM. A vigilant effective lookout is
required at all times!