Method and system for handling dynamic cyber security posture of v2x entities

Abstract

A method at a network element, the method comprising receiving at the network element at at least one message, the at least one message being one or both of the following: an update status information message from an update server; and an anomaly detection status information message from an anomaly detection server; determining a dynamic cybersecurity posture indication for an intelligent transportation system entity based on receiving the at least one message; and providing the dynamic cybersecurity posture indication for the intelligent transportation system entity to a registration authority, wherein the dynamic cybersecurity posture indication can be included in a certificate associated with the intelligent transportation system 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 enhanced systems or applications are being developed for vehicle-to-infrastructure and vehicle-to-portable scenarios.

[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 It is a graph that shows the network security level over time based on the occurrence of an event;

[0009] Figure 4 It is a data flow diagram that shows the determination and provision of dynamic network security posture to V2X entities;

[0010] Figure 5 This is a data flow diagram illustrating an alternative embodiment of determining and supplying dynamic cybersecurity posture to V2X entities;

[0011] Figure 6 This is a data flow diagram illustrating the addition of V2X entities to the certificate revocation list based on the network security posture from the update server;

[0012] Figure 7 This is a data flow diagram illustrating the addition of V2X entities to the certificate revocation list based on the network security posture from the anomaly detection server; and

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

[0014] This disclosure provides a method at a network element, the method comprising receiving at the network element at at least one message, the at least one message being one or both of the following: an update status information message from an update server; and an anomaly detection status information message from an anomaly detection server; determining a dynamic cybersecurity posture indication for an intelligent transportation system entity based on receiving the at least one message; and providing the dynamic cybersecurity posture indication for the intelligent transportation system entity to a registration authority, wherein the dynamic cybersecurity posture indication can be included in a certificate associated with the intelligent transportation system entity.

[0015] This disclosure also provides a network element comprising: a processor; and a communication subsystem, wherein the network element is configured to: receive at least one message at the network element, the at least one message being one or both of the following: an update status information message from an update server; and an anomaly detection status information message from an anomaly detection server; determine a dynamic cybersecurity posture indication for an intelligent transportation system entity based on receiving the at least one message; and provide the dynamic cybersecurity posture indication for the intelligent transportation system entity to a registration authority, wherein the dynamic cybersecurity posture indication can be included in a certificate associated with the intelligent transportation system entity.

[0016] This disclosure also provides a computer-readable medium for storing instruction code that, when executed by a processor of a network element, causes the network element to: receive at least one message, the at least one message being one or both of the following: an update status information message from an update server; and an anomaly detection status information message from an anomaly detection server; determine a dynamic cybersecurity posture indication for an intelligent transportation system entity based on receiving the at least one message; and provide the dynamic cybersecurity posture indication for the intelligent transportation system entity to a registration authority, wherein the dynamic cybersecurity posture indication can be included in a certificate associated with the intelligent transportation system entity.

[0017] When determining whether to take action on a received V2X message, a V2X entity (such as the vehicle receiving the message) may need to determine whether the message can be trusted. The level of trust required for a message can vary depending on its type. For example, safety-critical use cases may require a higher level of trust, such as an emergency braking warning, where the receiving vehicle may need to determine whether it should act on the message content and apply the brakes forcefully, even without other confirmatory information.

[0018] One challenge in determining trustworthiness for receiving V2X entities is whether the sending V2X entity is securely connected to the network. In other words, determining trustworthiness may require discovering that the sending V2X entity has not been compromised, sometimes referred to as "being hacked."

[0019] In one scenario, a V2X entity implementation may consist of an operating software component and a separate secure key storage component. Therefore, if the former is compromised while the latter remains intact, for example, because the latter is designed to be more robust / network secure, the V2X entity may be forced to send illegitimate V2X messages / data with secure signatures.

[0020] Therefore, this disclosure uses network security posture to determine whether the sender or transmitter of a V2X message is trustworthy, where “network security posture” is defined from a network security perspective as the posture or integrity of the sender or transmitter of a V2X message.

[0021] This disclosure relates to V2X, a feature that provides messaging communication 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, and the terms are used interchangeably.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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).

[0027] 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).

[0028] 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).

[0029] 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).

[0030] 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.

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

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

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

[0034] Example of certificate messaging Figure 2Describe 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.

[0035] 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.

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

[0037] 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.

[0038] 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 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.

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

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] As mentioned above, a 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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 2As shown, each V2X message sent by ITS-S includes the certificate or its hash, so the guarantee level is also sent.

[0055] 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.

[0056] 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 Communications Alliance, entitled "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 C2X stations. Key features include five trust levels designated as Trust Assurance Levels (TAL) 0 to TAL4, with TAL4 being the highest trust assurance level. The lowest acceptable TAL for an ITS station is TAL2. According to ETSI TS 103 097, each TAL maps to a subject assurance representation.

[0057] 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 perception 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.

[0058] 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.

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

[0060]

[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 Cybersecurity Assurance Level (CAL) as defined in Table 2 below.

[0066]

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

[0068] Furthermore, ISA / IEC 62443-3-3: "System Security Requirements and Security Levels" provides a framework for addressing and mitigating current and future security vulnerabilities in Industrial Automation and Control Systems (IACS). It defines several "Security Levels" (SLs), as follows:

[0069] •SL 1: Prevent temporary or accidental violations

[0070] •SL 2: Preventing intentional violations using simple methods with low resources, general skills, and low motivation.

[0071] •SL 3: Prevent intentional violations using sophisticated methods with moderate resources, IACS-specific skills, and moderate motivation.

[0072] •SL 4: Prevent intentional violations using sophisticated methods with expanded resources, IACS-specific skills, and high motivation.

[0073] Both CAL and SL demonstrate security guarantees based on entity-based design and development. In each case, the level of the entity is static over time.

[0074] Cybersecurity Situation

[0075] As used in this article, cybersecurity posture is a measure or level of security / cybersecurity. The cybersecurity posture of an entity (such as software, hardware, or a combination of hardware and software) is inherently dynamic and is generally considered to decrease over time due to the likelihood of the entity being threatened over time. This decrease over time can also be referred to as a “window of opportunity.” The decline in cybersecurity posture over time is often unpredictable and can therefore be non-linear. An entity's cybersecurity posture can also increase, and this typically occurs when the entity or its components (such as software and / or hardware components) are updated.

[0076] For example, now refer to Figure 3 , Figure 3 This describes an example of an entity's cybersecurity posture over time as certain example events occur.

[0077] In Event 310, i.e., Time 0 (e.g., when the entity completes development and validation and then deploys to end users), the cybersecurity posture of the example entity is considered to be high.

[0078] Between Events 310 and 320, cybersecurity was considered to be declining at a steady rate as the probability of an entity being successfully hacked / cracked using one or more unknown vulnerabilities increased over time. This can also be referred to as a "window of opportunity."

[0079] In Event 320, a vulnerability was discovered and disclosed. However, this vulnerability has not yet been proven to be a vulnerability.

[0080] Between Events 320 and 330, the cybersecurity posture may decline more rapidly than between Events 310 and 320, due to the possibility of successfully exploiting known vulnerabilities and compromising entities with one or more unknown vulnerabilities.

[0081] In Event 330, the known vulnerability was proven and / or detected to be used in other similar entities.

[0082] Between events 330 and 340, the decline in cybersecurity posture can be faster than between events 320 and 330 or between events 310 and 320. This is because of the probability of successfully exploiting known, verified vulnerabilities and the probability of using one or more unknown vulnerabilities to compromise an entity.

[0083] In Incident 340, the entity was hacked or compromised. For example, the attacker could successfully exploit both known and unknown vulnerabilities.

[0084] Between Event 340 and Event 350, the cybersecurity posture was considered low or insecure due to the successful cracking or compromise of Event 340.

[0085] In Event 350, a hardware and / or software update is performed on the entity or a component of the entity to mitigate or resolve a known vulnerability. In Event 360, the update immediately restores the entity's cybersecurity posture to its original level.

[0086] Following the 360 ​​incident, the cybersecurity posture was once again considered to be declining at a steady pace, as the probability of an entity being successfully hacked or compromised using one or more unknown vulnerabilities increased over time until another incident occurred.

[0087] Therefore, according to Figure 3 For example, an entity's cybersecurity posture is not static, but changes over time as events occur.

[0088] Based on the above, events can include updates and / or anomaly detection. Specifically, endpoints such as V2X entities can receive updates from entities in the network, including update servers. Updates can include firmware and / or software updates, which can be applied to one or more of the following options: V2X entities, ITS-S, OBU, ECU, infotainment system, electronic instrument cluster, digital dashboard, vehicle components, in-vehicle systems, UE (user equipment), etc. Such updates can be downloaded by the endpoint or uploaded to the endpoint via various media, including wired or wireless connections. Wired connections can include, but are not limited to, Universal Serial Bus (USB), Ethernet, RS-232, charging connections, etc. Wireless connections can include, but are not limited to, cellular connections, Wi-Fi, wireless chargers, Bluetooth, etc.

[0089] Example update solutions include those provided by the Open Mobility Alliance (OMA) Device Management (DM) specification and those provided by the UPTANE Alliance as a "live-time standard for design and implementation." Receiving and installing software updates at endpoints can improve or mitigate vulnerabilities, thereby enhancing or increasing their cybersecurity posture.

[0090] 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).

