物联网智能医疗细粒度访问控制

最新推荐文章于 2025-11-24 14:29:01 发布

原创最新推荐文章于 2025-11-24 14:29:01 发布 · 993 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#物联网 # 智能医疗 # 访问控制 # 细粒度 # 能力机制

关于面向基于物联网的智能医疗系统安全的细粒度访问控制架构设计

物联网（IoT）正在推动新型且具有成本效益的应用程序的发展，有望为患者和医疗机构提供更高效、更优质的医疗服务。这包括将智能“事物”作为医疗传感器连接到患者身上，以实时传输数据。然而，在医疗领域，患者数据的安全始终是一个重要问题。在大规模部署物联网赋能的智能医疗系统时，一个特别的问题是需要保护这些智能“事物”免受未授权访问。常用的访问控制方法，如基于属性的访问控制（ABAC）、基于角色的访问控制（RBAC）和基于能力的访问控制，单独使用时均无法为物联网赋能的智能医疗设备提供完整的安全访问解决方案。例如，这些方法可能需要过于集中的架构或导致策略库规模过大而难以管理。为解决这些问题，我们提出了一种新颖的访问控制架构，通过减少大规模医疗系统中所需的认证策略数量来改善策略管理，同时实现细粒度访问控制。我们设计了一种结合属性、角色和能力的混合访问控制模型。该模型利用属性进行角色成员分配和权限评估，角色成员资格赋予用户相应的能力，所签发的能力可根据用户的不同属性进行参数化，并用于访问物联网“事物”提供的特定服务。我们还提供了该模型的形式化规范及其实现描述，并通过不同的用例场景展示了其应用。最后，给出了本架构核心功能的评估结果。

1 引言与背景

随着物联网（IoT）[2]，医疗系统的快速发展，医疗系统正变得更快、更可穿戴、更易于访问，并且能够远程使用。以往的医疗系统被设计为专用环境，而现在必须在开放式系统环境中运行[3]。如今的医疗系统可以包含一系列可穿戴设备和智能传感器，用于自动收集、存储和报告健康相关信息，并辅助诊断和治疗[19]。随着智能移动设备（如智能手机、PDA等）数量的不断增加，出现了大量与可穿戴设备兼容的医疗应用，目前已有近165,000+种医疗应用可供使用[14]。在医疗领域中，对物联网解决方案的需求预计将持续增长，医务人员正依赖这一技术高效且安全地访问患者数据。

在物联网环境中，专科医生在医院探视患者时可能会携带自己的智能设备，并希望在其上查看连接到患者身上的传感器输出，而医生或医护人员可能使用医院签发的设备。同样，该医院的护士可能希望查看并控制与患者相连的传感器输出，但其访问权限级别可能与专科医生或主治医生不同（参见图1）。医疗系统需要包含能够支持各种所需访问的策略和访问控制机制。当考虑到现代医疗环境中各类医护人员、患者和数据的范围时，可能出现的多种访问级别便显而易见了。

在智能医疗系统中，管理和跟踪谁（例如用户和设备）连接并访问什么（例如系统和资源）非常重要。因此，需要构建鲁棒、可扩展且安全的医疗保健系统[29]。特别是对这些可穿戴设备（以及相连的医疗设备）的未授权访问可能会侵犯患者的隐私，并对组织的资源造成潜在威胁。支持物联网的医疗设备需求日益增长[27]。这些设备连接到患者身体，通过各种医疗应用（例如Cue[4]和Medtronic[17]）定期监测其健康状况，并通过无线介质（例如IEEE 802.15.4）进行通信。

示意图0

数字世界与物理世界的融合为医疗保健带来了改善，但也引发了众多安全问题和隐私挑战[15]。物联网设备具有低功耗、内存受限和处理能力有限的特点，这意味着通过这些设备实施重量级安全机制是不切实际的。从通信角度来看，异构网络环境、无线介质、终端设备的高度移动性、动态网络拓扑以及通信基础设施的可用性，都是部署安全解决方案的主要障碍[28]。

一些研究探讨了将常用的访问控制措施应用于物联网的适用性，例如使用基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）以及基于能力的访问控制。RBAC 使用角色来管理用户与策略之间的关系。它向特定角色授予权限，用户被分配为相应角色的成员，而不是直接向用户授予权限。然而，在动态且大规模的系统（如物联网）中，显式地识别并分配用户到角色是困难的。此外，在智能医疗系统中，可能存在大量用户和短期交互，这使得此类重量级访问控制机制不适用。因此，在此类系统中仅通过 RBAC 实现访问控制策略是无效的。

与基于角色的访问控制（RBAC）不同，基于属性的访问控制（ABAC）根据系统实体（例如用户、资源等）的“属性”做出访问控制决策。它还可以通过使用用户的属性（例如位置、职务等）来提供一种上下文感知的用户-角色分配方法。然而，在ABAC中，若不部署庞大的策略库，很难实现细粒度访问控制。在物联网（IoT）环境中，这意味着我们可能仍然面临大量things数量规模带来的困难。

