物联网安全实施中的常见陷阱及措施

介绍

从技术的角度来看，我们生活在一个激动人心的时代。“互联生活”的梦想正在实现，许多普通产品正在配备互联网连接，以实现这个便利的新世界。但是，互联网可能是一个危险的地方，保护这些新连接的产品免受威胁至关重要。否则，这种无与伦比的便利性可能会变成一场噩梦。作为系统设计人员，我们有责任成为解决方案的一部分，以取悦我们的最终用户，并成为他们数据的好管家，让您高枕无忧。

物联网 （IoT） 产品开发的挑战之一是安全性很困难。安全产品必须防御所有可能的攻击，但攻击者只需要找到一个薄弱环节即可利用系统。它们还具有时间优势：攻击总是变得更好，而不是更糟，计算能力，工具和如何使用它们的知识变得越来越便宜和广泛。此外，成本、上市时间、尺寸和客户便利性等标准压力导致许多设计人员快速、便捷地实施安全规定，或者只是不正确或不完整的安全规定。

本文特别关注小型无线连接系统，这些系统通常由电池供电并运行轻量级、低带宽射频协议，如低功耗蓝牙 （LE）、蓝牙网状网络、Zigbee、螺纹、Z 波、LoRa 或专有 ISM 频段协议。这里介绍的大多数挑战和解决方案也常见于大型系统（智能手机，笔记本电脑等）。

弹性设计

在详细了解可能出错的地方之前，计划一些事情会出错是有帮助的：漏洞和错误将被发现并需要解决。为系统预配安全的固件更新机制，最好是使用签名、加密和版本化的升级包以及具有回滚保护的更新管理器。此外，使用硬件信任根预配安全启动，以确保只有授权代码才能在您的产品上运行。

不要制作自己的安全协议

当面临安全需求时，再加上潜在的有限设备资源（代码空间、电池寿命、缺乏加密加速器）和有限的时间，许多嵌入式设计人员选择设计自己的安全协议，而不是采用合适的行业验证解决方案来满足安全要求。不幸的是，很容易提出一个看起来牢不可破的系统，并且识别这种设计中的缺陷更具挑战性。

创建安全连接需要验证链接远程端的真实性，对消息进行加密，并验证通过链接传递的消息的完整性和真实性。

Web 浏览器用于保护用户与其银行之间的“https：”连接的传输层安全性 （TLS） 会话可满足所有这些安全要求。银行网站的真实性通过使用基于证书的公钥加密来解决;机密性是使用对称密码学实现的;并且完整性由消息身份验证代码解决。

在小型嵌入式处理器上建立TLS连接似乎有些过分。幸运的是，还有其他重量较轻的既定标准，例如DTLS（在 Thread 中使用），可以采用这些标准。

管理设备真实性的最灵活的工具之一是 X.509 证书与公钥基础结构 （PKI） 相结合。这允许使用与上述银行网站示例相同的加密工具和方法对设备进行身份验证。该证书包含一些特定于设备的信息，例如唯一 ID、有效期、加密算法信息以及公司名称和其他数据。该证书由公司的私钥（受到强烈保护）签名，但可以通过任何人都可以访问的公钥进行验证。此外，如果设备或私钥遭到破坏，则可以吊销证书或证书系列，从而限制损坏范围。

将独特的设备证书注入产品或设备可能看起来很麻烦或昂贵，但由于物联网的高需求和普遍需求，许多MCU和SoC供应商，分销商和第三方以适度的成本提供这些功能作为其设备定制和预编程服务的一部分。

大多数基于标准的射频协议，如蓝牙、Zigbee、螺纹和Z-Wave，已经规定或至少推荐了建立安全认证链路的方法。所有这些协议都提供了一种建立机密传输通道的方法，设计人员绝对应该利用该协议提供的安全功能。某些设计人员可能希望在传输层之上添加其他安全性，以提供身份验证支持或应用程序级加密。

常见漏洞

2014年，麻省理工学院的研究人员调查了2011年至2014年间常见漏洞和披露（CVE）数据库中记录的最常见漏洞。他们对加密库和应用程序之间的漏洞来源进行了分类。有趣的是，只有17%的加密漏洞是在加密库中发现的，而大部分漏洞（83%）是在错误使用库的应用程序中发现的。最小化漏洞暴露的一种方法是选择正确的加密库。没有一个库是完全没有漏洞或错误的;但是，一个开源的、积极维护的库，其维护者遵循漏洞披露的最佳实践，可能是一个良好的开端。mbed TLS 库就是这样一个例子，它也针对资源受限的物联网系统进行了优化。

审核编辑：郭婷