[0091] 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.

[0092] 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:

[0093] • 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.

[0094] The purpose of NEA is to assess these endpoints to determine whether they comply with security policies so that corrective actions 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 actions to be taken.

[0095] • 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…

[0096] …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.

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

[0098] Based on the above, the existing guarantee levels conveyed in V2X messaging do not take into account dynamic network security posture. Specifically, the existing guarantee levels in V2X messaging only represent static levels, which are assumed to be valid for the lifetime of the V2X entity receiving these levels.

[0099] However, as Figure 3 As mentioned, the cybersecurity posture of endpoints may deteriorate over time. Therefore, according to some embodiments of this disclosure, a more dynamic mechanism is provided to better account for the extent to which cybersecurity posture deteriorates over time. This dynamic cybersecurity posture provides a more accurate measure of cybersecurity posture. Ensuring that only V2X entities deemed to have an acceptable level of cybersecurity posture can participate in the V2X system helps ensure the proper functioning of the V2X system and can reduce the number of misbehaving V2X entities in the V2X system.

[0100] Furthermore, there is currently no mechanism for determining the cybersecurity posture of a V2X entity and refusing to assign a new certificate to it if the entity's cybersecurity posture is deemed unacceptable.

[0101] According to other embodiments of this disclosure, methods and systems are provided for removing V2X entities from a V2X system in the event of a newly detected poor network security posture. Specifically, when the network security posture of a V2X entity suddenly declines, for example when a new vulnerability / exploit or anomaly is discovered and / or proven, or when an available update to mitigate the exploit is provided, there is currently no explicit mechanism to remove a V2X entity whose network security posture has declined from the V2X system until the V2X entity has been updated / patched / upgraded, and the situation can be notified to the V2X system.

[0102] These and other embodiments are described below. In the embodiments below, the examples are described according to the European Cooperative Credential Management System (CCMS). However, this is provided for illustrative purposes only and is not intended to be limiting. Similar concepts can be applied to any other type of Security Credential Management System (SCMS), including but not limited to SCMS systems based on the US Collision Avoidance Measurement Partners (CAMP), Chinese SCMS systems, and other options.

[0103] Furthermore, while all the solutions below focus on cybersecurity posture, such solutions are also applicable to other disciplines or posture types, including but not limited to: functional security; security of intended functions (SOTIF), etc.

[0104] Determine and indicate a reliable dynamic cybersecurity posture

[0105] According to one embodiment, methods and systems are provided for determining and indicating a trusted dynamic network security posture and indicating V2X entity updates required when a V2X entity attempts to obtain a V2X certificate. In this embodiment, a first V2X entity sends a V2X message including a certificate, wherein the certificate includes Dynamic Network Security Posture Information (DCPI), to a second V2X entity. Such V2X messages may include, but are not limited to, Basic Security Messages (BSM), Collaborative Awareness Messages (CAM), Collective Awareness Messages (CPM), etc.

[0106] Upon receiving a certificate including the DCPI, the second V2X entity can take appropriate action based on the DCPI. Such actions could include discarding or ignoring the V2X message, applying the vehicle's brakes, displaying instructions to vehicle occupants (e.g., the driver), etc. In this case, the second V2X entity trusts the value of the received DCPI because the DCPI is included in a certificate signed by a CA trusted by the second V2X entity. For example, the certificate could be signed by an authority authorized by the V2X system.

[0107] The second V2X entity can take appropriate action based on the trust level determined using the received DCPI. The second V2X entity can assign a higher level of trust to V2X messages containing a DCPI, which includes a date / timestamp value indicating the most recent date, and assign a lower level of trust to V2X messages containing a DCCI, which includes a date / timestamp value indicating a later / further date.

[0108] For example, if a receiving V2X entity receives a first V2X message containing a DCPI with a date / time stamp field indicating a date / time less than one month ago, and the receiving V2X entity also receives a second V2X message containing a DCPI with a date / time stamp field indicating a date / time more than one year ago, the receiving V2X entity can assign a higher level of trust to the first V2X message than to the second V2X message.

[0109] Alternatively, or in addition to the above, the second V2X entity may attribute a higher level of trust to a V2X message containing a DCPI, which includes an assurance level or network security posture level of a certain value or within a certain range. For example, if the receiving V2X entity receives a first V2X message containing a DCPI indicating an assurance level or network security posture level less than or equal to 4, and also receives a second V2X message containing a DCPI indicating an assurance level or network security posture level greater than 4, then the receiving V2X entity may assign a higher level of trust to the first V2X message than to the second V2X message.

[0110] Obtain cybersecurity posture information about V2X entities

[0111] To obtain a cybersecurity posture assessment, it is necessary to trust various entities. Assume the following entities have trust relationships: V2X entity and update server; V2X entity and anomaly detection server; update server and V2X entity Cybersecurity Posture Assessment Server (CPDS); anomaly detection server and V2X entity CPDS.

[0112] Now for reference Figure 4 .exist Figure 4 In the embodiments, V2X entity 410 is shown together with other network entities, including registration authority 412, V2X entity CPDS 414, authorization authority 416, update server 417, anomaly detection server 418, and second V2X entity 419.

[0113] Figure 4An example illustrates a data stream, with messages shown in dashed lines to represent optional or conditional message streams.

[0114] exist Figure 4 In this embodiment, V2X entity 410 sends an authorization request 420 to an authorization authority 416. The authorization request 420 includes service parameters and may include network security data.

[0115] Upon receiving authorization request 420, the authorizing authority 416 sends authorization verification request message 422 to the registration authority 412. The authorization verification request includes service parameters, and may include cybersecurity data if it is provided in the authorization request 420.

[0116] In a first embodiment, in response to receiving an authorization verification request message 422, the registration authority 412 may retrieve, for example, from a storage medium, or determine one or more of the following: the DCPI of V2X entity 410; V2X entity 410 has no identifiable DCPI; or the Dynamic Network Security Posture (DCP) of V2X entity 410 is too low for the V2X system. In this case, the determination may include using network security data associated with V2X entity 410. For example, such network security data may be received in the authorization verification request message 422, retrieved from a database, or received from other entities, such as directly from V2X entity 410, etc.

[0117] Because of this retrieval, in some cases, the registry 412 can skip messages 430, 432, 434, 440, 442 and 450 described below and proceed directly to message 460.

[0118] In another scenario, the following steps may occur. V2X entity 410 may send a message (not shown) including cybersecurity data (e.g., a registration request) to registration authority 412. Registration authority 412 receives the message and stores the received cybersecurity data, or determines the DCPI of V2X entity 410, or determines that V2X entity 410 has no identifiable DCPI, and determines based on the received cybersecurity data that the DCP of V2X entity 410 is too low for the V2X system. Registration authority may send a response message (such as a registration response) to V2X entity 410, and V2X entity 410 receives the message (not shown).

[0119] In another embodiment, in response to receiving the authorization verification request message 422, the registration authority 412 may send a network security posture determination (CPD) request message 430 to the V2X entity CPDS 414. Message 430 may include network security data, which may be received in message 422, searched in a database, received from another entity, etc. Message 430 may also include the identity / identifier of the V2X entity 410 used to identify the V2X entity 410 to the update server 417. For example, such an identity could be a V2X entity ID, an update client ID, etc. In other cases, the registration authority 412 may use the identity / identifier of the V2X entity 410 used to identify the V2X entity 410 to the V2X entity CPDS 414, and this identity / identifier is not an identity / identifier used in other V2X systems to enhance the privacy of the V2X entity 410.

[0120] In response to receiving the CPD request message 430, the V2X entity CPDS 414 can do one of two things. In the first case, the V2X entity CPDS can retrieve, for example, from storage media, or determine one or more of the following: the DCPI of the V2X entity 410; the V2X entity 410 has no identifiable DCPI; or the Dynamic Network Security Posture (DCP) of the V2X entity 410 is too low for the V2X system. In this case, determination may include using network security data associated with the V2X entity 410. For example, such network security data may be received in the CPD message 430, retrieved from a database, or received from other entities, etc.

[0121] In the second scenario, V2X entity CPDS 414 can send a V2X entity update status request message 432 to update server 417. Message 432 may include the identity / identifier of V2X entity 410 used to identify V2X entity 410 to update server 4107. For example, such an identifier could be a V2X entity ID, update client ID, etc. In other scenarios, V2X entity CPDS 414 may use the identity / identifier of V2X entity 410 used to identify V2X entity 410 to update server 417, and this identity / identifier is not used in other V2X systems, to enhance the privacy of V2X entity 410.

[0122] Update server 417 may include functionality for identifying a V2X entity based on the received V2X entity ID. For example, update server 418 may include a link seed value to identify the V2X entity based on the received anonymous certificate. Other options are also possible.

[0123] In response to receiving the V2X entity update status request message 432, the update server 417 sends a V2X entity upgrade status response message 434 to the V2X entity CPDS 414. Message 434 contains the update data of the V2X entity associated with V2X entity 410. The characteristics of the V2X entity update data are described below.

