3285本作品采用知识共享署名国际4.0许可协议进行许可。移动网关物联网协作的安全风险及其防范摘要周新安加州大学河滨xzhou114@ucr.edu美国加利福尼亚州里弗赛德卢义兴印第安纳大学布卢明顿luyixing@indiana.edu美国印第安纳州布卢明顿嘉乐观guanjia@iu.edu印第安纳大学布卢明顿分校美国印第安纳州钱志云加州大学河滨zhiyunq@cs.ucr.edu美国加利福尼亚州里弗赛德完全不连接到服务器/云，并且此类设备被管理移动即网关（MaaG）是一种流行的功能，它使用移动设备作为网关，将物联网设备连接到云服务进行管理。MaaG物联网访问控制系统支持远程访问共享/撤销，同时允许 实现这些功能需要云服务、配套应用程序和物联网设备之间的安全合作。 出于实际考虑，我们发现几乎所有的云服务都执行访问模型转换（AMT），将富有表现力的云端访问策略转换为简单的设备端策略。在此过程中，ad-hoc协议的开发，以支持访问策略同步。不幸的是，目前的MaaG物联网系统未能认识到访问模型转换和同步过程中的安全风险。 我们分析了10个顶级MaaG物联网设备，发现它们都有严重的漏洞，例如，允许临时用户不可撤销地和永久地访问。我们进一步提出了一个安全的协议设计，抵御所有已识别的攻击。CCS概念• 安全和隐私→嵌入式系统安全;软件逆向工程;·网络→网络架构。关键词物联网;访问控制;攻击;协议;形式化证明ACM参考格式：Xin2022年。移动网关物联网合作的安全风险和缓解。在2022年ACMSIGSAC计算机和通信安全会议（CCS '22）的会议记录中，2022年11月7日至11日，美国加利福尼亚州洛杉矶。ACM，纽约州纽约市，美国， 15 页。https://doi.org/10.1145/3548606.35605901引言物联网设备具有不同的互联网连接能力和模式。许多先前的作品[54]研究了物联网设备，CCS©2022版权归所有者/作者所有。ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560590通过本地控制台，例如移动电话。 最近的工作[20，22- 25，29，30，32，38，40，51，56，58，68，70，82，85]研究了利用现代物联网云基础设施进行方便的访问管理和部署的物联网设备，并且这些设备通过内置Wi-Fi/蜂窝模块或通过本地互联网连接的物联网集线器（例如具有蓝牙功能的Zigbee或Z-Wave兼容的物联网集线器）连接到云/互联网。 对设备的访问（例如，从用户的移动电话发送的操作命令较少研究的是一种新兴的物联网设备类别，旨在利用现代物联网云基础设施（例如，用于集中式用户管理、方便的设备固件更新），但缺乏持久的互联网连接。为了降低功耗、制造成本和维护成本，这些设备没有内置Wi-Fi/蜂窝模块（Wi-Fi显示消耗的功率是蓝牙的7倍[59]），也不需要一个持续的专用互联网连接物联网集线器来连接到云。相反，这些设备利用用户 我们将这种范例称为移动即网关（MaaG）物联网（图1）。尽管MaaG物联网很受欢迎[15，77，78]，但其安全和隐私风险尚未得到充分理解，更不用说充分缓解了。图1：MaaG IoT架构MaaG IoT固有的新安全挑战。先前的作品[13，36，50]研究了设备-网关-云（DGC）物联网，这与本文研究的MaaG物联网架构相似。特别地，[13，36]示出了在存在网络分区的情况下难以将许可撤销策略从云同步到IoT设备（例如，由于故意阻止设备访问互联网或互联网中断）。然而，现代MaaG物联网在野外已经变得更加复杂（比DGC）其设计带来了新的基本安全挑战。特别是，与之前研究的基于云的物联网不同，3286···CCS其中设备保持持久的Internet连接，表1：不同MaaG IoT设备的安全模型云和对设备的所有命令/请求都是访问的-在MaaG IoT中，设备和云划分安全责任，因此需要协调其安全控制，以确保整个系统的安全（未经授权/意外用户不应操作设备）。例如，诸如Kwikset Aura [2]的流行物联网锁管理/维护不与云共享的访问代码（用于解锁）（因此云或通信信道的妥协不会危及家庭的物理安全）。同时，IoT设备利用IoT云来进行复杂的用户管理（用户角色、许可、委托、撤销等），见第3节）。然而，在安全方面，MaaG IoT设备访问管理离线可用性[8]第八章：我的世界&8月[1]RemoteAdmin only[11]第十一话[10][12][13][14][15][16][17][18][19][19]&美国[9]美国[5]&美国[4]&美国[3]云服务、配套应用和物联网设备，很难纠正由于缺乏适当定义的访问控制模型在云和设备的MaaG物联网（模型之间往往有所不同），不明确和不健全的结果他们的联合控制努力可能会出现（见下文）。另一个挑战是缺乏适当的云和物联网设备之间访问策略的一致性模型。 MaaG IoT本质上是网络分区的[13]，设备通常不连接到云来获取最新的访问策略（例如，某个用户的回复例如，人们可能会认为“最终一致性”模型[36]（在恶意攻击者的访问被撤销后，良性用户可以帮助同步访问策略）可能是一个合理的模型。然而，我们发现为MaaGIoT实现这样的模型是棘手的，并且容易出错。此外，即使在设备通过网关连接到云之后，云和设备之间同步的必要策略也从未正确定义，很容易使现实世界的设备处于不安全状态（第5节）。 安全挑战伴随着严重的现实世界安全、隐私和安全影响，但从未得到系统的研究。安全分析和现实世界的缺陷。 为了了解现实世界MaaG IoT的安全影响，我们挑选了10款顶级MaaG IoT设备。在对其自定义协议进行逆向工程之后，我们系统地恢复了与访问模型转换和同步相关的概念模型。这些导致发现可能产生严重后果的几类安全缺陷它们包括（1）允许临时用户保留对设备的永久访问;（2）允许临时用户将其访问权限共享给其他未经授权的用户;（3）允许临时用户升级其权限。尽管过去也曾发生过类似的攻击[36，50]，但我们希望指出，它们所依赖的后果的程度和根源是完全不同的。例如，[36，50]已经证明，恶意临时用户可以保留对智能锁的访问，只要他们可以阻止锁将访问控制策略与云同步-如果良性用户能够帮助锁同步，则临时用户将失去访问。然而，在我们演示的攻击中，临时用户可以永远保留访问权限，即使在云上撤销权限并且相应的我们之所以能取得如此强大的成果，是因为我们对MaaGIoT的基本运营模式有着深刻的理解。安全协议设计。面对MaaG在物联网方面，我们提取了常见的设计目标，以避免我们在现实世界系统中看到的陷阱。然后，我们设计了一个一致的访问控制模型/机制，和一个新的轻量级协议，安全地同步云服务和物联网设备之间的访问策略，而不信任网关，这可以防御我们发现的攻击。捐款. 我们总结了本文的贡献：我们从两个主要方面提炼和阐述了MaaG物联网独特的安全挑战：访问模型转换和访问策略同步。我们研究了10款顶级MaaG物联网设备，发现了一些弱点。 它们允许我们开发一些攻击，实现比以前的结果更强的后果。我们设计并实现了一个专为MaaG IoT量身定制的安全协议它避免了所有常见的陷阱，并且是轻量级的。2背景在本节中，我们首先介绍MaaG物联网设备的两个主要功能，可能是矛盾的功能：远程访问共享/撤销和离线可用性。然后，我们描述了MaaG物联网的常见工作流程。2.1远程访问共享/撤销和离线可用性截至2022年，我们观察到本文中的所有MaaG物联网访问控制系统都已尝试启用访问共享/撤销和离线可用性。但是，不同的系统采用的安全模型略有不同，如表1所示。我们可以看到，除了Ultraloq之外，所有设备都可以原生支持远程访问共享/撤销。这意味着（特权）用户不需要物理地接近物联网设备来共享/撤销对受邀者的访问：她可以简单地将该受邀者添加到云端访问控制策略[ 34 ]。受邀者的应用程序可以稍后要求云认可其访问设备的资格，例如，通过向云认证以获得访问令牌/证书。相比之下，在本地访问共享/撤销中，（特权）用户必须物理地接近IoT设备以共享对受邀者的访问/撤销对受邀者的访问。移动网关物联网协作的安全风险及其防范CCS3287我们还可以看到，所有设备都支持离线可用性：即使用户的应用程序没有互联网连接，用户也可以访问设备 这可以例如使用对由IoT设备直接识别的证书/凭证的访问来完成。离线可用性已成为智能锁不可或缺的功能，因为否则互联网中断或服务器停机可能会将居民锁定在外。有趣的是，有些设备允许低特权的访客用户离线可用，而有些设备只允许高特权的管理用户。无论如何，这一特点是普遍存在的。2.2MaaG IoT的通用工作流程为了实现这两个功能，IoT设备制造商部署云服务来维护通常权威和最新的访问策略，以便决定是否允许用户在某个时间访问设备然而，IoT设备还可以具有其自己的设备上访问控制模型和机制，设备需要这些模型和机制来决定用户代理（即， 伴随应用程序）可以具有访问权，以及实现离线可用性，这可以改进如前所述的可用性。通过MaaG IoT架构，设备制造商这些消息使用诸如蓝牙低功耗（BLE）之类的无线协议传送到设备。 设备还可以具有反馈机制以通知云已经应用了特定的访问策略更新。目前，ad-hoc访问策略同步协议由不同的物联网设备制造商设计，以实现远程访问共享/撤销和离线可用性。图1说明了在MaaG IoT架构中，云服务和IoT设备具有不同但密切相关的访问控制模型/机制。例如，MaaG IoT设备可能具有离线访问代码，允许设备访问而不使用配套应用，其根本不同步到云。云服务、配套应用和物联网设备必须合作，以安全地同步云服务和物联网设备之间的访问策略，从而确保安全的访问控制。 在下一节中，我们将展示MaaG物联网架构具有微妙而严重的安全影响。3MAAG物联网合作中的安全风险概况. 值得信赖的MaaG IoT系统需要在云、配套应用程序和IoT设备之间进行安全合作和协调。在MaaG中，云通常充当发布/管理策略的机构，并且设备是当用户尝试操作IoT设备时强制执行策略的一方（例如，解锁智能锁）。 云可以支持/管理日益复杂的访问控制语义和模型，例如复杂的用户角色[64]，用户之间的委托关系[44，76]以及分组或基于位置的权限[61，65]。同时，设备难以维持云的复杂性的访问语义/策略，这可能过于复杂和昂贵，例如，考虑到功耗[59，81]，延迟/困难，固件更新[35，57，73]，甚至软件开发成本的增加[43]。例如，智能锁可能不需要知道用户用户A的权限是否被用户B授予），只要它可以在用户A试图操作锁时为用户A服务，同时拒绝意外的用户。为了支持MaaGIoT中的访问控制，现实世界的制造商开发了一组协议来将语义丰富的云侧访问模型/策略转换为更轻量级的设备侧访问模型/策略，提出了一种我们称为访问模型转换（AMT）的机制。第4节报告了对现实世界AMT流程的第一次也是最深入的安全分析，并揭示了端到端攻击的基本安全设计挑战。此外，云打算保持设备端策略与云同步，尽管这很困难，因为MaaG IoT本质上具有网络分区和弱一致性的特点。第5节显示，分布式系统中数据同步的先前“最终一致性”模型[ 69 ]为现代MaaGIoT提供了较低的安全保证，现实世界的供应商和利益相关者未能充分理解并提出云和MaaG IoT设备之间的足够访问策略一致性模型，为新的攻击留下了巨大的空间。在本文中，我们将发现的缺陷总结为两类，分别与MaaG物联网场景中的访问模型转换（第4节）和访问策略同步（第5节）威胁模型首先，我们假设云服务和物联网设备是可信的。我们还假设合法用户的移动终端和同伴应用（例如，所有者）是可信的（例如， 免费的恶意软件）。但是，我们假设攻击者的配套应用程序和移动操作系统（例如，临时的和低特权的用户，例如被邀请的客人）可以被任意篡改。例如，攻击者可以root/越狱他自己的智能手机[74，84]，对公开可用的配套应用程序进行反向工程，并修改应用程序。 更具体地说，攻击者可以阅读任何用户手册或面向开发人员的API（如果有），并了解设备、配套应用程序和云服务之间的协议/交互。 这意味着攻击者可以任意复制和更改配套应用程序的逻辑，以与设备和云进行交互。 我们不认为攻击者可以检查或更改设备固件（例如，甚至没有恢复出厂设置）或云端代码[71]。恶意临时用户的目标是尽可能长时间地保留其访问权限，进一步分发此类访问权限，甚至升级其权限。责任披露。在撰写本文时，我们已经向相关供应商报告了这项工作中的每一个产品漏洞，我们已经收到了七家供应商的回复。三个漏洞已经有未发布的CVE编号，四个供应商已经修补了他们的漏洞（例如，August/Yale，Level，and Geonfino）.4访问模型转换MaaG IoT中的一个关键安全挑战是物联网云如何将现代语义丰富的安全策略/模型转换为设备端执行的轻量级策略。通过研究一组CCSXin3288Kwikset云4.如果用户被授权图2：Kwikset AMT流程Kwikset锁我们的研究表明，主流物联网制造商通常难以确保策略转换保留足够的安全语义，因此，物联网设备难以合理地执行访问策略（弱点1，第4.1节）。此外，设备侧访问策略/模型不仅仅是云侧策略的简化版本，并且设备还可以维护不旨在与云完全共享和同步的访问策略，其管理在现实中通常是混乱和脆弱的（弱点2，第4.2节）。4.1缺点1：AMT中的语义丢失虽然MaaG IoT设备通常旨在支持比云更轻的访问模型，但当复杂的云端访问模型转换到设备端时，它应该保持通用的个从未充分定义的安全关键过程。在MaaG IoT中，设备所有者可以管理用户（例如， 管理用户角色，例如管理员、访客;邀请访客并授予他们个性化权限，例如锁定、解锁和邀请其他用户）。这种现代化的访问管理通过IoT配套应用程序（移动应用程序）执行，并且策略在设备制造商的云端维护。1虽然云提供了功能丰富的访问管理，但在MaaG架构中（第2节），当用户尝试操作设备时，是IoT设备执行访问策略（例如，以解锁智能锁），并且为此目的，设备侧保持更简单的访问模型���������。例如，云侧的访问模型包括管理访问角色（例如，��������� 无论它是管理员用户还是访客用户），委托关系������（例如，用户A授权用户B作为访客），以及许可证（例如，锁定、解锁、添加访问代码）电子邮件（例如，电子邮件地址、电话号码或帐户昵称），支持复杂 的用户认证机制（例如，在移动应用程序中输入密码，单击电子邮件中的链接，或2FA [16]）：:=(,, , ,)(1)相比之下，���������（设备端模型）可能不维护用户ID或支持复杂的身份验证（可能是为了简单和缺乏资源/硬件，如I/O[48]）。为了支持访问控制，来自云侧访问模型的用户������������������������的身份和她的许可被转换为秘密凭证的抽象概念和与以下各项相关的属性集合（例如，包括权限），这些都记录在1本文中的“应用”一词设备端访问模型：:=(,)(2)证书认证由云认可（例如， 基于签名，见下文），从而确保设备代表预期/授权用户。当目标用户想要操作设备时，她的物联网移动应用程序会向设备呈现（从云端获得，见下文），设备可以根据存储在其访问模型中的信息做出访问决策。这里的关键问题是，在做出访问决策时，是否有足够的SEM-MANTICS与SEM-MANTICS相称���������在我们的研究中，我们发现，���������和���������通 常 由各个供应商根据他们提供的访问控制功能（例如，基于SmartThings上的位置的分组权限[61]，用户角色等）。在缺乏标准的、有安全保证的机制来转换���������为相应的访问模型的情况下，该访问模型���������具有占用空间小和效率高的特点（本文中称为访问模型转换或AMT），我们发现主流物联网供应商在云和设备之间转换访问模型和策略时通常无法保留相应的语义。我们详细介绍了一些供应商的AMT过程，他们的安全弱点，以及我们的攻击如下。在AMT中丢失了身份我们的研究表明，在缺乏原则性安全指南和方法的情况下，现实世界的制造商������������将用户身份、角色和权限转换到设备端对应方的努力是临时的，很容易出错。图2概述了我们从Kwikset恢复的AMT流程（即， Kwikset Aura智能锁[2]）通过逆向工程Kwikset移动应用程序和应用程序流量。使用Kwikset应用程序的用户首先需要在操作锁之前对其进行身份验证基于BLE 连接（未经认证，基于Just Works [66]），Kwikset应用程序从锁中获取随机字符串（步骤1和2），并将其发送到Kwikset云（步骤3）。基于中的云侧策略，如果用户被授权（例如， 由所有者/管理员授权的访客、租户、雇员），云用用户凭证回复，该用户凭证是由云签名的签名（步骤45&）。锁接收验证（步骤6），验证签名，并且因此确保用户被云授权然后，锁信任用户应用程序，并按照标准BLE配对/绑定过程与移动电话建立BLE绑定，因此她的电话将来可以连接到并操作锁，而无需再次经历步骤1至6。 在这些步骤之后，锁定下降并且仅依赖于BLE绑定来识别经认证的用户。Kwikset的AMT过程中存在多个问题光环锁定，正如我们的研究所发现的首先是失去信任用户身份在网络上，这可能会导致一些后果。BLE1. 请求挑战锁2. Challenge字符串锁定6. cr =σ（rs锁定）7. 构建授权的操作系统范围BLE绑定HTTPS3. Challenge字符串锁定5. cr =σ（rs锁定）移动网关物联网协作的安全风险及其防范CCS3289（）下一页尽管IoT设备仅与已向Kwikset云认证并由云认可的授权用户绑定，但设备侧���������不维护用户������的身份或云已知的用户相关凭证（如上所述）。 相 反 ， 锁 仅 维 护 BLE 级 绑 定 关 系 ， 即 ，__������������，_，���������其中电话表示为���_;_也维护在用户的电话上，以便她将来可以连接到锁，而无需再次请求云（用于离线访问）。请注意，此处的“密码_密码_密码”（例如，JaneDoeNexus6）由攻击者控制的Kwikset应用程序提供，其可以被设置为与云已知的用户身份无关的任何任意值���������（参见等式1），例如，用户ID或电子邮件地址。 这意味着良性“所有者”将无法撤销恶意用户对设备的访问，因为_和原始受信任用户标识之间没有存储任何映射。事实上，根据Kwikset用户手册[7]，当一个良性的“所有者”（或“管理员”用户）表示为如果用户想要撤销用户���������为了尝试清理恶意软件，我们发现恶意软件将不得不物理地进入锁并使用Kwikset应用程序将用户从锁中删除，尽管这仍然是有 问 题 的 。 在 后 台 ， 应 用 程 序 向 锁 发 送 查 询 消 息query_paired_smartphones（通过BLE绑定），检索所有记录的BLE绑定关系（如���_），并显示设备名称（如__），供“所有者”选择和删除。所有者对设备名称的选择被发送到锁，锁相应地��� 问题在于，���������__是不可信的，与用户身份（或云已知的用户凭证������）不可靠相关。在实践中，恶意的被委托者用户（例如，Airbnb/酒店客人[52]，以前的雇员）可以使用欺骗性的设备名称（例如，所有者的名称），因此真正的所有者很容易混淆，无法正确定位被委派者用户，或者错误地认为被委派者已经被删除。在AMT中丢失角色、权限和生命周期控制。上述AMT工艺的问题并没有到此为止。与基于设备中记录的逻辑“槽”号来区分用户角色的Au-gust/Yale锁（参见第5.2节）���������不同，Kwikset访问模型的设计缺乏识别用户角色及其不同权限级别的语义。具体来说，尽管Kwikset云跟踪每个用户���������只有������������“管理员”用户可以邀请其他用户，只有授权的用户可以与锁绑定），在图2中概述的步骤6中，当锁接收到确保用户合法性的凭证时，没有可以描述用户角色或权限的伴随属性。有趣的是，“特权级别”似乎是由应用程序本地记录的 对于低特权访客用户，Kwikset应用程序不会在其GUI中显示特权操作，例如，添加/读取离线访问代码，或从锁中删除其他用户然而，该属性显然是错过了- ing在该设备���������这意味着可能仅临时访问锁的恶意低特权访客用户（例如，Airbnb/酒店客人，访客[79]，前雇员）基本上可以充当“所有者”并发送锁支持的任何特权命令。 这些特权命令实际上可以通过预留工程Kwikset应用程序来获得。进攻。对于Kwikset Aura Smart Lock，我们实施了以下攻击，其中权限较低的访客用户可以执行高权限（即，安全关键）操作。首先，我们使用攻击者的Kwikset帐户（授权为设备的访客用户）和攻击者自己的智能手机充当受邀访客攻击者，将向云进行身份验证并获得访客帐户的相应应用层凭据。然后可以使用未认证的BLE连接将该凭证呈现给锁，以便与锁建立BLE绑定（配对）。一旦BLE绑定建立，攻击者就可以从他的智能手机直接向锁发送命令即使应用程序GUI将不包含用于执行任何特权操作的选项，例如，创建/读取访问代码，我们通过使用动态插装工具修改Kwikset应用程序状态/逻辑（例如，Frida [62]）。具体来说，我们精心制作了BLE消息到包含特权操作的设备，例如，通过发送BLE消息创建/读取访问代码，如newbyte[]{TLV8CommandTxType.CMD_TX_TYPE_SET_ACCESS_CODE，access_code};其中access_code是攻击者控制的访问代码。这有效地打破了只有管理用户才能创建/读取访问代码的安全要求。4.2弱点2：不对称和错位的安全责任在MaaG的设计中，设备端访问模型���������不仅仅是云端模型的简化版本���������。在某些情况下，设备需要维护不打算与云完全共享的访问策略，因此需要适当地协调其安全责任和控制。然而，我们的研究表明，真正的供应商的设计和实践往往是特设的和脆弱的现实。例如，Kwikset锁的所有者或授权的受邀用户可以向Kwikset锁添加离线访问代码（用于在不使用应用程序的情况下解锁，请参见第2节）。具体来说，Kwikset应用程序与Kwikset锁绑定的授权用户（参见第4.1节）可以简单地使用该应用程序指定访问代码，应用程序将访问代码编码为设备特定的命令，并将命令发送到锁以添加访问代码。在后台，记录了���������表示为的离线访问代码。虽然访问代码是安全/安全关键的，但我们发现它������并不是设计/意图与Kwikset云共享的，Kwikset云没有记录锁���������的访问代码。事实上，根据设计，Kwikset云不维护任何可直接用于解锁/锁定Kwikset设备的凭据-���������仅跟踪授权用户是谁，并在需要时帮助他们与设备绑定，如图2所示。这样的设计确实有助于减轻一些安全风险，因此Kwikset云不会成为安全故障的单点：即使云被破坏并泄露了它存储的凭据，攻击者也无法获得访问代码来控制所有Kwikset用户的设备。尽管这种设计带来了安全性方面的好处，但也出现了严重的问题：虽然典型的物联网所有者可能依赖于供应商的应用程序（与云通信）来远程管理物联网3290CCS设备并完全检查设备的可访问性状态（例如，所有当前授权用户、锁定/解锁状态），Kwikset云不能显示在设备上添加了访问代码，即使在恶意的被委派者用户在她停留期间添加了访问代码之后（例如，在Airbnb或度假租赁）。即使在所有者从应用程序������������������撤销被在我们的实验中，我们发现所有者必须靠近锁，所以她的应用程序可以从锁中查询完整的状态���������：应用程序有一个专用的UI来显示已经添加到锁中的访问代码，并允许所有者添加/删除代码。 这种设计在现代物联网使用中有两个实际问题。首先，现代Airbnb主机和酒店服务通常只远程管理客人的访问，并利用供应商的应用程序来管理（添加/删除）用户和授予/撤销访问，而不打算/假设实际去房子。其次，从业主的角度来看了解并提出MaaG云和设备之间的充分一致性模型，为新的攻击留下重大机会。5.1弱点3：访问策略同步中因果一致性定义不充分在MaaG IoT中，当云上有策略更新时（例如，所有者/管理员使用移动应用程序来授予/撤销用户的许可），云需要将策略更新同步到设备，使得当用户试图操作设备时，设备可以实施最新的策略。级别云IoT设备的完整、安全管理被分成两个互补的部分而没有被供应商弄清楚远程IoT管理和本地IoT管理（例如，访问代码的管理必须在本地完成），并且管理任何部分的疏忽（这在现实中是非常可能的）可能使设备处于不安全的、非预期的状态，具有严重的安全性和安全性影响。袭击。我们实施了以下攻击。我们，演戏m1=（u1，p1）m2=（u1，p2）m3=（u1，R）m4=（u2，p3）m5=（u2，R）等级应用程序级锁作为KwiksetAura的授权、邀请用户，首先必须向云认证，并获得有效的凭证，并与锁建立有效的BLE绑定（就像之前的密钥一样）。然后，我们使用攻击者的智能手机通过前面提到的BLE消息直接向锁添加恶意访问代码。 如所讨论的，这样的访问代码不与云同步。我们验证了即使在所有者撤销了我们的访问权限/角色���������后，并且后来从锁上物理删除了我们的BLE绑定，我们仍然可以使用之前安装的访问代码来解锁锁。 这是因为离线访问代码是通过物理插件（与BLE绑定分开）输入的。一个良性的所有者将需要通过BLE查询访问代码列表，然后删除它们。5政策同步在现代物联网使用场景中（例如，远程Airbnb/酒店管理），MaaGIoT中的云和设备必须依赖客人/不受信任用户的电话作为网关来通信和同步访问策略。也就是说，MaaG IoT本质上具有网络分区和弱一致性的特征。因此，MaaG IoT的另一个关键挑战是设计适当的机制来同步云和设备之间的访问策略，以达到足够的一致性。“充分性”和相应的安全假设尚待很好地理解。值得注意的是，尽管经典的正如我们在本节中所展示的，现实世界的供应商和利益相关者未能完全图3：级别锁以Level锁为例（图3）。设备上策略���������维护一组<用户、许可记录，并且云将策略同步消息作为对设备的“更新”发送到设备，例如，以报告创建了新用户的事实对于每个Level用户帐户，都会在Level应用程序中记录一个公钥/私钥对。作为示例，设备所有者可以授予级别云将策略更新作为消息E11发送到用户E11（目的是用户可以锁定/解锁锁，但不能配置锁或邀请其他用户），并且相应地，级别云将策略更新作为消息E11到设备：由云签名的E11包括E11的公钥和许可E11。 请注意，在Level和其他最终一致性模型的设计中[ 26 ]，任何授权用户的应用程序，如果物理上靠近设备，则充当互联网网关来中继消息。在锁接收到RISK1之后，锁记录RISK1的公钥。因此，当用户1使用他的Level应用程序来操作锁时，应用程序用他的私钥签署命令，然后可以被锁识别。另外，所有者可以向同一用户1授予另一许可2（例如，有关锁定配置（如添加访问代码），请参见policy-sync消息2），然后通过删除用户1撤销他的所有权限（请参见policy-sync消息3）。此外，所有者可能授予另一个用户2对设备的访问权，并且稍后撤销他的许可（参见 4、 5）。在真实场景中，策略同步消息（例如，第1、2段），在装置处的裂缝可能是无序的。例如，如果在1003之后接收到1002（例如， 由于意外的网络分区/中断或故意操纵的重新排序，请参阅下面的恶意攻击）- 顺序表示为（ 101，���103，���102）-最终策略移动网关物联网协作的安全风险及其防范CCS3291（）下一页（）下一页（）（）设备中的状态将包括1、2，这违反了安全预期。传统的分布式系统通常利用消息之间的时间顺序因果关系来处理消息到达的不确定顺序，以确保数据对象的旧版本（如果晚于数据的新版本）不会覆盖新数据例如，使用基于向量时钟的最先进的因果关系模型[31，49，53]（由AWS DynamoDB采用，业界领先的分布式数据库[26]），发送方用时间信息 标记消息，如果消息1晚于2接收，则接收方应该丢弃消息（1早于2创建，接收方不应该用1替换2）。2在云和MaaG物联网设备具有更高的逻辑复杂性，无法直接采用先前的、经过行业验证的时序因果一致性模型。 按照前面的示例，尽管创建消息的时间顺序为���1、���2、���3，但无论它们的到达顺序如何，都必须保留���1和���2（ 晚于���2接收的1也应该保留）。因此，看起来MaaG中的策略同步消息之间的因果关系必须具有������然而，���相对于���1和���2接收3的顺序是安全关键的（见上文）。这是因为E13与E11和E12都有因果关系，���虽然R1和R2在逻辑上是相互独立的此外，两组消息E101、 E102、 E103和E104、 E105可能不是安全敏感的（它们涉及两个单独用户的安全策略）;然而，如果云发出消息E106以移除所有用户（或具有涉及E101和E102两者的特定角色的用户），则处理E106（在设备上）相对于五个消息（E101到E105）的顺序是安全关键的（例如，处理 6然后 4将用户 2留在设备上）。因此，这里的设计需要明确定义多个策略同步消息之间的相对逻辑关系，而现有的时间因果模型不足以保证MaaG IoT接入策略同步的安全性。在缺乏深入的安全分析和适当设计的MaaG策略同步机制的情况下，我们的研究表明，现实世界的MaaG供应商和系统未能理解策略同步消息之间的基本逻辑关系，从而为实际攻击留下了机会。 使MaaG策略同步的适当设计进一步复杂化的是确保云对最新设备侧策略状态的感知的目标，因为IoT用户将自然地依赖于云来理解/管理她的设备的状态（例如，使用移动应用程序作为控制台，请参见2在分布式系统中，多个存储/计算节点维护相同的数据对象（作为高可用性的副本），当任何一个节点拥有/接收到数据的更新版本时，它会尝试将数据发送到其他节点，目的是所有节点最终都具有一致的最新版本的数据（也称为最终一致性[69]）。为此，在现有模型中，发送器节点应该将时间顺序版本信息（称为版本时钟）与数据（例如， 基于AWS DynamoDB采用的向量时钟[31，49，53]，业界领先的分布式数据库[26]），版本时钟可以指示数据对象的多个副本之间的因果关系。例如，发送方节点发送方_1发送它接收到的数据对象的多个版本，每个版本伴随有版本时钟_1、_1、_1、_2等 尽管数据对象的多个版本可能不会严格遵循时间顺序到达其他节点（例如，由于网络分区或故障），接收具有暂时较新版本时钟的数据的节点可以忽略稍后接收的具有暂时较旧版本时钟的副本。第1节）。 在Level的情况下（图3），当锁接收到策略同步消息（例如，101，102），它向云（通过作为因特网网关的移动设备）回复响应消息，该响应消息指示特定消息（例如，已接收并在设备上处理同样，这种旨在向云通知设备上的策略状态的响应消息由于MaaG中的网络分区性质而不能基于它们生成的顺序可靠地到达云例如，对2的响应消息 可能比对3的响应消息 更晚到达云（因为设备在MaaG IoT中根本缺乏可靠的互联网连接），即使2和3以正确的时间顺序到达设备。 在这种情况下，云知道在设备处处理的2和3的顺序以及因此知道锁上的真实策略状态是不平凡的。我们发现，对于级别锁，恶意用户（例如，授权的雇员、租户、访客）可以操纵2和3的顺序，或者2和3的响应消息，使得设备上的策略状态将不同于云上的策略状态。袭击。 由于因果一致性定义不充分，作为恶意受邀访客的攻击者可以在使用攻击者的智能手机将消息从云转发到设备时重新排序或重新传输消息。这可能会导致Level锁出现各种意外状态-在这种情况下，攻击者甚至可以在所有者撤销它之后保留它的访问权我们首先做了一个简单的实验，如下所示：当云发出授予攻击者访问权限的初始远程邀请消息（表示为���������������）和稍后���������������删除攻击者访问权限的撤销消息时，如果这两条消息都通过攻击者的智能手机转发，攻击者可以简单地重新排序这两条消息。然后，它将导致���������������首先应用，这实际上对锁没有任何作用，然后���������������消息将允许攻击者随后获得访问权限。然而，更有可能的情况是，在一段时间内分开发送数据包和数据包，例如，一位客人住了在出租屋住几天然后离开在这种情况下，我们表明，攻击者可以首先应用初始的身份验证，并在身份验证后仍然保留访问权限。攻击者所要做的就是在将其转发到锁的同时保存原始密码的副本������������ 稍后，攻击者只需在���������������应用（可能由另一个良性用户）后重新发送它，重新允许攻击者访问。值得���������������一提的是，这些消息确实有时间戳，锁可以看到重新发送的消息与���������������。然而，由于MaaGIoT中消息传递的不可靠性，设备无法期望看到消息按顺序到达，因此仍然会接受较旧的消息，从而实现攻击。讨论值得注意的是，一项相当相关的工作[36]建议采用当云需要将策略同步到设备时，可以应用于MaaG场景的最终一致性模型。然而，基于一些关键假设的方法很难在现代MaaG架构中工作，并且尚未在我们研究的任何设备中采用最重要的是，它假设了云和设备之间完全等效的访问模型 在第3节中，我们展示了现实世界的MaaG云需要维护比设备更复杂的访问模型;例如，设备可能无法对用户进行身份验证或直接维护用户ID，实际上需要一个AMT过程，这很关键，但在[36]中没有考虑。第二，[36]基于相对简单的访问CCSXin3292|||AMT1八月/耶鲁云AMT28月/耶鲁锁图例说明：关键管理员，SN = 0关键访客，SN = 254图4：August在线身份验证协议模型（访问控制列表）与真实设备中的模型（访问控制列表）进行比较，并假设当云上有策略更新时，云将其整个策略发送到设备，这对于资源/功率有限的物联网来说可能很麻烦，而我们观察到的真实MaaG物联网系统并非如此。5.2弱点4：访问策略同步中缺乏冲突我们的研究发现，在缺乏可靠的标准机制来同步访问策略的情况下，MaaGIoT的设计空间中存在各种可能性，攻击者可以利用这些可能性来导致云和设备之间的访问策略冲突。 当冲突确实被引入时，缺乏正确的理解和技术来识别冲突，更不用说在不严重影响可用性和可用性的情况下充分地协调它们了。August Smart Lock [1]和Yale Smart Lock [11]是美国最受欢迎的智能锁之 智能锁市场，在云和利用移动电话作为网关的锁之间具有相对复杂的交互协议（基于他们的美国专利No.2016/0189454 A1 [42]和第三方分析[41]）。该协议提供多种高级功能。特别是提供了两个离线访问功能：（1）应用内离线访问（即使云端暂时宕机或应用失去互联网访问，授权管理员用户的应用仍然可以操作锁），以及(2) 离线访问代码（用于在没有应用程序的情况下解锁，请参见第2节）。我们发现，现代MaaG物联网中复杂的访问控制功能很容易出错，并导致云和设备之间难以解决的访问策略不一致。图4概述了涉及August/Yale云服务、移动应用程序和锁的专利访问管理协议每个锁都带有两个内置的、在出厂设置下与云预共享的持久秘密，即和（分别记录在两个逻辑槽中，槽0和槽254）。（掌声）。在高级别，合法用户可以获取由云利用与她的角色（管理员或访客）相对应的密钥加密的令牌，因此接收令牌的设备可以基于解密令牌所需的密钥来确定她的合法性和角色更具体地，应用发送两个随机数101和102（步骤1）;云服务加密它们以获得令牌102，并将令牌102发送给锁（步骤2和3）;锁解密令牌102以获得101，
