04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔

跨云IoT访问授权中的安全威胁

简介:2020-USENIX

一、贡献

  1. 对物联网授权的新认识。我们对物联网设备访问授权中的安全风险进行了首次系统研究。我们的研究揭示了当今领先的物联网云提供商和设备供应商的授权过程中意外和安全关键漏洞的新类别,一旦这些漏洞被利用,其根本原因以及修复它们的挑战。吸取的教训将有助于更好地保护现实世界的物联网授权。
  2. IoT委托验证。我们开发并发布了第一个支持真实世界物联网授权的正式验证。我们的基础模型、委托操作模板、安全属性和细化技术为方便和自动发现委托漏洞迈出了第一步,这不仅有助于保护今天的物联网委托操作,也有助于保护明天的物联网委托操作。

二、路线图

本文的其余部分组织如下:

第2节提供了物联网设备委托的背景信息,并讨论了其安全要求和潜在风险;

第3节阐述了我们发现的漏洞;

第4节描述了我们用来发现这些漏洞的半自动方法;

第5节报告了委托缺陷影响的测量研究;

第6节介绍了委托缺陷的影响。第六节讨论了安全委托机制的设计原则、工作的局限性和未来的发展方向;

第七节将相关研究与我们的工作进行了比较;

第八节总结了本文。

三、内容

1、委托链

04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第1张图片

2、Threat model

2个角色:管理员、被委托者

管理员

  1. 可以是设备的拥有者、或是系统的管理员。
  1. 【授给别人】可以把设备的访问控制权委托给被委托这(角色2)

被委托者

  1. 访问权限可能被撤销和过期
  2. 可以把他的权限进一步委托给别人

假定管理员和物联网云是诚实的,被委托者是恶意的

我们假设恶意被委托者会充分利用他的权力来获取他无权访问的凭证和有用信息

在此期间,我们不认为对手能够窃听其他各方之间的通信。

3、漏洞

  1. 研究了10个主流的物联网云平台
  2. 发现了5个漏洞,并构建了端到端的攻击
  3. 漏洞4是手动发现的,然后去做了在这个研究,顺带着又发现了其他4个漏洞
  4. 漏洞分为2类
    1. 被委托者和被委托云之间不一致的安全政策
    2. 在定制的情况下,授权传递性的执行不充分

3.1 跨云协调不足

  • Flaw1 设备ID泄露04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第2张图片
  • 漏洞2:泄露受委托者云的秘密04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第3张图片
  • 漏洞3:暴露委托者云中的隐藏设备。04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第4张图片
  • 漏洞4:OAuth陷阱04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第5张图片
  • 漏洞5:滥用跨云委派API

在这个演示中,一个恶意的委托(攻击者)滥用飞利浦Hue的跨云委托API来重新获得对飞利浦Hue设备的未经授权的访问。04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第6张图片

4、系统建模与形式化验证

在本节中,我们将详细介绍VerioT的设计和实现,VerioT是我们用于检测现实世界物联网云中委托缺陷的半自动工具。04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第7张图片04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第8张图片

基于上述分析,我们使用状态机M=(A,S,O,T,s0)来描述IoT系统的授权过程。其中,A表示系统中的实体,如设备、云平台、用户;S表示系统的状态,每个状态记录了各个实体的授权令牌集合;O表示授权操作(如表1所示)的集合;T表示系统状态的转移,即在授权操作的驱使下,系统从一个状态转移到另一个状态;s0则表示没有任何授权操作发生的初始状态。

  1. ai (ai ∈ A), we use two data sets, Recvai and Issuai
  2. 状态机M中维护一个访问控制列表,map (tokensmartthings, tokenlifx)
  3. ACLai, consist of 2-tuple(token,T), where token∈Issuai, andT ∈ P(Recvai )

Def

  1. Def.1 State: Sk records token sets and ACL set:04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第9张图片
  1. Def.2 Operation04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第10张图片04《Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation》随笔_第11张图片
  1. Def.3 Transition

T: S×O → S is a function that drives the transition from one state to the next. For example, T(si, OAuth) = s j (where si, s j ∈ S) indicates that an OAuth operation in state si drives the system to state s j.

  • Generating models
  • using the Promela language[32]
  • 配置文件是在检查了这些云的委托操作后手动构建的。具体地说,我们查看云支持的委托操作,并了解每个操作产生的数据流(例如,向用户发布令牌)。这是通过阅读他们的开发人员文档、用户手册和检查他们的移动应用程序的网络流量等来实现的

  • Detecting Flaws
  1.  形式化验证,model checker:  Spin[38]
  1. Def.4 Access Path
  2. Def. 5. Security Property

VerioT.py 是我们工具 VerioT 的源代码。基础模型的源代码位于“baseModel”文件夹中。委托操作模板列于“templates”文件夹中。在“Example”文件夹中,我们展示了现实世界物联网委托的委托设置和验证结果(本文中的缺陷1、2、3和5),包括配置文件(委托设置)、生成的模型和缺陷VerioT 的报告输出。更多详细信息和说明将稍后上传/更新。

你可能感兴趣的:(Iot,物联网)