智能家居应用程序框架权限模型的安全影响

主要结论

• 作为诸如苹果 HomeKit、三星 SmartThings 等智能家居编程框架的关键组件，权限模型针对远程攻击提供了第一道防线。
• 通过对苹果 HomeKit、IoTivity、AllJoyn，以及 SmartThings 四大智能家居框架进行调查发现，它们在权限模型方面采取了从“全有或全无（All-or-nothing）”到非常细化的控制等不同方式。
• 全有或全无是一种过高特权的极端案例，会让所有应用针对所有设备获得相同特权，但就算非常细化的控制方式，依然存在过高特权的情况。
• 针对现有 499 款 SmartThings 应用，即所谓的 SmartApp 进行分析发现，其中 55% 并未用到所申请的全部特权，其中 42% 获得了并未明确申请的特权。
• 过高特权的应用会使得将 PIN 码注入上锁的门锁、嗅探 PIN 码、禁用度假模式，甚至谎报火警等远程攻击有机可乘。

本文首发于 IEEE Software 杂志。 IEEE Software 针对当今世界的主要战略性技术问题提供了坚实的同行审阅信息。为了应对企业在可靠性、灵活性等方面提出的挑战，IT 经理和技术主管必须依赖 IT 专业人员才能获得最先进的解决方案。

通过分析主流编程框架发现，很多智能家居应用会自动获得过高特权，导致用户面临远程攻击风险，进而导致人身、财物，以及心理伤害。

智能家居技术已远远不局限于为我们提供便利，例如自动控制灯光和开门器，而是可以提供更切实的收益。例如通过水流传感器和智能仪表提高能源效率，配合使用网络摄像头、运动传感器以及可联网门锁更好地保护住宅安全。然而攻击者也可以借助智能设备造成用户人身、财物，以及心理方面的伤害。例如窃贼可能向智能门锁植入隐藏的访问代码 [1]。

早期的智能家居系统非常难用，需要通过复杂的操作进行配置，因此往往只被一些热衷于 DIY 的发烧友所接受（甚至有很多论坛供大家讨论相关知识，例如这个）。近年来，很多公司引入了更易用的云系统，帮助用户轻松上手和使用，同时还为第三方开发者提供了编程框架，方便大家构建智能家居应用。例如三星 SmartThings 、苹果HomeKit 、Vera Control 的 Vera3 、谷歌 Weave /Brillo，以及 AllSeen 联盟的 AllJoyn （包含高通、微软、LG、思科以及 AT&T）。

我们希望了解此类智能家居编程框架中一个重要组件：权限模型可能造成的安全影响。这些模型可限制第三方应用为用户及其设备造成的风险。我们首先调查了苹果 HomeKit、IoTivity、AllJoyn，以及 SmartThings 的安全模型，随后深入分析了 SmartThings 框架 [2]。

智能家居权限模型

在调查现有智能家居框架的权限模型时，我们发现它们在访问控制方面的细化程度各异，从全有或全无到非常细化，情况不一而足。

HomeKit 是一个框架，同时包含一组协议，可以让智能家居设备与 iOS 设备和应用安全地通信。第一和第三方开发者可以为 HomeKit 外设开发应用，而第一方应用通常由设备制造商开发。

HomeKit 会用HMAccessory对象代表物理设备，并向对象暴露出HMService类。例如，“外设”可以是一个车库开门器，并可能提供下列服务：照明和开关。服务所具备的特征可被应用操作，进而产生外设或设备状态的物理变化。例如，“开关”服务可能有“开 / 关”特征，分别对应车库门开启和关闭两个状态。iOS 应用以家庭为单位获得对这些外设的访问，也就是说，或者可以访问一个家庭的所有外设，或者全部不能访问。必须经过用户允许，随后应用才能访问 HomeKit 数据，这一点类似于 iOS 上允许或拒绝应用访问联系人和照片等操作的过程 [3]。以家为单位的粒度意味着所有应用都能自动获得过高特权。

IoTivity 是一个开源框架，由 Open Connectivity Foundation（OCF）赞助，该基金会成员包括微软、英特尔、三星、高通 [4]。IoTivity 的目标是打造一个开源参考实现的 OCF 物联网标准，促进物联网设备之间，以及设备与互联网的通信。