基于能力的访问控制方法（例如，基于身份的能力 [7], 分布式基于能力的访问控制机制（DCapBAC）[10]）可用于提供细粒度访问控制，并且由于对things的低要求，已被建议用于物联网系统。一种capability可被定义为一种可传递的、不可伪造的授权令牌 [8]。它与一个对象（唯一标识）以及对该对象的一组访问权限相关联，允许持有该能力的用户访问资源。尽管能力提供了一种细粒度的访问控制方法，但若没有额外的策略管理方法，为每个用户可能访问的每个资源都分配一个能力是不可扩展的。此外，所有这些系统（除了一些最近提出的能力型方案，例如 [10] 外）往往都是高度集中式的，这对于物联网赋能的智能医疗系统来说未必是理想的模型。

上述访问控制方法的一个常见问题是，它们各自并未明确设计或适用于在实际的物联网场景中管理设备、用户或策略的可扩展性。假设所有需要访问的用户身份都已预先知晓，并且所有策略规则都应在系统中先验地单独记录（例如，负责每位患者的专科医生的身份），从而以个体方式处理策略管理，在物联网情况下是不现实的。尽管ABAC可用于动态场景以应对用户可扩展性问题，但策略管理的复杂性，尤其是在细粒度层面上，可能令人望而生畏。RBAC可用于在角色关系中扩展用户规模，但通常需要预先识别授权用户及其能力，以便为每个用户生成唯一的权限；而这些能力伴随着众所周知的管理难题。

本文提出了一种面向物联网赋能的智能医疗保健系统的访问控制方法，该方法结合了基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）和能力机制，以实现细粒度且灵活的访问控制，同时最小化需要创建和维护的策略数量。首先，在第2节中我们给出了一个使用案例的概要。接着，在第3节中探讨了我们提出的访问控制架构。在第4节中，我们讨论了模型设计及各种访问场景。我们在第5节描述了详细的实现，并在第6节给出了性能评估结果。在第7节中，我们介绍了相关工作，并在第8节对全文进行总结。

2 用例示例与解决方案概述

考虑一个通过智能things控制患者监护和治疗交付的医疗机构。各种设备和传感器将被连接到患者（即可穿戴设备）身上，并由医疗专业人员（以及可能的其他人员）进行访问。在图2中，我们展示了该场景。这些设备和传感器可以在患者入院时或在医疗机构停留期间的任何阶段分配给患者。当设备和传感器被分配给患者时，它们将在系统中注册，包括记录其被分配给哪位患者。对传感器的访问将取决于医疗机构的策略，这可能包括不同用户对同一设备具有不同的访问级别（例如，护士可能只能读取药物输送设备的数据，而医生则可以更改剂量）。以下参与者涉及本场景，且医疗保健流程基于澳大利亚 [21] 的医疗护理制度。

患者：接受医疗治疗的人。
医生：初级保健医生。他们在患者前来就医时，可提供适当的初步建议。
专科医生：专门从事某一医学领域的医生，例如心脏病专家、神经外科医生等。
护士：定期检查患者健康状况并提供医疗服务的医护人员。
家属和朋友：探望患者的个人。

在我们的场景中，我们希望为不同的参与者提供对患者医疗传感器及其所提供数据的不同级别的访问权限，同时保护患者的隐私。为了简化问题，我们假设不同患者的物联网things具有不同的关联访问控制策略，并且这些策略存储在一个集中式系统中。然而，策略的执行是在things内部本地完成的，这既是为了利用此类系统的边缘智能优势，也是为了避免中央系统出现性能瓶颈。在真实的医院环境中，可能有数百名医生、护士和其他医护人员，以及数千名患者，每位患者都连接着多个传感器。没有任何一位医务人员能够访问所有患者的所有传感器。可以设想的是，甚至没有任何一位医务人员能够访问单个患者的所有传感器，即使可以访问，不同医务人员的访问级别也可能各不相同。以下是两个体现这种复杂性的示例。

医疗专科医生（如心脏病专家）应仅能访问其负责患者的相关信息。如果医生A正在治疗患者爱丽丝，医生B正在治疗患者鲍勃，则医生A只能访问爱丽丝心脏传感器的读数，而医生B只能访问鲍勃心脏传感器的读数。
护士可能被分配到特定病房。病房中的每位患者可能都连接有一组标准传感器，此外还可能有针对其特定病情的传感器。护士应能够访问其所在病房内所有患者的标准传感器，但不能访问其他病房患者的传感器。

采用类似于[8]的方法，我们建议使用能力作为凭证来管理对things的访问。问题在于如何在保持最少数量的访问控制策略的同时，制定并分发这些能力。考虑在第一个示例中策略可能如何编写，以及权限如何授予（即能力如何分发）。存在多种可选方案：

(1) 一种简单的解决方案是创建一个“心脏病专家”角色，为其成员提供一种能力，允许访问所有“心脏监测仪”类型的传感器。这将允许每位心脏病专家访问每位患者的心脏监测仪，从而侵犯患者隐私。

(2) 每项能力都可关联一个在访问时进行评估的测试，以确保患者处于出示该能力的专科医生的治疗之下。这将增加things上的处理和带宽需求。证明专科医生与患者之间关系的相关凭证必须提供给thing，并对其上的任何签名进行验证。签名验证是最耗时的操作，因此任何此类额外操作都会显著影响性能。

