Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/dsyx/docs.silabs.com_zh/llms.txt

Use this file to discover all available pages before exploring further.

保护物联网设备的安全是当今嵌入式系统开发中最重要的挑战之一。随着外在威胁不断增多,客户数据和商业模型面临的风险日益增加。Silicon Labs 是 ioXt(Internet of Secure Things,安全物联网)联盟的成员,致力于与安全社区、客户和行业专家合作,将最先进的安全技术引入产品开发工具链。本文档以 ioXt 联盟的八项安全原则为结构框架,清晰阐述了 Silicon Labs 提供的端点安全解决方案,以及开发者在 Silicon Labs 框架之外需要自行完成的工作。

ioXt 八项安全原则总览

ioXt 安全承诺覆盖安全性、可升级性和透明性三大维度,以下八项原则构成了 IoT 产品安全设计的基准:

1. 没有通用密码

产品必须使用唯一的安全凭证,禁止通用密码。

2. 安全接口

所有产品接口(调试、无线、串行)须经过适当保护。

3. 经过验证的加密方式

使用公开、经过同行评审的加密算法,禁止自行实现。

4. 默认安全

产品出厂时默认启用所有安全功能,无需用户手动开启。

5. 已签名的软件更新

仅接受加密签名的固件更新,防止恶意篡改。

6. 自动应用的更新

发现漏洞后,制造商应自动将安全补丁推送到设备。

7. 漏洞报告程序

建立公开的漏洞报告联系渠道,及时响应和披露。

8. 安全性到期日

公开安全更新的支持期限,保持透明度。

原则一:没有通用密码

产品不应具有通用密码;操作需要唯一的安全凭证。通用密码使攻击者可以轻松访问任意设备,因此产品应具有唯一的凭证或要求用户在首次使用时立即设置新密码。 开发者责任:在激活之前确保产品强制创建唯一密码。 各协议的安全认证示例:
  • EmberZNet Pro SDK:支持高度安全的集中式信任中心控制,将设备工厂编程的链接密钥替换为网络上每个设备唯一的密钥。
  • Z-Wave 700:首次上电时带有工厂编程的唯一 S2 密钥对,通过包含公钥的 QR 码支持 SmartStart commissioning。
  • Bluetooth:选项范围从不安全的 “Just Works” 到 LE Secure Connections Pairing 模型,开发者可添加额外的设备身份验证机制(如配套智能手机应用)。

原则二:安全接口

所有产品接口均应由制造商适当保护。
1

调试接口锁定

调试接口应始终被锁定。Series 1 设备通过写入调试锁定字(Debug Lock word)实现,解锁时会删除主应用和 Lockbits 页中存储的密钥材料。Series 2 设备通过设备内部的安全元素(Secure Element)完成安全调试访问控制。
2

NCP 接口保护

在 NCP 拓扑中,NCP 与 Host 之间的通信接口须得到保护,防止物理窃听。
3

无线接口加密

通过强大的配对和 commissioning 方法,以及启用加密和认证的传输层协议,保护无线通信接口的安全。

原则三:经过验证的加密方式

产品安全性应使用健壮的、经过验证的加密技术,采用公开的、同行评审的方法和算法。 Silicon Labs 提供了硬件 CRYPTO 模块,有效加速常见加密操作:
算法说明
AES(Advanced Encryption Standard)高级加密标准,支持硬件加速
SHA-1 / SHA-2(SHA-224、SHA-256)安全哈希算法,支持硬件加速
ECC(Elliptic Curve Cryptography)椭圆曲线密码学,通过模乘支持
GCM(Galois Counter Mode)伽罗瓦计数器模式认证加密
CCM(Counter with CBC-MAC)带消息认证的计数器模式加密
Silicon Labs 将 mbed TLS(ARM Limited 开源软件)作为 Gecko Platform SDK 的一部分提供。mbed TLS 支持 TLS 1.2 所有加密算法的软件实现,并允许硬件驱动程序替换软件实现以利用加速器,模块化框架支持加密库独立于 SSL/TLS 组件使用。
mbed TLS 提供的功能包括:
  • TCP/IP 通信(监听、连接、接受、读写)
  • SSL/TLS 通信(初始化、握手、读写)
  • X.509 证书、CRL 和密钥处理
  • 随机数生成、哈希、加密/解密