IoTivity 默认并不包含安全功能。为了实现安全功能，须在编译时设置SECURED=1标记。开启该标记后，承载资源的 IoTivity 服务器（即设备）可在创建时分配OC_SECURE属性，借此实现访问控制机制。这种访问控制仅能通过设备 ID 对希望与资源通信的设备进行粗粒度的写入和读取权限控制。权限会在添加设备时设置，随后可由用户按需更改。若要在开启安全功能的情况下向网络中添加设备，IoTivity 支持三种协议：

• just work，会在首次通信时建立一个共享密钥；
• random PIN，需要通过带外（Off-band）PIN 码建立信任关系；以及
• asymmetric key，基于自签名或制造商的密钥。

在安全模式下，可通过数据报 TLS（DTLS）保护安全资源之间的通信。

AllJoyn 是一种开放式标准，可以让不同物理设备和应用通过统一方式通信。该标准为设备制造商和应用开发者提供了必须使用的通信协议和软件库，软件库可在多种硬件上运行。AllJoyn 采取了一种分布式架构，没有中央控制器或中枢（Hub），采用公钥算法保护通信并定义访问控制策略。

按照 AllJoyn 的定义，软件应用或物理设备统称为“应用”。应用可暴露包含多个成员（Member）的接口，例如门锁可以在提供控制接口的同时，提供加锁和解锁两个成员。一个应用可通过其他应用使用这样的接口。例如，自动门锁应用可使用门锁的控制接口。AllJoyn 已对一些设备类型实现了标准化的接口定义，如照明和空调系统。

应用是一种安全主体，具备相关联的身份证书，证书包含可被所有应用信任的证书颁发机构提供的签名。AllJoyn 安全管理器组件可通过 AllJoyn 协议通信，向应用颁发身份证书。管理者（如住宅或建筑物的所有者）负责操作安全管理器组件。

AllJoyn 提供了灵活细化的访问控制机制，最细可到成员层面。然而建议使用的访问控制仅适用于接口层面。因此每个 AllJoyn 应用（纯软件或物理设备）必须创建清单模板，其中列出应用可提供的接口，以及将要使用的接口。这个清单模板代表了应用的权限请求，类似于智能手机应用针对敏感资源进行的权限请求。安装过程中，管理员可使用安全管理器为应用创建最终版清单，并将最终版清单的摘要包含在身份证书中。这一配置过程类似于智能手机的所有者批准应用的权限申请过程。随后安全管理器会在目标应用中安装该清单以及身份证书。

运行过程中，当消费者应用希望调用提供者应用提供的接口时，提供者应用会读取身份证书，验证证书（以及相应的证书链），验证清单摘要，最后检查该消费者是否可以访问提供者的接口。

SmartThings 提供了一个中枢以及云后端。第三方开发者编写的 SmartApp 可在云后端运行。SmartThings 框架必须确保 SmartApp 只具备完成所需功能必须的特权，因此 SmartThings 提供了一种安全架构：SmartThings 能力（Capability）模型，该架构决定了某个 SmartApp 可访问哪些设备。能力包含一系列命令（方法调用）和特性（属性）。命令代表可控制或驱动设备的具体方式，特性代表了设备的状态信息。表 1 列出了一些能力。设备可暴露一系列能力，例如智能门锁可暴露capability.lock和capability.battery。

SmartApp 必须向用户申请能力。当用户安装某个 SmartApp 时，所申请的能力会触发一个设备枚举进程，扫描当前与用户中枢配对的所有物理设备。对于每个能力请求，用户可看到所有能支持这个能力的设备。用户选择了暴露某一能力的特定设备后，SmartApp 便获得了对该设备的访问。SmartApp 可通过事件与设备交互，尤其是 SmartApp 可在设备上针对某种条件注册回调（Callback），当条件满足后，SmartApp 会收到回调，其中还会包含一些可选事件数据。应用提供了种类多样的功能，从基于规则的自动化（“如果门锁打开，那么就开灯”）到能耗监控和节约等。

为何选择 SmartThings？

我们选择深入分析 SmartThings 的原因有很多。首先，这是一个相对更成熟的平台，应用（名为 SmartApp）的数量飞速增加，目前已经可以支持 132 类设备。

