嵌入式系统信息安全概述

 

在受控环境中，防止意外错误和硬件故障足以实现安全行为。如果检测到不可恢复的情况，系统可以切换到功能有限或没有功能的状态，但仍然是安全的。

在不受控制的环境中，各种形式的破坏都可能危及系统的安全。只有在生命周期的每个步骤都考虑安全性，才能防止这种情况发生，这些步骤包括：

1 威胁建模-在设计阶段，必须识别安全需求。

2 安全的组件-软件开发人员必须正确地实现安全需求。此外，他们必须以不向系统添加任何漏洞的方式实现所有其他需求。

3 安全的部署-软件交付时（如从供应移到制造商），供应商必须提供软件完整性和真实性的检查机制。

4 主动维护-在产品的生命周期内，制造商必须纠正组件使用中发现的漏洞。

5 安全更新和启动-在更新系统时，产品制造商必须确保更新软件的完整性和真实性。

1. 威胁建模

创建安全系统的第一步是识别系统资产。产品制造商使用威胁建模来分析攻击者如何威胁这些资产。

威胁建模必须集成到设计过程中，并在所有抽象级别上执行。因此，在定义高级需求时，软件架构师识别进一步的抽象威胁。这些威胁会导致额外的安全需求，以减轻这些威胁。该分析将集成到随后的每个开发步骤中。

嵌入式系统必须保护：

• 系统安全：大多数类型的攻击都会影响系统的安全性。

• 系统可用性：如果攻击者可以关闭系统，则客户将无法使用设备。

• 商业秘密：如果攻击者可以访问固件，他们就可以获取其包含的商业秘密。

• 法律遵从性：如果攻击者可以导致系统违反法律（发送垃圾邮件，监视别人），这将对产品制造商造成法律影响。

• 公司声誉：系统故障可能会给制造商带来不好的影响。

一旦确定了系统资产，产品制造商就必须估计攻击者为攻击这些资产而愿意投入的成本和资源。基于这些信息，开发团队就可以定义产品必须达到的安全级别。基于定义的安全级别，开发人员可以导出安全需求以最小化风险。

IEC 62443安全等级

IEC62443定义了5个安全级别（SL）对组件达到的安全级别进行分类：

• 安全级别0：不需要特殊要求或保护。

• 安全级别1：防止无意或意外的误用。

• 安全级别2：使用很少的资源、一般技能和简单活动防止故意滥用。

• 安全级别3：利用适度的资源、系统特定知识和适度的活动，防止复杂手段的故意滥用。

• 安全级别4：通过大量的资源、系统特定知识和高度活动，防止使用复杂手段进行故意滥用。

按照功能安全标准开发系统时，安全级别SL-1不需要进一步的活动。术语“很少（few）”、“中等(moderate)”和“高(high)”并不能很好地定义更高的安全级别。对于安全级别的一般理解是：

• SL-2可以防止业余爱好者或愤怒的前雇员查阅有关安全和想攻击的系统的公开信息。

• SL-3可以防止专业黑客通过勒索、出售漏洞或提取的信息来赚钱。

• SL-4可防范从公司或政府获得大量资金支持的专业黑客组织。

IEC62443安全要求

IEC62443列出了为满足安全级别组件必须实现的功能需求。例如，“与系统交互的人……”：

• SL-1:…须被识别和验证。

• SL-2:…须唯一标识和身份验证（没有共享的管理帐户）。

• SL-3:…果从不受信任的网络访问，必须通过多因素身份验证进行唯一标识和身份验证。

• SL-4:…须在所有网络上通过多因素身份验证进行唯一标识和身份验证。

安全区域

提高安全性的屏障（墙、门、保安、防火墙、虚拟化技术等）将系统划分为区域，每个区域达到其组件的最低安全级别。虽然IEC62443主要解决自动化和控制系统中的操作技术安全问题，但定义的安全级别对于任何有关安全的讨论都是有价值的。

2. 安全的组件

实现安全系统的第二步是确保每个组件的设计和实现都是安全的，并为其他组件提供安全的接口。组件开发人员必须遵循“设计安全”的原则，考虑适用的安全标准，并将威胁建模的结果纳入设计过程的每个步骤。

接口约定