示意图1

应避免对things提出需求，尤其是在每次访问时都需要进行检查的情况下。

(3) 患者特定角色，例如可以创建“爱丽丝的心脏病专家”和“鲍勃的心脏病专家”，这些权限仅授予对特定患者传感器的访问权限。这将满足专科医生只能被授予其患者传感器访问权限的需求。然而，管理和生成大量类似策略将十分困难且耗时。此外，事先收集这些信息也可能很困难（考虑到医生-患者组合的数量庞大且具有动态性）。

一个更可取的替代方案是采用第一种选项，但向能力颁发系统提供额外的信息，即证明专科医生与患者之间关系的凭证。返回给用户的能力将仅授予对指定患者的访问权限。实际上，这些能力通过所提供的额外信息进行参数化，其方式类似于 [16]中的角色参数化。尽管仍需验证凭证上的签名，但这优于第二种选项，因为签名只需在颁发能力时由中央策略管理系统检查一次，而无需每次使用时都检查；且中央策略管理系统的处理能力远强于各个独立的things。这些things只需验证能力上的签名，而无需同时验证能力和凭证的签名。该解决方案同样满足第二个示例的需求，但在这种情况下，用于参数化的信息将是一份确认护士被分配到特定病房的凭证。在这两种情况下，things都需要在中央系统中注册，并附上其所分配的患者以及该患者当前所在病房等属性。

请注意，能力颁发系统实际上会根据相关策略存储所定义的能力模板。在颁发时，这些模板会被填入相关信息，例如有效期和适当的参数化信息。

3 拟议的访问控制架构

3.1 架构组件

在图3中，我们展示了拟议的访问控制架构。它由以下组件组成：用户设备（UD）、事物（TH）、中央管理系统（CMS）和事物注册存储库（TRR）。CMS包括角色管理器（RM）、能力目录（CD）和策略管理单元（PMU）。PMU包括评估引擎（EE）和策略数据库（PD）。

目标实体通过TRR在系统中注册。目标实体将发布其服务。当用户设备首次检测到所需服务时，会联系CMS以获取所需的凭证（能力）。CMS将检查目标实体在TRR中的注册信息，并根据其组件维护的策略提供所需的凭证。

用户设备（UD） ：一种属于特定人类用户（例如医生、医护人员、家庭成员等）的智能移动设备（例如智能手机、PDA等）。用户设备能够与目标实体（TH）进行交互。用户设备存储用户的属性（例如姓名、身份证等）以及被签发的能力。用户所持有的属性由可信权威机构签发。
事物（TH） ：智能物联网设备，例如附着在患者身上的传感器。TH 能够验证能力。一旦做出授权决定，就会向 UD 发送一条响应消息（即允许或拒绝）。在我们的架构中，这些设备在内存、电池和计算能力方面均属于资源受限型。为了减少策略信息扩散并提高用户的隐私性，TH 不了解用户的角色或其拥有的属性。
中央管理系统（CMS） ：CMS 是我们架构的核心组件。它与用户设备（UD）通信，接收属性并发放能力，同时对这些能力进行签名。CMS 由角色管理器（RM）、能力目录（CD）和 PMU 组成。
角色管理器（RM） ：存储角色、角色层次结构以及角色到权限（能力）的映射。角色管理器是一个集中式（例如基于云）的服务器，因为在资源受限的物联网设备中实现其功能是不可行的。与大多数基于角色的访问控制系统不同，系统不显式维护角色到用户的映射。相反，每个角色都关联有属性规则，并存储在策略数据库（PD）中。能够满足这些规则的用户将被授予与该角色相关的权限。
能力数据库 (CD) ：存储能力模板，这些模板用于根据参数化规则创建实际的能力。已撤销的能力列表也存储在CD中。
策略管理单元 (PMU) ：验证相关策略（例如角色成员资格/继承或能力参数化）。它包含以下两个组件：
- 评估引擎 (EE) : 通过查找角色成员资格必须满足的属性规则，检查用户提供的属性是否符合这些规则，并创建所请求的能力，来评估用户对能力的请求。
- 策略数据库（PD） ：存储授予角色成员资格并定义能力参数化的属性规则。
事物注册存储库（TRR） ：存储特定网络域中每个目标实体的身份证和属性。当目标实体加入或离开网络时，事物注册存储库会动态更新。

3.2 通信协议

在图4中，我们展示了满足用户请求的协议。目标实体（TH）使用IEEE 804.15.4蓝牙低功耗（BLE）信标或类似协议，向附近的用户设备（UD）广播其提供的服务（步骤1）。如果用户设备（UD）拥有适当的能力，则通信进入步骤6。否则，用户设备（UD）与CMS通信，指明希望访问的目标实体（TH）和服务，以获取适当的能力（步骤2）。CMS利用角色管理器（RM）和能力目录（CD）找到相应的能力模板，并从PD中提取必要的规则。这用于告知用户设备（UD）必须出示的属性（步骤3）。