其次，SmartThings 与其他框架采用了一些相同的重要安全设计准则。设备访问的身份验证和授权是确保智能家居应用平台安全性的基本要素，SmartThings 可通过内建机制保护设备防范第三方应用通过所谓“能力”进行攻击。

事件驱动的处理方式在智能家居应用中极为常见 [5]，SmartThings 可以让应用针对设备生成的特定事件流注册回调。其他平台也支持事件驱动的处理。例如，AllJoyn 可支持总线信号 [6]，HomeKit 提供了类似于通知 API 的机制 [7]。因此我们认为，对 SmartThings 权限模型分析得出的结论也能对其他可编程智能家居框架在前期设计阶段的工作提供一定的帮助。

最主要的发现在于：特权过高是 SmartThings 权限模型最大的不足。尤其是，我们发现分析的 499 个 SmartApp 应用中大量存在权限过高问题：55% 并未用到所请求的全部权限，42% 获得了并未明确申请或使用的能力。很多情况下，由于能力模型采用了设备层面的授权机制，特权过高问题是无法避免的，而这也不是开发者本身的问题。令人担忧的是，我们发现 68 个现有 SmartApp 会使用过高的特权，在未申请相应能力的情况下提供额外的功能。

为了证明这种情况可能导致的负面影响，我们通过高特权尝试攻击。我们的攻击可将 PIN 码注入可联网门锁，嗅探 PIN 码，禁用度假模式，产生虚假火警警报。

由于攻击的存在，必须慎重设计权限模型，并对应用使用敏感数据的方式进行更严格的控制。然而这一点通常很难实现。易用性与权限模型的细化程度之间存在与生俱来的矛盾，这一领域也是如此。模型设计方面存在的问题会导致智能家居安全疏漏，如果将其与智能手机以及其他周边领域在权限模型设计方面取得的进展相结合，将有助于进一步改善安全性。

SmartThings 深度分析

我们通过两个方向分析了 SmartThings 权限模型的安全性：最小特权，以及敏感事件的数据保护。在研究过权限模型并广泛测试 SmartApp 原型后，我们针对潜在安全问题创建了一个清单。

最小特权原则的遵守情况

能力模型能否保护设备上的敏感操作防范不可信或可信但存在 Bug 的 SmartApp？重点在于确保 SmartApp 只申请所需特权，并且只批准申请过的特权。然而我们发现很多 SmartApp 存在特权过高问题。

敏感事件数据的保护

对于设备生成的敏感事件数据，会通过哪种访问控制方法保护防范不可信或可信但存在 Bug 的 SmartApp？我们发现未经授权的 SmartApp 可以窃听敏感事件。

SmartApp 中存在的特权过高问题

我们发现 SmartThings 框架存在两个重要的特权过高问题，这些问题均源自其能力的设计和实施方法。首先，SmartThings 框架中的能力是粗粒度的，可用于访问设备上的多种命令和特性。因此 SmartApp 有权调用设备上的各种命令，哪怕并不是自己需要的。其次，由于 SmartApp 框架会将 SmartApp 与设备绑定，应用最终可能得到自己请求范围之外的能力。下文将详细介绍这两种情况。

粗粒度能力。在 SmartThings 框架中，“能力”定义了一系列命令和特性，以capability.lock为例：

• 相关的命令：lock和unlock。
• 相关的特性：lock特性的名称与命令名称一致，但特性代表了设备的解锁或锁定状态。

对 SmartThings 架构定义的现有能力进行调查发现，很多能力的粒度太粗了。例如 SmartThings 应用商店提供的自动门锁 SmartApp 中，capability.lock能力只需要使用lock命令，但依然可以访问unlock命令，如果 SmartApp 被利用，有可能增大攻击面。如果lock命令被滥用，SmartApp 可能会将获得授权的房主锁在门外，造成不便；然而如果unlock命令被滥用，SmartApp 可能导致房屋被非法闯入。设备命令与风险间通常存在不对称现象，例如开启烤箱可能是危险的，而关闭烤箱相对来说是安全的。因此自动允许 SmartApp 访问不安全的命令，而该应用原本只需要访问安全的命令，这种做法很不合适。

为了对由于粗粒度能力导致的权限过高问题进行简单量化，我们基于静态分析和人工检查，对每个有特权的 SmartApp 进行了下列计算：{所请求的命令和特性} - {实际使用的命令和特性}。理想情况下，大部分应用的计算结果应该是“零”，然而在对 499 个 SmartApp 进行的分析中，发现 276 个应用由于粗粒度能力而存在权限过高问题。

