CN116631093A - 用于从车辆提取数据的方法和设备 - Google Patents

Abstract

本发明涉及车辆的数据交互领域。本发明提供一种用于从车辆提取数据的方法，所述方法包括以下步骤：S1：借助统一诊断服务向车辆请求用于描述提取验证规则的描述性表述；S2：从车辆反馈的描述性表述中解析出特定于所述车辆的提取验证规则；S3：基于所述提取验证规则控制从车辆的数据提取操作。本发明还涉及一种用于从车辆提取数据的设备和一种机器可读的存储介质。本发明通过提供一种统一的车辆数据收集方案，实现了对不同车辆的行车数据的可靠读取，同时满足多样化的加密和认证需求。

Description

用于从车辆提取数据的方法和设备

技术领域

本发明涉及一种用于从车辆提取数据的方法，本发明还涉及一种用于从车辆提取数据的设备和一种机器可读的存储介质。

背景技术

车辆配备的数据记录器在数据记录条件满足的情况下存储预定时间段和/或特定时刻的行驶状态数据和/或驾驶员的操作数据和/或车载系统的相关数据和/或外界环境(例如视觉信息)数据等。作为事故判责和事故场景还原的主要依据，司法鉴定机构和/或监管机构对数据记录的读取同时提出统一提取工具和解析方式的期待，同时对这类重要的数据有完整性和真实性的要求。

为此，目前已在很多数据记录器中引入数据加密技术，从而能够提供对车辆数据进行数字签名，也有部分数据记录器引入数字证书的验证服务进行(读、取)权限管理。然而，加密技术和鉴权方式的选择是各厂商在综合考虑车载架构、应用环境、系统设计、成本情况下的自主决策结果，没有统一性。此外，不同车辆也对数据提取工具存在多样化的权限控制策略和由此对应的鉴权方式。因此，现阶段缺乏一套能够兼容多种安全认证规则的标准化数据提取方案。

目前，现有技术中提出给车辆的不同子模块分配独立数字签名，并使每个数字签名与清单文件关联，然而这只能为每个车辆单独提供适配的认证系统，但是当推广到不同车辆时，仍受到算法不兼容等问题的限制。

在这种背景下，期待提供一种统一的车辆数据读取方案，以实现不同车辆的行车数据的可靠读取，同时满足多样化的加密和认证需求。

发明内容

本发明的目的在于提供一种用于从车辆提取数据的方法、一种用于从车辆提取数据的设备和一种机器可读的存储介质，以至少解决现有技术中的部分问题。

根据本发明的第一方面，提供一种用于从车辆提取数据的方法，所述方法包括以下步骤：

S1：借助统一诊断服务向车辆请求用于描述提取验证规则的描述性表述；

S2：从车辆反馈的描述性表述中解析出特定于所述车辆的提取验证规则；以及

S3：基于所述提取验证规则控制从车辆的数据提取操作。

本发明尤其包括以下技术构思：通过预先约定安全验证逻辑，规范了后续的数据提取流程，从而使信息交互操作遵循每个车辆的具体配置，在多用户集成场景中提供了兼容多种认证策略的统一数据提取工具。此外，统一诊断服务是在国际标准化组织(ISO14229标准)中指定的ECU环境中的诊断通信协议，借助这种标准化通信协议可以灵活对接不同车辆设备，而无需针对每个车型独立开发通信架构，使数据安全访问更加便捷。

可选地，所述提取验证规则包括鉴权规则和/或数字签名规则，

其中，所述鉴权规则尤其包括基于种子-密钥的认证规则、对称性算法(例如SM4、AES、DES等)、非对称性算法(例如RSA、ECC、SM2等)、证书认证规则和/或基于身份的密码(例如IBE-KEM)；

其中，所述数字签名规则尤其包括RSA、椭圆曲线数字签名算法(ECDSA)和/或有限自动机数字签名算法。

由此，实现以下技术优点：在此提出的数据提取方案支持多样化的数字签名算法和权限控制策略，从而满足不同用户、不同环境下的各种需求，具有广泛的适用性。

可选地，所述步骤S1包括：借助按标识符读取数据服务和/或按地址读取数据服务向车辆发送第一诊断请求，所述第一诊断请求用于使车辆通过第一肯定响应返回所述描述性表述。

