From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0E6783CB36 for ; Tue, 27 Nov 2018 06:52:37 -0500 (EST) Received: from [172.16.10.187] ([134.76.241.253]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2nfO-1faTfI2VxG-00sdQd; Tue, 27 Nov 2018 12:52:34 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 27 Nov 2018 12:52:32 +0100 Cc: cerowrt-devel Content-Transfer-Encoding: quoted-printable Message-Id: <611D46EC-4E08-4D66-9163-C200FA2ECA09@gmx.de> References: <6F8CDBFF-8B8A-4B6B-BCE9-918A69354626@gmx.de> <05A88D6B-51BC-4CC5-98D9-E85AE11D96AC@gmx.de> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:bwhbB6RYEPJsXlt/XhliRVy6QGCP9Sjj2ddbhFqovZAetq5iRyP h3RqurEAjahfo1iwUN/qkc+w2mbuzchDmVgBsXyxy1avW9pzuYmt2Ve94XUqLUd+75f+w3w lEP7oIpvbvuNMr95dVrZVlcChBCxLan+uTmVw6OC7gG+AQT06jsPL92Q7CPlSLMbDfDtKQc 5fN6cquSUlGraG0Pj4Wzw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CEeU18wtoQc=:Yydfj6ctfN2G7BUyWOwmFu E/ErVpW5+R9NvvDX27f0FCo62PMFNxdXV5lhnOcYP/AMXFhTio58wC8vGKtml1ydnxi4STC+4 APM9vX7pEIqYfGIIDCf/r6hj6JfQKHiSwSWeJGFZcE3VFNPdHk2iHlKz2bPC786NcxOYZu+SS ywAxJLY9GT6B0bw2RKpYWb2nYfInTe+Llq6xSMpqSFESA/SGhJjrjnOGIUj/cP8Uw08QO1aGf 1H4/ipkiM//uLavA5RHrTcpYF+34hZvQNRztnvB0kIP0MVoUqgK1ww1ka9y090U6LyKkIOEjM 3WVmJ+RlW3VpkLpyPvt1mUYSppuGohgBri5TnsL6QRCL643jahMEJHExo0P4VKECWVDEbd2Z9 MKzEmf1EPTUz+gbRsupjTNLkwsjbop7Uo3c5XuDWUomAXJ4rMX7Kwa0uhqZCt/ieHtbRiS6sG PQ0FzoH5HlHb00HujG2K9vLdAitT9KmcB0UOcy8XbQa8efd4JIq+BULGxd7iDpbByWQziQ0aB +PTbkRgadqSklCEIbyTeu7dp+YVistg7RH6lhAo+Yu4vam3aiv55nCHoPAnplyaxYX9qsIXbL FVN4Z9Zja/ZvhOm8xOJhnxDoUCRXbsyXHZD7sw3DTfR+vzSYmeZ98RYw02HZYBhlgWX23bKhT YVYBEXbcxXYYJMiiphbECqaffrBWutu58deDLMjQc3l13kpdWjTB+dxLLJ2AXj71KM2APKpyW YkhfBNxoFjB7j0NrpPWSBUpTn8CEk1wJAgRqNry/190M2wXW8EzFAMUzxcc9+aB16/nq/tAML nK2fGRBwf1YjyjFHYUBKCLV2AgpakNNFFGtegMi2waUVmC7ocBpK9MhQOhx4Y0X/UxPIJv0b2 GTGYx3izWE91PVk4jpWaT0BEum3BwWxVFLyVDXdiXPfk9E0mvM+3le1wRG5jWm Subject: Re: [Cerowrt-devel] security guidelines for home routers X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 11:52:38 -0000 Hi Mikael, > On Nov 27, 2018, at 12:03, Mikael Abrahamsson = wrote: >=20 > On Mon, 26 Nov 2018, Sebastian Moeller wrote: >=20 >> 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. >=20 > 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). >=20 > 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. =46rom 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. >=20 > 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. >=20 > 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). >=20 >> 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. >=20 > 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. >=20 >> 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. >=20 > Agreed. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se