SmartApp 与 SmartDevice 间的粗粒度绑定。用户安装 SmartApp 时，SmartThings 平台会根据应用preferences设置中声明的能力，枚举所有可支持这些能力的物理设备，随后用户可选择一组设备并授权给 SmartApp。然而用户并不知道具体请求了哪些能力，只能看到一个设备清单，清单中列出了所有至少具备一个所请求能力的设备。更重要的是，一旦用户选择授权 SmartApp 使用的设备，SmartApp 将能访问所选设备能够实现的全部能力所涉及的全部命令和特性。同时我们发现，开发者根本无法避免这种特权过高问题，因为这是 SmartThings 框架自身的设计导致的。

具体来说，SmartDevice 可供我们访问相应的物理设备。除了管理物理设备并理解底层协议，每个 SmartDevice 还会针对自己管理的设备暴露一组能力。例如，默认的 Z-Wave 门锁 SmartDevice 支持下列能力：capability.actuator、capability.lock、capability.polling、capability.refresh、capability.sensor、capability.lockCodes，以及 capability.battery。

这些能力对应着门锁运作过程的不同方面。假设这样的情况：某个 SmartApp 请求了capability.battery，例如它想要监视门锁的电池状态。SmartThings 框架会要求用户授权访问 Z-Wave 锁设备（因为该设备与所请求的能力相匹配）。然而如果用户允许该授权请求，SmartApp 除了能访问所请求的能力，还将能访问 Z-Wave 锁定义的其他所有能力，例如这个 SmartApp 将能对 Z-Wave 上锁或解锁，读取状态，设置锁密码。

为了对由于批准了不必要的能力造成的权限过高问题进行简单量化，我们基于静态分析和人工检查，对每个有特权的 SmartApp 进行了下列计算：{所批准的能力} - {实际使用的能力}。理想情况下，大部分应用的计算结果应该是“零”，然而在对 499 个 SmartApp 进行的分析中，发现 213 个应用由于额外获得了不必要的能力而存在权限过高问题。

敏感事件数据保护能力的缺乏

SmartThings 支持回调，借此 SmartDevice 可生成包含特性数据的事件，SmartApp 可注册此类事件。用户家里每个 SmartDevice 与中枢配对时会获得一个 128 位设备标识符。除非将设备从中枢中删除或重新配对，否则该设备标识符将保持固定不变。因此这个 128 位设备标识符在用户家庭范围内是唯一的，这样也可以确保一个家庭里的 128 位设备标识符无法在另一个家庭中使用。然而我们发现事件访问方式控制方面存在极大漏洞：

• 一旦某个 SmartApp 请求能力后被获准访问某个 SmartDevice，SmartApp 将能监视该 SmartDevice 发布的任何事件数据。SmartThings 框架并未提供任何特殊的机制让 SmartDevice 能够选择性地将事件数据发送给部分 SmartApp，或让用户将 SmartApp 的访问限制在部分事件的范围内。
• 一旦某个 SmartApp 为某个 SmartDevice 获取了 128 位标识符，即可监视该 SmartDevice 的所有事件，而无须针对该设备所支持的任何能力获得许可。
• 某些事件可以篡改。尤其是，我们发现任何 SmartApp 或 SmartDevice 都可以篡改与位置有关，或与设备自身有关的事件。

基于能力的访问导致事件外泄。如上文所述，一旦用户批准了某 SmartApp 访问某 SmartDevice 所支持的任何能力，SmartThings 框架将允许该 SmartApp 订阅这个 SmartDevice 的所有事件。我们发现 SmartDevice 会大量使用事件传输敏感数据，例如 SmartThings 提供的 Z-Wave 门锁 SmartDevice 会传输包含门锁密码的codeReport事件。

能以任何方式访问 Z-Wave 锁 SmartDevice 的 SmartApp（例如监视设备电池状态的应用），均可自动监视设备的所有事件，并通过这种方式将事件记录至远程服务器，借此将能盗取门锁密码。SmartApp 还可用于在进门和出门过程中记录门锁状态代码，借此可以追踪房主的活动情况，这有可能威胁到个人隐私。