由此，实现以下技术优点：描述性表述不直接包括指定密钥和算法，而是凭借标识符或地址下的数据值间接地与相应规则挂钩，从而实现了敏感数据匿名化，降低安全访问信息的泄露风险。

可选地，在所述描述性表述中，基于读取数据服务预留的厂商自定义数据字段，统一数据字段对应的数据提取工具询问请求和/或ECU(服务器)返回的描述性表述，从而使得通过标识符对应的数据记录值和/或通过地址指向的内存数据值关联特定于车辆的提取验证规则。

由此，实现以下技术优点：可以使提取验证规则按照一定编号或次序集中存储在数据库中，为企业进行开发提供了稳定的要求来源、也为监管(数据管理、权限管理等)机构或人员提供了有序的管理/查询服务。

可选地，所述步骤S3包括：借助车辆指定的鉴权规则为数据提取工具提供身份和/或权限证明。

由此，实现以下技术优点：通过使用车辆指定的鉴权策略，不仅能可靠防止未经授权的访问，而且可以避免由于鉴权规则不兼容而导致的认证失败。

可选地，借助车辆指定的鉴权规则为数据提取工具提供身份和/或权限证明包括：

借助安全访问服务向车辆发送第二诊断请求，所述第二诊断请求用于使车辆返回种子；

基于车辆指定的鉴权规则从接收到的种子计算出安全密钥值；

将安全密钥值返回给车辆；以及

等待车辆的鉴权认证结果。

可选地，借助车辆指定的鉴权规则为数据提取工具提供身份和/或权限证明包括借助认证服务向车辆发送第二诊断请求，所述第二诊断请求用于诊断仪(或双向)的身份认证。

由此，实现以下技术优点：以简单的方式确认数据提取工具的身份合法性，为后续级别更高的信息交互操作的顺利进行奠定了基础。

可选地，所述步骤S3包括：

借助统一诊断服务向车辆发送第三诊断请求，所述第三诊断请求用于发起车辆的数据传输服务；

接收车辆通过数据传输服务发送的车辆侧数据以及车辆的数字签名；

借助车辆指定的数字签名算法对所述数字签名进行验证。

由此，实现以下技术优点：可以有效识别数据损坏并防止数据篡改，确保了数据的完整性。

可选地，借助车辆指定的数字签名算法对数字签名进行验证包括：

借助车辆预先提供的公钥按照指定的数字签名算法对车辆侧数据的数字签名解密，以得到第一摘要序列；

借助车辆指定的散列算法从所接收到的车辆侧数据计算第二摘要序列；

将第一摘要序列与第二摘要序列比较；以及

根据比较的结果确定数字签名验证的结论。

由此，实现以下技术优点：不仅可以分辨出原始车辆侧数据是否完整可靠，而且也能对数据提供者的身份进行追溯，进一步增强了数据提取过程的安全性。

根据本发明的第二方面，提供一种用于从车辆提取数据的设备，所述设备用于执行根据本发明的第一方面所述的方法，所述设备包括：

通信接口，所述通信接口被配置为能够借助统一诊断服务向车辆请求用于描述提取验证规则的描述性表述，并且用于接收车辆反馈的描述性表述；以及

计算单元，所述计算单元被配置为能够从车辆反馈的描述性表述中解析出特定于车辆的提取验证规则，并基于所述提取验证规则控制从车辆的数据提取操作。

根据本发明的第三方面，提供一种机器可读的存储介质，在所述存储介质上存储有计算机程序，所述计算机程序用于当在计算机上运行时执行根据本发明的第一方面所述的方法。

附图说明

下面，通过参看附图更详细地描述本发明，可以更好地理解本发明的原理、特点和优点。附图包括：

图1示出了根据本发明的一个示例性实施例的用于从车辆提取数据的设备的框图；

图2示出了根据本发明的一个示例性实施例的用于从车辆提取数据的方法的流程图；

图3示出了根据本发明的一个示例性实施例的用于对数据提取工具进行鉴权过程的时序图；

图4示出了根据本发明的一个示例性实施例的车辆的数据传输过程的时序图；以及

图5示出了根据本发明的一个示例性实施例的用于验证车辆的数字签名的原理性示意图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案以及有益的技术效果更加清楚明白，以下将结合附图以及多个示例性实施例对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用于解释本发明，而不是用于限定本发明的保护范围。

图1示出了根据本发明的一个示例性实施例的用于从车辆提取数据的设备的框图。

