[Cerowrt-devel] security guidelines for home routers

[Cerowrt-devel] security guidelines for home routers

[Dave Taht]

I only briefly scanned this, but I did find some things that made me
happy. Still, What happens after end of life?

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf;jsessionid=01F54E80B004E9BFB194DBC00DE9B961.2_cid360?__blob=publicationFile&v=2

"To be able to react to newly appearing exploits of soft- or hardware
vulnerabilities of the router or any of its components the router MUST
have a functionality to update the firmware (operating system and
applications) using a firmware package. The router MUST allow the
end-user to fully control such a firmware update and determine to
initiate an online update (router retrieves firmware package from the
Internet (WAN interface)) and/ or manually update the firmware through
the configuration interface (user provides firmware package) described
in Section 4.1: Configuration and Information."

The router SHOULD offer an option to automatically retrieve security
relevant firmware updates from a trustworthy source over the Internet
(WAN interface). If the router offers this functionality it SHOULD be
activated by default, but MUST be possible for the end-user to
deactivate it when using customized settings. In both scenarios
(manual and automated update) the firmware update function of the
router MUST check the authenticity of the firmware package (file)
before it is installed on the router. This SHOULD be done by a digital
signature that is applied to the firmware package by the manufacturer
and checked by the router itself. For this purpose only signature
schemes in accordance to [SOG-IS] Section 5.2: Digital Signatures MUST
be used. The router MUST NOT automatically install any unsigned
firmware. The router MAY allow the installation of unsigned firmware
(i.e. custom firmware) IF a meaningful warning message has been shown
to the authenticated end-user and the end-user accepts the
installation of the unsigned firmware.

the manufacturer of the router MUST provide information on how long
firmware updates fixing common vulnerabilities and exposures that have
a high severity (i.e. a CVSS combined score higher than 6.0 according
to the Common Vulnerability Scoring System3 assigned to the specific
device or a component used by the device) will be made available. This
information SHOULD be available on the manufacturer website.
Additionally it MAY be made available on the router configuration
interface described in Section 4.1.2: Providing Information. The
manufacturer MUST provide information if the router has reached the
End of its Support (EoS) and will not receive firmware updates by the
manufacturer anymore. This information (EoS) MUST be made available on
the router configuration as described in Section 4.1.2: Providing
Information. The manufacturer MUST provide firmware updates to fix
common vulnerabilities and exposures of a high severity without
culpable delay (without undue delay) after the manufacturer obtains
knowledge


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] security guidelines for home routers

[Sebastian Moeller]

Hi Dave,


neither the openwrt folks (see https://openwrt.org) nor the chaos computer club of germany (see German: https://www.ccc.de/en/updates/2018/risikorouter, machinenglish: https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=https%3A%2F%2Fwww.ccc.de%2Fen%2Fupdates%2F2018%2Frisikorouter&edit-text=) seem to be fully convinced.
Personally I believe this is a step in the right direction, even though hopefully just a first step. 

Openwrt and CCC mainly critizise:

"The Chaos Computer Club (CCC) and OpenWrt took part in multiple review and discussion rounds with the Bundesamt für Sicherheit in der Informationstechnik (BSI) and representatives of multiple device vendors and network operators. These are our two main demands:

1)  Vendors have to inform customer before buying the product for all devices being sold in Germany, how long the device will get security updates in case problems are found.

2) The customer must have the possibility to install custom software on their devices, to have the possibility to fix security problems even after the official vendor support ended."

I believe that 1) is currently supposed to be posted on a web-site so will not be effortlessly visible at the point of sale in a store.
And 2) basically is a complaint that there is a weak MAY clause for guaranteeing that  3rd party firmware like openwrt is installable. I think this was weakened on purpose by the DOCSIS-ISPs which seem to have zero interest for 3rd party firmwares for cable-modems/routers. (I would not be amazed if cable labs would actually rule something like this out per contract, but I have zero evidence for that hypothesis).