这些属性是获取角色成员资格所必需的属性，以及（如果指定）能力参数化所需的其他属性。假设用户设备（UD）代表用户持有能够满足需求的属性，它将这些属性和用户身份发送给CMS（步骤4）。CMS检查所提供的属性是否满足角色成员资格的需求。然后，通过在能力模板中填入用户身份、必要的时间戳（例如能力生命周期的开始时间和结束时间）以及任何参数化信息，为请求的thing/操作对创建一个能力。需要用户提供身份以确保该能力不会被传递给未授权的用户。随后，该能力及来自CMS的签名被发送到

UD（步骤5）。现在，UD 可以将能力与已签名的请求一起呈现给 TH（步骤6）。TH 将根据算法1中所述检查该能力，包括验证 CMS 对能力的签名以及 UD 对请求的签名，并向 UD 作出响应（步骤7）。

算法1 接收用户提供的能力、请求的操作、用户身份、目标实体（TH）的身份以及请求和能力上的签名。该算法检查当前时间是否在能力的签发时间和过期字段所定义的时间范围内，发起请求的用户是否为被授予该能力的用户，该能力是否允许对所请求的目标实体和操作进行访问，能力中包含的任何条件规则是否满足，以及签名是否有效。签名验证放在最后执行，因为这是最耗时的操作。条件可以涉及上下文信息，例如正确的日期和时间、位置等，或目标设备（TH）自身的属性，例如可用存储、剩余电量，以及其他与目标设备状态相关的条件。这些条件列在能力中，并在终端设备（THs）内部本地进行评估。该算法返回对所请求操作是否允许或拒绝的决策。

输入：能力，目标实体ID，用户ID，操作请求，用户签名(请求)， CMS签名(能力)；输出：权限决策（ PermissionDecision）
权限决策（ PermissionDecision）=”拒绝”；
如果能力不为空，则
如果时间戳有效，则
如果用户ID=能力(用户)成立，则
如果目标实体ID在能力(事物)中，则
如果操作请求在能力 (操作)中，则
如果条件规则=为真，则
如果用户签名有效且CMS签名有效，则
权限决策（ PermissionDecision）=”允许”；
结束
结束
结束
结束
结束
结束
结束
算法1：能力授权过程。

4 模型设计

4.1 不同的访问场景

我们回到第2节讨论的用例示例，基于签发的能力、对终端设备的不同访问操作以及各种条件，讨论不同的访问场景。

4.1.1 场景1：首次访问

在此场景中，一个用户（即本架构中的UD）从目标实体（TH）接收应用程序接口（API）。UD与CMS通信，请求来自特定TH的特定服务。UD需要具备执行某项操作的能力，但我们假设该UD没有适当的能力。用户设备向CMS发送适当的属性以满足角色成员资格。如果满足条件，CMS将颁发能力。用户设备向目标实体请求对操作的访问并出示该能力。目标实体通过算法1检查该能力是否授权了所请求的访问。如果算法返回“允许”，则授予用户设备访问权限。例如，护士C可以使用有效的能力访问鲍勃的临床传感器。

4.1.2 场景2：后续访问，相同的“实体”，相同的操作

在此场景中，用户设备希望对目标实体重复执行之前已获得相应能力的操作。由于用户设备已拥有适当的能力，因此直接向目标实体发起访问请求，并出示该能力。目标实体再次通过算法1验证该能力是否授权了所请求的访问。如果算法返回“允许”，则授予用户设备访问权限。注意，在此场景中不涉及CMS，且用户设备无需获取新能力。例如，医生A在获得能力后，可多次访问鲍勃的心脏传感器，而无需在首次访问后再咨询 CMS。

4.1.3 场景3：后续访问，相同的“事物”，不同的操作

能力可能允许多个操作的访问，且此类能力可用于访问最初请求该能力时所针对的操作之外的其他操作。如果用户设备（ UD）持有的能力允许访问，则参照场景2。

4.1.4 场景4：通过单一能力访问多个“事物”

能力可能允许访问多个TH。在首次访问时，能力的获取方式与场景1相同。对于后续访问，UD会联系新的TH，通过搜索其本地存储的能力数据库来确认是否已持有适当的能力。然后，UD将该能力连同访问请求一并提交，如场景2所示。例如，护士C被允许使用单一能力访问多位患者（如鲍勃和约翰）的体温和血压传感器。请注意，如果该能力允许多个TH以及在这些TH上的多个操作，则对不同TH的访问可能涉及与初始访问不同的操作。

4.1.5 场景5：能力的签发者无效和/或请求上的签名无效

一个用户设备（UD）具有某项能力并希望执行所需的操作。然而，该能力并非由目标实体（TH）所认可的签发者（即 CMS）所颁发。该用户设备将此能力连同访问请求一并提交给目标实体。当目标实体验证能力及请求上的签名时，将拒绝该请求（算法1返回“拒绝”），因此访问不会被允许。

4.1.6 场景6：能力已过期

一个用户设备（UD）拥有一项可允许访问的能力，但该能力已经过期（已超过其结束时间）。如果用户设备检测到此情况，则参考场景1。如果用户设备仍然将其提交给目标实体（TH），则目标实体在检查能力时会发现该能力的过期时间已到。算法1返回“拒绝”。若用户设备希望获得访问权限，则需要为所需的特定访问请求一个新的能力，获取方式可参照场景1。

