CN115462056A - 向v2x消息中添加保证信息的方法和系统 - Google Patents

向v2x消息中添加保证信息的方法和系统 Download PDF

Info

Publication number
CN115462056A
CN115462056A CN202180031993.7A CN202180031993A CN115462056A CN 115462056 A CN115462056 A CN 115462056A CN 202180031993 A CN202180031993 A CN 202180031993A CN 115462056 A CN115462056 A CN 115462056A
Authority
CN
China
Prior art keywords
entity
message
indication
assurance
security
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180031993.7A
Other languages
English (en)
Inventor
S·J·巴雷特
M·范德尔维恩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
BlackBerry Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BlackBerry Ltd filed Critical BlackBerry Ltd
Publication of CN115462056A publication Critical patent/CN115462056A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]

Abstract

一种智能交通系统(ITS)实体处的方法，该方法包括从第二ITS实体接收消息，该消息包含安全保证指示,以及基于安全保证指示在ITS实体处执行动作。此外，一种ITS实体包括处理器；以及通信子系统，其中ITS实体被配置为：从第二ITS实体接收消息，该消息包含安全保证指示；并且基于安全保证指示在ITS实体处执行动作。

Description

向V2X消息中添加保证信息的方法和系统
技术领域
本公开涉及车辆到一切(V2X)通信，并且具体地涉及V2X消息的信任。
背景技术
在智能交通系统(ITS)中，多个设备进行通信，以便交通系统在交通和流量管理方面做出更明智的决策，以及做出更安全、更协调的决策。ITS系统组件可以作为固定基础设施的部分设置在车辆内，诸如在桥梁上或在十字路口，以及被设置用于交通系统的其他用户，包括行人或骑自行车者。
ITS系统部署在世界各地的多个市场都受到了极大的关注，无线电频带被分配用于通信。除了用于安全关键和非关键应用的车辆到车辆通信之外，正在为车辆到基础设施和车辆到便携场景开发进一步的增强功能，以提供交通安全和效率。
然而，当这样的设备通信时，接收设备需要确信所接收的消息是可信的，以便对这样的消息中的信息采取行动。接收设备在确定可信度时面临的问题的一个方面是，发送实体是否正确运行，换言之，它没有故障。接收设备在确定可信度时面临的问题的另一方面是发送实体的行为是否符合预期。
附图说明
参考附图可以更好地理解本公开，在附图中：
图1是示出V2X系统中的证书的示例公钥基础设施架构的框图；
图2是示出V2X架构中的证书取回和V2X通信过程的数据流图；
图3是示出V2X架构中具有附加保证信息的证书取回和V2X通信过程的数据流图；
图4是示出可以用于传递功能安全、预期功能安全或聚合信息的信令八位字节的框图；
图5是示出接收ITS实体处用于基于接收的V2X消息中的功能安全保证等级信息来确定如何对接收的V2X消息作出反应的过程的流程图；
图6是示出接收ITS实体处用于基于接收的V2X消息中的预期功能安全保证等级信息来确定如何对接收的V2X消息作出反应的过程的流程图；
图7是示出接收ITS实体处用于基于接收的V2X消息中的多个安全保证等级信息来确定如何对接收的V2X消息作出反应的过程的流程图；
图8是示出接收ITS实体处用于基于接收的V2X消息中的聚合安全保证等级信息来确定如何对接收的V2X消息作出反应的过程的流程图；以及
图9是能够与本公开的实施例一起使用的示例计算设备或服务器的框图。
具体实施方式
本公开提供了一种智能交通系统(ITS)实体处的方法，该方法包括：从第二ITS实体接收消息，该消息包含安全保证指示；以及基于安全保证指示在ITS实体处执行动作。
本公开进一步提供了一种智能交通系统(ITS)实体，该ITS实体包括：处理器；以及通信子系统，其中ITS实体被配置为：从第二ITS实体接收消息，该消息包含安全保证指示；并且基于安全保证指示在ITS实体处执行动作。
本公开进一步提供了一种用于存储指令代码的计算机可读介质，该指令代码在由智能交通系统(ITS)实体的处理器执行时使ITS实体：从第二ITS实体接收消息，该消息包含安全保证指示；并且基于安全保证指示在ITS实体处执行动作。
在确定是否对接收的V2X消息采取行动时，V2X实体(诸如，接收该消息的车辆)可能需要确定是否可以信任该消息。消息的信任可能因消息类型而异。例如，安全关键用例可能需要更高等级的信任，诸如紧急制动警告，其中接收车辆可能需要确定是否应当对消息内容采取行动并且用力制动，甚至可能在没有其他证实信息的情况下。例如，大型卡车可能位于发送消息的车辆与接收消息的车辆之间，从而消除任何视线证实信息。
接收V2X实体在确定发送V2X实体的可信度时所面临的问题的各个方面都存在。第一方面是接收实体是否能够确信传输实体是网络安全的，并且没有或不太可能被黑客攻击。
第二方面是接收实体是否能够确信V2X传输实体没有故障并且因此没有错误地生成消息或生成具有内容错误的消息。
第三方面是接收实体是否能够确信V2X传输实体按预期运行。在这个第三方面，接收实体可能需要确定它是否确信在传输实体处的复杂感知算法的设计中没有不足或者在传感器的性能和操作中没有不足，这些不足可能导致错误地生成消息或生成具有内容错误的消息。
目前还没有解决方案可以用于V2X接收实体建立对V2X消息是由无故障传输器生成的信任。
此外，V2X接收实体无法通过任何解决方案确定预期功能安全性(SOTIF)存在功能安全性。具体地，V2X接收实体可能需要知道V2X传输实体不会基于预期功能故障来不适当或不准确地生成消息或消息内容。V2X消息可以基于感知算法生成，诸如人工智能(AI)或机器学习(ML)算法。然而，确保这样的AI/ML感知算法始终按预期运行的过程是困难的。例如，很难完全确信用于训练AI/ML模型的数据的类型和数量足以涵盖感知算法在现场可能遇到的所有场景。从SOTIF的观点来看，就制造方应当遵循的一套程序和流程而言，ISO 21448为这样的问题提供了答案，以便产品被视为“可接受释放”。
此外，在生成与不同用例相关联的消息时，可能会涉及不同的电子控制单元集(ECU)。例如，一条V2X消息(诸如，紧急制动警告)可以涉及从制动系统获取传感器信息，而诸如定期的合作意识消息(CAM)或基本安全消息(BSM)等其他V2X消息可能不会。制造方可能希望避免设计具有网络安全性、功能安全性或要求最高的V2X应用的SOTIF保证等级的每个ECU，因为这将不必要地昂贵。因此，在某些情况下，根据与给定V2X消息相关的特定应用类型来确定可信度可能是有利的。具体地，当前与网络安全保证相关的标准化使V2X传输器能够根据应用类型(PSID)指示网络安全保证等级(TAL)，但这些标准不支持在应用类型中存在多种操作模式的情况下指示保证等级。
此外，在车辆证书中添加区分信息(包括功能安全(FuSa)等级、SOTIF等级等)的一个问题是，该信息可以用于帮助希望跟踪车辆的人。特别是当不同的车辆具有不同的(尽管是固定的)设置时。这可能会降低传输V2X消息的车辆的车主或驾驶员的隐私。
本公开的实施例解决了上述问题中的一个或多个问题。
本公开与V2X有关，V2X是一种提供从车辆到其他实体(也可能相反)之间的消息通信的特征，该信息可能会影响车辆和/或其他实体。因此，V2X实体是支持发送V2X消息和接收V2X消息中的一者或两者的实体，并且可以包括智能交通系统(ITS)站(ITS-S)、电子控制单元(ECU)、车载单元(OBU)、用户设备(UE)、移动实体(ME)、终端实体(EE)等选项。V2X实体在本文中也称为ITS实体，并且术语可以互换使用。
与车辆之间的通信可以是与各种V2X端点之间的通信。V2X端点可以包括：其他车辆，其单独称为车辆到车辆(V2V)；基础设施，诸如路边单元，其单独称为车辆到基础设施(V2I)；行人或骑自行车者，其单独称为车辆到行人(V2P)；(多个)网络，其单独称为车辆到网络(V2N)；设备，诸如车辆内的电子设备，其单独称为车辆到设备(V2D)；电网，其单独称为车辆到网络(V2G)；以及其他选项。这些统称为V2X。
V2X通信可以用于多种用途。在某些情况下，V2X可以用于道路安全和提高道路运输效率两者，诸如通过减少拥堵或减少燃油消耗。
各种系统/架构可以提供V2X通信。诸如第三代合作伙伴项目(3GPP)规范中限定的蜂窝网络就是一个这样的系统/架构。例如，其他系统/架构可以包括综合数字增强网络(iDEN)、电气与电子工程师协会(IEEE)802.11p无线网络等。
目前存在各种标准可以用于在V2V消息中传达网络安全保证等级。其中包括欧洲电信标准协会(ETSI)、电气与电子工程师协会(IEEE)1609.2、2016年12月的“IEEE WAVE标准——应用和管理消息安全服务——IEEE 1609.2-2016合并草案及1609.2a/D8和1609.2b/D3中规定的修订”、以及Car2Car联盟。
通常，V2X通信由V2X实体发送的V2X消息和接收的V2X消息组成。V2X消息是广播消息，该广播消息包含有关车辆当前位置、速度的信息或其他信息，并且由临时密钥签名，临时密钥与属于发送实体的匿名证书相关联。证书将被完整发送，或者它的哈希将与消息一起发送。能够检测和解码这些消息的接收实体能够验证用于对其签名的证书。这些证书中可以包括网络安全保证等级。
例如，在欧洲ITS系统中，ETSI技术规范(TS)103 097“ITS；安全；安全报头和证书格式”v1.3.1(2017年10月)和ETSI TS 102941“ITS：安全；信任和隐私管理”v1.2.1(2018年5月)提供了这样的验证。在这个欧洲ITS系统中，在ITS站(ITS-S)制造时，在ITS-S中提供有规范的全球唯一标识符，并且在注册机构中提供有同一标识符以及与该标识符相关的其他信息，包括保证等级和ITS应用标识符(ITS AID)。此外，还可以提供服务特定权限(SSP)，以详细说明在创建和发送消息时允许车辆使用的应用或应用的特征。
现在参考图1，图1提供了欧洲电信标准协会(ETSI)ITS公钥基础设施的示例概览，如ETSI技术标准(TS)102 904“智能运输系统(ITS)安全、ITS通信安全架构和安全管理”v.1.2.1(1916年11月)中限定的。
在图1的示例中，在制造时，向V2X实体(例如，ITS-S 110)提供有规范标识符(ID)(它是V2X系统中每个V2X实体唯一的ID)，并且向注册机构112提供有相同的规范ID以及与该规范ID相关的其他信息，诸如保证等级。
在ITS架构中，注册机构112在接收到规范ID和可能的其他数据(例如，公钥)122时对ITS-S 110进行认证，并且通过颁发注册证书124来授予其参与ITS通信的授权。授权机构130(在美国系统(或IEEE描述的系统)中也称为授权证书机构)通过提供可以用于这些服务的临时/匿名证书132(也称为授权票据或授权证书)来向ITS-S 100提供使用特定ITS服务的授权。该授权基于注册ID 134，该注册ID 134由注册机构112使用授权验证请求136和授权验证响应138进行验证。
根证书机构140可以向注册机构112提供证书142，并且向授权机构130提供证书144。
然后，ITS-S 110可以使用利用授权证书保护的消息152与其他V2X端点(诸如ITS-S 150)通信。
证书消息传递的示例关于图2进行描述。在图2的实施例中，ITS-S发送实体210希望与ITS-S接收或中继实体212通信。但是，首先必须从注册机构214接收注册凭证，并且从授权机构216接收授权票据/证书。
在这点上，ITS-S发送实体210向注册机构214发送EnrollmentRequest消息220，并且包括其规范ID和公钥。
注册机构214利用EnrollmentResponse消息222响应于ITS-S发送实体210，并且包括结果和注册凭证。
ITS-S发送实体210然后通过向授权机构216发送AuthorizationRequest消息230来请求证书/授权票据。消息230包括服务参数。
授权机构216向注册机构214发送包括服务参数的AuthorizationValidationRequest消息232。注册机构215利用带有结果的AuthorizeationValidationResponse消息234响应于授权机构214。消息234还可以包括适用的保证等级。授权机构216可以在其产生的授权票据(也称为匿名证书或授权证书)中包括保证等级(如果接收到)。如本文中使用的，授权票据可以包括欧洲授权票据或美国授权证书，以前称为匿名证书。
这些授权票据由授权机构216在AuthorizationResponse消息240中提供给ITS-S发送实体210。
然后，ITS-S发送实体210可以将V2X消息(示出为SecuredMessage 250)发送给智能运输系统中的另一ITS-S，诸如ITS-S接收或中继实体212。在希望发送V2X消息时，ITS-S发送实体210通常创建V2X消息，V2X消息包括证书(授权票据)和有效负载(例如，车辆当前位置、速度)；使用众所周知的哈希算法计算可变长度V2X消息的固定长度哈希；使用ITS-S发送实体的私钥对哈希进行签名；并且将签名附加到有效负载并且发送所得到的V2X消息。
因此，V2X消息包含消息内容、消息的签名哈希和证书。根据ETSI TS 102 940，消息内容可能受到真实性、完整性、机密性和隐私性保护。因此，有效负载可以加密，但无需加密。
除其他外，证书可以包括发送实体的公钥；发送实体的匿名身份；签名块，其是发送实体的身份和发送实体的公钥的哈希，该哈希由证书机构使用证书机构的私钥进行签名；对证书进行签名的证书机构的身份；以及发送V2X实体的保证等级。
在接收到消息250时，ITS-S接收或中继实体212通常会将证书机构的已知公钥应用于证书的签名块，以验证发送实体的身份和发送实体的公钥。
然后，ITS-S接收或中继实体212可以检查身份是否不在证书吊销列表(CRL)中的身份列表(指向)上。如果发送实体的身份位于CRL上，则该消息可以被丢弃。ITS-S接收或中继实体212可以执行其他合理性(非加密)检查和有效性(加密)检查。
然后，ITS-S接收或中继实体212可以使用发送实体的公钥来验证V2X消息中包括的签名。
虽然以上描述了接收通过证书进行验证的V2X消息，但在某些情况下，还需要传达网络安全保证等级。例如，IEEE 1609.2；ETSI、互联网工程任务组(IETF)和Car2Car联盟中描述了用于提供网络安全保证等级的各种解决方案。
具体地，IEEE 1609.2中限定的获取注册证书和申请证书(类似于“授权票据”，以前称为“匿名证书”)的过程与ETSI TS 103 097中描述的过程相似。“assuranceLevel”项可以被包括在与V2X消息一起发送的IEEE 16092.证书中，其中该证书的对应私钥用于对V2X消息进行签名。
例如，IEEE 1609.2将ToBeSignedCertificate限定为包括各种字段，诸如Id、cracaID、region和assuranceLevel等字段。assuranceLevel的值限定为SubjectAssurance，并且是可选的。
此外，用于接收安全数据交换实体(SDEE)信息的设计还可以基于证书中的assuranceLevel字段来为特定签名的安全协议数据单元(SPDU)有效负载指定最低保证等级。在这种情况下，接收SDEE可以检查证书中的assuranceLevel是否适合接收的有效负载。例如，这在IEEE 1609.2的第5.2.4.3.3节有概述。
在名为draft-tls-certieee1609-02.txt的文件中，“使用ITS ETSI和IEEE证书的传输层安全(TLS)认证”，2018年3月，IETF被视为信任保证等级(强制性)。具体地，该草案规定：信任保证等级：CA和终端实体的C-ITS证书必须包含TAL：(1)对于V2X通信系统的安全性，确保参与者的车内安全至关重要：消息接收方必须能够依赖于发送方正确生成消息这一事实(即，汽车传感器信息是准确和完整的)。因此，发送方的安全漏洞将对消息的所有接收方产生影响；以及(2)只有具有合理“安全等级”的车辆才能从PKI获取证书。车辆到车辆通信联盟(C2C-CC)引入了不同等级的信任，限定为信任保证等级，并且车辆的授权票据(即，匿名证书)必须包括车辆TAL的值。后续草案不包含该要求。
Car2Car联盟为Car2Car通信联盟中的V2X硬件安全模块(HSM)限定了评估保证等级(EAL4)通用标准保护简档，“V2X硬件安全模件保护简档”(2018年8月)。Car2汽车联盟基本简档第7.4.6节“C2C-CC基本系统简档”(2016年8月)描述了C2X站的信任保证。重点包括5个信任等级被指定为信任保证等级(TAL)0到TAL4，其中TAL 4是最高信任保证等级。ITS站的最低可接受TAL为TAL2。根据ETSI TS 103 097，每个TAL映射到受试者保障表示。
此外，2012年在Car2Car联盟/CAMP会议上的演示有以下亮点：接收方可以基于以下概念来确保V2X消息没有错误，即，受信任方已经根据成熟的国际公认和可信的安全标准评估了发送端点，并且颁发证书，接收方可以验证其对向发送方妥协的难度的看法。会议进一步建议，不同的TAL可以用于不同的应用，因为如果只有一个TAL等级，则它必须是要求最高的应用所需要的TAL等级。对于所有应用来说，这个等级可能很难达到。
Car2Car会议考虑了“可信国际标准”的选项，包括NIST FIPS-140-X，该标准更多地涉及加密技术的使用，而非全面的网络安全标准；ISO通用标准3.1，其耐久性有限(2年)，这造成问题，并且成本高昂；以及CC改编的定制OEM C2X评估方案。此外，ISO/SAE21434国际标准草案“道路车辆——网络安全工程”(2020年2月)在2012年不存在，但如下所述。
C2C论坛限定的信任保证等级的示例如下表1所示。
Figure BDA0003915706630000091
Figure BDA0003915706630000101
表1：C2X站的信任保证等级
在上面的表1中，TAL 2是最低可接受等级。
保证等级的另一示例是关于PRESERVE。PRESERVE是一个欧洲共同体资助的项目，涉及车辆到一切通信的安全和隐私方面。“PRESERVE”(EC-DG INFSO资助的第七个框架计划)第2.5节(2016年1月)(“准备安全车辆到X通信系统”，可交付成果5.4，部署问题报告)的亮点包括：只有具有合理安全等级的车辆才能从C2X PKI处获取证书；实体(例如，认证型公司/行业联盟/OEM自行签名)应当能够验证V2X模块是否达到最低安全等级；成功的评估和认证可以作为注册机构向车辆颁发注册凭证的基础；TAL应当被包括在车辆的授权票据(匿名证书)中。
IEEE 1609.2证书的PSID和SSP
公共服务标识符(PSID)类似于ETSI ITS-AID，并且提供应用领域的标识符。SSP和PSID在IEEE 1609.2中进行了标准化，并且提供了以下内容。
应用权限定义为允许证书持有人按照其证书中的规定采取的多种。这样的应用权限在标准中使用PSID来表示。
如上所述，SSP是服务特定权限，并且由字段组成，该字段指示特定证书持有人相对于特定应用领域的权限。
使用这些定义，在证书中使用PSID来指定允许的应用领域。为应用权限中的每个PSID隐式或显式提供有SSP，以标识该PSID的应用领域中的特定发送方权限。SSP的语法和语义特定于每个PSID值。
例如，表1示出了IEEE 1609.2标准的第6.4.24节中提供的PsidSsp定义。
Figure BDA0003915706630000111
表2：PsidSsp格式
表2的结构表示证书持有人对单个应用领域(由Psid标识)的数据拥有的权限。如果省略ServiceSpecificPermissions字段，则表示证书持有人具有与该PSID相关联的默认权限。
关于SSP，如IEEE 1609.2的第5.2.4.3.3节所述，证书提供了两个字段，该字段用于确定单个SPDU的有效负载与发送方的权限一致。PSID字段指示发送方有权发送与由PSID字段指示的应用领域相关联的有效负载。SSP字段指示发送方有权发送在该应用领域内的特定负载类型。应用领域内应用行为的定义包括从有效负载内容到定义有效负载有效性的权限(PSID和SSP)的映射。换言之，PSID所有者的职责中的一个职责是定义SSP的语法和语义并且定义特定SSP允许的有效负载。
PSID、SSP和保证等级被包含在IEEE 1609.2的第6.4.8节中规定的证书中。证书格式支持包括多个(PSID，SSP)对，但PSID在有效证书中不会出现多次，因此正确的PSID可能与签名的SPDU有模糊关联。
隐私
智能交通系统内的一个原则是，应当尊重传输实体的隐私。然而，利用SSP传达传输车辆的能力可能会降低隐私，因为这种特殊SSP与附近其他传输实体的SSP不同。通常，匿名临时证书中的任何显著特征都会降低隐私。
如下文更详细地描述，为了克服这一点，在某些情况下，传输实体可以有多个证书与其相关联。特别是，传输实体可以具有“普通”证书，而没有任何特殊权限，另一证书可以具有为高级能力而设置的SSP。在这种情况下，传输实体将仅在消息授权时使用SSP证书，并且在其他任何地方使用普通证书。
提供功能安全和/或SOTIF保证等级的指示
因此，根据本公开，提供了各种解决方案，以建立对V2X消息是由无故障的传输器生成的信任。此外，上述实施例还提供了SOTIF功能安全的保证。在本文中的各种实施例中，解决方案可以基于ECU的功能进行定制。
这些和其他实施例描述如下。在下面的实施例中，示例是根据欧洲合作凭证管理系统(CCMS)描述的。然而，这仅仅是为了说明目的而提供的，并不具有限制性。类似的概念可以应用于任何其他类型的安全凭证管理系统(SCMS)，包括但不限于基于美国防撞度量合作伙伴(CAMP)的SCMS系统、中国SCMS系统等其他选项。
功能安全和/或SOTIF保证等级的指示示例关于图3进行描述。在图3的实施例中，ITS-S发送实体310希望与ITS-S接收或中继实体312通信。然而，首先，必须从注册机构314接收注册凭证，并且从授权机构316接收授权票据。此外，在图3的实施例中，数据库315可以存储实体的验证保证等级。
在这点上，ITS-S发送实体310向注册机构314发送EnrollmentRequest消息320，并且包括其规范ID和公钥。
注册机构314用EnrollmentResponse消息322响应于ITS-S发送实体310，并且包括结果和注册凭证。
ITS-S发送实体310然后通过向授权机构316发送AuthorizationRequest消息330来请求证书/授权票据。消息330包括服务参数。
授权机构316向注册机构314发送包括服务参数的AuthorizationValidationRequest消息332。在一个实施例中，授权机构316可以请求注册机构314使用AuthorizeationValidationrequest消息332中的RequestedSubjectAttributes字段的更新来提供新参数。特别是，提供了本文中定义为fusaAssuranceLevel和/或sotifAssuranceLevel的新参数。这些保证等级描述如下。因此，消息332内的RequestedSubjectAttributes可以请求fusaAssuranceLevel和/或sotifAssuranceLevel。但是，消息332中对fusaAssuranceLevel和/或sotifAssuranceLevel的请求是可选的，并且在某些情况下，注册机构314可以提供这些参数而无需请求。
在接收到消息332之后，或预期会接收到对特定实体的授权请求时，注册机构314可以从数据库315中获取AssuranceInfo，如消息334所示。如本文中使用的，AssuranceInform用于表示fusaAssuranceLevel和/或sotifAssuranceLevel。
特别是，诸如“欧洲合作智能交通系统(C-ITS)部署和运行的证书策略”(2017年6月，欧盟委员会发布的第1版)等策略和管理文件可能需要更新，以定义证书机构要执行的新要求。增加的要求包括，认证机构可能需要确定是否有来自独立第三方的证据表明原始设备制造方所述的与给定规范身份相关联的保证等级已经实现。所述保证等级可以处理网络安全、功能安全和/或SOTIF中的一个或多个。此外，可选地，所述保证等级还可以与给定V2X应用类型(诸如，PSID)相关联。
该验证的保证等级将记录在注册机构314可以访问的数据库315中。
注册机构312利用带有结果的AuthorizationValidationResponse消息340响应于授权机构316。消息340还可以包括适用的保证等级。授权机构316可以在其产生的授权票据(也称为匿名证书)中包括保证等级(如果接收到)。此外，除了当前保证等级参数，还可以提供新的参数fusaAssuranceLevel和/或sotifAssuranceLevel，在图3中表示为AssuranceInfo。以上所有内容(包括网络安全保证等级)都可以被提供作为由PSID表示的应用类型的函数，并且可选地，也可以作为SSP的函数。
这些授权票据由授权机构316在AuthorizationResponse消息350中提供给ITS-S发送实体310。特别是，消息350包括将被更新以与当前assuranceLevel参数一起包括fusaAssuranceLever和/或sotifAssuranceLevel的授权票据。
特别是，当前授权票据的构成如下表3所示：
Figure BDA0003915706630000141
Figure BDA0003915706630000151
表3：授权票据在第一实施例中，授权票据可以如下表4中的粗体所示进行修改：
Figure BDA0003915706630000152
表4：修改后的授权票据
根据本公开的一个实施例，SubjectFusaAssurance可以取与汽车安全完整性等级(ASIL)A、B、C或D相对应的四个值中的一个值，例如国际标准组织(ISO)26262中定义的。但是，SubjectHusaAssuration的其他选项也是可能的。
根据本公开的一个实施例，SubjectSotifAssurance可以取与“SOTIF接受释放的证据”或“没有SOTIF接受释放的证据”相对应的两个等级中的一个等级(BOOLEAN)。然而，SubjectSotifAssurance的其他选项也是可能的。
此外，在某些情况下，为了避免混淆，可以将当前“assuranceLevel”重新标记为“cybersecurityAssuranceLever”或类似内容。
在其他实施例中，为了进一步解决每应用类型/服务类型的保证等级的提供问题，授权票据的证书格式可以如下表5中的粗体和删除线所示进行修改：
Figure BDA0003915706630000161
Figure BDA0003915706630000171
表5：修改后的授权票据
因此，通过使用表5的结构，可以指定每个应用类型或服务类型的保证等级。
在另一实施例中，可能需要避免设计具有网络安全性、功能安全性或要求最高的V2X应用的SOTIF保证等级的每个ECU，因为这将不必要地昂贵。因此，在某些情况下，根据与给定V2X消息相关的特定应用类型来确定可信度可能是有益的。
因此，根据本另外的实施例，可以在为编码SSP而预留的八位字节内提供保证等级信息。现在参考图4，图4示出了传输的八位字节的格式410，其中传输了三个八位字节，即八位字节0、八位字节1和八位字节2。这些八位字节可以用于编码功能安全、网络安全和/或保证等级，如下所述。
用于功能安全的八位字节编码
关于功能安全，应用的一个示例用途是应用“道路和车道拓扑(RLT)”。这种类型的信息可以由车辆发送或接收，并且对于车辆来说，相信发送方经过安全认证可能很重要，因为不正确的道路拓扑可能会导致其他车辆处出现错误，这些车辆无法使用自己的传感器确定这样的拓扑，但仍需将该信息用于机动规划。然而，该应用仅用于说明，并且其他应用也是可能的。
为了对安全等级进行编码而不在RLT消息中不引入新字段，已定义的SSP八位字节串的最后的八位字节的四个位被设置为发信号通知最低安全认证，汽车安全完整性等级(ASIL)中的每个汽车安全完整性等级有一个。如果仅实现了传输车辆的ASIL A认证，则只有安全八位字节的位0设置为1(即，1,0,0,0)，所有其他位都设置为0。如果ASIL D，则所有前四位都设置为1(或者4位可以设置为0,0,0,1)。
例如，ETSI TS草案103 301v.1.3.3第5.4.3.2节可以如下表6中的粗体所示进行修改：
八位字节# 描述 值
0 SSP版本控制 1
1-2 服务特定参数 参见表7
表6：RLT服务SSP的八位字节方案服务参数在下表7中定义，对该表的补充以粗体示出：
Figure BDA0003915706630000181
表7：RLT服务通信简档
表6和表7的示例是一种可能性。但是，也可以使用其他备选编码。例如，前两位可以用于通过四个值0、1、2和3以最低安全等级值发信号通知，每个值分别表示ASIL A、B、C或D。
在另一备选方案中，第一八位字节内的备用位可以用于相同目的。
其他编码选项是可能的。
用于网络安全的八位字节编码
关于网络安全，应用的一个示例用途是RLT应用。这种类型的信息可以由车辆发送或接收。为了对网络安全等级进行编码而不在RLT消息中引入新字段，可以设置已定义的SSP八位字节字符串的最后的八位字节的四位，以发信号通知最低安全认证，网络安全保证等级中的每个网络安全保证等级有一个，例如ISO 21434CAL或ETSI定义的TAL提供的。根据本公开的实施例，提供了关于CAL的示例，但也可以同样适用于TAL。
如果仅实现传输车辆的CAL 1认证，则仅网络安全八位字节的位0设置为1，所有其他位设置为0。如果实现传输车辆的CAL 4认证，则所有前四位设置为1(或者4位可以设置为0,0,0,1)。
其他备选编码也是可能的。例如，前两位通过0、1、2和3四个值发信号通知最低网络安全等级，每个值分别表示CAL 1、2、3或4。
其他选项也是可能的。
例如，ETSI TS草案103 301v.1.3.3第5.4.3.2节可以如下表8中的粗体所示进行修改。
八位字节# 描述 值
0 SSP版本控制 1
1-2 服务特定参数 参见表9
表8：RLT服务SSP的八位字节方案服务参数在下表9中定义，对该表的补充以粗体示出：
Figure BDA0003915706630000191
Figure BDA0003915706630000201
表9：RLT服务通信简档
为了完整性，在上面提到ISO 21434CAL的表9中，这也可以是其他一些网络安全保证等级，包括但不限于car2Car联盟TAL或通用标准ISO 15408EAL。
SOTIF的编码也可以采用类似的方法，尽管在这种情况下只需要编码两个值：例如，“接受释放”或“不接受释放”。
其他选项也是可能的保证等级集的八位字节编码
如果为网络安全、FuSA和SOTIF中的每个提供保证等级细分，则可能需要发信号通知的可能组合的数目最多为5×5×2＝50。因此，这需要在最有效的可能编码中使用6位。具体地，有5个网络安全等级(TAL 0、1、2、3、4或CAL 1、2和3、4)和5个FuSa等级(QM、ASIL A、ASIL B、ASIL C、ASIL D)以及2个SOTIF等级(“防止向CA提交SOTIF相关的释放接受证据”、“没有向CA提交SOTIF相关的释放接受证据”)。
然而，可能只支持这三种保证的某些组合，因此组合保证的总数实际上少于50。例如，如果行业参与者同意申请至少需要CAL 2、ASIL B和“证明”SOTIF等级，则可以排除一些可能的组合。
基于上述，可以使用各种编码来传输fusaAssuranceLevel和/或sotifAssuranceLevel。再次参考图3。
在接收到消息350时，ITS-S发送实体310可以将V2X消息(示出为SecuredMessage360)发送给智能运输系统中的另一ITS-S，诸如ITS-S接收或中继实体312。在希望发送V2X消息时，ITS-S发送实体310通常创建V2X消息，V2X消息包括证书(授权票据)和有效负载(例如，车辆当前位置、速度)；使用众所周知的哈希算法计算可变长度V2X消息的固定长度哈希；使用ITS-S发送实体的私钥对哈希进行签名；并且将签名附加到有效负载并且发送所得到的V2X消息。在这种情况下，授权票据包括上述新的FuSa和/或SOTIF保证等级参数。
在接收消息360时，ITS-S接收或中继实体312通常将证书机构的已知公钥应用于证书的签名块，以验证发送实体的身份和发送实体的公钥。
ITS-S接收或中继实体312被预先编程有FuSa(ASIL)等级，接收车辆的设计者认为该等级对于给定应用是必要的。如本文中使用的，该等级被指定为“demandedASIL等级”。
因此，当接收到消息360时，ITS-S接收或中继实体312将检查以确定消息是否满足demandedASILlevel。现在参考图5。
图5的过程从框510开始，并且进行到框512，其中ITS-S接收或中继实体312确定V2X消息是否已经被接收到。如果没有，则该过程将继续循环到框512，直到接收到V2X消息。
一旦接收到V2X消息，该过程将进行到框520，其中进行检查，以确定V2X传输器的fusaAssuranceLevel(ASIL)(例如，从消息360中发现的ITS-S发送实体310)是否大于或等于接收实体的demandedASILlevel。
如果是，则该过程从框520进行到框530，其中接收V2X应用可以对V2X消息内容采取行动，而无需采取任何相应缓解行动，至少从FuSa的角度来看是这样的。
例如，如果V2X应用是紧急制动警告应用，则在框530，消息内容是可信的，并且可以用力踩下制动器，即使这可能会导致其他事故，比不用力踩下制动器的情况下发生的事故要轻。
相反，如果框520的检查确定V2X传输器的fusaAssuranceLevel(ASIL)低于接收实体的demandedASILlevel，则可能需要采取缓解措施，如框540所示。
例如，在紧急制动警告应用的情况下，与框530相比，框540的消息内容可信度较低。在这种情况下，在等待进一步的确证证据(诸如前方车辆以紧急方式应用其制动器的视觉证据)之前，仍可以更柔和地应用制动器。
在某些情况下，认证的fusaAssuranceLevel与demandedASILlevel之间的差异越大，接收实体对消息的反应就越谨慎，因此可以减少对消息的回应程度。例如，如果这两个等级之间存在较大差异，则车辆可能不会应用任何制动，而是可能会对制动器预充电。例如，这可能涉及启动液压系统，并且在人类驾驶员或自主机器人确实踩下制动器时，增加踩下制动器的力和速度。其他选项也是可能的。
从框530或框540，该过程进行到框550并且结束。
类似地，如果消息360包含sofitAssuranceLevel，则接收实体可以检查以确定该等级是否为“SOTIF接受释放的证据”。现在参考图6。
图6的过程从框610开始，并且进行到框612，其中ITS-S接收或中继实体312确定V2X消息是否已经被接收到。如果没有，则该过程将继续循环到框612，直到接收到V2X消息。
一旦接收到V2X消息，该过程将进行到框620，其中进行检查，以确定sofitAssuranceLevel是否为“SOTIF接受释放的证据”。如果是，则该过程从框620进行到框630，其中接收V2X应用可以对V2X消息内容进行到，而无需采取任何相应缓解措施。例如，使用紧急制动警告应用时，接收的消息内容值得信任，并且可以用力踩下制动器，即使这可能会导致其他事故，比不用力踩下制动器的情况下发生的事故要轻。
相反，如果框620的检查确定sofitAssuranceLevel“没有SOTIF接受释放的证据”，则该过程从框620进行到框640，其中可能需要采取缓解措施。例如，在紧急制动警告应用的情况下，消息内容的可信度较低。在进一步证实前方车辆实际紧急制动的证据之前，可以更柔和地制动。
从框630或框640，该过程进行到框650并且结束。
此外，如果消息360包含保证等级的组合，诸如(网络安全)保证等级、fusaAssuranceLevel和/或sotifAssuranceLevel，则接收实体可以检查以确定这些等级是否满足最低要求。现在参考图7。
图7的过程从框710开始，并且进行到框712，其中ITS-S接收或中继实体312确定V2X消息是否已经被接收到。如果没有，则该过程将继续循环到框712，直到接收到V2X消息。
一旦接收到V2X消息，该过程将进行到框720，其中进行检查，以确定所有保证等级是否满足托管V2X接收器的实体的设计者确定的最低要求。例如，最低要求可以包括SOTIF保证等级“可接受释放”，ASIL等级超过某一值，网络安全等级超过某个值。
如果是，则该过程从框720进行到框730，其中接收V2X应用可以对V2X消息内容采取行动，而无需采取任何相应缓解措施。例如，使用紧急制动警告应用时，接收的消息内容值得信任，并且可以用力踩下制动器，即使这可能会导致其他事故，比不用力踩下制动器的情况下发生的事故要轻。
相反，如果框720的检查确定未满足最低要求，则该过程从框720进行到框740，其中可能需要采取缓解措施。例如，在紧急制动警告应用的情况下，消息内容的可信度较低。在进一步证实前方车辆实际紧急制动的证据之前，可以更柔和地制动。
框740的缓解措施可以取决于未满足最低要求的程度。例如，在一个实施例中，考虑到功能安全、SOTIF和网络安全中的每个，要采取的缓解措施的程度是任何这些指定的“不平等测试”中的最大的缓解措施，如图5和图6中定义的。
在另一实施例中，如果多个测试失败，则指定的缓解措施甚至大于任何个体测试失败的缓解措施。例如，在一个实施例中，当个体FuSa测试或个体SOTIF测试失败时，可以更柔和地应用制动器。然而，如果FuSa和SOTIF“不平等测试”均失败，则车辆根本不会应用制动器，但可能会对制动器预充电，预充电表示当人类驾驶员或自动机器最终应用制动踏板时，制动可能会更快并且具有增强的力度。
从框730或框740，该过程进行到框750并且结束。
聚合保证等级/信任等级
在另一实施例中，对于网络安全、FuSa和/或SOTIF中的每个，可以提供聚合保证等级(AAL)，而不是在消息(诸如消息360)中提供保证等级细分。
聚合保证等级的一个示例如下表10所示。
Figure BDA0003915706630000241
表10：可能的聚合保证等级的示例
然而，表10的示例仅用于说明，对于本领域技术人员来说，考虑到本公开，其他类似的聚合表设计将是很清楚的。因此，表10的示例仅用于说明如何将可能较大的组合集减少为较小数目的聚合保证等级。
在另外的实施例中，表10中的AAL数字可以与指示信任等级的单词相关联，诸如“低”、“中”、“高”等。
利用这样的聚合保证等级，IEEE 1609.2中当前定义的证书格式和对应ETSI规范可以保持不变，但会重新定义assuranceLevel的含义。特别是，assuranceLevel可以与聚合保证等级相关联，而不是与当前使用的网络安全(TAL)等级相关联。
具体地，在现有方案中，与给定V2X模块规范ID相关联的保证等级存储在从注册机构可访问的数据库中。在本文中描述的实施例中，该保证等级的含义将发生变化。
与这样的变化相关联的消息可以如下。参考图2。当授权机构216向注册机构214发送AuthorizationValidationRequest消息232时，注册机构215用AuthorizeationValidationResponse消息234进行响应，AuthorizeationValidationResponse消息234包括confirmedSubjectAttributes，其中的一个是现在具有新含义的assuranceLevel。授权机构216向IT S-S发送实体210提供的授权票据中提供有该assuranceLevel。
在接收实体，需要根据新的给定“信任等级”或“聚合保证等级”决定应当采取什么措施。如本文中使用的，术语“信任等级”和“聚合保证等级”可以互换使用，也可以使用类似术语。
基于给定信任等级的这样的决策如图8所示，图8示出了紧急制动警告应用的情况。然而，紧急制动警告应用的使用仅作为示例提供，其他应用也可以类似地使用聚合保证等级或信任等级。
图8的过程从框810开始，并且进行到框812，其中接收实体确定V2X消息是否已经被接收到。如果没有，则该过程将继续循环到块812，直到接收到V2X消息。
一旦接收到V2X消息，该过程将进行到框820，其中进行检查，以确定接收的消息的认证信任等级是否大于或等于3。如果是，则该过程可以从框820进行到框822，其中接收V2X应用可以对V2X消息内容采取行动，而无需采取任何相应缓解措施。在紧急制动警告应用的示例中，消息内容是可信的，并且可以用力踩下制动器，即使这可能会导致其他事故，比不用力踩下制动器的情况下发生的事故要轻。
相反，如果认证信任等级不大于或等于3，则该过程将进行到框830，其中将进行检查以确定认证信任等级是否等于2。如果是，则该过程进行到框832，其中可以采取一些缓解措施。例如，在进一步证实(诸如，前方车辆实际紧急踩下制动器的可视化证据)之前，可以轻轻踩下制动器。
如果框830的检查确定认证信任等级不等于2，则过程将进行到框840，其中认证信任等级必须等于1。然后，该过程进行到框842，其中可以采取更严厉的缓解措施。例如，车辆不会施加任何制动，但可能会对制动器预充电。对制动器预充电可以包括启动液压系统，并且在人类驾驶员或自主机器人确实踩下制动器时，增加踩下制动器的力和速度。
从框822、832或842，该过程进行到框850并且结束。
关于聚合保证等级或信任等级的编码，以上关于图3或图4讨论的所有方法都可以应用于聚合保证等级和信任等级的编码。
这包括在一个实施例中重新定义证书中保证等级的含义。
在另一实施例中，编码可以将聚合的保证等级或信任等级作为项目包括在appPermissionsAndAssurance信息元素中。
在另一实施例中，对聚合保证等级的编码可以包括SSP信息元素中的这样的项目，例如如图4所述。具体地，如果使用聚合保证等级或信任等级方法，则也可以在与SSP相关联的八位字节内对该信息进行编码。对于每个可能的PSID/SSP组合，可以选择针对(多个)保证等级使用相同编码。
处理隐私问题
在某些情况下，隐私可以是与上述实施例相关的问题。具体地，将FuSa等级或SOTIF等级添加到证书可能会降低传输V2X消息的车辆的隐私。对于不同的应用，如果有不同的值，这个问题可能会更加明显。该信息与消息中的其他静态或半静态信息相结合可以提供特定车型特有的“指纹”，从而使车辆跟踪更容易。
在第一实施例中，克服隐私问题的一个选项是向ITS-S颁发两倍的授权票据/匿名证书。第一票据集具有授权等级，而另一集不具有授权等级。在这种情况下，当要传输的消息保证具有这样的安全保证等级时，使用具有安全保证等级的集。例如，当V2X消息用于支持道路安全应用时，或者如果消息内容不正确，则可能会影响安全。
如果需要发送不被视为安全关键的消息，则可以使用不泄露关于传输车辆的这个信息的证书。在这种方法中，车辆需要两套临时证书，这将增加车辆所需证书的数目。
在第一实施例中，当传输分散环境通知消息(DENM)紧急制动警告消息时，可以提供安全保证信息。这样的消息可能会导致接收消息的车辆启动。
相反，安全保证信息可以由四条定期的CAM/BSM消息免除，这四条消息提供状态更新，并且可能被认为不太安全关键。
在另一实施例中，关于表10描述的“聚合保证”等级方法可能具有隐私优势，因为车辆的消息指纹中的数据元素较少。换言之，如果消息中包括的唯一保证信息是总体信任是从高中或低中选择的高信任，并且指纹包括的细节很少，则很难区分或跟踪车辆，因为“高”的信任设置对很多车辆来说是常见的。
可以定义适用于每个应用或用例的其他保证等级，并且这些等级也会降低基于指纹跟踪车辆的能力，因为指纹的这一保证方面对于使用指纹的所有车辆都是相同的。然而，这种方法的缺点是需要行业协议，这种情况可能发生，也可能不会发生，并且可能导致延迟，这取决于传输器设计者可以对将要提供的保证做出某种独立的决定，而接收方设计者也可以根据传输器声称的保证等级对如何处理消息做出某种独立的决定。
可选地，如果传输车辆具有比应用最低要求更高的保证等级，无论是由传输方设计者确定还是由某些行业协会的行业共识确定，则证书可以包括较低的保证等级指示，其中这样做的动机是更好地保护隐私。具体地，很多或大多数车辆将采用这样的较低的保证等级，从而降低传输车辆的唯一“指纹”风险。
使用较低的保证等级也可能会改变注册机构和/或授权机构的行为，从而实现授权机构针对V2X传输器认证保证性能而降低的给定保证等级颁发授权票据的结果。注册机构或授权机构都可以降低保证等级。
V2X消息正文中提供的SOTIF保证
在另一实施例中，作为在证书中提供安全保证信息(诸如FuSa和/或SOTIF)的备选方案，该信息可以在V2X消息正文中提供。
具体地，V2X消息正文可以用指示SOTIF等级的信息元素进行增强。例如，这可以是二进制值，其采用“产品预期功能安全由独立审计CA排除发布”或“独立审计CA未排除发布产品的预期功能安全”中的一个。
在其他示例中，V2X消息正文可以用指示聚合安全保证等级的信息元素进行增强。在这种情况下，例如，聚合可以跨功能安全和SOTIF来进行。
在另一示例中，V2X消息正文可以利用指示聚合的网络安全和安全保障的信息元素进行增强。在这种情况下，聚合可以在功能安全、SOTIF和网络安全之间进行。关于表11，这样的聚合的一个示例如下所示。
信任等级 保证认证要求
1(低) FuSa ASIL等级为A或SOTIF为“无释放接受证明”
2(中) ASIL等级在B与C之间，并且SOTIF为“接受释放”
3(高) ASIL等级为D，并且SOTIF为“接受释放”
表11：可能的“信任等级”定义的示例
然而，表11的示例仅用于说明目的，在其他实施例中，这样的信任等级的不同定义是可能的。
硬件
V2X实体、V2X客户端、注册机构、证书机构、授权机构或网络服务器或节点可以是任何类型的计算设备。例如，关于图9，提供了一种可以执行上述实施例的简化计算设备。
在图9中，计算设备910包括处理器920和通信子系统930，其中处理器920和通信子系统920合作以执行本文所述实施例的方法。
处理器920被配置为执行可编程逻辑，该可编程逻辑可以与数据一起存储在计算设备910上，并且在图9的示例中示出为存储器940。存储器940可以是任何有形的非暂态的计算机可读存储介质，诸如DRAM、Flash、光盘(例如，CD、DVD等)、磁带(例如，磁带)、闪存驱动器、硬盘驱动器、或本领域已知的其他存储器。在一个实施例中，处理器920也可以完全用硬件实现，并且不需要任何存储程序来执行逻辑功能。
备选地或除了存储器940，计算设备910还可以从外部存储介质访问数据或可编程逻辑，例如通过通信子系统930。
通信子系统930允许计算设备910与其他设备或网络元素通信。
在一个实施例中，计算设备910的各个元素之间的通信可以通过内部总线960。然而，其他形式的通信也是可能的。
本文中描述的实施例是具有与本申请的技术的元素相对应的元素的结构、系统或方法的示例。本书面描述可以使得本领域技术人员能够制作和使用具有备选元素的实施例，备选元素同样对应于本申请技术的元素。因此，本申请的技术的预期范围包括与本文中描述的本申请的技术没有区别的其他结构、系统或方法，还包括与本文中描述的本申请技术无实质区别的其他结构、系统或方法。
虽然在附图中以特定顺序描述了操作，但这不应当理解为要求这样的操作按照所示的特定顺序或以依次顺序执行，或者要求执行所有图示操作，以获取理想的结果。在某些情况下，可以使用多任务和并行处理。此外，上述实现中不同系统组件的分离不应当理解为在所有实现中都需要这样的分离，应当理解，所描述的程序组件和系统通常可以集成在一个软件产品中或打包成多个软件产品。在某些情况下，功能可以完全在硬件中执行，并且这样的解决方案在功能上可能等同于软件解决方案。
此外，在各种实现中描述和说明为离散的或单独的技术、系统、子系统和方法可以与其他系统、模块、技术或方法组合或集成。示出或讨论为彼此耦合或直接耦合或通信的其他项目可以通过某种接口、设备或中间组件间接耦合或通信，无论是电气、机械还是其他。本领域技术人员可以确定并且可以进行改变、替换和变更的其他示例。
虽然上述详细描述已经示出、描述并且指出了本公开应用于各种实现的基本新颖特征，但应当理解，本领域技术人员可以对所示系统的形式和细节进行各种省略、替换和改变。此外，方法步骤的顺序并且不取决于它们在权利要求中的出现顺序。
当向电子设备发送消息或从电子设备发送消息时，这样的操作可能不会立即进行，也不会直接从服务器进行。它们可以从支持本文所述设备/方法/系统的服务器或其他计算系统基础设施同步或异步递送。上述步骤可以全部或部分包括与设备/基础设施的同步/异步通信。此外，通信可以是从电子设备到网络上的一个或多个端点。这些端点可以由服务器、分布式计算系统、流处理器等提供服务。内容交付网络(CDN)也可以向电子设备提供通信。例如，与典型的服务器响应不同，服务器还可以为内容交付网络(CDN)提供或指示数据，以等待稍后由电子设备下载，例如电子设备的后续活动。因此，数据可以直接从服务器或其他基础设施(诸如分布式基础设施或CDN)发送，该基础设施是系统的部分或独立于系统。
通常，存储介质可以包括以下中的任何或某种组合：半导体存储器设备，诸如动态或静态随机存取存储器(DRAM或SRAM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器和闪存；磁盘，诸如固定、软盘和可移动磁盘；另一磁性介质，包括磁带；光盘(诸如，压缩光盘(CD)或数字视频光盘(DVD))；或其他类型的存储设备。注意，上述指令可以在一个计算机可读或机器可读存储介质上提供，或者也可以在分布在可能具有多个节点的大型系统中的多个计算机可读/机器可读存储介质上提供。这样的计算机可读或机器可读存储介质被视为物品(或制品)的部分。物品或制品可以是指任何制造的单个组件或多个组件。一种或多种存储介质可以位于运行机器可读指令的机器上，也可以位于远程站点处，可以通过网络从该远程站点下载机器可读指令以执行。
在上述描述中，阐述了很多细节，以提供对本文中公开的主题的理解。然而，在实践中可以没有这些细节。其他实现可以包括对上述细节的修改和变化。所附权利要求旨在涵盖这样的修改和变化。

Claims (21)

1.一种智能交通系统(ITS)实体处的方法，所述方法包括：
从第二ITS实体接收消息，所述消息包含安全保证指示，以及
基于所述安全保证指示在所述ITS实体处执行动作。
2.根据权利要求1所述的方法，其中所述安全保证指示是功能安全保证等级指示和预期功能安全保证等级指示中的至少一项。
3.根据权利要求1所述的方法，其中所述安全保证指示是以下中的至少两项的聚合：功能安全保证等级指示；预期功能安全保证等级指示；以及网络安全保证等级指示。
4.根据权利要求1所述的方法，其中所述安全保证指示在授权票据或授权证书内被接收。
5.根据权利要求4所述的方法，其中所述安全保证指示与特定应用或服务相关联。
6.根据权利要求4所述的方法，其中所述安全保证指示以八位字节被编码以用于服务特定权限(SSP)。
7.根据权利要求1所述的方法，其中所述消息是在所述ITS实体处被接收的多个消息中的一个消息，其中仅传递安全信息的消息包括所述安全保证指示。
8.根据权利要求1所述的方法，其中执行所述动作包括：
当所述安全保证指示在最低阈值等级以上或者处于所述最低阈值等级时，在所述ITS实体处响应于所述消息；以及
当所述安全保证指示低于所述最低阈值等级时，缓解在所述ITS实体处对所述消息的所述响应。
9.根据权利要求8所述的方法，其中所述消息包括多个安全保证指示，并且其中用于缓解所述响应的程度取决于低于所述最低阈值等级的安全保证指示的数目。
10.根据权利要求1所述的方法，其中所述安全保证指示在所述消息的正文内。
11.一种智能交通系统(ITS)实体，所述ITS实体包括：
处理器；以及
通信子系统，
其中所述ITS实体被配置为：
从第二ITS实体接收消息，所述消息包含安全保证指示，以及
基于所述安全保证指示在所述ITS实体处执行动作。
12.根据权利要求11所述的ITS实体，其中所述安全保证指示是功能安全保证等级指示和预期功能安全保证等级指示中的至少一项。
13.根据权利要求11所述的ITS实体，其中所述安全保证指示是以下中的至少两项的聚合：功能安全保证等级指示；预期功能安全保证等级指示；以及网络安全保证等级指示。
14.根据权利要求11所述的ITS实体，其中所述安全保证指示在授权票据或授权证书内被接收。
15.根据权利要求14所述的ITS实体，其中所述安全保证指示与特定应用或服务相关联。
16.根据权利要求14所述的ITS实体，其中所述安全保证指示以八位字节被编码以用于服务特定权限(SSP)。
17.根据权利要求11所述的ITS实体，其中所述消息是在所述ITS实体处被接收的多个消息中的一个消息，其中仅传递安全信息的消息包括所述安全保证指示。
18.根据权利要求11所述的ITS实体，其中所述ITS实体被配置为通过以下方式执行动作：
当所述安全保证指示在最低阈值等级以上或者处于所述最低阈值等级时，在所述ITS实体处响应于所述消息；以及
当所述安全保证指示低于所述最低阈值等级时，缓解在所述ITS实体处对所述消息的所述响应。
19.根据权利要求18所述的ITS实体，其中所述消息包括多个安全保证指示，并且其中用于所述缓解所述响应的程度取决于低于所述最低阈值等级的安全保证指示的数目。
20.根据权利要求11所述的ITS实体，其中所述安全保证指示在所述消息的正文内。
21.一种用于存储指令代码的计算机可读介质，所述指令代码在由智能交通系统(ITS)实体的处理器执行时使所述ITS实体：
从第二ITS实体接收消息，所述消息包含安全保证指示，以及
基于所述安全保证指示在所述ITS实体处执行动作。
CN202180031993.7A 2020-04-29 2021-04-28 向v2x消息中添加保证信息的方法和系统 Pending CN115462056A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/861,870 US11758376B2 (en) 2020-04-29 2020-04-29 Method and system for addition of assurance information to V2X messaging
US16/861,870 2020-04-29
PCT/US2021/029703 WO2021222445A1 (en) 2020-04-29 2021-04-28 Method and system for addition of assurance information to v2x messaging

Publications (1)

Publication Number Publication Date
CN115462056A true CN115462056A (zh) 2022-12-09

Family

ID=78293586

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180031993.7A Pending CN115462056A (zh) 2020-04-29 2021-04-28 向v2x消息中添加保证信息的方法和系统

Country Status (5)

Country Link
US (2) US11758376B2 (zh)
EP (1) EP4107713A4 (zh)
CN (1) CN115462056A (zh)
CA (1) CA3171853A1 (zh)
WO (1) WO2021222445A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220301435A1 (en) * 2021-03-18 2022-09-22 Autotalks Ltd. Method and system for v2x asil decomposition
EP4087293A1 (en) * 2021-05-06 2022-11-09 Robert Bosch GmbH Methods and devices for radio communication
US20230199493A1 (en) * 2021-12-21 2023-06-22 Continental Automotive Systems, Inc. System and method for determining v2x message integrity
GB2616456A (en) * 2022-03-09 2023-09-13 Canon Kk Enhanced authorization tickets for test mode in intelligent transport systems

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8194550B2 (en) * 2009-02-09 2012-06-05 GM Global Technology Operations LLC Trust-based methodology for securing vehicle-to-vehicle communications
US9014915B2 (en) * 2011-07-25 2015-04-21 GM Global Technology Operations LLC Active safety control for vehicles
US11218948B2 (en) 2017-01-09 2022-01-04 Lg Electronics Inc. V2X communication device and data communication method therefor
US10360798B2 (en) * 2017-05-08 2019-07-23 Nokia Technologies Oy System and method for trust parameters in vehicle warning messages
US11184178B2 (en) 2018-09-28 2021-11-23 Blackberry Limited Method and system for intelligent transportation system certificate revocation list reduction
DE102018219960A1 (de) * 2018-11-21 2020-05-28 Continental Teves Ag & Co. Ohg Fahrzeug-zu-X-Kommunikationsanordnung und Verfahren zum Empfangen von Fahrzeug-zu-X-Nachrichten
GB201907461D0 (en) * 2019-05-27 2019-07-10 Canon Res Centre France Communication methods and devices in intelligent transport systems
US11811943B2 (en) * 2020-04-01 2023-11-07 Lg Electronics Inc. Verification of messages using hash chaining
US20210316755A1 (en) * 2020-04-09 2021-10-14 Baidu Usa Llc Method for real-time monitoring of safety redundancy autonomous driving system (ads) operating within predefined risk tolerable boundary

Also Published As

Publication number Publication date
US20230362607A1 (en) 2023-11-09
CA3171853A1 (en) 2021-11-04
WO2021222445A1 (en) 2021-11-04
US11758376B2 (en) 2023-09-12
US20210345074A1 (en) 2021-11-04
EP4107713A1 (en) 2022-12-28
EP4107713A4 (en) 2023-08-09

Similar Documents

Publication Publication Date Title
CN115462056A (zh) 向v2x消息中添加保证信息的方法和系统
US20200028699A1 (en) Digital certificate management
Lam et al. ANT-centric IoT security reference architecture—Security-by-design for satellite-enabled smart cities
CN110266364B (zh) 用于地面站和飞行器之间安全通信的系统和方法
US9888037B1 (en) Cipher suite negotiation
CN111684760A (zh) 用于管理数字证书的密码方法和系统
JP2021500816A (ja) 車両搭載機器アップグレード方法および関連機器
US11695574B2 (en) Method and system for establishing trust for a cybersecurity posture of a V2X entity
US20060048210A1 (en) System and method for policy enforcement in structured electronic messages
JP2020532215A (ja) 車両用のＩｏＴデバイスの安全な通信
CN106256111A (zh) 用于验证消息的方法
CN113711535A (zh) 用于远程控制自主交通工具的加密安全机制
Rezazadeh Baee et al. Authentication strategies in vehicular communications: a taxonomy and framework
US20220376932A1 (en) Method and system for handling dynamic cybersecurity posture of a v2x entity
CN111898991A (zh) 一种基于区块链的公章管理方法及系统
CN101951605A (zh) 移动Widget的数字签名方法
CN108632037B (zh) 公钥基础设施的公钥处理方法及装置
WO2007018476A1 (en) Hybrid cryptographic approach to mobile messaging
US10079680B2 (en) Selective revocation of certificates
Funderburg et al. Efficient short group signatures for conditional privacy in vehicular ad hoc networks via ID caching and timed revocation
US20230291576A1 (en) Device And Method for Issuing a Limited-Use Electronic Certificate
WO2023024487A1 (zh) 一种基于区块链的互联车辆认证系统和方法
Das et al. Design of a Trust-Based Authentication Scheme for Blockchain-Enabled IoV System
CN114374516A (zh) 证书吊销列表分发方法、设备及存储介质、服务器、车联网设备
Das et al. Authentication schemes for VANETs: a survey

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination