论文Summary04——TAP规则脆弱性动态修复

几个问题

机器人的例子是怎么找到motion相关的？怎么发现冲突的？模型偏向于预测数值，我觉得不好发现冲突。如何解决冲突的？提示用户加一条condition,但是加的不改变homemode并不是好例子
用户本身定义的TAP规则是怎么处理的？本文是怎么利用的？
看policy是不是都是有关可以测出来的环境属性，环境属性好像只能靠预测是否超过阈值来检测冲突
如果只是prevent，而不是静态的修改，那么问题仍会存在
动态体现在哪？周期性获取属性值并预测，以阻止不安全情况

做了两件事 多APP环境的体现？？我想实际多APP应该比较少（好像就smartThings会多应用），用户应该是倾向于在像米家这样综合的一个APP里操作多个设备，多APP里作用于相同通道的可以放一块

1. 运用动静结合的方法识别IoT设备runtime（实时）的physical interactions
2. 对physical interactions中的temporal physical interactions进行建模，动态地预测未来，识别risky situations related to temporal physical interactions，并阻止不安全的执行
   建模预测temporal相关属性的数值，如果预测数值不满足policy里的值，就判定为不安全提前结束，即sensor目前的温度距离那个温度还有一段距离

Cyberspace interactions:
refer to cross-app interactions where multiple apps subscribe/operate the same device.
two apps interact via the light.on event on the same device and share a common device attribute

multiple apps are installed together to operate the same devices.偏向TAP规则，一个smv对应一个APP？其实如果将多个APP的TAP放一个smv里也做到研究multiple app了

physical interactions：
app（如heater-control app、temperature-control app操控不同设备但都影响温度）/设备（heater and the temperature sensor）在shared physical environment channels (e.g., temperature, luminance, and humidity)交互

静态：static analysis based approaches only capture potential safety and security problems, rather than runtime policy violations，static approaches cannot be applied to identify real-time实时 physical interactions？？实时的交互里有设备型号，空间大小、设备距离这些静态少有思考或者较难体现的属性，那有什么violations是runtime才能识别的呢？？比如动态的时候设备有差异，空间大小有差异？？就是说设备型号和空间大小这些静态的属性其实是动态才能识别出来的，是real-time的，real-time的还有spatial location, device inflfluence range, and environment condition；以上是时间无关的，此外还有时间有关的temporal aspect方面，有些是瞬间有些动作需要一些时间或有些状态如烟雾报警需要开足够长时间才会有，时间方面的应该是可以静态分析吧，他弄成动态好像也行 通过静态的描述得到chennel，还有pysical interaction也是静态推出的

The continuous effect也是动态属性之一，比如加热器关闭后 means some devices are still capable of changing environment parameters even after they have been turned off.

静态分析通过拼接 apps if they share common physical channels.来discovers all potential physical interactions

好像空间大小，型号这种弄成静态也行，但是要先做个实验统计下，不过会存在之后更新场景然后不太充分的问题。我想可以先做一次动态把动态的属性分析明白，然后写入静态里，后期不断更新

如何identifying real physical interactions

consider more complex factors, such as room structure, device inflfluence range, and environment condition.
动静态

4个挑战

空间

the interaction between the heater and sensor are highly relying on their locations，比如不在一间房

时间

瞬时和延时。interval。continuous effect

Implicit Effect

如提升温度会降低湿度，另一类静态无法识别（因为静态是通过app description，只能找到定义的那些东西），如扫地机器人主要是描述clean而不是motion方面，其实我觉得静态可通过人为的加入这些来弥补缺点

Joint Effect

可能会导致更快地触发某些条件
我的idea，动态的重心是在real-time，那么动态只收集real-time再结合静态是否可以，本文是multi-app，还有什么multi

IoTGuard的问题：

1. without capturing real physical interactions
2. it enforces policies when device states are approaching to unsafe conditions (e.g., the temperature is already close to a critical level), which is often too late to prevent from damaging impacts on smart home environments

为什么实际会少于？ We identify 39 real physical interactions among 130 static interactions