4.1.7 场景7：验证本地条件

一个能力可能包含必须由目标实体在授予访问权限之前进行验证的条件规则。条件可以涉及上下文，例如正确的位置、日期和时间、位置等，或目标实体（TH）自身的属性，例如可用存储、剩余电量以及与目标实体自身状态相关的任何其他条件。因此，当用户设备（UD）向目标实体（TH）发送能力时，除了上述所有检查外（参见场景1），目标实体（TH）还会检查该能力中的条件规则。如果条件规则验证成功，则允许访问（算法1返回“允许”），否则拒绝访问。

关于面向基于物联网的智能医疗系统安全的细粒度访问控制架构设计

4 模型设计

4.2 形式化规范

4.2.1 基本概念

我们提出的模型包含以下组件：R、A、Capt、C、U、T、O、Cla 和 E（分别对应角色、属性、capability templates、能力、用户、things、操作、类和 environment）。我们将一个 Cla 表示为一个用于设计和构建应用程序对象的可扩展程序。我们需要以下映射：

RCapt : 角色集合 × 能力模板，一种多对多的角色到能力模板的分配关系。
ClaO : Cla × O，一种多对多的类到操作的分配关系。
ClaT ：Cla × T，一种从类到终端设备的一对多分配关系。
CaptT ：Capt × T，一种从能力模板到终端设备的多对多分配关系。
CaptO ：Capt × O，一种从能力模板到操作的多对多分配关系。
CaptC ：Capt → C，一种从能力模板到能力实例的一对多分配关系。
UC ：U × C，一种从用户到能力实例的一对多分配关系。

请注意，存在与 CaptT 和 CaptO 相对应的 CT 和 CO，用于将能力实例映射到终端设备和操作。CO 直接继承自 CaptO，其中能力实例映射到由 CaptO 为其所源自的能力模板定义的操作。能力实例通过 CT 映射到的终端设备是 CaptT 中对应映射的一个子集，该子集由参数化规则和提供的属性确定。

UAk (1 ≤ k ≤ K)、 TAm (1 ≤ m ≤ M) 和 EAn (1 ≤ n ≤ N) 分别是为用户、属性集合和环境预定义的属性。其中 K 表示用户属性的数量，M 表示属性集合属性的数量，N 表示环境属性的数量。我们采用 [33] 的方法。

用户 u、事物 t 和环境 e 的属性分配关系（ATTR）分别为 ATTR(u)、ATTR(t) 和 ATTR(e)。其中，

ATTR(u) ⊆ UA₁ × UA₂ × ⋯ × UA_K
ATTR(t) ⊆ TA₁ × TA₂ × ⋯ × TA_M
ATTR(e) ⊆ EA₁ × EA₂ × ⋯ × EA_N

我们在模型中使用三条基于属性的策略规则：

角色成员资格规则 ：用户属性与环境属性的布尔函数 f(ATTR(u), ATTR(e))。每种角色都存在此类规则，用于实现角色到用户的映射，规定用户（u）在特定环境（e）下成为该角色成员所需具备的属性。可表示如下：
策略规则：Role_Membership(u, e) ← f(ATTR(u), ATTR(e))
能力参数化规则 ：一条规则，用于指定在给定用户提供属性的情况下，可通过从能力模板（Capt）生成的能力访问哪些目标实体 things。可表示如下：
策略规则：能力_参数化(u, Capt) ← f(ATTR(u), Capt)
条件规则 ：这是由属性集合 things 和环境属性 f(ATTR(t), ATTR(e)) 构成的布尔函数。它决定用户 (u) 是否可以在特定环境 (e) 下访问某个终端设备 (t)。这可以表示如下：
策略规则：条件(t, e) ← f(ATTR(t), ATTR(e))

4.2.2 能力结构

在我们的模型中，采用以下能力结构。一个能力模板简单地由 t、o 和 CoR 字段以及相关的参数化规则组成，其他字段在创建能力时生成。o 和 CoR 字段被复制到新能力中，能力的 t 字段可能是模板对应字段的一个子集，具体由能力参数化规则规定。

<能力实例id, 用户id, 签发者id, 签发时间, 过期时间, 终端设备, 操作, 签名, 条件规则集>

其中：

Capid ：能力 ID，是每个能力的唯一标识。
Uid ：用户 ID，是指被授予该能力的特定用户的唯一身份标识。
Issid ：颁发者 ID，是签发能力的实体的唯一身份标识。
Isstime ：颁发能力的时间，即能力签发给用户的时间。
Exptime ：已颁发能力将过期的时间。
t ：这表示一个类 ID（cl ∈ Cla）或一组相关的 things ID，其中所有 things 均为同一类的实例。需要注意的是，t ⊆ T 且，
t = {clid} if clid ∈ Cla {tid₁, tid₂, ..., tidₙ} if ∃clid ∈ Cla → ∀tidi ∈ {tid₁,...,tidₙ}, tidi ∈ ClaT(clid)
o ：这标识了一组可在能力允许访问的 thing(s) 上执行的 <operations> 。需要注意的是，o ⊆ O 且，
o = {oid₁, oid₂, ..., oidₙ} if ∃clid ∈ Cla → o ⊆ ClaO(clid)
需要注意的是，此处的类 ID（clid）与 t 所讨论的类 ID 相同。
Sig ：这是能力签发者的数字签名。它保护能力的完整性，防止被伪造或篡改。
CoR ：条件规则的集合。如何解释多条规则（例如是否必须全部满足，或只需满足其中一条）由 things 自行决定。重要的是，CoR 引用本地上下文，例如目标实体的位置（如建筑物中的特定房间）或日期和时间。

