一、ETSI EN 303 645 安全认证的背景

在家庭中，有越来越多的设备都通过有线或者无线连接到互联网，即使是传统上离线的产品，现在也联网了。因此，物联网的网络安全越来越受到人们的关注。人们的私人数据被委托给各种在线设备和服务，那就需要设计用来抵御网络威胁的各种标准规范。

ETSI EN 303 645 就是为参与消费物联网开发和制造的所有各方提供关于确保其产品安全的一种标准规范。

ETSI EN 303 645 除了可用于 IoT 设备的认证，还可用于电网设备的认证。英国国家电网于 2021 年 9 月发布新版并网标准，旧版标准的撤销实际是 2022 年 9 月 1 日，现有相关

证书必须在 2022 年 9 月 1 日前完成标准更新，否则将被撤销，因此，制造商必须遵守新的

特定的网络安全标准。ETSI EN 303 645 就是新的并网标准所推荐的网络安全标准之一。本文就是讲述了标准的主要内容，以及在设备中需要如何满足这些标准的要求。

二、ETSI EN 303 645 安全认证的主要内容和应对方案

ETSI EN 303 645 中，主要包含 13 项消费者网络安全规定及 1 项消费者数据保护规定。在该项标准附带的表格（Table B.1： Implementation of provisions for consumer IoT security） 中，说明了哪些条款是强制性的（M， mandatory），哪些是推荐的（R，recommendation），哪些是在条件性强制的（MC），哪些是条件性推荐的（RC）。条件性强制是指，在符合某些条件的情况下，才需要强制性满足某些规定，不满足相关条件时，则不需要考虑。条件性推荐类似。

由于条款众多，下面仅列举出强制性和条件性强制的条款，并说明为符合该项条款标准， 制造商所需做的工作。

条款 5.1：没有通用默认密码

该项属于条件性强制（MC），即如果设备使用了密码，则需要做到以下几点：

1、每个设备的密码唯一，或者以相同预装密码登录后必须要求用户修改密码。

2、如果密码作为验证身份验证的机制，则该密码需要符合 NIST 特别出版物 800-63B：

"Digital Identity Guidelines - Authentication and Lifecycle Management".I 中关于密码的最佳实践。该文件链接为： https：//nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

63b.pdf。

3、预装密码需要充分随机化，不易被破解。

4、用于对用户进行身份验证的身份验证机制，无论是指纹、密码还是其他令牌，其值都需要可变。

5、 设备在一定时间间隔内对身份验证尝试的次数有限制，还可增加尝试之间的时间间隔。

6、客户端应用程序能够锁定帐户，或者在有限数量的失败身份验证尝试之后延迟其他身份验证尝试。

条款 5.2：实现管理漏洞报告的一种方法

该项要求制造商必须公开漏洞披露政策（M 强制性的）。本政策至少应包括：

·报告问题的联系方式；

·关于下面几个方面的时间表信息：

1）初步确认收到漏洞报告；

2）状态更新，直到报告的问题得到解决。具体操作可用参照下述方案：

1、 提供漏洞上报的渠道，如邮箱、网页、电话等，且用户方便知晓这些渠道；

2、 收到用户反馈的漏洞信息后，应明确指定的部门对接处理漏洞信息，并于一定日期内进行通报；

3、 对所披露的漏洞应及时采取行动，通常针对软件解决方案的漏洞处理过程在 90 天内完成，包括补丁的可用性和问题的通知。硬件修复也许会比软件修复的时间更长，而且当产品使用了第三方硬件或者软件时，需要进行协商处理，并需要第三方进行通报。

4、 如果产品使用了开源库，需要根据开源库的漏洞披露信息，及时修改相关漏洞，更新产品。

5、 在完成修改后，可用进行版本更新，并在版本更新日志中说明修复的了哪些漏洞。

条款 5.3 保持软件更新

及时开发和部署安全更新是制造商为保护其客户和更广泛的技术生态系统所能采取的最重要的行动之一。所有软件保持更新和维护是良好的做法。

该项中，必须要做到的是（M 强制性的）：

1、 制造商应通知用户产品的支持周期；

2、 产品有可靠的唯一标识。

这里产品支持的周期，只要用户能知晓，无论哪种方式都可以。

如果设备软件支持更新，则必须做到以下几点（MC 条件强制性的）：

1、应提供可靠地安装更新软件的方法；

2、用户更新软件的操作应尽量简单；

3、软件更新应使用被公认为业界最佳实践的加密方法；

4、关于安全的更新应及时；

5、如果软件是通过互联网更新，设备应通过一个可信机制检查更新的真实性和完整性。对于软件不支持更新的情况，可能是以下两种情况之一：

1、 设备上的第一阶段引导加载器只能写一次到设备存储中，从那以后是不可变的。

2、  具有多个微控制器的设备（例如，一个用于通信，一个用于应用程序），其中一些可能是不可更新的。

