[Battlemesh] [Office] FCC Firmware lockdown

[Paul Gardner-Stephen]

Hello,

Is someone adding these arguments to the wiki?

I apologise that I am totally swamped at the moment, and cannot easily find
the time to do so, if I am to also contribute to the text of the submission
(which I want to do).

Paul.

On Sat, Sep 5, 2015 at 1:38 AM, L. Aaron Kaplan <aaron at lo-res.org> 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...
>
> > 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 :)
>
>
> > 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?
>
> > 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?
>
> 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
>
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20150905/a84f743d/attachment.htm>