Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] security guidelines for home routers
Date: Tue, 27 Nov 2018 12:52:32 +0100	[thread overview]
Message-ID: <611D46EC-4E08-4D66-9163-C200FA2ECA09@gmx.de> (raw)
In-Reply-To: <alpine.DEB.2.20.1811271156340.7766@uplift.swm.pp.se>

Hi Mikael,


> On Nov 27, 2018, at 12:03, Mikael Abrahamsson <swmike@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@swm.pp.se


  reply	other threads:[~2018-11-27 11:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 18:05 Dave Taht
2018-11-26 18:24 ` Sebastian Moeller
2018-11-26 18:35   ` Mikael Abrahamsson
2018-11-26 22:13     ` Sebastian Moeller
2018-11-27 11:03       ` Mikael Abrahamsson
2018-11-27 11:52         ` Sebastian Moeller [this message]
2018-11-27 13:34           ` Mikael Abrahamsson
2018-11-28 13:49             ` Sebastian Moeller
2018-11-27 18:23         ` valdis.kletnieks
2018-11-26 18:40   ` Dave Taht
2018-11-26 21:05     ` Toke Høiland-Jørgensen
2018-11-26 22:28     ` Sebastian Moeller
2018-11-27  0:29       ` David P. Reed
2018-11-27 11:07         ` Mikael Abrahamsson
2018-11-27 11:17           ` Jonathan Morton
2018-11-28  9:17           ` Michael Richardson
2018-11-28  9:14         ` Michael Richardson
2018-11-28 19:10           ` David P. Reed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=611D46EC-4E08-4D66-9163-C200FA2ECA09@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=swmike@swm.pp.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox