面向安全D2D共享的移动设备云

用于安全的D2D共享的可扩展且自主的以移动设备为中心的云

摘要

本研究提出了一种高度可扩展、自主且易于实现的以移动设备为中心的云（MDCC）模型，用于安全的设备到设备共享（D2D共享）和以用户为中心的服务。具有特定社会关系的用户通过移动设备连接，并基于短密钥共享机制，由移动设备启动一个自主的微型移动数据中心，并选举出一个代理。该代理负责管理物理网络连接、资源关联以及媒体服务代理，从而配置定量的安全服务等级协议（SLA）以及流媒体质量SLA。在MDCC中的内容所有者或生产者可直接共享数字内容，而无需上传至特定的云服务器。本文实现了两个示例：第一个是视频广播，第二个是通过将DLNA网关与MDCC关联，扩展DLNA局域网的服务覆盖范围，以通过互联网安全地对外发布内容，并从局域网外部获取内容。这两个示例表明，设备到设备共享（D2D共享）在实现高可扩展性和自主性的同时，缓解了传统大型数据中心存在的安全问题焦虑。

关键词 : 移动云计算 Device-Centric cloud User-Centricservice Device-to-Device sharing Information安全

1 引言

传统内容共享通过大型数据中心实现——先上传再分享。然而，由于用户始终不清楚上传的内容会发生什么，且大型数据中心不提供任何保证，因此出现了安全问题。如[1–3]中所述，这些问题包括特权用户访问、合规性、数据位置、数据隔离、恢复以及调查支持。引发这些担忧的主要原因是，内容一旦被上传，内容的生产者便完全失去了对其管理。然而，这正是其基本特性

传统云计算——资源被虚拟化，且资源分配始终是透明的。[4]中提出了一种具有参数(n, k)的安全共享框架，使得云存储服务中的定量服务级别协议(SLA)可以定制。然而，[4]中既不支持移动性，也不支持移动设备之间的基于社交网络的对等共享。[5]中提出的以移动为中心的计算模型“人即服务(PeaaS)”能够生成并维护用户的社会学画像，并可安全地向第三方提供这些画像。用户了解这些画像的访问控制，以贡献于集体社会学信息。然而，我们仍需要一种基于移动设备的云计算架构，以实现由社交网络定义的定量SLA。

本文提出并实现了一种移动设备中心云（MDCC）计算架构，该架构在安全性和服务卸载之间提供了权衡。在此模型中，设备同时作为内容生产者、服务提供者和消费者。在与朋友共享时，例如向单个用户或一组用户流式传输视频，移动设备充当内容生产者和服务提供商。因此，提供服务的用户可以配置待共享内容的访问权限、合规设置、数据分发和日志记录。为了保持一定程度的资源透明性，自主性和可扩展性是首要考虑因素。配置完成后，系统管理和控制对用户透明。当作为消费者接收视频流时，用户无需了解资源状态。例如， CPU和内存使用率、网络拓扑以及带宽分配对消费者保持透明。

与传统的对等(P2P)共享不同，所提出的MDCC模型不仅提供文件共享，还提供IT资源的共享。此外，云设备的分组基于特定的社交关系，这种关系可以即时创建和实施。例如，一群朋友在著名景点附近的一家咖啡店中，希望共享几分钟前拍摄的视频和照片，并获取仍在外面闲逛的人们所分享的多媒体内容。

设备到设备共享（D2D共享）不需要特定服务器。参与设备自行组成一个临时微型云，以提供和获取服务。如果所需服务在微型MDCC中可用，则无需连接互联网。在参与设备中会选举出一个代理来监控资源状态，并在必要时连接互联网。这种自主且动态分组的MDCC也不同于那些依赖近似的小型数据中心供用户订阅的云粒[6–8]。

设备到设备(D2D)共享仍然是一个新兴的研究领域，因此安全问题尚未得到充分解决。以移动设备为中心的云计算的安全性仍然是一个开放的研究挑战 [9]。本文提出的模型结合了资源虚拟化和安全性。使用该模型的人们可以了解正在发生的情况，而无需知道服务是如何以及从何处获取的。因此，传统云计算的安全焦虑通过以下优势得以缓解：