与其他采用重量级 XML 结构的能力结构（例如 [8]）相比，我们使用 JSON（JavaScript 对象表示法）。以下是能力的一个示例：

{
  "Capid": "jXEPy0U FLzC4oa4ROYTCRTS39",
  "Uid": "SN 12348484",
  "Issid": "medical#organisationA",
  "Isstime": "0506171200",
  "Exptime": "0506181200",
  "t": "heartsensor#patient1",
  "o": "read",
  "Sig": "jJhbGciECEF0OSQVMiLC0eXApS",
  "CoR": [
    {
      "date": "20170606",
      "loc": "e6a360"
    }
  ]
}

5 实现

我们已经构建了设计的初步实现。由于智能终端设备（TH）及其通信代表了系统中资源最受限的部分，因此我们重点研究了用户设备（UD）与终端设备（TH）之间的通信以及在智能终端设备内对能力的检查。我们使用 HTC Desire 626G+ 智能手机作为用户设备（即客户端）。我们采用 ESP8266-12E 微控制器来实现终端设备（即资源受限设备），因为这些设备经过高度优化，能够在低功耗和低内存消耗下保证高性能。ESP8266-12E 具备现成可用的无线网络连接，并完全支持 TCP/IP 协议栈。它配备了一个可扩展速度的 32 位 RISC CPU（60–160 MHz）、42 KB 内存和 4 MB 闪存。目前，CMS 正在一台具有以下配置的惠普笔记本电脑上实现：2.5 GHz Intel Core i7-6500U（双核，4 MB 缓存，睿频加速最高可达 3.1 GHz）、Intel HD Graphics 520、8 GB LPDDR3 SDRAM（1,866 MHz）以及一个无线接入模块。该设备运行 Ubuntu Server 12.04.5 LTS-32 位操作系统。然而，架构的其他部分（例如 RM、PMU 和 TRR）可以轻松地通过资源丰富的服务器端应用程序构建，例如可以使用 Firebase [6] 云托管。

该实现包含一个物理测试平台，用于测量用户设备（UD）与终端设备（TH）之间的访问控制性能。

在 TH 中运行的代码是使用 nodeMCU（一种基于 Lua 的固件 SDK）开发的。Lua 是一种高级语言，能极大地促进设计和实现，但其生成的代码不会经过优化，因此所获得的结果是保守的。我们已在 EPS8266-12E 中实现了能力检查的策略（参见算法 1）。我们的主要目标是在资源受限的 TH 中实现一种能够基于能力做出决策的去中心化授权机制。我们使用 AES 算法（128 位密钥长度）进行安全通信，使用 RSA 算法验证能力签发者（即 CMS）和请求者（即 UD）的签名。我们采用 MD5 消息摘要用于身份验证。如上所述，我们选择 JSON 作为能力令牌的格式。UD 和 CMS 使用 RESTful（表述性状态转移）客户端服务器技术实现。

6 性能评估

在本节中，我们展示了对系统核心部分的性能评估结果——用户设备（UD）与智能终端设备（TH）之间的通信，以及终端设备（TH）对能力的评估。由于终端设备（THs）是系统中资源最受限的组成部分，因此确保我们的架构需求不会给系统带来无法管理的负载至关重要。

我们考察了多个场景，包括第 4 节中描述的场景，涵盖访问被允许和被拒绝的情况，并涉及目标实体（TH）检查不同数量条件的情形。为了验证我们模型的可行性，每次测试均运行 100 次以确保数据可靠。为展示本方案所耗费的时间，所有无关因素均被排除在外，例如由其他网络流量引起的延迟。这使我们能够准确展示本方案所产生的负载/延迟。每次成功或失败时，都会向用户设备（UD）发送相应的消息（如允许或拒绝）。注意，所有时间均以毫秒（ms）为单位显示。

图 5 显示了能力在算法 1 的初始测试中失败的情况，即当前时间是否落在能力的签发时间和过期时间字段所定义的有效期限内。这代表了终端设备在向目标实体出示能力后，目标实体响应的最短时间。结果表明，此阶段的中位时间为 0.542 毫秒（μ = 0.540, σ = 0.003）。

图 6 显示了两个结果：（i）当时间戳有效但能力不适用于目标实体时，此阶段的中位时间为 0.564 毫秒（μ = 0.564, σ = 0.003）；（ii）当时间戳有效，能力适用于目标实体，但该能力不允许对目标实体执行有效操作时，此阶段的中位时间为 0.577 毫秒（μ = 0.578, σ = 0.003）。这些结果仅比图 5 中的结果略长。第二个结果比第一个结果耗时更长，因为在判断所请求的操作是否被能力允许之前，必须先进行并完成能力是否适用于目标实体的测试。