SmartDevice 标识符导致的事件外泄。上文曾经提到，用户家里每个 SmartDevice 都会随机分配一个 128 位标识符。然而这个标识符并不能向 SmartApp 隐藏。一旦某个 SmartApp 获得授权能与某个 SmartDevice 通信，即可读取device.id值获知这个 128 位 SmartDevice 标识符。我们发现有恶意 SmartApp 可直接使用该标识符读取其他设备生成的任何事件，完全不受能力请求的限制。

不幸的是，设备标识符很容易便可在不同 SmartApp 之间交换，标识符对设备的处理程序完全是透明的，与具体 SmartApp 也完全没有关系。目前 SmartThings 应用商店中已经有好几个 SmartApp 可以通过 OAuth 协议远程获取用户家中设备的标识符。

事件篡改。SmartThings 框架既没有针对所生成的事件强制实施访问控制机制，也没有提供触发 SmartApp 验证事件完整性或来源的方法。我们发现有个无特权 SmartApp 可以同时篡改物理设备以及与位置有关的事件。

SmartDevice 在检测到设备物理状态的变化后，会产生相应事件。例如烟雾检测器 SmartDevice 会在检测到周围存在烟雾后发出“有烟”事件。事件对象包含多种状态信息，外加一个位置标识符，一个中枢标识符，以及代表事件来源的 128 位设备标识符。我们发现攻击者可以通过正确的标识符创建非法事件对象，并在其中放入任何状态信息。如果出现此类事件，SmartThings 会将事件传播到所有订阅过的 SmartApp，就好像 SmartDevice 自己触发了这个事件一样。标识符可以轻易获取，而中枢和位置 ID 会自动对所有 SmartApp 可用。

简而言之，SmartThings 事件子系统在设计方面很不安全。SmartDevice 大量使用这种方式发布状态和敏感数据，我们数据集中的 132 个设备处理程序，有 111 个会引发这样的事件（参阅脚注 2）。

概念验证攻击

我们通过四次攻击证明了特权过高这一设计方面的问题如何影响到住宅安全性。我们将特权过高问题与 SmartThings 框架中有关安全设计的其他瑕疵结合在一起，暗地里进行了远程攻击。有关其他设计漏洞的详情，请参阅脚注 2 中提到的“Security Analysis of Emerging Smart Home Applications”。

表 2 总结了针对 SmartThings 权限模型设计疏漏进行的四次攻击。后门 PIN 码注入攻击通过粗粒度 SmartApp-SmartDevice 绑定特权过高问题，强制通过现有 SmartApp 将 PIN 码写入门锁。过高的特权使得攻击者可以通过编程方式将 PIN 码注入 SmartApp。门锁 PIN 码嗅探攻击则通过悄悄运行的恶意应用，使用 SmartThings 事件系统特权过高问题，在创建 PIN 码的同时进行嗅探并顺利外泄。由于对位置对象缺乏访问控制，可以欺骗 SmartApp 认为家里有人，进而通过攻击禁用度假模式。最后，假火警攻击使用恶意应用窃取设备标识符提升自己的特权，生成虚假的一氧化碳传感器读数，进而顺利完成。

表 2：针对 SmartThings 的四次概念验证攻击

攻击描述

攻击途径

对现实世界的影响

后门 PIN 码注入 1. 将命令注入现有的 Web 服务 SmartApp；
2. 通过 SmartApp 与 SmartDevice 之间的粗粒度绑定提升特权；
3. 使用现有库中硬编码的密文窃取 OAuth 令牌；
4. 诱骗受害人点击指向 SmartThings 网站的链接

导致物理进入，盗窃 门锁 PIN 码嗅探 1. 后台运行的攻击应用请求监视电池电量所需的能力，诱骗受害人安装该攻击用应用；
2. 窃听事件数据；
3. 通过 SmartApp 与 SmartDevice 之间的粗粒度绑定提升特权；
4. 使用不受限制的短消息服务泄露敏感数据

导致物理进入，盗窃 禁用度假模式 1. 编写不具备具体能力的攻击用应用；
2. 诱骗受害人安装攻击用应用 ;
3. 滥用正常 SmartApp 的逻辑；
4. 编造事件