一个例子： 我觉得这是个能说明动态的例子，如果静态的去查找的话，偏向于现有的逻辑漏洞，而这种可能是新出现的之前没有的状态（静态里一般没有），那么动态检测的话可以避免这种错误

这篇文章能检测什么种类的漏洞？？ 上篇是检测用户输入的，🍍哥的是检测几类具体的,这篇应该是temporal / 使policy失效的physical interaction

系统结构

App Analysis 属于静，但是这个静并不是提取很多详细信息的静（并不是，第一步得到的信息给服务器生成交互图去了），是为动服务的

整体目的：

1. 加入能提取id,room,trigger中的数值,action中的数值的代码，方便下一步动态。
2. 并加入能判断动作是否能执行的代码，方便最后一步（能动态阻止的代码实现）

具体：
static interaction ：trigger conditions, actions, and user settings of apps
根据设备的房间信息（由物联网用户配置）提供粗粒度的设备组
uses specifific user settings,such as devices id, trigger conditions, and room information to build inter-app interaction graphs.依赖关系
then it patches the app’s source code for runtime data collection, such as sending device ids and user confifigurations给服务器，服务器进行交互图的生成，并进行判断，如果不安全就返回flase，插入代码接收到false就不执行.所以能facilitate 下一步
这一步的可行性是因为官方直接提供了类似的debug API
It also adds extra logic for runtime interaction control(文献25)
插入代码的一个位置是在installed()；另一个位置是在动作函数里，在动作要执行前传入action和当前的某些环境数据进行判断。 是否存在这样的问题，只是installed()安装时反应是不是不够动态？？

交互图的生成
比较重要的是id和room，trigger中的值，action中的值，都只有在Installed的时候才发了
一个房间是一个图，包含了能在该房间作用的设备
我的想法，也可以按cyber channel（由app定义）分类，如一个mode模式下的设备交互。

Real Physical Interaction Discovery 属于动

难点在于静态识别的不包含joint和implicit，要动态的去识别（或对静态的加以扩展）
识别延时类的交互
解决：Using these modes instead of the specifific temperature values, we can reduce its testing cases to 4 cases.
对安全敏感的设备（锁，洒水）不要动态测试，可能出大问题。
解决：生成测试用例时不去枚举它们
测试的环境条件应在安全范围内，例如不能出现储藏室中的高温或潮湿的环境
解决：allows users to set a safe range for sensitive physical channels, e.g.,temperature and humidity

比如fan和smart plug连一起，视它们为一体为fan，然后可以将fan的状态加一个on和off（smart plug）

IOTSAFE uses app confifigurations (e.g., a temperature threshold that triggers a heater’s action) and room information to generate testing cases。用testing case动态测试，发现Real Physical Interaction 测试序列的选择有利于减少开支

records the temporal interaction data for related sensors.

testing case generation

provides all testable cases based on static analysis results.
a testing case is a combination of all device states in a group where these devices are in the same room and may interact via physical channels.State(Di),state(Di),testing case一个工作其他全关？？是为了减少其它设备对物理信道的影响，是测单个设备的单个能力的影响？？{D1.off,state(Di),Dn.off}
虽然不直接测试安全敏感设备，但是也要获得它们的交互
解决：use runtime data to verify static interactions during normal usage
过程：一开始全off，随机设备，他的某一状态加其它设备off是一个test case。这个设备状态遍历完后，将它off开启另一个设备。安全敏感设备不要选，或者某个设备的某个安全属性不要选。

dynamic testing

we need to test them to identify the spatial, joint, and implicit effects of physical interactions among devices.
捕获设备的正常波动，sensor测两次某设备的某状态，算出差值就是波动，如果测试时的差值大于波动就认定为是a real physical interaction.

Sequential Testing

目的：identify devices’ spatial, temporal, joint, and implicit physical interactions effificiently，如何实现找到的还是没看懂
方法：focuses on reducing testing overhead by choosing the proper testing sequence, which is
started by matching devices’ trigger conditions from apps.
由于continuous effect,testing sequence有差异
choosing the proper testing sequence的方法：如现在温度低那么更适合测试加热功能而不是降温功能，那么下次就执行能触发加热这个设备状态的（像如果时间是6点这样的触发条件不考虑/如果一个设备状态与多个触发条件相关，然后系统会对所有触发条件进行比较/如果有几个都满足的，选其中具有最近触发条件的/如果都不满足就随机选一个/避免conflicting influences如加热和降温）
避免冲突
缺点：sensor，也就是对有环境影响的，没影响的测不到？

