[Cerowrt-devel] security guidelines for home routers
Sebastian Moeller
moeller0 at gmx.de
Tue Nov 27 06:52:32 EST 2018
Hi Mikael,
> On Nov 27, 2018, at 12:03, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>
> On Mon, 26 Nov 2018, Sebastian Moeller wrote:
>
>> I guess that most cheap routers do not actually do "secure boot" but rather make it hard to flash not-approved firmware binaries from the GUI, and for the intents an purposes of the BSI document that level of security, in spite of the talk about firmware authentication by digital signatures, seems sufficient. So no need to secure the JTAG interface, or even a tftp update method that can be initiated by pressing a button on the router or similar.
>
> There are a huge amount of routers in peoples homes in Germany that have secure boot enabled.
Really, which ones? I would like to know so I can avoid them ;) Just joking, but I have never heard of secure booting in the context of MIPS based routers and at least in the retail market most cheap devices still seem MIPS based. Then again this is slowly changing with x86 (via DOCSIS-SoCs and even the high end lantiq/intel dsl SoCs) and ARM slowly seeping into the market. I think bot x86 and ARM have specs for secure booting or related methods.
> Trying to achieve the requirement that these can have any software installed on them requires new functionality to be created, perhaps even new administration to handle this in a secure way.
A physical switch to disable the secure boot restrictions, maybe involving breaking away latch or something that will remove a wire to tell the firmware to not check anymore and at the same time signal to the outside that the device is not pristine anymore and has been tempered with (albeit hopefully on purpose by the owner).
>
> Yes, it might be enough to in the future create a button inside the device (so it actually has to be opened up) to disable secure boot, but this still does open up for tampering by someone who happens to have physical access to the device.
I am old school, once somebody has physical access to the device it is game over already. Point in case people have found ways to decrypt the encrypted configuration files huawei tends to use in their routers, and some people even hacked docsis-modems. From my reading of the BSI recommendations, even pressing a reset button long enough would be okay, the only nono seems to be allowing changing the firmware to non-signed ones without explicit opt-in by the user.
>
> Right now with secure boot on and all code being signed, it's really hard to tamper with the device and making it do things it wasn't designed to do.
But that is okay for a device that an ISP owns and rents out, but decidedly not okay for a device I want to own.
>
> I'd really like to see a wider audience weigh in on the pro:s and con:s of this approach. Do parents really want to come home to their 12 year old who might have opened up their residential gateway and installed something the 12 year old downloaded from the Internet? Perhaps yes, perhaps no.
I believe Bruce Schneier calls this movie-plot threat scenarios. But that is relatively easy to foil, just keep the router locked away. And locking thing away, keeping things out of reach of those not (yet) ready to deal with them is something all parents know how to do (think aggressive household chemicals like detergents and bleach).
>
>> Why? In my reading 2 basically just turns the "The router MAY allow the installation of unsigned firmware (i.e. custom firmware)" into a "The router MUST allow " it does not rule that the manufacturer needs to actively help to develop said custom firmware IMHO. Now it would be a great idea to do so, but certainly not required.
>
> Ok, I just took for granted that to make the idea practical, one would need access to hw / sw specifications.
Well, yes that would be nice, but as far as I can see neither the ccc nor the openwrt developers actually demand that much.
>
>> Yes, I agree, this is one of the issues where one of the heavy-weights needs to get involved. My bet is on the EU picking something like this up first though. ATM I do not see much appetite for such regulatory actions in the US.
>
> Agreed.
>
> --
> Mikael Abrahamsson email: swmike at swm.pp.se
More information about the Cerowrt-devel
mailing list