企业官网建设流程全解析

成都php网站制作程序员,有关商业网站的风格特征,长春有什么好的网站制作公司,wordpress访问后台摘要物联网已成为智能生活各个领域的主导现象。联网汽车和车载物联网涉及车辆、交通基础设施或其他实体之间的通信和数据交换#xff0c;是实现智慧城市和智能交通愿景的关键。车载云提供了一种很有前景的架构#xff0c;其中智能对象的存储和处理能力被用于提供即时雾计算平…摘要物联网已成为智能生活各个领域的主导现象。联网汽车和车载物联网涉及车辆、交通基础设施或其他实体之间的通信和数据交换是实现智慧城市和智能交通愿景的关键。车载云提供了一种很有前景的架构其中智能对象的存储和处理能力被用于提供即时雾计算平台。研究人员已经证实了这种新兴车载物联网生态系统中存在的漏洞例如关键传感器的数据被盗以及智能车辆被远程控制等问题。在车联网IoV中安全性和隐私至关重要联网汽车中的电子控制单元、应用程序和数据应仅授权给合法用户、传感器或车辆访问。本文提出了一种授权架构来保护这种实体间交互非预定义的动态系统。我们提供了一种与车联网相关的扩展访问控制导向E-ACO架构并讨论了在这种对时间和位置敏感的环境中车载云的必要性。我们概述了可在 E-ACO 架构各层和授权框架中实施的不同访问控制模型的实现方法。最后我们通过用例说明了云辅助联网汽车和车载物联网愿景中的访问控制需求并探讨了可能的研究方向。1、引言物联网IoT是技术的新时代其愿景是让人类生活更加智能。这一概念已在医疗保健、家庭、工业、交通、电网等多个领域吸引了广泛的应用和服务。据估计到 2020 年物联网设备数量将超过 200 亿台这一数据充分彰显了该技术的规模。如此大规模的智能设备互联和联网所带来的核心资产是大数据通过对大数据的分析可以获取洞察并提供有价值的信息。物联网需要多种技术的支持包括识别命名和寻址、传感传感器设备、射频识别标签等、通信技术蓝牙、WiFi 等、涉及云等硬件或软件平台的计算技术、多种物联网服务以及为终端用户提供功能的应用程序。已有多种物联网架构被提出这些架构包含物理对象、对象抽象虚拟对象、中间件或服务、应用程序和业务层只是在架构栈和术语方面存在差异。云计算也是当今世界的一个重要领域它为多个用户提供了无限的应用程序和资源存储和计算。因此物联网与云的融合对于充分发挥物联网智能对象的潜力无疑是必不可少的因为物联网智能对象的存储、处理和通信能力有限。文献中已通过 “云辅助”“云使能” 和 “云中心” 等术语认可了这种理想的融合。智慧城市和智能交通一直是未来社会的愿景。物联网通过引入联网汽车和车载通信在实现交通智能化方面发挥着重要作用。车载物联网涉及多个实体之间的交互和车对万物V2X数据 / 消息交换包括车对车V2V、车对道路基础设施V2I、车对人V2H、车内通信以及车对云V2C。车载自组织网络VANETs提供了必要的连接性并且通过使用更智能的设备以及云和雾计算基础设施得到了扩展。联网汽车内部和周围的多个传感器相互 “通信”以做出更智能的决策并为用户提供便捷的交通体验。我们对车载物联网的愿景是利用云的计算和存储能力以及虚拟对象的概念例如亚马逊网络服务AWS影子。安全性和隐私一直是物联网应用推广面临的严重问题和挑战。当我们考虑车载物联网和新兴的自动驾驶汽车概念所带来的影响时这些问题的严重性更加凸显。在这一生态系统中联网汽车是最重要但也最脆弱的实体。联网汽车拥有超过 1 亿行代码、100 多个电子控制单元ECUs并且通过车载诊断、驾驶辅助系统和安全气囊等功能带来了广泛的攻击面因此保护这一智能实体极具挑战性。此外智能对象之间的通信车对车、车对基础设施等、移动性以及动态网络拓扑结构使得该系统的安全保障更加困难。车载物联网中的一些潜在风险包括来自智能对象的不可信或虚假消息、数据隐私问题、关键电子控制单元被黑客攻击和控制、联网车辆传感器被欺骗以及恶意软件注入等。美国运输部USDOT和国家公路交通安全管理局NHTSA一直关注车载安全并就此发布了重要的网络安全指南。美国运输部的战略计划还概述了智能交通系统ITS项目的方向和目标。访问控制是防止任何系统中的资源被未授权访问的重要机制。本文重点关注车载物联网和联网汽车我们统称为车联网IoV中的访问控制和授权需求。我们将云和虚拟对象视为云辅助车载物联网的重要组成部分。我们提出了一种面向车联网的扩展访问控制导向架构E-ACO该架构是对最近提出的面向物联网的 ACO 架构的扩展。这些架构之间的主要区别在于引入了集群对象即具有多个传感器的对象以及同一集群对象内的传感器之间或不同对象的传感器之间可能存在的交互。集群对象在联网汽车、交通信号灯或其他安装有多个传感器和电子控制单元的智能设备中尤为相关。我们的授权框架阐述了车载物联网中不同的交互和数据交换场景并提出了在 E-ACO 各层包括物理层、虚拟对象层、云层和应用层的访问控制模型。我们进一步讨论了车联网中不同的基于云或雾计算的架构以及车载云的概念及其相关性。本文还详细阐述了全面的用例和研究方向以说明车载物联网生态系统中授权框架的必要性。本文的结构如下第 2 节讨论与车载物联网相关的重要技术和概念包括联网汽车、车载云、虚拟对象、车联网安全和隐私问题以及 ACO 架构。第 3 节详细阐述了车联网的特点、各种云和雾计算架构以及我们提出的扩展访问控制导向E-ACO架构。第 4 节讨论了具有不同车联网实体交互的授权框架和一些访问控制方法。第 5 节讨论了反映单云和多云系统中访问控制需求的现实世界用例随后在第 6 节提出了一些研究议程第 7 节为结论。2、相关背景车载物联网是一个新兴领域其目标是实现汽车、交通基础设施、行人、家庭之间乃至所有事物之间的联网和通信。这一新兴概念涉及多种新的和已成熟的技术为了理解车联网系统和我们的授权框架有必要对这些技术进行讨论。本节回顾了我们认为是车联网基础且构成我们工作基础的核心组件。2.1 联网汽车车联网的主要目标是实现智能实体之间的互联其中车辆是最重要的实体。正如维基百科所指出的“联网汽车或联网车辆CV是一种配备互联网接入功能通常还配备无线局域网的汽车。这使得汽车能够与车辆内部和外部的其他设备共享互联网接入。” 车辆与基础设施之间的通信、驾驶辅助和自动驾驶、自动制动和紧急呼叫、天气和事故预警、停车场信息、电子收费以及预测性维护等都是当今联网汽车中最受欢迎和已实现的功能。为支持这些功能这些汽车配备了 100 多个电子控制单元和 1 亿多行代码。联网汽车配备了控制器局域网CAN总线、FlexRay、以太网和其他协议用于车内电子控制单元之间的通信。消息会广播到连接到总线的所有电子控制单元。多个总线通过网关通常是远程信息处理控制单元TCU连接该网关还提供与外部环境的接口。这些车辆生成、交换和处理大量数据通常被称为 “车轮上的智能手机”。联网汽车中一些最容易被黑客攻击和暴露的攻击面包括安全气囊电子控制单元、蓝牙、轮胎压力监测系统TPMS和遥控钥匙。随着具有广泛攻击面的车辆连接到互联网它们容易受到远程恶意活动的攻击。网络攻击可以从车载网络、车内用户使用智能手机发起也可以从附近的外部实体发起甚至通过云发起。2.2 车载云文献中提出了车载自组织网络VANETs以支持车对车和车对基础设施的通信为驾驶员提供先进服务。车载自组织网络中的网络节点汽车、基础设施等配备了存储、计算和通信模块以提供这些服务。然而这些车载资源中的大部分在现有提供的应用程序中通常未得到充分利用可以为相关方提供额外服务。车载云VC的概念应运而生它融合了车载自组织网络和云计算这两个独立的理念。云计算以基础设施即服务IaaS、平台即服务PaaS和软件即服务SaaS的形式提供了无限的存储、计算或网络资源这些资源被扩展到车载自组织网络提供的联网汽车和基础设施中。车载云利用汽车和基础设施的协同车载资源为有需要的用户提供 “即时云” 服务。车联网的愿景要求实体之间进行协作以实现顺畅高效的交通流并为驾驶员提供信息娱乐服务。所有这些应用程序都具有本地相关性需要对信息进行时间和位置敏感的计算以避免在中央云中加载和处理信息时出现延迟和带宽问题。因此周围的车辆可以形成自主云以解决驾驶员关于前方交通或附近停车场的本地相关查询。已提出了多种车载云形成架构例如固定车载云、与固定基础设施相连的车载云或动态车载云每种架构都有不同的形成场景。区分传统云与车载云的关键特征是车辆的移动性、敏捷性和自主性车辆是车载云中的计算和存储节点。在车载云中周围的车辆会选择一辆车作为代理该代理协调特定地理边界内例如 2 英里半径内车辆之间的资源共享。代理向相关当局申请云形成许可并向邻近车辆发送资源共享请求。一旦获得当局机动车管理局DMV或交通机构的批准这些车辆就会汇集其资源形成一个所有车载云用户共享的虚拟环境。此外在地震等紧急情况下可以建立大规模的车载云联盟在传统云无法访问时提供临时基础设施。我们认为车载物联网将涉及单个或多个云 / 雾计算实例支持不同的服务模型软件即服务、平台即服务和基础设施即服务。这些实例可以根据不同的用例利用中央云、1-2 英里半径内的雾计算实例甚至每个联网汽车级别的雾计算实例覆盖广泛的地理区域。这些架构可以是公共的、私有例如由汽车制造商拥有或混合的并且涉及单个互联网云、车载云、雾计算实例或它们的任意组合这将在第 3 节中进一步讨论。2.3 虚拟对象车载物联网的信息物理生态系统包含异构对象这些对象具有不同的运行条件、通信技术和功能。此外对象连接性、可扩展性、对象和服务发现、安全性和隐私、质量管理以及识别等相关问题是任何物联网系统都面临的挑战。为了解决这些问题多种物联网架构中引入了虚拟对象的概念。亚马逊 AWS 物联网也将虚拟对象纳入为设备影子在物理设备未连接的情况下其对应的虚拟对象即影子将存储最后接收到的状态或期望的未来状态信息。因此每当物理设备与其虚拟实体连接时它会更新为其虚拟对象的状态并缓解对象连接不稳定的问题。微软 Azure拥有设备孪生即 Azure 物联网中心为每个连接的设备维护的 JSON 文档用于存储设备状态信息。物理对象和虚拟对象之间存在不同的关联场景无论物理对象提供多少服务和功能一个物理对象对应一个虚拟对象而对于具有多个服务的对象同一物理对象的每个服务可能对应多个虚拟对象。同样根据不同的用例需求还可能存在其他配置例如多个物理对象对应一个虚拟对象或多个物理对象对应多个虚拟对象。虚拟对象的创建和位置主要在云中其通信采用 RESTful 技术。由于虚拟对象的创建会存在高延迟和低带宽问题对于车载物联网等实时应用我们设想将虚拟对象放置在靠近物理对象的位置即雾计算层或车载云中。2.4 安全和隐私问题大多数安全漏洞如特洛伊木马、缓冲区溢出漏洞利用、恶意软件、勒索软件和权限提升等都可能被利用来攻击联网车辆和其他车联网实体。联网车辆拥有 100 多个电子控制单元攻击面广泛既与车载系统交互又与包括 WiFi、蜂窝网络和互联网在内的各种外部网络交互以实现与服务站、收费公路、加油站以及多个汽车和售后市场应用程序之间的数据交换这对安全性构成了巨大挑战。最近特斯拉 Model X 被黑客攻击过去还发生了许多其他攻击事件。在车联网和联网汽车中安全性至关重要诸如刹车失灵等攻击甚至可能导致人员伤亡。已有多项研究和报告阐述了车联网中智能实体可能面临的潜在风险和攻击。正如所讨论的联网汽车和车联网中的一些网络攻击示例包括用户冒充以交换虚假的基本安全消息BSM或关于事故的虚假信息、窃取个人数据或信用卡信息、控制联网车辆的关键传感器、获取车辆和驾驶员的行驶轨迹、欺骗联网汽车的传感器、对基础设施的协同攻击、未授权的空中固件更新以及向联网汽车植入勒索软件等。用于内部电子控制单元通信的控制器局域网总线也必须受到保护以防止数据被未授权获取以及电子控制单元和传感器系统上的软件被篡改。未授权方一旦获得总线访问权限就可以阻止合法消息并传输非法消息。车载设备OBEs与控制器局域网总线集成向参与实体提供车辆速度和制动系统状态等信息。这使得我们必须回到保护车辆内部组件的问题上以确保车对车、车对基础设施和车对万物消息的合法性。保护车联网和联网车辆需要保护控制系统车载诊断OBD端口、控制器局域网总线等、保护信息娱乐系统、保护智能手机应用程序、保护基础设施、保护空中更新以及保护硬件免受手动篡改。考虑到车联网具有动态拓扑结构、移动限制和大规模网络等固有特征安全机制的实施变得非常困难。美国运输部发起了智能交通系统ITS项目旨在实现车辆与其他智能基础设施之间的通信同时确保相关方的安全和隐私。实体之间交换的基本安全消息不得包含个人身份信息并且必须在有限的地理区域内广播。专用短程通信DSRC用于在实体之间交换信息多个安全和其他应用程序利用该技术为驾驶员生成警报。因此此类消息的机密性和完整性至关重要以便驾驶员能够信任其来源和其中的信息。安全凭证管理系统SCMS已被提出旨在通过公钥基础设施PKI方法确保信任和消息安全其中证书颁发机构CA生成的证书与基本安全消息相关联以确保通信实体之间的信任。欧盟网络与信息安全局ENISA也于 2017 年发布了一项研究列出了智能汽车中的关键资产、威胁、潜在风险并提出了良好实践主要分为政策和标准、组织措施以及安全功能三类以确保智能汽车免受网络威胁。欧盟委员会建立了协同智能交通系统C-ITS部署平台以推动协同、联网和自动驾驶车辆的发展并发布了安全框架和证书政策文件。美国国家标准与技术研究院NIST还为信息物理系统CPS提出了一个框架该框架涉及信息物理系统的概念化、实现和保障包括安全性和互操作性。2.5 ACO 架构一般来说所有提出的物联网架构都具有三层对象层、中间件层包含多个子层和应用层。最近阿尔塞赫里Alsehri和桑杜Sandhu提出了一种物联网架构称为访问控制导向架构ACO该架构考虑了物联网中的访问控制需求并在各层整合了相关模型。如图 1 所示ACO 架构具有四层 —— 对象层、虚拟对象层、云服务层和应用层用户和管理员在对象层和应用层进行交互。由于我们提出的面向车载物联网的扩展 ACO 架构将在第 3 节中讨论是对基于通用物联网的 ACO 架构的补充 / 完善因此我们将在下面概述 ACO 架构的各层。图1、ACO架构对象层ACO 架构的最底层由物理智能设备组成例如传感器、射频识别标签、信标和电子控制单元这些设备负责数据传感和收集并将数据发送到上层。这些设备可以使用不同的通信技术包括蓝牙、WiFi、紫蜂Zigbee、局域网LAN和长期演进LTE与其他设备通信。物理设备使用超文本传输协议HTTP、消息队列遥测传输MQTT、数据分发服务DDS或受限应用协议CoAP等协议与其对应的虚拟对象通信。用户也可以在该层直接访问物理对象。虚拟对象层如前所述虚拟对象是物理对象的数字对应物即使物理对象未连接虚拟对象也能维护其状态。ACO 架构建议将虚拟对象层作为中间件的一部分以支持异构对象之间的通信并克服物联网在可扩展性或 locality 方面的挑战。云服务层随着物联网设备数量的激增数据的存储和计算将在云中进行不同的应用程序可以利用这些数据做出有价值的决策。可能存在单云或多云场景以支持它们之间的联盟或可信协作。一些重要的物联网云平台包括亚马逊 AWS、微软 Azure 物联网中心和谷歌云物联网核心。应用层物联网系统为终端用户提供的应用程序位于该层这些应用程序利用下层云服务层的服务和功能。用户和管理员可以通过这些应用程序远程向下层的智能设备发送命令和指令但这种交互必须通过其他两个 ACO 中间件层云服务层和虚拟对象层。管理员还可以通过该层为各种物联网资源定义访问控制策略。3、云辅助车载物联网智慧城市和智能交通的愿景将联网汽车和车载物联网视为重要组成部分。车联网的最终目标是整合车辆、基础设施、智能事物、家庭乃至所有事物以促进高效交通、事故安全、燃油效率等并为驾驶员提供愉悦的出行体验。该技术涉及车辆之间V2V、车辆对人V2H、车辆对云V2C、车辆对基础设施V2I等之间的通信以交换车辆远程信息处理数据并收集周围环境信息为用户提供服务。车联网中的安全应用需要在智能实体之间交换基本安全消息BSM这些消息包含与车辆状态和预测路径相关的车辆位置、行驶方向、速度等信息。这种交互可以使用专用短程通信DSRC技术类似于 WiFi安全且可靠进行该技术允许车联网中各元素之间进行快速通信每秒高达 10 次以满足终端用户应用程序的需求。3.1 特点和云架构车载物联网继承了物联网在云中进行数据共享、通信和积累的固有特征。然而动态拓扑结构、动态通信、移动性、网络规模和非均匀节点分布如图 2 所示是区分车载物联网与其他物联网领域的一些特征这些特征带来了新的安全和隐私挑战。此外车载物联网领域的多个应用程序对时间和位置非常敏感例如来自邻近车辆或交通信号灯的关于交通拥堵的基本安全消息或关于桥面结冰的信息或向附近医院发送的事故报告等使得车联网生态系统极具动态性。车联网包含基于移动性、功能或处理能力的不同类型的对象如图 3 所示。一些智能对象是静态的例如餐厅外的信标或智能交通信号灯上的传感器而移动对象包括联网汽车、携带智能手机的行人等。此外其中一些是具有单个传感器、仅执行一项功能的独立对象而另一些是具有多个相关传感器的集群对象。联网汽车配备了多个电子控制单元和传感器因此被称为集群对象而汽车中的单个电子控制单元通常仅执行一项功能属于独立对象。这种分类是必要的因为它决定了我们的访问控制框架和模型。智慧城市智能交通倡议中设想了联网汽车和车载物联网的多个应用包括以下内容图2、车联网识别特征图3、IoV中的智能对象类型安全与辅助通过车辆与基础设施之间的机器对机器M2M通信这些应用程序提供关于其他车辆和交通的实时信息以控制车速、车道内位置控制或来自路标指示牌的道路施工警告。此外在恶劣天气、非理想驾驶条件或视线盲区情况下即使是携带智能手机的行人也可以与驶来的车辆交换安全消息例如在过马路时。诊断与维护制造商或授权机械师对车辆进行远程诊断和预测性维护将节省时间和成本。车辆传感器数据可以发送到云端进行处理以预测车辆的机械问题。制造商还可以通过空中OTA更新来修复汽车固件从而无需车主前往维修店。车队管理应用程序提供实时远程信息处理、驾驶员疲劳检测和包裹跟踪功能。信息与娱乐基于驾驶行为的保险模型已经推出该模型将评估驾驶员的行为以确定保险费。停车场和车辆之间可以共享实时停车信息。餐厅和加油站可以向附近车辆的仪表盘发送优惠信息。拼车、联网驾驶、网页浏览、音乐等是车联网的其他一些应用。我们认为亚马逊 AWS、微软 Azure 等云平台将在充分发挥车联网的潜力和应用方面发挥重要作用。此外边缘计算或雾计算的使用对于解决使用中央云时存在的高延迟、低带宽和通信延迟问题至关重要这些问题在对时间和位置敏感的车联网应用中尤为突出。图 4 展示了车联网中可行的各种单云和多云场景。单云架构可能仅涉及一个中央云该中央云管理广泛地理区域如一个城市内智能实体生成的用户应用程序、虚拟对象和数据。由于上述延迟和其他问题这种架构并不可行。雾计算或边缘计算至关重要我们认为车联网可以使用车载云即道路上的智能车辆和基础设施提供的资源或者在道路沿线设置固定基础设施其中计算和存储集群专门用于小范围区域。也可以为每个联网汽车使用雾计算结构车辆中的传感器在雾计算中具有虚拟对象可用于实现车内通信。车载云VC可以是固定的例如停在商场停车场的车辆以获取奖励如免费停车为目的提供其资源也可以是移动的即车辆在行驶过程中可能通过代理形成云并且如果在指定地理范围内可以加入或离开云。此外这些移动车载云可以由固定基础设施支持例如路边的交通信号灯作为代理或者行驶中的车辆可以自主形成车载云。在多云车联网架构中我们设想将具有多个云、云 - 雾计算或多个雾计算设置。然而我们认为单一中央云和多个雾计算架构非常适合覆盖大多数联网汽车和车联网应用这将在我们的扩展 ACO 架构中进一步讨论。图4、IoV中的不同云和雾架构3.2 扩展ACO架构联网汽车和车载物联网生态系统包含多个异构设备独立或集群和内置汽车应用程序这些设备和应用程序协同工作为终端用户提供服务。一些设备是独立的街道上的摄像头、餐厅的信标而另一些则属于更大的集群对象联网汽车中的电子控制单元或传感器。因此我们建议将这种区分纳入先前定义的访问控制导向架构ACO中以满足车联网生态系统的访问控制需求。纳入集群对象的一个重要原因是为了反映车际和车内通信。两辆联网汽车可以相互交换基本安全消息BSM这一事实反映了集群对象通信。ACO 架构是为通用物联网系统提出的其中没有定义此类概念。除了对象之外这些集群对象中可能运行着应用程序例如汽车中可能安装了导航应用程序或安全警告应用程序这些应用程序可以与智能路牌上的传感器交互通过汽车仪表盘、座椅振动或蜂鸣器向驾驶员发出警告。需要注意的是这些传感器或应用程序可能访问其所属汽车的传感器或者可能访问其他汽车的传感器。图 5 展示了我们提出的扩展 ACOE-ACO架构以及图 5b中不同 E-ACO 层对应的车载物联网组件。E-ACO 架构与 ACO 类似具有四层对象层、虚拟对象层、云服务层和应用层层内组件之间以及上下相邻层之间可以进行通信如图 5a中的自循环所示。我们现在将更详细地讨论各层图5、联网汽车和车载物联网的扩展ACO架构对象层对象层引入了集群对象这些对象具有多个独立传感器或智能对象。集群对象中还可能安装有多个内置应用程序如轮胎压力监测。这些应用程序可以与同一汽车或邻近汽车中的电子控制单元和传感器通信以获取数据并向驾驶员更新信息。其中一些应用程序收集数据并将其发送到云基础设施进行进一步分析例如制造商安装的诊断应用程序将收集来自关键发动机传感器的数据并发送到云端进行处理为客户提供空中维护服务。应用程序、电子控制单元和传感器之间的车内通信由不同的网络技术支持包括控制器局域网CAN、本地互联网络LIN、以太网、面向媒体的系统传输MOST等。对象层中的对象和集群对象之间以及与上层虚拟对象层和下层用户之间可以进行通信。不同车辆或集群对象之间的对象层内对象通信可以通过专用短程通信DSRC、蓝牙、WiFi 和长期演进LTE等技术实现。对象层中的一个交互示例是手机中的宝马互联应用程序该应用程序从手机读取地址并发送到汽车导航系统或使用专用短程通信进行车对车基本安全消息交换。需要注意的是我们没有将集群对象作为 E-ACO 中的独立层引入而是将它们添加到 ACO 架构的同一对象层中这反映了对象、应用程序与其所属集群对象之间的绑定关系。我们认为对象和集群对象之间的关系非常重要例如汽车中的车道偏离传感器将具有一些从汽车继承的属性如车辆 ID这种绑定关系通过将它们置于同一层来体现。这些集群对象和汽车还关联有应用程序为车内驾驶员提供服务。例如后视系统是汽车中的一种应用程序用于获取后方视野它从后置摄像头一个对象获取数据为驾驶员提供仪表盘视图。其他应用程序包括与轮胎中安装的传感器通信的轮胎压力监测系统、车厢监测系统、信息娱乐系统等这些应用程序内置在联网汽车中可以与系统中的传感器或其他应用程序通信。E-ACO 对象层中的这些应用程序是对 ACO 架构对象层的补充反映了其在车联网生态系统中的重要性车联网生态系统非常依赖智能汽车支持的内置应用程序。虚拟对象层传感器、车辆和其他智能实体的通信可能还涉及虚拟对象或虚拟实体以消除连接性、异构性和 locality 问题。车联网中最重要的智能实体智能汽车通常处于运动状态并且始终会经过互联网连接较差或无连接的区域。在这种情况下必须在云中创建智能汽车及其传感器的虚拟实体以便当汽车未连接时汽车及其传感器的最后状态和期望状态信息可以发送到虚拟实体。一旦物理对象重新获得互联网连接虚拟实体将向其物理对应物推送信息 / 状态。例如如果诊断出汽车的动力传动系统控制电子控制单元存在问题机械师需要向电子控制单元发送命令以控制空燃比。如果汽车具有互联网连接则可以直接向电子控制单元发送消息但如果没有连接则应向电子控制单元的虚拟实体发送消息当汽车获得连接并同步虚拟和物理实体时虚拟实体将向物理电子控制单元推送消息。我们设想 E-ACO 架构中的虚拟对象层将为集群对象和独立对象都提供一个或多个虚拟实体虚拟对象或设备影子。物理对象可以使用超文本传输协议HTTP、消息队列遥测传输MQTT、高级消息队列协议AMQP或受限应用协议CoAP等协议与其虚拟对应物通信。当不同车辆或集群对象中的传感器 s₁和 s₂相互通信时通过虚拟对象层的通信序列应遵循 s₁到 s₁的虚拟实体vs₁、vs₁到 vs₂以及 vs₂到物理传感器 s₂的顺序。对于内置汽车应用程序也可以设想类似的通信方式这些应用程序可以通过在云、车载云或雾计算架构中创建的虚拟对应物间接从物理传感器交换信息。可以为每辆车创建一个雾计算云片虚拟实体将驻留在该云片中并支持汽车内部物理传感器和电子控制单元之间的间接通信。我们的 E-ACO 架构不为车联网支持的车内应用程序提供虚拟实体也不会为此类应用程序创建虚拟对象。云服务层和应用层由于大多数用户车联网应用程序都由云支持即使用云基础设施和服务我们将它们一起解释以便更好地理解这两个相互依赖的 E-ACO 层。云层提供存储和处理功能而应用层提供应用程序界面供用户控制和与对象层组件交互如 ACO 架构中所述。汽车中固件和其他软件组件的空中OTA更新通过云服务层进行只有授权用户才能发起空中更新。用户和应用程序可以访问智能基础设施推送到云中的数据为客户提供增值服务。我们提出的架构假设车联网生态系统中同时具有中央云和雾计算由车载云实例化组件但将它们统称为云服务。车联网和联网汽车中云层的一个重要用途是为授权车载通信定义安全策略我们认为这在文献中是缺失的。此外我们假设可以根据访问对象的用例和应用程序范围在中央云和雾计算中创建各种对象的虚拟实体。例如事故安全应用程序的地理范围有限因此将访问在雾计算中创建的虚拟对象以克服延迟问题而健康监测应用程序可能通过在中央云中创建的虚拟对象访问人体传感器。云服务和应用程序可以使用消息队列遥测传输MQTT或其他相关协议从虚拟对象访问信息和数据。需要注意的是我们研究的大多数车联网架构和用例没有虚拟对象层仅包括对象层、云服务层和应用层。对象层中的汽车、传感器和应用程序之间的通信不涉及虚拟对象而是使用专用短程通信DSRC、车联网无线接入WAVE、蓝牙或 WiFi 等下层协议进行。传感器可以直接将数据发送到云存储进行处理而无需涉及虚拟对象然后应用程序使用这些数据。然而如本节前面所讨论的行驶中汽车的连接问题和实体之间的通信异构性支持了虚拟层的必要性。图 5b展示了一个车联网实例其中包含物理对象汽车、交通信号灯及其在虚拟对象层中的虚拟对应物以及其他 E-ACO 层。可以看出物理对象与虚拟对象通信应用程序通过云访问由对象的虚拟实体推送的数据。对象层的存储和处理图标代表路边基础设施这些基础设施可以帮助存储来自车辆的数据并在将数据推送到云之前进行过滤。为了满足不同的应用需求在雾计算和中央云中都创建了虚拟对象。4、车联网授权架构车载物联网的动态性和分布式特性给生态系统的安全带来了挑战。广泛的攻击面和众多的外部接口加上车联网的固有特征使得确保内部组件和数据的安全性和隐私变得困难。访问控制对于限制未授权访问联网汽车和车联网中的数据、传感器、应用程序、基础设施和其他资源至关重要。MobEyes和CarSpeak等应用程序允许车辆或传感器不仅访问自己的传感器还可以访问邻近车辆的传感器以获取数据和信息。车辆和智能实体之间基本安全消息BSM的交换及其使用必须是可信的并经过检查。此外电子控制单元和应用程序之间通过总线进行的车内通信也应受到保护。此类交换必须经过授权以确保车辆和用户个人数据的机密性和完整性并防止对联网智能实体的远程或物理控制。在本节中我们定义了一个访问控制架构该架构反映了前面讨论的扩展 ACO 架构各层的授权需求。我们还讨论了一些与车联网生态系统相关的访问控制模型和授权方法。4.1 授权架构车联网中存在多种交互场景这使得理解不同的访问控制决策和执行点以及其他安全需求变得困难。基于扩展 ACO 架构我们将各种车载物联网通信分为三类对象级、虚拟对象级和云服务级如图 6 所示。由于大多数用户应用程序都是基于云的使用云中的服务和资源因此我们将车联网实体与云和应用程序的交互捆绑在一起。如 E-ACO 架构中所讨论的每个层的组件都与自身同一层中的组件以及紧邻的上下层组件进行交互。E-ACO 中存在两种类型的交互直接交互和间接交互如图中的实线框和虚线框所示。相邻层和同一层之间的通信是直接通信而间接通信包括跨越相邻层的交互即 E-ACO 中上下两层或多层之间的交互。例如集群对象与其内部的对象之间的交互是直接的因为它们属于同一对象层而应用层中的应用程序与对象之间的交互是间接的因为应用程序将通过其在云中创建的虚拟实体与对象交互。可能存在两类交互重叠的情况例如云服务CSR和虚拟对象VOB之间的交互既属于云服务类也属于虚拟对象类。以下是授权架构的类别和一些车联网通信场景图6、IoV生态系统中的不同相互作用对象级此类涵盖 E-ACO 架构中对象层内部的交互以及与相邻层虚拟对象层和用户的交互。一些交互类型如图 6 所示包括集群对象之间的交互CO-CO、集群对象与对象之间的交互CO-OB例如智能手机和汽车 USB 端口、用户与传感器之间的交互U-OB、传感器与汽车内部运行的任何应用程序之间的交互OB-OAP以及电子控制单元之间的交互OB-OB。需要访问控制模型来授权这些交互以及由此产生的数据交换。使用专用短程通信DSRC在联网汽车之间交换基本安全消息BSM是需要实体授权以确保消息完整性的通信示例这必须通过适当的访问控制方法来解决。虚拟对象级这包括虚拟实体与真实对象、云服务或用户应用程序之间的通信。一些示例包括虚拟对象之间的通信VCO-VCO、VOB-VOB、应用程序与虚拟对象之间的通信AP-VOB、云服务与虚拟对象之间的通信CSR-VOC、CSR-VOB等。这些通信大多通过发布 - 订阅协议如消息队列遥测传输MQTT、数据分发服务DDS或超文本传输协议HTTP、受限应用协议CoAP进行。最近阿尔塞赫里Alsehri和桑杜Sandhu提出了基于主题的通信中虚拟对象 - 虚拟对象VOB-VOB交互的访问控制模型使用了基于能力的访问控制CapBAC、访问控制列表ACLs和基于属性的访问控制ABAC。云服务级云提供必要的存储、处理和服务以释放物联网的真正潜力。此外大多数应用程序也是基于云的其软件和硬件组件在云中得到支持。因此此类包括应用程序和云与车联网实体和虚拟对象的交互。该层还考虑了多云或雾计算 - 云交互这在分布式车联网中非常重要。此类中的一些交互如图 6 所示包括用户应用程序与云服务之间的交互AP-CSR、多云或雾计算交互CL-CL、FG-CL、应用程序与对象之间的间接交互AP-OB、云服务之间的交互CSR-CSR等。车载网络允许汽车内部的传感器和应用程序之间进行交互这也需要保护。根据所涉及的实体是物理实体、虚拟实体还是应用程序此类通信可以归入上述类别。可以通过为电子控制单元分配访问控制列表ACLs和权限来保护控制器局域网CAN总线和其他车内通信以防止欺骗和其他攻击。远程信息处理控制单元TCUs或网关已被用于将关键电子控制单元与车辆中安装的其他非重要子网分离并作为联网汽车的通用外部接口。需要进行身份验证以防止电子控制单元被欺骗并隔离关键传感器。电子控制单元内部的数据应受到保护空中固件更新必须安全。美国政府问责局GAO指出通过短程通信连接到车辆的蓝牙单元可能允许攻击者获取车辆访问权限这也需要安全保障。必须限制对电子控制单元的物理篡改和直接车载诊断OBD端口访问。4.2 访问控制方法研究人员已经研究了物联网系统中的授权需求并提出了多种访问控制模型和实现方案。最近有学者提出了一种用于虚拟对象的访问控制模型该模型使用了访问控制列表ACLs、基于属性的能力访问控制CapABAC和基于属性的访问控制ABAC。亚马逊网络服务AWS物联网的访问控制模型进行了讨论该模型使用策略来控制发布 - 订阅交换协议中的物理、虚拟、云服务和其他通信。我们认为车联网环境需要在两个层面进行访问控制策略决策和执行外部通信和车内内部通信。外部接口的访问控制将确保外部实体如车辆、交通信号灯、智能手机或用户应用程序等对车辆数据、传感器、电子控制单元和应用程序的授权访问而内部机制将确保联网汽车中由控制器局域网CAN总线、蓝牙、WiFi 等支持的电子控制单元和车内应用程序通信及数据交换的安全。仅保护外部接口可能不足以阻止黑客因为他们可能冒充可信设备并绕过外部访问控制。此外如果某些具有外部接口的电子控制单元被泄露第二层访问控制将保护联网汽车中的关键系统。车辆会发现新的车辆和基础设施并开始与它们交换基本安全消息BSM。车载物联网主要有两种数据交换场景静态和动态其中静态场景考虑的是长期关系导致的交互例如车辆和车主或汽车制造商之间的交互。动态通信是暂时的发生在实体位于特定位置或地理范围内且彼此之间没有先前关系的情况下。此外静态关系可能共享更多的私人信息而动态关系则不然。这些关系有助于理解和制定车联网中的访问控制。另一种方法可能需要多层访问控制其中对对象所需执行的操作类型决定了可以做出访问决策的授权方。例如控制自动驾驶车辆可能需要同时获得车主和交通当局的许可而读取车辆数据可能只需要车主的同意。我们认为集群对象在访问控制决策中非常重要可以帮助做出初步决策。以车辆为例不仅车辆之间会共享基本安全消息BSM车辆中的传感器或应用程序也会进行通信。因此第一层检查将确保两辆车作为集群对象是否允许通信而不考虑其内置传感器。如果在第一层获得授权下一层访问控制将包括车辆的传感器、应用程序和电子控制单元以做出最终决策。可以引入信任概念即只有可信实体才能进行通信。信任可以基于两个实体之间的交互或关系来建立。例如之前交换过数据的实体更可信属于同一车主的家庭和车辆更可信可以进行通信。美国运输部USDOT支持的安全凭证和管理系统SCMS[68] 中基于公钥基础设施PKI的信任建立是确保车对车通信中基本安全消息BSM机密性和完整性的重要系统。此外可以添加基于属性的解决方案其中车联网实体可以从其地理位置或制造商那里继承一组属性。在这种情况下在检查车辆之间的信任后可以使用基于属性的策略来确定传感器通信。可用于访问决策的属性包括地理位置、当前速度、加速度、减速度、路面温度或其他车辆远程信息处理数据。可能需要两级策略一级在云层控制车对车、车对基础设施等类似通信另一级在雾计算或车载云层控制车内电子控制单元、应用程序或传感器交互。可能存在单云和多云场景同一云或跨云的车辆可以进行交互这也需要访问控制。还需要管理模型 来支持车联网操作访问控制模型的管理。5、用例在本节中我们将讨论一些与我们的授权架构相关的用例这些用例整合了扩展 ACO 架构如图 5 所示、车联网中的各种通信交换场景如图 6 所示、云和雾计算架构以及如图 7 所示的车载物联网生态系统实体。我们将用例分为单云系统和多云系统以反映实体通信和用户车联网应用程序的本地或全局范围然而单云中的所有应用程序都可以扩展到多云反之亦然。我们的主要目标是描述在分布式和动态车载物联网生态系统中交互和数据交换如何发生以及各种访问控制决策和执行点的需求。图7、联网汽车和车联网生态系统车载物联网中的大多数应用程序对时间和位置敏感需要实时处理从有限地理区域内的智能车辆、传感器、电子控制单元和其他智能对象收集的信息。为了解决使用中央云时存在的延迟和带宽问题我们认为车载云VC将发挥重要作用其中智能车辆或路边基础设施智能交通信号灯、路标等中存在的存储和计算可以用于支持车联网应用程序。因此我们的单云应用程序由车载云形式的雾计算或云片实例支持物理对象将在其中具有其虚拟对应物虚拟对象。也可以为每个联网汽车设置一个雾计算实例汽车内部的任何通信都通过该实例支持。其他场景可能需要为单个物理对象设置多个虚拟对象其中一些对象在车载云中一些在中央互联网云中这对于更持久的状态或非时间敏感的应用程序或者当交互的车联网实体不在同一车载云的范围内时是必要的。此类用例在多云或雾计算 - 云架构场景中进行讨论。5.1 单云系统单云应用程序包括有限地理区域内的实体进行通信和信息交换。过马路的行人向驶来的车辆发送警报消息或宝马 7 系的远程停车功能帮助驾驶员使用触摸屏钥匙停车这些都是短程通信的示例。附近的餐厅或加油站也可以向联网车辆的仪表盘发送优惠信息或者在巡航模式下限速路标在与车辆交换消息时自动降低车辆速度。物理层中的每个车联网实体集群对象、传感器、电子控制单元在虚拟对象层中都将有一个虚拟实体一对一该虚拟对象层是车载云、云片或雾计算的一部分。消息队列遥测传输MQTT和其他基于物联网主题或内容的发布 - 订阅模型中发布者传感器、应用程序可以向特定主题发布消息其他传感器或应用程序订阅这些主题当发布者在这些主题上发布消息时消息代理将相关消息传递给所需的订阅者。除了跨实体交互外还会发生车内通信其中联网汽车中的传感器、电子控制单元和应用程序与坐在车内的乘客的智能设备交换消息或进行交互。每辆车的雾计算架构支持车内通信其中可以为每个电子控制单元、传感器或设备创建虚拟实体。此外在控制器局域网CAN总线通信的情况下关键电子控制单元通过网关分离该网关还提供与联网汽车的外部接口。这确保了对空中OTA更新的身份验证和授权并为车内通信执行访问控制策略。物理层、虚拟对象层和云服务层需要访问控制点只允许合法和授权的实体之间进行交互和数据交换。在对象层使用专用短程通信DSRC、WiFi 等在集群对象之间进行的车对车、车对基础设施和其他车对万物通信需要访问控制以确保基本安全消息BSM的机密性并防止恶意活动。用户使用遥控钥匙或通过智能手机应用程序直接访问车辆也需要授权。也可以将信用卡信息存储在车辆存储中或车辆的虚拟实体中这可以简化收费公路或停车场的支付过程。在这种情况下只有授权的应用程序才能访问信用卡信息如果泄露给恶意行为者可能会产生巨大的财务影响。在对象层内还需要访问控制来确保传感器或应用程序与集群设备之间的授权通信例如智能手机访问信息娱乐系统或插入汽车的设备需要安全保障。当物理对象与云中的虚拟实体通信时需要访问控制。例如汽车中的安全气囊电子控制单元或传感器应只能联系其对应的虚拟实体以更新其状态或通过主题推送消息。我们的车联网生态系统概念包含虚拟对象每个物理对象对应一个虚拟对象这对于异构对象之间的消息和信息交换非常重要。还将为可以向联网车辆发出命令的车内智能设备创建虚拟实体。因此虚拟对象层也需要访问控制以控制虚拟实体之间的交互。汽车中的内置应用程序还访问车载传感器例如轮胎压力监测、车道偏离警告系统等这些应用程序必须仅授权给合法应用程序。电子控制单元之间的通信也需要通过网关或远程信息处理控制单元TCUs进行授权。基于属性的访问控制可以提供细粒度的策略并使用上下文信息来保护物理和虚拟对象层的数据交换和通信。因此为了保护关键电子控制单元第一层访问控制限制外部接口然后车内访问控制提供第二层检查。联网汽车生成大量数据被称为 “车轮上的数据中心”。应用程序使用这些数据提供关于交通、道路安全、天气或道路维护的实时信息。应用程序还可以诊断车辆问题并向道路上的驾驶员提供预测性和预防性建议。机械师或用户通过云执行此类操作必须经过授权。此外如果任何应用程序想要向汽车中的传感器发送命令则需要应用程序和虚拟对象通信的访问控制。生成的数据可以发送到云服务器进行存储和处理。由于这些应用程序大多与地理位置相关因此它们可以利用车载云并使用其存储和处理能力。云中的数据安全至关重要。需要适当的访问控制只允许相关实体访问和处理多租户数据湖中的数据。应用程序和云服务必须经过授权以确保用户数据的隐私。分析大数据的最常见平台是 Hadoop其中已提出了多种访问控制模型。这些数据可以由车辆内部的应用程序或 E-ACO 应用层的用户应用程序使用。5.2 多云系统一些车联网应用程序和用例需要多个云实例以在广阔的地理区域或非时间敏感的条件下提供服务。例如假设一家车辆制造商拥有一个私有云该云收集其车辆生成的所有数据分析潜在问题并提供空中OTA解决方案如固件或软件更新。这些数据有时还可能反映车辆中需要立即关注的问题因此需要发送给附近的机械师。现在机械师有自己的私有云无法访问存储在原始设备制造商OEMs云中的车辆数据。在这种情况下必须在两个云之间建立信任以便在获得车主批准的情况下车辆数据可以在机械师的云和制造商的云之间共享。如果机械师需要向车辆中的传感器发送消息则必须在车载云汽车中传感器的虚拟对象在其中创建和机械师云中的应用程序之间进行跨云通信这也需要访问控制和信任。CarSpeak [49] 等应用程序不仅从同一辆车还从可能在或可能不在同一车载云中的不同车辆的不同传感器收集数据。在这种情况下应用程序还将访问不同车载云中的虚拟实体这可能需要不同云基础设施之间的信任。两个车载云之间或车载云与中央云之间也可能交换信息。例如假设一辆车正在接近驾驶员的家需要向恒温器发送消息以打开空调。可能的情况是家位于不同的云中因此其虚拟实体在其他云中。在这种情况下将进行跨云通信车辆中的应用程序将与其他云中的家恒温器对应的虚拟对象通信。由于在这种情况下家和车辆属于同一车主我们可以在跨云之间创建它们之间的信任级别并利用它来做出更快的访问决策而无需使用基于策略的控制。在另一个示例中假设机动车管理局DMV或当地警方发布了关于被盗车辆或城市中一些恶意分子的通知车辆仪表盘将开始显示警报消息。这些应用程序将在机动车管理局DMV云或警察局拥有的云中运行这些云将向城市中行驶的车辆发送消息这也需要多云访问场景。在这种情况下机动车管理局DMV还可以在城市或高速公路周围安装专用基础设施这些基础设施将通过云接收消息然后通过虚拟对象或 WiFi 通信将消息传递给地理区域内的附近车辆或相关传感器。因此需要单云和多云架构中的访问控制以确保车联网生态系统中物理对象、虚拟对象和应用程序之间的安全交互。6、拟议的以安全为重点的研究议程车联网授权架构和扩展 ACO 架构的主要目标是理解安全需求并提出一些以安全为重点的研究方向。在本节中我们将重点介绍以下研究问题外部交互智能实体暴露于外部行为者和互联网为远程攻击和数据盗窃打开了大门。联网汽车和个人设备拥有私人数据需要以用户为中心的隐私政策用户可以接受或拒绝信息披露。此外需要控制关键电子控制单元中的数据并确保只有授权实体才能发出执行操作的命令。与在路上随机发送消息的人相比可信实体应该被允许共享更多信息。这里的一个重要问题是如何在对象之间建立信任车对万物基本安全消息BSM必须加密实体在执行操作之前必须经过适当的身份验证。车联网中的动态和短期交互使得难以防止或检测来自受损实体的攻击。车内交互汽车内部的广播控制器局域网CAN通信总线和其他协议用于支持电子控制单元和应用程序通过网关进行通信。该网关提供防火墙功能将关键传感器与车辆中安装的其他应用程序隔离并提供安全的外部接口。需要进行身份验证以防止电子控制单元被欺骗并隔离关键传感器。电子控制单元内部的数据应受到保护空中固件更新必须安全。美国政府问责局GAO[30] 指出通过短程通信连接到车辆的蓝牙单元可能允许攻击者获取车辆访问权限这也需要安全保障。必须限制对电子控制单元的物理篡改和直接车载诊断OBD端口访问。跨云交互和共享车载物联网的云辅助愿景支持多个云或雾计算基础设施。为了确保安全的跨云或雾计算交互必须在两个提供商之间建立信任这可以决定共享和数据交换的级别。特定于物联网的跨云访问控制和相关安全模型仍处于起步阶段需要更多的关注。云中的数据云中收集的用户和车辆数据必须受到保护防止恶意用户访问并根据用户和云提供商定义的隐私政策进行共享和处理。此外云应用程序和虚拟实体必须进行安全通信。此外移动车载云VC及其安全需求相关的问题需要进一步研究。当参与车辆离开车载云或形成车载云时虚拟机迁移等问题在文献中尚未得到广泛讨论。7、总结本文提供了一种面向云辅助联网汽车和车载物联网的授权架构。它提出了安全需求并讨论了车联网动态生态系统中必要的多个访问控制决策和执行点。本文首先概述了相关概念的背景研究包括联网汽车、虚拟对象、车载云和 ACO 架构。我们提出了一种扩展 ACOE-ACO架构该架构引入了集群对象汽车、基础设施、家庭的新概念集群对象具有多个独立的智能对象、传感器和应用程序。我们设想车联网将同时具有雾计算和云实例其中雾计算可以是静态的或者使用车辆基础设施或固定路边单元动态构建。本文讨论了不同的通信和数据交换场景随后介绍了 E-ACO 层中的访问控制方法。具有单云和多云场景以及访问控制需求的现实世界用例反映了车联网授权架构的必要性和用途。我们设想基于提出的研究议程为云辅助联网汽车和车联网中不同的通信和数据交换需求开发访问控制模型。