现在参考图1，车辆1包括数据记录器2、至少一个传感器3和通信装置4。数据记录器2被配置为在数据记录条件满足的情况下存储预定时间段和/或特定时刻的车辆侧数据，这样的车辆侧数据例如包括车辆的行驶状态数据和/或驾驶员的操作数据和/或车载系统的相关数据和/或外界环境(例如图像或视频信息)数据等。通常情况下，数据记录器2可以包括车辆1的事件数据记录器(Event Data Recorder，简称EDR)和/或自动驾驶车辆数据记录系统(Data Storage System for Automated Driving，简称DSSAD)。数据记录器2可以经由车辆数据总线获取至少一个传感器3的测量值和/或捕捉数据记录器直接关联的系统处理的数据，从而能够在预定义时间段内记录车辆的运行状态、车辆的动力以及驾驶员的操作数据等。在数据记录器2中还可以设有安全存储单元，这用于存储例如车辆1的私钥、至少一个外部设备的公钥、第三方可信机构发放的数字证书和/或安全密钥，以便验证从外部接收的数据的数字签名以及对外部设备的身份和/或权限进行验证。此外，在数据记录器2中还可以包括加密单元，以允许在导出车辆1的车辆侧数据之前为其添加数字签名和/或进行加密处理。数据记录器2连接到通信装置4，由此可以将车辆侧数据传送至数据提取工具，该通信装置4例如被构造为车辆1的诊断端口4并且符合OBD-II接口标准，从而例如能够基于统一诊断服务(Unified diagnostic services，简称UDS)与外界设备交换数据。

用于从车辆1提取数据的设备10例如可以被实现为能够执行数据提取操作的任何类型的计算或处理设备，这例如包括：计算机、移动计算机、可穿戴设备、笔记本等。如在图1中示出的，设备10包括通信接口11和计算单元12。不同诊断通信协议的开发和维护会给车辆制造商和系统供应商带来不必要的成本，为了解决此问题，目前大部分车厂均采用一种与数据链路无关的通用诊断协议(UDS)。为此，设备1的通信接口11被配置为与车辆1的通信装置4适配，也就是说，通信接口11例如同样符合OBD II接口标准并因此支持UDS协议，由此可以使用统一的数据采集设备对不同车辆内部数据进行读取和分析，而无需引入新的通信架构。在该示例中，通信接口11被配置能够借助统一诊断服务向车辆1请求用于描述提取验证规则的描述性表述，并且用于接收车辆1反馈的描述性表述。

计算单元12被配置为能够从车辆1反馈的描述性表述中解析出特定于车辆1的提取验证规则，并基于该提取验证规则控制从车辆1的数据提取操作。为此，计算单元12例如连接到布置在本地或云端的数据库20，以便按照车辆1反馈的描述性表述从数据库20中查找对应的提取验证规则。在该数据库20中按照一定编号或代码顺序地存储有不同鉴权规则和数字签名算法，这示例性地在表1和表2中示出。

验证规则	描述性表述
		RSA2048	0x01
SHA512	0x02
		Certificate based	0x03
…	…
		AES128	0x0A
SM2	0x0B
		SM4	0x0C
IBE-KEM(from SM9)	0x0D
		…	…

表1：鉴权规则示例

表2：数字签名规则示例

在图1所示实施例中，计算单元12还进一步包括鉴权规则引擎121和数字签名规则引擎122。一旦计算单元12从数据库20提取出与车辆1适配的提取验证规则，接下来计算单元12可以将鉴权算法/程序加载到鉴权规则引擎121中，并且将数字签名算法/程序加载到数字签名规则引擎122中，在这一过程中，可以在这两个引擎121、122中的寄存器中加载适当的参数或操作数，由此指示相应的引擎121、122执行加密运算和解密运算，由此允许在数据提取工具10对待发送消息进行签名或者对提取出的经加密的数字签名进行验证。

在此应注意的是，在本实施例中对计算单元12的构型方式仅是示例性的，在其他实施例中设备1还可以包括其他类型或数量的组件。

图2示出了根据本发明的一个示例性实施例的用于从车辆提取数据的方法的流程图。该方法示例性地包括步骤S1-S3，并且例如可以在使用图1所示的设备10的情况下实施。

在步骤S1中，借助统一诊断服务向车辆请求用于描述提取验证规则的描述性表述。