对于软件支持更新的产品来说，更新机制可以从设备直接从远程服务器下载更新、从移动应用程序传输或通过 USB 或其他物理接口传输。如果攻击者破坏此机制，就允许在设备上安装恶意版本的软件。因此，对于第 1 条和第 4 条，我们可以结合来看。

我们知道，成功地管理软件更新通常依赖于设备和制造商之间的软件组件版本信息的通信。更新机制如果是从远程服务器上下载更新，则需要明确的是，不能使用 FTP/HTTP 此类不安全协议，而需要使用SFTP/HTTPS 该类安全协议，在使用HTTPS 时，我们最好采用TLSv1.2 及其以上版本。传输更新文件的过程中，采用了安全协议，才不会导致更新文件被恶意篡改， 从而导致产品升级失败或者造成信息泄露，造成无法挽回的后果。如果为了进一步符合安全认证的要求，除了传输过程的加密，可以把更新文件自身进行加密。

更新机制如果是本地的，比如通过 USB 或者其他物理接口传输，则更需要考虑到的是物理安全性，是否有人会冒充用户进行操作。

对于第 3 条标准，软件更新应使用加密方法的业界最佳实践。针对常用的加密算法，我们需要简单了解到以下内容：

对于分组密码，比较推荐的是 AES[FIPS197，ISO18033-3]（k=128 位， k=192 位， k=256

位）; Triple-DES [FIPS46-3， ISO18033-3]相对于 AES，则被认为是不推荐的。

对于哈希函数，比较推荐的是 SHA-2[FIPS180-4，ISO10118-3]（（SHA-256、SHA-384、

SHA-512、SHA-512/h）以及 SHA-3[FIPS202]（h=256 位，h=384 位，h=512 位），不推荐

的是（SHA-224、SHA-512/224）。

对于第 4 条标准，涉及到安全要及时更新，我们需要注意的是，如果需要及时更新，那么产品就需要有推送更新的功能，比如手机版本更新时，手机用户就会收到手机版本更新的通知，由用户决定是否升级，当然，也有可能有些产品会在后台进行强制升级。

当然，如果自动更新失败，那么在某些情况下，用户可能无法再使用设备。诸如看门狗之类的检测机制、使用双存储库闪存或者恢复分区等方式，可以确保设备返回到已知的良好版本或出厂状态。

条款 5.4 安全存储敏感的安全参数

该项中，必须要做到敏感安全数据不使用硬编码（M 强制性）。其他的标准如下（MC 条件强制性）：

1、如果持久化储存中保存了敏感安全数据，则数据需要被加密存储，或者储存该数据的环境是安全的。

2、如果设备软件的源代码中以硬编码的方式使用了设备标识，则该标识的实施方式应该具有防篡改的能力，这里的篡改手段包括物理、电气或软件等。

3、如果有用于检查软件更新完整性、真实性的安全数据，以及用于保护和设备软件中相关服务通信的安全数据，都应该是每设备唯一，并且应该采用一种机制来产生，从而降低被自动攻击的风险。

下面将分别列出上述三点标准对应的处理方案：

第 1 条，安全的存储机制可以用于保护敏感的安全参数。根据 ETSI TR 121 905[I.29]、ETSI TS 102 221[I.25]/根据 GSMA SGP.22 技术规范V2.2.1[I.26]的嵌入式UICC（即嵌入式 SIM

卡），适当的机制包括由可信执行环境（TEE）提供的机制、与硬件相关联的加密存储、安全元件（SE）或专用安全组件（DSC）以及在UICC 上运行的软件的处理能力。

比如：

1）在授权和访问许可射频（例如，LTE-m 蜂窝接入）中涉及的根密钥存储在 UICC 中。

2）使用可信执行环境（TEE）来存储和访问敏感的安全参数的远程控制门锁。

3）无线恒温器将无线网络的凭据存储在防篡改微控制器中，而不是外部闪存中。

第 2 条，采取的方案，可以是用于网络访问的设备独有的主密钥存储在符合相关 ETSI

标准的UICC 中。

第 3 条，采取的方案可以是两种：

1）在同一产品类别的每个设备上部署不同的对称密钥，用于生成和验证软件更新的消

息身份验证代码。

2）设备使用制造商的公钥来验证软件更新。这不是一个关键的安全参数，不需要每个设备都是唯一的。

如果使用全局关键安全参数，它们的泄漏可能会导致对其他物联网设备的大规模攻击， 例如创建僵尸网络。为了保护软件更新的完整性和真实性，必须使用唯一的关键安全参数， 从而也达到了保护设备与其相关服务之间通信的目的。

条款 5.5 安全通信

该项中，必须要做到的是使用被认为是最佳实践的加密方式来安全通信（M 强制性）。其他条件强制性标准如下（MC 条件强制性）：