[0124] Update server 417 can retrieve information including V2X entity update data from local storage, other entities, or a combination of both.

[0125] Furthermore, in response to receiving the CPD request message 430, the V2X entity CPDS 414 may send a V2X entity anomaly detection status request message 440 to the anomaly detection server 418. Message 440 may include the identity / identifier of the V2X entity 410 used to identify the V2X entity 410 to the anomaly detection server 418. For example, such an identity could be a V2X entity ID, anomaly detection client ID, etc. In other cases, the V2X entity CPDS 414 may use the identity / identifier of the V2X entity 410 used to identify the V2X entity 410 to the anomaly detection server 418, but this identity / identifier is not an identity / identifier used in other V2X systems to enhance the privacy of the V2X entity 410.

[0126] Furthermore, the anomaly detection server 418 may include functionality for identifying a V2X entity based on the received V2X entity ID. For example, the anomaly detection server 418 may include a link seed value to identify the V2X entity based on the received anonymous certificate. Other options are also possible.

[0127] In response to receiving message 440, the anomaly detection server 418 sends a V2X entity anomaly detection status response message 442 back to the V2X entity CPDS 414. Message 442 contains V2X entity anomaly detection data associated with V2X entity 410, as described below. The anomaly detection server 418 may retrieve information including the V2X entity anomaly detection data from local storage, from another entity, or a combination of both.

[0128] In response to receiving one or both of messages 434 and 442, V2X entity CPDS 414 determines one or more of the following: the DCPI of V2X entity 410; V2X entity 410 has no identifiable DCPI; or the DCP of V2X entity 410 is too low for the V2X system. The determination may include one or more of the following: using V2X entity update data received in message 434, V2X entity anomaly detection data received in message 442, and using network security data associated with V2X entity 410. Such network security data may be received in CPD request 430, may be searched in a database, may be retrieved from another entity, etc.

[0129] V2X entity CPDS 414 sends a CPD response message 450 to the registration authority 412. Message 450 may include one or more of the following: DCPI; an indication that there is no defined DCPI (hereinafter referred to as "No DCPI Indication"); and an indication that the DCP of V2X entity 410 is too low for the V2X system (hereinafter referred to as "DCP Too Low Indication").

[0130] In response to the registration authority 412 receiving the CPD response 450, or based on the registration authority 411 retrieving or determining the DCPI, the absence of the DCPI, or the DCPI being too low, the registration authority may send an authorization verification response message 460 to the authorization authority 416. Message 460 includes the DCPI received in the CPD response 450 or determined according to the authorization verification request 422, the absence of a DCPI indication, and / or the DCPI being too low indication.

[0131] Authorizing authority 416 receives message 460 and sends an authorization response 470 to V2X entity 410, which may include result parameters. Response 470 includes the DCPI, no DCPI indication, and / or low DCP indication retrieved by the authorizing authority or received in the authorization verification response message 460. The DCPI, no DCPI indication, and / or low DCP indication may be included in the authorization ticket / certificate, and / or the no DCP indication and low DCP indication may be included as values ​​in the result parameters.

[0132] If V2X entity 410 does not receive a DCPI (e.g., a DCPI is not present in one or more received certificates) or receives a DCPI that the V2X entity determines indicates a low or poor DCP; does not receive a DPI indication; and / or receives a DCP too low indication, then V2X entity 410 may send a "Request Needed Updates" message 472 to update server 417. This can be used to initiate the download of an update for the V2X entity to improve / correct / enhance the DCP of V2X entity 410.

[0133] Alternatively or concurrently, V2X entity 410 may indicate to vehicle occupants that a V2X entity update is required. This indication may be, for example, an audible sound, the illumination of a light on the dashboard, information displayed on a display unit, an audible instruction emitted through speakers within the vehicle, or other indications on the vehicle's infotainment system, dashboard, or other signaling mechanisms. For instance, this could signal occupants to begin the update process.

[0134] Once the update is performed (e.g., manually initiated based on request 472, such as by a vehicle occupant), V2X entity 410 can repeat... Figure 4 The message passing in the V2X system is used to retry or retrieve / obtain a new certificate for use in the V2X system.

[0135] If V2X entity 410 receives a DCPI, such as in a certificate, then V2X entity 419 can send V2X message 480 to V2X entity 419, which includes the DCPI received in message 470. For example, such V2X message 480 may include a Basic Security Message (BSM), a Cooperation Awareness Message (CAM), a Collective Perception Message (CPM), etc.

[0136] In response to receiving a V2X message 480 including a DCPI, V2X entity 419 can use the DCPI to determine the trust or integrity level of the received V2X message, as described below. After determining the trust level of the received V2X message 480, V2X entity 419 can perform specific actions based on the determined trust level of the received V2X message. For example, V2X entity 419 can process the V2X message, discard / ignore / unnotify the V2X message, perform V2X entity-related operations in the vehicle, such as displaying a warning (e.g., a message or icon) to the user, etc., or perform other actions.

[0137] Any entity in a V2X system can determine its trust level (or network security posture or network security integrity), including but not limited to V2X entities, CPCS servers, registration authorities, and authorizing authorities.

[0138] The update server can be an OMA DM server or an Uptane server. The anomaly detection server can be an IETF NEA server, such as those defined in IETF RFC 5209. V2X entity CPDS can include an IETF NEA client, such as those defined in IEEETF RFC 5209. V1X entity 410 can include OMA DM client and / or Uptane client functionality.

[0139] In some embodiments, the authorizing authority 416 may include a registration authority and / or a certificate authority.

[0140] also, Figure 4 One or more entities shown can be combined with each other. Furthermore, Figure 4 The data stream shown can be executed in a different order than that shown.

[0141] also, Figure 4 The message names shown are just examples, and different message names can be used.

[0142] about Figure 5 Alternative embodiments are shown. In particular, Figure 5 The embodiment illustrates the message flow between V2X entity 510, registration authority 512, V2X entity CPDS 514, authorization authority 516, update server 517, anomaly detection server 518 and V2X entity 519.

[0143] and Figure 4 The implementation is the same as the previous one. Figure 5 In the embodiments, dashed lines represent optional or conditional message flows.

[0144] exist Figure 5 In this embodiment, V2X entity CPDS 514 can be retrieved from storage media or other storage, or one or more of the following can be determined: the DCPI of V2X entity 510; V2X entity 510 has no identifiable DCPI; or the DCPI of V2X entity 510 is too low for the V2X system. Determination may include using network security data received in a V2X entity 510 message or data retrieved from a database.

[0145] Optionally, V2X entity CPDS 514 may send a V2X entity update status request message 520 to update server 517. Message 520 may include the identity / identifier of V2X entity 510 that identifies the V2X entity to update server 5127. For example, such identity may be a V2X entity ID, update client ID, etc. In other cases, V2X entity CPDS 514 may use the identity / identifier of V2X entity 510 that identifies V2X entity 510 to update server 517, and this identity / identifier is not the identity / identifier used in other V2X systems to enhance the privacy of V2X entity 510.

[0146] Update server 517 may include functionality for identifying a V2X entity based on the received V2X entity ID. For example, update server 517 may include a link seed value to identify the V2X entity based on the received anonymous certificate. Other options are also possible.

[0147] Update server 517 may send V2X entity update status notification message 522 to V2X entity CPDS 514. In some cases, message 522 may respond to receiving V2X entity status request message 520, but it does not have to be. Message 522 contains V2X entity update data associated with V2X entity 510. The characteristics of the V2X entity data are as follows.

[0148] Update server 517 can retrieve information including V2X entity update data from local storage, another entity, or a combination of both.

[0149] V2X entity CPDS 514 can also send a V2X entity anomaly detection status request message 530 to anomaly detection server 518. Message 530 may include the identity / identifier of V2X entity 510 that identifies V2X entity 510 to anomaly detection server 518. For example, such identity could be a V2X entity ID, anomaly detection client ID, etc. In other cases, V2X entity CPDS 514 may use the identity / identifier of V2X entity 510 that identifies V2X entity 510 to anomaly detection server 518, and this identity / identifier is not an identity / identifier used in other V2X systems to enhance the privacy of V2X entity 510.

[0150] Furthermore, the anomaly detection server 518 may include functionality for identifying a V2X entity based on the received V2X entity ID. For example, the anomaly detection server 518 may include a link seed value to identify the V2X entity based on the received anonymous certificate. Other options are also possible.

[0151] The anomaly detection server 518 sends a V2X entity anomaly detection status notification message 532 to the V2X entity CPDS 514. In some cases, message 532 may be sent in response to the receipt of message 530, but in other cases, message 530 may not be sent.

[0152] Message 532 contains V2X entity anomaly detection data associated with V2X entity 510, as described below. The V2X entity anomaly detection data may also contain the identity / identifier of V2X entity 510, which identifies V2X entity 510 to anomaly detection server 518. Anomaly detection server 518 may retrieve information including the V2X entity anomaly detection data from local storage, from another entity, or a combination of both.

