On 06/07/2021 13:05, Michael Richardson wrote:
Henrique de Moraes Holschuh <henri...@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 <codemarau...@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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