> On Nov 26, 2018, at 19:05, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I only briefly scanned this, but I did find some things that made me
> happy. Still, What happens after end of life?
> 
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf;jsessionid=01F54E80B004E9BFB194DBC00DE9B961.2_cid360?__blob=publicationFile&v=2
> 
> "To be able to react to newly appearing exploits of soft- or hardware
> vulnerabilities of the router or any of its components the router MUST
> have a functionality to update the firmware (operating system and
> applications) using a firmware package. The router MUST allow the
> end-user to fully control such a firmware update and determine to
> initiate an online update (router retrieves firmware package from the
> Internet (WAN interface)) and/ or manually update the firmware through
> the configuration interface (user provides firmware package) described
> in Section 4.1: Configuration and Information."
> 
> The router SHOULD offer an option to automatically retrieve security
> relevant firmware updates from a trustworthy source over the Internet
> (WAN interface). If the router offers this functionality it SHOULD be
> activated by default, but MUST be possible for the end-user to
> deactivate it when using customized settings. In both scenarios
> (manual and automated update) the firmware update function of the
> router MUST check the authenticity of the firmware package (file)
> before it is installed on the router. This SHOULD be done by a digital
> signature that is applied to the firmware package by the manufacturer
> and checked by the router itself. For this purpose only signature
> schemes in accordance to [SOG-IS] Section 5.2: Digital Signatures MUST
> be used. The router MUST NOT automatically install any unsigned
> firmware. The router MAY allow the installation of unsigned firmware
> (i.e. custom firmware) IF a meaningful warning message has been shown
> to the authenticated end-user and the end-user accepts the
> installation of the unsigned firmware.
> 
> the manufacturer of the router MUST provide information on how long
> firmware updates fixing common vulnerabilities and exposures that have
> a high severity (i.e. a CVSS combined score higher than 6.0 according
> to the Common Vulnerability Scoring System3 assigned to the specific
> device or a component used by the device) will be made available. This
> information SHOULD be available on the manufacturer website.
> Additionally it MAY be made available on the router configuration
> interface described in Section 4.1.2: Providing Information. The
> manufacturer MUST provide information if the router has reached the
> End of its Support (EoS) and will not receive firmware updates by the
> manufacturer anymore. This information (EoS) MUST be made available on
> the router configuration as described in Section 4.1.2: Providing
> Information. The manufacturer MUST provide firmware updates to fix
> common vulnerabilities and exposures of a high severity without
> culpable delay (without undue delay) after the manufacturer obtains
> knowledge
> 
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] security guidelines for home routers

[Mikael Abrahamsson]

On Mon, 26 Nov 2018, Sebastian Moeller wrote:

> And 2) basically is a complaint that there is a weak MAY clause for 
> guaranteeing that 3rd party firmware like openwrt is installable. I 
> think this was weakened on purpose by the DOCSIS-ISPs which seem to have 
> zero interest for 3rd party firmwares for cable-modems/routers. (I would 
> not be amazed if cable labs would actually rule something like this out 
> per contract, but I have zero evidence for that hypothesis).

2 is interesting from a security point of view. With secure boot special 
provisions have to be put into the router to turn off secure boot to be 
able to install anything on it. Question is how this would be done in a 
way that is both secure and somewhat user friendly.

2 also implies sharing drivers etc, and it's unclear how this would be 
done. I believe Germany is too small to drive this requirement, we'd need 
at least US or EU size market to really succeed with this.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] security guidelines for home routers

[Sebastian Moeller]

Hi Mikael,


> On Nov 26, 2018, at 19:35, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Mon, 26 Nov 2018, Sebastian Moeller wrote:
> 
>> And 2) basically is a complaint that there is a weak MAY clause for guaranteeing that 3rd party firmware like openwrt is installable. I think this was weakened on purpose by the DOCSIS-ISPs which seem to have zero interest for 3rd party firmwares for cable-modems/routers. (I would not be amazed if cable labs would actually rule something like this out per contract, but I have zero evidence for that hypothesis).
> 
> 2 is interesting from a security point of view. With secure boot special provisions have to be put into the router to turn off secure boot to be able to install anything on it. Question is how this would be done in a way that is both secure and somewhat user friendly.

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. 



> 2 also implies sharing drivers etc, and it's unclear how this would be done.

	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.