不属于temporal的设备work时间会很短，为了观察引起的物理变化，将work time = one sensor report interval（测应该是随时在测，但是发出去是定时发），off时间is chosen to be the same as the related sensor’s report interval，可能为了测延迟等几个interval收几个report，那这不都一样了吗？自动汇报的我没试过，不过正常是点开温度计界面从温度计导入上次到这次的数据，然后可以实时变化

Single-room Parallel Testing

不作用于同一物理属性的可以并行测试，减少动态测试的时间开销，作用于同一物理属性的进行上一步的顺序测试(因为同时测试会互相影响)

Cross-room Parallel Testing

cross-room device (i.e., a device with a multiple room tag)

Real Interaction Graph

Fig.4变Fig.6

Runtime Prediction

建描述temporal的physical interaction model，收集当前状态和模型比较，是不是要经常进行收集，岂不很浪费？？我的想法是只收集那些动态才能准确获得的数据

如果新加入设备或者当前有变动（可能是根据报文类型判断），则更新模型

我们将温度设置在80华氏度以上为危险情况，有55份危险报告 policy violation detection.（计算预测数据的原因？）假阴性是因为地面真实温度仅在80华氏度以上的边界线上，而预测结果略低于80华氏度

提前时间定义为在实际传感器读数报告违规之前进行预测的提前时间，越提前越不能精准预测，用于解决too late问题

Physical Modeling:

自己动态产生一堆事件存在云端建模
needs an early detection for unsafe physical conditions to ensure the policy enforcement in a timely manner.
mainly concerns the air-related physical channel如temperature, humidity, smoke,and water level
温度相关装置的热增失Q主要有两种类型：1）交流电或窗扇等装置的热流；2）加热器等装置的热辐射。湿度等属性同理，给出来源并具体来源具体分析
对于热辐射，参数Qi可以通过使用其功率或连接的智能插头的功率乘以其工作时间来计算

对于热流

公式中的常量

计算湿度的变化，设备的一些速率可以通过附近的sensor测或设备本身的说明

平均误差是预测的温度值与传感器在运行时的实际读数之间的平均差值

Policy Specification and Enforcement

本文检测的思路是首先有policy，比如室内温度不能高于80F，IotSafe去
first requires users to setup their policies through a policy management app（用户设置，所以又是只检测用户的？）
如果当前/之后的状态违反Policy就冲突，就去制止或者发送warning，所以是用户输入policy，开发人员这种专业的预先定义最好，或者先定义然后加入用户自定义Policy。
关键是检测并修复（静态是修复，动态是阻止）

satety and security policies

能否把policy抽象为更有概括性的漏洞分类，如🍍哥？？
a policy contains two parts, the trigger condition and the enforced action
如trigger = sensor1 & sensor1.value>85 action = heater.off & warning

分类 Control Policies for Temporal Interactions.

用户输入trigger
看policy是不是都是有关可以测出来的环境属性，环境属性好像只能靠预测是否超过阈值来检测冲突

分类 Control Policies for Instant Interactions.

用户输入trigger和action

定义

如何Enforcement

一种方法是每次执行前httprequest给服务器判断是否执行
一种是定期发送
对某个设备执行policy时（如heater.off），要询问其它设备要不要也执行

IMPLEMENTATION AND EVALUATION

