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

开发 架构与设计 移动 物联网 智能家居

摘要：

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

正文：

主要结论

• 作为诸如苹果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的四次概念验证攻击

预计到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