cpegg's home

SmartAuth: User-Centered Authorization for the Internet of Things

 
  • Apr 04, 2018

SmartAuth: User-Centered Authorization for the Internet of Things(USENIX’17) 论文笔记

#SmartAuth: User-Centered Authorization for the Internet of Things(USENIX’17) 原文链接：https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tian.pdf 作者： Yuan Tian1, Nan Zhang2, Yueh-Hsun Lin3, XiaoFeng Wang2, Blase Ur4, XianZheng Guo1 and Patrick Tague1 单位： 1Carnegie Mellon University 2Indiana University Bloomington 3Samsung 4University of Chicago

Abstract

IoT平台通常需要用户给第三方APP以权限，但是由于用户的不熟悉，常常导致恶意程序的过度权限。为了满足IoT环境中的一些诸如跨设备、环境影响、自动操作等的影响，本文作者们设计了以用户为中心的、基于语义的“智能”验证系统SmartAuth。通过分析app的描述、代码和注释，能够帮助用户更好的理解系统需要的功能和系统实际会进行的操作之间的关系。 作者发明了一种利用自然语言处理和程序分析的方法来分析设备环境和活动语义之间的技术。同时实验也证明用户可以通过SmartAuth来更大可能避免过度权限的问题。

Intro

IoT使得家庭自动化的概念愈发成熟。很多成熟的系统整合了云架构、家庭IoT设备（从传感器到大型应用），允许用户执行较为==复杂的指令== 然而和普通的移动APP不同，IoT的应用能够控制一些带有潜在的安全威胁的设备（如门锁等） 最近对Samsung的智能设备分析为IoT带来了一点点不安，主要是由于framework下的不充分防护，而这中间最重要的就是在SmartApp验证时的过度权限问题。

  • 一些不清晰的验证说明常常有粗糙的粒度和对环境的忽视，即：如一个APP如果被授予了一个设备的某些权限，那么它同时也可能可以实现对这个设备的其他一些功能。
  • 同时，APP可能也会尝试去获得一些它根本不需要、甚至是很危险的功能。尽管有些APP有权限询问，但是大量用户常常搞不清楚、或者根本选错。
  • 而更糟糕的是，与安卓的权限模型不同，安卓手机上常常会有对一些资源的访问控制，但是这在家庭环境当中也显得==更为复杂==。因此不光向用户解释这些操作很麻烦，同时在给予权限之后对权限使用的监管也是相当的复杂呐。 所以这就造成了用户理解的功能和实际实现之间的鸿沟。
  • 同时还有使用环境的问题：比如私人信息给医生可以帮助你，但是流落至公众可能就不太好

因此作者们设计了以用户为中心、系统级IoT平台强化手段。SmartAuth最小化了用户期望和系统实际行为之间的差距。为了达成这个目标，SmartAuth通过自动收集、分析来自如APP源码、注释和权限请求等的信息来了解IoT 应用的实际功能。由于在应用商店中的应用描述是用户选择这个应用的重要因素之一，他们还采取了NLP来自动提取描述中的功能与实际功能、调用接口进行比较。 NLP还被用在代码注释分析上，用来更快得到开发者的意图。 为了减轻用户负担，SmartAuth还能够根据描述和实际功能之间的差异进行自然语言生成，来告知用户对这些未预料的操作进行处理。

  • 实验在Samsung上测试了超过180款应用，成功在10秒/APP 内找到了验证相关的信息（误报率3.8% 漏报率0）。发现有16.7%的应用存在这种新型的过度权限问题（如模糊描述、隐藏安全敏感功能等等）
  • 同时作者们找了100个志愿者来评估SmartAuth对用户的影响。发现确实在更好理解模糊政策、安全风险、决策判断上有帮助
  • 最后他们对这些APP打了自动补丁，发现也没有明显的功能上冲突。

考虑到它的效率、低性能损耗和高兼容性，这个工具能被用于检查APP、增强验证制度、为用户提供更好保护上。总体上说他们做的工作如下：

  • 使用代码检查和app描述NLP进行用户中心的安全计算
  • 设计新的兼容性好的功耗低的家庭自动架构
  • 对开发出的SmartAuth进行基于真实情况的评估

Backgrounds

家庭自动系统