which typically has an average of 11 devices,according to a Deloitte US report
部署了23种不同类型的物联网设备和总共33台设备
一个客厅、一个卧室和一个浴室
定义了36个物理交互控制的安全策略
15分钟。根据我们的实验结果，这个间隔足够长来识别设备的时间影响
监视器每分钟更新设备的状态到服务器，并根据服务器的响应采取操作
静态的FP the static analysis gives 4 potential interactions but only one is real,which leads to 3 false positives.基于关键字之间的相似性，静态分析方法给出了加热器和烟雾通道之间的潜在相互作用。然而，由于加热器在动态测试中不会引起烟雾问题，我们认为这种相互作用是一个假阳性。
静态的FN The implicit interactions are actually false negatives of static analysis。
第一组（组1）包含5个与温度相关的应用程序，来测试识别与温度相关的物理交互和检测设备之间的策略违反的有效性。第二组（组2）的目的是学习照度相关设备之间的相互作用，如灯泡、阴影和光传感器。第三组（组3）被用来测试交叉通道的物理相互作用。第四组（第4组）包含21个应用程序，用于测试与多个物理通道相关的交互

coffee machine to the humidity sensors, stove to the temperature sensor, and TV to the illuminance sensor

实例1 bypass the security policy “Do not open window when no one is at home”

首先compromise “no one is at home”这个条件，通过移动机器人
然后compromise “Do not open window”，通过控制heater
系统如何防御这种恶意攻击的（应该还有正常系统的）？
在攻击前，IOTSAFE first detected the interaction between the robot and the motion sensor，our system gives hints to the user to set additional trigger conditions. For example, if the user sets an additional condition as “Do not trigger the family mode when the robot is working”,感觉只能预测到the robot is working，而Do not trigger the family mode是根据攻击实例来的

实例2

用户设置的策略是“温度应低于80华氏度”，iotsafe预测了温度的变化，提前18分钟关闭了加热器，使家庭环境远离高温环境。

Related work

Runtime Policy Enforcement

运行时状态和静态描述一样
通过分析应用程序的源代码和用户界面来定义一个正常的交通行为模型/或通过用户的数据构建一个正常模型。它在运行时检测应用程序的恶意行为。

Discussion

在这项工作中，我们没有考虑外部环境和时间动态对物理相互作用的影响（例如，时间和季节的影响）。我们通过考虑对外部环境的影响和时间的动态，将我们的方法的增强留给了我们未来的工作。

改变物理环境可能会导致危险的情况，并在测试过程中造成安全问题。因此，设备的某些功能不能进行测试，或者只能在一个有限的范围内进行测试，这可能会错过一些物理交互（例如，一个烤面包机到烟雾通道）。另一个挑战是测试开销，这与探索/测试可能路径的顺序有关。 静态全面但不太准确，动态准确但不太全面

dynamic testing period, which can be interfered by human activities.

一些符号

Ruledger

能够动态验证事件的真实性和所采取动作的有效性

区块链blockchain 每天一个账本，一个账本就是一个区块，记账者，找邻居抄账本

智能合约smart contract解决  合约强制性还钱 基于区块链（特点：不可篡改、分布式，别人也记着呢）

记下了所有的action requests和trigger event

区块链blockchain和智能合约smart contract解决

记下了所有的action requests和trigger event，防篡改

API level attacks（API脆弱性，所以API本身的功能会不会对应某种spoofing状态，系统API）

and platform/device compromise attacks

use vulnerable APIs to generate fake events.

rule tampering attacks that leverage vulnerable configuration APIs

action requests generated from the trigger-action platforms

malicious trigger requests

sends a trigger request to the trigger-action platform.

---

action requests generated from the trigger-action platforms

malicious trigger requests

action verifification module sends a trigger request to the trigger-action platform.

API level attacks（API脆弱性，所以API本身的功能会不会对应某种spoofing状态，系统API） and platform/device compromise attacks直接损坏控制设备

use vulnerable APIs to generate fake events.

rule tampering attacks that leverage vulnerable configuration APIs

IFTTT if this then that

---

如果发动device API和config API攻击能直接修改trigger或者直接rule

搞懂API攻击到底是个啥

Fernandes 等人[95]分析了包括 IFTTT[96]在内的 7 个联动平台(trigger-action platform), 发现攻击者可能获得过度授权的 OAuth 令牌,

从而对设备进行提权攻击, 为此作者设计了一个去中心化的联动平台, 使得攻击者无法使用与用户定义规则不一致的 OAuth 令牌。

all fake events and fake actions triggered by APIs

1.cannot abuse API to inject fake users or rule configurations due to the lack of the key