[0153] Registry 512 may optionally send a CPD request message 540 to V2X entity CPDS 514. Message 540 may include network security data, which can be looked up in a database, received in the message from another entity (e.g., V2X entity 510), etc. Message 540 may also include the identity / identifier of V2X entity 510 that identifies V2X entity 510 to V2X entity CPDS 514. For example, such an identity could be a V2X entity ID, an update client ID, an anomaly detection client ID, etc. In other cases, Registry 512 may use the identity / identifier of V2X entity 510 that identifies V2X entity 510 to V2X entity CPDS 514, where this identity / identifier is not an identity / identifier used in other V2X systems to enhance the privacy of V2X entity 512.

[0154] If the registration authority 512 determines one or more of the following: the DCPI of V2X entity 510, V2X entity 510 has no measurable DCPI, or the DCP of V2X entity 610 is too low for the V2X system, wherein the determination includes using network security data associated with V2X entity 510 received in a message from another entity (the other entity is V2X entity 510), then in an alternative, the following steps may occur. Specifically, V2X entity 510 may send a message (not shown) including network security data (e.g., a registration request) to the registration authority 512. The registration authority 512 receives the message and stores the received network security data, or determines the DCPI of V2X entity 510, or determines that V2X entity 510 has no measurable DCPI, and determines that the DCP of V2X entity 510 is too low for the V2X system based on the received network security data. The registration authority may send a response message (such as a registration response) to V2X entity 510, and V2X entity 610 receives the message (not shown).

[0155] In response to receiving one or more of messages 522, 532, and 540, V2X entity CPDS 514 determines one or more of the following: the DCPI of V2X entity 510; V2X entity 510 has no determineable DCPI; or the DCP of V2X entity 510 is too low for the V2X system. The determination may include one or more of the following: using V2X entity update data received in message 522, V2X entity anomaly detection data received in message 532, and using network security data associated with V2X entity 510. Such network security data may be received in CPD request 540, may be searched in a database, may be retrieved from another entity, etc.

[0156] V2X entity CPDS 514 sends CPD notification message 542 to the registration authority 512. Message 542 may include one or more of the following: DCPI; "No DCPI indication"; and "DCP too low indication".

[0157] When the registration authority 512 receives message 542, it can store one or more of the received DCPI, no DCPI indication, and DCP low indication.

[0158] V2X entity 510 sends an authorization request 550 to the authorizing authority 516. The authorization request 550 includes service parameters and may include network security data.

[0159] Upon receiving authorization request 550, the authorizing authority 516 sends authorization verification request message 552 to the registration authority 512. The authorization verification request includes service parameters, and may include cybersecurity data if such data is provided in the authorization request.

[0160] Registration authority 512 retrieves (e.g., from storage) one or more previously stored DCPI, no DCPI, and low DCP indicators. Registration authority 512 may use network security data (if available) to verify one or more previously stored DCPI, no DCPI, and low DCP indicators, for example, to determine if they are still valid. If verification fails, for example, if a previously stored indicator is determined to be no longer valid, registration authority 512 may send a CPD request 540 and may receive a CPD notification 542 as described above, or may perform... Figure 4 One or more of messages 430, 432, 434, 440, 442 and 450.

[0161] Registration authority 512 sends authorization verification response message 554 to authorization authority 516. Authorization verification response message 554 includes DCPI, no DCPI indication and / or DCP too low indication.

[0162] Authorizing authority 516 receives message 554 and sends an authorization response 556 to V2X entity 510, which may include result parameters. Response 556 includes the DCPI, no DCPI indication, and / or low DCP indication received in the authorization verification response message 554. The DCPI, no DCPI indication, and / or low DCP indication may be included in the authorization invoice / certificate, and / or the no DCP indication and low DCP indication may be included as values ​​in the result parameters.

[0163] If V2X entity 510 does not receive a DCPI (e.g., no DCPI is received in one or more certificates), or receives a DCPI that the V2X entity determines indicates a low or poor DCP; receives a no DPI indication; and / or receives a DCP too low indication, then V2X entity 510 may send an "Update Request Required" message 560 to update server 517. This can be used to initiate a download of an update for the V2X entity to improve / correct / enhance the DCP of V2X entity 510.

[0164] Alternatively or concurrently, V2X entity 510 may indicate to vehicle occupants that a V2X entity update is required. This indication may be, for example, an audible sound, the illumination of a light on the dashboard, information displayed on a display unit, an audible instruction emitted through speakers within the vehicle, or other indications on the vehicle's infotainment system, dashboard, or other signaling mechanisms. For instance, this could signal occupants to begin the update process.

[0165] Once the update is executed (e.g., based on request 560, manually initiated, such as by a vehicle occupant), V2X entity 510 can repeat... Figure 5 The message passing in the V2X system is used to retry or retrieve / obtain a new certificate for use in the V2X system.

[0166] If V2X entity 510 receives a DCPI, such as in a certificate, then V2X entity 151 can send a V2X message 570 to V2X entity 519, which includes the received DCPI. For example, such a V2X message 570 could include a Basic Security Message (BSM), a Cooperation Awareness Message (CAM), a Collective Perception Message (CPM), etc.

[0167] In response to receiving a V2X message 570 including a DCPI, V2X entity 519 may use the DCPI to determine a specific trust or integrity level of the received V2X message, as described below. V2X entity 519 determines the specific trust level of the received V2X message 570 and performs a specific action. For example, V2X entity 519 may process the V2X message, discard / ignore / unnoticed discard the V2X message, perform V2X entity-related operations in the vehicle, such as displaying a warning (e.g., a message or icon) to the user, etc., or perform other actions.

[0168] Any entity in a V2X system can determine its trust level (or network security posture or network security integrity), including but not limited to V2X entities, CPCS servers, registration authorities, and authorizing authorities.

[0169] The update server can be an OMA DM server or an Uptane server. The anomaly detection server can be an IETF NEA server, such as those defined in IETF RFC 5209. V2X entity CPDS can include an IETF NEA client, such as those defined in IEEETF RFC 5209. V1X entity 510 can include OMA DM client and / or Uptane client functionality.

[0170] In some embodiments, the authorizing body 516 may include a registration authority and / or an authorized certificate authority.

[0171] also, Figure 5 One or more entities shown can be combined with each other. Furthermore, Figure 5 The data stream shown can be executed in a different order than that shown.

[0172] also, Figure 5 The message names shown are just examples, and different message names can be used.

[0173] based on Figure 4 and Figure 5 The first V2X entity can retrieve a certificate including the DCPI by sending a first message to the authorizing authority, and the authorizing authority receives the first message. The first V2X entity may include data / information about its cybersecurity posture in the first message, referred to herein as "cybersecurity data". In some cases, cybersecurity data can be determined by the V2X entity using existing solutions, such as endpoint authentication as described in IETF RFC 5209, etc.

[0174] In response to receiving the first message, the authorizing authority sends a second message to the registrar. The second message may include cybersecurity data, such as cybersecurity data received from a first V2X entity identified by the authorizing authority. In response to receiving the second message, the registrar then determines the DCPI of the first V2X entity, for example, by using the received cybersecurity data or by sending a third message to the V2X entity's CPDS. The third message may include cybersecurity data that the registrar determines can be received from the authorizing authority.

[0175] Authorized or registered authorities may use received cybersecurity data (such as data received from an authorized authority, data received from a V2X entity, or data determined by themselves) to determine the DCPI. V2X entity CPDS may use one or more of the following to determine the DCPI: received cybersecurity data that may be received from or determined by an authorized or registered authority; V2X entity update data that may be received from an update server; and V2X entity anomaly detection data that may be received from an anomaly detection server.

[0176] V2X Entity CPCS can obtain V2X entity update data by receiving messages from the update server, and it can also obtain V2X entity anomaly detection data by receiving messages from the anomaly detection server.

[0177] The update server can send a message containing V2X entity update data to the V2X entity CPDS, which can be responded to by receiving a request message. The anomaly detection server can send a message containing V2X entity anomaly detection data to the V2X entity CPDS, which can be responded to by receiving a request message.

[0178] The authorization server, registration server, or V2X entity CPDS can determine that no DCPI is determinable, for example, if there is no information or insufficient information, or if the network security posture of the first V2X entity is determined to be too low for the V2X entity to participate in the V2X system.

[0179] After determining the DCPI, determining that no DCPI can be determined, or determining that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system, the V2X entity CPDS sends a message to the registry authority. This message includes the determined DCPI, an indication that no DCPI can be determined, and / or an indication that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system. The V2X entity CPDS may, in response to receiving a request message, send a message including the determined DCPI, an indication that no DCPI can be determined, and / or an indication that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system.

[0180] After determining the DCPI, determining that no DCPI can be determined, determining that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system, or receiving a message from the V2X entity's CPDS including a DCPI, an indication that no DCPI can be determined, and / or an indication that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system, the registration authority sends a response message to the authorization authority, which includes the determined or received DCPI, an indication that no DCPI can be determined, and / or an indication that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system.

[0181] After determining the DCPI, determining that no DCPI can be determined, determining that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system, or receiving a message from the V2X entity's CPDS or registration authority including a DCPI, an instruction that no DCPI can be determined, and / or an instruction that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the V2X system, the authorizing authority then sends a response message to the first V2X entity, which includes the determined or received DCPI, an instruction that no DCPI can be determined, and / or an instruction that the cybersecurity posture of the first V2X entity is too low to allow the V2X entity to participate in the first V2X entity's V2X system.