• 社交网络特权用户访问：由于MDCC是基于社交网络配置文件创建的，因此授权和认证由内容生产者用户进行配置。此外，采用(n, k)安全共享，安全性也被参数化为多个级别。
• 移动性下的可靠性：传统移动云计算中的移动性通常指客户端是移动的。在 MDCC中，设备具有多种角色。因此，通过采用(n,k)秘密共享，只要可用份额数量大于阈值k，成员设备的脱离不会导致服务失败。
• 合规性：所提出的架构专用于使用相同已实现APP的便携式设备。该APP调用代理选举过程，随后由代理管理参与设备。
• 数据位置：发布内容以供共享的用户知晓云的物理位置，例如某些景点附近的咖啡店。
• 恢复：用户负责维护其内容，而恢复对于D2D共享而言不是问题。
• 调查支持：所有请求和任务分配都会被记录日志。这些日志可用于后续分析，以检测搭便车行为或恶意软件攻击。通过分析日志也可实现计费。

本文组织如下。第2节介绍系统架构，包括代理的内部队列结构和基本子系统。第3节描述消息协议，包括代理选举、MDCC分组、服务请求转发和执行。在第4节中，对MDCC进行了示例实现，以验证其在设备到设备共享（D2D共享）中的有效性。第5节讨论了MDCC的评估和开放的安全问题。最后，第6节给出结论。

2 系统架构

MDCC系统包含用户设备中的大量资源。我们假设每个用户的资源列表（包括 IT资源状态、数字内容列表和个人信息）均受到（n,k）密钥共享方案的保护。

在初始阶段，首先，n个具有社会关系的邻近用户（发起者）提出其资源列表，以启动一个类似于Facebook中俱乐部或粉丝群的MDCC组。每个资源列表都有一个由（n, k）定义的相应安全级别，并使用密码密钥（PWK）进行加密。来自成员的资源列表的聚合称为MDCC配置文件。发起者拥有足够数量的密钥信息（PWKs），以维持对MDCC的管理。在管理方面，为了适应由于用户移动性或设备故障导致的动态加入和离开系统域等动态变化，我们采用自适应代理机制来应对移动自组织网络中的这些不确定性。此外，由于每个新成员的加入协议对MDCC中所有其他设备都是通用的，因此MDCC具有可扩展性。接下来，我们将在介绍第3节的协议之前，先介绍MDCC中的各个组件。

2.1 成员设备

成员设备配备了Web服务器，使得数字内容可以通过URL地址进行索引。对于 DLNA局域网中的设备，我们在DLNA网关的Web服务器上发布contentlist。因此， DLNA网关成为成员设备，并且还将请求转发给代理，从而使其他设备也能共享使用DLNA设备共享内容。成员在通过代理成功认证后加入群组，并提交其资源列表以与MDCC关联。对于每个受(n, k)秘密共享保护的资源列表，所有其他成员设备都会存储由代理分发的密钥分片和数据分片。当成员中分发的分片数量超过阈值 k时，该资源列表即可访问。也就是说，设备数量大于k时资源列表可用。因此，根据用户离开和物理连接故障等事件，可以定量衡量访问MDCC资源的可靠性。

2.2 代理

MDCC 由代理管理，负责网络连接、成员关联、请求处理、内容搜索和任务分配。如图 1所示，MDCC 代理可基于资源状态从发起者中动态选举产生，或从可信服务器中选定。MDCC 类似于 [6, 7],中提出的由小型业务单元（如咖啡店或诊所）拥有的小型数据中心。但与 [6, 7]不同的是，MDCC 由用户设备自主组网形成，且设备之间共享资源。代理可选择性地连接至互联网。在所提出的架构中，各设备中的内容和计算资源均被虚拟化。

2.3 代理内部架构