”表示在所有先前检查均成功后，条件返回为真所花费的时间。类似地，“Fail(ts,con)”表示所有先前检查均成功但条件不成立时所花费的时间。)

图 7 显示了检查单个条件的结果。右侧结果为条件检查失败时的情况，左侧结果为条件检查通过时的情况。出于比较目的，排除了签名验证。请注意，此处的时间相当比之前的情况稍长，尽管仍然只有几毫秒，因为条件检查涉及一些初始化设置。此处检查的条件是：作为存储在 TH 中的字符串表示的 TH 的位置是否满足“条件规则”中表达的要求。

当条件评估为真时所需的中位时间为 2.87 ms（μ = 2.861, σ = 0.003），当条件评估为假时的中位时间也为 2.87 ms（μ = 2.861, σ = 0.003）。结果相同（至少在显示的精度范围内）是预料之中的，因为在进行此测试之前必须检查所有其他字段，而无论条件成功或失败都需要执行大致相同的操作。这两种情况下所需的中位 RAM 和 ROM 分别为 15 KB 和 9.2 KB。

图 8 展示了当需要检查的条件数量在 1 到 4 之间变化时的结果。在所有情况下，所有条件均返回真值，以确保检查完成。第一个条件与图 7 中的相同，以便进行比较。第二个条件检查当前时间是否处于条件规则中指定的时间段内，第三个条件检查日期，第四个条件涉及检查目标实体中的剩余电量。需要注意的是，在第一个条件之后增加额外条件的检查所增加的时间非常少，且所有情况下的设置相同。检查一个条件所需的中位时间为 2.87 毫秒（μ = 2.873, σ = 0.003），两个条件为 2.87 毫秒（μ = 2.877, σ = 0.003），三个条件为 2.885 毫秒（μ = 2.885, σ = 0.003），四个条件为 2.894 毫秒（μ = 2.894, σ = 0.003）。同样，我们排除了签名验证。对用户设备响应的总时间小于三毫秒。类似系统，例如 [10]，将涉及等效的签名验证，即两次验证：一次是针对用户设备在请求上的签名，另一次是针对 CMS（或等效系统）在能力上的签名。文献中这些操作的最佳耗时为使用椭圆曲线密码学 (ECC) 的签名验证耗时约为 300 毫秒（[10] 给出的数据为 288.18 毫秒）。如果在我们的结果中包含两次此类验证的时间，则这些并非我们研究重点的签名验证时间将完全掩盖我们方案中各项功能所消耗的时间。这表明，我们的方案并未给物联网环境下所有基于能力的访问控制方案所必需的基础签名验证带来显著的额外开销。

7 相关工作

Moosavi 等人 [18] 提出了一种面向物联网的、支持移动性的安全医疗保健方案。该方案采用数据报传输层安全协议（DTLS）实现终端用户认证和授权。然而，策略管理不在该项工作的范围之内，而是简单假设用户拥有有效的凭证。尽管他们的方法与本文所提出的方案明显不同，但其 RAM 和 ROM 开销处于相同数量级。Tarouco 等人 [31] 研究了通过由简单网络管理协议（SNMP）或网络服务支持的无线网络/蓝牙网关实现的物联网医疗系统中各类用户与设备之间的互操作性问题。他们的方案基于一个 SNMP 代理，作为用户设备与智能传感器之间的代理。访问控制将通过该代理实现，但仅给出了高层描述。

Ren 等人 [26] 和 Lee 等人 [11] 等采用椭圆曲线密码学（ECC）来保护医疗系统。使用 ECC 可以使高强度加密变得更加实用和可行，因为它减少了公钥密码学的密钥长度和计算开销，但这些方案并未考察访问控制的更广泛问题，例如策略规范与管理。Liu 等人 [12] 提出了一种结合了椭圆曲线密码学（ECC）与基于角色的访问控制（RBAC）的物联网系统访问控制模型。ECC 用于实体身份验证过程中的密钥建立，而 RBAC 用于管理访问控制策略。他们的 RBAC 使用方式高度集中化，所有决策均由中央服务器作出，并且需要预先获取所有信息。他们的方案中没有等同于我们方法的设计，即允许先前未知的用户通过提供适当的属性来获得访问权限。

各种方法例如 [1], [30], [23] 在医疗系统背景下使用了基于角色的访问控制（RBAC），有时还与其他访问控制机制结合使用。例如，[1] 将 RBAC 与自主访问控制（DAC）和强制访问控制（MAC）相结合。其中 RBAC 用于为系统内的参与者分配角色，并采用 MAC 方法进行整体安全标签管理，患者则通过 DAC 风格的访问控制列表来管理对其数据的访问。[23] 在基于 Kerberos 的票据授予系统中将 RBAC 与基于活动的访问控制相结合，以实现对患者医疗记录的访问。然而，这些提案均未涉及在医疗保健环境中对基于物联网的传感器的访问控制问题。张和田 [35] 提出了一种结合 RBAC 和安全相关的上下文信息（如时间、位置、环境等）的访问控制模型，适用于物联网系统。但与我们的方案不同，他们并未提供系统架构，也未详细讨论访问决策的具体执行位置，这意味着该系统可能是高度集中式的，而这对于物联网而言并非理想解决方案。

