CN109756897A - 一种车联网的认证授权机制及系统 - Google Patents

Abstract

本发明提供一种车联网的认证授权机制及系统，属于信息安全领域。本发明通过二次认证和基于token的身份认证，解决了V2X信息交换的可信问题。该认证授权机制包括：端、边、雾通过运营商网络和云端的二次认证后，云端为边、雾生成token；云端获取车辆路径信息后，将边、雾的token信息发送给车辆；车辆收到边、雾发送的V2X信息，通过保存的token，对V2X信息的可信性进行认证。本发明还公开了一种认证授权系统，所述系统包括运营商认证系统、云端认证系统、token系统和V2X系统。本发明提供的认证授权机制及系统，有助于云端发现恶意边、雾设备，或者自身缺陷或出现逻辑错误的边、雾设备。

Description

一种车联网的认证授权机制及系统

技术领域

本说明书涉及信息安全领域，尤其涉及一种车联网的认证授权机制及系统。

背景技术

V2X(vihicle to X，即车对外界的信息交换)是未来智能交通运输系统的关键技术，可以通过通讯获得实时路况、道路信息、行人信息等一系列交通信息，提高驾驶安全性、减少拥堵、提高交通效率等。基于V2X技术可以提升交通安全，同时为自动驾驶、智能交通和车联网创新提供低成本、易实施的技术路线和基础平台。

目前在3GPP(第三代合作伙伴计划，3rd Generation Partnership Project)的标准中仅对车联网终端的认证授权进行了规定(TS23.303，23.285)，通过认证授权的车联网终端可以在指定的PLMN(Public Land Mobile Network，公共陆地移动网络)的特定地理区域通过指定的频段使用特定的V2X业务。

现有标准和方案对于V2X消息的可信问题并没有规定，例如通过网络认证和授权的RSU(road side unit，路侧单元)基站或者MEC(Multi-access Edge Computing，移动边缘计算)雾端设备给终端发送恶意的V2X消息，扰乱道路正常行驶(比如报告虚假的道路维修和道路结冰信息等)，或者获得额外利益(比如在充电站附近宣称下一充电站距离很远，从而吸引更多的车进站充电)。RSU基站或者MEC雾端设备由于本身缺陷或者逻辑错误，也有可能发出错误的V2X消息，从而影响道路正常行驶。

发明内容

鉴于上述现有技术中的不足之处，本发明的目的在于建立一种车联网的认证授权机制，解决V2X信息的可信问题。

本发明解决技术问题所采用的技术方案如下：

本发明提供一种车联网的认证授权机制，所述认证授权方法包括：

端、边、雾与运营商网络进行双向认证；

端、边、雾与云端进行二次认证；

二次认证通过后，云端为边和雾端生成token信息，并将token信息返回给边、雾保存；

云端根据车辆行驶路径，向车辆发送沿途边、雾设备的token信息，并由车辆保存；

车辆在行驶过程中，收到沿途边、雾设备发送的V2X信息；

车辆收到V2X信息后，通过已存储的token信息，对收到的V2X信息的可信性进行认证。

进一步地，本发明包括车辆开始一次行程时需要进行认证授权。

进一步地，端为联网车辆，边为RSU等路边设备，雾为MEC等部署在靠近路侧的平台或设备。

进一步地，端、边、雾和运营商网络的双向认证，主要完成终端及网络的认证，所述运营商网络包括但不限于4G或者5G网络。

进一步地，车联网终端向云端进行二次认证时，需要提供车辆终端的IMSI，云端统一为车辆终端分配的唯一识别号码、口令等。

进一步地，边、雾向云端进行二次认证时，需要提供边和雾设备的IMSI，云端统一为边、雾分配的唯一识别号码，口令等。

进一步地，边、雾和云端完成双向认证后，云端生成的token信息包括边和雾设备的IMSI、云端统一为边雾分配的唯一识别号码、口令、有效期、token签发时间、签名信息等。云端生成的token，返回给边、雾，由边、雾保存，并在边、雾发送的V2X信息中包含该token信息。

进一步地，车联网终端通过云端的二次认证后，车辆在开始第一次行程时，向云端上报自己的行驶路径，云端收到后可选地和车辆进行路径协商，并根据最终确定的路径信息，向车辆发送沿途边和雾端设备的token信息，用于车辆对收到的V2X信息进行可信性认证。

进一步地，车辆在行驶过程中，收到沿途边、雾设备发送的V2X信息。车辆利用已存储的token信息，对收到的V2X信息的可信性进行认证。

车辆收到V2X信息后，首先检查是否包含token信息。如果不包含，车辆忽略该V2X信息，并向云端报告，车辆向云端报告信息中可选包括：地理位置、收到的V2X信息、上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置等信息，向相关系统或者部门发出相应的地理位置可能有恶意边、雾设备的告警。