原则四:默认安全

制造商默认应适当地启用产品的所有安全功能,客户不必手动开启安全性,而应需要主动禁用它。 例如,Silicon Labs Z-Wave 终端节点和网关 SDK 默认附带 S2 加密和 SmartStart 网络形成。Silicon Labs 认为应在产品设计过程中将安全性纳入考量,而非事后补救。
AN961: Bringing Up Custom Devices for the EFR32MG and EFR32FG Families 描述了可编程到自定义设备中的安全性 Token(密钥和证书等),支持 Gecko Bootloader 提供的多种安全功能。

原则五:已签名的软件更新

产品应仅支持经过加密签名的软件更新,以防止部署过程中的固件篡改。 Silicon Labs Gecko Bootloader 是实现安全固件更新的核心组件,主要特性包括:
安全启动(Secure Boot)启用安全引导后,Bootloader 在每次启动时使用非对称密码(如 ECDSA)对应用映像执行加密签名验证,确保应用由受信任方创建并签名。在 Silicon Labs 提供的示例配置中默认未启用,但强烈建议在生产产品中启用。已签名的升级映像文件Gecko Bootloader 支持对升级映像文件执行加密签名验证,在开始升级前验证映像来源的可信度。已加密的升级映像文件映像文件可进行加密,防止窃听者获取明文固件内容,保护知识产权。两阶段设计(Series 1)最小的初阶 Bootloader 负责升级主阶 Bootloader。主阶 Bootloader 在升级前验证映像完整性和真实性,通过 CRC32 校验后复制到主阶 Bootloader 位置。安全元素升级(Series 2)Series 2 设备仅有主阶 Bootloader,通过硬件安全外设**安全元素(Secure Element)**完成升级。安全元素可针对信任根验证主阶 Bootloader 更新映像的真实性,并能以相同机制自行升级。
Series 1 设备中,Gecko Bootloader 的真实性和完整性被假定为受信任且未进行明确检查;而 Series 2 设备支持硬件信任根,可在启动时验证 Gecko Bootloader 本身的真实性和完整性。设计高安全等级产品时,应优先选用 Series 2 设备。
Gecko Bootloader 的两个安全级别:
级别说明
安全启动(Secure Boot)每次启动时验证主 Flash 中应用映像的真实性
安全固件升级(Secure Firmware Upgrade)引导加载前验证升级映像真实性,并可选对映像加密

原则六:自动应用的更新

制造商应迅速行动,在检测到安全漏洞后自动将补丁推送到设备,无需用户干预。 开发者责任:设计并实现自动安全更新机制(如通过云连接基础设施或服务代理直接干预)。Silicon Labs 会在发现安全相关更新时通知客户,由开发者评估漏洞风险等级并将更新集成到平台中。 建议的操作:
  • 通过 Salesforce 门户订阅安全更新(选中 Software/Security Advisory Notices & PCNs
  • 不要关闭 Simplicity Studio 的更新通知

原则七:漏洞报告程序

Silicon Labs 建立了完整的漏洞响应流程:
1

漏洞报告

客户和安全研究人员可在 silabs.com/security/product-security 报告 Silicon Labs 硬件和软件产品中的安全漏洞。
2

PSIRT 处理

Silicon Labs PSIRT(Product Security Incident Response Team)负责案例管理,与应用、开发、销售团队协作评估漏洞,基于 CVSS 3.1 对事件进行评分(低、中、高、严重)。
3

分诊与分析

确认漏洞的可重现性、有效性、范围及影响,制定解决方案或处置决策。
4

输出与披露

通过 Salesforce 门户向订阅客户发布安全建议通知,披露级别和方法取决于漏洞的严重性和范围。

原则八:安全性到期日

制造商应对提供安全更新的时间段保持透明,发布安全性到期日期,并在各个生命周期阶段提供产品支持详情。 Z-Wave 协议生命周期是良好示例,其详细定义了各阶段将应用哪些更新以及适用于哪个产品分支。有关 Silicon Labs 安全资源的完整列表,请访问 silabs.com/security

Build docs developers (and LLMs) love