除了正确实现组件的功能需求外，安全性还依赖于对所使用的其他组件的约定的严格遵守。在这种情况下，约定意味着组件对其调用者的需求。

例如:

• 从内存池中取出的每个内存块都将返回到相同的内存池中。

• 函数的参数不能为零。

• 需在临界区内调用函数。

对调用者施加这样的限制有很多原因（性能、灵活性、可移植性等），系统的安全性要求满足这些约定。

执行期望

在实现新组件时，开发人员应该通过尽可能多地验证约定的遵从性来提高安全性。由于软件无法在运行时验证所有约定，组件开发者必须在相应的文档中清楚地描述剩余的未检查的期望。组件用户可以遵循这些约定，并使用各种软件开发技术（如评审、静态分析、测试等）来证明对约定的遵从性。

通信协议验证

实现通信端点的组件必须确保所有通信消息符合商定并记录的协议。

具体来说，这意味着要验证每条消息字段的类型、值范围、大小和编码，还要验证元数据，如每次消息的数量、发送方地址和消息的预期顺序。软件必须根据安全列表检查枚举，而不是从拒绝列表中排除项目。对违反协议的反应必须设计成不可滥用。

隔离组件

有时，开发团队希望使用与产品的目标安全级别不匹配的组件。在这种情况下，可以在具有受限的隔离环境中运行该组件。一种方法是使用内存保护单元限制内存访问，并使用抢占式调度器保证运行时间。组件中漏洞造成的损害将被限制在孤立的环境中，不会影响系统的其余部分。

安全检查表

使组件安全的第一步是确保它具有相对简单的API，该API指导用户如何正确使用它。这样的组件需要详细的、最新的文档，包括安全手册：checklist是用户必须采取的确保安全使用组件的所有步骤的清单（例如“运行此验证”，“使用这些选项进行编译”或“在此常量中插入公钥”）。

加密算法

系统的安全性很可能基于某些加密操作，用于加解密或签名和校验和的生成和验证。这些加密操作仅在以下情况下提供安全性：使用了最先进的算法，可以熟练地实施，将来可以被更安全的东西取代。

很少有人具有相应知识和思维来设计好的加密算法。在密码分析专家花了数年时间仍未破解成功之后，新的算法被认为是安全的（至少暂时如此）并公布。

安全地实现算法几乎同样棘手。有无数的障碍需要克服，从选择适当的填充方案到防止定时攻击或在正确的模式下使用加密原语。

依赖信誉良好的第三方的解决方案是一种被广泛接受的最佳实践。

系统配置

如果嵌入式设备具有影响其安全性的配置参数，则其应该具有默认的安全值。例如，密码保护接口应该具有唯一的强密码，或者在设备运行之前强制用户修改密码。

使用默认密码并要求用户更改密码是远远不够的。类似地，系统设计必须默认启用加密，而非建议用户稍后启用。

系统日志记录

记录与安全相关的事件对于安全漏洞审计和分析至关重要，但很难实现。日志的完整性和机密性是产品制造商在威胁建模中必须分析的安全资产。

对于安全漏洞分析，希望在日志中包含尽可能多的信息和细节。然而，嵌入式设备中的系统资源限制了这个决策。如果不能保证协议的机密性，很多有价值的信息会泄漏。此外，一些法律也会限制记录个人数据或要求在短时间内删除这些数据。

开发团队必须考虑的另一个方面是日志泛滥。如果攻击者做了一些生成大量日志记录的操作，那么不相关的信息可能会覆盖关键信息。

在设计安全日志记录方案时，要考虑到日志通常是设备制造商和设备所有者之间的责任案件中的证据，设备所有者可能对操纵日志感兴趣。

3. 安全的部署

实现安全系统的第三步是确保编译过的代码和源代码以及所有文档存储在安全介质上，并通过安全通道传输。在文件传输到嵌入式系统之前，攻击者可以通过修改部分设计、代码或二进制文件攻击系统。

IT环境

攻击者可以通过访问或操纵开发人员的机器、带有源代码管理系统的服务器或在传输过程中操纵软件来实现攻击。防止开发者机器和服务器被操纵的措施：

• 适当的IT权限管理

• 定期更新所有使用的软件

• 限制物理访问

• 安全策略（例如，员工不在电脑前时必须锁上电脑）

软件传输