如图2所示，内部架构包括请求与任务队列、反馈控制环路和日志单元。反馈控制环路由三个子系统组成，分别为云检测子系统(CIS)、云控制子系统(CCS)和云执行子系统(CES)，它们分别对应经典反馈控制系统中的观察器、控制器和被控对象。CIS、CCS和CES的各自功能描述如下。

(1) CIS — 云检测子系统

CIS子系统接收来自本地虚拟机(VMs)和成员设备的状态更新。作为观察器，它过滤系统状态，包括成员设备的剩余IT资源和多媒体内容分布。然后，它检索并更新MDCC配置文件。因此，CIS数据库变为分布式。CIS写入所观察到的信息提供给CIS数据库，供CCS进行管理和控制时参考。数字内容列表通过URL内容进行索引。对于剩余IT资源的状态，CIS根据每个成员设备的 CPU能力、内存/存储大小、可用带宽和电池电量，分别在MDCC内部以百分比形式进行汇总。

(2) CCS — 云控制子系统

代理的CCS在CIS上确定新MDCC分片向成员的分配，从而完成资源列表的更新。CCS还会定位用于恢复资源列表的分片。然后，CCS通过其CIS数据库检查请求，以确定哪些设备能够为请求成员提供服务。如果请求的服务可用，则将服务成员设备分配任务以提供请求的服务；否则，请求将被丢弃。共享多媒体内容的最简单分配任务是通过内容的URL地址索引的Web服务。请求者在收到代理回复的URL地址后，调用多媒体流媒体服务。CCS会通过CIS的监控检查用于流媒体的计算资源是否可用。因此，在纯流媒体情况下，服务提供商的IT资源通过MDCC代理方案共享给请求者（消费者）。简单的服务等级协议（SLA），如流媒体和视频质量，包含在多媒体流媒体请求中。

(3) CES—云执行子系统

CES是图2中控制环路的执行器。CES提交的主要任务是接收CCS的控制指令和任务分配，然后调用本地虚拟机或将任务分配转发给成员。它使成员对CCS透明，就像它是CCS控制器的单一被控对象一样。实际上，它将本地虚拟机视为其成员。来自成员的任务执行结果和状态更新由 CIS过滤以进行数据库刷新。由于是CES而非CCS执行任务，因此CCS能够在图 2的“请求队列”中处理下一个排队的请求，而无需等待当前作业执行结束。

3 协议设计

在本节中，我们描述了用于MDCC网络虚拟化的消息协议。当成员设备与组关联时，通过将IT资源和多媒体内容汇总到XML列表中，以更新代理的CIS数据库，从而实现虚拟化。CIS是CCS进行资源分配的主要参考依据，用于分配与请求相对应的服务任务。

3.1 代理选举

在对组成员进行分组之前，首先选择代理。代理选择有两种方式。第一种方式如图 3所示，由现有的邻近服务器选择代理，该服务器根据排序后的IT资源状态更新，选择评分最高的设备作为云簇代理。第二种方式如图3（b）所示，通过选举方式进行，所有用户设备广播其资源状态，每个设备都执行与第一种方式相同的评分过程。这两种方式均安全地执行，因为状态消息交换（j, lk）是PWK加密的。评分评估可以考虑多个因素。在本文中，评分结果以选举计算能力最强（CPU性能和内存大小）的设备作为云簇代理。也可以选择其他选择算法来优化不同指标。当选后，该代理同时也是用户设备，会调用其CCS以批准接入和关联请求，并控制CES形成一个以设备为中心的云。如果出现代理离开或故障情况，将重新初始化代理选举。恶意设备无法被选为代理，因为它无法拥有足够的密钥信息来冒充发起者。也就是说，后续的代理仅从MDCC发起者中选举产生。

. 云簇的分组 服务器选定的代理)
. 云簇的分组 当选的代理)

3.2 成员接入

网络接入的准入是成员分组在成员关联之前的第一个阶段。成员设备请求进行物理网络连接的接入。接入由代理执行。代理为每个请求设备分配端口号。设备使用该端口用于后续认证目的。经过认证后，请求设备即可请求与MDCC的关联。