[0182] The DCPI included in the response message sent to the first authorizing authority and / or the response message sent to the V2X entity may (and preferably) be included in the authorization ticket / certificate. Indications in the response message from the first authorizing authority and / or the V2X entity regarding the absence of a DCPI and / or regarding the first V2X entity's cybersecurity posture being too low for the V2X entity to participate in the V2X system may include values ​​from the result code field, such as the response code.

[0183] The first V2X entity receives a response message from the authorization server. This response message may include a DCPI (Distributed Digital Pricing Index), an indication that no DCPI can be determined, or an indication that the first V2X entity's cybersecurity posture is too low for it to participate in the V2X system. In response to receiving an indication that no DCPI can be determined and / or an indication that the first V2X entity's cybersecurity posture is too low for it to participate in the V2X system, the first V2X may: request a new V2X entity update, for example, from an update server; and / or provide vehicle occupants with an indication that a V2X entity update is needed, including emitting an audible sound, illuminating lights (e.g., on the dashboard), displaying a message or icon on a display unit (e.g., on the infotainment system, on the instrument panel), etc.

[0184] The first V2X entity can retrieve / obtain a new certificate from the Authorisation Authority at any time due to one or more of the following: the first V2X entity determines that it has too few or no valid certificates to use in the V2X system; the first V2X entity detects that one or more certificates are included in / indicated on the Certificate Revocation List (CRL); a new V2X entity update has been installed / applied in the first V2X entity; a timer expires; etc.

[0185] Characteristics of network security data

[0186] According to the above Figure 4 and Figure 5In some embodiments, network security data may include one or more of the following from a V2X entity.

[0187] In the first scenario, network security data may include V2X entity identities / identifiers, such as canonical IDs; certificates, including certificates defined by IEEE 1609.2, certificates defined by X.509, admission certificates, pseudonyms / application certificates, authorization tickets; link seeds / values; Internet Protocol (IP) addresses; hostnames (which may include domain names), Uniform Resource Locators (URLs), Uniform Source Indicators (URIs), Network Access Identifiers (NAIs), access tokens, etc.

[0188] In another scenario, cybersecurity data may include indications of the manufacturer, operating system, and / or application of a V2X entity or its components, collectively referred to as a “component list” or “bill of materials.”

[0189] In another scenario, cybersecurity data may include an indication of the version of one or more components, such as software, firmware, hardware, or system components.

[0190] In another scenario, cybersecurity data may include the last contact date / time with a network server (such as an update server, anomaly detection server, registry, authorization authority, etc.).

[0191] In another scenario, cybersecurity data may include the date / time of downloading / installing components (such as software, firmware, hardware, or system components). This can be referred to as the component's date / time stamp.

[0192] In another scenario, cybersecurity data may include indications of one or more mitigated / resolved vulnerabilities / cybersecurity issues (e.g., common vulnerabilities and risks (CVEs)) in a V2X entity or component.

[0193] In another scenario, cybersecurity data may include indications of one or more assurance / cybersecurity levels. This could include the Trust Assurance Level (TAL) of a C2X site, the Cybersecurity Assurance Level (CAL) as defined in ISO / SAE 21434, or the Security Level (SL) as defined in ISA / IEC 62443-3-3.

[0194] In another scenario, cybersecurity data may include indications of one or more detected anomalies.

[0195] As mentioned above, cybersecurity data can be one or a combination of the above items.

[0196] Characteristics of Dynamic Network Security Situation Information (DCPI)

[0197] To illustrate the dynamic aspects of the cybersecurity landscape, such as Figure 3 The DCPI may include one or more date / time stamp fields. These date / time stamp fields can provide the date / time: indicating when the hardware and / or software constituting the V2X entity was last audited / certified for network security, for example, reaching a certain standard or level, and may be indicated in the assuranceLevel field of the certificate, as described below; providing the latest security patches downloaded and / or installed by the V2X entity; providing the last connection of the V2X entity to the update server; providing the last connection of the V2X entity to the anomaly detection server; providing the software (component) build; and so on.

[0198] In some cases, the values ​​in the date / timestamp field of DCPI can be obfuscated to enhance the privacy of sending V2X entities. This obfuscation may require: indications of only month and year; indications of only year and quarter; indications of predefined time periods (e.g., "period 1") that indicate any time between two specific dates (e.g., between 00:00 on 2019-12-01 and 23:59 on 2020-01-08); and / or indications of relative time periods (e.g., the time the message was sent), including the past week / month / year, the past 3 months / week / year, etc.

[0199] When entities in a V2X system (such as V2X entities, V2X entity CPDS, registration authorities, authorization authorities, or other entities (hereinafter referred to as "V2X system entities")) determine the credibility of a message based on DCPI, the most recent date in the date field may take precedence over a later date and generate higher credibility compared to it, or in some cases, a later date may take precedence over the most recent date.

[0200] Alternatively or additionally, DCPI includes indications of known vulnerabilities that have been mitigated / patched in the software and / or hardware constituting the V2X entity. This may include a list of one or more indications of component identifiers (such as software identifiers (SWIN)), where each component is associated with one or more vulnerabilities that have been mitigated / patched.

[0201] When V2X system entities determine message trustworthiness based on DCPI, these values ​​can be numbers, or smaller numbers can take precedence over larger numbers, or vice versa. These values ​​can be aggregated, and the aggregated value is used to determine trustworthiness. Among other options, aggregation can include adding the numbers to produce an average.

[0202] It can also indicate the cybersecurity posture level, which can be based on each V2X entity, each component, or a combination of these. The cybersecurity posture level can include a value indicating the level, and may also have a associated date / time. This value can be numeric, alphanumeric, alphanumeric, etc.

[0203] The network security posture level can be indicated in existing fields of the V2X certificate, such as the Subject Assurance / Assurance Level field defined in IEEE 1609.2, or in a new field. The value of the network security posture level can include values ​​based on existing standards or schemes. For example, the value could be the Trust Assurance Level (TAL) of the C2X site; CAL as defined in ISO / SAE 21434; and / or SL as defined in ISA / IEC 62443-3-3.

[0204] Cybersecurity posture level values ​​can be numbers, letters, or alphanumeric. If numerical values ​​are used, smaller numbers may take precedence over larger numbers, or vice versa, when V2X system entities determine trustworthiness based on the DCPI. If more than one cybersecurity posture level is shown, all values ​​or subsets of the cybersecurity posture levels can be aggregated, and the aggregated value can then be used to determine trustworthiness. Aggregation may include adding cybersecurity posture levels to generate an average, generating a standard deviation, selecting the highest value, selecting the lowest value, using metrics and scores defined by the Common Vulnerability Scoring System (CVSS), and so on.

[0205] Alternatively, the indicated relevant cybersecurity posture level may include values ​​based on one or more of the following. In one case, the value may indicate the software version or build. In this case, information about the software details may also be provided. For example, this could be an indication of the software manufacturer / owner / creator / maintainer.

[0206] In another scenario, the value can indicate the hardware version or build. In this case, it can also provide information about the hardware details. For example, this could indicate the circuit board and / or chipset to the software manufacturer / owner / creator / maintainer.

[0207] In another scenario, the value can indicate a cybersecurity posture score.

[0208] In another case, the value can indicate a vulnerability / cybersecurity score.

[0209] The value indicating the vulnerability score can be a Cybersecurity Vulnerability Scoring System (CVSS) score, or an aggregate (and quantifiable) CVSS score of a V2X entity.

[0210] Features without DCPI indication

[0211] A no-DCPI indication can be a new information element or a value within an existing information element. For example, a no-DCPI indication can be a new information element of type NULL (its existence indicates that no DCPI can determine it), a new value in an existing result / error code field (its value indicates that no DCPI can determine it), or a value in a new information element (its value indicates that no DCPI can determine it), etc. The purpose of a no-DCPI indication is to show the receiving V2X entity that the V2X entity's current network security posture is unknown. It can also indicate that the V2X entity needs to update / improve / enhance its network security posture. This can be achieved by the V2X entity performing / installing / applying V2X entity updates to its components, such as by downloading or receiving V2X entity upgrades from an update server, as described above. Figure 4 and Figure 5 As shown.

[0212] V2X entity update data characteristics

[0213] V2X entity update data may include one or more of the following.

[0214] In the first case, V2X entity update data may include indications of the manufacturer, operating system, and / or application of the V2X entity or V2X entity components (collectively referred to as the “component list” or “bill of materials”).

[0215] In another scenario, V2X entity update data may include indications of the version of one or more components or date / time stamps, such as SWIN.

[0216] In another scenario, V2X entity update data may include the date / time of the last contact with the update server.

[0217] In another scenario, V2X entity update data may include the date / time of downloading / installing components (such as software, firmware, hardware, or system components). In other words, it is the date / time stamp of the component installation.

[0218] Characteristics of V2X entity anomaly detection data

[0219] V2X entity anomaly detection data may include one or more of the following.

[0220] In the first case, V2X entity anomaly detection data may include indications of the manufacturer, operating system, and / or application of the V2X entity or V2X entity components (collectively referred to as the “component list” or “bill of materials”).