防止软件在传输过程中被操纵的措施包括：

• 使用PGP或X.509证书建立一个安全的通信通道，对所有通信进行签名（和加密）。

• 在通过电子邮件发送信息的同时，通过不同的通道（电话、信件、加密聊天等）传递加密安全的指纹。

• 使用通过TLS、X.509证书、身份验证和授权保护的数据传输门户。

4. 主动维护

实现安全系统的第四步是确保所有组件在运行期间保持安全。

在对协议、密码学和库的研究中，随时可能发现重大漏洞，产品的最终用户必须更新其安全系统。软件组件供应商必须建立一个系统，将发现的漏洞通知所有客户。库用户必须能够接收这些信息，以便在他们的系统中创建和部署软件更新。

5. 安全更新和安全启动

实现安全系统的第五步是确保在系统上执行的所有软件的完整性和真实性，原则上可以通过下列方式：只有制造商可以安装软件，更新过程是安全的，启动过程是安全的。

如果最终用户无法更新软件，则必须禁用具有已知漏洞的系统，并用改进的设备替换。在某些情况下，这可能是一个可行的解决方案，但通常的嵌入式系统需要一种方法来安装新的固件。

如果攻击者获得对嵌入式系统的物理访问权限，就有可能操纵其固件。在这种情况下，引导过程必须是安全的。安全更新过程对启动时间没有影响，适用于大多数嵌入式系统。这两种机制都必须确保应用程序：

• 固件真实性：可信方创建了固件。

• 固件完整性：没有其他人修改固件。

• 固件版本：更新必须提供比已安装的固件更新的版本（防止回滚到易受攻击的旧版本）。

产品制造商应使用数字签名方案来验证固件的真实性。消息验证码（MAC）提供相同级别的安全性，但需要软件提供商和嵌入式设备之间共享密钥。多个设备不应使用相同的共享密钥。

该产品需要认证方案的信任根。这个信任根是一个证书或公钥，嵌入式系统可以用它来验证固件的签名。

身份验证方案通常还验证固件的完整性。

最后，引导代码必须检查软件的版本。引导代码将固件版本号存储在无法篡改的安全位置。引导代码不会安装或引导版本号较低的固件。

安全更新

在安全更新方案中，固件在接收到软件后对其进行验证，并将其存储在可信存储区域（内部flash）中。设备在后续引导中使用更新和验证过的软件。更新过程的挑战包括完整的固件通常不适合临时通信内存，攻击者可能会断开电源并阻止安全检查的执行。

安全启动

在安全引导方案中，引导代码在每次重新引导时加载并验证软件，这允许我们将软件存储在不安全的介质上（外部闪存，SD卡，网络服务器等），简化了更新过程并降低了硬件制造成本。但需要更多的内存，并且每次重新启动需要更长的时间。

引导代码仍然需要可信内存存储固件加载程序的和信任根（用于验证固件的加密密钥）。

复位后，引导代码将固件加载到RAM中，验证其真实性、完整性和版本，对其进行解密，并在RAM中执行。

如果应用程序存在允许攻击者修改引导代码的安全漏洞，那么攻击者就可以完全控制设备。有几种硬件方式可以防止这种攻击：

• 一次性可编程（OTP）引导记录锁定引导代码或信任锚的校验和。

• 硬件安全模块（HSMs）是专用的协处理器，具有更高的权限和防篡改存储。

• 带密钥存储的加密协处理器允许使用密钥（用于解密或验证），同时防止任何系统部分读取或更改密钥。

为了使用这种硬件支持，引导代码通常配备了一个三阶段的引导过程：

• 硬件验证引导管理器和信任根。

• 引导管理器验证并执行引导加载程序。

• 引导加载程序加载、验证、解密并执行应用程序。

引导加载程序和引导管理器是分开的，引导管理器尽可能简单，不太可能包含错误，只有在极少数情况下才需要更新。引导加载程序包含所有复杂的设备驱动程序和网络协议，因此它更有可能包含错误。由于不涉及硬件，所以更新引导加载程序更容易。

结论

在不断变化的威胁环境中，在设计阶段考虑产品的安全性至关重要。本文提供了对软件开发挑战的概述和见解。这些知识将帮助你从产品的规划阶段开始，在快速发展的威胁环境中确保产品的安全性和完整性。