3.3 设备关联

物理网络接入后，用户使用阈值(n, k)对资源的安全级别和访问权限进行量化配置，以便与他人共享。设备信息随后以XML格式收集，供代理参考。除了设备信息外，设备ID还可选择性地包含GPS坐标、网络端口和IP字段，用于后续的认证、授权和计费（AAA）目的。当与群组关联时，如图3所示，成员设备j发出关联请求“Associate req. state(j, lk)”，以上传安全级别为k的资源列表lk。设备j向代理提供其设备ID和对应列表的PWK。代理将每个列表及其对应的 PWK分别分割为n个分片，并将这些分片对分发给所有成员，包括代理自身。CIS数据库记录每个分片的位置，而CCS负责维护这些记录。设备j会在更新事件发生时、按代理要求或周期性地通过请求“Associate req. state(j, lk)”更新其资源列表。在本文中，我们采用事件驱动的方式对数字内容进行更新。

3.4 服务请求与执行

用户输入包含媒体关键词的服务请求以进行内容搜索。如图3(c)所示，该请求使用资源列表的公钥PWK加密后发送给代理，以便在该列表中搜索关键词。当请求被接收并解密后，代理的CCS模块在CIS数据库中搜索该关键词，该数据库记录了MDCC配置文件共享位置。本文未研究数字内容索引方法，因为我们专注于MDCC多设备协作云计算。成功定位请求的媒体内容时，使用资源列表的PWK加密内容的URL，并将其发送到请求设备。该URL包含服务器的端口和标识符。服务设备由代理选定以提供服务。我们注意到，仅在成员设备中分发MDCC配置文件，而数字内容并未分发。内容的所有者或生产者无需发起大量数据传输来上传内容。因此，基于 MDCC的内容共享特别是在移动无线环境中节省了能源。

. 服务请求与执行)

4 系统实现和示例

4.1 虚拟化

我们实现了一个示例性的MDCC，其中用户设备包括手机、平板电脑、笔记本电脑和台式机。云粒由用户终端设备进行分组。MDCC链路可能包含多个物理网络跳数，而每一跳可通过无线网络、3G网络或有线以太网连接。手持设备和平板电脑嵌入了安卓操作系统，而台式机则配备Windows系统。每台设备还安装了Java虚拟机（JVM）、Web服务器和SQL/SQL‐lite数据库系统。Windows系统除了JVM外，还可包含多个虚拟机（VMs）。主要的编程语言为Java，用于实现CCS、内容分发服务器、代理队列架构（图2）以及连接虚拟机的网络虚拟化。SQL服务器充当内容信息系统子系统，所有设备均嵌入Web服务器，通过MDCC发布数字内容。除JVM外，所有虚拟机均由Oracle Virtual Box管理器[10]进行管理。类似于Xen云平台[11],，该管理器为域0，负责管理标识为域1到域n的虚拟机，且所有域均位于一个桌面版Windows物理机（PM）。每个安卓系统只有一个虚拟机，即Java虚拟机。每个虚拟机（无论是否为Java虚拟机）均充当代理或成员。

4.2 系统操作

如图 4 所示，我们实现了四种系统主要操作，包括网络接入、成员关联、请求转发和服务执行。网络接入基于网络虚拟化，其中虚拟机（VM）相互连接。在建立初始网络连接后，每个VM成员以XML格式广播其资源列表，以选举代理。随后，被接纳的VM成员使用代理分配的端口将其自身的CIS SQL数据库与代理的CIS SQL数据库同步。此过程完成成员关联。接着，用户通过在安卓图形用户界面中输入关键词和可选的媒体质量来发起请求。流媒体请求包含源虚拟机 ID（IP、端口、GPS坐标）、超时、关键词和质量。代理利用关键词和质量构成查询，在成功检索资源分片、恢复资源列表并定位具有可用IT资源的服务器虚拟机后，将内容的URLs返回给请求的VM。否则，代理将在超时设定后返回不可用通知。