> I believe Germany is too small to drive this requirement, we'd need at least US or EU size market to really succeed with this.

	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.




> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] security guidelines for home routers

[Mikael Abrahamsson]

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

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.

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.

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.

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

> 	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

Re: [Cerowrt-devel] security guidelines for home routers

[Sebastian Moeller]

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

Re: [Cerowrt-devel] security guidelines for home routers

[Mikael Abrahamsson]

On Tue, 27 Nov 2018, Sebastian Moeller wrote:

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

DTs Speedports.

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

Again, how do you define "explicit opt-in"? Yes, cutting a wire inside the 
device is probably a good way to do it, if someone doesn't understand this 
is modification of the device then I don't know what is.

> 	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 agree, but it might be exactly what some other people want to own, who 
just want things to work. There are plenty of devices that people pay and 
own, but they expect their ISP to manage and software update.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] security guidelines for home routers

[Sebastian Moeller]

Hi Mikael,



> On Nov 27, 2018, at 14:34, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Tue, 27 Nov 2018, Sebastian Moeller wrote:
> 
>> 	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.
> 
> DTs Speedports.
> 

These do have secure boot? interesting. But it explains the lack of user modifications to these devices. As an alternative example the AVM Fritz! brand devices quite popular in Germany do actual allow to install modded firmwares, but the steps to do so are involved enough to not have anybody do this accidentally.


>> 	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.
> 
> Again, how do you define "explicit opt-in"?

	Well, BSI document proposes simply modal warning dialogs from the GUI as an entry barrier...

> Yes, cutting a wire inside the device is probably a good way to do it, if someone doesn't understand this is modification of the device then I don't know what is.

	Well, the wire thing is probably the weakest part, I guess my proposal was to make this change cause visible irrevocable physical changes to the device. But i guess this is solving a non-existent problem...

> 
>> 	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 agree, but it might be exactly what some other people want to own, who just want things to work. There are plenty of devices that people pay and own, but they expect their ISP to manage and software update.

	And that is fine, but the whole issue under scrutiny here is what happens when the manufacturer/seller EOL's a device, and at that point the only alternative is a forced retirement of hardware that might still be up to the job.

> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] security guidelines for home routers

[valdis.kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Tue, 27 Nov 2018 12:03:35 +0100, Mikael Abrahamsson said:
> 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.

That's a parenting problem not easily solved via technology. In particular, there's
the issue that often, the 12 year old is more clever than the parent - or the person
who designed the parental controls on the device.

On Tue, 27 Nov 2018 13:17:57 +0200, Jonathan Morton said:
> Currently, the easiest way to build a machine that's *truly* secure is to
> take something like a 6502 (which is still being manufactured by WDC) and
> associated 74AHC-series logic chips, SRAMs and EEPROMs, a 4-layer PCBs, all of
> which are built on crude enough technology to be physically examined for
> backdoor devices in an airport-grade X-ray machine if necessary.  Then write
> the necessary software in assembly, which can be translated to machine code (or
> at least verified) by hand if you're truly paranoid, and toggle it in byte by
>byte on the front panel.

> Good luck getting a web browser running on one of those, though.

Couldn't find a browser, but somebody cooked up an ethernet based webserver for a 6502..

https://developers.slashdot.org/story/03/08/16/1226253/a-tcpip-stack-and-web-server-in-basic


[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]

Re: [Cerowrt-devel] security guidelines for home routers

[Dave Taht]

On Mon, Nov 26, 2018 at 10:24 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Hi Dave,
>
>
> neither the openwrt folks (see https://openwrt.org) nor the chaos computer club of germany (see German: https://www.ccc.de/en/updates/2018/risikorouter, machinenglish: https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=https%3A%2F%2Fwww.ccc.de%2Fen%2Fupdates%2F2018%2Frisikorouter&edit-text=) seem to be fully convinced.
> Personally I believe this is a step in the right direction, even though hopefully just a first step.

I would like it very much if my country attempted to get to something
similar as a requirement for FCC certification or import. Stronger
yes, would be nice, but there was
nothing horrible in here that I could see.

It is extremely well written, could probably use a glossary.

>
> Openwrt and CCC mainly critizise:
>
> "The Chaos Computer Club (CCC) and OpenWrt took part in multiple review and discussion rounds with the Bundesamt für Sicherheit in der Informationstechnik (BSI) and representatives of multiple device vendors and network operators. These are our two main demands:
>
> 1)  Vendors have to inform customer before buying the product for all devices being sold in Germany, how long the device will get security updates in case problems are found.

I am reminded of the mandatory warnings on all cig smoking cartons.
Long term, I guess, they've been effective. I seem to be one of the
few left that still smoke, and most of the other smokers I know use
rollies, and don't have to read about what they are doing to
themselves on every pack.

> 2) The customer must have the possibility to install custom software on their devices, to have the possibility to fix security problems even after the official vendor support ended."
>
> I believe that 1) is currently supposed to be posted on a web-site so will not be effortlessly visible at the point of sale in a store.

