[Battlemesh] [Office] FCC Firmware lockdown

L. Aaron Kaplan aaron at lo-res.org
Sat Sep 5 18:49:09 CEST 2015


> On 04.09.2015, at 19:10, Amelia Andersdotter <teirdes at gmail.com> wrote:
> Hi,
>> On 09/04/15 18:08, L. Aaron Kaplan wrote:
>>> On Sep 4, 2015, at 5:53 PM, Amelia Andersdotter <teirdes at gmail.com> wrote:
>>> Thanks Luis and Paul;
>>> In whose interest is it to stop unauthorised software?
>> As weird as it sounds but actually it really helps keeping the devices terribly insecure.
>> You guess who would be interested in that...
> Actually I can't. It was suggested to me only yesterday that maybe Apple
> is behind this.

Well I was no trying to attribute it to any one in particular. However I wanted to point out an unexpected side effect of these regulations. 

> You're alluding to security agencies, but the directive doesn't apply

Exactly those will benefit. Why? In the IT securities circles it is well known that attack trumps defense. Hence if you can "own" many wifi devices , you get a large forward operations basis. 

> only to apparatuses which are EXCLUSIVELY aplicable in national security
> fields.

IMHO It's not about if this is made for them or not. I did not want to imply this. Actually I don't believe that intel agencies are behind this. I believe they simply will benefit (they already do so now with all the unpacked wifi devices!). At least those large ones who may / do hack into internet facing devices.  

Personalized, flashed and non standard devices however increase the effort to hack each modified device individually. And that simply costs a lot of brain-/manpower. Therefore I support  polycultures in wifi devices and their  firmwares. 

> Personally I don't have much experience with certification authorities
> in Sweden, but they are mostly important for public procurement - that
> is, how does one make sure in the public sector that one doesn't buy
> shite? One outsources the pain of ensuring something isn't shite and
> hopefully avoids big shite costs. I've previously came across the
> problem for fire alarms (specifically fire alarms equipped with Linux,
> where an NP-complete problem hindered the proposed device/software
> combination from guaranteeing 100% non-failure - this is because it
> cannot be proven that a given algorithm will complete definitely, it can
> only be demonstrated with a very high certainty and this was

You mean the problem was mathematically undecideable? Halting problem etc.?

> insufficient for the certification authority).