徐等人提出了一种基于物联网的紧急医疗服务数据访问设计 [32]。尽管该模型展示了如何灵活地收集、整合和互操作物联网数据，以支持紧急医疗服务，但它仅将访问控制抽象为模型中业务活动层的一部分。

Mukherjee 等人 [20] 和 Ray 等人 [25] 提出了一种基于属性的访问控制方法用于医疗保健数据，但该方法针对的是中心化数据存储，而非可能作为此类数据来源的物联网传感器数据。张和刘 [34] 提出了一种基于属性的访问控制模型，以实现对物联网系统的细粒度访问控制。该模型允许根据用户属性、资源属性、环境属性以及当前任务，将权限分配给用户以访问资源。尽管他们的框架包含了策略决策点和执行点，但与我们的系统不同，这些组件在系统中的具体实现位置并不明确。此外，在他们的设计中，策略还必须基于明确的用户身份预先编写。

一些方案讨论了面向物联网和医疗保健的基于能力的访问控制。这些方法通过向用户提供访问令牌（即能力），使智能物联网设备能够验证访问权限，从而实现针对单个用户需求定制访问控制，并避免完全的集中式系统。古斯莫里等人 [8] 提出了一种面向物联网的基于能力的访问控制方法。埃尔南德斯-拉莫斯等人 [9] 提出了类似的方法，描述了一个面向物联网设备的分布式基于能力的访问控制框架。这些设备内部实现了高度优化的椭圆曲线数字签名算法（ECDSA），以确保端到端认证、完整性和不可否认性。然而，尽管这两种方案在能力结构和处理方面提供了详细说明，但均未涉及能力分发问题，也未说明定义哪些用户可访问哪些能力的信息应如何存储。它们仅假设存在一个能力颁发者。马哈尔等人 [13] 和翁迪埃格等人 [22] 提出了本质上相似的物联网访问控制能力型方案。值得注意的是，前三种方案均在能力中包含主体身份，以便验证发起访问请求的用户身份。

我们的系统在先前的基于能力的访问方法基础上进行了扩展。通过允许能力授予对多个 things 的访问权限，我们减少了系统所需的能力数量。在之前的方案中，能力是针对特定设备的。更重要的是，我们讨论了用户如何获得能力。通过提供属性来实现角色成员资格，简化了角色定义，并避免了预先知晓每个可能用户身份的需求。能力参数化允许从同一个能力模板创建不同的能力，这再次简化了策略库的建立。鉴于物联网系统中可能存在大量用户和 things，以及它们之间的大量关系，这种减少对于构建可管理的策略库是必要的。考虑到医疗保健环境中患者数据的敏感性，对策略库的管理以确保仅允许预期的访问，是一个至关重要的考虑因素。

8 结论与未来工作

访问控制、策略执行和身份管理是开发安全的物联网赋能的智能医疗系统中最重要的一些问题。我们提出了一种结合 RBAC、ABAC 和能力机制优势的访问控制架构。属性既用于角色成员资格决策，也用于参数化能力，从而在最小化策略规范的前提下实现细粒度访问控制。该架构具有灵活性，因为角色成员资格基于属性，而不是预先确定用户被分配到哪些角色。这使得策略规范具有一定程度的灵活性和简洁性，这是大多数其他已提出的系统所无法实现的。属性的使用在条件规则提供了额外的细粒度控制。能力的参数化使得策略规范能够应用于多个用户-thing 关系，而无需提供不必要的广泛访问权限，也无需进行大量的策略开发。该架构为部分去中心化，通过让资源受限的物联网 things 负责验证能力，从而有效利用其资源。另一方面，角色的管理由中央管理系统执行（在实际系统中可能存在多个），因为该系统所管理的信息会超出物联网设备的存储和处理能力。

我们的结果表明，这种基于资源受限物联网 things 的去中心化授权系统可以作为大规模物联网系统的完全集中式授权系统的替代方案。去中心化授权所需的时间对于更广泛的物联网系统部署而言是可行的，并且在资源受限设备的能力范围之内。限制因素仍然是签名验证，而本系统独特功能所需的时间要求比采用椭圆曲线密码学的签名验证技术的最新水平低两个数量级。尽管本系统仍然需要此类验证，但在提供灵活且细粒度的访问控制时并未增加显著的额外资源需求。还值得注意的是，在许多情况下，用户设备与中央管理系统之间的通信将不再必要，因为我们的能力机制可以在不降低安全性的前提下，使用户访问多个智能 things。

在未来的工作中，我们将扩展系统的实现，例如通过在条件指定方面增加灵活性，并优化代码，从 Lua 转向更高效的编程语言。本文工作中我们使用了 HTTP，但目前我们正在使用约束应用协议（CoAP）重新开发该架构。我们还将研究所提出架构中的信任与身份管理问题。