I would rather like that. With most computer gear today, you are
essentially buying a lease. "Supported for 1 week longer than our 1
year warranty". People should value a long term support plan, as much
as they value getting a 10 year "bumper to bumper" warranty on a car.
Spending 200 bucks on a piece

> And 2) basically is a complaint that there is a weak MAY clause for guaranteeing that  3rd party firmware like openwrt is installable. I think this was weakened on purpose by the DOCSIS-ISPs which seem to have zero interest for 3rd party firmwares for cable-modems/routers. (I would not be amazed if cable labs would actually rule something like this out per contract, but I have zero evidence for that hypothesis).

These are the people that *rent* modems to you at an enormous margin
and are unwilling to support it?

Sigh... I have zip, zero problem, if cable folk *leased* you a modem,
managed it,
and then provided a new one when their support costs got too great. It
would do wonders for the entire industry if they simply gave away new
docsis 3 or 3.1 modems to every one still running an earlier one....

There's a huge difference in "leasing" vs "renting" vs "buying" I guess.

There's a movement here called "right to repair", which is not
something I've been tracking here. How's it going over there? It's
used a lot when arguing with John Deer about their tractors....

>
>
>
> > On Nov 26, 2018, at 19:05, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > I only briefly scanned this, but I did find some things that made me
> > happy. Still, What happens after end of life?
> >
> > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf;jsessionid=01F54E80B004E9BFB194DBC00DE9B961.2_cid360?__blob=publicationFile&v=2
> >
> > "To be able to react to newly appearing exploits of soft- or hardware
> > vulnerabilities of the router or any of its components the router MUST
> > have a functionality to update the firmware (operating system and
> > applications) using a firmware package. The router MUST allow the
> > end-user to fully control such a firmware update and determine to
> > initiate an online update (router retrieves firmware package from the
> > Internet (WAN interface)) and/ or manually update the firmware through
> > the configuration interface (user provides firmware package) described
> > in Section 4.1: Configuration and Information."
> >
> > The router SHOULD offer an option to automatically retrieve security
> > relevant firmware updates from a trustworthy source over the Internet
> > (WAN interface). If the router offers this functionality it SHOULD be
> > activated by default, but MUST be possible for the end-user to
> > deactivate it when using customized settings. In both scenarios
> > (manual and automated update) the firmware update function of the
> > router MUST check the authenticity of the firmware package (file)
> > before it is installed on the router. This SHOULD be done by a digital
> > signature that is applied to the firmware package by the manufacturer
> > and checked by the router itself. For this purpose only signature
> > schemes in accordance to [SOG-IS] Section 5.2: Digital Signatures MUST
> > be used. The router MUST NOT automatically install any unsigned
> > firmware. The router MAY allow the installation of unsigned firmware
> > (i.e. custom firmware) IF a meaningful warning message has been shown
> > to the authenticated end-user and the end-user accepts the
> > installation of the unsigned firmware.
> >
> > the manufacturer of the router MUST provide information on how long
> > firmware updates fixing common vulnerabilities and exposures that have
> > a high severity (i.e. a CVSS combined score higher than 6.0 according
> > to the Common Vulnerability Scoring System3 assigned to the specific
> > device or a component used by the device) will be made available. This
> > information SHOULD be available on the manufacturer website.
> > Additionally it MAY be made available on the router configuration
> > interface described in Section 4.1.2: Providing Information. The
> > manufacturer MUST provide information if the router has reached the
> > End of its Support (EoS) and will not receive firmware updates by the
> > manufacturer anymore. This information (EoS) MUST be made available on
> > the router configuration as described in Section 4.1.2: Providing
> > Information. The manufacturer MUST provide firmware updates to fix
> > common vulnerabilities and exposures of a high severity without
> > culpable delay (without undue delay) after the manufacturer obtains
> > knowledge
> >
> >
> > --
> >
> > Dave Täht
> > CTO, TekLibre, LLC
> > http://www.teklibre.com
> > Tel: 1-831-205-9740
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] security guidelines for home routers

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> Sigh... I have zip, zero problem, if cable folk *leased* you a modem,
> managed it, and then provided a new one when their support costs got
> too great. It would do wonders for the entire industry if they simply
> gave away new docsis 3 or 3.1 modems to every one still running an
> earlier one....