2.events实际发生The attacks constructed by any malicious users, e.g., via a compromised,cannot abuse any rule or trigger malicious execution。event对应了rule和trigger

3.trigger不会fake，requests generated from the triggeraction platforms are authentic

parameters, e.g., event info and a temporary key Cid), are submitted to the trigger-action platform, and then the platform generates trigger requests that carry these parameters to trigger specifific actions for IoT devices

Rethinking

异常行为的定义？异常行为的检测？动态的体现？
感觉就是对policy有启发，比如在policy中引入了角色而且引入了时间的概念如不要在晚上放音乐（好像还没人这么干），那么smv对应会增加一个权限变量，状态机的变化会伴随权限的变化，但是问题是我们是从iot app即开发人员的角度而不是user-driven，目前还没有这么细化的（只有家庭创建者，管理员，一般成员），也就处理不了，智能自己加。环境因素（有静有动）会影响当前的策略

调研了实际用户对智能家居访问控制的期望，其中指出用户、设备位置、设备使用历史、时间、用户位置、设备耗电量、设备状态等因素是构成访问控制情境的关键因素

访问控制定义：
which particular users, in which contexts, are permitted to access a resource
认证定义：
authentication (verifying that users are who they claim to be)
访问控制偏向死板规定，漏洞检测偏向灵活

平时的访问控制是设备一个人使用，有屏幕键盘，物联网设备多人共享，没屏幕键盘

以设备为中心的模型(允不允许使用设备)转向一个以能力为中心的模型,不同的能力有不同的敏感性

把角色更细化了（不仅根据年龄，还根据设备位置等环境因素划分），同时权力的划分也细化了（具体到某一能力了），智能化

智能家居的两大主要对手是外部第三方和那些有合法的物理使用权的人。

为了获得家庭物联网的理想的访问控制政策。做了好几个调查，调查结论：

以能力和以关系为中心的模型更符合用户的期望

6.2节

所需的访问控制策略在不同功能之间的差异(RQ1，第6.2节)
在一个设备中，参与者对不同的能力的态度是不同的，有些允许所有人用，有些比较严格
与上下文有关的功能：如门铃响是否应答或代替应答，取决于家中的人员情况。

6.3节

以及所需的策略在不同关系之间的差异程度(RQ1，第6.3节)。
保姆将获得比来访的家庭成员更高的许可。
一个青少年（表现为16岁）和一个孩子（表现为8岁）得到了非常不同的访问范围

6.4节

default policies
配偶是高度信任的，默认情况下，只有配偶应该能够访问管理功能，开关灯可以默认分配出去
“删除锁定日志”是最不经常允许的功能，因此在默认情况下应拒绝访问。即使对于配偶，默认情况下也不应该访问这个功能，对孩童的分配要默认监督

RQ3，第6.5节

