Method and system for establishing trust for network security posture for v2x entities

Abstract

A method at an intelligent transportation system (ITS) transmitting entity, the method comprising: generating an ITS message; augmenting the ITS message with an integrity report generated by an integrity detection function at the ITS transmitting entity to create an augmented ITS message; signing the augmented ITS message with an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including an assurance indication from an audit certificate authority for the integrity detection function; and transmitting the signed augmented ITS message to an ITS receiving entity.

Description

Technical Field

[0001] This disclosure relates to vehicle-to-everything (V2X) communication, and specifically to trust in V2X messages. Background Technology

[0002] In intelligent transport systems (ITS), multiple devices communicate to enable the transport system to make more informed, safer, and more coordinated decisions regarding traffic and flow management. ITS system components can be provided as part of fixed infrastructure within vehicles, such as on bridges or at intersections, and also for other users of the transport system, including pedestrians or cyclists.

[0003] ITS systems have received significant attention in many markets around the world, with radio bands allocated for communication. In addition to vehicle-to-vehicle communication for both safety-critical and non-critical applications, further enhancements are being developed for vehicle-to-infrastructure and vehicle-to-portable scenarios to improve traffic safety and efficiency.

[0004] However, when such devices communicate, the receiving device needs to be confident that the received message is trustworthy in order to take action on the information within it. One aspect of the problem the receiving device faces in determining trustworthiness is whether the sending entity is securely networked. In other words, the receiving entity needs to be confident that the sending entity has not been compromised or hacked. A compromised sending entity could be forced to send securely signed but non-compliant messages or data, which could be detrimental to the ITS system. Attached Figure Description

[0005] This disclosure can be better understood with reference to the accompanying drawings, in which:

[0006] Figure 1 This is a block diagram illustrating an example public key infrastructure architecture for certificates in a V2X system;

[0007] Figure 2 This is a data flow diagram illustrating the certificate retrieval process in a V2X architecture;

[0008] Figure 3 This is a block diagram illustrating a conceptual architecture for On-Board Equipment (OBE) and Misbehavior Detection (MBD) in a Security Credential Management System (SCMS).

[0009] Figure 4 This is a flowchart for creating V2X messages based on integrity reports;

[0010] Figure 5This is a block diagram of an example integrity detection function implemented in the security hardware at the V2X entity.

[0011] Figure 6 This is a block diagram illustrating the interaction between V2X applications implemented in a rich operating environment and integrity detection functions implemented in secure hardware;

[0012] Figure 7 This is a data flow diagram showing the addition of a V2X entity to the certificate revocation list;

[0013] Figure 8 This is a flowchart illustrating the process at the receiving V2X entity for determining whether a mitigation action is needed when taking action on a received V2X message;

[0014] Figure 9 This is a data flow diagram illustrating the message sequence used to request network security posture; and

[0015] Figure 10 This is a block diagram of an example computing device or server that can be used with embodiments of the present disclosure. Detailed Implementation

[0016] This disclosure provides a method at an Intelligent Transportation System (ITS) transmitting entity, the method comprising: generating an ITS message; augmenting the ITS message to create an augmented ITS message using an integrity report generated by an integrity detection function at the ITS transmitting entity; signing the augmented ITS message using an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including an assurance instruction from an audit certificate authority for the integrity detection function; and sending the signed augmented ITS message to an ITS receiving entity.

[0017] This disclosure also provides an Intelligent Transportation System (ITS) transmitting entity, comprising: a processor; and a communication subsystem, wherein the ITS transmitting entity is configured to: generate an ITS message; augment the ITS message to create an augmented ITS message using an integrity report generated by an integrity detection function at the ITS transmitting entity; sign the augmented ITS message using an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including an assurance instruction from an audit certificate authority regarding the integrity detection function; and send the signed augmented ITS message to an ITS receiving entity.

[0018] This disclosure also provides a computer-readable medium for storing instruction code that, when executed by a processor of an Intelligent Transportation System (ITS) transmitting entity, causes the ITS transmitting entity to: generate an ITS message; augment the ITS message to create an augmented ITS message using an integrity report generated by an integrity detection function at the ITS transmitting entity; sign the augmented ITS message using an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including assurance instructions from an audit certificate authority regarding the integrity detection function; and send the signed augmented ITS message to an ITS receiving entity.

[0019] When determining whether to take action on a received V2X message, the V2X entity or ITS-S (such as a vehicle) receiving the message may need to determine whether it can trust the message. This is especially important in safety-critical use cases. For example, in situations such as an emergency braking warning, the receiving vehicle may need to determine whether it should take action based on the message content and apply the brakes forcefully, even in the absence of other corroborating information.

[0020] One challenge in determining the trustworthiness of a V2X receiver is whether the V2X transmitting vehicle is cybersecurity. If the V2X transmitter has been compromised or hacked by malicious actors, this can lead to corrupted or erroneous V2X message content. If the V2X transmitter is compromised, malicious actors might generate false emergency braking warning messages, increasing the likelihood of an accident.

[0021] Therefore, this disclosure addresses the problem of how an ITS station (ITS-S) receiving a V2X message can determine whether it can trust the content of the V2X message and thus take action on or otherwise utilize the information in the received V2X message. Specifically, one problem considered herein is how an ITS-S station receiving a V2X message establishes trust that the V2X transmitter has not been compromised by malicious actors. For example, in some cases, the transmitter may be compromised by exploiting network security vulnerabilities.

[0022] This disclosure relates to V2X, a feature that provides communication for messages between a vehicle and other entities (or vice versa), which may affect the vehicle and / or other entities. Therefore, a V2X entity is an entity that supports sending and receiving V2X messages, and may include Intelligent Transportation System (ITS) stations (ITS-S), Electronic Control Units (ECUs), Onboard Units (OBUs), User Equipment (UEs), Mobile Entities (MEs), Terminal Entities (EEs), etc. V2X entities are also referred to herein as ITS entities or ITS-S, and these terms are used interchangeably.

[0023] Communication between vehicles can be communication with various V2X endpoints. V2X endpoints can include: other vehicles, referred to separately as vehicle-to-vehicle (V2V); infrastructure, such as roadside units, referred to separately as vehicle-to-infrastructure (V2I); pedestrians or cyclists, referred to separately as vehicle-to-pedestrian (V2P); (multiple) networks, referred to separately as vehicle-to-network (V2N); devices, such as electronic devices within a vehicle, referred to separately as vehicle-to-device (V2D); power grids, referred to separately as vehicle-to-grid (V2G); and so on. These are collectively referred to as V2X.

[0024] V2X communication can be used for a variety of purposes. In some cases, V2X can be used for both road safety and improving road transport efficiency, such as by reducing congestion or reducing fuel consumption.

[0025] Various systems / architectures can provide V2X communication. Cellular networks, as defined in the 3GPP specifications, are one such system / architecture. Other examples include Integrated Digital Enhanced Network (iDEN) and the IEEE 802.11p wireless network.

[0026] Typically, V2X communication consists of V2X messages sent and received by V2X entities. To protect V2X messages and the entire V2X system from attacks by rogue V2X entities sending malicious messages, all V2X messages are protected with integrity. This integrity protection is achieved by the V2X endpoints signing the V2X messages before sending / broadcasting them, and including a certificate (also known as an authorization ticket) for the receiving V2X endpoints to verify the signature. Therefore, a V2X message consists of the data to be transmitted, a signature of the transmitted data, and a certificate.

[0027] The certificate contains data used to verify the authenticity of the signature, as well as other data. For example, the data used to verify the authenticity of the signature may consist of a verification key, a public key, or other such data. The included signature may conform to the format defined in IEEE 1609.2 Section 2.2.1, “IEEE Standard for WAVE – Security Services for Applications and Management Messages – Consolidated Draft of IEEE 1609.2-2016 with Amendments Specified in 1609.2a / D8 and 1609.2b / D3” (December 2016).

[0028] V2X entities can obtain certificates for use in a V2X system by performing enrolment (e.g., through a registration authority) and then authorization (e.g., through an authorization authority).