[0221] In another scenario, V2X entity anomaly detection data may include an indication of the number and / or severity of anomalies detected in one or more components.

[0222] In another scenario, V2X entity anomaly detection data may include the date / time of the last contact with the anomaly detection server.

[0223] The severity of the detected anomalies can be a Cyber ​​Vulnerability Scoring System (CVSS) score or an aggregated (and quantifiable) CVSS score, such as using metrics and scores defined by CVSS.

[0224] Features of DCP Low Indicator

[0225] The DCP low indicator can be a new message element or a value in an existing message element. For example, the DCP low indicator can be a new message element of type NULL (which indicates that the DCP of the V2X entity is too low for the V2X system), a new value in an existing result / error code field (which indicates that the DCP of the V2X entity is too low for the V2X system), or a value in a new message element (which indicates that the DCP of the V2X entity is too low for the V2X system).

[0226] The purpose of a low DCP indication is to show the receiving V2X entity that its current network security posture is too low to allow it to participate in the V2X system. This can also indicate that the V2X entity needs to update / improve / enhance its network security posture. This can be achieved by the V2X entity performing / installing / applying V2X entity updates, for example, by downloading or receiving V2X entity upgrades from an update server. (For example, regarding the above...) Figure 4 and Figure 5 As described in the embodiments.

[0227] When an event occurs at the update server or anomaly detection server, add the V2X entity to the CRL.

[0228] In another embodiment, a V2X entity may perform one or both of the following: send a request message to an update server, the request message including a request for one or more V2X entities to update or a request for information related to the upgrade of one or more V2X entities; and / or send a request message to an anomaly detection server, for example to report detected anomalies or to provide information for the anomaly detection server to detect anomalies.

[0229] The above requests may include updating the client's identity / identifier (ID) or the anomaly detection client's anomaly detection client ID, and may also include V2X client IDs, such as canonical IDs, certificates of V2X clients associated with V2X entities, etc.

[0230] Upon receiving a request message that includes an update client ID and one or more V2X client IDs, the update server stores the association between the update client ID and the one or more V2X client IDs. The update server may also optionally store other information, such as V2X entity updates downloaded by the update client, including version information, software component information, etc.

[0231] If or when an event occurs at the update server, the update server may send a CRL add request message to the certificate authority. This CRL add request message includes one or more stored V2X client IDs associated with the update client in the V2X entity. Such events may include the time elapsed since the V2X entity last connected to check for V2X entity updates exceeding a threshold, and the time when an upgrade to the V2X entity is initiated / installed / provided on the update server.

[0232] As an alternative to sending a message to the certificate authority when an event occurs at the update server, the update server can send a notification update server event message to the V2X entity CPDS. This might happen, for example, if there are no one or more V2X client IDs associated with the update client ID.

[0233] Upon receiving a request message including an anomaly detection client ID and one or more V2X client IDs, the anomaly detection server stores the association between the anomaly detection ID and one or more V2X client IDs. If or when an event occurs at the anomaly detection server, the anomaly detection server may send a CRL add request message to the certificate authority. This CRL add request message includes one or more stored V2X client IDs associated with the anomaly detection client IDs associated with the anomaly detection client in the V2X entity. Such events may include the time since the V2X entity last connected to report an anomaly or provide anomaly detection information exceeding a time threshold, the time when a new anomaly is detected in the V2X entity, etc.

[0234] As an alternative to sending messages to the certificate authority when an event occurs at the anomaly detection server, the anomaly detection server can send a notification anomaly event message to the V2X entity CPDS. In this case, the event may include a situation where one or more V2X client IDs are not stored associated with the anomaly detection client ID.

[0235] Upon receiving a notification update server event message that includes an updated client ID or an information anomaly detection server event message that includes an anomaly detection client ID, the V2X entity CPDS can determine one or more V2X client IDs associated with the received updated client ID or anomaly detection client ID, and can send a CRL add request message to the certificate authority, which includes the determined one or more V2X client IDs. The V2X entity CPDS can determine the one or more V2X client IDs associated with the received updated client ID or anomaly detection client ID by querying a pre-configured list, store, or database.

[0236] After receiving a CRL addition request from an update server, an anomaly detection server, or a V2X entity CPDS, the certificate authority can add one or more entries to one or more Certificate Revocation Lists (CRLs), where each entry corresponds to one or more V2X certificates associated with a V2X entity identified by a V2X client ID. Alternatively, the update server, anomaly detection server, certificate authority, or V2X entity CPDS can send a request message to another entity (such as a CRL store, misconduct authority, etc.) to request that the other entity add one or more entries to one or more CRLs.

[0237] Subsequently, all V2X entities of a V2X system that have downloaded and applied one or more CRLs will blacklist the V2X client / V2X entity. This can include actions such as ignoring, automatically discarding, or abandoning V2X messages received from the V2X client / V2X entity.

[0238] If a V2X entity finds one or more certificates in one or more CRLs, the V2X entity can take remedial actions, such as performing the actions described above. Figure 4 or Figure 5 Examples of implementations.

[0239] In some cases, a V2X entity may include separate clients for V2X messaging (V2X client) and update messaging (update client), and the update client may not have an available V2X client ID. In this case, the update client can send a V2X client ID request message to the V2X client to obtain one or more V2X client IDs. This can be done, for example, via API or AT commands.

[0240] The V2X client receives a V2X Client ID Request message from the update client and sends a V2X Client ID Response message to the update client, which includes one or more V2X Client IDs.

[0241] In other cases, a V2X entity may include separate clients for V2X messaging (V2X client) and anomaly detection messaging (anomaly detection client), and the anomaly detection client may not have an available V2X client ID. In this case, the anomaly detection client can send a V2X client ID request message to the V2X client to obtain one or more V2X client IDs. This can be done via API or AT commands.

[0242] The V2X client receives a V2X client ID request message from the anomaly detection client and sends a V2X client ID response message containing one or more V2X client IDs to the anomaly detection client.

[0243] Now for reference Figure 6 .exist Figure 6 In this embodiment, V2X entity 610 includes V2X client 612 and update client 614. Other network entities include update server 616, V2X entity CPDS 617, and certificate authority 618, which may include one or more other entities, such as a "distribution center" (which can distribute one or more CRLs), a misconduct authority (which can sign one or more CRLs), etc.

[0244] and Figure 4 and Figure 5 The implementation is the same as the previous one. Figure 6 The dashed lines in the example indicate optional or conditional message flows.

[0245] exist Figure 6 In the example, update client 614 can send a V2X client ID request message 620 to V2X client 612. This can be done, for example, if update client 615 does not have any or enough V2X client IDs.

[0246] After receiving the V2X Client ID Request message 620, the V2X client 612 sends a V2X Client ID Response message 622 to the Update client 614. The V2X Client ID Response message 622 includes one or more V2X Client IDs.

[0247] Another module in update client 614 or V2X entity 610 sends a "Fetch Update Request" message 630 to update server 616. Message 630 includes the update client ID, and may also include one or more V2X client IDs. Such V2X client IDs may have already been received in message 622.

[0248] Upon receiving the "Fetch Update Request" message 630, the update server 616 sends a "Fetch Update Response" message 632 to the update client 614 or other modules on the V2X entity 610. Message 632 may include one or more V2X entity updates or information about one or more V2X entity updates. The update client 614 or other modules on the V2X entity 610 receive the "Fetch Update Response" message 632. The update client 614 or other modules on the V2X entity 610 can install or apply the V2X entity update. For example, in some cases, such an update may be received in the "Fetch Update Response" message 632. In other cases, such an update may be received by initiating a new message to the update server or another server.

[0249] Event A 640 occurs after a period of time. Event A 640 may occur before the report exception request message 630 is received, and may be one or more of the following:

[0250] In the first case, event A 640 could be a time threshold exceeding the time threshold for receiving the "Fetch Update Request" message 630 from the update client 614.

[0251] In another scenario, event A 640 could be the time threshold for the update client to retrieve the new update after 614.

[0252] In another scenario, event A 640 could be a different event type.

[0253] Due to the occurrence of event A 640, update server 616 may perform one of the following two actions. In the first case, update server 616 may send a CRL add request message 650 to certificate authority 618, which includes one or more V2X client IDs, such as those received in message 630.

[0254] Optionally, update server 616 may send a notification update server event message 660 to V2X entity CPDS 617, which includes the update client ID associated with update client 614 or V2X entity 610, such as the one received in message 630.

[0255] In some cases, if update server 616 does not receive one or more V2X client IDs in message 630 or does not receive message 630, update server 615 may send message 660 instead of message 650.

[0256] Upon receiving the Notification Update Server Event Message 660, the V2X entity CPDS 617 determines one or more V2X client IDs associated with the update client ID received in the Notification Event Message 661, and then sends a CRL Add Request Message 662 to the Certificate Authority 618. Message 662 includes one or more determined V2X client IDs. The determination of one or more V2X client IDs can be accomplished by querying a list, store, or database, or by configuring or pre-configuring data, etc.

[0257] Before sending message 662, it is assumed that V2X entity CPDS 617 has been configured with data or information to associate the updated client ID with one or more V2X client IDs. In this case, the V2X client ID can be an identity / identifier that does not change during the lifetime of V2X entity 610, such as a canonical ID.

