[嵌入式]IoTSAFE:Enforcing Safety and Security Policy with Real IoT Physical Interaction Discovery

背景

近几年，IoT设备和平台在固件漏洞、协议漏洞、信息泄露、恶意软件以及测信道攻击等等方面被挖掘出很多漏洞。

背景知识

IoT设备设计到的交互有两个方面：网络交互和物理交互。

网络交互：不同的APP之间通过网络中的通用设备和系统事件进行交互。比如：一个设备在日落之后开灯，另一个设备检测到开灯后把门给关上。这两个APP共享了同一个IoT平台上一个变量（light.on）。
物理交互：IoT设备可以影响物理环境，物理环境的改变出发其他IoT设备的行为。如：加热器把室内温度提高，然后另一个设备检测到温度提高后把窗户打开了。这种情况下，温度这个物理量把加热器和温度传感器给连接起来了，形成了物理交互。

相关工作

通过网络交互产生的安全问题方面，Soteria和IoTSan等工作通过设置一些安全规则，然后用模型检测的方法去看设备是否违反了安全规则。比如：多个Apps修改同一设备上的属性可能导致冲突和异常。
物理交互也有可能引起安全问题。比如刚刚的例子，窃贼可以通过操控温度让窗户打开，从而入室抢劫。IoTMon通过静态分析的方法去找由物理交互引起的安全问题。他通过对app的描述文档进行文字分析来找到设备之间所有可能的物理交互通道，但是静态分析不能捕获到在运行时发生的一些安全问题。IoTGuard通过模拟IoT app的运行时行为来检测不安全的状态。但是对于多设备多app之间的物理交互，IoTGuard不能很好地检测。

本文工作：

多app的IoT环境下动态物理交互的风险情况预测。

问题陈述

在IoT环境下，攻击者可能利用设备之间的物理交互中存在的安全漏洞发动攻击。而现有的方法不能用于检测实时的运行状态下物理交互带来的安全问题。

挑战：

1. 现有的静态方法不能用于检测真实环境下的物理交互。
2. 多种因素可能会影响到物理交互。如：空间位置、设备影响范围和环境状况。
3. 临时的物理交互：一些物理交互可能是在短时间内完成的。

1. IoT设备的物理交互通常是上下文敏感的，用以下的上下文来识别真实的物理交互：

• 空间上下文：设备的位置信息。
• 时间上下文：时间上下文。
• 隐式效应：一些设备可能带来多种影响，比如：加热器不仅会提高温度，还会降低湿度。
• 联合效应：多个设备给同一物理量造成影响。

2. 时间相关的物理交互控制：

设备在关闭之后可能存在持续的影响。此外，一些设备考虑到成本和续航能力，它们生成报告的时间间隔会很长，这造成不能及时地处理一个异常。

威胁模型

这篇论文主要针对智能家居平台上由于物理交互发生的不安全的现象。假设攻击这能够通过有漏洞或者恶意的IoT应用，并且有漏洞的设备能够通过物理交互触发周围的设备的行为。

整体框架

整个系统由四个部分组成：App分析，真实物理交互挖掘，运行时预测，策略制定和执行。

1. App分析
   通过动态测试和收集用户的配置等来分析程序的控制流，主要包括触发条件，动作以及用户配置。代码分析获取的触发条件和对应的动作生成一个静态的交互表格。根据用户的配置也可以提供一个粗粒度的设备组。个人理解是说通过多个设备的分析最后组合成一个细粒度的交互表。
2. 真实物理交互挖掘
   部署app之后，IoTSafe用配置信息以及房间信息来生成测试用例。基于测试用例进行动态的测试来识别设备的物理交互。然后通过一系列的测试分析空间、隐式和联合影响。

前两步我理解的应该是首先通过分析应用程序的配置信息去列出来所有可能的物理交互，然后通过运行时的测试来确定哪些交互是真实存在的。

3. 运行时预测
   初始化并且维持一个物理模型来描述物理交互造成的临时的影响。然后收集数据，对比当前状态和物理交互模型来预测将来的状态。初始化的状态就是基于测试阶段的数据收集。对于未测试的设备以及新添加的设备，IoTSafe就使用在线数据来训练它们的交互表。如果用户修改了设置，IoTSafe也会相应的调整。

问题：如何调整？如何识别新设备的加入？如何识别用户配置信息修改？

4. 策略制定和执行
   用一个控制服务器来负责识别是否由违反policy的现象，主要是检查app事件以及违法用户自定义的规则的动作。允许用户自定义规则。一旦发现有违反规则的情况，就发出警告，或者把相应的动作给停掉。

系统设计

