[FCC] Worldwide Threat

Daniel Golle daniel at makrotopia.org
Tue Sep 1 06:35:35 PDT 2015


On Tue, Sep 01, 2015 at 02:01:34PM +0200, Imre Kaloz wrote:
> On Tue, 01 Sep 2015 04:11:03 +0200, Christopher Waid
> <chris at thinkpenguin.com> wrote:
> 
> <snip>
> 
> >An acceptable solution I think would involve the radio settings being held
> >in a read-only factory set portion of the device or otherwise controlled
> >by hardware circuits only.
> 
> And when the FCC changes in mind, increasing/decreasing channels, tx power
> limits, you end up with a non-compliant device or a device that restricts
> you. Given we do want free drivers people can modify, the solution has to be
> implemented on the radio's side.
> 
> Manufacturers can still store the calibration data on the flash chip, but it
> has to be signed. The key to verify that signature should be stored _in_ the
> CPU (trustzone/embedded OTP eeprom). The radio's firmware should read this
> key and verify the calibration data -> problem solved.

That's true for FullMAC or uC-supported SoftMAC radios which include a
built-in micro-controller running it's own firmware. On chips like
ath9k or rt2x00 there is no such firmware and it's really the driver
running on the host CPU being in control of registers directly
affecting RF properties such as frequencies or transmit power.
I strongly assume at least certain chipset makers were very aware and
most likely even in favour of the upcoming changes to regulations as
they do result in significant changes to the markets they are catering
to. I know at least one chipset vendor recently making the switch to
include a radio-embedded-uC while all their previous chips were SoftMAC
designs.
In fact, most chip-makers seem to be well-prepared -- however, some
rely on rather tiny uC and firmware, others use yet another full-blown
embedded Linux for that as well.
Thus, for some designs (SoftMACs and embedded-Linux iNICs) the problem
is harder to solve as they will then need a way to prevent the user
from altering the driver running inside a Linux environment. Imho it's
not unlikely that most vendors will opt to have the whole firmware
signed and either verify that signature within the boot-loader or at
least somehow guard and lock-down access to the bootloader as well as
the firmware-upgrade process.
Similar to other embedded Linux devices, users wanting to alter *any*
part of the firmware will then have to count on the firmware vendor to
provide some sort of unlocking procedure or find usable exploits or
planted backdoors in the stock firmware (ie. having to 'jail-break' the
device before being free to run what ever software on it).
This definitely gives more control over after-market life-time to
vendors, which can result in physically fine devices being rendered
into useless bricks e.g. if a vendor goes bankrupt or decides that the
support life-time of a product has ended.
Imagine for example security weaknesses of wireless encryption methods
being disclosed in future, let's say a year or two after a device was
sold: How would the user of a device be able to upgrade
hostapd/wpa_supplicant or an affected shared library?
As it's device owners being responsible for the risks of running these
general purpose computers, they also need to be able react to security
issues and should not depend on the device manufacturer for that, as
the manufacturer might not be bothered or no longer exist.
I stop here and recommend everyone to watch Cory Doctorow's talk
'The coming war on general computation' held on 28c3 in 2011,
which imho is very relevant in this context...

https://events.ccc.de/congress/2011/Fahrplan/events/4848.en.html
https://www.youtube.com/watch?v=HUEvRyemKSg
HQ download: http://bit.ly/sTTFyt



Cheers


Daniel


More information about the FCC mailing list