[0258] Furthermore, if update server 616 sends CRL add request message 650 to certificate authority 618, message 662 can be skipped.

[0259] When a CRL add request message 650 or 662 is received from update server 616 or V2X entity CPDS 617, certificate authority 618 adds one or more entries related to the V2X entity to the Certificate Revocation List (CRL). These entries are identified by one or more V2X client IDs from messages 650 and 662, as shown in box 670. In other words, certificate authority 618 adds V2X client 612 or V2X entity 610 to the CRL.

[0260] The action of adding one or more entries to the CRL that are related to one or more V2X client IDs received in messages 650 or 662 may involve the certificate authority 618 sending a message to another entity, such as a CRL store or misconduct authority, that includes the V2X client IDs received in messages 650 and 662.

[0261] After being added to the CRL, V2X client 612 of V2X entity 610 can discover one or more certificates in one or more CRLs and can take remedial actions. For example, the remedial action could be to perform the above... Figure 4 or Figure 5 Examples of implementations.

[0262] The update server 616 may, in some cases, be an OMA DM server or an Uptane server. The V2X client 612 may, in some cases, include OMA DM client and / or Uptane client functionality. The certificate authority 618 may be or may include a misconduct authority, and the CRL add request message may be or may include a misconduct report.

[0263] Figure 6 One or more entities shown can be combined with each other. Furthermore, Figure 6 The message passing shown can be performed in a different order than that shown.

[0264] V2X entities can include anomaly detection clients as replacements or supplements to existing client updates. See now for reference. Figure 7 .

[0265] exist Figure 7 In one embodiment, V2X entity 710 includes V2X client 712 and anomaly detection client 714.

[0266] and Figure 4 , Figure 5 and Figure 6 The implementation is the same as the previous one. Figure 7 The dashed lines in the example indicate optional or conditional message flows.

[0267] The network also includes an anomaly detection server 716, a V2X entity CPDS 717, and a certificate authority 718.

[0268] exist Figure 7 In the example, the anomaly detection client 714 can send a V2X client ID request message 720 to the V2X client 712. For example, if the anomaly detection client 714 does not have any or enough V2X client IDs, it can do so.

[0269] After receiving the V2X Client ID Request message 720, the V2X client 712 sends a V2X Client ID Response message 722 to the anomaly detection client 714. The V2X Client ID Response message 722 includes one or more V2X Client IDs.

[0270] Anomaly detection client 714 sends an anomaly report request message 730 to anomaly detection server 716. The anomaly report request message 730 includes the anomaly detection client ID, and may also include one or more V2X client IDs. Such V2X client IDs can be received in message 722.

[0271] After receiving the report anomaly request message 730, the anomaly detection server 716 can send the report anomaly update response message 732 to the anomaly detection client 714.

[0272] Event B 740 occurs some time later. Event B 740 may occur before the report exception request message 730 is received, and may be one or more of the following conditions.

[0273] In the first case, event B 740 could be a time threshold exceeding the time threshold for receiving a report exception request message 730 from the exception detection client 714.

[0274] In another scenario, event B 740 could be an anomaly detected in V2X entity 710 and / or anomaly detection client 714.

[0275] In another scenario, event B 740 could be a different event type.

[0276] Due to the occurrence of event B 740, the anomaly detection server 716 can perform one of two actions. In the first case, the anomaly detection server 716 can send a CRL addition request message 750 to the certificate authority 718, which includes one or more V2X client IDs, such as those received in message 730.

[0277] Alternatively, the anomaly detection server 716 may send a notification anomaly detection server event message 760 to the V2X entity CPDS 717, the notification anomaly detection server event message 760 including the anomaly detection client ID associated with the anomaly detection client 714 or the V2X entity 710, such as received in message 730.

[0278] In some cases, if the anomaly detection server 716 does not receive one or more V2X client IDs in message 730, or does not receive message 730, the anomaly detection server 726 may send message 760 instead of message 750.

[0279] Upon receiving the Notification Anomaly Detection Server event message 760, the V2X entity CPDS 717 determines one or more V2X client IDs associated with the anomaly detection client ID received in the Notification Anomaly Detection Server event message 766, and then sends a CRL Add Request message 762 to the Certificate Authority 718. Message 762 includes one or more determined V2X client IDs. The determination of one or more V2X client IDs can be accomplished by querying a list, store, or database, or by configuring or pre-configuring data, etc.

[0280] Before sending message 762, it is assumed that V2X entity CPDS 717 has been configured with data or information that associates anomaly detection client IDs with one or more V2X client IDs. In this case, the V2X client ID can be an identity / identifier that does not change during the lifetime of V2X entity 710, such as a canonical ID.

[0281] Furthermore, if the anomaly detection server 716 sends a CRL add request message 750 to the certificate authority 718, message 762 can be skipped.

[0282] When a CRL add request message 750 or 762 is received from the anomaly detection server 716 or the V2X entity CPDS 717, the certificate authority 718 adds one or more entries related to the V2X entity to the Certificate Revocation List (CRL). These entries are identified by one or more V2X client IDs from message 750 or 772, as shown in box 770. In other words, the certificate authority 718 adds the V2X client 712 or the V2X entity 710 to the CRL.

[0283] The action of adding one or more entries to the CRL related to one or more V2X client IDs received in message 750 or 762 may involve the certificate authority 718 sending a message to another entity (such as the CRL store or misconduct authority) that includes the V2X client IDs received in message 750 or 762.

[0284] After being added to a CRL, V2X client 712 or V2X entity 710 can discover one or more certificates in one or more CRLs and can take remedial actions. For example, a remedial action could be to perform the actions described above. Figure 4 or Figure 5 Examples of implementations.

[0285] In some cases, the anomaly detection server 716 may be an IETF NEA server as defined in IETF RFC 5209. In some cases, the anomaly detection client 714 may include an IETF NEA client as defined in IETF RFC 5209. The certificate authority may be or may include a misconduct authority, and the CRL add request message may or may include a misconduct report.

[0286] Figure 7 One or more entities shown can be combined with each other. Furthermore, Figure 7 The message passing shown can be performed in a different order than that shown.

[0287] Characteristics of V2X Client ID

[0288] V2X Entity ID identifies a V2X entity and / or V2X client, and may consist of one or more of the following: a canonical ID; a certificate as defined by IEEE 1609.2, such as a certificate, admission certificate, application certificate, or authorization ticket as defined by X.509; a link seed / value; an IP address; a hostname, which may include a domain name / fully qualified domain name (FQDN); a URL; a URI; a NAI; a device ID; an International Mobile Equipment Identity (IMEI); SWIN; etc.

[0289] Features of updating client ID

[0290] The update client ID identifies the update client and / or V2X entity and may consist of one or more of the following: IP address; hostname, which may include domain name / FQDN; URL; URI; NAI; device ID; IMEI; SWIN; etc.

[0291] Features of anomaly detection client ID

[0292] Anomaly detection client ID identifies the anomaly detection client and / or V2X entity, and may consist of one or more of the following: IP address; hostname, which may include domain name / FQDN; URL; URI; NAI; device ID; IMEI; SWIN; etc.

[0293] Protocol Changes

[0294] Examples of changes to the “ToBeSignedCertificate” ASN.1 definition in IEEE 1609.2 can be found in the appendix below, which includes several options for the newly introduced network security posture level.

[0295] In particular, support Figure 4 and Figure 5 The protocol variations of the embodiments are shown in Appendix A below. In Appendix A, Tables 3 to 17 show the changes to the existing protocols shown in bold.

[0296] support Figure 6 and Figure 7 The protocol variations of the embodiments are shown in Appendix B below. In Appendix B, Table 18 shows the changes to the existing protocols, which are shown in bold.

[0297] hardware

[0298] V2X entities, V2X clients, registration authorities, V2X entity CPCS, authorization authorities, update servers, anomaly detection servers, certificate authorities, or network servers or nodes can be any type of computing device. For example, regarding... Figure 8 A simplified computing device is provided that can perform the above embodiments.

[0299] exist Figure 8 In this embodiment, computing device 810 includes processor 820 and communication subsystem 830, wherein processor 820 and communication subsystem 830 cooperate to perform the methods of the embodiments described herein.

[0300] Processor 820 is configured to execute programmable logic, which can be stored on computing device 810 along with data, and Figure 8 The example shown is memory 840. Memory 840 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 820 can also be implemented entirely in hardware and does not require any stored program to perform logical functions.

[0301] Alternatively, in addition to memory 840, computing device 810 may also access data or programmable logic from external storage media, such as via communication subsystem 830.

[0302] The communication subsystem 830 allows the computing device 810 to communicate with other devices or network elements.

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

[0304] 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 with 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.

[0305] 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.

[0306] 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.

[0307] 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.

[0308] 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.

[0309] 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.

[0310] 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.

[0311] Appendix A

[0312]

[0313]

[0314] Table 3: Example Changes in Certificate Definitions in IEEE 1609.2ASN.1

[0315]

[0316] Table 4: Example variations of the ETSI TS 102 941 – AuthorizationValidationResponse message

[0317]

[0318] Table 5: Example ASN.1 definition of "DynamicCybersecurityPostureInfo"