如果收到V2X信息包含token信息，车辆对该V2X信息进行处理。车辆检查其签名信息和自己存储的相应token的签名是否一致。如果不一致，车辆忽略该V2X信息，并向云端报告。向云端报告信息中可选包括：地理位置，收到的V2X信息，上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置等信息，向相关系统或者部门发出相应的地理位置可能有恶意边/雾设备的告警。

如果车辆收到的V2X信息中token签名一致，车辆通过运算从token信息中获取有效期等信息，并检查有效期是否过期。如果token已过期，车辆忽略该V2X信息，并向云端报告。向云端报告信息中可选包括：地理位置，收到的V2X信息，上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置、token等信息，确定发送含有该过期token信息的V2X消息的边/雾设备，然后和相应的边/雾设备进行认证，认证通过重新颁发含有新的有效期的token。如果token未过期，车辆对V2X信息进行进一步的处理。

进一步地，在车辆行驶过程中，如果车辆要改变行驶路径，需要和云端再次协商，包括但不限于，车辆上报新的路径信息，云端可选地对车辆的路径信息给出优化建议，并和车辆达成一致。协商一致后，云端根据具体应用场景把沿途所有或者部分边端和雾端设备的token信息发送给车辆，用于车辆对收到的V2X消息进行认证。具体方法同车辆开始一次行程时的认证授权机制。

进一步地，云端收到的来自车辆的信息包括两类：一类是车辆上报的路径信息；一类是车辆上报的有问题的边、雾设备信息。

进一步的，车辆增加信息上报模块，用于车辆信息上报；云端增加对车辆上报信息的处理模块，用于上报信息的处理。

本发明的一种车联网的认证授权系统，其特征在于，所述认证授权系统包括：运营商认证系统、云端认证系统、token系统和V2X系统。

优选地，运营商认证系统，主要用于端、边、雾和运营商网络的双向认证；

优选地，云端认证系统，主要用于端、边、雾和云端的二次认证；

优选地，token系统主要用于token信息的生成及异常token处理；

优选地，V2X系统主要用于V2X信息的生成、发送，完成V2X信息可信性认证。

实施本发明的一种车联网的认证授权机制及系统，具有以下有益效果：本发明中，车联网终端、边和雾通过运营商网络认证授权后，向云端进行二次认证，通过token建立互信关系，从而可以避免车辆受到恶意边端和雾端设备的影响，云端也能及时发现恶意的边端和雾端设备。对于自身缺陷或者出现逻辑错误的边端和雾端设备，云端识别该情况后(通过持续的消息分析或通过举报机制)，可以通过收回相应边端和雾端设备token的方式，快速避免这些设备继续对车辆产生影响。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图做简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书提供的一种车联网的认证授权机制；

图2为本说明书提供的二次认证机制；

图3为本说明书实施例中的V2X信息认证机制；

图4为本说明书实施例中车辆改变行驶路径后V2X信息可信度认证流程；

图5为本说明书实施例中提供的签名过期的token，需要获取新有效期的token信息；

图6为本发明实施例中的车联网的认证授权系统。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1为本说明书提供的一种车联网的认证授权机制，包括端、边、雾、运营商网络和云端五部分，其中端为联网车辆，边为RSU等路边设备，雾为MEC等部署在靠近路侧的平台或设备。

所述认证授权机制包括：

S101、端、边、雾与运营商网络进行双向认证；

S102、端、边、雾与云端进行二次认证；

S103、二次认证通过后，云端为边和雾端生成token信息，并将token信息返回给边、雾保存；

S104、云端根据车辆行驶路径，向车辆发送沿途边、雾设备的token信息，并由车辆保存；

S105、车辆在行驶过程中，收到沿途边、雾设备发送的V2X信息；

S106、车辆收到V2X信息后，通过已存储的token信息，对收到的V2X信息的可信性进行认证。

基于上述方法，下面对本说明书的方案进行详细说明。

图2为本实施例提供的二次认证机制，该机制具体包括以下步骤：

S201、端、边、雾向运营商网络发送认证请求，运营商网络收到发送请求后，对端、边、雾进行认证，确保端、边、雾的网络正确，是它宣称的网络；端、边、雾设备终端正确，是它所宣称的终端，从而完成端、边、雾与运营商网络的双向认证。运营商网络包括但不限于4G或者5G网络。

S202、端、边、雾通过运营商网络的认证授权后，向云服务器发送认证请求，云服务器收到认证请求后，进行二次认证，认证信息可选包括IMSI、唯一识别号码、口令等。