[0029] Now for reference Figure 1 , Figure 1 Provides an example overview of the European Telecommunications Standards Institute (ETSI) ITS public key infrastructure, as defined in ETSI Technical Standard (TS) 102 904 "Security of Intelligent Transport Systems (ITS), Security Architecture and Security Management of ITS Communications" (November 1916, version 1.2.1).

[0030] exist Figure 1 In the example, during manufacturing, a specification identifier (ID) is provided to the V2X entity (e.g., ITS-S 110) (which is a unique ID for each V2X entity in the V2X system), and the same specification ID, along with other information associated with that specification ID, such as the assurance level, is provided to the registry 112. This is described, for example, in ETSI TS 103 097 “ITS; Security; Security Header and Certificate Formats” (October 2017, version 1.3.1) and ETSI TS 102941 “ITS; Security; Trust and Privacy Management” (May 2018, version 1.2.1).

[0031] In the ITS architecture, the Registrar 112 authenticates ITS-S 110 upon receiving a canonical ID and possibly other data (e.g., a public key) 122, and grants it authorization to participate in ITS communications by issuing a registration certificate 124 (also referred to herein as a registration ID or registration credential). The Authorizing Authority 130 authorizes ITS-S 100 to use specific ITS services by providing a temporary / anonymous certificate 132 (also referred to as an authorization ticket or authorization certificate) that can be used for these services. This authorization is based on the registration certificate 134, which is verified by the Registrar 112 using an Authorization Validation Request 136 and an Authorization Validation Response 138. For example, ETSI TS102 941 “ITS; Security; Trust and Privacy Management” (May 2018, version 1.2.1) describes Authorization Validation Request and Authorization Validation Response messages. Specifically, the Authorization Validation Request message may include data such as a signed external payload and a shared attribute request. Such data can be signed and encrypted.

[0032] The AuthorizationValidationResponse message can include the authorization validation response itself, which can be signed and encrypted.

[0033] Root certificate authority 140 can provide certificate 142 to registration authority 112 and certificate 144 to authorizing authority 130.

[0034] Then, the ITS-S 110 can communicate with other V2X endpoints (such as the ITS-S 150) using message 152 with authorization certificate guarantee.

[0035] Example of certificate messaging Figure 2 Describe it. In Figure 2 In this embodiment, ITS-S sending entity 210 wishes to communicate with ITS-S receiving or relay entity 212. However, it must first receive registration credentials from registration authority 214 and authorization tickets from authorization authority 216.

[0036] In this regard, ITS-S sending entity 210 sends an EnrollmentRequest message 220 to the registration authority 214, including its canonical ID and public key.

[0037] Registration Authority 214 responds to ITS-S Sending Entity 210 with EnrollmentResponse message 222, including the result and registration credentials.

[0038] ITS-S sends entity 210 and then requests a certificate / authorization ticket by sending an Authorization Request message 230 to the Authorizing Authority 216. Message 230 includes service parameters.

[0039] Authorizing authority 216 sends an AuthorizationValidationRequest message 232, including service parameters, to registrar 214. Registrar 215 responds to authorizing authority 214 with an AuthorizationValidationResponse message 234 containing the result. Message 234 may also include the applied assurance level. Authorizing authority 216 may include the assurance level (if received) in its generated authorization ticket (also known as an authorization certificate or anonymous certificate). As used herein, the authorization ticket may include a European authorization ticket or a US authorization certificate, formerly known as an anonymous certificate.

[0040] These authorization tickets are provided by the authorizing authority 216 to the ITS-S sending entity 210 in the Authorization Response message 240.