典型的家庭自动系统的架构如下： @figure2 由第三方开发的IoT apps可以为其提供获得传感器状态及设备控制等权限，来帮助用户对自己的家庭设备状态进行管理。 当下的IoT平台使用capabilities来描述设备的功能以及从用户处获取相关权限。但是和permission不同的是，capability不是出于安全而是出于应用的考虑。由于相关程序的复杂性，capabilities往往设计得比较粗糙。如一个capability可能允许一个app来检查几个设备的属性或者进行一系列操作。 同时一个设备也能作为一个网络终端，与服务器进行交互。许多系统都支持标准验证和授权的机制（如OAuth）来让第三方监控、控制设备

自然语言处理

使用Word2Vec神经网络来计算语义空间中的两个单词的距离，进而得到两个单词之间的关系。 使用Stanford的Part-of-speech（POS），基于定义和语境来标记某个单词在句子中的词性。其在短语、句子、段落中的关系都将影响POS对word的判定 同时还依赖于typed dependencies analysis来理解句子的语法结构、整合单词来理解句义。

IoT App Security Challenges

以前的IoT研究主要关注两类overprivilege的问题：

  • 粗糙的capability描述&限制
  • 设备-APP绑定过程

在后者中，一个设备可能被模糊赋予原本不需要或没想要的权限 作者发现过度权限问题可能不光与IoT应用的功能性相关，还可能和用户对app功能性认识不够有关。这虽然在移动应用中被讨论的很多，但是却在IoT世界中鲜为提及。 远程权限也是很重要的安全问题，因为它允许应用发送隐私数据给云端或者接受之（27个案例）。同时，SmartApp作为一个网络服务设备，也扩展了攻击面，并且也可能让恶意的服务器向其发送恶意指令造成恶意的远程控制。（17个案例）

SmartAuth 设计综述

应满足的要求如下：

  • 最小权限：系统只能给IoT应用最小的权限，只能刚好满足其设想的功能
  • 针对IoT：与移动设备不同，IoT系统应该满足多个设备、基于环境、自动化操作的需求。因此相关的权限模型应该基于清楚的权限和运行时请求
  • 可用性：应该以用户为中心，最小化gap
  • 轻量级：不应该对性能造成过大的影响
  • 兼容性：应该和存在的智能家庭平台相兼容，同时不能影响这些app的正常功能

同时，作者们还设计了一个智能验证系统，能够从IoT应用中还原足够多的语义信息，然后将其以容易理解的形式返还给用户。同时将其与实际代码中的语义逻辑进行比较，将不同处返还给用户。 因此系统包括如下5个成分：

  • 程序分析 通过程序分析，解析IoT应用中的语义，同时应用NLP处理code和注释，创建一系列的维持功能性所需要的权限列表
  • 语义检查 NLP app的描述来判断其对用户请求的权限
  • 一致性检查 比较上述两者的权限列表，产生安全策略，比较两者之间的区别。当然，除了自动化处理之外，这个过程也应该要能受用户控制
  • 创建验证信息 将策略和相关信息显示给用户检查
  • 权限策略执行 执行制定的策略 @figure3

因此，智能家居结构可以有下列的三元组来表示：(E,A,T)

  • E代表事件、输入以及对IoT设备的==量度==，对策略环境的描述
  • A代表由E所触发的事件
  • T代表A的执行目标，如果为空则代表是广播信息或者是广播命令

这样一个模型描述了典型的APP功能。它会在下列几种情况中被生成：

  • 授权过程
  • 根据APP描述生成
  • 根据代码生成

    设计应用

    自动化侦测App行为

    为了分析得到一个app的安全相关行为，使用对app的source code静态分析手段和NLPcode注释和API文档来分析 首先作者们在2016年5月从应用市场收集了180个三星智能设备应用的源代码。差不多代表了当时100%的开源APP和80.2%的所有智能设备APP。 对于每个收集的APP，根据其code生成抽象语法树（Abstract Syntax Tree），解决一些类、静态加载和变量域的问题。（首先能够获得源代码，那么就很适合做AST；其次这些智能设备APP都是用Groovy写的，能够将调用的方法生成镜像，为普通二进制分析带来很多麻烦）

首先通过搜索与capabilities有关的==块==解析capabilities，这与安全行为直接相关。同时将搜索结果和IoT APP文档中要求的权限结合起来。 为更好了解ioT APP是如何使用这些要求的权限的，作者还分析了与每个要求的权限相关的命令和属性，原理是利用APP状态更新时需要向事件绑定信息subscribe(dev,attr,handler)。为了保证分析，作者还维护了一个由权限到相关命令、属性的映射表。