S203、边、雾通过云端二次认证，云端为边、雾生成token信息，并返回边、雾设备保存；端通过云端二次认证，车辆开始一次行程时，向云端报告行程，双方协商行驶路线。

进一步地，云端为边、雾设备生成的token信息包括边、雾设备的IMSI，云端统一为边、雾设备分配的唯一识别号码、口令、有效期，token签发时间、签名信息等。

进一步地，车辆与云端协商好行驶路线后，云端将沿途边、雾设备的token信息下发给车辆，并由车辆保存。车辆在行驶过程中，不断收到沿途边、雾设备发送的V2X信息；车辆收到V2X信息后，通过已存储的token信息，对收到的V2X信息的可信性进行认证。

图3为本实施例提供的V2X信息认证机制，该机制具体包括以下步骤：

S301、车辆收到V2X信息后，首先检查是否包含token信息。如果不包含，车辆忽略该V2X信息，并向云端报告，车辆向云端报告信息中可选包括：地理位置、收到的V2X信息、上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置等信息，向相关系统或者部门发出相应的地理位置可能有恶意边/雾设备的告警。

S302、如果车辆收到的V2X信息包含token信息，车辆对该V2X信息进行处理。车辆检查其签名信息和自己存储的相应token的签名是否一致，如果不一致，车辆忽略该V2X信息，并向云端报告。向云端报告信息可选包括：地理位置，收到的V2X信息，上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置等信息，向相关系统或者部门发出相应的地理位置可能有恶意边/雾设备的告警。

S303、如果车辆收到的V2X信息中token签名一致，车辆通过运算从token信息中获取有效期等信息，并检查有效期是否过期。如果token已过期，车辆忽略该V2X信息，并向云端报告。向云端报告信息可选包括：地理位置，收到的V2X信息，上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置、token等信息，确定发送含有该过期token信息的V2X消息的边/雾设备，然后和相应的边/雾设备进行认证，认证通过重新颁发含有新的有效期的token。如果token未过期，车辆对V2X信息进行进一步的处理。

进一步的，车辆结合token中的其他信息(角色等)，对V2X信息进行处理和响应。

本发明的另一个实施例中，车辆改变行驶路径，V2X信息需要再次进行认证。

图4为车辆改变行驶路径后，token信息认证流程。具体包括以下步骤：

S401、车辆改变行程，需要上报云端，协商路径。

具体的，在车辆行驶过程中，如果车辆要改变行驶路径，需要和云端再次协商，包括但不限于，车辆上报新的路径信息。云端可选地对车辆的路径信息给出优化建议，并和车辆达成一致。

S402、云端重新下发token信息。

云端与车辆协商好行驶路线后，云端根据具体应用场景，把沿途所有或者部分边端和雾端设备的token信息发送给车辆，用于车辆对收到的V2X消息进行认证。

S403、边、雾向车辆发送V2X信息。

车辆在行驶过程中，不断收到沿途边、雾设备发送的V2X信息。

S404、车辆收到V2X信息后，首先检查是否包含token信息。如果不包含，车辆忽略该V2X信息，并向云端报告，车辆向云端报告信息中可选包括：地理位置、收到的V2X信息、上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置等信息，向相关系统或者部门发出相应的地理位置可能有恶意边/雾设备的告警。

S405、如果车辆收到的V2X信息包含token信息，车辆对该V2X信息进行处理。车辆检查其签名信息和自己存储的相应token的签名是否一致，如果不一致，车辆忽略该V2X信息，并向云端报告。向云端报告信息可选包括：地理位置，收到的V2X信息，上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置等信息，向相关系统或者部门发出相应的地理位置可能有恶意边/雾设备的告警。

S406、如果车辆收到的V2X信息中token签名一致，车辆通过运算从token信息中获取有效期等信息，并检查有效期是否过期。如果token已过期，车辆忽略该V2X信息，并向云端报告。向云端报告信息可选包括：地理位置，收到的V2X信息，上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置、token等信息，确定发送含有该过期token信息的V2X消息的边/雾设备，然后和相应的边/雾设备进行认证，认证通过重新颁发含有新的有效期的token。如果token未过期，车辆对V2X信息进行进一步的处理。

进一步的，车辆结合token中的其他信息(角色等)，对V2X信息进行处理和响应。

图5为本说明书实施例中提供的签名过期的token，需要获取新有效期的token信息。具体实施过程包括：

S501、token过期，车辆向云端报告。

进一步地，如果token已过期，车辆忽略该V2X信息，并向云端报告。向云端报告信息可选包括：地理位置、收到的V2X信息、上报该信息的车辆信息。云端收到上报信息后，可选地进行如下处理：根据上报消息中的地理位置、token等信息，确定发送含有该过期token信息的V2X消息的边、雾设备。