[0041] Then, ITS-S sending entity 210 can send the V2X message (shown as a SecuredMessage 250) to another ITS-S in the intelligent transportation system, such as ITS-S receiving or relay entity 212. When it is desired to send a V2X message, ITS-S sending entity 210 typically creates a V2X message, which includes a certificate (authorization ticket) and a payload (e.g., the vehicle's current location and speed); calculates a fixed-length hash of the variable-length V2X message using a well-known hash algorithm; signs the hash using the private key of the ITS-S sending entity; and appends the signature to the payload and sends the resulting V2X message.

[0042] Therefore, a V2X message contains message content, a message signature hash, and a certificate. According to ETSI TS 102 940, the message content may be protected for authenticity, integrity, confidentiality, and privacy. Therefore, the payload can be encrypted, but encryption is not required.

[0043] Among other things, an authorization ticket / certificate may include the anonymous identity of the sending entity; a signature block, which is the identity of the sending entity and a hash of the sending entity's public key, which is signed by a certificate authority using the certificate authority's private key; the identity of the certificate authority that signed the certificate; and the guarantee level of the sending V2X entity.

[0044] Upon receiving message 250, ITS-S receiving or relaying entity 212 typically applies the certificate authority's known public key to the certificate's signature block to verify the sender's identity and the sender's public key.

[0045] Then, ITS-S receiving or relay entity 212 can check whether the identity is not on the list of identities (pointed to) in the Certificate Revocation List (CRL). If the sending entity's identity is on the CRL, the message can be discarded. ITS-S receiving or relay entity 212 can perform other plausibility (non-encrypted) checks and validity (encrypted) checks.

[0046] Then, the ITS-S receiving or relay entity 212 can use the public key of the sending entity to verify the signature included in the V2X message.

[0047] As described above, ITS-S receiving or relay entity 212 can check whether an identity is not in the list of identities pointed to in the Certificate Revocation List (CRL). The receiving entity is typically configured with information for verifying certificates (such as root certificates). However, a certificate can be revoked at any time, for example, due to receiving a misconduct report from a misconduct authority.

[0048] Therefore, receiving entities may need to be able to detect or configure data identifying revoked certificates, such as a Certificate Revocation List (CRL). The basic form of a CRL is a digital certificate or a list of certificates indicated by digital certificates, sometimes including hashes or "link seeds," which a Certificate Authority (CA) has decided to revoke before their expiration date / time. CRLs are generated by the Certificate Authority (or a misconduct authority) under the authorization of the CA for the certificate. These certificates are distributed to or retrieved by V2X entities that need to process certificates issued by that CA. CRLs are typically signed to provide the integrity and authenticity of their content.

[0049] The entity receiving the certificate checks whether the CRL obtained from the Certificate Revocation Authority (CRACA) of the certificate indicates that the received certificate has been revoked (each certificate contains an indication of its CRACA, such as CracaID), and if so, it and its associated data (such as payload data in V2X messages) should be considered untrusted.

[0050] The CRL typically only contains certificates that have not yet expired. In other words, once a certificate expires, it no longer needs to appear on the CRL because the entity that received the expired certificate has already considered it revoked.

[0051] CRLs can be distributed to entities that need them at any time, such as before an entity wants to begin receiving certificates. However, when an entity receives a certificate that includes a CRACA indicating that the entity does not have a CRL, or a CARCA indicating that a CRL has already been acquired and that the CRACA has expired, or includes a "next update" field with values ​​that have occurred in the past, the entity may need to fetch / obtain a new CRL.

[0052] While the above describes receiving V2X messages that are authenticated via certificates, in some cases it is also necessary to convey network security assurance levels. For example, various solutions for providing network security assurance levels are described in IEEE 1609.2; ETSI; the Internet Engineering Task Force (IETF); and the Car2Car Consortium.

[0053] Specifically, the process for obtaining a registration certificate and requesting a certificate (similar to an "authorization ticket," formerly known as an "anonymous certificate") as defined in IEEE 1609.2 is similar to the process described in ETSI TS 103 097. The "assurance level" item can be included in the IEEE 1609.2 certificate sent with the V2X message, where the corresponding private key is used to sign the V2X message.

[0054] For example, IEEE 1609.2 defines ToBeSignedCertificate as including various fields such as Id, cracaID, region, and assuranceLevel. The value of assuranceLevel is defined as SubjectAssurance and is optional.

[0055] In ETSI TS 102 941, the above regarding Figure 2 The process applies. The attribute guarantee level is a "subject guarantee" defined in IEEE 1609.2 and is reused in ETSI-ITS. For example... Figure 2 As shown, each V2X message sent by ITS-S includes the certificate or its hash, so the guarantee level is also sent.

[0056] In a file named draft-tls-certieee1609-02.txt, titled “Transport Layer Security (TLS) Authentication Using ITS ETSI and IEEE Certificates,” the IETF considered the Trust Assurance Level (mandatory) in March 2018. Specifically, the draft stipulated: Trust Assurance Level: C-ITS certificates for both the CA and the end entity must contain TAL: (1) For the security of V2X communication systems, ensuring the safety of participants within the vehicle is crucial: message receivers must be able to rely on the fact that the sender correctly generated the message (i.e., the vehicle sensor information is accurate and complete). Therefore, a security breach on the sender will affect all receivers of the message; and (2) Only vehicles with a reasonable “security level” can obtain certificates from the PKI. The Vehicle-to-Vehicle Communication Consortium (C2C-CC) introduced different levels of trust, defined as Trust Assurance Levels, and the vehicle's authorization ticket (i.e., anonymous certificate) must include the value of the vehicle's TAL. Subsequent drafts did not include this requirement.

[0057] The Car2Car Alliance defines a common standard protection profile for the Evaluation Assurance Level (EAL4) of the V2X Hardware Security Module (HSM) in the Car2Car communication alliance, as outlined in the "V2X Hardware Security Module Protection Profile" (August 2018). Section 7.4.6 of the Car2Car Alliance Basic Profile, "C2C-CC Basic System Profile" (August 2016), describes the trust assurance for vehicle-to-vehicle (C2X) stations. Key features include five trust levels designated as Trust Assurance Levels (TAL) 0 through TAL 4, with TAL 4 being the highest trust assurance level. The lowest acceptable TAL for an ITS station is TAL 2. Each TAL is mapped to a subject assurance representation according to ETSI TS 103 097.

[0058] Furthermore, a demonstration at the Car2Car Alliance / CAMP conference in 2012 highlighted the following: The receiver can ensure error-free V2X messages based on the concept that the trusted party has evaluated the sending endpoint according to mature, internationally recognized, and trusted security standards and issued a certificate, allowing the receiver to verify its assessment of the difficulty of compromising with the sender. The conference further suggested that different TAL levels can be used for different applications, because if there is only one TAL level, it must be the TAL level required by the most demanding applications. For all applications, this level may be difficult to achieve.

[0059] The Car2Car conference considered options for “trusted international standards,” including NIST FIPS-140-X, which focuses more on the use of encryption technology than on comprehensive cybersecurity standards; ISO General Standard 3.1, which has limited durability (2 years), causing problems and is costly; and a custom OEM C2X assessment scheme adapted from CC. Additionally, the ISO / SAE 21434 international standard draft “Road Vehicles – Cybersecurity Engineering” (February 2020) did not exist in 2012, but is described below.

[0060] Examples of trust guarantee levels defined by the C2C forum are shown in Table 1 below.

[0061]

[0062] Table 1: Trust Guarantee Levels for C2X Sites

[0063] In Table 1 above, TAL 2 is the lowest acceptable level.

[0064] Another example of assurance levels is regarding PRESERVE. PRESERVE is a European Community-funded project concerning the security and privacy aspects of vehicle-to-everything (V2X) communications. Highlights of Section 2.5 of PRESERVE (the seventh framework program funded by EC-DG INFSO, January 2016) (“Preparing Secure Vehicle-to-X Communication Systems,” Deliverable 5.4, Deployment Issues Report) include: only vehicles with a reasonable security level can obtain certification from the C2X PKI; entities (e.g., certification companies / industry alliances / OEM self-signing) should be able to verify that the V2X module meets the minimum security level; successful assessment and certification can serve as the basis for a registration authority to issue a registration certificate to the vehicle; and TAL should be included in the vehicle's authorization document (anonymous certificate).

[0065] In another example, the ISO / SAE 21434 draft international standard (DIS) specifies the following:

[0066] The network security assurance level (CAL) is defined in Table 2.

[0067]

[0068] Table 2: ISO / SAE 21434 Network Security Assurance Levels

[0069] Inappropriate behavior detection

[0070] An example of global misbehavior detection is described in the "Vehicle-to-Vehicle Communication Misbehavior Detection" (CAMP, V2V-CRFinal Report). Specifically, the CAMP Vehicle Safety Communications 6 (VSC6) consortium provides an example of a conceptual Onboard Equipment (OBE) and Safety Credential Management System (SCMS) misbehavior detection (MBD) component architecture. Refer to [link / reference] now. Figure 3 .

[0071] exist Figure 3 In this embodiment, the left side of the figure shows the information flow within OBE 310. The right side of the figure shows SCMS 312. Communication with other vehicles is facilitated via V2V interface 314.

[0072] In OBE 310, the over-the-air (OTA) receive (RX) and transmit (TX) function block 316 is shown and communicates with the V2V interface 314. Vehicle Controller Area Network (CAN) and Global Positioning System (GPS) information is provided from block 318 to the OTA RX / TX function block 316.

[0073] In addition, information from boxes 316 and 318 can be provided to security application box 320 and local misbehavior detection (LMBD) box 330.

[0074] Safety application box 320 and supporting processes include target classification (TC), threat arbitration (TA), and safety applications for warning report generation. These include forward collision warning (FCW) box 322 and blind spot warning / lane change warning (BSW / LCW) box 324.

[0075] Local Misbehavior Detection (LMBD) method block 330 can generate reports, including a proximity report at block 332 and a warning report at block 334. LMBD method block 330 receives inputs from blocks 316, 318, and 320 and can provide outputs to Misbehavior Reporting (MBR) generation block 340.

[0076] MBR generation frame 340 generates misconduct reports and can provide them to MBR storage frame 342, local certificate revocation list (CRL) storage frame 344, and MBR launch frame 350.

[0077] The MBR transmitter frame 350 can communicate with the SCMS 312 using the MBR interface 354. Specifically, communication can be with the registration authority 360 and / or optionally with the MBR storage / database 362.

[0078] Registration authority 360 and / or MBR storage / database 362 provide input to Global Misbehavior Detection (GMBD) method box 370. GMBD method box 3700 analyzes the MBR received from the OBE / vehicle and processes the MBR to identify misbehavior and determine which(s) device(s), if any, is the root cause of the misbehavior. GMBD box 370 includes device box 372, event box 374, and feature box 376.

[0079] Device frame 372 provides a detection method that scans the database of received MBRs to count the number of MBRs reporting identical illegal link values. If any link value totals more than a revocation threshold, the link value is submitted for revocation using certificate revocation manager 380.

[0080] Event box 374 provides event-based detection designed to capture misconduct and attacks occurring in the same physical location and within a time window (e.g., minutes, hours, days), even if (multiple) misconducting devices use multiple anonymous certificates to commit misconduct.

[0081] Feature box 376 provides feature-based detection designed to capture advanced attacks and malicious behavior. This box is best considered as a framework upon which many detection algorithms can be built.

[0082] Event box 374 and feature box 376 can provide input to link information manager 382, ​​and link information manager 382 can then provide its output to certificate revocation manager 380.

[0083] The certificate revocation manager 380 can provide information to the certificate linking box 384, which can include a linking authority (LA), an anonymous certificate authority (PCA), and / or a registration authority (RA).

[0084] In addition, the Certificate Revocation Manager 380 can provide information to the CRL Generation and Distribution Frame 386. Frame 386 can be used to provide CRLs to the OBE 310, and particularly to the local CRL storage frame 344, via the CRL interface 390.

[0085] Therefore, in Figure 3 In the structure shown in the diagram, the left side illustrates the information flow within the OBE 310, which is typically located on the vehicle. This forms the basis of MBD, as it provides information for performing GMBD. Typically, the LMBD method 380, which receives input from the vehicle's CAN and GPS receivers 318, as well as from other sources (e.g., safety applications and received V2X messages, such as OTA messages received by the BSM from surrounding vehicles), provides the basis for generating the MBR, which is then sent via the MB interface 354 to the Misbehavior Authority (MA) residing on the SCMS.

[0086] Figure 3 The right side illustrates the information flow within the SCMS. Typically, the GMBD method 370 receives input from the MBR (usually located on the vehicle) via the MBR interface 354 and performs a summary analysis, which provides the basis for placing the OBE or vehicle on the CRL. The CRL is then sent to one or more OBEs in the V2X system, thus completing the end-to-end MBD and reversal process.

[0087] In addition, solutions for endpoint anomaly detection exist in the V2X industry, which may include sending data to network entities so that the network entities can identify anomalies in the endpoints. Example anomaly solutions include those provided by the Internet Engineering Task Force (IETF) Network Endpoint Assessment (NEA).

[0088] A network entity can be called an anomaly detection server. Such a server detecting anomalies in an endpoint can indicate that the endpoint has been compromised or compromised. In other words, the endpoint's network security posture is low, or it has been compromised or adversely affected. This could happen, for example, due to attackers exploiting vulnerabilities in the endpoint.

[0089] Endpoints can be assessed according to IETF Request for Comments (RFC) 5209, “Network Endpoint Assessment (NEA): Overview and Requirements.” Specifically, the IETF defines a system architecture and a set of protocols for network endpoint assessment, primarily to enable enterprise IT infrastructure to assess the network security posture of endpoints wishing to join the enterprise network in order to implement network access control. In this context, endpoints can be laptops, desktop computers, etc. For example, such endpoints may be isolated until their network security posture is determined to be satisfactory. An example from IETF RFC 5209 is as follows:

[0090] • NEA provides network owners (e.g., businesses providing remote access) with a mechanism to assess system posture. This can occur at any time during a request for network access and / or upon subsequent connection to the network. The learned posture information can then be applied to various regulatory compliance-oriented decisions. Posture information is commonly used to detect systems lacking or with outdated security protections, such as antivirus and host-based firewall software.

[0091] The purpose of NEA is to assess these endpoints to determine whether they comply with security policies so that remedial measures can be taken before they are exposed to these threats. For example, if a system is determined to be non-compliant due to a lack of appropriate defense mechanisms (such as host-based firewalls, antivirus software, or a lack of critical security patches), the NEA protocol provides a mechanism to detect this fact and indicate the appropriate remedial measures to be taken.

[0092] • NEA typically involves using specialized client software running on the requesting endpoint that observes and reports system configuration to the network infrastructure. The infrastructure has corresponding verification software that compares the endpoint's configuration information against network compliance policies and provides the results to the appropriate authorized entity making network and application access decisions…

[0093] …Architectures similar to NEA have existed in the industry for some time and have appeared in product releases, but they haven't provided sufficient interoperability. Some examples of such architectures include Trusted NetworkConnect [TNC] from Trusted Computing Group, Network Access Protection [NAP] from Microsoft, and Cisco Network Administration Control [CNAC] from Cisco. These technologies evaluate the software and / or hardware configuration of endpoint devices to monitor or enforce compliance with an organization's policies.

[0094] Other solutions may exist in this technical field, and are referred to herein as "endpoint attestation".

[0095] Anomalies can be detected in a variety of ways. Examples of methods for detecting anomalous behavior in IT equipment (which can indicate potential security risks) may include, but are not limited to, the following.

[0096] In the first aspect, anomalies can be detected by detecting security policy violations. This can include identifying which processes can attach to which inter-process communication channel(s). It can also include processing capability restrictions, such as mapping physical memory ranges, switching unique identifiers (UIDs), and the ability to create and unlock data.

[0097] On the other hand, anomalies can be detected by detecting memory violations. This can include detecting overwritten stack cookies; attempts to run code from non-executable memory; attempts to write read-only data; heap hardening boundary protection; access to invalid memory pages; and so on.

[0098] On the other hand, anomalies can be detected by detecting network anomalies. This can include detecting abnormal throughput rates on a given network resource or detecting violations of network policies. Network policies can include those that allow or prohibit endpoints from communicating with other endpoints. Violations of network policies can also be related to packets detected at firewalls, such as packets that are rejected and dropped by firewalls.

[0099] On the other hand, anomalies can be detected by detecting process anomalies. This can include detecting unexpected processes running; processes not expected to run; and / or processes not running at the expected privilege level; and so on.

[0100] On the other hand, anomalies can be detected based on Task Manager anomalies. In particular, such anomalies may include processes that are not consuming the expected level of processing power.

[0101] On the other hand, anomalies can be detected from collision detection, namely, processes that end or terminate unexpectedly or prematurely. In particular, the process of a crash can indicate the existence of a compromise.

[0102] On the other hand, anomalies can be detected based on integrity checks. For example, such integrity checks may include cross-checking the signatures and hashes of executable files and other critical files, including one or more of the following: hardware; software; boot read-only memory (ROM); operating system (OS); and applications, etc.

[0103] On the other hand, anomalies can be detected by detecting tampering with the Hardware Security Module (HSM).

[0104] Other aspects that can be used to detect anomalies are also possible.

[0105] Detection of misconduct in V2X transmitters

[0106] According to embodiments of this disclosure, a receiving entity that receives a V2X message may need to determine whether it can trust the content of the V2X message and thus take action on the received V2X message or otherwise utilize the information. Specifically, the ITS-S receiving the V2X message may need to establish trust that the V2X transmitter has not been compromised by a malicious actor, which may occur by exploiting cybersecurity vulnerabilities.

[0107] The examples provided in this article are based on the European Collaborative Credential Management System (CCMS) solution. However, similar concepts apply to any other type of SCMS, including but not limited to Security Credential Management System (SCMS) based on the US Collision Avoidance Index Partners (CAMP), Chinese SCMS systems, etc.

[0108] As used herein, the term "auditing CA" can refer to any company capable of performing cybersecurity assessments of the V2X design, manufacturing, and post-production processes of an original equipment manufacturer (OEM) or Tier 1 supplier. Such assessments may involve an auditing certificate authority (CA) examining provided documentation and evidence and interviewing employees of the company designing, manufacturing, and / or operating the V2X transmitter. In some cases disclosed herein, the auditing CA is not required to operate its own public key infrastructure (PKI).

[0109] about Figure 4 This provides a high-level overview of one embodiment of the present disclosure. Figure 4 In such environments, V2X transmitters have the ability to detect improper behavior. In some cases, this can be based on security hardware components that monitor the transmitter of the V2X system.

[0110] Figure 4 The process begins at box 410 and proceeds to box 420, where integrity checks can be performed. Specifically, improper or anomalous behavior is detected within the V2X transmitter, not in a third-party entity outside the V2X transmitter. This integrity check can be performed using an integrity detection engine. An example of such an engine is, for instance, the BlackBerry Integrity Detection Engine described in James Dreher's article, "BlackBerry Integrity Detection is here!" (May 19, 2016).

[0111] Integrity inspection, as used in this article, is a broad term used to refer to the inspection of the network security posture of a transmitter, including but not limited to checking for any anomalies and whether the integrity of software, memory, and other system components is good or acceptable.

[0112] Therefore, as part of an integrity detection procedure or process, functions within the V2X transmitter (such as applications running in secure hardware) generate integrity reports that may include information associated with anomalous behavior of the V2X transmitter. This information associated with anomalous behavior of the V2X transmitter may be information or data related to the various anomaly detection processes described above.

[0113] As used herein, “secure hardware” consists of hardware that is typically isolated in a secure manner from an operating environment zone (in which V2X applications run), referred to herein as a “rich operating environment.” This zone is typically more limited in terms of processing power and is used to support security-related features. For example, “secure hardware” can be any of the following: a Trusted Execution Environment (sometimes called a TEE); a secure element; a TrustZone-like feature of a Reduced Instruction Set Computer (RISC) machine (ARM); a secure enclave; or other similar solutions.

[0114] The integrity check performed at box 420 can be based on a trigger that occurs. For example, a trigger may include one or more of the following: when a device or OS boots or starts; whenever an application boots, loads, or starts; periodically, such as based on a timer; when a firmware or software update is completed, in determining how the update was received, such as whether the update was received over the air or performed directly; when new hardware is detected; when a new or updated application is detected; and / or whenever a V2X message is to be sent; etc.

[0115] Once an integrity check occurs and an integrity report is generated, the process proceeds from box 420 to box 430, where the V2X transmitter can compose a V2X message based on the integrity report. Specifically, the result of box 420 affects the content included in the V2X message to be sent and whether the V2X message should be sent at all.

[0116] For example, when constructing or structuring a V2X message, the V2X transmitter may include an integrity report indicating that the V2X transmitter is currently considered secure across the network. In other words, the V2X transmitter can be considered free of detected anomalies, and its software can be up-to-date as of a specific date. The integrity report and the V2X message itself are signed, for example, and can be executed within secure hardware within the V2X transmitter.

[0117] Therefore, there are various options for V2X messages based on integrity reports. In the first option, when no hazard or anomaly is detected, the integrity report can be included in the V2X message sent to the V2X receiver. If a hazard or anomaly is detected, the V2X transmitter can choose not to send a V2X message, or can choose to indicate a decision not to send V2X information to another entity, including one or more of the following: sending a message to an application (e.g., via an API), sending a message to an OBU or ECU (e.g., via a CAN bus), sending a message to a server outside the vehicle (e.g., an anomaly detection server or a cloud-based server), triggering a visual alarm on a display unit (e.g., a dashboard or infotainment system), triggering an audible alarm, etc. Messages sent to applications, OBUs or ECUs, and external servers can include integrity reports and can include indications that a hazard or anomaly has been detected.

[0118] In the second option, an integrity report can be included in the V2X message sent to the V2X receiver, regardless of whether a hazard or anomaly is detected. In some cases, such a message can also be sent regardless of the severity of the detected anomaly.

[0119] In another scenario, integrity reports may be included in some V2X messages but not in others. For example, in some cases, integrity reports may only be included in safety-critical V2X messages, such as emergency braking warning messages, but not in common or periodic Cooperation Awareness (CAM) or Basic Safety (BSM) messages.

[0120] The content of an integrity report can take many forms. For example, in the first case, an integrity report could provide an indication that "no hazard was detected" or "a hazard was detected."

[0121] In another scenario, an integrity report can provide an indication of "no hazard detected," "an anomaly detected but it is unclear whether a hazard exists," or "a hazard detected."

[0122] In another scenario, the integrity report can provide an indication of "no anomaly detected" or "anomaly".

[0123] In another scenario, the integrity report can provide an indication of "no anomaly detected," "anomaly," or "highly anomaly."

[0124] In another scenario, the integrity report may be presented as indicating “All monitored features: within expected operating range,” “One or more monitored features: outside expected operating range,” or “One or more monitored features: far outside expected operating range.”

[0125] In another scenario, other variations similar to those described above may be provided. Furthermore, more fine-grained faults may occur, exhibiting different types of anomalies found in V2X transmitters.

[0126] Many potential anomalies can be Boolean values ​​(true or false), so either an anomaly exists or it doesn't. Some anomalies can also be non-binary. For example, in one case, the expected network data throughput is within a range less than the value "X". Therefore, an "anomaly" could correspond to throughput between the measured values ​​"X" and "Y", and a "highly anomaly" could be throughput with a measured value greater than the value "Y". Other examples are also possible.

[0127] Furthermore, integrity reports can also be sent to functions provided within the vehicle to aid in diagnosis or analysis after an incident, such as post-collision analysis. This functionality can be referred to as a "black box" or "event data logger." These integrity reports can optionally provide more detailed information than that included in V2X messages. For example, an integrity report can provide more detailed information about the type of anomaly detected and can indicate the ECU(s)(s) that detected the anomaly, as well as a list of software and hardware materials and version numbers for a given situation. Such more detailed integrity reports can be sent to servers outside the vehicle, such as anomaly detection servers, cloud-based servers, etc.

[0128] Therefore, based on the V2X message composed at box 430, the process can proceed to box 440, where a V2X message is sent if the content of the integrity report allows.

[0129] From box 440, the process can return to box 430 to compose another V2X message. However, if a trigger to perform integrity checks is received, the process can proceed to box 420 to perform further integrity checks.

[0130] When a message is sent in box 440, the auditing CA can provide assurances regarding the security or cybersecurity of the integrity detection solution or function at a specific level. This is to ensure that reports provided by the integrity detection function are both accurate and truthful, generated by the function within the V2X transmitter. The assurance is indicated in an authorization ticket / certificate signed by the application CA and the root CA of the final CCMS / SCMS. As used herein, certificates issued by the application CA may be used for a short period of time, associated with a specific application and anonymous identity. This entity was formerly known as the Anonymous Certificate Authority.

[0131] ETSI (CCMS) authorized agencies perform similar functions.

[0132] Various measures can be taken to minimize the possibility that the integrity detection function itself is not compromised or is very difficult to compromise.

[0133] In one aspect, such measures could include running integrity detection applications within secure hardware, such as a TrustZone on a Reduced Instruction Set Computer (RISC) machine (ARM) processor or similar processor. In such a system, the rich operating environment or system runs in an untrusted zone, while smaller security-specific code runs in a more trusted zone. This reduces the attack surface for integrity detection applications and other security applications. This simultaneous support for rich and trusted operating environments can be achieved using virtualization techniques running on a single kernel.

[0134] On the other hand, such measures could include a secure boot chain process using a root key of trust in the embedded hardware. This secure boot chain process could involve checking the boot ROM signature, then the operating system software signature, and then one or more application signatures (e.g., an integrity detection application signature).

[0135] On the other hand, such measures could include signing the integrity report using a private key, for example, the private key could be installed in secure hardware. The V2X receiver could then use the corresponding public key to verify the authenticity of the integrity report. The following is about... Figure 5 Example implementations of where signing can occur are provided.

[0136] On the other hand, such measures could include ensuring that the integrity detection functionality itself is patchable and patched as patches become available. In this case, one possible assumption is that the audit CA can guarantee the original design is sound and that patching mechanisms are in place, but the audit CA does not re-evaluate the system every time the integrity detection software is updated. This assumption could also be that the initial guarantee also provides the V2X receiver with less trust than that the running integrity detection software is indeed the latest version.

[0137] Another possible assumption is that the certificates of vehicles that fail to update their integrity detection software in a timely manner may be revoked, for example, using a certificate revocation list.

[0138] Now for reference Figure 5 , Figure 5 An example implementation of the integrity detection function in ITS-S is shown. Figure 5 In the example, the embedded central processing unit (CPU) boot ROM 510 can securely boot the boot ROM 520 based on key 512. The boot ROM 520 can securely boot a network security operating system (OS) 530 based on key 522, such as a microkernel considered to be a specific network security assurance level (CAL), such as CAL4.

[0139] The network security OS 530 can securely boot the rich operating environment 540 based on key 532. The rich operating environment 550 may include V2X applications 542.

[0140] The network security OS 530 can further securely boot the security hardware 550 based on key 532. The security hardware 550 may include integrity detection functionality 552.

[0141] One advantage of providing integrity detection functionality 552 on security hardware 550 is that it is more difficult for attackers to compromise or crack integrity detection functionality compared to providing integrity testing functionality in rich operating environment 540.

[0142] Example interaction between ITS-S internal integrity detection function and V2X client / application: Figure 6 As shown. In particular, Figure 6 The environment includes a rich operating environment 610, a secure hardware zone 612, and an operating system 614.

[0143] The rich operating environment 610 includes a V2X application 620 that can generate V2X messages, as shown in box 622.

[0144] exist Figure 6 In one embodiment, the security hardware region 612 includes an integrity detection function 630. However, Figure 6 The example provided is just one solution; in another scenario, the integrity detection functionality could be located outside the secure hardware area.

[0145] After generating the V2X message at box 622, it is sent to the integrity detection module 630. The integrity detection module 630 can then check system integrity at box 640, for example, using the methods described above. Figure 4 The method described in block 420. The system integrity check may also optionally involve querying other electronic control units (ECUs) to determine if these ECUs have experienced any anomalies. Such ECUs may be, for example, sensor or actuator ECUs that provide information used when delivering V2X messages.

[0146] In box 642, V2X messages can be expanded with integrity reports.

[0147] In box 644, a V2X message with an integrity report can be signed using a private key, which can be installed within secure hardware 612, such as zone 632. This key can be verified by the V2X receiver using the corresponding public key to verify the authenticity of the integrity report.

[0148] For example, in one scenario, integrity detection function 630 adds an integrity report to the V2X message and signs the augmented V2X message using the private key associated with the authorization ticket / certificate; the signature and the authorization ticket / certificate are then added to the augmented V2X message. As described above, the authorization ticket / certificate may include information about the integrity detection function from the auditing CA.

[0149] Then, the signed, augmented V2X message is provided back to the rich operating environment 610 at box 646 so that the message can be transmitted on the V2X communication stack at box 670.

[0150] To prevent V2X applications from replaying old messages and attaching old integrity check reports, various techniques can be used. In one technique, time-varying information (such as timestamps, random numbers, or counts) is included in V2X messages passed from the rich operating environment 610 to the secure hardware area 612. In some cases, V2X messages may include timestamps because timestamps are often critical information for V2X receiver applications for reasons unrelated to network security, as described in SAE J2735. In this case, if the granularity of the timestamp is in 10-millisecond increments, any replay sent within the same second will succeed because replays are indistinguishable. However, sequence numbers or message counts, along with timestamps, can overcome this problem. In this case, the count may need to be rolled high enough to occur outside the granularity of the timestamp.

[0151] Similarly, message counts are included in many V2X messages, as defined in SAE J2735. This message count can be important in applications that need to know if a message has been lost.

[0152] In another scenario, the integrity detection function 630 may insert random numbers, message counts, or timestamps into the secure hardware area 612, which are then included in the integrity detection report.

[0153] In all of the above cases, the V2X receiver may need to track these values ​​(e.g., random number, message count, or timestamp) to detect replay.

[0154] The expanded V2X message also includes an authorization ticket / certificate with an indication that the integrity detection function is secure. This indication can be in an existing field or a new field. Furthermore, the integrity detection function 630 can be more secure than the V2X application 620.

[0155] This instruction / assurance may initially come from the auditing CA, which checks whether the manufacturer's processes and documentation comply with the security development lifecycle standards and / or product standards. In one example, this assurance information would be provided to the registration authority. The registration authority would then provide this information to the licensing authority as part of the process by which the ITS-S obtains an authorization note. For example, this could be... Figure 2 This is part of message 230.

[0156] In this way, only ITS stations whose integrity detection function is guaranteed to be highly secure will receive an authorization ticket / certificate, in which a field indicates that the integrity report can be trusted by the V2X receiver set.

[0157] Integrity detection damage

[0158] Although many mechanisms may be established in the design and process to ensure the reliability of cybersecurity reports, hackers / attackers may compromise the functionality within the V2X transmitter that generates integrity reports.

[0159] When such a hazard is detected, the SCMS CA can be notified, and one or more certificates of the affected V2X transmitter can be revoked. This may include certificates that share the same hardware / software as the compromised transmitter, for example, by adding or sending a request to add a certificate, or by sending one or more indications of the certificate to the Certificate Revocation List (CRL).

[0160] SCMS CA sends messages to the Certificate Revocation List (CRL) to request one or more certificates or one or more instructions regarding certificates, such as... Figure 7 As shown. In Figure 7 In this embodiment, V2X entity 710 may include one or more certificates to sign the integrity report. SCMS CA 716 may provide one or more such certificates to V2X entity 710.

[0161] exist Figure 7 In this embodiment, the V2X entity may optionally report an anomaly to SCMS CA 716, as shown in message 720.

[0162] In a separate option, the event shown in box 730 can occur. For example, the event could be a traffic accident, which would be analyzed and a violation of integrity report would be found. Other events are possible in box 730.

[0163] Based on the receipt of message 720 or the occurrence of event 730, SCMS CA 716 can send a CRL addition request message 750 to the Certificate Authority 718, wherein message 750 includes one or more certificates or one or more indications of certificates. In one case, message 750 may also include vehicle-related information, such as the vehicle's brand, model, etc. Other options are also possible.

[0164] Upon receiving message 750, the Certificate Authority 718 may add one or more received certificates or one or more indications of certificates to the CRL, as shown in box 770. Such a CRL can then be distributed to the ITS station.

[0165] Subsequently, when an affected V2X transmitter with one or more revoked certificates contacts SCMS CA 716 to obtain one or more new certificates, a new certificate may not be issued, or one or more certificates with a lower integrity detection guarantee level may be issued.

[0166] A single organization (OEM) can track whether a specific type of vehicle / V2X transmitter design has been compromised by integrity detection (or cybersecurity posture) reports and place indications of one or more certificates for affected vehicles on the CRL. This can be possible where the same entity or organization owning the CRL also has access to integrity detection (or cybersecurity posture) information, for example, vehicle OEMs operating SCMS.

[0167] In addition, by placing one or more certificates of the affected vehicle, or an indication of one or more certificates, on the CRL, this can prompt the vehicle to request one or more new certificates when it discovers that one or more of their certificates exist or are indicated on the CRL.

[0168] Furthermore, in some cases, different intermediate certification bodies may be used for a group of vehicles, such as a CA for each brand / model / year or "V2X module HW generation". By using different intermediate CAs for a group of vehicles, revoking an intermediate CA certificate can be a simpler and more scalable alternative to revoking an individual vehicle's certificate using one or more certificates.

[0169] SCMS operations by a vehicle OEM can be achieved by mapping or binding the type of V2X transmitter (software / hardware used) within the vehicle to the vehicle's anonymous certificate. This can be done by using lookup lists or tables, performing database lookups, etc. The anonymous certificate can later be provided to the SCMS misconduct authority in a misconduct report (or similar report) to result in one or more certificates associated with that vehicle being placed on the CRL.

[0170] The process of securely transmitting the vehicle's public key to the authorized CA, and ensuring that the receiving vehicle possesses a trusted copy of the authorized CA's public key, can follow the currently defined mechanisms.

[0171] Furthermore, not all V2X transmitters will achieve the above. Figures 4 to 7 Instead of the processes and mechanisms provided in the documentation, some transmitters will continue to operate according to the current definition, without including integrity reporting or modifying the certificate format. To support this paradigm, V2X receivers need to determine the type of V2X transmitter. For example, they can determine whether an integrity detection guarantee level is included (or whether the certificate belongs to a type that can include such an integrity detection guarantee level) by examining the certificate in the received V2X message. If the V2X transmitter is determined to not use, support, or implement this feature, the V2X receiver can process the received V2X message and certificate according to the current method.

[0172] Therefore, according to Figures 4 to 7 In this embodiment, through the integrity report and audit CA information in the received V2X message, the V2X receiver can ensure that: the integrity detection engine provides confirmation of whether the V2X transmitter is complete (e.g., no anomalies were detected, a recent check for new software patches was performed and action was taken, and other checks); and the reports from the integrity detection function can be trusted because the related design and processes used to generate the integrity detection reports have been guaranteed to be trustworthy at a very high level by an independent audit CA.

[0173] In addition, although Figures 4 to 7 The process described in the embodiments can completely replace the currently used traditional misconduct authorization scheme, but both schemes can also be used simultaneously.

[0174] Receive V2X messages

[0175] V2X receivers ITS-S can be equipped with / pre-programmed with a variety of actions that can be taken based on the content of the received integrity report (e.g., based on the included network security posture level). The exact behavioral options depend on the use case, and an example is given below. However, as the trust level decreases, V2X receivers may become more cautious.

[0176] An example of the process of receiving a V2X entity is as follows: Figure 8 As shown. Figure 8 The process begins at box 810 and proceeds to box 812, where the ITS-S receiving entity determines whether a V2X message has been received. If not, the process continues looping back to box 812 until a V2X message is received.

[0177] Once a V2X message is received, the process proceeds to box 820, where an inspection is performed to determine whether the integrity report indicates "no anomaly detected" or other similar conditions. This inspection may also include checking whether the integrity detection function is certified by the auditing CA, as described above.

[0178] If so, the process proceeds from box 820 to box 830, where the receiving V2X application can take action on the V2X message content without having to take any mitigation actions as a result, at least from a cybersecurity perspective.

[0179] For example, if the V2X application is an emergency braking warning application, then in box 830, the message content is credible and force braking can be applied, even if this may cause other accidents, which are less serious than accidents that occur without force braking.

[0180] Conversely, if the check performed at box 820 determines that the V2X transmitter integrity report is missing or indicates that an anomaly has been detected, the process proceeds to box 840, and the ITS-S receiving entity can take mitigation actions.

[0181] For example, in the case of an emergency braking warning application, the level of trust in the message content in box 840 will be lower than the level of trust in box 830. In this case, braking can still be applied more gently, pending further confirmatory evidence, such as visual evidence that the vehicle ahead has braked urgently.

[0182] In some cases, if the exception is not a Boolean value but has different levels, the higher the exception level, the more cautious the receiving entity is in responding to the message, and therefore the degree of response may be reduced. For example, if there is a large difference between the two levels, the vehicle may not apply any braking but instead pre-charge the brakes. This could involve activating the hydraulic system, and increasing the force and speed at which the brakes are applied when a human driver or autonomous robot does apply them. Other options are also possible.

[0183] The process proceeds from box 830 or box 840 to box 850 and then ends.

[0184] Update message

[0185] Strategy and governance documents can be updated to define new requirements that certification bodies must implement, such as the European Commission’s “Certificate policy for deployment and operation of European Cooperative Intelligent Transport Systems (C-ITS)” (1st edition, June 2017). Added requirements could include: SCMCA can determine that there is evidence from an independent third party (i.e., the auditing CA) that the OEM’s mandated level of assurance regarding integrity testing capabilities associated with a given specification identity has actually been achieved.

[0186] In some cases, the cybersecurity “quality” (level) of integrity testing software can be determined based on the requirements of a common standard protection profile and can have an associated Assessment Assurance Level (EAL).

[0187] Similarly, V2X industry associations or standards bodies can define their own rankings, such as the Trust Assurance Level (TAL) defined by the Car2Car consortium and ETSI. Another alternative could be to use the Cybersecurity Assurance Level (CAL), as defined in ISO 21434.

[0188] Various messages and entities may need to be updated, including registry authorities, AuthorizationValidationResponse messages and AuthorizationValidationRequest messages and / or authorization tickets / certificates, etc.

[0189] The AuthorizationValidationResponse and AuthorizationValidationRequest messages can be updated to include a new parameter, labeled intDetectAssuranceLevel in this document, in addition to the current assuranceLevel parameter. This new parameter indicates the assurance level associated with the integrity detection function.

[0190] Specifically, the CertificateSubjectAttributes structure used in both messages can be updated, as shown in bold in Table 3 below. This structure is the type associated with both the requestedSubjectAttributes (AuthorizationValidationRequest) and concemedSubjectAttribute (AuthoritionValidationResponse) messages.

[0191]

[0192] Table 3: CertificateSubjectAttributes

[0193] In addition, for authorization tickets / certificates, the authorization response message sent by the authorizing authority to ITS-S, which includes the authorization ticket, can update the authorization ticket to include the new parameter intDetectAssuranceLevel along with the current assuranceLevel parameter.

[0194] For example, Table 4 shows the current licensed tickets as defined in IEEE 1609.2.

[0195]

[0196] Table 4: Authorization Ticket In one embodiment, the authorization ticket can be modified according to Table 5 below, as shown in bold.

[0197]

[0198]

[0199] Table 5: Modified Authorization Tickets

[0200] For example, SubjectIntDetectAssurance can select one of seven levels. These can correspond to the general standard EAL 1 through 7. Alternatively, these levels can take equivalent TAL or CAL values. In other cases, more or fewer levels can be used.

[0201] Furthermore, in some cases, SubjectIntDetectAssurance can be defined essentially as binary: for example, "the integrity detection report is trustworthy" or "the integrity check report may be untrustworthy".

[0202] In another scenario, if the information element is present, the integrity check report can be trusted and can be relied upon according to the V2X transmitter-based misconduct method according to the embodiments herein, while if it is not present, the V2X receiver can rely on a conventional misconduct agency (which may involve CRL) method.

[0203] Then, the existing assuranceLevel information can be associated with V2X applications running in rich operating environments.

[0204] Peer-to-peer cybersecurity posture report

[0205] In the above Figures 4 to 7 In variations of the embodiments, unlike solutions designed around actual detection and optional reporting of misconduct, the transmitting vehicle may alternatively or additionally identify and report other aspects of the cybersecurity posture that the V2X receiver can use to determine the level of trust in received messages. Such misconduct may include detecting anomalies, detecting actual malicious activity, and other such actions.

[0206] Other aspects of the cybersecurity posture that can be reported can include a variety of items.

[0207] One metric may include the network security vulnerability scoring system (CVSS) aggregate (and possibly quantified) score of the V2X transmitter. Here, CVSS is a standardized network security vulnerability scoring system, and the aggregate metric can be determined by considering all or a subset of known vulnerabilities for the V2X transmitter and aggregating the corresponding CVSS scores for those vulnerabilities.

[0208] Another factor may include whether the software in the V2X transmitter (e.g., a V2X application that may be located in a rich operating environment, integrity detection functionality that may be located in secure hardware, etc.) is considered up-to-date.

[0209] Another factor could be the time when the software update server was last accessed / polled to determine if new software / patches were available. For example, such software or patches could be used in V2X applications, integrity detection functions, etc.

[0210] Another item could include whether the V2X transmitter has weaknesses or vulnerabilities. These vulnerabilities could be related to specific hardware versions, software versions, and other considerations. Such items could also include the severity of known weaknesses(s), such as those measured by CVSS.

[0211] Another item could include whether patches for known weaknesses are available.

[0212] according to Figures 4 to 7In some embodiments, the report may include other aspects to ensure its security, such as timestamps, so that it cannot be replayed.

[0213] ITS-S may need to poll an entity, such as an OEM server or a federal vulnerability database / server, to obtain the aforementioned cybersecurity posture information. In this case, polling can occur in software loaded into the security hardware. Now refer to Figure 9 .

[0214] exist Figure 9 In this embodiment, the V2X integrity detection function 910 can communicate with the network security posture information server 912. In this case, the V2X integrity detection function 920 can send a network security posture request 920 to the server 912.

[0215] In response, server 912 can send network security posture response 922 back to V2X integrity inspection function 910.

[0216] Therefore, according to Figure 9 It can perform peer-to-peer cybersecurity posture reports.

[0217] hardware

[0218] V2X entities, V2X clients, ITS-S, registration authorities, authorization authorities, SCMS, certificate authorities, or network servers or nodes can be any type of computing device. For example, regarding Figure 10 A simplified computing device is provided that can perform the above embodiments.

[0219] exist Figure 10 In this embodiment, computing device 1010 includes processor 1020 and communication subsystem 1030, wherein processor 1020 and communication subsystem 1030 cooperate to perform the methods of the embodiments described herein.

[0220] Processor 1020 is configured to execute programmable logic, which can be stored on computing device 1010 along with data, and Figure 10 The example shown is memory 1040. Memory 1040 can be any tangible, non-transitory computer-readable storage medium, such as DRAM, Flash, optical disc (e.g., CD, DVD, etc.), magnetic tape (e.g., magnetic tape), flash drive, hard disk drive, or other memory known in the art. In one embodiment, processor 1020 can also be implemented entirely in hardware and does not require any stored program to perform logical functions.

[0221] Alternatively, in addition to memory 1040, computing device 1010 may also access data or programmable logic from external storage media, such as through communication subsystem 1030.

[0222] The communication subsystem 1030 allows the computing device 1010 to communicate with other devices or network elements.

[0223] In one embodiment, communication between the various components of the computing device 1010 can be achieved via an internal bus 1060. However, other forms of communication are also possible.

[0224] The embodiments described herein are examples of structures, systems, or methods having elements corresponding to the elements of the technology of this application. This written description enables those skilled in the art to make and use embodiments having alternative elements, which also correspond to the elements of the technology of this application. Therefore, the intended scope of the technology of this application includes other structures, systems, or methods that are not different from the technology of this application described herein, as well as other structures, systems, or methods that are not substantially different from the technology of this application described herein.

[0225] Although the operations are described in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or sequentially, or requiring the execution of all illustrated operations to obtain the desired result. In some cases, multitasking and parallel processing may be used. Furthermore, the separation of different system components in the above implementation should not be construed as requiring such separation in all implementations. It should be understood that the described program components and systems can typically be integrated into a single software product or packaged into multiple software products. In some cases, functionality can be implemented entirely in hardware, and such solutions may be functionally equivalent to software solutions.

[0226] Furthermore, the technologies, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations can be combined or integrated with other systems, modules, technologies, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrical, mechanical, or otherwise. Other examples can be identified by those skilled in the art and can be modified, replaced, and altered.

[0227] While the foregoing detailed description has shown, described, and pointed out the essential novel features of this disclosure applicable to various implementations, it should be understood that those skilled in the art can make various omissions, substitutions, and changes to the form and details of the illustrated system. Furthermore, the order of the method steps is not dependent on their order of appearance in the claims.

[0228] When sending or receiving messages to electronic devices, such operations may not occur immediately or directly from a server. They can be delivered synchronously or asynchronously from servers or other computing system infrastructure that support the devices / methods / systems described herein. The aforementioned steps may include, in whole or in part, synchronous / asynchronous communication with the devices / infrastructure. Furthermore, communication can be from an electronic device to one or more endpoints on a network. These endpoints can be served by servers, distributed computing systems, stream processors, etc. Content delivery networks (CDNs) can also provide communication to electronic devices. For example, unlike a typical server response, a server can also provide or instruct a content delivery network (CDN) to provide data for later download by an electronic device, such as subsequent activity of the electronic device. Therefore, data can be sent directly from servers or other infrastructure (such as distributed infrastructure or CDNs) that is part of or independent of the system.

[0229] Typically, storage media can include any or some combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory, and flash memory; magnetic disks, such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical disks (such as compact discs (CDs) or digital video discs (DVDs)); or other types of storage devices. Note that the above instructions may be provided on a single computer-readable or machine-readable storage medium, or on multiple computer-readable / machine-readable storage media distributed across a large system that may have multiple nodes. Such computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture can refer to any single or multiple components manufactured. One or more storage media may be located on a machine that executes the machine-readable instructions, or at a remote site from which the machine-readable instructions can be downloaded via a network for execution.

[0230] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, in practice, these details may be omitted. Other implementations may include modifications and variations to the foregoing details. The appended claims are intended to cover such modifications and variations.

[0231] Furthermore, the exemplary provisions may provide a method at a receiving entity of an Intelligent Transportation System (ITS), the method comprising: receiving an ITS message; determining that the received ITS message is signed using a certificate from an accredited certificate authority; determining that an assurance instruction from an audit certificate authority for an integrity detection function exists within the ITS message; extracting an integrity report from the ITS message; and taking action on the ITS information based on the results within the integrity report.

Claims

1. A method at an intelligent transportation system (ITS) transmitter entity, the method comprising: An ITS message is generated at the ITS transmitting entity; The ITS message is augmented using an integrity report generated by an integrity detection function within the ITS transmitting entity to create an augmented ITS message. The integrity detection function checks the network security posture of the transmitter of the ITS transmitting entity. The integrity report is generated by performing an integrity check of the ITS transmitting entity by the integrity detection function at the ITS transmitting entity, and the network security posture includes information for detecting systems that lack or have outdated security protection mechanisms. The augmented ITS message is signed using a private key associated with an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including an assurance indication from an audit certificate authority indicating that the integrity detection function is secure; as well as Send the signed, expanded ITS message to the ITS receiving entity.

2. The method of claim 1, wherein the generation of the ITS message is performed in the rich operating environment of the ITS transmitting entity.

3. The method of claim 1, wherein the integrity detection function is within the security element of the ITS transmitting entity.

4. The method of claim 1, wherein the execution is based on a triggering condition, the triggering condition being one or more of the following: device or operating system startup; whenever an application is started or loaded; periodically; when a firmware or software update is completed; when new hardware is detected; when a new or updated application is detected; and whenever a new ITS message is to be sent.

5. The method of claim 1, wherein the detection of anomalies in the transmitter of the ITS transmitting entity includes one or more of the following: detecting security policy violations; detecting memory violations; Detecting network connectivity issues; The detection process is abnormal; Task Manager malfunction; Collision detection; integrity checks of one or more of the following: hardware, software, boot read-only memory ROM, operating system, and applications. And detect tampering with hardware security modules.

6. The method according to claim 1, further comprising: The integrity report indicating an anomaly is detected by at least one of the following: sending a message to an application; sending a message to an onboard unit (OBU) or electronic control unit (ECU); sending a message to a server outside the vehicle; triggering a visual alarm on a display unit; or triggering an audible alarm.

7. The method of claim 1, wherein the integrity report is a Boolean value indicating whether an anomaly has been detected.

8. The method of claim 1, wherein the integrity report includes the level of the detected anomaly.

9. The method of claim 1, wherein the assurance indication from the audit certificate authority is within a field of the authorization certificate or the authorization document.

10. An Intelligent Transportation System (ITS) transmitter entity, the ITS transmitter entity comprising: processor; Memory; as well as Communication subsystem The memory stores instructions that, when executed by the processor, cause the ITS to launch entity: Using the processor, an ITS message is generated at the ITS transmitting entity; Using the processor, the ITS message is augmented with an integrity report generated by an integrity detection function within the ITS transmitting entity to create an augmented ITS message. The integrity detection function checks the network security posture of the transmitter of the ITS transmitting entity. The integrity report is generated by performing an integrity check of the ITS transmitting entity by the integrity detection function at the ITS transmitting entity, and the network security posture includes information for detecting systems that lack or have outdated security protection mechanisms. Using the processor, the expanded ITS message is signed with a private key associated with an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including an assurance indication from an audit certificate authority indicating that the integrity detection function is secure; as well as Using the communication subsystem, the signed, expanded ITS message is sent to the ITS receiving entity.

11. The ITS transmitting entity of claim 10, wherein the ITS transmitting entity is configured to generate the ITS message in a rich operating environment of the ITS transmitting entity.

12. The ITS transmitter entity of claim 10, wherein the integrity detection function is located within the security element of the ITS transmitter entity.

13. The ITS transmitting entity of claim 10, wherein the ITS transmitting entity is configured to execute based on triggering conditions, the triggering conditions being one or more of the following: device or operating system startup; whenever an application is started or loaded; periodically; when a firmware or software update is completed; when new hardware is detected; when a new or updated application is detected; and whenever a new ITS message is to be sent.

14. The ITS transmitting entity of claim 10, wherein the ITS transmitting entity is configured to: perform detection of anomalies in the transmitter of the ITS transmitting entity, the detection including one or more of the following: detecting security policy violations; detecting memory violations; Detecting network connectivity issues; The detection process is abnormal; Task Manager malfunction; Collision detection; integrity checks of one or more of the following: hardware, software, boot read-only memory ROM, operating system, and applications. And detect tampering with hardware security modules.

15. The ITS transmitting entity of claim 10, wherein the integrity report indicating an anomaly is detected by at least one of: sending a message to an application; sending a message to an onboard unit (OBU) or electronic control unit (ECU); sending a message to a server outside the vehicle; triggering a visual alarm on a display unit; or triggering an audible alarm.

16. The ITS transmission entity of claim 10, wherein the integrity report is a Boolean value indicating whether an anomaly has been detected.

17. The ITS transmission entity of claim 10, wherein the integrity report includes the level of the detected anomaly.

18. The ITS launch entity of claim 10, wherein the assurance indication from the audit certificate authority is within a field of the authorization certificate or the authorization ticket.

19. A computer-readable medium for storing instruction code, which, when executed by a processor of an Intelligent Transportation System (ITS) transmitter entity, causes the ITS transmitter entity to: An ITS message is generated at the ITS transmitting entity; The ITS message is augmented using an integrity report generated by an integrity detection function within the ITS transmitting entity to create an augmented ITS message. The integrity detection function checks the network security posture of the transmitter of the ITS transmitting entity. The integrity report is generated by performing an integrity check of the ITS transmitting entity by the integrity detection function at the ITS transmitting entity, and the network security posture includes information for detecting systems that lack or have outdated security protection mechanisms. The augmented ITS message is signed using a private key associated with an authorization certificate or authorization ticket, the authorization certificate or authorization ticket including an assurance indication from an audit certificate authority indicating that the integrity detection function is secure; as well as Send the signed, expanded ITS message to the ITS receiving entity.

Images