if an action was bought, they would just stop selling them here. not a good outcome. and who would fund that little exercise anyway
Mike, I hear you going to open source all your code..is that true? > On 4 Mar 2016, at 00 PM, Mike Borgelt <mborg...@borgeltinstruments.com> wrote: > > If it is who I think it is they are a bunch of very smart guys and I've met > one of them. The lab will be a proper facility. > > If a traffic awareness system is mandated it should be open protocol. Real > aviation ones are. The present situation causes a nasty situation for those > doing any mandating. I suspect even some questions of illegality under > Australian Trade Practices Act. > > Mike > > > > > > > > > At 01:08 PM 3/4/2016, you wrote: >> I saw it on rec.aviation.soaring yesterday. I can't answer the points about >> crypto etc (not my field of expertise) but I'd like to see the data they >> base their claim on. They say it's been tested and confirmed by "very >> accurate tests in private laboratories" but they don't say how, or by who. >> Is the "private laboratory" a company with expertise in avionics, or their >> mate's back shed? Also, who is the writer of this article? Are they credible >> on this topic? >> >> The lack of details regarding sources and methodology make me pretty >> dubious. What do you think? >> >> >> Teal >> >>> On 4/03/2016 12:45 PM, Mike Borgelt wrote: >>> Anyone else seen this? My giess is English wasn't the language it was >>> originally written in. >>> >>> >>> Mike >>> >>> >>> *Information for all users of Flarm, OEM FLARM supplier and Flarm PowerFlarm >>> >>> * >>> --------------------------------------------------------------------------------------------------------------- >>> >>> *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 . >>> >>> * >>> >>> >>> >>> >>> >>> >>> >>> *Borgelt Instruments***- /design & manufacture of quality soaring >>> instrumentation since 1978 >>> / www.borgeltinstruments.com >>> < http://www.borgeltinstruments.com/>tel: 07 4635 5784overseas: >>> int+61-7-4635 5784 >>> mob: 042835 5784: int+61-42835 5784 >>> P O Box 4607, Toowoomba East, QLD 4350, Australia >>> >>> >>> _______________________________________________ >>> Aus-soaring mailing list >>> Aus-soaring@lists.base64.com.au >>> http://lists.base64.com.au/listinfo/aus-soaring >> >> >> _______________________________________________ >> Aus-soaring mailing list >> Aus-soaring@lists.base64.com.au >> http://lists.base64.com.au/listinfo/aus-soaring > Borgelt Instruments - design & manufacture of quality soaring instrumentation > since 1978 > www.borgeltinstruments.com > tel: 07 4635 5784 overseas: int+61-7-4635 5784 > mob: 042835 5784 : int+61-42835 5784 > P O Box 4607, Toowoomba East, QLD 4350, Australia > > _______________________________________________ > Aus-soaring mailing list > Aus-soaring@lists.base64.com.au > http://lists.base64.com.au/listinfo/aus-soaring
_______________________________________________ Aus-soaring mailing list Aus-soaring@lists.base64.com.au http://lists.base64.com.au/listinfo/aus-soaring