4.3 示例

我们通过三个示例说明，所提出的MDCC架构具备利用成员资源进行动态任务卸载的能力，从而能够轻松应用现有的安全技术。

示例（1）视频多播 。虚拟化支持不同类型的设备通过不同的物理网络连接实时共享多媒体内容。物理环境如表1所示，其中可以看到使用了不同的网络接口。手机1被选举为代理。由于只有手机2拥有该视频，它被分配为多播服务器。用户转入特定的广播频道或输入其请求，这些请求将被转发到代理，代理和服务器随后在CIS数据库查询成功的情况下，向所有请求设备提供所请求视频的统一资源定位符。通过Java服务API，视频访问会自动开始，同时服务器端的流媒体任务在后台运行。请注意，如果客户端数量变得很大，服务器的能耗将会很高。一旦客户端数量超过阈值，代理就会将中继任务分配给当前的一个客户端，以将其视频数据包转发给后续加入的客户端。因此，多播流媒体任务得以卸载。如图 5所示，一台当选为代理的手持设备正在记录系统操作，而服务手持设备正在进行多播任务。

表1. 参与示例1中MDCC的设备
| 设备 | 笔记本1 | 笔记本2 | 手机1 | 手机2 | 平板电脑 |
| — | — | — | — | — | — |
| 网络接口 | 以太网 | WiFi | 3G | WiFi | WiFi |
| 媒体文件 | none | none | none | 视频.mp4 | none |
| PM操作系统 | Windows XP | Windows 7 | 安卓 | 安卓 | 安卓 |
| VM | JVM | JVM | JVM | JVM | JVM |

示例（2）实现通过广域网的DLNA/UPnP共享 。传统上，DLNA/UPnP功能仅在部署了 DLNA设备的局域网内部可用。所提出的MDCC支持通过广域网访问DLNA/UPnP资源互联网。局域网外的视频也可供DLNA设备访问。表2列出了本示例中使用的设备。我们将DLNA网关配置为成员设备，并在其内部嵌入一个Web服务器，使得局域网中的每个多媒体文件均可通过Web服务器发布。我们使用一台台式电脑作为代理，其中CIS数据库由DLNA网关和一台3G手持设备（手机1）进行更新。为了展示网络虚拟化，台式电脑部署在KH市，而DLNA局域网和手持设备位于TP市。这两个城市相距约360公里。DLNA局域网与互联网共享视频的结果如图6(a)–(e)所示，分别为代理接收到的XML格式的资源列表更新、代理对 XML的解析结果、代理处记录的查询响应日志、匹配请求关键词“jay”的返回 URL，以及客户端（手机1）解码的视频流。对于向DLNA局域网共享其视频的设备，发往DLNA网关的请求会被转发至代理。然后，在查询成功后，3G手机中视频文件的URL将通过DLNA网关返回给请求设备。结果显示与图6相同，只是视频和IT资源的内容不同。这两种共享方向的处理方式相同，这表明无论资源位于何处，资源都被虚拟化。

表2。参与示例2中MDCC的设备
| 设备 | 台式电脑 | 手机1 | 电话 2 (DLNA 网关) |
| — | — | — | — |
| 网络接口 | 以太网 | 3G | WiFi |
| 媒体文件 | none | Video2.mp4 | jay1.mp4, jay2.mp4 |
| PM操作系统 | Windows XP | 安卓 | 安卓 |
| VM | JVM | JVM | JVM |
| 位置 | 高雄（KH） | 台北（TP） | 台北（TP） |

. 代理从DLNA网关接收资源列表（XML）)
. 资源列表的解析结果显示“hello”，以允许DLNA网关加入MDCC)
. 代理处查询成功的日志)
. 对“jay”的查询成功后返回的URL结果)
. 请求设备上显示的视频)

5 评估与讨论

5.1 可扩展性与自主性

