ETSI TS 103 848 V1.1.1 (2022-03)

TECHNICAL SPECIFICATION
Cyber Security for Home Gateways;
Security Requirements
as vertical from Consumer Internet of Things

2 ETSI TS 103 848 V1.1.1 (2022-03)

Reference
DTS/CYBER-0069
Keywords
cybersecurity, Home Gateway, IoT, privacy

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
warranty is made of merchantability or fitness
and/or governmental rule and/or regulation and further, no representation or
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI TS 103 848 V1.1.1 (2022-03)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Methodology and general requirements . 8
4.1 Introduction . 8
4.2 Handling of provisions . 8
4.3 Naming conventions . 9
4.4 Reporting implementation . 9
5 Adapted cyber security provisions for the HG . 10
5.1 No universal default passwords . 10
5.2 Implement a means to manage reports of vulnerabilities . 10
5.3 Keep software updated . 11
5.4 Securely store sensitive security parameters . 12
5.5 Communicate securely . 12
5.6 Minimize exposed attack surfaces . 12
5.7 Ensure software integrity . 13
5.8 Ensure that personal data is secure . 13
5.9 Make systems resilient to outages . 14
5.10 Examine system telemetry data . 14
5.11 Make it easy for users to delete user data . 14
5.12 Make installation and maintenance of devices easy . 14
5.13 Validate input data. 14
6 Adapted data protection provisions for HGs . 14
7 Additional cybersecurity provisions for HGs . 15
7.1 No universal default passwords . 15
7.2 Implement a means to manage reports of vulnerabilities . 15
7.3 Keep software updated . 15
7.4 Securely store sensitive security parameters . 16
7.5 Communicate securely . 17
7.6 Minimize exposed attack surfaces . 18
7.7 Ensure software integrity . 18
7.8 Ensure that personal data is secure . 18
7.9 Make system resilient to outages . 18
7.10 Collecting log data. 19
7.11 Make it easy for users to delete user data . 19
7.12 Make installation and maintenance of devices easy . 19
7.13 Validate input data. 19
Annex A (informative): Basic concepts and models . 20
Annex B (informative): Implementation conformance statement pro forma . 21
History . 25

