Enabling Wi-Fi on First boot

[Michael Richardson]

(combined reply to several emails)

Henrique de Moraes Holschuh <henrique at nic.br> wrote:
    > However, it is *not* a simple matter to just "enable wireless" at first boot
    > in OpenWrt (due to a "default password" issue), except maybe in a
    > home-and-enthusiast setting.  You cannot just do it for a device (or
    > firmware) you're going to deliver to third parties: it is *unsafe*, and
    > extremely strongly discouraged.

I agree with you.  I think is the OP's case, they are delivering something
that is a physical unit, with a specific purpose.

    > 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 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)

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.

    >> 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.

    > 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.

    > 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"

    > The solution for "you ship firmware" could then become "build once, but at
    > download time you append the signed variable data that resists factory-reset,
    > and contains any unit-specific passwords.  You also attach a PDF with the
    > device passwords for the user to print and glue to his unit".

Here is a PDF to print is an interesting solution.

    > [1] The reports are public, and available at https://ceptro.br. Disclaimer: I
    > work for a different division of the same NGO that produced those reports.

Thanks for this pointer... but can you give us the whole URL for those of us
who don't speak Portugese (and google translate doesn't seem to have helped).

    > [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.

Would a (secret) key hash of the MAC address satisfy it?
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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210706/322fe480/attachment.sig>