1. APP分析
   首先分析代码去提取依赖表，并且插入给用户设置以及策略执行模块。然后构建交互表，记录设备ID，触发条件、房间信息。
   代码分析和插桩：

   • 建立app和设备之间的依赖。
   • 在源代码上打补丁用于信息的收集。添加一些输出设备信息的代码。
   • 添加一些运行时的交互控制逻辑。
     交互表生成：
   • 提取设备id，触发场景的门限规定的数值（如温度），动作中涉及的数值、房间标签信息。
   • 把整个静态交互表根据用户添加的设置分成子表。

2. 物理交互发掘
   在前一步生成静态的交互表，这其中一些交互在APP中存在这个功能，但可能在当前场景下并不会用到，并且我们还需要识别潜在以及联合影响。因此，需要通过动态的测试来找到静态交互表中在当前环境下真实存在的交互。
   这里的动态测试策略需要满足以下条件：

   • 考虑到有些物理交互的时间比较长，进行的比较缓慢。动态测试需要考虑时间成本，要选择正确的测试顺序以及提高同步测试能力。
   • 由于测试的环境是真实环境，测试过程中要避免触发这些并不安全的场景。

   本文中的方法：
   测试一个设备的动作对其他设备状态的影响来确认它们之间的交互。

   1. 测试场景生成（这里觉得测试场景比测试用例更恰当一点）
      把一个房间内能够进行物理交互的所有设备看作是一个设备组。每个设备由很多状态，用 $States(D_i)$来表示一个设备$i$的所有可能状态。 一个测试场景就是所有设备的状态的集合，表示为$D_1.off,...,state(D_i),...,D_n.off$。

      这里除了$D_i$，其他设备都是off的状态，也就是每次都有且仅有一个设备处于运行状态。这里作者的解释是为了降低其他设备对该设备的影响。但是，这样如果多个设备的动作的叠加影响不久测不到了吗？？之前提到的joint effect怎么得到？

      测试场景生成时不考虑那些可能导致安全问题的设备，但是这些设备要参与到别的设备的测试中。对此，一种方法时用户去设置值，另一种方法是正常使用该设备，让运行时的数据表示一个状态。对于那些时间不确定的物理交互，这里的方法是把确定的值简化成设备的不同模式。比如不给自动恒温器设置具体的数值，而是只设置4种模式。
      智能插座这种设备就只给两种状态：开和关。并且把这个智能开关和它连接的设备视为一个设备。

   2. 生成所有可能测试场景后，用这些测试场景去确定设备之间空间、联合和潜在影响。方法就是首先获得传感器正常的信号，然后看传感器report的时间间隔，记录$State$状态下设备两次report的信号的变化量，记为$\Delta SensVal(D_i,state,t)$，用来表示正常情况下的传感器信号。在测试过程中，如果发现当前的变化和正常的不一样，就确定为一个真实的物理交互。
      3.顺序测试就是用于测试所有非同步的测试场景，从而确定设备之间的空间、时间、联合以节潜在的物理交互。在顺序测试的时候要考虑到两种测试场景之间的冲突，还要考虑到当前的环境物理量适合测试哪个场景。

   3. 对于互不依赖的物理量的测试场景，就可以并行测试。对于相互有影响的物理量就得分开测试，如温度和湿度。

   4. 对于一个设备能够跨房间编号，也可以同时测。

   5. 得到真实的物理交互。通过上述测试去掉静态分析中不存在的物理交互。

3. 运行时预测
   由于一些物理量是渐变的，设备传感器进行报告是有时间间隔的，因此，即使我们设置了安全策略，IoT设备依旧可能会触发不安全的情况。因此，我们需要对不安全的情况进行预测。
   这篇论文中的预测涉及两个方面：离线物理通道建模以及在线预测。

   1. 离线物理建模，这里对于和空气相关的物理量（温度、湿度、烟）进行了建模。
      $\Delta SensVal(D_i,state,t_1,t_2)=\frac{\Delta Q(D_i,state,t_1,t_2)}{\beta }$
      公式左边表示从时间$t_1$到$t_2$传感器捕获的值的变化量。右边的分子是传感器捕获到的真实值，$\beta$是多个空气相关的参数的乘积。
      $\Delta Q(D_i,state,t_1,t_2)=P_i?(t_2?t_1)$
      Q是物理量变化的计算方式，$P_i$是设备对物理量的影响或者通过设备功率等得到，括号里是时间差，这个公式就是能够计算时间间隔内设备对物理量的改变。还要考虑设备和传感器之间的距离造成的影响。
   2. 离线物理模型的初始化
      通过对真实数据取样，去计算上述公式中的参数。
   3. 对于新的设备或者受限设备，就通过日常的使用来获取数据。

4. 制定安全策略。

   1. 策略的种类：对于瞬间和非瞬间的交互分别做策略制定。
   2. 策略的定义：
      

5. 策略执行
   目前的动态策略执行方法有两种：一种就是在每条指令前进行插桩，在执行指令之前进行判断。第二种方法是预测策略是否被违反。用一个APP去监控所有设备的事件，然后做预测。如果策略被违反就给用户发送一个警告。