S502、边、雾设备重新与云端进行认证。

S503、认证通过后，云端为边、雾端生成新token信息，并将token信息返回给边、雾保存。

进一步地，新token信息获得了一个新的有效期。

S504、新的车辆开始行程时，云端向新的车辆发送沿途边、雾设备的token信息，并由车辆保存；边、雾设备向新的车辆发送V2X信息。

S505、新的车辆收到V2X信息后，通过已存储的token信息，对收到的V2X信息的可信性进行认证。

图6为本发明实施例中的车联网的认证授权系统。具体包括：运营商认证系统、云端认证系统、token系统和V2X系统。

优选地，运营商认证系统，主要用于端、边、雾和运营商网络的双向认证；

优选地，云端认证系统，主要用于端、边、雾和云端的二次认证；

优选地，token系统主要用于token信息的生成及异常token处理；

优选地，V2X系统主要用于V2X信息的生成、发送，完成V2X信息可信性认证。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书实施例提供的装置、电子设备、非易失性计算机存储介质与方法是对应的，因此，装置、电子设备、非易失性计算机存储介质也具有与对应方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、电子设备、非易失性计算机存储介质的有益技术效果。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (15)

1.一种车联网的认证授权机制，所述认证授权方法包括：

端、边、雾与运营商网络进行双向认证；

端、边、雾与云端进行二次认证；

二次认证通过后，云端为边和雾端生成token信息，并将token信息返回给边、雾保存；

云端根据车辆行驶路径，向车辆发送沿途边、雾设备的token信息，并由车辆保存；

车辆在行驶过程中，收到沿途边、雾设备发送的V2X信息；

车辆收到V2X信息后，通过已存储的token信息，对收到的V2X信息的可信性进行认证。

2.根据权利要求1所述的认证授权机制，其特征在于，所述认证授权机制为车辆开始一次行程时需要进行认证授权。

3.根据权利要求1所述的认证授权机制，其特征在于，所述端为联网车辆，边为RSU等路边设备，雾为MEC等部署在靠近路侧的平台或设备。

4.根据权利要求1所述的认证授权机制，其特征在于，所述运营商网络包括但不限于4G或者5G网络。

5.根据权利要求1所述的认证授权机制，其特征在于，所述运营商网络的双向认证，主要是完成终端及网络的认证。

6.根据权利要求1所述的认证授权机制，其特征在于，所述云端二次认证信息包括端、边、雾设备的IMSI、唯一识别号码、口令等。

7.根据权利要求1所述的认证授权机制，其特征在于，所述token的流转过程包括：

边、雾通过二次认证后，向云端发送token请求；

云端收到边/雾的请求，生成token信息；

云端将生成的token信息返回给边/雾；

云端根据车辆的行驶路线，向车辆发送沿途边、雾设备的token信息，并由车辆保存token信息；

车辆收到V2X信息后，利用车辆已保存的token信息，对V2X的可信性进行认证。

8.根据权利要求1所述的认证授权机制，其特征在于，所述云端生成的token信息包括边/雾设备的IMSI、云端统一为边/雾设备分配的唯一识别号码、口令、有效期、token签发时间、签名信息等。

9.根据权利要求1所述的认证授权机制，其特征在于，所述云端收到的来自车辆的信息包括两类：一类是车辆上报的路径信息；一类是车辆上报的有问题的边、雾设备信息。

10.根据权利要求1所述的认证授权机制，其特征在于，车辆开始一次行程时，向云端上报行驶路径，云端收到后，可选地，对路径消息进行协商，并根据最终确定的路径信息向车辆发送沿途边、雾设备的token信息。

11.根据权利要求1所述的认证授权机制，其特征在于，所述V2X信息的可信性认证，包括是否包含token信息、token签名是否一致、token有效期是否过期等。

12.根据权利要求1所述的认证授权机制，其特征在于，车辆增加信息上报模块，用于车辆信息上报；云端增加对车辆上报信息的处理模块，用于对收到的上报信息进行处理。

13.根据权利要求1所述的认证授权机制，其特征在于，所述认证授权机制，还包括车辆改变行程路线时，需要重新进行认证授权。

14.一种车联网的认证授权系统，其特征在于，所述认证授权系统包括：运营商认证系统、云端认证系统、token系统和V2X系统。

15.根据权利要求14所述的认证授权系统，其特征在于：

运营商认证系统，主要用于端、边、雾与运营商网络的双向认证；

云端认证系统，主要用于端、边、雾与云端的二次认证；

token系统主要用于token信息的生成及异常token处理；

V2X系统主要用于V2X信息的生成、发送，完成V2X信息可信性认证。