然后是产生安全策略，首先从事件调用的方法(handler)开始，进行向后分析。

  • 分析调用的函数的代码块来判断其是否有条件判断
  • 在条件块中，找寻事件、对象及相应的活动内容
  • 被调用的方法中一定传进来了与事件有关的信息，将其与AST中的变量相结合，分析事件及其相关所需的权限内容
  • 然后再分析这个事件所触发的活动内容

然后再考虑app是否会访问除了物联网云之外的服务器。在此考虑两种远程控制：一种是app向远程服务器发送数据；另一种是app作为网络服务，从服务器接受了指令。因此作者们搜索AST种符合OAuth、createAccessToken和groovyx.net.http的特征片段

同时，通过对代码注释的语义分析还可以得到更多关于设备环境和设备状态的信息

分析APP的描述

从三个层面抽出比较描述和实际权限使用的情况：

  1. 实体（如运动传感器等）及其之间的关系
  2. 环境和活动
  3. 条件

为了避免由于设备环境造成的对实体应用的影响，作者们还执行了下面的程序：

  • 如果描述中直接表明了使用的实体，就直接提取出来
  • 通过Word2Vec评估描述中的单词和相关设备之间的关系
  • 对于描述中的单词和实体之间没有直接关系的情况，则将其与代码注释中的语境相结合

为了比较描述中活动的语义和设备的实际活动之间的差别，他们又从物联网的API文档中产生属性和指令模型，也就是代表他们语义的命令属性关键词，进而产生应用描述和实体之间的关系图 Figure 6 在比较了代码中使用的设备和描述中提及的设备之后，还需要知道实际的控制流是否符合策略模型，因为在多设备管理的情况下，设备之间往往也会产生相互影响。因此他们通过分析代码中的相关性来建立设备之间的关联程度（触发事件-结果），然后判断哪些行为是在代码和描述中相符合，而哪些是违背的

产生验证界面

对于测试者（300名），主要调查：

  1. 使用IoT平台的经历
  2. 安装第三方IoT APP时候考虑的方面
  3. 对于智能家居设备的认知 平均30.8岁，年龄范围18-60，32%女性 对于App的功能性和隐私问题这些影响用户选择IoT App的方面，采取5个等级的care程度调查。 对用户对IoT和安卓/IOS上的权限模型的敏感程度调查：
    • 受访者对同样的IoT设备的不同行为有很大的risk感知差异，因此用户需要极大提升自己对app实际会在家中做的事情而不是仅仅针对某个设备的了解程度
    • 69%的受访者认为只能家居设备会比安卓苹果的权限模型更加敏感

      “Smart home compromises can inflict serious damage or injury. Imagine being locked in your house, with the heat cranked up. Or an invader monitoring your location in the house, or studying your patterns. The risk involved in a smartphone knowing your location or accessing the devices hardware, like reading contents, contacts or accessing the camera are far more limited in potential effects by an attacker.”

为了产生用户界面，最小化用户理解和实际操作之间的差距。作者们首先依赖连接应用功能和实际授权之间的策略模型，去除冗余逻辑，利用SimpleNlG产生用户可以理解的书面语言。 最终生成的描述中包含设备属性、设备使用了哪些指令以及为什么使用了这些指令这些内容。 由于用户大量依赖应用的描述给予其所需的权限，而不是授权界面上的信息。作者们默认用户选择描述中依赖的权限之后，分析应用可能会使用这些权限产生的额外行为，并且生成对这些行为所将采取的策略，而不是一些晦涩的设置信息。 三类危险等级：符合声称的已被验证的行为、不敏感但未被提及的行为以及未被提及且有一定风险的行为；风险程度根据专家和大众对其可能发生的状态变化和设备操作进行评估。

策略实行