统一诊断服务(UDS)是涵盖了对数据传输方式、数据格式、具体诊断服务等各方面要求的标准交互架构，其例如包括6大类共26种，每种统一诊断服务都有自己独立的服务标识符(Service identifier，简称SID)。对于有些服务，还通过预定义数据标识符(dataidentifier，简称DID)指定数据读/写方式。

作为示例，可以由图1所示的设备10借助“0x22-按照标识符读取数据服务”和“0x23-按地址读取数据服务”向车辆1发送第一诊断请求。在0x22的情况下，利用DID标识某个待读取的数据记录值，在0x23的情况下，需要在第一诊断请求中提供待读取的内存地址范围，并指定要求读取的内存大小。统一诊断服务事先已经定义了一部分DID，例如，0xF186是当前诊断会话数据标识符，0xF187是车厂备件号数据标识符等，但是在ISO协议中同样给DID预留了一些字段，以供各车辆制造商和/或系统供应商自行定义。在本方案中，例如可以分别针对鉴权规则和数字签名规则在预留的字段中定义不同的DID。应该注意的是，这种请求也可以根据其他形式的协议或格式来传输。

在步骤S2中，从车辆反馈的描述性表述中解析出特定于车辆的提取验证规则。

在0x22服务中，支持肯定响应和否定响应形式的消息格式。例如当请求的消息长度不正确或格式无效时会触发否定响应，否则将会通过肯定响应返回特定于车辆的提取验证规则。

作为示例，提取验证规则包括鉴权规则和/或数字签名规则。鉴权规则可以理解为向车辆证明数据提取工具的身份或权限(释放不同权限等级)时用到的规则。数字签名规则可以理解为信息发送者用于产生消息真实性和完整性的有效证明的规则，一套数字签名通常定义两种互补运算，一个用于结合私钥和具体加密算法进行加密和签名，另一个用于结合公钥和加密算法进行解密和验证。一般地，数字签名规则包括对非对称密钥加密技术和数字摘要技术的应用，因此，在车辆提供的针对数字签名规则的描述性表述中不仅涵盖了诸如对称加密算法、非对称加密算法一类的加/解密算法，而且也可以包括散列(哈希)算法。

在该步骤中，在从车辆侧接收到肯定响应之后，从车辆反馈的描述性表述中读取确定标识符对应的数据记录值和/或确定地址指向的内存数据值，然后在数据库中按照索引查找这些值或代码关联的提取验证规则。

在步骤S3中，基于所述提取验证规则控制从车辆的数据提取操作。作为示例，在该步骤中可以借助车辆指定的鉴权规则为数据提取工具提供身份和/或权限证明。作为另一示例，也可以借助车辆指定的数字签名规则对数字签名算法进行验证。

在鉴权方面，取决于车辆适用的鉴权规则，一方面可以利用“0x27-安全访问服务”进行为数据提取工具提供身份/权限证明，另一方面也可以利用“0x29-认证服务”来协助数据提取工具的鉴权。借助车辆指定的鉴权规则为数据提取工具提供身份和/或权限证明例如包括：借助认证服务执行基于PKI证书交换的非对称解密以及执行不带PKI证书的质询-响应过程。

图3示出了根据本发明的一个示例性实施例的用于对数据提取工具进行鉴权过程的时序图。

为便于描述，图1中所示的用于从车辆1提取数据的设备10在上下文中也被同义地称为数据提取工具10。

在步骤301中，数据提取工具10借助统一诊断服务向车辆的事件数据记录器2发送第一诊断请求。

在一个示例中，例如可以基于0x22服务(按标识符读取数据服务)发送第一诊断请求，以读取一个或多个被标识的数据记录值。基于0x22服务的第一诊断请求例如是：03 2200 66，其中，03表示有效数据长度为3个字节，22为服务号(SID)，00 66是代表鉴权规则的数据标识符(DID)。

在另一示例中，还可以基于0x23服务(按地址读取数据服务)发送第一诊断请求，基于该服务的第一诊断请求例如是：07 23 14 20 48 13 92 01，07表示有效数据长度为7字节，23表示服务号，1表示字节数为1，4表示地址占四个字节，20 48 13 92表示地址，01表示字节数为1。