我们评估哪些上下文因素（例如，年龄、位置、天气）对“有时”情况的影响最大，从而解释了用户不总是允许访问某个功能的原因(可能是某些语境下之前适合访问的现在不能访问？）
五个上下文因素（有静有态）的显著差异

1. 年龄
2. 设备位置
   “相机角度”，特别是在卧室或浴室，它将更加隐私敏感，室内使用还是在室外使用
3. 最近使用记录
   一方面，如果历史记录表明用户正在滥用某个功能，那么所有者可以撤销访问权限。
   另一方面，如果一个用户被证明是值得信任的，那么所有者可以考虑让他们保持访问权限，甚至扩展它
4. 当前时间
   为了不干扰他人的休息，参与者倾向于将割草机的使用限制在白天，并在傍晚播放音乐
5. 使用者位置
   任何目前不在家里的人使用这些能力
6. 当前设备状态
   如果摄像头目前是关闭的，那么任何人都没有理由禁用面部识别。
   还有其他因素

Situational Access Control

有一些跨层和每层分别部署的idea

通过实现智能家居的对设备连接层、资源层、设备控制层、应用框架与接口层、应用层的访问控制，从而为智能家居应用的执行提供了资源访问、应用接口服务、服务交互、以及设备与应用交互的访问控制权限。

这类论文的4个主要问题：能检测什么样的冲突？看是否满足policy。冲突是怎么检测的？冲突是怎么解决的？

如果涉及动态，是怎么个动态法?situational情景一词体现了动态，例如追踪用户位置，以推断用户是否在家里。只有在当前存在特定情况时，主体才可以访问对象。
如何situational access control？利用app、api或者一些需要的素材，去获取数据，然后判断是否满足

访问控制从根本上来说是分散的。它发生在多个独立的框架中，情况跟踪需要跨框架的交互和许可。

The interaction between an access-control system and a ESO is a basic client-server interaction.
各层访问控制所用的协议根据该层自身的特点ZigBee和Z-Wave
实际只部署在了两层

客户端服务器的一些实现细节：
首先，因为响应时间取决于rESO，所以在查询rESO之前，会向请求的客户端发送一条确认消息。它表明请求正在处理，而重传是不必要的。其次，情况查询是异步的：在发出远程请求后，我们立即生成线程，以便可以处理并发请求。

Case study
跨层和上层的体现

If this then what?

可以泛化为访问控制中不同等级（安全等级）的能力之间是否能调用，如低权限不调用高权限（流）
信息流和控制流的定义：
触发器源和操作接收器之间的信息流是用户隐私策略的一部分
flow of information from private sources to public sinks
breaks the flow from private to public, thus preventing privacy attacks.
每种行为都对应一种权限，状态机的变化伴随着权限的变化

文献[14] 关注了自动化规则动作的隐私违规问题，设计了基于访问控制和信息流控制两种保护机制，实现对异常动作的限制。上述工作只关注了规则语义层面的信息来进行访问控制。

短期：安全等级

上面的照片备份小程序，它意味着该小程序应该是完全私有的。但由于各方服务的融合，纯私有的小应用程序可能会变得过于严格。
防止同时访问私人和公共通信渠道

长期：信息流

建模小程序的反应性和定时行为reactivity and timing behavior，捕获由攻击造成的微小信息差距

IoTGuard:Dynamic Enforcement of Security and Safety Policy

根据用户制定的安全策略，动态地决定规则动作的执行,没引入如设备空间信息、时序信息、物理通道信息等

能检测什么样的冲突？policy
冲突是怎么检测的？ reachability analysis, parallel edges, self-loops, and loops
冲突是怎么解决的？和扩展文献26一样，阻止运行并告诉用户，并没有修改从本质上解决，下次还会发生，错误允许/拒绝访问某种能力的影响后果，要减少拒绝访问的后果，找到替代方案
如果涉及动态，是怎么个动态法？和扩展文献26一样是在执行action前进行判断

实现位置：in hub software, as a software service in the cloud, or in a local server。文章是在Local server实现的，local server是三种方式里最好的。

hook APP达到收集实时数据

smartThing和IFTTT有效吧，其它没用app的不行，而且可能存在安全问题难以hook
插入位置的选择：action前
插入位置的识别：通过逆向分析如入口点、处理函数、调用图，识别action，静态分析得到触发的trigger、里面的数值以及path condition（函数的互相调用和函数实现中每行代码）以及设备id（哪个设备发生的，因果，相同能力的设备有很多用于说明是哪一台）
收集四类数据：device,event,action,数值attribute

对这些数据建模，得到一个runtime model

从0开始动态建模，如果event从未出现过，把他初始化为一个新状态并添加trasition

检验policy

比如两个app都是实现了检测到运动就开灯，那么在状态机里检测到运动的状态到开灯状态有两条平行边
policy的分类：有app的，有解决触发操作平台服务和物联网平台之间的完整性和机密性违规问题的，我们主要是对应用层policy，这个得区分下
例如，如果规则在用户发送电子邮件时会打开智能开关，则当用户发送电子邮件时，发送电子邮件事件将具有可信的标签。这些标签存储在数据收集器所维护的应用程序的动态模型中。
根据完整性和机密性标签检查触发-操作平台策略，获得lebel,checks whether a path exists to a public state that makes private information public,and from an untrusted state to a trusted state.
reachability analysis 比如检测到smoke后能reach门关的状态
parallel edges
self-loops, and loops 互相trigger