一旦用户完成的权限选择，系统就会对未授权的指令和属性获取权进行端到端的验证。 为了验证策略实行的机制，作者们在本地使用REST APIs来直接模拟物联网云的整合状态，通过对应用中的指令及属性函数patch成等价的REST API调用，这样应用在调用时就能直接返回给被patch的app，而不会对app本身逻辑造成影响了。同样的，应用也需要连接到实行模型来获得对事件的关联。 策略实行机制自用户开始安装应用开始，用户首先会被导向至作者们设计的加强版设置界面，基于用户的策略，模块会做出两类决策：

  1. 当模块收到来自app的命令或属性请求时，首先其会解析设备ID及活动，然后检查数据库中是否有合适的验证信息。如果有就转发至云并接收云传回的信息转发至app，没有的话就会向app返回一个错误信息（如果app中没有设计对错误信息的处理，可能会导致程序崩溃）
  2. 当模块收到来自云的报告信息时，它会首先检查相关的app ID和安全策略，仅在允许的条件下将其转发给app（因此它可以阻拦掉所有未验证绑定、指令和属性方面的请求）

    Evaluation

    解析策略的准确性

    通过对180个app进行手动分析，将其与自动分析结果进行比较。发现漏报率为0，错报率为3.9%（自动分析为unexpected，手动分析为其他类别） 在其中的两个案例里，一个应用使用产品名字来代表设备，但是这个产品名却与其功能并不相关，这可以通过使用命名实体分析来判断其引用的app的行为及描述之间的关系来判断；另一个案例中的描述有着长达几个句子的复杂逻辑，因此用户常常无法清楚判断设备和应用场景之间的关系了。

    对用户的影响

    首先是验证SmartAuth对用户安装时的影响： 100受访者，不同领域，19-41岁，25.7岁的平均年龄，59%男性，至少高中以上学历，68%的有科技背景，熟悉使用移动设备且对家庭自动系统较为熟悉，使用实验室环境下预先配置好的手机并回答相关问题。 实验首先是对IoT应用的一些选择题，用户选择5类IoT应用中的两款相似的应用中的某一个，两个应用功能相似但其中一款有过度权限的问题。 用户分成两组，一组使用三星自带的物联设备验证界面，另一组使用SmartAuth提供的界面。 对于每一类APP，有48%-60%使用三星界面的用户选择了过度权限的应用，即便其告知了应用可能使用的设备及潜在使用的设备 但对于SmartAuth，有84%的受访者成功避免了过度权限应用的安装 @尤其注意这里的AB类是含有较危险行为的APP，而CDE中的未预料行为并不那么危险 用户最后对这些应用的实际感知评估、作出决定时的自信程度和从界面中获得关键信息的困难程度也被考虑在内,SmartAuth也比三星自带的系统更好 最后的开放题，用户均表示了对功能性和方面配置的需求，但是使用SmartAuth的用户还讨论了有关隐私和未预料的危险行为的考虑

    性能和兼容性

    性能测试包括两个：

    • 预处理性能：程序分析、描述分析、行为符合度以及最后的策略描述生成 测试环境3.1GHz Inter Core i7 + 16G memory 平均时间为10.42s 由于这个预处理只用执行一次而且可以离线进行，因此还是很适合用于大量应用的分析的
    • 运行时性能：验证界面的生成、策略实施 首先强制智能应用与在Amazone EC2云服务器上的策略服务器进行交互，这样就可以执行用户的意愿，同时为了比较不同app之间的兼容性，权限设置使用系统默认配置，也是==很多用户会直接选择==的配置 为了检测性能，所有检测出未预料行为和危险行为都被设为拒绝。 程序都在三星的在线应用模拟平台上运行来避免采购过多设备的需求，使用模拟的IoT设备来测试它们的功能 测试环境3.1GHz Inter Core i7 + 1G memory + 180 apps + 1800次实验(包括对不同指令、属性和事件处理的活动的delay记录) 平均时间为35.4ms

兼容性测试在性能测试的同时进行，屏蔽了所有的未预料指令、属性获取和远程执行，然后再放到模拟环境中运行。每个APP至少触发5次事件，并且还向代码中插入调试信息来观察其从云上获得信息或事件被触发时的app行为。 测试结果发现没有任何程序在patch之后crash，也就是说patch并没有破坏原有描述中的功能。在进一步屏蔽所由第三方远程控制之后，仅有6款应用出现了有效的功能性缺陷

缺陷

恶意程序开发者可能使用自定义的方法和属性名来镜像智能设备指令或属性来欺骗SmartAuth。但是随着AST transformation的进步，检测这类混淆或是其他手段的效率也将进一步提高 同时，恶意代码还可能构造app描述，在用户察觉不到的情况下欺骗语义分析，这方面今后可能会结合IFTTT来做 还有，远程动态调用也可能是今后的威胁之一，但是像三星这样的公司已经可以从代码分析中ban掉这种远程执行方法了 另外，用户实验可能也有设计缺陷，用户可能因为SmartAuth的新奇界面就会认为这个设计得更好而不去关注自己是否真正适应这种方式；同时，实际应用当中用户可能面对的是安装唯一的过度应用选项，那么是否仍能规避这样的安装还需要考量；还有，用户是否真的如假设所述地花很大精力去研究应用描述也需要实际的实验证明

Search