CN115486107A - 用于针对v2x实体的网络安全态势建立信任的方法和系统 - Google Patents

用于针对v2x实体的网络安全态势建立信任的方法和系统 Download PDF

Info

Publication number
CN115486107A
CN115486107A CN202180031980.XA CN202180031980A CN115486107A CN 115486107 A CN115486107 A CN 115486107A CN 202180031980 A CN202180031980 A CN 202180031980A CN 115486107 A CN115486107 A CN 115486107A
Authority
CN
China
Prior art keywords
message
integrity
transmitting entity
entity
certificate
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
CN202180031980.XA
Other languages
English (en)
Inventor
S·J·巴雷特
N·J·鲁塞尔
J·O·戈约
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 CN115486107A publication Critical patent/CN115486107A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • 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
    • 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]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • 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]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种在智能交通系统(ITS)发射实体处的方法，该方法包括：生成ITS消息；利用由在ITS发射实体处的完整性检测功能生成的完整性报告来扩充ITS消息以创建经扩充的ITS消息；利用授权证书或授权票据对经扩充的ITS消息签名，授权证书或授权票据包括针对完整性检测功能的、来自审计证书机构的保证指示；以及向ITS接收实体发送经签名的经扩充的ITS消息。

Description

用于针对V2X实体的网络安全态势建立信任的方法和系统
技术领域
本公开涉及车辆到一切(vehicle to everything，V2X)通信，并且具体地涉及针对V2X消息的信任。
背景技术
在智能交通系统(intelligent transport systems，ITS)中，多个设备进行通信，以便交通系统在交通和流量管理方面做出更明智的决策，以及做出更安全、更协调的决策。ITS系统组件可以作为固定基础设施的一部分提供在车辆内，诸如在桥梁上或在十字路口，以及被提供用于交通系统的其他用户，包括行人或骑自行车者。
ITS系统部署在世界各地的很多市场都受到了极大的关注，无线电频带被分配用于通信。除了用于安全关键和非关键应用的车辆到车辆通信之外，正在针对车辆到基础设施和车辆到便携场景开发进一步的增强功能以提供交通安全和效率。
然而，当这样的设备通信时，接收设备需要确信所接收的消息是可信的，以便对这样的消息中的信息采取行动。接收设备在确定可信度时面临的问题的一个方面是，发送实体是否是网络安全的。换言之，接收实体需要确信发送实体没有被泄露或黑客攻击。受损的发送实体可以被强制发送安全签名但不合规的消息或数据，这可能对ITS系统有害。
附图说明
参考附图可以更好地理解本公开，在附图中：
图1是示出V2X系统中的证书的示例公钥基础设施架构的框图；
图2是示出V2X架构中的证书检索过程的数据流图；
图3是示出概念性机载设备(On Board Equipment，OBE)和安全凭证管理系统(SCMS)不当行为检测(MBD)架构的框图；
图4是基于完整性报告创建V2X消息的流程图；
图5是在V2X实体处的安全硬件中实现的示例完整性检测功能的框图；
图6是示出在富操作环境中实现的V2X应用与在安全硬件中实现的完整性检测功能之间的交互的框图；
图7是示出将V2X实体添加到证书撤销列表上的数据流图；
图8是示出在接收V2X实体处的用于确定在对所接收的V2X消息采取行动时是否需要缓解动作的过程的流程图；
图9是示出用于请求网络安全态势的消息序列的数据流图；以及
图10是能够与本公开的实施例一起使用的示例计算设备或服务器的框图。
具体实施方式
本公开提供了一种在智能交通系统(ITS)发射实体(transmitting entity)处的方法，该方法包括：生成ITS消息；利用由在ITS发射实体处的完整性检测功能生成的完整性报告来扩充(augment)ITS消息以创建经扩充的ITS消息；利用授权证书或授权票据对经扩充的ITS消息签名，授权证书或授权票据包括针对完整性检测功能的、来自审计证书机构(audit certificate authority)的保证指示；以及向ITS接收实体(receiving entity)发送经签名的经扩充的ITS消息。
本公开还提供了一种智能交通系统(ITS)发射实体，该ITS发射实体包括：处理器；以及通信子系统，其中ITS发射实体被配置为：生成ITS消息；利用由在ITS发射实体处的完整性检测功能生成的完整性报告来扩充ITS消息以创建经扩充的ITS消息；利用授权证书或授权票据对经扩充的ITS消息签名，授权证书或授权票据包括针对完整性检测功能的、来自审计证书机构的保证指示；以及向ITS接收实体发送经签名的经扩充的ITS消息。
本公开还提供了一种用于存储指令代码的计算机可读介质，该指令代码在由智能交通系统(ITS)发射实体的处理器执行时使得ITS发射实体：生成ITS消息；利用由在ITS发射实体处的完整性检测功能生成的完整性报告来扩充ITS消息以创建经扩充的ITS消息；利用授权证书或授权票据对经扩充的ITS消息签名，授权证书或授权票据包括针对完整性检测功能的、来自审计证书机构的保证指示；以及向ITS接收实体发送经签名的经扩充的ITS消息。
在确定是否对接收的V2X消息采取行动时，接收该消息的V2X实体或ITS-S(如车辆)可能需要确定其是否可以信任该消息。这在安全关键用例中尤为重要。例如，在紧急制动警告等情况下，接收车辆可能需要确定是否应根据信息内容采取行动并且用力制动，甚至可以在没有其他佐证信息的情况下。
V2X接收器在确定可信度时面临的一个问题是V2X发射车辆是否网络安全。如果V2X发射器已经被恶意行为者破坏或黑客攻击，则这可以导致V2X消息内容受损或错误。如果V2X发射器已受损，恶意行为者可能会生成错误的紧急制动警告信息，以增加事故发生的可能性。
因此，本公开解决了接收V2X消息的ITS站(ITS-S)如何确定其是否可以信任V2X消息内容并且从而对接收的V2X消息中的信息采取行动或以其他方式利用该信息的问题。具体地，本文考虑的一个问题是，接收V2X消息的ITS-S站如何建立V2X发射器未被恶意行为者破坏的信任。例如，在某些情况下，发射器可能会因利用网络安全漏洞而受损。
本公开与V2X有关，V2X是一种提供用于从车辆到其他实体(也可能相反)之间的消息的通信的特征，该信息可能会影响车辆和/或其他实体。因此，V2X实体是支持发送V2X消息和接收V2X消息中的一者或两者的实体，并且可以包括智能交通系统(ITS)站(ITS-S)、电子控制单元(ECU)、机载单元(OBU)、用户设备(UE)、移动实体(ME)、终端实体(EE)等。V2X实体在本文中也称为ITS实体或ITS-S，并且这些术语可以互换使用。
与车辆之间的通信可以是与各种V2X端点之间的通信。V2X端点可以包括：其他车辆，其单独称为车辆到车辆(V2V)；基础设施，诸如路边单元，其单独称为车辆到基础设施(V2I)；行人或骑自行车者，其单独称为车辆到行人(V2P)；(多个)网络，其单独称为车辆到网络(V2N)；设备，诸如车辆内的电子设备，其单独称为车辆到设备(V2D)；电网，其单独称为车辆到电网(V2G)；等等。这些统称为V2X。
V2X通信可以用于多种用途。在某些情况下，V2X可以用于道路安全和提高道路运输效率两者，诸如通过减少拥堵或减少燃油消耗。
各种系统/架构可以提供V2X通信。诸如第三代合作伙伴项目(3GPP)规范中定义的蜂窝网络就是一个这样的系统/架构。例如，其他系统/架构可以包括综合数字增强网络(iDEN)、电气与电子工程师协会(IEEE)802.11p无线网络等。
通常，V2X通信由V2X实体发送和接收的V2X消息组成。为了保护V2X消息和整个V2X系统免受发送流氓消息的流氓V2X实体的攻击，所有V2X消息都受到完整性保护。这种完整性保护是通过V2X端点在发送/广播之前对V2X消息进行签名来实现的，并且包括证书(也称为授权票据)以供接收V2X端点用于验证签名。因此，V2X消息由要传送的数据、要传送的数据的签名和证书组成。
证书包含用于验证签名真实性的数据、以及其他数据。例如，用于验证签名真实性的数据可以由验证密钥、公钥或其他这样的数据组成。包括的签名可以遵循IEEE 1609.2第2.2.1条“IEEE Standard for WAVE–Security Services for Applications andManagement Messages–Consolidated Draft of IEEE 1609.2-2016with AmendmentsSpecified in1609.2a/D8 and 1609.2b/D3”(2016年12月)中定义的格式。
V2X实体可以通过执行注册(enrolment)(例如通过注册机构)并且然后是授权(例如通过授权机构)来获取证书以便在V2X系统中使用。
现在参考图1，图1提供了欧洲电信标准协会(ETSI)ITS公钥基础设施的示例概览，如ETSI技术标准(TS)102 904“智能运输系统(ITS)安全、ITS通信安全架构和安全管理”(1916年11月第1.2.1版)中定义的。
在图1的示例中，在制造时，向V2X实体(例如，ITS-S 110)提供有规范标识符(ID)(它是V2X系统中每个V2X实体唯一的ID)，并且向注册机构112提供有相同的规范ID以及与该规范ID相关的其他信息，诸如保证级别。例如，这在ETSI TS 103 097“ITS；Security；Security Header and Certificate Formats”(2017年10月第1.3.1版)和ETSI TS 102941“ITS；Security；Trust and Privacy Management”(2018年5月第1.2.1版)中有描述。
在ITS架构中，注册机构112在接收到规范ID和可能的其他数据(例如，公钥)122时对ITS-S 110进行认证，并且通过颁发注册证书124(本文中也称为注册ID或注册凭证)授予其参与ITS通信的授权。授权机构130通过提供可以用于这些服务的临时/匿名证书132(也称为授权票据或授权证书)来向ITS-S 100提供使用特定ITS服务的授权。该授权基于注册证书134，注册证书134由注册机构112使用授权验证请求136和授权验证响应138进行验证。例如，ETSI TS102 941“ITS；Security；Trust and Privacy Management”(2018年5月第1.2.1版)描述了授权验证请求消息和授权验证响应消息。特别地，AuthorizationValidationRequest消息可以包括诸如签名的外部有效载荷和共享的属性请求等数据。这样的数据可以被签名和加密。
AuthorizationValidationResponse消息可以包括授权验证响应本身，该响应可以被签名和加密。
根证书机构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可以执行其他似真性(plausibility)(非加密)检查和有效性(加密)检查。
然后，ITS-S接收或中继实体212可以使用发送实体的公钥来验证V2X消息中包括的签名。
如上所述，ITS-S接收或中继实体212可以检查身份是否不在证书撤销列表(CRL)中指向的身份列表中。接收实体通常配置有用于验证证书(如根证书)的信息。但是，证书可以随时撤销，例如由于在不当行为机构处接收到不当行为报告。
因此，接收实体可能需要能够检测或配置标识被撤销证书的数据，例如证书撤销列表(CRL)。CRL的基本形式是数字证书或数字证书指示的列表，在某些情况下包括哈希或“链接种子”，证书机构(CA)已决定在其到期日期/时间之前撤销这些证书。CRL由证书机构(也可以是不当行为机构)在CA授权下为证书产生。这些证书分发给需要处理该CA颁发的证书的V2X实体或由其提取。CRL通常被签名，以提供其内容的完整性和真实性(authenticity)。
接收证书的实体检查从证书的证书撤销机构CA(CRACA)获取的CRL中是否表明接收的证书已经被撤销(每个证书包含其CRACA的指示，例如CracaID)，并且如果是，则应当将其及其关联数据(如V2X消息中的有效载荷数据)视为不可信。
CRL上通常只有未到期的证书。换言之，一旦证书到期，它就不再需要出现在CRL上，因为接收到期证书的实体已经将这样的证书视为已撤销。
CRL可以随时分发给需要它们的实体，例如在实体希望开始接收证书之前。然而，当实体收到证书，该证书包括标识该实体没有CRL的CRL的CRACA或者包括标识已经获取的CRL的CARCA，并且该CRACA已经到期或者包括具有过去发生的值的“下一次更新”字段时，该实体可能需要提取/获取新的CRL。
虽然以上描述了接收通过证书进行验证的V2X消息，但在某些情况下，还需要传达网络安全保证级别。例如，IEEE 1609.2；ETSI、互联网工程任务组(IETF)和Car2Car联盟中描述了用于提供网络安全保证级别的各种解决方案。
具体地，IEEE 1609.2中定义的获取注册证书和申请证书(类似于“授权票据”，以前称为“匿名证书”)的过程与ETSI TS 103 097中描述的过程相似。“保证级别(assuranceLevel)”项可以被包括在与V2X消息一起发送的IEEE 1609.2证书中，其中该证书的对应私钥用于对V2X消息进行签名。
例如，IEEE 1609.2将ToBeSignedCertificate定义为包括各种字段，诸如Id、cracaID、region和assuranceLevel等字段。assuranceLevel的值定义为SubjectAssurance，并且是可选的。
在ETSI TS 102 941中，上述关于图2的过程适用。属性保证级别是IEEE 1609.2中定义的一种“主题保证”，并且在ETSI-ITS中重复使用。如图2所示，ITS-S发送的每个V2X消息包括证书或其哈希，因此保证级别也会被发送。
在名为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到TAL 4，其中TAL 4是最高信任保证级别。ITS站的最低可接受TAL为TAL 2。根据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 BDA0003915666070000101
表1：针对C2X站的信任保证级别
在上面的表1中，TAL 2是最低可接受级别。
保证级别的另一示例是关于PRESERVE。PRESERVE是一个欧洲共同体资助的项目，涉及车辆到一切通信的安全和隐私方面。“PRESERVE”(EC-DG INFSO资助的第七个框架计划)第2.5节(2016年1月)(“准备安全车辆到X通信系统”，可交付成果5.4，部署问题报告)的亮点包括：只有具有合理安全级别的车辆才能从C2X PKI处获取证书；实体(例如，认证型公司/行业联盟/OEM自行签名)应当能够验证V2X模块是否达到最低安全级别；成功的评估和认证可以作为注册机构向车辆颁发注册凭证的基础；TAL应当被包括在车辆的授权票据(匿名证书)中。
在另一示例中，ISO/SAE 21434国际标准草案(DIS)规定了下
表2中定义的网络安全保证级别(CAL)。
Figure BDA0003915666070000111
表2：ISO/SAE 21434网络安全保证级别
不当行为检测
全局不当行为检测的一个示例在“车辆到车辆通信不当行为检测”(CAMP,V2V-CRFinal Report)中有描述。特别地，CAMP车辆安全通信6(VSC6)联盟提供了概念机载设备(OBE)和安全凭证管理系统(SCMS)不当行为检测(MBD)组件结构的一个示例。现在参考图3。
在图3的实施例中，图的左侧示出了OBE 310内的信息流。图的右侧示出了SCMS312。与其他车辆的通信通过V2V接口314来促进。
在OBE 310中，空中(OTA)接收(RX)和发射(TX)功能框316处示出，并且与V2V接口314通信。车辆控制器局域网(CAN)和全球定位系统(GPS)信息从框318提供给OTA RX/TX功能框316。
此外，来自框316和318的信息可以被提供给安全应用框320和本地不当行为检测(LMBD)框330。
安全应用框320和支持过程包括目标分类(TC)、威胁仲裁(TA)和用于警告报告生成的安全应用。这些包括前向碰撞警告(FCW)框322和盲点警告/车道改变警告(BSW/LCW)框324。
局部不当行为检测(LMBD)方法框330可以生成报告，包括框332处的接近似真性报告和框334处的警告报告。LMBD方法框330从框316、框318和框320接收输入，并且可以向不当行为报告(MBR)生成框340提供输出。
MBR生成框340生成不当行为报告并且可以将其提供给MBR存储框342、本地证书撤销列表(CRL)存储框344和MBR发射框350。
MBR发射框350可以使用MBR接口354与SCMS 312通信。具体地，通信可以与登记(registration)机构360和/或可选地与MBR存储/数据库362通信。
登记机构360和/或MBR存储/数据库362向全局不当行为检测(GMBD)方法框370提供输入。GMBD方法框3700分析从OBE/车辆接收的MBR，并且处理MBR以标识不当行为，并且确定哪个(哪些)设备(如果有的话)是不当行为的根本原因。GMBD框370包括设备框372、事件框374和特征框376。
设备框372提供了一种检测方法，该方法扫描接收的MBR的数据库以对报告完全相同的违规链接值的MBR的数目进行计数。如果任何链接值总计超过撤销阈值，则该链接值使用证书撤销管理器380被提交以进行撤销。
事件框374提供基于事件的检测，该检测旨在捕获在同一物理位置和在时间窗口(例如，分钟、小时、天)内发生的不当行为和攻击，即使(多个)不当行为设备使用多个匿名证书进行不当行为。
特征框376提供基于特征的检测，该检测旨在捕获高级攻击和不当行为。这个框最好被认为是一个框架，在这个框架上可以构建很多检测算法。
事件框374和特征框376可以向链接信息管理器382提供输入，然后链接信息管理器382可以向证书撤销管理器380提供其输出。
证书撤销管理器380可以向证书链接框384提供信息，证书链接框384可以包括链接机构(LA)、匿名证书机构(PCA)和/或登记机构(RA)。
此外，证书撤销管理器380可以向CRL生成和分发框386提供信息。框386可以用于通过CRL接口390向OBE 310、特别是向本地CRL存储框344提供CRL。
因此，在图3的结构中，图的左侧示出了OBE 310内的信息流，OBE 310通常位于车辆上。这是MBD的基础，因为它为执行GMBD提供信息。通常，可以从车辆CAN和GPS接收器318以及其他来源(例如，安全应用和接收的V2X消息(例如，BSM从周围车辆接收到OTA))获取输入的LMBD方法380为生成MBR提供了基础，该MBR通过MB接口354发送到驻留在SCMS上的不当行为机构(MA)。
图3的右侧示出了SCMS内的信息流。通常，GMBD方法370通过MBR接口354从OBE(通常位于车辆上)接收的MBR中获取输入，并且执行汇总分析，这为将OBE或车辆放置在CRL上提供了基础。然后，CRL被发送到V2X系统中的一个或多个OBE，从而完成端到端MBD和撤销过程。
此外，V2X行业中存在端点异常检测的解决方案，其中可以包括向网络实体发送数据，以便网络实体确定端点中的异常。示例异常解决方案包括互联网工程任务组(IETF)网络端点评估(NEA)等提供的解决方案。
一个网络实体可以称为异常检测服务器。这样的服务器检测到端点中存在的异常可以表示该端点已经被黑客攻击或被破坏。换言之，端点的网络安全态势较低，或已经被破坏或受到不利影响。例如，由于攻击者利用端点中的漏洞，可能会发生这种情况。
端点可以根据IETF网络端点评估征求意见(RFC)5209“Network EndpointAssessment(NEA):Overview and Requirements”进行评估。具体地，IETF为网络端点评估定义了系统架构和一套协议，主要目的是使得企业IT基础设施能够评估希望加入企业网络的端点的网络安全态势，以实现网络访问控制。在这种情况下，端点可以是笔记本电脑、台式计算机等。例如，这样的端点可能会被隔离，直到其网络安全态势被确定为令人满意。IETF RFC 5209的一个示例如下：
·NEA为网络所有者(例如，提供远程访问的企业)提供了用于评估系统态势的机制。这可以发生在请求网络访问期间和/或随后连接到网络时的任何时间。然后，学习到的态势信息可以应用于各种面向法规遵从性的决策。态势信息通常用于检测缺少或具有过时安全保护机制的系统，例如：防病毒和基于主机的防火墙软件。
·……NEA的目的是评估这些端点，以确定它们是否符合安全策略，以便在它们暴露于这些威胁之前提供校正措施。例如，如果系统由于缺乏适当的防御机制(如基于主机的防火墙、防病毒软件或缺少关键安全修补程序)而被确定为不合规，则NEA协议提供了一种机制来检测这一事实并且指示要采取的适当补救措施……。
·NEA通常涉及使用在请求端点上运行的特殊客户端软件，该软件观察并且向网络基础设施报告系统配置。基础设施具有对应验证软件，能够将端点的配置信息与网络合规性策略进行比较，并且将结果提供给做出网络和应用访问决策的适当授权实体……
·……类似于NEA的架构在业界已经存在了一段时间，并且出现在产品发布中，但没有提供足够的互操作性。这样的架构的一些示例包括：Trusted Computing Group的Trusted NetworkConnect[TNC]、Microsoft的Network Access Protection[NAP]和Cisco的Cisco Network Administration Control[CNAC]。这些技术评估端点设备的软件和/或硬件配置，以监测或强制遵守组织的策略。
本技术领域也可以存在其他解决方案，并且在本文中称为“端点证明(endpointattestation)”。
异常可以通过多种方式检测。检测IT设备中异常行为的方法示例(可以指示存在安全隐患)可以包括但不限于以下内容。
在第一方面，可以通过检测安全策略违规来发现异常。这可以包括找到哪些进程可以附接到哪个(哪些)进程间通信信道。它还可以包括处理能力限制，诸如映射物理存储器范围、切换唯一标识符(UID)、创建、解锁等能力。
在另一方面，可以通过检测存储器违规来发现异常。这可以包括检测被覆盖的堆栈cookie；试图从不可执行存储器运行代码；试图写入只读数据；堆硬化边界保护；访问无效存储器页；等等。
在另一方面，可以通过检测网络异常来发现异常。这可以包括检测给定网络资源上的异常吞吐量率或检测违规网络策略等等。网络策略可以包括允许或禁止端点与其他端点通信的策略。违规网络策略还可以与在防火墙处检测到分组有关，例如，通过防火墙被拒绝并且被丢弃的分组。
在另一方面，可以通过检测进程异常来发现异常。这可以包括检测正在运行的意外进程；预期未运行进程；和/或不以预期特权级别运行的进程；等等。
在另一方面，可以基于任务管理器异常发现异常。特别地，这样的异常可以包括未消耗预期处理能力级别的进程。
在另一方面，可以从碰撞检测中发现异常，即意外或过早结束或终止的过程。特别地，崩溃的进程可以指示存在折衷。
在另一方面，可以基于完整性检查发现异常。例如，这样的完整性检查可以包括交叉检查可执行文件和其他关键文件的签名和哈希，包括以下中的一项或多项：硬件；软件；引导只读存储器(ROM)；操作系统(OS)；和应用等等。
在另一方面，可以通过检测硬件安全模块(HSM)篡改来发现异常。
用于发现异常的其他方面也是可能的。
V2X发射器中的不当行为检测
根据本公开的实施例，接收V2X消息的接收实体可能需要确定其是否可以信任V2X消息中的内容并且从而对接收的V2X消息采取行动或以其他方式利用该信息。具体地，接收V2X消息的ITS-S可能需要建立关于V2X发射器未被恶意行为人破坏的信任，这可能会通过利用网络安全漏洞而发生。
本文中提供的示例是根据欧洲合作凭证管理系统(CCMS)解决方案描述的。然而，类似的概念同样适用于任何其他类型的SCMS，包括但不限于基于美国防撞指标合作伙伴(CAMP)的安全凭证管理系统(SCMS)系统、中国SCMS系统等。
如本文中使用的，术语“审计CA”可以是可以对原始设备制造商(OEM)或一级供应商的V2X设计、制造和后期生产过程执行网络安全评估的任何公司。这样的评估可以涉及审计证书机构(CA)检查所提供的文件和证据，并且采访设计、制造和/或操作V2X发射器的公司的员工。在本公开的某些情况下，审计CA不需要操作自己的公钥基础设施(PKI)。
关于图4，提供了本公开的一个实施例的高级概述。在图4的环境中，V2X发射器具有检测不当行为的能力。在某些情况下，这可以基于监测V2X系统的发射器的安全硬件组件。
图4的过程从框410开始，并且进入框420，在框420中可以进行完整性检测。特别地，在V2X发射器中检测到不当行为或异常行为，而不是在V2X发射器外部的第三方实体中。这种完整性检测可以利用完整性检测引擎来进行。这种完整性检测引擎的一个示例是例如James Dreher的题为“BlackBerry Integrity Detection is here！”(2016年5月19日)的文章中所述的BlackBerry完整性检测引擎。
本文中使用的完整性检测是一个广义术语，其用于指代对发射器的网络安全态势的检查，包括但不限于检查是否检测到任何异常、以及软件、存储器和其他系统组件的完整性是否良好或可接受。
因此，作为完整性检测程序或过程的一部分，V2X发射器内的功能(如在安全硬件中运行的应用)产生完整性报告，该报告可以包括与V2X发射器的异常行为相关联的信息。与V2X发射器异常行为相关联的信息可以是与上述各种异常检测过程相关的信息或数据。
如本文中使用的，“安全硬件”由通常以安全方式与操作环境区域(V2X应用在其中运行)隔离的硬件组成，该环境在本文中称为“富操作环境”。通常，该区域在处理能力方面受到更多限制，并且用于支持安全相关特征。例如，“安全硬件”可以是以下中的任何一项：可信执行环境(有时称为TEE)；安全元件；高级精简指令集计算机(RISC)机器(ARM)TrustZone类特征；安全飞地或其他类似的解决方案。
在框420处执行的完整性检测可以基于发生的触发。例如，触发器可以包括以下中的一项或多项：设备或OS引导或启动；每当应用引导或加载或启动时；定期地，例如基于定时器；在固件或软件更新完成时，在确定更新是如何接收的，例如这种更新是通过空中接收的还是直接执行的；在检测到新硬件时；在检测到新的或已更新应用时；和/或每当要发送V2X消息时；等等。
一旦发生完整性检测并且生成完整性报告，过程从框420进行到框430，在框430中，V2X发射器可以基于完整性报告组成V2X消息。特别地，框420的结果影响将要发送的V2X消息中包括的内容以及是否要发送V2X消息。
例如，在构建或构造V2X消息时，V2X发射器可以包括完整性报告，该完整性报告表明V2X发射器当前被认为是网络安全的。换言之，V2X发射器可以被认为没有检测到的异常，并且其软件可以在特定日期是最新的。完整性报告和V2X消息本身已签名，例如，可以在V2X发射器内的安全硬件内执行。
因此，基于完整性报告的V2X消息存在各种选项。在第一选项中，当未检测到危害或异常时，完整性报告可以被包括在发送给V2X接收器的V2X消息中。如果检测到危害或异常，则V2X发射器可以选择不发送V2X消息，也可以选择指示不向另一实体发送V2X信息的决定，包括以下中的一项或多项：向应用发送消息(例如，通过API)，向OBU或ECU发送消息(如，通过CAN总线)，向车辆外部的服务器(例如，异常检测服务器或基于云的服务器)发送消息，在显示单元(例如，仪表板或信息娱乐系统)上引起视觉警报，引起可听警报，等等。发送给应用、OBU或ECU以及车外服务器的消息可以包括完整性报告，并且可以包括指示已经检测到危害或异常的指示。
在第二选项中，完整性报告可以被包括在发送给V2X接收器的V2X消息中，而不管是否检测到危害或异常。在某些情况下，无论检测到的异常程度如何，也可以发送这样的消息。
在另一种情况下，完整性报告可以被包括在某些V2X消息中，而不包括在其他V2X消息中。例如，在某些情况下，完整性报告可以仅被包括在安全关键V2X消息中，例如紧急制动警告消息，但不包括在常见或定期的合作意识消息(CAM)或基本安全消息(BSM)传输中。
完整性报告的内容可以采取多种形式。例如，在第一种情况下，完整性报告可以提供“未检测到任何危害”或“检测到危害”的指示。
在另一种情况下，完整性报告的形式可以提供“未检测到任何危害”、“检测到异常但不清楚是否存在危害”或“检测到危害”的指示。
在另一种情况下，完整性报告的形式可以提供“未检测到异常”或“异常”的指示。
在另一种情况下，完整性报告的形式可以提供“未检测到异常”、“异常”或“高度异常”的指示。
在另一种情况下，完整性报告的形式可以提供“所有监测特征：在预期操作范围内”、“一个或多个监测特征：超出预期操作范围”或“一个或多个监测特征：远远超出预期操作范围”的指示。
在另一种情况下，可以提供与上述内容类似的其他变体。此外，可能会出现更细粒度的故障，并且显示V2X发射器中发现的不同类型的异常。
发现的很多潜在异常可以是布尔值(真或假)，因此要么存在异常，要么不存在。一些异常也可以是非二进制的。例如，在一种情况下，预期网络数据吞吐量的操作范围小于值“X”。因此，“异常”可以对应于测量值“X”与“Y”之间的吞吐量，并且“高度异常”可以是测量值大于值“Y”的吞吐量。其他示例也是可能的。
此外，完整性报告还可以发送到车辆中提供的功能，以帮助在车辆发生事件后进行诊断或分析，例如车辆碰撞后分析。这种功能可以称为“黑盒”或“事件数据记录器”。这种完整性报告可以可选地提供比V2X消息中包括的信息更详细的信息。例如，完整性报告可以提供关于检测到的异常类型的更多详细信息，并且可以指示检测到异常的(多个)ECU、以及一种情况下的软件和硬件材料清单和版本编号。这样的包括更详细信息的完整性报告可以发送到车辆外部的服务器，例如异常检测服务器、基于云的服务器等。
因此，基于在框430处组成的V2X消息，过程可以进行到框440，在框440中，如果完整性报告的内容允许，则发送V2X消息。
从框440，过程可以返回到框430以组成另一V2X消息。然而，如果接收到执行完整性检测的触发，则该过程可以进行到框420以执行进一步的完整性检测。
当在框440发送消息时，审计CA可以提供关于完整性检测解决方案或功能在特定级别上安全或网络安全的保证。这样做是为了确保由完整性检测功能提供的报告既准确又真实地由V2X发射器内的功能产生。保证指示在由应用CA和最终CCMS/SCMS的根CA签名的授权票据/证书中提供。如本文中使用的，应用CA颁发的证书可以在特定有效期内短期使用，与特定应用和匿名身份相关。该实体以前称为匿名证书机构。
ETSI(CCMS)授权机构执行类似功能。
可以采取各种措施，以将完整性检测功能本身未受到损害或很难受到损害的可能性降到最低。
在一个方面，这样的措施可以包括在安全硬件(例如，高级精简指令集计算机(RISC)机器(ARM)处理器或类似处理器的TrustZone)中运行完整性检测应用。在这样的系统中，富操作环境或系统运行在不受信任的区域中，而较小的安全专用代码运行在更受信任的区域中。这可以减少完整性检测应用和其他安全应用的攻击面。这种对富操作环境和可信操作环境的同时支持可以使用运行在单个内核上的虚拟化技术来实现。
在另一方面，这样的措施可以包括使用嵌入式硬件中的信任根密钥的安全引导链过程。可以使用安全引导链过程，其中检查引导ROM签名，然后检查操作系统软件签名，然后再检查一个或多个应用签名(例如，完整性检测应用签名)。
在另一方面，这样的措施可以包括使用私钥对完整性报告进行签名，例如，私钥可以安装在安全硬件中。V2X接收器可以使用相应公钥来验证完整性报告的真实性。下面关于图5提供了签名可以发生的示例实现。
在另一方面，这样的措施可以包括完整性检测功能本身是可修补的，并且在补丁可用时进行修补。在这种情况下，一个可能的假定是，审计CA可以保证原始设计良好，并且有修补机制，但审计CA不会在每次更新完整性检测软件时重新评估系统。该假定也可以是，最初的保证也为V2X接收器提供了低于正在运行的完整性检测软件确实是最新版本的信任。
另一可能的假定是，未及时更新完整性检测软件的车辆的证书可能会被撤销，例如使用证书撤销列表。
现在参考图5，图5示出了ITS-S中完整性检测功能的示例实现。在图5的示例中，嵌入式中央处理单元(CPU)引导ROM 510可以基于密钥512安全地引导引导ROM 520。引导ROM520可以基于密钥522安全地引导网络安全操作系统(OS)530，例如被视为特定网络安全保证级别(CAL)的微内核，例如CAL4。
网络安全OS 530可以基于密钥532安全地引导富操作环境540。富操作环境550可以包括V2X应用542。
网络安全OS 530可以基于密钥532进一步安全地引导安全硬件550。安全硬件550可以包括完整性检测功能552。
在安全硬件550上提供有完整性检测功能552的一个好处是，与在富操作环境540中提供完整性测试功能相比，攻击者更难破坏或破解完整性检测功能。
ITS-S内完整性检测功能与V2X客户端/应用之间的示例交互如图6所示。特别地，图6的环境包括富操作环境610、安全硬件区域612和操作系统614。
富操作环境610包括可以生成V2X消息的V2X应用620，如框622所示。
在图6的实施例中，安全硬件区域612包括完整性检测功能630。然而，图6的示例仅是一种解决方案，在另一种情况下，完整性检测功能可以位于安全硬件区域之外。
在框622处生成V2X消息后，将其发送给完整性检测功能630。完整性检测模块630随后可以在框640处检查系统完整性，例如，使用上文关于图4的框420所述的方法。系统完整性的检查还可以可选地涉及查询其他电子控制单元(ECU)以确定这些ECU是否经历了任何异常。这样的ECU可以是例如提供用于在提供V2X消息的内容时使用的信息的传感器或致动器ECU。
在框642，V2X消息可以用完整性报告来扩充。
在框644，可以使用私钥对具有完整性报告的V2X消息进行签名，该私钥可以安装在安全硬件612内，例如区域632中。该密钥可以由V2X接收器使用相应公钥进行验证，以验证完整性报告的真实性。
例如，在一种情况下，完整性检测功能630将完整性报告添加到V2X消息中，并且使用与授权票据/证书相关联的私钥签名经扩充的V2X消息，并且该签名和授权票据/证书被添加到经扩充的V2X消息中。如上所述，授权票据/证书可以包括来自审计CA的关于完整性检测功能的信息。
然后，经签名的、经扩充的V2X消息在框646处提供回富操作环境610，以便在框670处在V2X通信堆栈上发射消息。
为了防止V2X应用重放旧消息并且附接旧完整性检测报告，可以使用各种技术。在一种技术中，时变信息(例如时间戳、随机数或计数)被包括在从富操作环境610传递到安全硬件区域612的V2X消息中。在某些情况下，V2X消息可以包括时间戳，因为由于与网络安全无关的原因，时间戳通常是V2X接收器应用的关键信息，如美国汽车工程师学会(SAE)J2735所述。在这种情况下，如果时间戳的粒度以10毫秒为增量，则在同一秒内发送的任何重放都将成功，因为重放无法区分。然而，序列号或消息计数与时间戳一起可以克服这一问题。在这种情况下，计数可能需要足够高的滚动，以在时间戳的粒度之外发生。
类似地，消息计数被包括在很多V2X消息中，如SAE J2735中定义的。该消息计数在需要知道消息是否丢失的应用中可以很重要。
在另一种情况下，可以由完整性检测功能630在安全硬件区域612内插入随机数、消息计数或时间戳，其被包括在完整性检测报告中。
在上述所有情况下，V2X接收器可能需要跟踪这些值(例如，随机数、消息计数或时间戳)以检测重放。
经扩充的V2X消息还包括具有指示完整性检测功能是安全的指示的授权票据/证书。这种指示可以在现有字段中或在新字段中。此外，完整性检测功能630的安全性可以比V2X应用620更安全。
该指示/保证最初可以来自审计CA，该CA检查了制造商流程和文档是否符合安全开发生命周期标准和/或是否符合产品标准。在一个示例中，该保证信息将被提供给注册机构。然后，注册机构将向授权机构提供该信息，作为ITS-S获取具有授权票据的颁发的过程的一部分。例如，这可以是图2中的消息230的一部分。
以这种方式，只有完整性检测功能被保证为高度安全的ITS站才会接收到授权票据/证书，其中字段指示完整性报告可以被V2X接收器集合所信任。
完整性检测损害
尽管在设计和过程中可能会建立很多机制，以确保网络安全报告的可靠性，但黑客/攻击者可能会破坏产生完整性报告的V2X发射器内的功能。
当检测到这样的危害时，可以通知SCMS CA，并且可以撤销受影响的V2X发射器的一个或多个证书，可以包括与受损的发射器共享相同硬件/软件的证书的哪些，例如，通过添加或发送请求添加的消息，一个或多个证书将证书的一个或多个指示发送到证书撤销列表(CRL)。
SCMS CA向证书撤销列表(CRL)发送消息以请求一个或多个证书或证书的一个或多个指示，如图7所示。在图7的实施例中，V2X实体710可以包括一个或多个证书来对完整性报告进行签名。SCMS CA 716可以向V2X实体710提供这样的一个或多个证书。
在图7的实施例中，V2X实体可以可选地向SCMS CA 716报告异常，如消息720所示。
在单独的选项中，可以发生框730所示的事件。例如，该事件可以是一次交通事故，对该事故进行分析并且发现违反完整性报告。在框730处的其他事件是可能的。
基于消息720的接收或事件730的发生，SCMS CA 716可以向证书机构718发送CRL添加请求消息750，其中消息750包括一个或多个证书或证书的一个或多个指示。在一种情况下，消息750还可以包括与车辆相关的信息，例如车辆的品牌、车辆的型号等。其他选项也是可能的。
在接收到消息750时，证书机构718可以将接收的一个或多个证书或证书的一个或多个指示添加到CRL，如框770所示。然后，这样的CRL可以被分发给ITS站。
此后，当具有被撤销的一个或多个证书的受影响的V2X发射器联系SCMS CA 716以获取一个或多个新的证书时，可以不颁发新证书，也可以颁发完整性检测保证级别较低的一个或多个证书。
单个组织(OEM)可以跟踪特定类型的汽车/V2X发射器设计是否已破坏完整性检测(或网络安全态势)报告，并且将受影响车辆的一个或多个证书或一个或多个证书的指示放在CRL上。这在拥有CRL的同一实体或组织也可以访问完整性检测(或网络安全态势)信息的情况下可以是可能的，例如，车辆OEM操作SCMS。
此外，通过将受影响车辆的一个或多个证书或一个或多个证书的指示放在CRL上，这可以在这样的车辆发现CRL上存在或指示了一个或多个它们的证书时提示车辆请求一个或多个新的证书。
此外，在某些情况下，针对一组车辆可能会使用不同的中间认证机构，例如用于每个品牌/型号/年份或“V2X模块HW生成”的CA。通过对一组车辆使用不同的中间CA，撤销中间CA证书可以是通过一个或多个证书撤销个体车辆的更简单、更可扩展的备选方案。
车辆OEM操作的SCMS可以通过映射或绑定车辆内的V2X发射器类型(使用的软件/硬件)和该车辆的匿名证书来实现。这可以通过使用查找列表或表、执行数据库查找等等来实现。匿名证书可以稍后在不当行为报告(或类似报告)中提供给SCMS不当行为机构，以导致将与该车辆相关联的一个或多个证书被放在CRL上。
车辆相关公钥安全发射到授权CA的过程以及确保接收车辆拥有授权CA公钥的可信副本的过程可以遵循当前定义的机制。
此外，并非所有V2X发射器都会实现上述图4至图7中提供的流程和机制，而是一些发射器会继续按照当前定义运行，不包括完整性报告，也不修改证书格式。为了支持这种范例，V2X接收器需要确定V2X发射器的类型，例如，它们可以通过检查接收的V2X消息中的证书来确定是否包括完整性检测保证级别(或者证书是否属于可以包括这种完整性检测保证级别的类型)。如果V2X发射器被确定为不使用或不支持或不实现该特征，则V2X接收器可以根据当前方法处理接收的V2X消息和证书。
因此，根据图4至图7的实施例，通过接收的V2X消息中的完整性报告和审计CA信息，V2X接收器可以确保：完整性检测引擎提供关于V2X发射器的完整性是否完整的确认(例如，没有检测到异常，最近执行了新软件补丁的检查并且采取了行动、以及其他检查)；并且完整性检测功能的报告可以被信任，因为用于完整性检测报告产生的相关设计和过程已经被独立审计CA保证在非常高的级别上是可信的。
此外，虽然图4至图7实施例中描述的过程可以完全取代当前使用的传统不当行为授权方案，但也可以同时使用这两种方案。
接收V2X消息
V2X接收器ITS-S可以配备/预编程有可以基于接收的完整性报告的内容(例如，基于包括的网络安全态势级别)而采取的一组各种动作。确切的行为选项取决于用例，并且下面给出了一个示例。然而，随着信任级别的降低，V2X接收器可能会更加谨慎。
接收V2X实体的过程的一个示例如图8所示。图8的过程从框810开始，并且进入框812，在框812中，ITS-S接收实体确定是否接收到V2X消息。如果没有，则过程继续循环到框812，直到接收到V2X消息。
一旦接收到V2X消息，过程进行到框820，在框820中，进行检查以确定完整性报告是否指示“未检测到异常”或其他类似情况。这种检查还可以包括检查完整性检测功能是否由审计CA认证，如上所述。
如果是，则过程从框820进行到框830，在框830中，接收V2X应用可以对V2X消息内容采取行动，而不必采取由此产生的任何缓解动作，至少从网络安全的角度来看。
例如，如果V2X应用是紧急制动警告应用，则在框830中，消息内容可信，并且可以用力制动，即使这可能会导致其他事故，与不用力制动的情况下发生的事故相比不太严重。
相反，如果在框820处进行的检查确定V2X发射器的完整性报告缺失或表明已检测到异常，则过程将进行到框840，并且ITS-S接收实体可以采取缓解动作。
例如，在紧急制动警告应用的情况下，在框840中，对消息内容的信任度将低于在框830中的信任度。在这种情况下，制动仍然可以更柔和地应用，以等待进一步的确证证据，例如前方车辆已紧急制动的视觉证据。
在某些情况下，如果异常不是布尔值，而是具有不同的级别，则异常级别越高，接收实体对消息的反应就越谨慎，因此对消息的响应程度可能会降低。例如，如果这两个级别之间存在较大差异，则车辆可以不会施加任何制动，而是会对制动器进行预充电。例如，这可以涉及启动液压系统，并且在人类驾驶员或自主机器人确实应用制动器时，增加施加制动器的力和速度。其他选项也是可能的。
从框830或框840，过程进行到框850并且结束。
更新消息
策略和治理文件可以更新以定义认证机构要执行的新要求，如欧洲委员会的“Certificate policy for deployment and operation of European CooperativeIntelligent Transport Systems(C-ITS)”(2017年6月第1版)。增加的要求可以包括：SCMSCA可以确定有独立第三方(即，审计CA)的证据表明，OEM对与给定规范身份相关的完整性检测功能的规定保证级别实际上已达到。
在某些情况下，完整性检测软件的网络安全“质量”(级别)可以根据通用标准保护简档的要求确定，并且可以具有与其相关的评估保证级别(EAL)。
同样，V2X行业协会或标准体可以定义自己的排名，就像使用Car2Car财团和ETSI定义的信任保证级别(TAL)一样。另一替代方案可以是使用网络安全保证级别(CAL)，例如ISO 21434中定义的。
可能需要更新各种消息和实体，包括注册机构、授权验证响应(AuthorizationValidationResponse)消息和授权验证请求(AuthoriizationValidationRequest)消息和/或授权票据/证书等。
授权验证响应(AuthorizationValidationResponse)和授权验证请求(AuthoriizationValidationRequest)消息可以更新以除了当前的assuranceLevel参数外，还包括新的参数，在本文中标记为intDetectAssuranceLevel。该新参数指示与完整性检测功能相关联的保证级别。
具体地，两条消息中使用的CertificateSubjectAttributes结构可以更新，如下表3中粗体所示。该结构是与requestedSubjectAttributes(AuthorizationValidationRequest消息)和concemedSubjectAttribute(AuthoritionValidationResponse)消息两者相关联的类型。
Figure BDA0003915666070000271
表3：CertificateSubjectAttributes
此外，对于授权票据/证书，授权机构发送给ITS-S的并且包括授权票据的授权响应消息可以更新授权票据，以使其与当前assuranceLevel参数一起包括新参数intDetectAssuranceLevel。
例如，表4示出了IEEE 1609.2中定义的当前授权票据。
Figure BDA0003915666070000281
表4：授权票据在一个实施例中，根据下表5，可以修改授权票据，如粗体所示
Figure BDA0003915666070000282
Figure BDA0003915666070000291
表5：经修改的授权票据
例如，SubjectIntDetectAssurance可以选择7个级别中的一个。这些可以与通用标准EAL 1至7相对应。备选地，这些级别可以采用等效的TAL或CAL值。在其他情况下，可以使用更多或更少的级别。
此外，在某些情况下，SubjectIntDetectAssurance本质上可以定义为二进制：例如“完整性检测报告是可信的”，“完整性检查报告可能不可信”。
在另一种情况下，如果信息元素存在，则表示完整性检测报告可以被信任，并且可以依赖根据本文实施例的基于V2X发射器的不当行为方法，而如果不存在，则V2X接收器可以依赖于传统的不当行为机构(其可以涉及CRL)方法。
然后，现有assuranceLevel信息可以与在富操作环境中运行的V2X应用相关联。
对等(peer to peer)网络安全态势报告
在上述图4至图7的实施例的变体中，与围绕实际检测和可选报告不当行为而设计的解决方案不同，发射车辆可以备选地或另外地确定和报告网络安全态势的其他方面，V2X接收器可以使用这些方面来确定接收消息的信任程度。这样的不当行为可以包括检测异常、检测实际恶意活动以及其他这样的行为。
可以报告的网络安全态势的其他方面可以包括各种项目。
一项可以包括该V2X发射器的网络安全漏洞评分系统(CVSS)汇总(和可能量化)得分。这里，CVSS是一个标准化的网络安全漏洞评分系统，并且汇总指标可以通过考虑针对该V2X发射器的所有或一个已知漏洞的子集并且将这些漏洞的相应CVSS得分进行汇总来确定。
另一项可以包括V2X发射器中的软件(例如可以位于富操作环境中的V2X应用、可以位于安全硬件中的完整性检测功能等)，是否被认为是最新的。
另一项可以包括上次访问/轮询软件更新服务器以确定新软件/补丁是否可用的时间。例如，这样的软件或补丁可以用于V2X应用软件、完整性检测功能等。
另一项可以包括V2X发射器是否存在弱点或漏洞。该漏洞可以与特定硬件版本、软件版本以及其他考虑因素有关。这样的项目还可以包括(多个)已知弱点的严重性，例如通过CVSS而测量的。
另一项可以包括已知弱点的补丁是否可用。
根据图4至图7的实施例，报告可以包括其他方面，以确保报告的安全，例如时间戳，以便其无法重放。
ITS-S可能需要轮询某个实体，如OEM服务器或联邦漏洞公开数据库/服务器，以便获取上述网络安全态势信息。在这种情况下，轮询可以发生在加载到安全硬件中的软件中。现在参考图9。
在图9的实施例中，V2X完整性检测功能910可以与网络安全姿势信息服务器912通信。在这种情况下，V2X完好性检测功能920可以向服务器912发送网络安全姿势请求920。
作为响应，服务器912可以将网络安全姿态响应922发送回V2X完整性检测功能910。
因此，根据图9，可以执行对等网络安全态势报告。
硬件
V2X实体、V2X客户端、ITS-S、注册机构、授权机构、SCMS、证书机构或网络服务器或节点可以是任何类型的计算设备。例如，关于图10，提供了一种可以执行上述实施例的简化计算设备。
在图10中，计算设备1010包括处理器1020和通信子系统1030，其中处理器1020和通信子系统1030合作以执行本文所述实施例的方法。
处理器1020被配置为执行可编程逻辑，该可编程逻辑可以与数据一起存储在计算设备1010上，并且在图10的示例中示出为存储器1040。存储器1040可以是任何有形的非暂态的计算机可读存储介质，诸如DRAM、Flash、光盘(例如，CD、DVD等)、磁带(例如，磁带)、闪存驱动器、硬盘驱动器、或本领域已知的其他存储器。在一个实施例中，处理器1020也可以完全用硬件实现，并且不需要任何存储程序来执行逻辑功能。
备选地或除了存储器1040，计算设备1010还可以从外部存储介质访问数据或可编程逻辑，例如通过通信子系统1030。
通信子系统1030允许计算设备1010与其他设备或网元通信。
在一个实施例中，计算设备1010的各个元件之间的通信可以通过内部总线1060。然而，其他形式的通信也是可能的。
本文中描述的实施例是具有与本申请的技术的元素相对应的元素的结构、系统或方法的示例。本书面描述可以使得本领域技术人员能够制作和使用具有替代元素的实施例，替代元素同样对应于本申请技术的元素。因此，本申请的技术的预期范围包括与本文中描述的本申请的技术没有区别的其他结构、系统或方法，还包括与本文中描述的本申请技术无实质区别的其他结构、系统或方法。
虽然在附图中以特定顺序描述了操作，但这不应当理解为要求这样的操作按照所示的特定顺序或以依次顺序执行，或者要求执行所有图示操作，以获取理想的结果。在某些情况下，可以使用多任务和并行处理。此外，上述实现中不同系统组件的分离不应当理解为在所有实现中都需要这样的分离，应当理解，所描述的程序组件和系统通常可以集成在一个软件产品中或打包成多个软件产品。在某些情况下，功能可以完全在硬件中执行，并且这样的解决方案在功能上可能等同于软件解决方案。
此外，在各种实现中描述和说明为离散的或单独的技术、系统、子系统和方法可以与其他系统、模块、技术或方法组合或集成。示出或讨论为彼此耦合或直接耦合或通信的其他项目可以通过某种接口、设备或中间组件间接耦合或通信，无论是电气、机械还是其他。本领域技术人员可以确定并且可以进行改变、替换和变更的其他示例。
虽然上述详细描述已经示出、描述并且指出了本公开应用于各种实现的基本新颖特征，但应当理解，本领域技术人员可以对所示系统的形式和细节进行各种省略、替换和改变。此外，方法步骤的顺序并不取决于它们在权利要求中的出现顺序。
当向电子设备发送消息或从电子设备发送消息时，这样的操作可能不会立即进行，也不会直接从服务器进行。它们可以从支持本文所述设备/方法/系统的服务器或其他计算系统基础设施同步或异步递送。上述步骤可以全部或部分包括与设备/基础设施的同步/异步通信。此外，通信可以是从电子设备到网络上的一个或多个端点。这些端点可以由服务器、分布式计算系统、流处理器等提供服务。内容交付网络(CDN)也可以向电子设备提供通信。例如，与典型的服务器响应不同，服务器还可以为内容交付网络(CDN)提供或指示数据，以等待稍后由电子设备下载，例如电子设备的后续活动。因此，数据可以直接从服务器或其他基础设施(诸如分布式基础设施或CDN)发送，该基础设施是系统的一部分或独立于系统。
通常，存储介质可以包括以下中的任何或某种组合：半导体存储器设备，诸如动态或静态随机存取存储器(DRAM或SRAM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器和闪存；磁盘，诸如固定、软盘和可移动磁盘；另一种磁性介质，包括磁带；光盘(诸如压缩光盘(CD)或数字视频光盘(DVD))；或其他类型的存储设备。注意，上述指令可以在一个计算机可读或机器可读存储介质上提供，或者也可以在分布在可能具有多个节点的大型系统中的多个计算机可读/机器可读存储介质上提供。这样的计算机可读或机器可读存储介质被视为物品(或制品)的一部分。物品或制品可以是指任何制造的单个组件或多个组件。一种或多种存储介质可以位于运行机器可读指令的机器上，也可以位于远程站点处，可以通过网络从该远程站点下载机器可读指令以执行。
在上述描述中，阐述了很多细节，以提供对本文中公开的主题的理解。然而，在实践中可以没有这些细节。其他实现可以包括对上述细节的修改和变化。所附权利要求旨在涵盖这样的修改和变化。
此外，示例性条款可以提供一种在智能交通系统(ITS)接收实体处的方法，该方法包括：接收ITS消息；确定所接收的ITS消息使用来自认可的证书机构的证书被签名；确定针对完整性检测功能的来自审计证书机构的保证指示存在于ITS消息内；从ITS消息中提取完整性报告；并且基于完整性报告内的结果对ITS信息采取行动。

Claims (21)

1.一种在智能交通系统(ITS)发射实体处的方法，所述方法包括：
生成ITS消息；
利用由在所述ITS发射实体处的完整性检测功能生成的完整性报告来扩充所述ITS消息以创建经扩充的ITS消息；
利用授权证书或授权票据对所述经扩充的ITS消息签名，所述授权证书或所述授权票据包括针对所述完整性检测功能的、来自审计证书机构的保证指示；以及
向ITS接收实体发送经签名的所述经扩充的ITS消息。
2.根据权利要求1所述的方法，其中所述生成所述ITS消息是在所述ITS发射实体的富操作环境中被执行的。
3.根据权利要求1所述的方法，其中所述完整性检测功能在所述ITS发射实体的安全元件内。
4.根据权利要求1所述的方法，还包括：由在所述ITS发射实体处的所述完整性检测功能执行ITS发射实体的完整性检查，从而生成所述完整性报告。
5.根据权利要求4所述的方法，其中所述执行基于触发条件，所述触发条件是以下一项或多项：设备上或操作系统启动；每当应用被启动或被加载时；定期地；在固件或软件更新完成时；在检测到新的硬件时；在检测到新的或已更新的应用时；以及每当新的ITS消息将被发送时。
6.根据权利要求4所述的方法，其中所述执行用于检测所述ITS发射器中的异常，所述检测包括以下一项或多项：检测安全策略违规；检测存储器违规；检测联网异常；检测进程异常；任务管理器异常；碰撞检测；硬件、软件、引导只读存储器(ROM)、操作系统和应用中的一项或多项的完整性检查；以及检测硬件安全模块篡改。
7.根据权利要求1所述的方法，还包括：指示异常的所述完整性报告是通过以下至少一项而被检测的：向应用发送消息；向机载单元(OBU)或电子控制单元(ECU)发送消息；向车辆外部的服务器发送消息；在显示单元上引起视觉警报；引起可听警报。
8.根据权利要求1所述的方法，其中所述完整性报告是指示是否检测到异常的布尔值。
9.根据权利要求1所述的方法，其中所述完整性报告包括检测到的异常的级别。
10.根据权利要求1所述的方法，其中来自所述审计证书机构的所述保证指示在所述授权证书或所述授权票据的字段内。
11.一种智能交通系统(ITS)发射实体，所述ITS发射实体包括：
处理器；以及
通信子系统，
其中所述ITS发射实体被配置为：
生成ITS消息；
利用由在所述ITS发射实体处的完整性检测功能生成的完整性报告来扩充所述ITS消息以创建经扩充的ITS消息；
利用授权证书或授权票据对所述经扩充的ITS消息签名，所述授权证书或所述授权票据包括针对所述完整性检测功能的、来自审计证书机构的保证指示；以及
向ITS接收实体发送经签名的所述经扩充的ITS消息。
12.根据权利要求11所述的ITS发射实体，其中所述ITS发射实体被配置为：在所述ITS发射实体的富操作环境中生成所述ITS消息。
13.根据权利要求11所述的ITS发射实体，其中所述完整性检测功能在所述ITS发射实体的安全元件内。
14.根据权利要求11所述的ITS发射实体，其中所述ITS发射实体还被配置为：在所述完整性检测功能处执行ITS发射实体的完整性检查，从而生成所述完整性报告。
15.根据权利要求14所述的ITS发射实体，其中所述ITS发射实体被配置为：基于触发条件执行，所述触发条件是以下一项或多项：设备上或操作系统启动；每当应用被启动或被加载时；定期地；在固件或软件更新完成时；在检测到新的硬件时；在检测到新的或已更新的应用时；以及每当新的ITS消息将被发送时。
16.根据权利要求14所述的ITS发射实体，其中所述ITS发射实体被配置为：执行以检测所述ITS发射器中的异常，所述检测包括以下一项或多项：检测安全策略违规；检测存储器违规；检测联网异常；检测进程异常；任务管理器异常；碰撞检测；硬件、软件、引导只读存储器(ROM)、操作系统和应用中的一项或多项的完整性检查；以及检测硬件安全模块篡改。
17.根据权利要求11所述的ITS发射实体，其中指示异常的所述完整性报告是使用以下至少一项而被检测的：向应用发送消息；向机载单元(OBU)或电子控制单元(ECU)发送消息；向车辆外部的服务器发送消息；在显示单元上引起视觉警报；引起可听警报。
18.根据权利要求11所述的ITS发射实体，其中所述完整性报告是指示是否检测到异常的布尔值。
19.根据权利要求11所述的ITS发射实体，其中所述完整性报告包括检测到的异常的级别。
20.根据权利要求11所述的ITS发射实体，其中来自所述审计证书机构的所述保证指示在所述授权证书或所述授权票据的字段内。
21.一种用于存储指令代码的计算机可读介质，所述指令代码在由智能交通系统(ITS)发射实体的处理器执行时使得所述ITS发射实体：
生成ITS消息；
利用由在所述ITS发射实体处的完整性检测功能生成的完整性报告来扩充所述ITS消息以创建经扩充的ITS消息；
利用授权证书或授权票据对所述经扩充的ITS消息签名，所述授权证书或所述授权票据包括针对所述完整性检测功能的、来自审计证书机构的保证指示；以及
向ITS接收实体发送经签名的所述经扩充的ITS消息。
CN202180031980.XA 2020-04-29 2021-04-29 用于针对v2x实体的网络安全态势建立信任的方法和系统 Pending CN115486107A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/861,991 2020-04-29
US16/861,991 US11695574B2 (en) 2020-04-29 2020-04-29 Method and system for establishing trust for a cybersecurity posture of a V2X entity
PCT/CA2021/050593 WO2021217263A1 (en) 2020-04-29 2021-04-29 Method and system for establishing trust for a cybersecurity posture of a v2x entity

Publications (1)

Publication Number Publication Date
CN115486107A true CN115486107A (zh) 2022-12-16

Family

ID=78293454

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180031980.XA Pending CN115486107A (zh) 2020-04-29 2021-04-29 用于针对v2x实体的网络安全态势建立信任的方法和系统

Country Status (5)

Country Link
US (2) US11695574B2 (zh)
EP (1) EP4144116A4 (zh)
CN (1) CN115486107A (zh)
CA (1) CA3171847A1 (zh)
WO (1) WO2021217263A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11407423B2 (en) * 2019-12-26 2022-08-09 Intel Corporation Ego actions in response to misbehaving vehicle identification
US20230104332A1 (en) * 2021-10-06 2023-04-06 Robert Bosch Gmbh Hsm-memory-efficient means of providing hsm-based pki operations for vehicle controllers
FR3136618A1 (fr) * 2022-06-13 2023-12-15 Stmicroelectronics (Rousset) Sas Procédé de gestion de communications de système de transport intelligent et unité de commande électronique correspondante
JP2024005949A (ja) * 2022-06-30 2024-01-17 キヤノン株式会社 システム、情報処理装置、情報処理方法
GB2621158A (en) * 2022-08-04 2024-02-07 Continental Automotive Tech Gmbh System and apparatus suitable for facilitating trustworthiness assessment, and a processing method in association thereto
CN115550880B (zh) * 2022-12-06 2023-03-10 中汽智联技术有限公司 V2x设备的证书的异常处理方法、设备和存储介质

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8806196B2 (en) * 2011-11-04 2014-08-12 Motorola Solutions, Inc. Method and apparatus for authenticating a digital certificate status and authorization credentials
IN2013MU02326A (zh) * 2013-07-10 2015-06-19 Tata Consultancy Services Ltd
CN107004091B (zh) * 2014-09-26 2021-07-13 英特尔公司 安全地交换车辆传感器信息
US9762601B2 (en) * 2015-06-17 2017-09-12 Uber Technologies, Inc. Trip anomaly detection system
US10163350B1 (en) * 2015-08-28 2018-12-25 State Farm Mutual Automobile Insurance Company Vehicular driver warnings
JP6423402B2 (ja) * 2015-12-16 2018-11-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
US10341321B2 (en) 2016-10-17 2019-07-02 Mocana Corporation System and method for policy based adaptive application capability management and device attestation
EP3606124B1 (en) * 2017-03-29 2021-12-29 LG Electronics Inc. V2x communication device and data communication method thereof
EP3382930A1 (en) * 2017-03-31 2018-10-03 Nxp B.V. Intelligent transportation system station, host processor, and method therefor
US10360798B2 (en) * 2017-05-08 2019-07-23 Nokia Technologies Oy System and method for trust parameters in vehicle warning messages
FR3067830B1 (fr) * 2017-06-16 2023-10-06 Valeo Comfort & Driving Assistance Procede de transmission d'un rapport a un vehicule
JP7190686B2 (ja) * 2017-09-06 2022-12-16 パナソニックＩｐマネジメント株式会社 路側装置、通信システム、異常検知方法および異常通知方法
WO2019132081A1 (ko) * 2017-12-29 2019-07-04 엘지전자(주) V2x 통신 장치 및 v2x 통신 장치의 its 메시지 송수신 방법
JP7045288B2 (ja) * 2018-01-22 2022-03-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ データ解析装置、データ解析方法及びプログラム
US11290470B2 (en) * 2018-03-16 2022-03-29 Onboard Security, Inc. Misbehavior protection for connected vehicle communication
US11082846B2 (en) * 2018-03-20 2021-08-03 Qualcomm Incorporated Method and system for onboard equipment misbehavior detection report routing
US11303458B2 (en) * 2018-04-09 2022-04-12 Blackberry Limited Method and system for reduced V2X receiver processing load using network based application layer message processing
US11652827B2 (en) * 2018-06-08 2023-05-16 Nvidia Corporation Virtualized intrusion detection and prevention in autonomous vehicles
US11199413B2 (en) * 2018-07-19 2021-12-14 Qualcomm Incorporated Navigation techniques for autonomous and semi-autonomous vehicles
CN111200799B (zh) * 2018-11-20 2021-06-15 华为技术有限公司 一种车联网的异常行为检测方法、装置和系统
US11423162B2 (en) * 2020-03-27 2022-08-23 Intel Corporation Systems and methods for message assurance in vehicle systems

Also Published As

Publication number Publication date
CA3171847A1 (en) 2021-11-04
WO2021217263A1 (en) 2021-11-04
EP4144116A1 (en) 2023-03-08
US20230291578A1 (en) 2023-09-14
US11695574B2 (en) 2023-07-04
EP4144116A4 (en) 2023-10-18
US20210344514A1 (en) 2021-11-04

Similar Documents

Publication Publication Date Title
US10644891B2 (en) Secure communication of IoT devices for vehicles
US11695574B2 (en) Method and system for establishing trust for a cybersecurity posture of a V2X entity
US20210226802A1 (en) Digital Certificate Application Method
Othmane et al. A survey of security and privacy in connected vehicles
Guette et al. Using tpms to secure vehicular ad-hoc networks (vanets)
JP2018121328A (ja) 電子デバイスのためのイベント証明書
JP2020532215A (ja) 車両用のＩｏＴデバイスの安全な通信
US11979509B2 (en) Method and system for handling dynamic cybersecurity posture of a V2X entity
US11758376B2 (en) Method and system for addition of assurance information to V2X messaging
Förster et al. Rewire–revocation without resolution: A privacy-friendly revocation mechanism for vehicular ad-hoc networks
Weimerskirch et al. Data security in vehicular communication networks
Oyler et al. Security in automotive telematics: a survey of threats and risk mitigation strategies to counter the existing and emerging attack vectors
Amirtahmasebi et al. Vehicular networks–security, vulnerabilities and countermeasures
Adams et al. Development of DSRC device and communication system performance measures recommendations for DSRC OBE performance and security requirements.
Saed et al. Security concepts and issues in intra-inter vehicle communication network
Khodaei Secure vehicular communication systems: Design and implementation of a vehicular PKI (VPKI)
Correia et al. Using Range-Revocable Pseudonyms to Provide Backward Unlinkability in the Edge
Dehez-Clementi et al. BEAT-Traffic: a Blockchain-Enabled infrastructure for Anonymous-yet-Traceable Traffic reporting
Bißmeyer et al. PREparing SEcuRe VEhicle-to-X Communication Systems
Kurachi et al. Asymmetric key-based secure ECU replacement without PKI
Wolf Vehicular security mechanisms
Carter et al. Analysis of vehicle-based security operations
Boström et al. Wireless Threats Against V2X Communication
Shipman et al. A Zero Trust Architecture for Automotive Networks
Kim et al. Analysis of OBE-related SCMS security requirements and evaluation procedures in V2X environment

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