[0319]

[0320] Table 6: Example ASN.1 definition of "CybersecurityPostureLevel" (1)

[0321]

[0322] Table 7: Example ASN.1 definition of "CybersecurityPostureLevel" (2)

[0323]

[0324]

[0325] Table 8: Example ASN.1 definition of “componentManifest”

[0326] Protocol changes without DCPI indication and DCP under indication

[0327]

[0328]

[0329] Table 9: Example Variation 1 of ETSI TS 102 941 – AuthorizationValidationResponse Message

[0330]

[0331] Table 10: Example Variation 2 of ETSI TS 102 941 – AuthorizationValidationResponse Message

[0332]

[0333]

[0334]

[0335] Table 11: Example Variation 1 of ETSI TS 102 941 – AuthorizationResponse Message

[0336]

[0337] Table 12: Example variation 2 of ETSI TS 102 941[5] - AuthorizationResponse message

[0338] Protocol changes for network security data

[0339] The changes to the network security data protocol are similar to those of the DCPI protocol, as both can include similar or identical information.

[0340]

[0341]

[0342] Table 13: Example variations of ETSI TS 102 941[5]ASN—permission requests

[0343]

[0344] Table 14: Example variations of ETSI TS 102 941[5]ASN—Verification Request

[0345]

[0346] Table 15: Example ASN.1 of "CybersecurityData" defines protocol variations for V2X entity update data and V2X entity anomaly detection data.

[0347]

[0348]

[0349] Table 16: Example ASN.1 Definitions of V2X Entity Update Data and V2X Entity Anomaly Detection Data

[0350] Protocol changes for Message CPD requests / responses, V2X entity status update requests / responses, and V2X entity anomaly detection status requests / responses.

[0351]

[0352]

[0353]

[0354]

[0355]

[0356]

[0357]

[0358] Table 17: Example ASN.1 Definitions of Message CPD Request / Response, V2X Entity Update Status Request / Response, and V2X Entity Anomaly Detection Status Request / Response

[0359] Appendix B

[0360] Message extraction for update requests / responses, reporting of exception requests / responses, notification of update server events, notification of exception detection server events, and protocol changes for CRL addition requests.

[0361]

[0362]

[0363]

[0364]

[0365]

[0366] Table 18: Example ASN.1 Definitions for Message Retrieval Update Requests, Notification Update Server Events, Notification Anomaly Detection Server Events, and CRL Add Requests

Claims

1. A method at a network element, the method comprising: sending a status request to at least one of an update server and an anomaly detection server; receiving, at the network element, at least one message in response to the status request, the at least one message being one or both of: an update status information message from the update server; and an anomaly detection status information message from the anomaly detection server; determining a dynamic cyber-security posture indication for a smart transportation system entity based on receiving the at least one message, wherein the dynamic cyber-security posture indication changes over time based on receiving the at least one message, the dynamic cyber-security posture indication representing a measure or level of security of the smart transportation system entity; digitally signing, by a certificate authority for the smart transportation system entity, the dynamic cyber-security posture indication; and providing, to a registration authority, the signed dynamic cyber-security posture indication for the smart transportation system entity, wherein the signed dynamic cyber-security posture indication is included in a certificate related to the smart transportation system entity; the method further comprising: receiving, at the network element, an information message from one of the update server and the anomaly detection server, the information message indicating that an event has occurred for the smart transportation system entity, wherein the event decreases the dynamic cyber-security posture indication; and based on receiving the information message, sending a certificate revocation list addition request to the certificate authority for the smart transportation system entity.

2. The method of claim 1, wherein the network element further: receiving a cyber-security posture determination request from the registration authority, the cyber-security posture determination request containing cyber-security data about the smart transportation system entity; and using the cyber-security data about the smart transportation system entity when determining the dynamic cyber-security posture indication for the smart transportation system entity.

3. The method of claim 1, wherein the dynamic cyber-security posture indication is one of: dynamic cyber-security posture information; an indication that dynamic cyber-security posture information cannot be provided; an indication that the dynamic cyber-security posture is too low for the smart transportation system.

4. The method of claim 3, wherein the dynamic cyber-security posture information is one or more of: a timestamp field providing information about a time when the smart transportation system entity was last audited for cyber-security; a timestamp field providing information of a last connection date to the update server; a timestamp field providing information about a time when the smart transportation system entity last connected to an anomaly detection server; an indication that the smart transportation system entity has mitigated known vulnerabilities against; a cyber-security posture level; a hardware version or build for the smart transportation system entity; a software version or build for the smart transportation system entity; a cyber-security posture score; and a vulnerability score. ​ ​ 5. The method of claim 3, wherein the indication that dynamic cyber-security posture information is not available comprises an information element or a field within an information element.

6. The method of claim 3, wherein the indication that the dynamic cyber-security posture is too low for the intelligent transportation system comprises an information element or a field within an information element.

7. The method of claim 1, wherein prior to sending the certificate revocation list addition request, the network element determines one or more identifiers for the intelligent transportation system entity based on a client identifier received in the information message.

8. The method of claim 7, wherein the one or more identifiers are canonical identifiers for the intelligent transportation system entity.

9. A network element comprising: a processor; and a communication subsystem, wherein the network element is configured to: send a status request to at least one of an update server and an anomaly detection server; receive at the network element at least one message in response to the status request, the at least one message being one or both of: an update status information message from the update server; and an anomaly detection status information message from the anomaly detection server; determine a dynamic cyber-security posture indication for an intelligent transportation system entity based on receiving the at least one message, wherein the dynamic cyber-security posture indication changes over time based on receiving the at least one message, the dynamic cyber-security posture indication representing a measure or level of security for the intelligent transportation system entity; digitally sign the dynamic cyber-security posture indication by a certificate authority for the intelligent transportation system entity; and provide the signed dynamic cyber-security posture indication for the intelligent transportation system entity to a registration authority, wherein the signed dynamic cyber-security posture indication is included in a certificate related to the intelligent transportation system entity; the network element is further configured to: receive an information message at the network element, the information message being from one of the update server and the anomaly detection server, the information message indicating that an event has occurred for the intelligent transportation system entity, wherein the event decreases the dynamic cyber-security posture indication; and send a certificate revocation list addition request to the certificate authority for the intelligent transportation system entity based on receipt of the information message.

10. The network element of claim 9, wherein the network element is further configured to: receive a cyber-security posture determination request from the registration authority, the cyber-security posture determination request containing cyber-security data about the intelligent transportation system entity; and use the cyber-security data about the intelligent transportation system entity when determining the dynamic cyber-security posture indication for the intelligent transportation system entity.

11. The network element of claim 9, wherein the dynamic cyber-security posture indication is one of: dynamic cyber-security posture information; an indication that dynamic cyber-security posture information is not available; an indication that the dynamic cyber-security posture is too low for the intelligent transportation system. ​ ​ 12. The network element of claim 11, wherein the dynamic cyber-security posture information is one or more of: a timestamp field providing information about a time when the intelligent transportation system entity was last audited for cyber-security; a timestamp field providing information of a last connection date to the update server; a timestamp field providing information about a time when the intelligent transportation system entity last connected to an anomaly detection server; an indication that the intelligent transportation system entity has mitigated a known vulnerability against; a cyber-security posture level; a hardware version or build for the intelligent transportation system entity; a software version or build for the intelligent transportation system entity; a cyber-security posture score; and a vulnerability score.

13. The network element of claim 11, wherein the indication that dynamic cyber-security posture information is unavailable comprises an information element or a field within an information element.

14. The network element of claim 11, wherein the indication that a dynamic cyber-security posture is too low for the intelligent transportation system comprises an information element or a field within an information element.

15. The network element of claim 11, wherein prior to sending the certificate revocation list addition request, the network element is configured to determine one or more identifiers for the intelligent transportation system entity based on a client identifier received in the information message.

16. The network element of claim 15, wherein the one or more identifiers are canonical identifiers for the intelligent transportation system entity.

17. A computer-readable medium for storing instruction code that, when executed by a processor of a network element, causes the network element to: send a status request to at least one of an update server and an anomaly detection server; receive, at the network element, at least one message in response to the status request, the at least one message being one or both of: an update status information message from the update server; and an anomaly detection status information message from the anomaly detection server; determine, based on receiving the at least one message, a dynamic cyber-security posture indication for an intelligent transportation system entity, wherein the dynamic cyber-security posture indication changes over time based on receiving the at least one message, the dynamic cyber-security posture indication representing a measure or level of security for the intelligent transportation system entity; digitally sign, by a certificate authority for the intelligent transportation system entity, the dynamic cyber-security posture indication; and provide, to a registration authority, the signed dynamic cyber-security posture indication for the intelligent transportation system entity, wherein the signed dynamic cyber-security posture indication is included in a certificate related to the intelligent transportation system entity; the instruction code, when executed by the processor, further causes the network element to: receive, at the network element, an information message from one of the update server and the anomaly detection server, the information message indicating that an event has occurred for the intelligent transportation system entity, wherein the event decreases the dynamic cyber-security posture indication; and ​ ​ Based on the reception of the information message, a certificate revocation list addition request is sent to the certificate authority for the intelligent transportation system entity.

Images