FWIW, this model is roughly what is usually happening in Denmark for DSL
(dunno about cable, but may be similar). I've had multiple occasions
where I've been talking to support about an unrelated issue, and they
noticed I had an ancient router and went "wait, let me send you a new
one". Free of charge, and you just return the old one.

(In all cases the router has just been an expensive DSL model in bridge
mode to my OpenWrt router, but still, nice practice...)

-Toke

Re: [Cerowrt-devel] security guidelines for home routers

[Sebastian Moeller]

Hi Dave,


> On Nov 26, 2018, at 19:40, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Mon, Nov 26, 2018 at 10:24 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Hi Dave,
>> 
>> 
>> neither the openwrt folks (see https://openwrt.org) nor the chaos computer club of germany (see German: https://www.ccc.de/en/updates/2018/risikorouter, machinenglish: https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=https%3A%2F%2Fwww.ccc.de%2Fen%2Fupdates%2F2018%2Frisikorouter&edit-text=) seem to be fully convinced.
>> Personally I believe this is a step in the right direction, even though hopefully just a first step.
> 
> I would like it very much if my country attempted to get to something
> similar as a requirement for FCC certification or import. Stronger
> yes, would be nice, but there was
> nothing horrible in here that I could see.

	+1

> 
> It is extremely well written, could probably use a glossary.

	See table 1 of https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile&v=2 for an attempt at a terse glossary

> 
>> 
>> Openwrt and CCC mainly critizise:
>> 
>> "The Chaos Computer Club (CCC) and OpenWrt took part in multiple review and discussion rounds with the Bundesamt für Sicherheit in der Informationstechnik (BSI) and representatives of multiple device vendors and network operators. These are our two main demands:
>> 
>> 1)  Vendors have to inform customer before buying the product for all devices being sold in Germany, how long the device will get security updates in case problems are found.
> 
> I am reminded of the mandatory warnings on all cig smoking cartons.
> Long term, I guess, they've been effective. I seem to be one of the
> few left that still smoke, and most of the other smokers I know use
> rollies, and don't have to read about what they are doing to
> themselves on every pack.

	I tend to think that "real tobacco aficionados" will sooner or later switch to chewing tobacco ;)


> 
>> 2) The customer must have the possibility to install custom software on their devices, to have the possibility to fix security problems even after the official vendor support ended."
>> 
>> I believe that 1) is currently supposed to be posted on a web-site so will not be effortlessly visible at the point of sale in a store.
> 
> I would rather like that. With most computer gear today, you are
> essentially buying a lease. "Supported for 1 week longer than our 1
> year warranty".

	If at all! Now there are a few good apples in there as well. e.g. AVM typically supports their new router models for several years, publish EOS and EOL notices regularly and even introduce new features to older hardware as part of their firmware upgrades (I believe they partly do this to reduce the version explosion in their testing matrix, but still it is a win-win, for both AVM and customers). Also evenroute seem to do good with their iq-router brand in that regard.

