FCC reported to be trying to prevent 3rd party WiFi device firmware upgrades

[Rob Seastrom]

Fifteen years ago give or take, there was a big kerfluffle about DeCSS
and DVD ripping.  Today's code signing algorithms may be stronger than
content scramble system, systems today often have TPMs built in... but
keys that can generate "signed" binaries will be leaked, tribal
knowledge will accumulate about which rev levels of which devices are
"the good ones to have", and eventually we're back to the ecosystem of
today, but with the added complicating dimension of crypto.

In short, the Internet routes around damage.  If the FCC cares to
waste their cycles and taxpayer dollars here, it won't work out well
for them.

-r


Martin <dcmk1mr2 at gmail.com> writes:

> This extends beyond WiFi routers - it's anything with a Part 15 Certification.  Phones with WiFi, IOT, ...
>
>
>
> The FCC seems to be suggesting that manufacturers use a bootloader that looks for signed binaries. Â Â 
>
>
>
> The comment deadline has been extended to Oct
> 9. [[https://www.federalregister.gov/articles/2015/09/01/2015-21634/extension-of-time-for-comments-on-equipment-authorization]]
>
>
>
> Martin W6MRR
>
>
>
> On Thu, Sep 3, 2015 at 8:18 AM, Artie Lekstutis <[[Artie at lekstutis.com]]> wrote:
>
>           Has anyone else heard of this? Is this accurate? Bad news if it is. This would probably
>      exclude the use of Broadband-Hamnet (and DD-WRT).
>      
>      This is the Hackaday article that first brought my attention to this. Their stuff can be a bit
>      fringe, especially their opinions, but is usually somewhat accurate:
>      [[http://hackaday.com/2015/09/02/save-wifi-act-now-to-save-wifi-from-the-fcc/]]
>      
>      Hereâ(TM)s a direct link to the FCC website that specifically identifies DD-WRT as an example of
>      needing to be excluded from all firmware updates for future regulatory compliance:
>      [[https://apps.fcc.gov/kdb/GetAttachment.html?id=1UiSJRK869RsyQddPi5hpw%3D%3D&desc=594280%20D02%20U-NII%20Device%20Security%20v01r02&tracking_number=39498]]
>      
>      Except that it is conveniently unavailable now until the end of the comment period while âoethe
>      FCC IT Team will be working to upgrade and modernize the FCCâ(TM)s legacy infrastructureâY\... I
>      was able to read it yesterday. Luckily I have a cached copy. I'm reluctant to distribute it even
>      though it's an FCC document that was published publicly. If you can find a copy, see
>      âoeII. SOFTWARE SECURITY DESCRIPTION GUIDE: Third-Party Access Control: 2âY\...
>      
>      If what they are saying is true- this will exclude many very useful projects from being flashed on
>      future commercial hardware of any type. This would include DD-WRT, OpenWrt, SECN,
>      Broadband-Hamnet, HSMM-MESH, etcâ¦
>      
>      This in fact degrades security as it means you are now entirely dependent on the WiFi device
>      manufacturer patching vulnerabilities, which they often donâ(TM)t do or do very slowly, especially
>      on older hardware. Options like DD-WRT usually address such vulnerabilities very quickly, if they
>      ever had them in the first place.
>      
>      I havenâ(TM)t made a public comment yet. Still trying to understand the details.
>      [[https://www.federalregister.gov/articles/2015/08/06/2015-18402/equipment-authorization-and-electronic-labeling-for-wireless-devices]]
>      
>      Thanks,
>      Artie Lekstutis
>      KC2MFS
>      73
>      _______________________________________________
>      Tacos mailing list
>      [[Tacos at amrad.org]]
>      [[https://lists.amrad.org/mailman/listinfo/tacos]]
>      
>
>
>
> _______________________________________________
> Tacos mailing list
> Tacos at amrad.org
> https://lists.amrad.org/mailman/listinfo/tacos