在步骤302中，数据记录器2向数据提取工具10发送肯定响应。UDS消息的SID服务本质上是一种定向通信，即，数据提取工具10向数据记录器2发送指定的诊断请求，如果请求读取的数据有效且诊断请求被顺利执行，则由车辆给予肯定响应。例如，如果发送的第一诊断请求的SID是0x22，那么肯定响应是0x62，如果第一诊断请求的SID是0x23，则肯定响应是0x63。如果由于某种原因无法执行数据提取工具10发过来的诊断请求，则由车辆侧发出否定响应，在这种情况下数据记录器2向数据提取工具10返回的是0x7F开头的报文，这表示数据记录器2拒绝了数据提取工具10的请求。

在步骤302'中，数据提取工具10对数据记录器2反馈的描述性表述进行分析，并从中解析出特定于车辆的提取验证规则。

在一个示例中，由数据记录器2向数据提取工具10发送的肯定响应为：04 62 0066 03，04表示有效数据长度为4个字节，62表示针对0x22请求的肯定响应的服务号(SID)，00 66是代表鉴权规则的数据标识符(DID)，03为该数据标识符对应的数据记录值。在数据提取工具10中，通过参考上文中的表1内容可知，数据记录器2返回的数据记录值“03”表示车辆指定的鉴权规则是基于*.cert文件对数据提取工具10进行安全认证，这尤其可以基于统一诊断服务中的0x29服务(即安全认证服务)来实现证书文件交换和验证。

在另一示例中，由数据记录器2向数据提取工具10发送的肯定响应为：04 62 0066 0D。通过对照上文中的表1可知，数据记录器2返回的数据记录值“0x0D”表示车辆指定的鉴权规则是基于IBE-KEM算法的，这例如可通过统一诊断服务中的0x27服务(安全访问服务)来验证数据提取工具10的身份。

接下来以IBE-KEM算法为例简要介绍车辆对数据提取工具10的鉴权过程。一般地，车辆制造商会为EDR/DSSAD定义一些安全级别较高的诊断服务或数据交互服务(例如上传/下载数据)，在执行此类服务之前，就需要执行基于0x27的安全认证命令，以进行简单的身份验证。

在步骤303中，数据提取工具10借助“0x27-安全访问服务”向车辆发送第二诊断请求，以向数据记录器2请求种子(Seed)。基于0x27服务的第二请求例如是：27 03，27为服务号，03为子服务号(sub-function identification)。在此应注意，请求种子的子服务号不一定要是03，而是也可以是01、05或07-0D之间的任意奇数值，它们分别代表请求进入的不同安全等级。

在步骤304中，接收数据记录器2返回的种子。在数据记录器2收到来自数据提取工具10的第二诊断请求之后，会通过内部随机数生成算法生成随机数，并通过诊断响应将其作为种子返回给数据提取工具10。作为示例，这种响应消息例如可以是：67 03 01 01 01，其中，67为服务号，03代表子服务号或者说安全等级，01 01 01是车辆侧通过随机数生成算法生成的种子(随机数)。

对于数据提取工具10而言，在接收到种子之后，会将其引入车辆要求的鉴权规则(即，IBE-KEM)，并在结合由证书授权中心(Certification Authority，简称CA)分发的本地密码的情况下计算出对应的安全密钥(Key)。也就是说，鉴权规则定义了本地密码与种子之间的函数关系，假设种子是01 01 01，本地密码是01 02 03，而鉴权规则例如是将种子与本地密码相加，由此得到安全密钥值为02 03 04。

接下来在步骤305中，数据提取工具10会把计算出的安全密钥值通过另外的诊断请求发送给数据记录器2。例如，依旧以数据提取工具10请求进入03安全等级为例，数据提取工具10向数据记录器2发送的消息为：27 04 02 03 04，其中，27为服务号，04是用于提供安全密钥的子服务号(03+1)，02 03 04表示安全密钥值。

在车辆侧，数据记录器2在生成种子之后也将按照车辆适用的鉴权规则(即，IBE-KEM)计算出安全密钥。然后，数据记录器2将数据提取工具10计算出的安全密钥值与存储在本地的安全密钥值进行比较。若结果一致，则表示安全认证通过，于是数据记录器2在步骤306中回复肯定响应并切换到对应请求的权限状态。反之，则数据记录器2回复否定响应并附带对应的NRC来表示当前安全解锁失败的原因。作为示例，在安全认证通过的情况下，由数据记录器2向数据提取工具10发送消息“67 04”，这表示数据提取工具10的身份被成功验证。此时车辆的数据记录器2对于数据提取工具10处于解锁状态，那些被保护起来的诊断服务和车辆侧数据可以被正常使用和访问。