> People should value a long term support plan, as much
> as they value getting a 10 year "bumper to bumper" warranty on a car.
> Spending 200 bucks on a piece
> 
>> And 2) basically is a complaint that there is a weak MAY clause for guaranteeing that  3rd party firmware like openwrt is installable. I think this was weakened on purpose by the DOCSIS-ISPs which seem to have zero interest for 3rd party firmwares for cable-modems/routers. (I would not be amazed if cable labs would actually rule something like this out per contract, but I have zero evidence for that hypothesis).
> 
> These are the people that *rent* modems to you at an enormous margin
> and are unwilling to support it?

	Yes, even worst, the same companies that distributed the latency-jinxed intel puma5/6/7 based docsis modems that had/have rather unfortunate latency spikes and packet drops; and often have not managed to distribute the newer firmware images that severely ameliorate that issue. In that light I understand ccc/openwrt's frustration with the weak custom firmware requirements.


> 
> Sigh... I have zip, zero problem, if cable folk *leased* you a modem,
> managed it,
> and then provided a new one when their support costs got too great. It
> would do wonders for the entire industry if they simply gave away new
> docsis 3 or 3.1 modems to every one still running an earlier one....

	Well, they, as well as most dsl-ISPs in Germany, will happily rent you something, and at least the dsl isp tend to get "timely" firmware updates (at least if conpared with the docsis isps). The sad thing is that in the past these devices were factored into the plans but now are run as profit centers (say 4 EUR for a device that is expected to last for 5 years at a customers home will net you 4*12*5 = 240 EUR for hardware and support).


> 
> There's a huge difference in "leasing" vs "renting" vs "buying" I guess.
> 
> There's a movement here called "right to repair", which is not
> something I've been tracking here. How's it going over there? It's
> used a lot when arguing with John Deer about their tractors....

	It is discussed in the media, and I have (so far unsubstantiated) hopes that the EU-parlament might tackle this somehow, somewhen ;)

> 
>> 
>> 
>> 
>>> On Nov 26, 2018, at 19:05, Dave Taht <dave.taht@gmail.com> wrote:
>>> 
>>> I only briefly scanned this, but I did find some things that made me
>>> happy. Still, What happens after end of life?
>>> 
>>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf;jsessionid=01F54E80B004E9BFB194DBC00DE9B961.2_cid360?__blob=publicationFile&v=2
>>> 
>>> "To be able to react to newly appearing exploits of soft- or hardware
>>> vulnerabilities of the router or any of its components the router MUST
>>> have a functionality to update the firmware (operating system and
>>> applications) using a firmware package. The router MUST allow the
>>> end-user to fully control such a firmware update and determine to
>>> initiate an online update (router retrieves firmware package from the
>>> Internet (WAN interface)) and/ or manually update the firmware through
>>> the configuration interface (user provides firmware package) described
>>> in Section 4.1: Configuration and Information."
>>> 
>>> The router SHOULD offer an option to automatically retrieve security
>>> relevant firmware updates from a trustworthy source over the Internet
>>> (WAN interface). If the router offers this functionality it SHOULD be
>>> activated by default, but MUST be possible for the end-user to
>>> deactivate it when using customized settings. In both scenarios
>>> (manual and automated update) the firmware update function of the
>>> router MUST check the authenticity of the firmware package (file)
>>> before it is installed on the router. This SHOULD be done by a digital
>>> signature that is applied to the firmware package by the manufacturer
>>> and checked by the router itself. For this purpose only signature
>>> schemes in accordance to [SOG-IS] Section 5.2: Digital Signatures MUST
>>> be used. The router MUST NOT automatically install any unsigned
>>> firmware. The router MAY allow the installation of unsigned firmware
>>> (i.e. custom firmware) IF a meaningful warning message has been shown
>>> to the authenticated end-user and the end-user accepts the
>>> installation of the unsigned firmware.
>>> 
>>> the manufacturer of the router MUST provide information on how long
>>> firmware updates fixing common vulnerabilities and exposures that have
>>> a high severity (i.e. a CVSS combined score higher than 6.0 according
>>> to the Common Vulnerability Scoring System3 assigned to the specific
>>> device or a component used by the device) will be made available. This
>>> information SHOULD be available on the manufacturer website.
>>> Additionally it MAY be made available on the router configuration
>>> interface described in Section 4.1.2: Providing Information. The
>>> manufacturer MUST provide information if the router has reached the
>>> End of its Support (EoS) and will not receive firmware updates by the
>>> manufacturer anymore. This information (EoS) MUST be made available on
>>> the router configuration as described in Section 4.1.2: Providing
>>> Information. The manufacturer MUST provide firmware updates to fix
>>> common vulnerabilities and exposures of a high severity without
>>> culpable delay (without undue delay) after the manufacturer obtains
>>> knowledge
>>> 
>>> 
>>> --
>>> 
>>> Dave Täht
>>> CTO, TekLibre, LLC
>>> http://www.teklibre.com
>>> Tel: 1-831-205-9740
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740