>>> To my understanding these directives also cover stuff like wifi
>>> connected pace-makers and so.
>> Oh, now your' talking ;) Sweet!
>> But there is a problem with that part, see the next sentence.
>>> Health care apparatuses used for the
>>> elderly, automobile on board entertainment systems and so forth.
>> Well, in that case - at least over here - we are not allowed to update them
>> anyway. They need to be certified and after certification they MUST NEVER be updated nor changed
>> unless they will be re-certified (and that usually takes one year).
>> So nobody does that. I won't talk about the IT security issues of these devices now. You figure :)
> Right - but since the directive applies to radio equipment including
> these devices, and there is an explicit possibility for the Commission
> to make exceptions for certain categories of products from certain
> essential requirements, this needn't necessarily be more difficult than
> lobbying a national regulator to exempt certain apparatuses from the
> offending requirement (for instance by arguing that this requirement is
> indeed very helpful in already locked-down markets such as onboard
> automobile entertainment but that small scale entrepreneurship in the
> wireless sector needn't fall under such burdensome requirements).

I think you are pointing in the right direction. 

>>> There are also blanket exemptions in Annex I for anything which is not
>>> used commercially of the directive.
>> Would that cover stuff we are doing in community wireless networks?
> It might depend on what kind of association you've formed. Probably it
> depends on national law, who knows? Ask your regulator.
>>> If there is a strong commercial interest behind stopping unauthorized
>>> software that is clearly a bigger problem than if this is just a
>>> precautionary measure by the legislature to impose more liability on
>>> large-scale vendors of radio equipment to various other society sectors.
>> true
>>> One way to certify experimental solutions could perhaps be to ask the
>>> national regulatory for a de minimis-exception: if the market shares are
>>> so small that the burden of certification is clearly unreasonable, then
>>> a market actor can self-certify knowing that failure to do so adequately
>>> will impose liabilities. This rule could apply for any commercial actor
>>> which holds less than 5% of the relevant market shares within any
>>> particular market branch. De minimis is a known concept from competition
>>> law, and in this case it would serve to help small market players avoid
>>> impossible costs of certification. Something like this.
>> So this would be an idea for the putting into national law part?
> One could. If one were so inclined, one would have to think about
> complications, but afterwards one could consult the regulator and
> probably responsible people inside the government. A de minimis-rule
> could technically applied at any % of market presence (2, 5, 10, or
> whatever). There are already fixed limits from the De Minimis-framework
> in competition law so no new thinking is essentially required.
> I'm currently preparing a formal response to a Swedish government
> consultation process, but my interest in this directive so far has been
> the essential requirement on privacy protection/data protection in
> article 3(3)(e). Since national regulators will now have a larger
> ability to act on enforcing essential requirements I've been considering
> proposing the Swedish Data Protection Authority is named supervisory
> authority for article 3(3)(e), since they've accumulated experience in
> the field (two investigations done in 2009-2010 and 2014-2015
> respectively on the mobile phone sector). The organisation for which I
> will propose the draft eventually works with digital rights and are
> technically-minded, so it might also interest them to make a de
> minimis-proposal. Tbh I just thought of it and there may be huge
> complications which I haven't thought about.
> I will read Luis comments very carefully and then I can write to the
> Swedish regulator to ask.

Would you be willing to share his response here and discuss with us? We might all learn from that.  
> best regards,
> Amelia

Sorry for the iTypos. 

>> Best,
>> a.
>>> /a
>>> On 09/03/15 23:20, Paul Fuxjaeger wrote:
>>>>>> On 03/09/2015, Amelia Andersdotter <teirdes at gmail.com> wrote:
>>>>>> Dear all,
>>>>>> I fail to see how the EU directive hinders anyone from putting in
>>>>>> their own software on a radio device.
>>>>>> Could someone update me? It's being implemented in Sweden with a
>>>>>> deadline for comments in October.
>>>> Article 3, point (i) of [1]:
>>>> "radio equipment supports certain features in order to ENSURE that
>>>> software can only be loaded into the radio equipment where the
>>>> compliance of the combination of the radio equipment and software has
>>>> been demonstrated."
>>>> My current interpretation is that for all devices using SoftMAC radio
>>>> chipsets this necessitates a lockdown of the complete software stack.
>>>> Because on such devices the code that sets the regulatory rules is
>>>> executed in the same context as everything else.
>>>> AFAIK, the majority of APs currently on the market is based on such an
>>>> architecture. Manufacturers have an alternative: switch back to more
>>>> complex (e.g. FullMAC) architectures that allow to lock down the radio
>>>> subsystem separately [2].
>>>> To me this FCC document [3] indicates complete lockdown:
>>>> "ENSURE that only properly authenticated software is loaded and
>>>> operating the device [...] manufacturers may consider applying existing
>>>> industry standards for strong security and authentication. It is
>>>> suggested that manufacturers follow existing security standards and
>>>> definitions: X.800, RFC 2828, and IEEE 802.11i."
>>>> -paul
>>>> [1]
>>>> http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32014L0053&from=EN
>>>> [2] Enforcement of local regulatory differences is still an issue as the
>>>> radio subsystem cannot reliably detect where it is located without the
>>>> help of the host system.
>>>> [3] http://www.heise.de/downloads/18/1/5/7/9/4/3/6/GetAttachment.pdf
>>> _______________________________________________
>>> Office mailing list
>>> Office at openspectrum.eu
>>> http://lists.lo-res.org/cgi-bin/mailman/listinfo/office

More information about the Battlemesh mailing list