图4示出了根据本发明的一个示例性实施例的车辆的数据传输过程的时序图。

在该实施例中，步骤401-402可以与图3中的步骤301-302依次地或并行地进行。例如，在步骤401中，数据提取工具10借助统一诊断服务向车辆的事件数据记录器2请求数字签名规则，该第一诊断请求例如同样可以使用“0x22+数据标识符”或“0x23+指定地址范围”形式的帧格式。

在步骤402中，车辆的数据记录器2向数据提取工具10返回肯定响应，在肯定响应中携带有用于描述数字签名规则的描述性表述，这例如包括：标识符对应的数据记录值或地址字段对应的内存数据值。

在步骤402'中，通过查找相关编号或代码关联的算法类别来确定车辆适用的数字签名算法，这例如可以参照上文中的表2内容来进行。

在步骤403中，通过请求上传服务(0x35)或请求文件传输服务(0x38)发起从车辆的数据记录器2向数据提取工具10的数据传输。作为示例，数据提取工具10借助“0x38-文件传输服务”向车辆发送第三诊断请求，作用是告知数据记录器2准备传输车辆侧数据，从而启动从数据记录器2向数据提取工具10的数据传输过程。

在步骤404中，数据记录器2接收到第三诊断请求之后，通过0x78的肯定响应报文通知数据提取工具10，其接下来的每个数据传输的报文中应包含多少数据字节，数据提取工具将根据该反馈的参数对自身的数据接收能力进行调整。

在步骤405中，如果基于0x38服务的第三诊断请求得到了车辆侧(即数据记录器2)的正确响应，则数据提取工具10通过“0x36-数据传输服务”开始请求数据记录器2返回车辆侧数据。在每个基于0x36服务的请求中都会标识当前请求传输的是第几个数据块，即帧序号，或者简单地说是第几次调用0x36服务。

在步骤406中，数据记录器2会基于0x76服务返回肯定响应，在该肯定响应中的传输响应参数记录(Transfer Response Parameter Record)一项中将会写入数据提取工具10要求且支持的数据，在本实施例中，这例如包括车辆侧数据。这里，每个基于0x76服务传输的数据量大小将由步骤403-404中基于0x38服务约定的参数决定。在从数据记录器2向数据传输工具10传输车辆侧数据的同时，还附加地为传输的数据添加了数字签名，这与车辆侧数据一起被传输给数据提取工具10。

在步骤407中，数据提取工具10基于0x37(退出上传服务)向数据记录器2发送结束数据传输过程的请求。

在步骤408中，如果之前基于0x38服务和0x36服务的数据传输过程都顺利完成，则车辆的数据记录器2向数据提取工具10返回基于0x77的肯定响应。否则，数据记录器2会将以0x7F开头的否定响应发送给数据提取工具10，这表示之前的诊断序列或者数据传输过程的执行有错误。

在步骤409中，数据提取工具10借助车辆要求的数字签名算法对数据记录器2添加的数字签名进行验证。这将在下文中结合图5被进一步阐述。

应理解的是，步骤403-408所描述的数据传输过程仅是示例性的，在这期间也可利用其他类型的统一诊断服务(例如基于0x31的开始/停止例程、基于0x35的数据上传服务等)来实现信息交互。

图5示出了根据本发明的一个示例性实施例的用于验证车辆的数字签名的原理性示意图。

在图5中示例性示出了车辆侧数据的发送方和接收方——即数据记录器2和数据提取工具10。在执行数据传输之前，数据记录器2通过散列算法(如MD5、SHA-1等算法)从原本要传输的车辆侧数据50中提取出一个摘要序列51，并用车辆的私钥对其加密以形成数字签名52。从该摘要序列51中不能通过散列算法逆向恢复出原始传输内容50，即，得到的摘要序列51不会透露最初的明文信息，如果原始信息受到改动，则摘要序列51也会不同。