1、 如果可以通过网络接口更改安全配置相关的设备功能，那么该访问必须在认证后才能进行；

2、 如果可以通过远程访问的网络接口传输关键安全参数，那么需要保证该关键安全参数的机密性；

3、 如果存在与设备相关的关键安全参数，那么应该遵守相关的安全管理流程。

条款 5.6 尽量减少暴露的攻击面

“最小特权原则”是良好安全工程的基石，适用于物联网和其他任何应用领域。该项中，必须要做到的是（M 强制性）：

1、不能对外放开任何没有用到网络接口或者逻辑接口

2、在默认状态下，设备的网络接口需要减少在没有认证情况下，能够获取的安全信息， 也就是未登录或者注销的状态下，用户不应该看到任何相关安全信息。如果用户权限分等级， 也应该不同权限的用户，看到不同的信息内容。

其他条件性强制标准如下（MC 条件强制性）：

如果有调试端口在物理上可访问的，则应在软件中禁用该接口。

条款 5.7 确保软件完整性，是推荐规定，这里暂不列举。

条款 5.8 确保个人资料安全

该项是条件性强制标准（MC 条件强制性）：

1、 如果敏感个人数据在设备和服务（一般指云服务）之间传输，应该对这些数据的机密性进行保护。并选用适合于技术和使用特性的加密技术。

2、 如果设备存在外部传感能力，则所有的外部传感能力需要以用户清楚透明的方式记录。

条款 5.9 使系统对停机有弹性，是推荐规定，这里暂不列举。

条款 5.10 检查系统遥测数据，是推荐规定，这里暂不列举。

条款 5.11 使用户易于删除用户数据

该项是条件性强制标准（MC 条件强制性）：

如果用户数据存储在设备上，则应向用户提供删除的功能，即可以以用简单的方式将所有的用户数据（包括个人数据、用户配置和密码资料， 比如用户密码或密钥）从设备中删除。

条款 5.12 使装置的安装和维护变得简便，是推荐规定，这里暂不列举。

条款 5.13 验证输入数据。

该项是条件性强制标准（MC 条件强制性）：

如果用户可以通过界面输入数据，或通过 API 传输数据，或通过网络在服务和设备之间传输数据，则需要校验通过用户接口输入的数据或通过 API 传输的数据，或在服务和设备中的网络之间传输的数据。

条款 6 消费者物联网的数据保护规定

该项是条件性强制标准（MC 条件强制性）：

1、如果保存了个人数据用作处理，需要向消费者提供清楚且透明的信息，包括说明每台设备和每个服务处理和使用了哪些个人数据，这些数据由谁使用，用于什么目的。

2、如果在客户同意的前提上处理个人资料，则须以有效方式取得该许可。

3、如果在客户同意的基础上处理个人资料，则消费者有权随时撤回该资料。

4、如果存在收集遥测数据，则从消费者设备和服务收集收集遥测数据，应向消费者提供相关信息，包括收集什么遥测数据、如何使用这些数据 、由谁使用以及用于什么目的。以上，是对ETSI EN 303 645 安全认证的解析及部分应对方案建议，对于物联网设备或

者电网嵌入式设备都适用。制造商可以根据上述要求评估产品目前的情况，对于不符合标准的产品，可根据相关建议方案进行处理。

三、提供认证机构测试的要求

与现有的网络安全标准相比（比如：网络安全通用准则 ISO 15408 标准 ）， EN 303 645 标准专为消费品而设计，其测试流程更快捷、更简单，成本也更经济。因此制造商要在欧盟和英国出售物联网及电网设备产品，一般会通过相关认证机构进行 EN 303 645 的安全认证。

产品的开发人员、制造商、卖方或分销商（供应商）均可提交产品来申请 EN 303 645 标准的合规测评。

产品提交认证机构测试需提供：

1、 产品实物及相关软件（如适用）

2、 待测试设备（简称"DUT"）的详细识别信息、具体说明产品详情（如：产品名称、相关硬件及固件版本，以及操作系统（如适用） ）。

3、 提供《实施合规声明》（简称"ICS 声明"），在声明中须具体说明产品设计符合 ETSI EN

303 645 标准的哪些具体规定（并且需提供不符合或不适用该等规定的合理解释）。

4、 提供"测试实现附加信息" （简称"IXIT 信息"） （此信息是一种与产品相关的问卷调查）， 以便获取所有必需的额外信息，根据 ETSI EN 303 645 标准的具体条款对产品实施评估。IXIT 声明所需提供的相关信息将取决于 ICS 声明具体的指定要求。

以上就是ETSI EN 303 645 安全认证需要初步了解的相关内容，后续交由认证机构评测后，还需要根据评测结果进行修改，直到所有评测项都通过，才能最终获取相关证书。

参考文档：

1 、 ETSI EN 303 645_2020 Cyber Security for Consumer Internet of Things_Baseline Requirements .pdf

2、SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf