网络弹性法案下嵌入式Linux设备的完整性

# 网络韧性法案下嵌入式Linux设备的完整性 来源：https://sigma-star.at/blog/2026/06/integrity-on-embedded-linux-devices-under-the-cyber-resilience-act/ 与保密性（https://sigma-star.at/blog/2026/02/data-confidentiality-via-storage-encryption-on-embedded-linux-devices/）一样，《网络韧性法案》(CRA)将完整性列为一项关键的网络安全要求。本文将探讨这对嵌入式Linux设备意味着什么。 附件一第一部分第(2)条（https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_I）规定，投放欧盟市场的含有数字元素的产品应： > (f) 保护存储、传输或以其他方式处理的数据（个人或其他）、命令、程序和配置免受未经用户授权的任何篡改或修改的侵害，并报告损坏情况。 那么，嵌入式Linux设备如何实际满足这一要求呢？CRA的完整性要求涵盖范围广泛。它不仅涉及（个人和非个人）数据，还包括命令、程序和配置，并且适用于设备存储、传输或主动处理这些资产的所有状态。 没有单一的技术控制措施能够保护所有状态下所有这些资产。根据产品和威胁模型的不同，完整性可能需要对启动链、软件更新、存储数据、应用程序二进制文件、配置、命令以及与其他系统的通信实施控制。 ## CRA完整性要求的范围 这包含两个部分： ### 范围内的资产 > 存储、传输或以其他方式处理的数据（个人或其他）、命令、程序和配置 CRA明确提到了数据、命令、程序和配置，但并未规定固定的组件或控制措施清单。根据第13条（https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_13），网络安全风险评估必须指明附件一第一部分第(2)条的要求是否适用于该产品以及如何适用。对于嵌入式设备，这意味着供应商需要一个威胁模型。该模型应确定攻击者可能修改哪些资产、可能使用哪些路径以及后果是什么。 对于嵌入式设备，范围内的资产可能包括引导加载程序、内核、内核命令行、应用程序二进制文件、配置以及与其他系统交换的消息或命令。因此，该要求并不仅限于用户数据或个人数据。即使是不存储任何个人数据的设备，也属于完整性要求的范围。 ### 所需的保护 > 保护……免受未经用户授权的任何篡改或修改的侵害，并报告损坏情况 对于嵌入式Linux设备而言，这意味着保护相关资产免受未经授权的修改，在适当情况下检测完整性故障，并报告损坏情况。采用何种技术取决于资产和威胁模型。 在某些情况下，防止未经授权的修改还需要真实性（https://csrc.nist.gov/glossary/term/authenticity）。设备必须验证软件、配置、命令或数据是否来自授权来源。 ## 嵌入式Linux的完整性控制措施 嵌入式Linux设备通常需要在多个层面实施完整性控制措施。以下示例是起点，而非每个产品的核对清单： - **安全启动**：在设备执行启动链中的每个组件之前，验证其完整性和真实性。需谨慎实施安全启动：攻击者可能会滥用信任链之外的输入（例如内核命令行或引导加载程序环境）来实施绕过。 - **签名更新**：在设备安装固件、操作系统和应用程序更新之前，验证其真实性和完整性。根据产品的不同，这可能还需要回滚保护。 - **静态数据完整性**：检测存储数据的修改或损坏。根据层级和用例，可以通过不同机制实现，例如： - dm-verity（https://docs.kernel.org/admin-guide/device-mapper/verity.html）用于只读块设备 - dm-integrity（https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html）用于可写块设备，可选择与dm-crypt（https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html）结合使用以实现认证加密。 - Linux IMA和EVM（https://ejaaskel.dev/yocto-hardening-ima-and-evm/）用于文件完整性和选定的文件元数据。 - fs-verity（https://docs.kernel.org/filesystems/fsverity.html）用于只读文件内容。 - **访问控制**：通过限制谁或什么可以修改相关资产来维护完整性。设备可以在不同层面实施访问控制，例如使用文件系统权限、Linux安全模块（如SELinux（https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git/tree/README.md）或AppArmor（https://apparmor.net/）），或针对API（如REST或GraphQL）的应用程序级授权检查。 - **传输中数据完整性**：检测设备与其他系统交换数据时未经授权的修改，并拒绝修改后的数据，例如使用TLS。 - **可信执行环境**：保护使用中的选定代码和数据。例如，根据TEE的设计和威胁模型，即使在攻击者攻破主操作系统的情况下，TEE也能提供完整性和机密性保护。 ## 结论 主要结论是，CRA的完整性要求范围广泛，没有单一功能能够满足它。根据威胁模型，产品可能需要多种互补技术。 提醒一下，违反CRA将面临巨额罚款。主要义务自2027年12月11日起适用，此后若不符合基本网络安全要求，可能导致高达1500万欧元或全球年营业额2.5%（https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_64）的罚款。 如果您需要协助推导威胁模型、选择合适的完整性机制，或审查现有缓解措施是否覆盖相关威胁，我们乐意提供帮助。