从上述示例可知，MDCC 是可扩展的，因为代理可以尽可能多地将成员设备进行分组，而这些成员包括单个设备、虚拟机甚至局域网（DLNA）等多种类型。如果通过部分 MDCC 成员中继多播，则视频共享也具有可扩展性。其自主性优势来源于管理由在移动设备中选举出的代理执行。网络接入认证和资源关联在 MDCC 中均由代理完成。未来，各设备可自行配置授权，例如媒体文件的有条件访问，该配置将成为 XML 资源列表的一部分。根据 IT 资源使用统计以及共享媒体文件的大小，还可实现计费功能。

5.2 复杂度

管理复杂性源于将每个资源列表状态(j, lk)划分为n个分片split(j, lk, m)，以及对这些分片进行加密、解密和分发。对于一个具有n个成员（包括代理自身）且每个成员平均拥有l个列表的MDCC，需要向n个成员分发n²l个分片。由于每个资源列表的数据量远小于多媒体文件，因此由管理开销引起的能耗和延迟不会大于将多媒体文件上传至传统云中心所导致的能耗和延迟。代理承担大部分管理任务。将开发能量感知的代理选举和分组方法以实现公平性和更好的能源利用。

5.3 MDCC中的开放安全问题

大数据中心的订阅用户普遍存在的安全焦虑在于：无法了解共享内容如何配置访问权限，不清楚这些内容如何存储以及存储在何处，不确定是否提供恢复程序以及如何进行恢复，也不清楚访问历史如何被记录。这种焦虑主要源于内容上传至大数据中心后，用户便失去了对其的控制。MDCC 在资源虚拟化与安全之间提供了折衷方案。由于数据从产生之初就由用户保持控制权，因此现有的安全技术可用于保障 MDCC 计算环境的安全，尽管虚拟化程度有所降低。具体而言，以下安全技术可应用于 MDCC：

• 虚假和有害文件 ：在MDCC中，用户成为发布者，类似于应用程序开发者作为发布者[12]。发布的内容可能包含恶意的可执行文件。最简单的解决方案是禁止共享可执行文件。许多电子邮件系统不允许将可执行文件作为附件，这种情况十分常见。
• DDoS攻击 ：来自分布式用户的大量请求会降低MDCC的性能并浪费能源。在代理中，入站请求采样时间以及在采样时间间隔内根据请求数量设定的配额限制提供了一种解决方案。此外，MDCC 会根据频率阈值，解除关联并分离那些频繁超出配额限制的设备。
• 代理替换和来自感染病毒的代理的拒绝服务攻击 ：一个感染病毒的发起设备可能在选举中赢得代理位置。随后，它持续将任务分配给某些特定设备，以消耗这些设备的IT资源和能源。成员可采用类似于[13]中提出的代理评估机制，排除恶意代理设备，并重新启动MDCC分组过程。

MDCC仍然存在许多开放的安全问题，例如避免搭便车、AAA完整性、数字版权管理以及防范恶意Web服务器的钓鱼、URL重定向、恶意JavaScript注入等。本文并不旨在解决移动计算所面临的所有安全问题。然而，我们实现了 MDCC，使其更有可能应用传统安全技术。

6 结论

我们提出了移动设备中心云（MDCC）计算，以实现安全的设备到设备（ D2D）共享。与需要特定服务器的传统P2P不同，MDCC是自主组网的，成员设备动态关联。MDCC也不同于使用小型数据中心的云粒。设备会自主选举一个代理，该代理通过关联协议管理物理网络连接和资源虚拟化，进而规范安全服务代理。两个示例——视频多播和通过互联网实现DLNA/UPnP共享——表明， MDCC能够轻松地在成员设备之间卸载流媒体任务，并突破了传统的“先上传 后分享”模式。MDCC缓解了通过大型数据中心共享内容时的安全担忧。然而， MDCC仍存在一些开放的安全问题，例如搭便车、AAA机制的完整性、数字版权管理等。未来，将继续发展强健的安全技术并对MDCC进行定量分析。