Re: [Cerowrt-devel] security guidelines for home routers

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]


> I would like it very much if my country attempted to get to something> similar as a requirement for FCC certification or import. Stronger> yes, would be nice, but there was> nothing horrible in here that I could see.
 
Dave T. - You may remember from when I helped get you in contact with the FCC regarding their attempt to rule against software updates of routers. Subsequent to that, I and others were brought into an ex parte discussion with the top policy people in the FCC regarding their role in supporting security reviews of routers and development of secure routers for WiFi. The FCC lawyers have asserted that they have no legal authority whatsoever in regard to assuring security of routers.
 
They haven't been interested in communications security at all, in all of my work with them over the last 20 years. Personally, I don't see Congress passing laws on router security, or for that matter, "Internet of Things" security. There is some thought that the Federal Trade Commission might have authority under "consumer protection" and "product safety" laws. But FTC is generally weak and uninterested in regulating most technologies.
 
One of the US's problems (which may have parallels in Europe) is that ALL responsibility for communications security in the USG resides in the NSA, which is in the Department of Defense. Every other part of the USG depends on NSA support. (Even the Federal Information Processing Standards for commercial encryption are vetted officially by NSA, because they are the only agency that has security competencies)
 
Is it a good thing to bring NSA into regulating the security of home routers or IoT? Technically, they and their contractors are very sharp on this. I've worked with them since I began work in computer security in my research group at MIT in 1973. (we did no classified research, but NSA was part of our support, and the chief scientist of the NSA shared an office with me when he visited us).
 
Personally, I think it's time to move "security" out of the military sector of government..
 
But maybe not in the FCC, which is in a weird part of the USG, with no budget for technical expertise at all. (Congress doesn't want them to have technical resources)
 
 

[-- Attachment #2: Type: text/html, Size: 7017 bytes --]

Re: [Cerowrt-devel] security guidelines for home routers

[Mikael Abrahamsson]

On Mon, 26 Nov 2018, David P. Reed wrote:

> Personally, I think it's time to move "security" out of the military 
> sector of government..

I think we need some kind of international cooperation body that develops 
guidelines that vendors can then slap their "approved by"-sticker on the 
box by complying to these guidelines. Problem here is that 99% of the 
population do not care about this, they just want to get their network 
running. That's why apple succeeds with their products, because they sell 
a "this is secure and works"-product, even if this security means you have 
to go to an authorized apple store to get your components replaced 
(because they're cryptographically paired for security reasons). It's 
possibly also that for most of Apples customers, this level of security is 
too high. People would rather have their pictures unencrypted and 
extractable without password from the device, compared to them being lost 
because the device was damanged otherwise broken.

So we need to come up with a security regime that makes sense for the most 
amount of people, and then try to still cater to the ones who want to do 
more/less.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] security guidelines for home routers

[Jonathan Morton]

> On 27 Nov, 2018, at 1:07 pm, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> So we need to come up with a security regime that makes sense for the most amount of people, and then try to still cater to the ones who want to do more/less.

For most people, I think the "floppy disk" security model is usually appropriate - you can take your data out of your computer and put it in your pocket, where nobody can read it without physically stealing it from you first.  Unfortunately it's hard to apply using modern technology and paradigms, which try to move your data out of your house entirely, for "convenience" (and to trawl through it for great profitssss).

This is also, for example, why IoT devices and voting machines built using modern technology are perpetually insecure and unsecurable.

Currently, the easiest way to build a machine that's *truly* secure is to take something like a 6502 (which is still being manufactured by WDC) and associated 74AHC-series logic chips, SRAMs and EEPROMs, a 4-layer PCBs, all of which are built on crude enough technology to be physically examined for backdoor devices in an airport-grade X-ray machine if necessary.  Then write the necessary software in assembly, which can be translated to machine code (or at least verified) by hand if you're truly paranoid, and toggle it in byte by byte on the front panel.

Good luck getting a web browser running on one of those, though.

 - Jonathan Morton

Re: [Cerowrt-devel] security guidelines for home routers

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]


Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    >> Personally, I think it's time to move "security" out of the military
    >> sector of government..

    > I think we need some kind of international cooperation body that
    > develops guidelines that vendors can then slap their "approved
    > by"-sticker on the box by complying to these guidelines. Problem here

There are multiple efforts:

I'm involved with this one: https://www.iotsecurityfoundation.org/best-practice-guidelines/
(and there are more documents in progress)

There are other efforts, and there are attempts to coordinate, and there is
interest in the testing labs (EULabs, UL, and others) in doing evaluations
with prices from $ to $$$$$.

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Cerowrt-devel] security guidelines for home routers