数据记录器2将车辆的数字签名52连同原本要传送的车辆侧数据50一起发送给数据提取工具10。一方面，由于之前已经通过车辆反馈的描述性表述已知了特定于车辆的数字签名算法(这例如包括车辆使用的散列算法和非对称加密算法)，因此数据提取工具10可以用车辆预先提供的(例如在监管平台备案的)公钥对接收到的数字签名52'进行解密，从而得到第一摘要序列51'。另一方面，数据提取工具10可以借助车辆指定的散列算法从接收到的车辆侧数据50'提取出数字摘要，这被称为第二摘要序列51”。通过比较第一摘要序列51'和第二摘要序列51”是否一致，就可以得知数据提取工具接收到的车辆侧数据50'是否被篡改过。若第一和第二摘要序列51'、51”相同，则表示信息未被改动。

尽管这里详细描述了本发明的特定实施方式，但它们仅仅是为了解释的目的而给出的，而不应认为它们对本发明的范围构成限制。在不脱离本发明精神和范围的前提下，各种替换、变更和改造可被构想出来。

Claims (10)

1.一种用于从车辆(1)提取数据的方法，所述方法包括以下步骤：

S1：借助统一诊断服务向车辆(1)请求用于描述提取验证规则的描述性表述；

S2：从车辆(1)反馈的描述性表述中解析出特定于所述车辆(1)的提取验证规则；以及

S3：基于所述提取验证规则控制从车辆(1)的数据提取操作。

2.根据权利要求1所述的方法，其中，所述提取验证规则包括鉴权规则和/或数字签名规则，

其中，所述鉴权规则尤其包括基于种子-密钥的认证规则、对称性算法、非对称性算法、证书认证规则和/或基于身份的密码；

其中，所述数字签名规则尤其包括散列算法、RSA、椭圆曲线数字签名算法和/或有限自动机数字签名算法。

3.根据权利要求1或2所述的方法，其中，所述步骤S1包括：借助按标识符读取数据服务和/或按地址读取数据服务向车辆(1)发送第一诊断请求，所述第一诊断请求用于使车辆(1)通过第一肯定响应返回所述描述性表述。

4.根据权利要求1至3中任一项所述的方法，其中，在所述描述性表述中，通过标识符对应的数据记录值和/或通过地址指向的内存数据值关联特定于车辆(1)的提取验证规则。

5.根据权利要求1至4中任一项所述的方法，其中，所述步骤S3包括：借助车辆(1)指定的鉴权规则为数据提取工具提供身份和/或权限证明。

6.根据权利要求5所述的方法，其中，借助车辆(1)指定的鉴权规则为数据提取工具提供身份和/或权限证明包括：

借助安全访问服务向车辆(1)发送第二诊断请求，所述第二诊断请求用于使车辆(1)返回种子；

基于车辆(1)指定的鉴权规则从接收到的种子计算出安全密钥值；

将安全密钥值返回给车辆(1)；以及

等待车辆(1)的鉴权认证结果。

7.根据权利要求1至6中任一项所述的方法，所述步骤S3包括：

借助统一诊断服务向车辆(1)发送第三诊断请求，所述第三诊断请求用于发起车辆(1)的数据传输服务；

接收车辆(1)通过数据传输服务发送的车辆侧数据(50)以及车辆侧数据(50)的数字签名(52)；

借助车辆(1)指定的数字签名算法对所述数字签名(52)进行验证。

8.根据权利要求7所述的方法，其中，借助车辆(1)指定的数字签名算法对数字签名(52)进行验证包括：

借助车辆(1)预先提供的公钥按照指定的数字签名算法对车辆侧数据(50)的数字签名(52)解密，以得到第一摘要序列(51')；

借助车辆(1)指定的散列算法从所接收到的车辆侧数据(50)计算第二摘要序列(51”)；

将第一摘要序列(51')与第二摘要序列(51”)比较；以及

根据比较的结果确定数字签名(52)验证的结论。

9.一种用于从车辆(1)提取数据的设备(10)，所述设备(10)用于执行根据权利要求1至8中任一项所述的方法，所述设备(10)包括：

通信接口(11)，所述通信接口(11)被配置为能够借助统一诊断服务向车辆(1)请求用于描述提取验证规则的描述性表述，并且用于接收车辆(1)反馈的描述性表述；以及

计算单元(12)，所述计算单元(12)被配置为能够从车辆(1)反馈的描述性表述中解析出特定于车辆(1)的提取验证规则，并基于所述提取验证规则控制从车辆(1)的数据提取操作。

10.一种机器可读的存储介质，在所述存储介质上存储有计算机程序，所述计算机程序用于当在计算机上运行时执行根据权利要求1至8中任一项所述的方法。