Enabling Wi-Fi on First boot

Fri Jul 9 17:01:12 PDT 2021

On 06/07/2021 13:05, Michael Richardson wrote:
> Henrique de Moraes Holschuh <henrique at nic.br> wrote:
>      > So, to safely and responsibly enable wireless by default in a device (or
>      > firmware) you're delivering to a third-party, you need that "per-unit unique
>      > wireless password" per device thing most vendors are doing.
> 
>      > Now, unique per-device passwords are "easy" [2] to do if you're delivering
>      > whole devices, as you can just print a label with the device's unique
>      > password and attach to it or to its documentation.
> 
> My training session from 2020:  https://www.iotsecurityfoundation.org/consumer-iot/
>                           https://www.youtube.com/watch?v=I-wHZ64T-Ps

It is mandatory in Brazil for new devices.  This is a somewhat recent 
change here.

Default passwords for wireless are not allowed anymore, they must be 
unique per device, *AND* our standards specifically say you are not to 
use anything derived from the MAC address or other network-visible 
information.

>      > It is far less easy when you're delivering just the firmware (openwrt-based),
>      > which the third-party/user will install by herself.  At least for generic
>      > devices in the general case.
> 
> This problem also presents itself for generating HTTPS certificates (which
> we've discussed at length on this list), and it's particularly acute when
> attempting to ship Virtual Machine Appliances!
> (Somehow, cloud-init can help, but I haven't figured out how yet)

Security-aside, cloud-init-like solutions (like TR-069, etc) depend on 
"WAN" always working without initial configuration, as well as the 
entire trust path required to connect to the "metadata server" never 
getting bitrotted / changed away until all units in the field have been 
updated to whatever needed to be changed.

And when you look at security (which you *must*), it is all needles and 
lava, and pitfalls.  You first need to solve the problem of setting the 
system clock with a *trusted* value to even have HTTPS and DNSSEC 
working (not to mention working *correctly*, so just setting it close 
enough for the PKI certificates to not be invalid isn't enough unless a 
domain-expert signed on it!), etc.

You can always try to bite the bullet: get the clock ipdate in an 
insecure way from a *as local as possible* server at a known IP address, 
and then proceed with 1st boot configuration (which had better be signed 
with a key you will actually manage to protect, or you're toast).

> IoTSF's ManySecured WG, at https://manysecured.net/ is trying to figure this
> part out, and I think we'll shortly have a more open (less IoTSF member-only)
> ML for discussion.  We'd very much like openwrt people involved.

Sounds interesting :-)  Hopefully core openwrt developers will join.

>      >> This would allow us to relax the security settings for the moment being,
>      >> and discuss and plan them later on. It seems to me there is the general
>      >> desire for having such a feature.
> 
>      > I would very much like to have a config option that allows one to implement
>      > what I described in [2] below -- or something else that could be likewise
>      > used.  Basically, a way to append to an already-finished sysupgrade/factory
>      > file some signed configuration data that will resist factory-reset, so that
>      > it is easy/fast to do so at download time without the need to run the image
>      > builder.
> 
> I also think that this would be a good idea.
> I think that really, it belongs in the eeprom or in a custom partition that
> acts in a similiar way.  The problem is that one also needs a "really really"
> factory-reset mode, which *does* erase this data and really goes back to
> default.

That is easy enough to implement -- just require a hundred-second reset 
button press or something like that.

However, because there can be no "default" that requires a static 
hardcoded default password, not even one that is a 
realy-really-factory-reset (do it and you're likely afoul of the 
regulations), you actually need the device to either self-heal somehow 
*safely*, or lock itself down until it receives a firmware-trusted 
signed credentials package.

Maybe you could have it go into the current openwrt scheme, but a bit 
more locked down.  It depends on the requirements.  Here in Brazil, 
you'd *at the very least* need to get the unit into a "clearly unusable 
state meant to facilitate technician repair only" that cannot expose the 
user to local/remote exploitation -- and you'd better clear this with 
your lawyers, because that might not be enough.  No idea about the EU or US.

But most likely you'd want to add a "factory provisioning mode" which 
would be what is the "really-really-factory-reset" thing: it would be 
far more useful.  As an example: down WAN and wireless, up LAN in DHCP 
mode, firewall for TTL=255 at ethernet frame level, listen only for the 
provisioning protocol (say: signed blob containing the preset data you'd 
write to FLASH, over pure TCP, in some specific port.  Can be done using 
usign + shell + busybox netcat, or small C or Lua).  On any error, 
shutdown and require a power cycle to restart.  While in this mode, the 
device won't forward packets nor enable radios, and the hardcoded secret 
it will use to verify the provisioning information is the public half of 
a crypto key pair, which is likely to be regulation-compatible as long 
as it is only active in this "factory provisioning mode".

Blink leds appropriately for ease of documentation in the user manual, 
in any case ;-)

You might also want to enter this factory provisioning mode on 1st boot 
should it detect that there is no valid preset configuration in FLASH 
(this should be a Kconfig choice).  And you'd likely want to use that 
mode to set the router preset at the "factory", obviously, so that it is 
both cost-effective for development *and* it won't bitrot and fail when 
you really need it.

If an user does that realy-realy-factory-reset, they have to ask for 
help from the ISP/vendor, as they won't have the factory provisioning 
key -- unless it is a self-built firmware.  Or they can do the TFTP 
dance to replace the firmware entirely, or enter openwrt failsafe mode 
if you left that enabled in the firmware.

Variations of that would work just as well, IMHO, and there are many.

>      > Around here, the ISPs call this kind of variable data that resists a
>      > factory-reset "preseed configuration".  Apparently, your typical home user
>      > will factory-reset the device every time anything goes wrong, once they know
>      > how to do it.
> 
> AFAIK, the preseed configuration usually nukes all their per-customer
> settings, but retains the TR69 login info, which lets the device retrieve
> it's customer-specific configuration from the ISP.  OpenWRT doesn't have a
> TR69 implementation merged (yet?!), and TR369 is out, and I know that several
> people are working on that.

Yeah, that might work, but it is less generally useful.  For one, you 
need to be very close to the device on the WAN side for it to be safe 
for provisioning.

>      > So it is extremely important that the factory-reset settings
>      > match whatever is needed for ISP connectivity and local wireless to work.
>      > Easy to do if you're the router vendor and have a mtd partition set aside for
>      > it, a lot more difficult otherwise.
> 
>      > Then, you could at least easily address the "you're shipping the device with
>      > the label attached" case: you can do that right now using custom code on
>      > specific devices you know of a partition you can reuse like that, etc.  But a
>      > "generic device" solution is still missing.
> 
> I suggest that we should focus initially on the "I ship a device" situation.
> I think that the generic-device situation will have to sort itself out via
> help from hardware manufacturers: This is often already here, for instance,
> Turris has a keypair in the eeprom generated at the "factory"

Unless there's regulation, it will never sort itself for the "generic" 
class, we don't even have that for bootloader config :-(

I'd prefer a way to do it in any openwrt-supported device, but allowing 
for the usual "when you can do better, do it" that is often possible for 
specific models, etc.

>      > [2] not really: openwrt sysugrade *does not help* in that there is no way to
>      > add variable information to an already *finished* image file, to be used on
>      > first-boot only, and which would *survive a factory reset*.
> 
> Nishant Sharma <codemarauder at gmail.com> wrote:
>      >> So, to safely and responsibly enable wireless by default in a device (or
>      >> firmware) you're delivering to a third-party, you need that "per-unit
>      >> unique wireless password" per device thing most vendors are doing.
>      >>
>      >> [2] not really: openwrt sysugrade *does not help* in that there is no
>      >> way to add variable information to an already *finished* image file, to
>      >> be used on first-boot only, and which would *survive a factory reset*.
>      >>
> 
>      > How about a first-boot script that enables the Wi-Fi if it is disabled
>      > and then sets the password (if not already set) using the first MAC
>      > address it finds on the device?
> 
> The MAC address is considered public information.
> This process will not satisfy the UK and US regulations on it's own.

The Brazilian one is actually based on this:
https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1.pdf

No derivation of secret material from the MAC address or other 
network-exposed information, period.  The M3-AAWG document is not very 
fond of the no-password access through LAN cable, either.

> Would a (secret) key hash of the MAC address satisfy it?

Maybe, regulations are hard.  We use non-network-exposed variable 
information instead here when really-random-injected-per-unit is not 
possible.

But a FLASH area that has the factory-config is better, and failing 
that, a "sysupgrade-protected" 
signed-data-appended-to-the-sysupgrade-and-factory-image solution.

> The UK https://www.ncsc.gov.uk/ people I spoke with said that it would
> technically satisfy
>    https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf
> but not the spirit of it.  And that this was a compromise position when
> preparing EN303645.
> 
> And, in a source-code available system, we really have no way to keep the
> secret we'd need... secret.

Exactly.

-- 
Henrique de Moraes Holschuh
www.nic.br