ETSI
4 ETSI TS 103 848 V1.1.1 (2022-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Cyber Security (CYBER).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
5 ETSI TS 103 848 V1.1.1 (2022-03)
1 Scope
The present document defines security provisions for Home Gateways resulting from the analysis presented in ETSI
TR 103 743 [i.1], and extending from the provisions for consumer IoT devices defined in ETSI EN 303 645 [1].
NOTE 1: The Home Gateway (HG) is not an IoT device as defined in ETSI EN 303 645 [1]. However, due to its
generic character, ETSI EN 303 645 [1] is appropriate as baseline for the HG. The present document
therefore is an adaption of the provisions of ETSI EN 303 645 [1] for the specific capabilities of a HG.
EXAMPLE: The HG is responsible for network management and is therefore subject to higher requirements
than a consumer IoT device concerning the role of an administrator having a higher level of
privilege than a user.
NOTE 2: The adoption of ETSI EN 303 645 [1] as a baseline does not infer that a Home Gateway (HG) is an IoT
device according to the ETSI EN 303 645 [1] definition.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 303 645: "CYBER; Cyber Security for Consumer Internet of Things: Baseline
Requirements".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 743: "CYBER; Home Gateway Security Threat Analysis".
[i.2] Wi-Fi Easy Connect™.
NOTE: Available at https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect.
[i.3] NIST SP 800-90B: "Recommendation for the Entropy Sources Used for Random Bit Generation".
ETSI
6 ETSI TS 103 848 V1.1.1 (2022-03)
[i.4] IEEE 802.11™-2020: "IEEE Standard for Information Technology--Telecommunications and
Information Exchange between Systems - Local and Metropolitan Area Networks--Specific
Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
NOTE: The above reference supersedes IEEE 802.11i™ and incorporates the latest security mechanisms as
originally found in IEEE 802.11i™.
[i.5] ETSI TR 103 309: "CYBER; Secure by Default - platform security technology".
[i.6] ETSI TR 103 305-2: "CYBER; Critical Security Controls for Effective Cyber Defence; Part 2:
Measurement and auditing".
[i.7] ETSI TS 102 165-1: "CYBER; Methods and protocols; Part 1: Method and pro forma for Threat,
Vulnerability, Risk Analysis (TVRA)".
[i.8] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
NOTE: Earlier versions of TLS still apply.
[i.9] Broadband Forum Technical Report 069 (TR-069): "CPE WAN Management Protocol (CWMP)".
[i.10] IETF RFC 5905: "Network Time Protocol Version 4: Protocol and Algorithms Specification".
[i.11] ISO/IEC 14882:2020(E): "Programming Language C++".
[i.12] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 303 645 [1], ETSI TR 103 743 [i.1] and the
following apply:
community Wi-Fi®: Wi-Fi® channel made available from the HG independently of the user and guest provisions to
allow public access to the Internet
Hardware-Based Root of Trust (HBRT): hardware component that provides a tamper-proof unique per device
identity and can perform cryptographic functions in an isolated environment
EXAMPLE 1: A hardware-based Trusted Platform Module (TPM) can be used as a hardware-based root of trust.
Home Gateway (HG): physical device that lies between the in-home network and the public network with a primary
purpose of managing traffic between these networks
IPsec tunnel: protective communication protocol and technology on which a VPN can be built
NOTE: Each IP packet gets encrypted and authenticated prior sending. Authenticated means that an encrypted or
signed hash-value is attached, which only the receiving entity can decrypt and verify. Prior sending, the
packet is then encapsulated into a new packet with a packet header and sent. This establishes a
confidentiality and integrity protection between two network entities.
local administrator: administrator that performs management actions on the HG from the LAN connection
EXAMPLE: A local administrator generates and manages the LAN Wi-Fi® accounts and interfaces.
remote administrator: administrator that performs management actions on the HG from the WAN connection
NOTE: The remote administrator can include the role of the ISP in managing elements of the HG required for
access to the WAN.
ETSI
7 ETSI TS 103 848 V1.1.1 (2022-03)
security log data: log data that is related to security events only
NOTE: These data can contain MAC-, IP-addresses and other data types which could constitute or be related to
personal data.
security critical data: all data comprising security parameters, keys, authentication credentials, security relevant device
configuration settings and any similar values, suitable either to compromise the HG, jeopardize the user LAN, or even
the ISP network.
traffic management log data: log data that is related to traffic management events only
transmission log data: log data that is related to transmission events only
Virtual Private Network (VPN): protected and managed communication channel between one or more entities
traversing a public network
NOTE: The protection of each communication link within a VPN relies usually on preparation steps: The entities
have been identified, authenticated, authorized, negotiated a common session symmetric key, and have
means in place to preserve the integrity of the subsequent communication. The identification,
authentication and authorization of each entity is usually based on security credentials managed by the
VPN operator. All these protection means constitute a VPN.
EXAMPLE: An IPsec tunnel is one means of implementing a VPN.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 303 645 [1] and the following apply:
ACL Access Control List(s)
CPE Customer Premises Equipment
DoS Denial of Service
EN European Standard
HBRT Hardware-Based Root of Trust
HG Home Gateway
HMEE Hardware Mediated Execution Enclave
HSM Hardware Security Module
ISP Internet Service Provider
IT Information Technology
KASLR Kernel Address Space Layout Randomization
LTS Long-Term Support
N/A Not applicable
NMS Network Management System
NTP Network Time Protocol
NVM None-Volatile Memory
OS Operating System
PIE Position Independent Executable
PSK Pre-Shared-Key
RELRO Relocation Read Only
R&D Research and Development
SNMP Simple Network Management Protocol
SP Special Publication
SSH Secure Shell
SW Software
TLS Transport Layer Security
TPM Trusted Platform Module
VPN Virtual Private Network
Wi-Fi® Wireless Fidelity (deprecated)
ETSI
8 ETSI TS 103 848 V1.1.1 (2022-03)
WPA Wi-Fi® Protected Access
4 Methodology and general requirements
4.1 Introduction
A Home Gateway (HG) is connected on one side to the Internet Service Provider (ISP) network and on the other side to
the user's Local Area Network (LAN). On the ISP network side, the HG is exposed to other risks and attacks as an IoT
device, which justifies the promotions, refinements, extensions and additions of the provisions of ETSI EN 303 645 [1].
For the purposes of the present document, the ETSI EN 303 645 [1] sets a security baseline that has been adopted for
the Home Gateway (HG) independently of a potential classification of an HG as an IoT device.
The provisions specified in the present document are supported by the threat analysis in clauses 5 and 6 of ETSI
TR 103 743 [i.1].
4.2 Handling of provisions
The present document adopts the provisions of ETSI EN 303 645 [1] as a baseline for the HG. The methodology used
for the adoption is described in the present clause, which includes different operations to modify provisions from ETSI
EN 303 645 [1] and add new provisions specific to the present document.
All provisions from ETSI EN 303 645 [1] shall apply in the present document, unchanged, to the HG, unless
otherwise noted in the present document.
Consumer IoT devices in the vertical domain of a HG are not constrained devices. Consequently, all provisions from
ETSI EN 303 645 [1] regarding constrained devices are adjusted accordingly.
There are different types of modifications indicated by a naming convention as described in clause 4.3. Within clauses 5
and 6 of the present document, the following modifications can be applied to the set of provisions defined in ETSI
EN 303 645 [1]:
• Information: Providing additional information (in the form of informative text) to an unmodified provision.
The original provision in ETSI EN 303 645 [1] is still valid.
• Promotion: Promoting a recommendation to a mandatory provision. The wording of the provision remains as
in the original provision, but the promoted modal verb is replaced by the new modal verb (e.g. "should" is
replaced by "shall"). The original provision in ETSI EN 303 645 [1] is replaced by the promotion and is not
valid anymore.
• Refinement: Refining a provision with additions or modifications to its normative definition text, including
stronger scoping of conditionality. The original scope and spirit remain in force. The original provision in
ETSI EN 303 645 [1] is replaced by the refinement and is not valid anymore.
NOTE: A refinement can be used to scope the conditionality of a provision, i.e. to remove one or more conditions
from the provision, as part of the clarification on the provision's constraints.
• Extension: Extending an existing provision with one or more new sub-provisions. The original provision in
ETSI EN 303 645 [1] is still valid.
• Substitution: Replacing a recommendation that is not applicable for the HG with another recommendation of
equivalent effect (that provides, possibly in combination with other recommendations or provisions, the same
security outcome as the replaced recommendation). The original provision in ETSI EN 303 645 [1] is replaced
by the substitution and is not valid anymore.
• Exclusion (only possible for recommendations and conditional provisions): Declaring a recommendation or
conditional provision as "not applicable" for the HG. The original provision in ETSI EN 303 645 [1] is
excluded and is not valid anymore.
ETSI
9 ETSI TS 103 848 V1.1.1 (2022-03)
The present document allows to define new provisions within the clauses 7 and 8 that are not covered in ETSI
EN 303 645 [1]. There is one type of new provisions, that is also covered by the naming convention in clause 4.3:
• Addition: Defining a new provision specific to the HG that cannot be linked to any provision in ETSI
EN 303 645 [1].
4.3 Naming conventions
The provisions in the present document are named following the naming conventions described in the present clause.
Each provision contains an acronym representing the HG. The acronym for the HG is set to HG.
Names for provisions that are specific to the present document are constructed as follows:
• The name starts with the string "Provision" to which the acronym "HG" is appended.
• A provision identifier (id) is appended. An example id is 5.1-1.
• One or more suffixes are appended (according to the types of provisions as described in clause 4.2).
NOTE: A provision can be at the same time promoted and refined, in which case the two suffixes are appended to
its name.
• For provisions that are extensions, an alphabetical index is appended, that is unique to the provision, for
example, "-a". The alphabetical index is appended only in cases where there is more than one extension to a
given provision.
The following list describes the suffixes depending on the type of the provision as described in clause 4.2:
• Information: The id is the id of the original provision in ETSI EN 303 645 [1] additional informative
information is provided for. The suffix is "(information)".
• Promotion: The id is the id of the original provision in ETSI EN 303 645 [1] that is promoted. The suffix is
"(promoted)".
• Refinement: The id is the id of the original provision in ETSI EN 303 645 [1] that is refined. The suffix is
"(refined)".
• Extension: The id is the id of the original provision in ETSI EN 303 645 [1] that is extended. The suffix is
"(extended)".
• Substitution: The id is the id of the original provision in ETSI EN 303 645 [1] that is substituted. The suffix is
"(substituted)".
• Exclusion: The id is the id of the original provision in ETSI EN 303 645 [1] that is excluded. The suffix is
"(excluded)".
• Addition: The id is a new and unique id added in clauses 7 or 8 that reflects the clause in which it is defined.
The suffix is "(added)".
4.4 Reporting implementation
Provision HG 4-1 (extended): A justification shall be recorded for each recommendation in the present document that
is considered to be not applicable for or not fulfilled by the device.
ETSI
10 ETSI TS 103 848 V1.1.1 (2022-03)
5 Adapted cyber security provisions for the HG
5.1 No universal default passwords
Existing provisions from ETSI EN 303 645 [1], clause 5.1 are modified as follows.
In an HG, it is broadly assumed that a user and administrator can be the same person (not all users will be the same
person as the administrator) but for the purposes of the present document the terms user and administrator refer to roles
with respect to the HG, with the administrator having a higher level of privilege than a user.
EXAMPLE: An administrator account allows direct modification of some operational parameters of the HG. It
is recognized that an HG can have more than one administrator account: one for the LAN side, and
one for the ISP side. When separate local and ISP administrator accounts exist, it is assumed that
these are suitably isolated from each other.
Provision HG 5.1-1 (extended): Where Wi-Fi® or administrator passwords are preconfigured in factory default, these
preconfigured passwords shall be unique per HG.
Provision HG 5.1-4 (extended) a: HGs shall allow an administrator to set the Wi-Fi® password.
Provision HG 5.1-4 (extended) b: The HG shall provide to the local administrator a simple mechanism to change the
Wi-Fi® password.
Provision HG 5.1-4 (extended) c: The HG shall provide to an administrator a simple mechanism to change the
administrator password (local to local, remote to remote).
Provision HG 5.1-5 (refined): The HG shall have a mechanism available which makes brute-force attacks on
authentication mechanisms via network interfaces impracticable.
5.2 Implement a means to manage reports of vulnerabilities
Existing provisions from ETSI EN 303 645 [1], clause 5.2 are modified as follows.
Provision HG 5.2-1 (information) and Provision HG 5.2-2 (information):
The above-named provisions in clause 5.2 of ETSI EN 303 645 [1] require the manufacturer to publish a policy for
vulnerability disclosure and recommends handling vulnerabilities in a timely manner. The following clarifies these
provisions for the HG, as the HG manufacturer can instantiate different parties and relations between them in the HG
supply chain. Specifically, it is not a user problem to think about where to feedback a discovered vulnerability back to
the manufacturer.
Thus provision 5.2-1 of ETSI EN 303 645 [1] holds true, but needs an explanation for HGs, as those can be subject to
the peculiarities of supply chains that may or may not modify, or personalize, or in other ways alter, the manufacturer
supplied HG. Users will probably address identified vulnerabilities to the instance where they have purchased the HG
which is not necessarily the manufacturer in all cases.
EXAMPLE 1: If the HG is provided through a retail channel, or any other supply chain channel in addition to
direct sales, the manufacturer enables all instances in that supply chain towards the customer to
receive vulnerability reports by the user and handle them.
EXAMPLE 2: Whilst being made available to the manufacturer, the logs and vulnerability reports are made
available through the supply chain for analysis. The supply chain in due course makes reports
available to the manufacturer.
NOTE: Some of the provisions in this group are subject to constraints applied under consumer protection law in
some jurisdictions.
EXAMPLE 3: In many jurisdictions the retail outlet has a primary duty of care for a period of time after sale and
the user ought to be directed to the retail outlet to fix any problems within that period.
ETSI
11 ETSI TS 103 848 V1.1.1 (2022-03)
5.3 Keep software updated
Existing provisions from ETSI EN 303 645 [1], clause 5.3 are modified as follows.
Provision HG 5.3-1 (extended) a: If not all software components are updateable, those components affected shall be
noted and indicated in the user guidance.
Provision HG 5.3-1 (extended) b: The HG shall implement software version control and verify that the version of the
software provided by the update is valid prior to installation.
EXAMPLE 1: The simplest form of version control is to check that the update provides software that has a higher
version number than the currently installed software. Such version control can also be used for
rollback protection.
NOTE 1: If an update fails and the previous state is reinstated, this is considered to be a reversion to the last known
operational state and not a rollback attack.
EXAMPLE 2: If the currently installed software is v2.2 and v2.1 of the software is known to have an exploitable
vulnerability, then reversion to v2.1 is considered to be a rollback attack.
Provision HG 5.3-2 (refined): The HG shall have an update mechanism for the secure installation of updates.
Provision HG 5.3-5 (refined): The HG should be configured by default to check after initialization, and then at least
daily, whether updates are available.
NOTE 2: If the HG is ISP administered then Provision HG 7.3-4 (added) can also apply wherein the ISP pushes
updates to the HG.
NOTE 3: It is assumed that the check for updates is configured at times with low service load.
Provision HG 5.3-6 (extended): If the HG is not an ISP-administrated device and supports the update functionality,
then this functionality shall be enabled by default, configurable including its deactivation and its automation.
Provision HG 5.3-9 (promoted) a: The HG shall verify the authenticity and integrity of software updates.
NOTE 4: A time stamp can be added to the signature to allow the receiver to validate the freshness of the update
after the authentication step.
NOTE 5: The authentication step thereby ensures that the signature preserving the integrity of the update stems
from the allowed party of the supply chain and not from a threat agent.
Provision HG 5.3-9 (extended) b: The HG shall only install updates if the authentication and verification was
successful.
NOTE 6: Authentication and verification, can be based on digital signatures. In the case of third-party software
(Provision HG 7.3-7 (added)), it might not be possible in any case to check the trustworthiness of the
origin.
Provision HG 5.3-11 (refined): The manufacturer should inform the local or remote administrator in a recognizable
and apparent manner that an update is required together with information on the risks mitigated by that update.
NOTE 7: This notification can include the currently new available update version information, but does not
necessarily need to name the older version information which is operated prior to the update.
Provision HG 5.3-14 (excluded): The provision is not applicable for HG and shall not apply.
Provision HG 5.3-15 (excluded): The provision is not applicable for HG and shall not apply.
Provision HG 5.3-16 (extended): Software version numbers shall only be retrievable by an administrator or an
authenticated user on the LAN.
NOTE 8: The version information of the software can help an attacker.
NOTE 9: This provision is not applicable for users on guest Wi-Fi® or Community Wi-Fi®.
ETSI
12 ETSI TS 103 848 V1.1.1 (2022-03)
EXAMPLE 3: If the software release notes for any version includes information on vulnerabilities that have been
fixed in the update an attacker can exploit those vulnerabilities in devices that have not been
updated.
5.4 Securely store sensitive security parameters
An information to the provision from ETSI EN 303 645 [1], clause 5.4 is defined in the present document.
Provision HG 5.4-1 (information):
NOTE 1: See note in the ETSI EN 303 645 [1].
NOTE 2: Critical security parameters as defined by the ETSI EN 303 645 [1] is extended to the broader definition
security critical data for the HG. These data include Wi-Fi®, user and administrator passwords, as well as
access data to the ISP or similar infrastructures.
5.5 Communicate securely
Existing provisions from ETSI EN 303 645 [1], clause 5.5 are modified as follows.
NOTE 1: For the core purpose of the HG to maintain separation of LAN and WAN traffic, the provisions of
clause 5.1 apply to ensure data from any connected device to the HG is protected.
Provision HG 5.5-1 (information):
NOTE 2: Best practice cryptography to communicate securely includes best practice cryptography for the Wi-Fi®
encryption [i.4].
NOTE 3: The meaning of best practice cryptography is defined in ETSI EN 303 645 [1]. However, best practice is
technology and time dependent and for that reason the manufacturer is expected to follow the guidance
provided in the form of maintained cryptographic catalogues, for example by ENISA European
certification schemes.
NOTE 4: WPA3™ is the most recent version (as of the date of publication of the present document), but will not be
supported by some legacy or existing devices that try to connect to the HG. In such cases, WPA2-PSK
hybrid mode or similar is an appropriate compromise between security and availability.
Provision HG 5.5-3 (information):
NOTE 5: Updatability of cryptographic algorithms and primitives depends on the algorithms and key sizes
supported in the hardware and for relevant protocols.
Provision HG 5.5-4 (extended)-a: The HG should support TLS [i.8] for device management via a web-portal by the
local administrator.
EXAMPLE 1: NMS device management services are enabled by a protocol such as the Customer-Premises
Equipment (CPE) WAN Management Protocol [i.9].
Provision HG 5.5-4 (extended)-b: The HG should support TLS [i.8] with mutual authentication using a pre-installed
device certificate for the Network Management System (NMS) and remote device management by the
ISP-administrator.
Provision HG 5.5-5 (information): Accessibility includes both credentials managed by the ISP for connection to the
ISP, and credentials managed on the home network for connections related to the home network side of the HG.
5.6 Minimize exposed attack surfaces
Existing provisions from ETSI EN 303 645 [1], clause 5.6 are modified as follows.
As a guide to the HG developer, the default configuration settings for the HG puts it into a condition where the best
protection against the attacks outlined in ETSI TR 103 309 [i.5] is achieved, taking due note of the analysis provided in
ETSI TR 103 743 [i.1]. It is best practice for the product designer to keep the security by default configuration as a
principle in mind during product development.
ETSI
13 ETSI TS 103 848 V1.1.1 (2022-03)
Provision HG 5.6-1 (extended): The guest Wi-Fi® access, if present, shall be disabled by default.
NOTE 1: Only the ISP administrator will have the ability to enable or disable the community Wi-Fi®.
HGs between the ISP and user LAN are exposed to attacks at all times. For that reason, Provision EN 5.6-5 from ETSI
EN 303 645 [1] is upgraded to a mandatory requirement.
Provision HG 5.6-5 (promoted): The manufacturer shall only enable software services that are used or required for the
intended use or operation of the device.
Third party application and plug-ins are potential high-risk software which can incur attacks to the HG. Applying
techniques for process isolation provides an isolated environment such as a closed container or a sandbox for operation.
Operation in such closed compartments mitigates attacks originated from third party applications and plug ins.
Provision HG 5.6-7 (extended): If the HG supports installation of third-party applications and plug-ins, the HG should
support a container or sandbox for third party applications and plug-in isolation.
NOTE 2: Not all HGs will support the installation of third-party applications and plug-ins, thus this provision only
applies to relevant HGs.
Vulnerabilities of the HG can be a result of coding without security considerations or simply by implemented faults.
Therefore, applying secure coding is an essential good practice for all R&D engineers to improve the security of the
product code and decreasing potential vulnerabilities which could enable the undesired modification of the code.
Additionally, secure coding practices habitually prohibit the implementation of hard-coded cryptographic keys which
could enable disclosure of code and data and their modification from being abused.
Provision HG 5.6-9 (information) a: This provision is more detailed by following examples:
EXAMPLE 1: Secure compiling flags such as stack protection, Relocation Read-Only (RELRO), PIE, and
Stack-Smashing-Protector techniques.
EXAMPLE 2: Memory protection features such as the use of Non-eXecutable (NX) memory and Kernel Address
Space Layout Randomization (KASLR).
EXAMPLE 3: Secure variants of functions provided by the latest versions of programming languages. For
example, the function gets() in C/C++ [i.11] can lead to a buffer overflow if the string being read
is longer than the variable assigned, whereas the function fgets() is bounded to read a fixed length
string.
Provision HG 5.6-9 (extended) b: The firmware should use best-practice programming techniques to mitigate
tampering, fault and leakage attacks.
It is recognized that manufacturers can choose to develop their products on the basis of open source software. When this
is the case the same provisions apply to open source software with respect to good programming practice. In particular
where faults or vulnerabilities exist in the open source resource they are reported and fixed in the same manner as any
other code development.
5.7 Ensure software integrity
Existing provisions from ETSI EN 303 645 [1], clause 5.7 are modified as follows.
Provision HG 5.7-1 (extended): The HG should not provide any command or API to disable the secure boot feature or
to circumvent this feature and boot from other sources.
Provision HG 5.7-2 (extended): If any integrity verification fails during the secure booting the HG should reset and
retry the secure booting using the firmware backup image. If secure boot using the firmware backup image fails, the HG
should be disabled from further operation.
5.8 Ensure that personal data is secure
No modifications to the provisions from ETSI EN 303 645 [1], clause 5.8 are defined in the present document.
ETSI
14 ETSI TS 103 848 V1.1.1 (2022-03)
5.9 Make systems resilient to outages
Existing provisions from ETSI EN 303 645 [1], clause 5.9 are modified as follows.
Having firmware and log file backups mitigates against the consequences of a data integrity failure. In the event of a
failure, the original data can be recovered from an uncorrupted copy stored on a different device.
Provision HG 5.9-2 (promoted)(refined): The HG shall remain operating and locally functional in the case of a loss of
network access and shall automatically recover to the previous connectivity and configuration state without user action
in the case of restoration of a loss of power.
The HG is exposed to the internet by design and can be under attack as described in ETSI TR 103 743 [i.1]. The
following requirement extends Provision EN 5.9-3 from ETSI EN 303 645 [1] to address specific sources of functional
outages that impact system resilience.
Provision HG 5.9-3 (extended): When the HG is overloaded, it should buffer unprocessed traffic management packets
in order to maintain availability.
5.10 Examine system telemetry data
No modifications to the provisions from ETSI EN 303 645 [1], clause 5.10 are defined in the present document.
The timely examination of telemetry, including log data, is often useful for security evaluation and can allow problems
(e.g. faults or attacks) to be identified early and dealt with, minimizing security risk and allowing mitigation of
problems.
Whilst an HG can use telemetry data for some traffic management tasks, e.g. routing optimization, the present
document focusses on the recording of security events.
Security event data include, but are not restricted to: log-in failures, firmware updates, and memory area accesses.
As telemetry and security data are different, the event records are stored in discrete log files. The present document
addresses the requirements for generating and maintaining security log data and the resulting security log file.
The additional provisions and a description of the log data are given in clause 7.10.
5.11 Make it easy for users to delete user data
No modifications to the provisions from ETSI EN 303 645 [1], clause 5.11 are defined in the present document.
5.12 Make installation and maintenance of devices easy
Existing
...