医疗物联网需要重视无线连接的安全问题
物联网 (IoT) 为连接设备带来了新的应用。制造商正在超越耳机和键盘。其中一个新用例尤其突出：应用程序较少依赖连续流，而是定期中继少量数据。在远程外围设备正在传递有关其周围环境的信息的传感器应用中尤其如此，例如恒温器、安全传感器或医疗监控设备。同时，蓝牙标准的进步使这些新应用成为可能。
经典蓝牙和低功耗蓝牙简史
蓝牙最初的规范自 1998 年就已经存在，第一款免提耳机于 1999 年出现在市场上。从那时起，它就被用于连接从电脑鼠标和键盘到便携式扬声器和耳机的所有东西。现在被称为经典蓝牙的标准，可覆盖 79 个通道，在 50 米范围内传输高达 3Mb/s 的速度，这使其可用于数据传输、流式音频以及与其他智能手机共享图片等。
虽然许多使用蓝牙经典的设备都是电池供电的（至少是外围设备），但电源从来都不是问题——因为这些组件的设计便于充电和更换电池。如果您的电脑鼠标的电池只使用了几天也没关系，您可以插入充电电缆或更换电池。
此后出现了一种新标准，即低功耗蓝牙 (BLE)，以支持较低的带宽速率，范围从 125 Kb/s 到 2 Mb/s，除了经典蓝牙所面向连接模式之外，还包括一种新的无连接模式。BLE 最大的进步是它节省电力，可以为设备供电更长时间。默认情况下，BLE 外设会休眠，直到它们准备好传输数据。结合以较低数据速率传输期间的较低功耗，BLE 设备的功耗通常仅为使用蓝牙经典设备的 1-5%。它们的功耗在 15-20 微安之间，这意味着标准纽扣电池可以为大多数 BLE 设备供电多年。
重塑医疗物联网
合理的数据传输速率加上低功耗使 BLE 设备对消费类应用（例如耳机和恒温器）具有吸引力，但这只是故事的一部分。这些相同的属性也使 BLE 成为连接医疗设备的理想选择——也称为医疗物联网 (IoMT)。例如，血糖监测仪可以使用 BLE 将血糖水平传送到智能手机，以便于监测。在医院环境中，附在设备上的廉价 BLE 标签可以使库存跟踪和定位变得更加容易。此外，BLE 对大量连接外围设备的支持使其在可能涉及数百（或数千）连接医疗设备的临床或医院环境中更具价值。例如，想想护士的监测站。借助 BLE，您可以让所有楼层的 ECG 和其他患者监护设备将遥测信息中继到一个中心位置。与健康相关的可穿戴设备（例如心脏监测器和健身手表）的想法相同——所有这些设备都通过 BLE 中继信息。
免除电缆、笨重的电池并启用智能手机通信是向前迈出的一大步。但与任何创新一样，也存在不可避免的风险。就医疗设备而言，这些风险不仅会导致音频质量下降或电池寿命下降等不便。对于 IoMT，设备安全风险会直接危及患者安全。
医疗物联网中的网络安全
对于连接的医疗设备，网络攻击是对患者安全的巨大威胁。例如，对 BLE 无线电接口的攻击可能会干扰 IoMT 设备的基本性能——这可能会伤害或可能杀死患者。类似这样的多个漏洞已经在支持蓝牙的医疗设备中被发现，导致广泛宣传的披露、强制缓解和设备召回。影响最大的例子之一是 SweynTooth 漏洞，它影响了许多 BLE IoMT 设备。影响是如此严重，以至于 FDA 向医疗设备制造商发布了一份安全通信，警告如果触发其中一个漏洞会带来危险——这可能导致设备崩溃、死锁和冻结，甚至使攻击者能够绕过其安全保障措施.
SweynTooth（以及其他类似漏洞）的最大教训是它让制造商意识到供应链中的上游漏洞。尽管漏洞令人担忧，但医疗设备制造商并未编写有缺陷的代码。事实上，他们并不知道他们的存在。他们只是从值得信赖的知名电子公司采购了蓝牙片上系统SoC，并将其应用在他们的设备中。SoC 提供了漏洞，在产品发货之前根本没有进行足够的安全测试，这使得它们所包含的每个系统都处于危险之中。
通过协议模糊测试发现隐藏的漏洞
SweynTooth 漏洞影响了多家经验丰富的制造商，包括德州仪器、恩智浦、赛普拉斯、Dialog Semiconductors、Microchip、STMicroelectronics 和 Telink Semiconductor。这么多不同的制造商是如何受到影响的？问题是这些漏洞隐藏在协议栈中，使得检测和诊断变得异常困难。虽然安全社区已经开发了一系列用于发现应用程序级漏洞的最佳实践——包括可以与应用程序软件和库交叉检查的威胁库的常见策略和数据库——但协议级漏洞更难查明。事实上，只有一种方法可以充分测试这类漏洞：一种称为协议模糊测试的详尽测试机制。
通俗地说，协议模糊测试将各种错误注入到通信交换中，以混淆连接另一端的实体并将其置于不正确的状态。这可能涉及相当简单的错误，例如发送数据包的多个副本，或者可能导致更复杂的协议损坏。这里有一些例子：
· 可以在单个数据包中设置指示连接开始和结束的标志。
· 数据包中的字段可能太大或太小。
· 数据包中的字段可以设置为无效值。
· 数据包可以乱序发送。
在许多情况下，在连接开始时发生的“握手”以建立安全性、加密和其他通信参数，是很容易被利用的目标。由于远程设备根据握手期间建立的设置进行自我配置，因此特别损坏的数据包（或数据包序列）可能导致关闭或通信错误，需要手动重置。
在最坏的情况下，攻击者可以针对握手本身，如 CVE-2019-19194 中所述。由于握手建立了安全和加密参数，攻击者可以绕过通常会限制某些操作并启用系统任意控制的控制。特别是对于物联网设备，这可能会产生明显的灾难性影响。攻击者可以指示设备报告不正确的遥测数据，忽略其他命令，通过向未经授权的系统报告数据来违反患者隐私规则，甚至管理可能致命的药物剂量。
保护支持 BLE 的 IoMT 设备中的协议级漏洞
显然，这种类型的漏洞是医疗设备制造商的一个严重问题——正如 FDA 在美国的关注和全球类似的监管审查所反映的那样。但是保护连接设备的最佳方法是什么？对于初学者来说，这意味着实施验证和验证策略来识别 SoC 协议栈中的漏洞。制造商需要充当最后一道防线。毕竟，他们负责将受影响设备的警告通信、缓解策略和修复固件更新快速分发给患者和护理提供者。而且，如上例所述，即使是资源最充足的供应商也不能幸免于提供易受攻击的芯片组。
然而，安全是一个旅程，而不是一个目的地。这就是为什么设备制造商至少必须坚持在产品发布之前从芯片组供应商那里得到补救更新。同时，他们还必须自己承担对他们的设备进行广泛的协议模糊评估——同时在 FDA 上市前许可提交中包括他们的验证和验证策略。
随着 IoMT 设备的 BLE 连接变得越来越普遍，协议模糊验证对于维护患者安全和对先进技术的信任将变得更加重要。幸运的是，fuzzing协议工具包变得更加广泛可用和更容易使用——即使对于在网络安全方面几乎没有经验的质量控制团队也是如此。考虑到芯片组供应商彻底复制、诊断、修复和验证漏洞可能需要时间，现在是时候开始测试开发中的产品了。只需要看一下 SweynTooth，就会发现越晚发现漏洞，修复的成本就越高。