导致盗窃，破坏行为 假火警 1. 编写不具备具体能力的攻击用应用；
2. 诱骗受害人安装攻击用应用；
3. 编造物理设备事件；
4. 在不具备相应能力的情况下控制设备；
5. 滥用正常 SmartApp 的逻辑

导致信息误导，扰民预计到 2020 年，物联网规模将发展至包含 208 亿可联网设备，消费者市场将迎来最大安装量 [8]。同时我们发现可编程框架陆续涌现，这些技术可将原本相互独立的设备统一到一个可支持第三方应用的平台。虽然第三方应用能更好地发挥网络化智能设备的作用，但也蕴含一定的技术风险。本文中，我们研究了四种新框架（IoTivity、HomeKit、AllJoyn，以及 SmartThings）的权限模型，因为权限模型往往是用户的隐私数据和物理设备，以及攻击者之间的第一道防线。安全设计存在瑕疵的权限模型容易造成各种类型的攻击。我们的结论主要强调需要对安全模型，以及应用获得访问之后对数据的使用方式进行更深入的研究 [9]。

希望有关 SmartThings 的分析可以提醒 SmartThings 开发者着手设计实现能够减少自动获得过高特权这一问题的技术，并在能力的粒度和易用性之间进行更全面的权衡。作为第一道防线，SmartThings 团队应修订自己的应用审阅指南，参照我们进行攻击的方式手工检查高特权的使用和滥用情况。如果希望进一步增强防御机制，SmartThings 还需要修订开发者文档，提供与安全有关的最佳实践。例如指导开发者针对自己订阅的事件进行演练，除非有明确且慎重的声明，否则尽量不要使用 Groovy 动态方法执行，借此确保不会被执行非预期操作，进而防止远程攻击者滥用过高的特权 [10]。

关于本书作者

Earlence Fernandes正在美国密歇根大学（University of Michigan）读博，他的研究主要围绕可以提高物联网平台安全性的技术，包括构建安全系统、寻找设计漏洞、进行大规模测量等。他的联系方式：earlence@umich.edu。

Amir Rahmati正在美国密歇根大学读博，他的研究主要围绕提高新兴技术，资源有限设备（例如嵌入式设备和物联网设备）的安全性。Rahmati 在密歇根大学获得了计算机科学和工程专业的软件工程硕士学位，他的联系方式：rahmati@umich.edu。

Jaeyeon Jung是三星云平台部门的副总裁，她的研究主要围绕消费者隐私保护新技术的开发，尤其是移动系统和新兴的智能家居领域。她的联系方式：jae.jung@samsung.com。

Atul Prakash是密歇根大学计算机科学系教授，他的研究主要围绕安全和隐私、网络 - 现实系统、借助计算机进行的协作，以及分布式系统。他的联系方式：aprakash@umich.edu。

作者： Earlence Fernandes 、 Amir Rahm 、 Jaeyeon Jung 、 Atul Prakash ，阅读英文原文： Security Implications of Permission Models in Smart-Home Application Frameworks

1. T. Denning, T. Kohno, and H.M. Levy, “Computer Security and the Modern Home”, Comm. ACM, vol. 56, no. 1, 2013, pp. 94–103.
2. E. Fernandes, J. Jung, and A. Prakash, “ Security Analysis of Emerging Smart Home Applications ”, Proc. 37th IEEE Symp. Security and Privacy, 2016;
3. “ iOS Security Guide ”, Apple, May 2016;
4. “Open Connectivity Foundation”, IoTivity , 2016;
5. B. Ur et al., “Practical Trigger-Action Programming in the Smart Home”, Proc. SIGCHI Conf. Human Factors in Computing Systems (CHI 14), 2014, pp. 803–812.
6. “ Documentation: Data Exchange ”, AllSeen Alliance;
7. “ HMCharacteristic ”, Apple, 2017;
8. “ Gartner Says 6.4 Billion Connected ‘Things’ Will Be in Use in 2016, Up 30 Percent from 2015 ”, Gartner, 10 Nov. 2015;
9. E. Fernandes et al., “Flowfence: Practical Data Protection for Emerging IoT Application Frameworks”, Proc. 25th USENIX Security Symp. (USENIX Security 16), 2016, pp. 531–548.
10. “ Code Review Guidelines and Best Practices: Security Considerations ”, SmartThings Developer Documentation, 2016;