[1] Perils and Mitigation of Security Risks of Cooperation in Mobile-as-a-Gateway IoT.
AMT访问模型转换
MaaG移动网关Mobile-asa-Gateway
iot设备 app（网关） cloud
C cloud D device
前提：攻击者可以对自己的智能手机进行 root/越狱，对公开可用的配套应用程序进行逆向工程，并修改该应用程序
感觉是不能获取最新的访问策略，因为不是一直链接到云服务器
设备允许离线访问，比如门锁，如果互联网中断居民就会被锁在门外，MaaG IoT 设备可能具有离线访问代码，允许设备访问而无需使用根本不同步到云端的配套应用程序；某些设备允许低权限的来宾用户脱机使用，而其他设备则仅允许高权限的管理用户
恶意临时用户的目标是尽可能长时间地保留其访问权限，进一步分发此类访问权限，甚至提升其权限。
1 problem
(1) 允许临时用户保留对设备的永久访问权限； (2) 允许临时用户与其他未经授权的用户共享其访问权限； (3) 允许临时用户升级权限。
即使在云端撤销权限并且相应的策略与物联网设备成功同步后，临时用户也可以永远保留访问权限
1 语义丢失（？）
缺乏标准的、有安全保证的机制来将 AMC 转换为相应的访问模型 AMD（在本文中称为访问模型转换或 AMT），AMD 具有轻量级和高效率的特点，我们发现主流物联网供应商通常无法在以下情况下保留相应的语义：在云和设备之间转换访问模型和策略。
在这些步骤之后，锁会丢弃 cr，并仅依靠 BLE 绑定来识别经过身份验证的用户。设备端 AMD 并不维护云端已知的用户身份或与用户相关的凭证 cr（如上所述） 。相反，锁仅维护 BLE 级别的绑定关系。以便她将来可以连接到锁，而无需再次请求云（用于离线访问）。
Admin如果从云删除用户，并不会删除app蓝牙保存的凭证，只能亲自前往锁在app将锁删除？在实践中，恶意委托用户（例如 Airbnb/酒店客人 [52]、前雇员）可以使用欺骗性的设备名称（例如所有者的姓名），因此真正的所有者很容易感到困惑并无法找到设备名称。正确地识别受委托者用户，或错误地认为受委托者已被删除。
(𝐵𝐿𝐸𝑑𝑒𝑣𝑖𝑐𝑒𝑛𝑎𝑚𝑒, 𝐵𝐿𝐸𝑏𝑜𝑛𝑑𝑖𝑛𝑔𝑙𝑜𝑛𝑔𝑡𝑒𝑟𝑚𝑘𝑒𝑦)
在已经是Guest用户的情况下，利用动态检测工具（例如 Frida [62]）修改 Kwikset 应用程序状态/逻辑来绕过它。具体来说，我们向设备制作了包含特权操作的 BLE 消息，例如，通过发送 BLE 消息（如 new byte[]{TLV8CommandTxType.CMD_TX_TYPE_SET_ACCESS_CODE, access_code}）来创建/读取访问代码；其中 access_code 是攻击者控制的访问代码。这有效地打破了只有管理用户才能创建/读取访问代码的安全要求。
2 安全责任不对称、错位
如果已经是Guest，首先必须向云进行身份验证并获取有效凭证，并与锁建立有效的 BLE 绑定（就像之前的 PoC 一样）。然后，我们通过前面 PoC 中提到的 BLE 消息，使用攻击者的智能手机直接向锁添加恶意访问代码。
此类访问代码未同步到云。
即使所有者从 AMC 撤销了我们的访问权限/角色，并随后从锁上物理删除了我们的 BLE 绑定，我们仍然可以使用之前安装的访问代码来解锁锁。这是因为离线访问代码是通过物理键盘（与 BLE 绑定分开）输入的。
良性的所有者需要通过 BLE 查询访问代码列表，然后将其删除。
政策同步的风险？
MaaG IoT 的另一个关键挑战是设计适当的机制来同步云和设备之间的访问策略，以达到足够的一致性。C策略更新会通知给每个D
3 访问策略同步中的因果一致性定义不充分
假如admin（私钥/公钥，s/g）给user1（公钥g1）配置权限p1，则C会用s签名p1和g1生成m1发送给D。看文章到达的策略同步消息可能无序m1,m3,m2。则D中的状态包括u1, p2。
同步策略流程：当锁收到策略同步消息（例如 m1、m2）时，它会向云回复一条响应消息（通过移动设备作为互联网网关），指示特定消息（例如，m1、m2）已在设备上接收并处理。虽然可以用时间戳来判定时间，如果时间不对可以丢弃等等。
对于级别锁，恶意用户（例如，授权员工、租户、访客）可以操纵 m2 和 m3 的顺序，或者 m2 和 m3 的响应消息，从而使设备上的策略状态和云端的不一样。
当云发送初始远程邀请消息（maddA）授予攻击者访问权限，并发送撤销消息（mrevA）以删除攻击者的访问权限时，攻击者可以简单地重新排序这两条消息（如果两者都转发）通过其智能手机。结果，mrevA消息将首先应用，对锁不会产生任何影响，然后maddA消息将允许攻击者随后获得访问权限。 更可能的情况是，maddA和mrevA之间存在一段时间间隔，例如，客人在租赁物业中停留几天后离开。
在这种情况下，攻击者可以先应用初始的maddA，并在mrevA之后仍然保留访问权限。攻击者只需保存原始maddA的副本，并将其转发到锁。然后，在应用mrevA之后（可能是由另一个良性用户触发），攻击者只需重新发送它即可重新获得访问权限。需要注意的是，这些消息都有时间戳，并且锁可以看到重新发送的maddA消息比mrevA消息更早。然而，由于MaaG IoT中消息传递的不可靠性质，设备无法依赖消息按顺序到达，因此仍会接受较旧的消息，从而引发攻击。
4 访问策略同步缺乏冲突识别
两种离线访问功能： （1）应用程序内离线访问（即使云暂时关闭或应用程序失去互联网访问权限，授权管理员用户的应用程序仍然可以操作锁） （2）离线访问代码（用于在没有应用程序的情况下解锁）
每个锁都带有两个内置的、在出厂设置下与云预共享的持久秘密，即 keyadmin 和 keyguest
操作1： 为了使离线应用程序能够在失去互联网连接或云关闭时访问设备，应用程序可以通过添加新的密钥（例如keyoffline）到锁中来建立有效的会话。该密钥存储在设备中的逻辑插槽中，与其他内置密钥并行。然而，在现代的物联网环境中，存在一个问题，即移动网关（如访客或委托用户）不始终可信，并且云缺乏可靠的协议来监控密钥的添加、存在或撤销。因此，当设备所有者从云中删除授权用户时，无法跟踪用户保存的任何离线密钥，也无法识别云和锁之间的不一致状态。 此外，August/Yale锁支持离线访问代码，但云端和设备之间无法可靠同步。用户可以通过有效的管理会话向锁添加离线访问代码，并将此策略同步到云端。然而，云和设备之间的同步可能不完全可靠，导致即使所有者从云端策略中删除用户，用户仍然可以通过离线访问代码保持对锁的访问权限。
操作2： 作为拥有所有者权限的攻击者，我们可以注入恶意离线密钥到August和Yale智能锁中，而无需在云端记录。我们允许攻击者的应用程序与锁完成握手，验证应用程序作为锁的所有者，并添加离线密钥。应用程序会检查通过应用程序GUI添加离线密钥的结果，但攻击者可以修改应用程序行为并绕过通知云端的最后一步。这导致云端无法知道离线密钥已成功安装在锁上。即使另一个所有者撤销了攻击者的云端访问权限并进行物理同步，攻击者仍可以使用”隐藏”的离线密钥保持对锁的访问权限，因为锁无法向云端报告其当前策略状态。
2 why
独立于云来执行此策略
- 访问权限管理不当：临时用户被允许保留对设备的永久访问权限，临时用户与其他未经授权的用户共享访问权限，以及临时用户被允许升级权限。这可能是由于权限管理策略设计的不足，没有对用户的权限进行详细和精确的划分和控制。
- 语义丢失：在将访问模型转换为轻量级和高效的形式时，可能会丢失一些重要的信息，如用户身份和相关凭证，导致临时用户可以通过设备名称欺骗系统，使真正的所有者无法正确识别受委托者用户。
- 安全责任错位：当临时用户向设备添加恶意访问代码时，这些访问代码并不会被同步到云端，从而使所有者无法通过云端查询并删除这些恶意访问代码，这反映了在访问权限管理和设备控制上的安全责任错位。
- 访问策略同步问题：在物联网环境中，云端与设备端的访问策略同步通常面临诸多挑战，如因果一致性的定义不充分，缺乏冲突识别等问题。如果访问策略同步不及时或不正确，可能会导致恶意用户利用策略不一致的漏洞，通过重新排序消息、保存和重新发送消息等方式维持对设备的访问权限。
3 solution
（1）只有当前根据云上的访问策略明确授权的用户才能访问物联网设备，并受到有限的延迟（可配置）的限制，允许用户在某些有限的时间内保留访问权限时间 （2）永久用户（例如所有者）可以在较长时间内（可配置）享受“离线可用性”[50]。
4 result
Ultraloq、Honeywell、Schlage、Geonfino、Tile、Chipolo 都通过共享永不更改/旋转的静态密钥来实现访问共享/撤销给不受信任的用户/受邀者。
展示了 8 个智能锁设备和另外 2 个物联网设备中的缺陷。
5 future work
蓝牙存在弱点，允许窃听、数据包注入和设备欺骗。
[2] Understanding and Mitigating Security Risks in Cloud-based IoT Access Policies.
平台即服务 (PaaS) 和基础设施即服务 (IaaS)
在字符串的层面设计
研究对象：基于 AWS-IoT 的开源项目
后果：任何用户都可以控制所有t2Fi用户的智能烧烤炉，存在严重的火灾/安全危险；任何用户都可以收集所有 Biobeat 用户的敏感健康/医疗信息，例如血压、身高、体重和年龄。
这一个架构和之前的不一样了，通过云转发消息：
MQTT 发布-订阅模式
例子：（考虑到潜在的大量 IoT 最终用户，AWS IoT 支持/推荐带有策略变量的模板式 IoT 策略，而不是为每个用户创建单独的 IoT 策略）${iot:Connection.Thing.ThingName}
1 problem
设计空间缺陷 1：物联网访问策略中的语义差距（关注的MQTT格式的）
通配符的过滤不完整，恶意 Govee 用户仍然可以订阅主题 +/
设计空间缺陷 2：IAM 政策和 IoT 政策之间的合作存在缺陷
IAM是？是一种权限策略，用于在 AWS 账户中控制特定实体（如 IAM 用户、IAM 组或 IAM 角色）对 AWS 资源的访问级别。它们定义了哪些操作可以被执行以及哪些资源可以被访问。IAM 策略可以以 JSON 格式编写，然后附加到 IAM 用户、组或角色。
AWS IoT 直接利用另外两项 AWS 服务（即 Cognito 和 IAM）来帮助进行身份验证和授权。
普通AWS流程：Cognito 返回cred_authed=xxx凭证，给用户/客户端，有cred_authed的向AWS请求服务，AWS根据cred_authed查询Cognito，获取用户的 Cognito 身份和关联的 IAM 策略，并根据 IAM 策略中特定于服务的语句，通过确定是否允许请求中的特定操作（例如 s3:ListBucket、iot:Publish、iot:AttachPolicy）来强制执行策略。
AWS IOT：AWS IoT 还需要与客户端关联的 IoT 策略。特别是，关联 IAM 策略允许“iot:AttachPolicy”操作的客户端/主体可以通过调用 AWS IoT API Attach_policy [18] 将给定的 IoT 策略附加到给定的 Cognito 身份。
三种逻辑关系：
- IAM 策略与 IoT 策略的关系： 客户端必须具有宽松的 IAM 策略才能连接到 AWS IoT 或使用 AWS IoT 发出 API 请求。IAM 策略应允许 IoT 相关操作（例如 iot:AttachPolicy 和 iot:Subscribe）。AWS IoT 的这种要求可能继承自所有 AWS 服务，这些服务通常依赖于 AWS 范围内的 IAM 策略评估引擎来确定 AWS 服务（即此处的 AWS IoT）是否应处理 API 请求。
- 客户端与 IoT 设备的交互控制关系： 对于要控制 IoT 设备或与 IoT 设备交互的客户端，特定的 IoT 操作（例如 iot:Publish、iot:Subscribe）和目标资源必须在物联网政策中允许。
- 空的 IoT 策略与默认安全原则的关系： 默认情况下，如果客户端与 IoT 设备关联的 IoT 策略为空，那么与 IoT 设备控制/交互相关的任何允许的操作和资源在 IAM 策略中会失效，即”安全原则”故障安全默认值。
客户端权限：
物联网供应商/开发人员通常通过为物联网用户定义高度宽松的 IAM 策略（例如，使用 iot:* 允许任何物联网 API 被调用到 AWS IoT，参见图中的策略）
说是这反映了未经身份验证的身份的真实授权逻辑
我们逆向工程了物联网供应商的移动应用程序，无需登录，我们获得了未经身份验证角色的Cognito凭据。通过这些凭据，我们能够连接到供应商的公共AWS IoT端点，并执行与他们的应用程序相同的操作。使用我们的脚本，我们可以订阅所有主题（我们会根据设备ID进行过滤），并向自己的设备发送任意命令。
实施空间缺陷 3：物联网策略模板的困境
此处例子是NetVue：
当 NetVue 摄像头根据内部转发规则（使用 AWS IoT 规则引擎 [39]）向其特定于设备的主题（例如 dc/4047512672901241/control）发布消息/状态时，该消息将被转发到合法用户的主题。 （例如，设备所有者）主题（例如，cs/58412338f7944fb0）
IoT 供应商可能不得不采取一些功能工作解决方法，例如，通常使用通配符（例如 dc/*，参见图 8 中的第 3 行）来允许用户发布到任何设备主题。
缺陷 3：使用我们的 NetVue 摄像头，我们的“恶意”脚本（其底层凭证/用户没有摄像头的权限）可以发布命令（MQTT 消息，例如 {“payload” : “ptz”:“x”:-20 ,“y”:0, “token” : “uewlylljoewbheek”, “clientId” : “957e9eb81b8e4fe5”}) 到目标凸轮的主题并任意控制凸轮的角度
实施空间缺陷 4：物联网政策互斥的约束
两个角色可以建立为互斥的，因此同一用户不允许同时担任这两个角色
例子：
任何可以临时物理触摸 SwitchBot 设备上按钮的用户都可以与其配对，并被分配相同的“管理员”级 IoT 策略来完全控制智能开关（打开/关闭、恢复出厂设置、监控设备活动）。
例如，前员工/Airbnb/酒店/访客用户一旦为设备分配了 IoT 策略，就可以在设备为其他用户提供服务时完全控制该设备。更糟糕的是，我们发现即使新用户重置设备（通过按下设备上和 SwitchBot 应用程序中的按钮），前用户仍然承担 IoT 策略并可以控制设备。
管理同一物联网设备的相同物联网策略不应无限制地分配给不同的用户
2 why
- 物联网访问策略中的语义差距： 由于物联网设备使用 MQTT 的发布-订阅模式进行通信，需要对主题进行筛选和控制。然而，通配符的过滤不完整，导致可能存在恶意用户订阅到非法主题的问题。
- IAM 政策和 IoT 政策之间的合作存在缺陷： IAM 是 AWS 的权限策略服务，用于控制特定实体对 AWS 资源的访问级别，但在物联网环境中，IAM 和 IoT 策略的协作存在缺陷。例如，即使在 IAM 策略中禁止了某些操作，如果 IoT 策略为空，这些操作仍然可能被执行。另外，物联网供应商/开发人员常常为用户定义过于宽松的 IAM 策略，可能导致安全风险。
- 物联网策略模板的困境： IoT 供应商可能需要通过一些工作解决方案来实现特定功能，例如使用通配符来允许用户发布到任何设备主题。但这样做可能导致未授权的用户或脚本能够控制 IoT 设备。
- 物联网政策互斥的约束： 物联网设备通常支持多用户，并可能会给每个用户分配不同的角色和权限。然而，如果这些策略没有正确地设置为互斥的，那么一个用户可能会被分配到多个角色，从而获取更多的权限。例如，同一物联网设备的管理员级 IoT 策略如果无限制地分配给不同的用户，可能导致前用户仍然可以控制设备，即使新用户重置了设备。
[3] Are You Spying on Me? Large-Scale Analysis on IoT Data Exposure through Companion Apps.
solution
- 数据收集和预处理：
- 收集了大量数据，包括2021年10月29日至2022年4月26日期间来自Apple应用程序商店（美国）的366,685个iOS独特应用程序。
- 同时收集了这些应用程序的隐私标签和隐私政策。
- 使用与应用程序下载时间最接近的隐私标签，并检查版本历史记录以确保应用程序版本是隐私标签页面中列出的最新版本。
- 静态评估框架（Static Assessment Framework，SAF）：
- 对应用程序二进制文件以及其隐私标签和策略进行分析。在应用程序的二进制文件中搜索选择器名称
- 输出两个应用程序集：
- 使用iOS系统API的应用程序，其返回数据（如果由应用程序收集）应在iOS隐私标签中公开，包括161,262个应用程序。
- 隐私标签和隐私政策的数据实践披露不一致（关于数据收集和使用目的）的应用程序，记为PP，包括53,376个应用程序。
- 如果在应用程序的二进制代码中找不到相应的 iOS API -[ASIdentifierManager AdvertisingIdentifier]，则该应用程序不会收集 IDFA（设备 ID）等信息
- 动态评估框架（Dynamic Assessment Framework，DAF）：
- 基于感兴趣的应用程序（即集API和PP）进行动态分析。
- DAF包括执行端到端执行，涉及全自动应用程序UI执行、动态检测和网络监控的动态分析管道。
- 通过应用程序的子集来全面执行该管道，以提高隐私标签违规检测的精度，并保持研究的可扩展性。
- 基于管道收集的数据实践的上下文，DAF推断收集的实际数据和收集的目的，并将它们抽象为元组（数据、目的），涵盖Apple定义的32个数据项和6个目的。
- DAF将这些元组与供应商隐私声明中的披露进行比较，最终报告隐私标签不合规情况。
- 数据采集：
- 收集了366,685个iOS应用程序用于进行隐私标签合规性检查。
- 使用先前作品中超过一百万个Android应用程序名称来找到对应的iOS版本的应用程序，共收集了485,024个唯一的应用程序Bundle ID。
- 在10部iPhone上运行应用程序爬虫来下载和解密这些应用程序，最终收集了366,685个iOS应用程序，涵盖了27个应用类别。
- 对于每个iOS应用程序，还收集了其隐私标签和隐私政策。
[4] Lalaine: Measuring and Characterizing Non-Compliance of Apple Privacy Labels at Scale.
IoTProfiler利用两个关键观察结果来进行分析：
- 观察结果O1：超过70%的物联网设备需要在本地连接到移动配套应用程序（如蓝牙、局域网）进行数据处理（解析、组织、标记等）和初步分析（例如，将唯一标识符与用户相关联），然后再将数据传输到云端。这意味着物联网设备并不直接将用户数据传输到云后端，而是通过配套应用程序进行中间处理。
- 观察结果O2：这些配套应用程序通常包含丰富的自然语言文本描述（例如字符串常量），这不仅表明物联网数据的存在，还表明其语义（例如心率和血压等数据）由物联网设备检测到。
挑战： (1) 自动定位配套应用程序中处理的物联网数据，这些数据通常与应用程序的本地数据保存在一起； (2) 理解数据的语义，以确定其收集和共享的合法性。
result
每个应用程序平均公开 5.6 个数据项（例如，准确的家庭地址、体重、BMI 、呼吸暂停计数、呼吸频率、血糖水平等）