[Michael Richardson]

David P. Reed <dpreed@deepplum.com> wrote:
    > Personally, I think it's time to move "security" out of the military
    > sector of government..

+1

    > But maybe not in the FCC, which is in a weird part of the USG, with no
    > budget for technical expertise at all. (Congress doesn't want them to
    > have technical resources)

So where would it go, if not the FTC?

Re: [Cerowrt-devel] security guidelines for home routers

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]


Michael Richardson asked: "So where would it go, if not the FTC?"
 
I think Congress has to create a function in some organization that has technical and policy capabilities, and the powers to regulate manufacturers.
 
It could be in the Dept. of Commerce, but it needs things the FTC doesn't have. I know NIST (also in Commerce) has a number of initiatives in non-military security, but not privacy or individual rights. They have the technical capabilities in house, and define standards where appropriate. But NIST doesn't do policy nor have any power to regulate.
 
Much like the FDA has powers to regulate medical device makers and sellers, because there are important public goods in medical treatment, I think it might be time to begin dealing with *essential* devices like routers in an appropriate way. Doing so while retaining low cost and maximizing innovation is hard, but it need not be done the same way as the regulation of medical devices are regulated (in fact medical device regulations should probably be rethought after 100 years of progress in technology and medicine).
 
<rant>
FYI: This whole idea, which seems necessary, makes part of me personally uncomfortable. I don't trust Congress to get it right, given the huge amount of money available to drive them in the wrong direction. FB and Google have run extremely successful propaganda campaigns to convince America that they "serve their users" and it is too hard to do the right thing, so we should admire their tiny amount of concern about their own bad behavior.  But the real truth is that they "serve their users to their customers on a platter", where their customers are not their users at all, but a vast advertising and data-brokerage system that lives to maximize surveillance of of every behavior of every human on the planet, and then to find new exploits that can "monetize" the observed behavior.
 
We didn't build the Internet protocols to enable mass surveillance by anybody. We built it for simplifying communications among willing participants. But the latter good is lost, as the Pied Piper solved our communications concerns using the Internet, and then demanded control of our children.
</rant>
 
-----Original Message-----
From: "Michael Richardson" <mcr@sandelman.ca>
Sent: Wednesday, November 28, 2018 4:14am
To: "David P. Reed" <dpreed@deepplum.com>
Cc: "Sebastian Moeller" <moeller0@gmx.de>, "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] security guidelines for home routers



David P. Reed <dpreed@deepplum.com> wrote:
 > Personally, I think it's time to move "security" out of the military
 > sector of government..

+1

 > But maybe not in the FCC, which is in a weird part of the USG, with no
 > budget for technical expertise at all. (Congress doesn't want them to
 > have technical resources)

So where would it go, if not the FTC?


[-- Attachment #2: Type: text/html, Size: 4725 bytes --]