Method and system for adding assurance information to v2x messages

Abstract

A method at an Intelligent Transportation System (ITS) entity, the method comprising receiving a message from a second ITS entity, the message containing a security assurance indication, and performing an action at the ITS entity based on the security assurance indication. Further, an ITS entity comprising a processor; and a communication subsystem, wherein the ITS entity is configured to: receive a message from a second ITS entity, the message containing a security assurance indication; and perform an action at the ITS entity based on the security assurance indication.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to vehicle-to-everything (V2X) communications, and in particular to trust of V2X messages. BACKGROUND

[0002] In intelligent transportation systems (ITS), multiple devices communicate in order for the transportation system to make more intelligent decisions in terms of traffic and flow management, as well as to make safer, more coordinated decisions. ITS system components can be set up as part of fixed infrastructure, within vehicles, such as on bridges or at crossroads, as well as for other users of the transportation system, including pedestrians or cyclists.

[0003] ITS system deployments are of great interest in multiple markets around the world, and radio bands are allocated for communication. In addition to vehicle-to-vehicle communication for safety-critical and non-critical applications, further enhancements are being developed for vehicle-to-infrastructure and vehicle-to-portable scenarios to provide for traffic safety and efficiency.

[0004] However, when such devices communicate, the receiving device needs to be confident that the received message is trustworthy in order to take action on the information in such a message. One aspect of the problem that the receiving device faces in determining trustworthiness is whether the sending entity is functioning correctly, in other words, it is not malfunctioning. Another aspect of the problem that the receiving device faces in determining trustworthiness is whether the behavior of the sending entity is as expected. BRIEF DESCRIPTION OF DRAWINGS

[0005] The present disclosure can be better understood with reference to the following drawings, in which:

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

[0007] Figure 2 is a data flow diagram illustrating certificate retrieval and V2X communication procedures in a V2X architecture;

[0008] Figure 3 is a data flow diagram illustrating certificate retrieval and V2X communication procedures in a V2X architecture with additional assurance information;

[0009] Figure 4 is a block diagram illustrating a signaling octet that can be used to convey functional safety, expected functional safety, or aggregated information;

[0010] Figure 5 is a flow diagram illustrating a procedure at a receiving ITS entity for determining how to react to a received V2X message based on functional safety assurance level information in the received V2X message;

[0011] Figure 6 is a flowchart illustrating a process at a receiving ITS entity for determining how to react to a received V2X message based on expected functional safety assurance level information in the received V2X message;

[0012] Figure 7 is a flowchart illustrating a process at a receiving ITS entity for determining how to react to a received V2X message based on multiple safety assurance level information in the received V2X message;

[0013] Figure 8 is a flowchart illustrating a process at a receiving ITS entity for determining how to react to a received V2X message based on aggregated safety assurance level information in the received V2X message; and

[0014] Figure 9 is a block diagram of an example computing device or server that can be used with embodiments of the present disclosure. DETAILED DESCRIPTION

[0015] The present disclosure provides a method at an Intelligent Transportation System (ITS) entity, the method comprising: receiving a message from a second ITS entity, the message containing a safety assurance indication; and performing an action at the ITS entity based on the safety assurance indication.

[0016] The present disclosure further provides an Intelligent Transportation System (ITS) entity, the ITS entity comprising: a processor; and a communication subsystem, wherein the ITS entity is configured to: receive a message from a second ITS entity, the message containing a safety assurance indication; and perform an action at the ITS entity based on the safety assurance indication.

[0017] The present disclosure further provides a computer readable medium for storing instruction code that, when executed by a processor of an Intelligent Transportation System (ITS) entity, causes the ITS entity to: receive a message from a second ITS entity, the message containing a safety assurance indication; and perform an action at the ITS entity based on the safety assurance indication.

[0018] In determining whether to take action on a received V2X message, a V2X entity, such as a vehicle receiving the message, can need to determine whether the message can be trusted. The trust of the message can vary by message type. For example, a safety critical use case can require a higher level of trust, such as an emergency braking warning, where the receiving vehicle can need to determine whether it should take action on the message content and brake hard, even possibly without other corroborating information. For example, a large truck can be located between the vehicle sending the message and the vehicle receiving the message, thus eliminating any line-of-sight corroborating information.

[0019] Aspects of the problems faced by a receiving V2X entity in determining the trustworthiness of a transmitting V2X entity exist. A first aspect is whether the receiving entity can be confident that the transmitting entity is cyber secure and has not or is not likely to be hacked.

[0020] A second aspect is whether the receiving entity can be confident that the V2X transmitting entity is free from faults and thus does not generate messages in error or generate messages with content errors.

[0021] A third aspect is whether the receiving entity can be confident that the V2X transmitting entity is functioning as intended. In this third aspect, the receiving entity can need to determine whether it is confident that there are no deficiencies in the design of complex perception algorithms at the transmitting entity or in the performance and operation of sensors that can lead to messages being generated in error or messages with content errors.

[0022] There is currently no solution that can be used by a V2X receiving entity to establish trust that a V2X message was generated by a fault-free transmitter.

[0023] Furthermore, a V2X receiving entity cannot determine through any solution that the intended function safety (SOTIF) exists functional safety. Specifically, the V2X receiving entity can need to know that the V2X transmitting entity does not inappropriately or inaccurately generate messages or message content based on intended functional faults. V2X messages can be generated based on perception algorithms, such as artificial intelligence (AI) or machine learning (ML) algorithms. However, the process of ensuring that such AI / ML perception algorithms are always functioning as intended is difficult. For example, it is difficult to be completely confident that the type and amount of data used to train an AI / ML model is sufficient to cover all scenarios that the perception algorithm can encounter in the field. From a SOTIF perspective, ISO 21448 provides an answer to such issues in terms of a set of procedures and processes that a manufacturer should follow so that a product is considered to be “acceptable release”.

[0024] Furthermore, when generating messages associated with different use cases, different sets of electronic control units (ECUs) can be involved. For example, one V2X message, such as an emergency brake warning, can involve obtaining sensor information from the braking system, while other V2X messages, such as periodic cooperative awareness messages (CAMs) or basic safety messages (BSMs), can not. A manufacturer can wish to avoid designing each ECU with a network security, functional safety, or SOTIF assurance level for the most demanding V2X applications, as this would be unnecessarily expensive. Thus, in some cases, it can be advantageous to determine the trustworthiness according to the specific application type related to a given V2X message. In particular, current standardization related to network security assurance enables a V2X transmitter to indicate a network security assurance level (TAL) according to the application type (PSID), but these standards do not support indicating assurance levels in cases where multiple operational modes exist within an application type.

[0025] Furthermore, one problem with adding differentiation information in the vehicle certificate, including functional safety (FuSa) level, SOTIF level, etc., is that this information can be used to help people who wish to track vehicles. In particular when different vehicles have different (albeit fixed) settings. This can reduce the privacy of the owner or driver of a vehicle transmitting V2X messages.

[0026] Embodiments of the present disclosure address one or more of the problems described above.

[0027] The present disclosure is related to V2X, which is a feature that provides for communication of messages between vehicles and other entities (and possibly vice versa) that can affect the vehicles and / or other entities. Thus, a V2X entity is an entity that supports one or both of sending and receiving V2X messages, and can include the options of an intelligent transportation system (ITS) station (ITS-S), an electronic control unit (ECU), an on-board unit (OBU), a user equipment (UE), a mobile entity (ME), a terminal entity (EE), etc. A V2X entity is also referred to herein as an ITS entity, and the terms can be used interchangeably.

[0028] The communication with vehicles can be with various V2X endpoints. V2X endpoints can include other vehicles, individually referred to as vehicle-to-vehicle (V2V); infrastructure, such as roadside units, individually referred to as vehicle-to-infrastructure (V2I); pedestrians or cyclists, individually referred to as vehicle-to-pedestrian (V2P); network(s), individually referred to as vehicle-to-network (V2N); devices, such as electronic devices within a vehicle, individually referred to as vehicle-to-device (V2D); a power grid, individually referred to as vehicle-to-grid (V2G); and other options. These are collectively referred to as V2X.

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

[0030] Various systems / architectures can provide V2X communications. One such system / architecture is a cellular network, such as defined in Third Generation Partnership Project (3GPP) specifications. Other systems / architectures can include, for example, Integrated Digital Enhanced Network (iDEN), Institute of Electrical and Electronics Engineers (IEEE) 802.1 lp wireless networks, etc.

[0031] There are currently various standards that can be used to convey a network security assurance level in V2V messages. These include European Telecommunications Standards Institute (ETSI), Institute of Electrical and Electronics Engineers (IEEE) 1609.2, “IEEE WAVE Standards - Application and Management Message Security Services - IEEE 1609.2-2016 Consolidated Draft and Amendments Specified in 1609.2a / D8 and 1609.2b / D3,” December 2016, and Car2Car consortium.

[0032] Generally, V2X communications consist of V2X messages sent by V2X entities and received V2X messages. V2X messages are broadcast messages that contain information about the current location, speed, or other information of a vehicle and are signed by a temporary key that is associated with an anonymous certificate belonging to the sending entity. The certificate will be sent in its entirety or its hash will be sent with the message. A receiving entity that is able to detect and decode these messages is able to verify the certificate used to sign it. The network security assurance level can be included in these certificates.

[0033] For example, in the European ITS system, ETSI Technical Specification (TS) 103 097 “ITS; Security; Security Header and Certificate Format” vl.3.1 (October 2017) and ETSI TS 102 941 “ITS: Security; Trust and Privacy Management” vl.2.1 (May 2018) provide for such verification. In this European ITS system, at the time of ITS Station (ITS-S) manufacture, a standardized globally unique identifier is provisioned in the ITS-S and the same identifier is provisioned in a registration authority along with other information related to the identifier, including an assurance level and an ITS Application Identifier (ITS AID). In addition, a Service Specific Permission (SSP) can be provisioned to detail the applications or features of applications that the vehicle is allowed to use when creating and sending messages.

[0034] Reference is now made to Figure 1 , Figure 1An example overview of the European Telecommunications Standards Institute (ETSI) ITS public key infrastructure is provided, as defined in ETSI Technical Standard (TS) 102 904 "Security of Intelligent Transport Systems (ITS), Security Architecture and Security Management of ITS Communications" v.1.2.1 (November 1916).

[0035] exist Figure 1 In the example, during manufacturing, a specification identifier (ID) (which is a unique ID for each V2X entity in the V2X system) is provided to the V2X entity (e.g., ITS-S 110), and the same specification ID, along with other information associated with that specification ID, such as the warranty level, is provided to the registration authority 112.

[0036] In the ITS architecture, the registration authority 112 authenticates the 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. The authorizing authority 130 (also referred to as an authorized certificate authority in the US system (or the system described by IEEE) authorizes the 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 ID 134, which is verified by the registration authority 112 using an authorization verification request 136 and an authorization verification response 138.

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

[0038] Then, the ITS-S 110 can use message 152, which is protected by an authorized certificate, to communicate with other V2X endpoints, such as the ITS-S 150.

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

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

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

[0042] The ITS-S sending entity 210 then requests a certificate / authorization ticket by sending an AuthorizationRequest message 230 to the authority 216. The message 230 includes the service parameters.

[0043] The authority 216 sends an AuthorizationValidationRequest message 232 to the registrar 214 including the service parameters. The registrar 215 responds to the authority 214 with an AuthoriztionValidationResponse message 234 with a result. The message 234 can also include the applicable assurance level. The authority 216 can include the assurance level (if received) in the authorization ticket (also known as an anonymous certificate or authorization certificate) that it generates. As used herein, an authorization ticket can include a European authorization ticket or a U.S. authorization certificate, formerly known as an anonymous certificate.

[0044] These authorization tickets are provided by the authority 216 to the ITS-S sending entity 210 in an AuthorizationResponse message 240.

[0045] The ITS-S sending entity 210 can then send a V2X message (shown as SecuredMessage 250) to another ITS-S in the intelligent transportation system, such as the ITS-S receiving or relaying entity 212. When the ITS-S sending entity 210 wishes to send a V2X message, it typically creates the V2X message including a certificate (authorization ticket) and a payload (e.g., the vehicle’s current location, speed); computes a fixed-length hash of the variable-length V2X message using a well-known hash algorithm; signs the hash using the ITS-S sending entity’s private key; and appends the signature to the payload and sends the resulting V2X message.

[0046] Thus, the V2X message contains the message content, a signed hash of the message, and a certificate. According to ETSI TS 102 940, the message content can be protected for authenticity, integrity, confidentiality, and privacy. Thus, the payload can be encrypted, but need not be.

[0047] The certificate can include, among other things, the sending entity’s public key; the sending entity’s anonymous identity; a signature block that is a hash of the sending entity’s identity and the sending entity’s public key, signed by the certificate authority using the certificate authority’s private key; the identity of the certificate authority that signed the certificate; and the assurance level of the sending V2X entity.

[0048] Upon receiving the message 250, the ITS-S receiving or relaying entity 212 would typically apply the known public key of the certificate authority to the signature block of the certificate to verify the identity of the sending entity and the public key of the sending entity.

[0049] The ITS-S receiving or relaying entity 212 can then check whether the identity is not on a list (pointed to) of identities in a certificate revocation list (CRL). If the identity of the sending entity is on the CRL, the message can be discarded. The ITS-S receiving or relaying entity 212 can perform other plausibility (non-encryption) checks and validity (encryption) checks.

[0050] The ITS-S receiving or relaying entity 212 can then use the public key of the sending entity to verify the signature included in the V2X message.

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

[0052] In particular, the process of obtaining a registration certificate and an application certificate (similar to an “authorization ticket”, formerly called an “anonymous certificate”) as defined in IEEE 1609.2 is similar to the process described in ETSI TS 103 097. An “assuranceLevel” item can be included in the IEEE 1609.2 certificate that is sent with the V2X message, where the corresponding private key of this certificate is used to sign the V2X message.

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

[0054] Furthermore, the design for receiving secure data exchange entity (SDEE) information can also specify a minimum assurance level for a particular signed secure protocol data unit (SPDU) payload based on the assuranceLevel field in the certificate. In this case, the receiving SDEE can check whether the assuranceLevel in the certificate is suitable for the received payload. For example, this is outlined in Section 5.2.4.3.3 of IEEE 1609.2.

[0055] In the document draft-tls-certieee1609-02.txt, Transport Layer Security (TLS) Authentication Using ITS ETSI and IEEE Certificates, March 2018, IETF is considered a trust assurance level (mandatory). Specifically, this draft states: Trust Assurance Level: C-ITS certificates of the CA and the end entity must contain a TAL: (1) For the security of the V2X communication system, it is essential that the in-vehicle safety of the participants is ensured: the message recipient must be able to rely on the fact that the sender has correctly generated the message (i.e., the car sensor information is accurate and complete). Therefore, a security breach of the sender will have an impact on all recipients of the message; and (2) Only vehicles with a reasonable “security level” can obtain a certificate from the PKI. The Car-to-Car 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 TAL. The subsequent draft does not contain this requirement.

[0056] The Car2Car Consortium defined an Evaluation Assurance Level (EAL4) Common Criteria Protection Profile for V2X Hardware Security Module (HSM) in the Car2Car Communication Consortium, “V2X Hardware Security Module Protection Profile” (August 2018). The Car2Car Consortium Basic Profile Section 7.4.6, “C2C-CC Basic System Profile” (August 2016) describes the trust assurance of a C2X station. The focus includes five trust levels designated as Trust Assurance Levels (TAL) 0 through TAL 4, with TAL 4 being the highest trust assurance level. The minimum acceptable TAL for an ITS station is TAL 2. According to ETSI TS 103 097, each TAL maps to a subject assurance representation.

[0057] Further, a presentation at the Car2Car Consortium / CAMP meeting in 2012 had the following highlights: The receiver can ensure that a V2X message is error-free based on the concept that a trusted party has evaluated the sending endpoint according to a well-established, internationally recognized, and trusted security standard and issued a certificate that the receiver can verify its view of the difficulty of compromising the sending party. The meeting further suggested that different TALs can be used for different applications, as if there is only one TAL level, it must be the TAL level required by the most demanding application. This level can be difficult to achieve for all applications.

[0058] The Car2Car conference considered options for a “trusted international standard,” including NIST FIPS-140-X, which is more about the use of encryption technology than a comprehensive network security standard; ISO generic standard 3.1, which has limited durability (2 years), which creates problems and is costly; and CC adapted custom OEM C2X evaluation scheme. In addition, 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 assurance levels defined by the C2C forum are shown in Table 1 below.

[0060]

[0061]

[0062] Table 1: Trust assurance levels for C2X stations

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

[0064] Another example of assurance levels is with respect to PRESERVE. PRESERVE is a European Community funded project that deals with security and privacy aspects of vehicle-to-anything communications. Highlights of “PRESERVE” (EC-DG INFSO funded 7th Framework Program) Section 2.5 (January 2016) (“Preparing Secure Vehicle-to-X Communication Systems,” Deliverable 5.4, Deployment Issues Report) include: only vehicles with a reasonable security level can get a certificate from the C2X PKI; an entity (e.g., a certification-type company / industry alliance / OEM self-sign) should be able to verify that a V2X module meets a minimum security level; a successful evaluation and certification can be the basis for a registration authority to issue a registration credential to a vehicle; and TALs should be included in the vehicle’s authorization ticket (anonymous certificate).

[0065] PSID and SSP of IEEE 1609.2 certificates

[0066] A public service identifier (PSID) is similar to an ETSI ITS-AID and provides an identifier of an application domain. SSPs and PSIDs are standardized in IEEE 1609.2 and provide the following.

[0067] Application rights are defined as the various actions that a certificate holder is allowed to take as specified in its certificate. Such application rights are expressed in the standard using PSIDs.

[0068] As mentioned above, SSPs are service-specific permissions, and are composed of a field that indicates the specific sender's permissions with respect to a specific application domain.

[0069] Using these definitions, the PsidSsp is used in the certificate to specify the allowed application domains. An SSP is implicitly or explicitly provided for each Psid in the application permissions to identify the specific sender's permissions in the application domain of that Psid. The syntax and semantics of the SSP are specific to each Psid value.

[0070] For example, Table 1 shows the PsidSsp definitions provided in Section 6.4.24 of the IEEE 1609.2 standard.

[0071]

[0072] Table 2: PsidSsp format

[0073] The structure of Table 2 indicates the permissions that the certificate holder has on the data for a single application domain (identified by the Psid). If the ServiceSpecificPermissions field is omitted, it indicates that the certificate holder has the default permissions associated with that Psid.

[0074] Regarding SSPs, as described in Section 5.2.4.3.3 of IEEE 1609.2, the certificate provides two fields that are used to determine that the payload of a single SPDU is consistent with the sender's permissions. The Psid field indicates that the sender is authorized to send a payload associated with the application domain indicated by the Psid field. The SSP field indicates that the sender is authorized to send a specific payload type within that application domain. The definition of application behavior within an application domain includes a mapping from the payload content to the permissions (Psid and SSP) that define the validity of the payload. In other words, one of the responsibilities of the owner of a Psid is to define the syntax and semantics of the SSPs and to define the payload that a specific SSP allows.

[0075] The Psid, SSP, and assurance level are contained in the certificate specified in Section 6.4.8 of IEEE 1609.2. The certificate format supports multiple (Psid, SSP) pairs, but a Psid does not appear multiple times in a valid certificate, so there can be an ambiguous association of a properly signed SPDU with a Psid.

[0076] Privacy

[0077] One principle within the Intelligent Transportation System is that the privacy of the transmitting entity should be respected. However, conveying the ability of a transmitting vehicle using SSPs can degrade privacy because this special SSP is different from the SSPs of other transmitting entities in the vicinity. In general, any significant feature in an anonymous, temporary certificate degrades privacy.

[0078] As described in more detail below, to overcome this, in some cases, a transmitting entity can have multiple certificates associated with it. In particular, a transmitting entity can have a "normal" certificate without any special privileges, and another certificate can have an SSP set for advanced capabilities. In this case, the transmitting entity will use the SSP certificate only for message authorization, and the normal certificate everywhere else.

[0079] Providing an indication of a functional safety and / or SOTIF assurance level

[0080] Accordingly, in accordance with the present disclosure, various solutions are provided to establish trust that a V2X message was generated by a fault-free transmitter. Moreover, the above-described embodiments also provide assurance of SOTIF functional safety. In various embodiments herein, the solutions can be tailored based on the functionality of the ECU.

[0081] These and other embodiments are described below. In the following embodiments, examples are described in accordance with the European Cooperative Credential Management System (CCMS). However, this is provided for illustrative purposes only and is not limiting. Similar concepts can be applied to any other type of secure credential management system (SCMS), including but not limited to a U.S. Collision Avoidance Metrics Partnership (CAMP) based SCMS system, a Chinese SCMS system, and other options.

[0082] Examples of indications of functional safety and / or SOTIF assurance levels Figure 3 are described. In Figure 3 In embodiments of the above, the ITS-S sending entity 310 wishes to communicate with an ITS-S receiving or relaying entity 312. However, first, enrollment credentials must be received from a registration authority 314, and authorization tickets must be received from an authorization authority 316. Moreover, in Figure 3 In embodiments of the above, the database 315 can store the verification assurance level of the entity.

[0083] In this regard, the ITS-S sending entity 310 sends an EnrollmentRequest message 320 to the registration authority 314, and includes its specification ID and public key.

[0084] The registration authority 314 responds to the ITS-S sending entity 310 with an EnrollmentResponse message 322, and includes the result and enrollment credentials.

[0085] The ITS-S sending entity 310 then requests a certificate / authorization ticket by sending an AuthorizationRequest message 330 to the authorization authority 316. The message 330 includes the service parameters.

[0086] The authorization authority 316 sends an AuthorizationValidationRequest message 332 including service parameters to the registration authority 314. In one embodiment, the authorization authority 316 can request that the registration authority 314 provide new parameters using updates to the RequestedSubjectAttributes field in the AuthorizationValidationRequest message 332. In particular, new parameters are provided herein defined as fusaAssuranceLevel and / or sotifAssuranceLevel. These assurance levels are described below. Thus, the RequestedSubjectAttributes within message 332 can request fusaAssuranceLevel and / or sotifAssuranceLevel. However, the request for fusaAssuranceLevel and / or sotifAssuranceLevel in message 332 is optional, and in some cases the registration authority 314 can provide these parameters without being requested.

[0087] Upon receiving message 332, or anticipating that an authorization request for a particular entity will be received, the registration authority 314 can obtain Assurancelnfo from the database 315, as shown in message 334. As used herein, Assurancelnfo is used to mean fusaAssuranceLevel and / or sotifAssuranceLevel.

[0088] In particular, policy and governance documents such as the “Certificate Policy for European Cooperative Intelligent Transport Systems (C-ITS) Deployment and Operation” (Version 1, published by the European Commission in June 2017) can need to be updated to define new requirements to be performed by certificate authorities. The added requirements include that the certification authority can need to determine if there is evidence from an independent third party that the assurance level associated with a given specification identity as stated by the original equipment manufacturer has been implemented. The assurance level can address one or more of cybersecurity, functional safety, and / or SOTIF. Further, the assurance level can optionally be associated with a given V2X application type such as a PSID.

[0089] This verified assurance level is recorded in the database 315 accessible to the registration authority 314.

[0090] The registration authority 312 responds to the authorization authority 316 with an AuthorizationValidationResponse message 340 with the results. The message 340 can also include the applicable assurance level. The authorization authority 316 can include the assurance level (if received) in the authorization ticket (also referred to as an anonymous certificate) that it generates. In addition, new parameters fusaAssuranceLevel and / or sotifAssuranceLevel can be provided in addition to the current assuranceLevel parameter, in Figure 3 all of the above (including the network security assurance level) can be provided as a function of the application type, denoted by PSID, and optionally, as a function of the SSP.

[0091] These authorization tickets are provided by the authorization authority 316 to the ITS-S sending entity 310 in an AuthorizationResponse message 350. In particular, the message 350 includes the authorization ticket that is updated to include the fusaAssuranceLever and / or sotifAssuranceLevel in addition to the current assuranceLevel parameter.

[0092] In particular, the current authorization ticket is structured as shown in Table 3 below:

[0093]

[0094]

[0095] Table 3: Authorization Ticket In the first embodiment, the authorization ticket can be modified as shown in bold in Table 4 below:

[0096]

[0097] Table 4: Modified Authorization Ticket

[0098] According to one embodiment of the present disclosure, SubjectFusaAssurance can take one of four values corresponding to the Automotive Safety Integrity Level (ASIL) A, B, C, or D, for example, as defined in International Organization for Standardization (ISO) 26262. However, other options for SubjectFusaAssurance are possible.

[0099] According to one embodiment of the present disclosure, SubjectSotifAssurance can take one of two levels (BOOLEAN) corresponding to “SOTIF Acceptance Release Evidences” or “No SOTIF Acceptance Release Evidences”. However, other options for SubjectSotifAssurance are also possible.

[0100] Furthermore, in some cases, the current “assuranceLevel” can be re-labeled as “cybersecurityAssuranceLever” or the like in order to avoid confusion.

[0101] In other embodiments, in order to further address the provision of assurance levels per application type / service type, the certificate format of the authorization ticket can be modified as shown in bold and strikeout in Table 5 below:

[0102]

[0103]

[0104] Table 5: Modified authorization ticket

[0105] Thus, by using the structure of Table 5, the assurance level per application type or service type can be specified.

[0106] In another embodiment, it can be desirable to avoid designing each ECU with SOTIF assurance levels for V2X applications with cybersecurity, functional safety, or the highest requirements, as this would be unnecessarily expensive. Thus, in some cases, it can be beneficial to determine the trustworthiness according to the specific application type related to a given V2X message.

[0107] Thus, according to this further embodiment, assurance level information can be provided within the eight bytes reserved for encoding the SSP. Referring now to Figure 4 , Figure 4 A format 410 of the transmitted octets is shown, in which three octets are transmitted, namely octet 0, octet 1, and octet 2. These octets can be used to encode functional safety, cybersecurity, and / or assurance levels, as described below.

[0108] Octet encoding for functional safety

[0109] One example use of the application is the application of "Road and Lane Topology (RLT)". This type of information can be sent or received by vehicles and it can be important for a vehicle to believe that the sender is security certified, as incorrect road topology can lead to errors for other vehicles that cannot determine such topology using their own sensors, but still need to use this information for maneuver planning. However, this application is for illustration only and other applications are possible.

[0110] To encode the safety level without introducing a new field in the RLT message, the last octet of the defined SSP octet string has its last four bits set to signal the lowest safety certification, one for each of the Automotive Safety Integrity Levels (ASILs). If only ASIL A certification of the transmitting vehicle is implemented, then only bit 0 of the safety octet is set to 1 (i.e., 1,0,0,0), all other bits are set to 0. If ASIL D, then all the first four bits are set to 1 (or the four bits can be set to 0,0,0,1).

[0111] For example, ETSI TS Draft 103 301 v.1.3.3 section 5.4.3.2 can be modified as shown in Table 6 below in bold:

[0112] Octet Description Value 0 SSP version control 1 1-2 Service specific parameters See Table 7

[0113] The octet scheme service parameters for the RLT service SSP are defined in Table 7 below, which is supplemented in bold:

[0114]

[0115] Table 7: RLT service communication profile

[0116] The example of Table 6 and Table 7 is one possibility. However, other alternative encodings can also be used. For example, the first two bits can be used to signal the lowest safety level value by four values 0, 1, 2, and 3, each representing ASIL A, B, C, or D, respectively.

[0117] In another alternative, the spare bits within the first octet can be used for the same purpose.

[0118] Other encoding options are possible.

[0119] Octet encoding for network security

[0120] An example use case for the application is RLT application. This type of information can be sent or received by a vehicle. To encode the network security level without introducing new fields in the RLT message, the last octet of the defined SSP octet string can be set to signal the minimum security authentication, one of each of the network security assurance levels provided by, for example, ISO 21434 CAL or ETSI defined TAL. According to embodiments of the present disclosure, examples are provided regarding CAL, but can equally apply to TAL.

[0121] If only CAL 1 authentication of the transmitting vehicle is implemented, then only bit 0 of the network security octet is set to 1, all other bits are set to 0. If CAL 4 authentication of the transmitting vehicle is implemented, then all first four bits are set to 1 (or the 4 bits can be set to 0,0,0,1).

[0122] Other alternative encodings are possible. For example, the first two bits signal the minimum network security level by the 0, 1, 2, and 3 four values, each representing CAL 1, 2, 3, or 4, respectively.

[0123] Other options are possible as well.

[0124] For example, ETSI TS Draft 103 301 v.1.3.3 section 5.4.3.2 can be modified as shown in Table 8 below in bold.

[0125] Octet Description Value 0 SSP version control 1 1-2 Service specific parameters See Table 9

[0126] Table 8: Octet scheme service parameter for RLT service SSP is defined in Table 9 below, which is complemented by the following table with the additions in bold:

[0127]

[0128]

[0129] Table 9: RLT service communication profile

[0130] For completeness, in Table 9 above mentioning ISO 21434 CAL, this can also be some other network security assurance level, including but not limited to car2Car alliance TAL or generic standard ISO 15408 EAL.

[0131] Encoding of SOTIF can also take a similar approach, although in this case only two values need to be encoded: for example, “release accepted” or “release not accepted”.

[0132] Other options are possible as well

[0133] If a guarantee level subdivision is provided for each of cybersecurity, FuSA, and SOTIF, the number of possible combinations that can need to be signaled is at most 5 x 5 x 2 = 50. Thus, this requires the use of 6 bits in the most efficient possible encoding. Specifically, there are 5 cybersecurity levels (TAL 0, 1, 2, 3, 4 or CAL 1, 2, and 3, 4) and 5 FuSa levels (QM, ASIL A, ASIL B, ASIL C, ASIL D) and 2 SOTIF levels (“SOTIF-related release acceptance evidence was prevented from being submitted to the CA”, “SOTIF-related release acceptance evidence was not submitted to the CA”).

[0134] However, only certain combinations of these three guarantees can be supported, so the total number of combined guarantees is actually less than 50. For example, if industry participants agree that an application needs at least CAL 2, ASIL B, and “proof” SOTIF levels, some possible combinations can be excluded.

[0135] Based on the above, various encodings can be used to transmit fusaAssuranceLevel and / or sotifAssuranceLevel. Again referring to Figure 3 .

[0136] Upon receiving message 350, ITS-S sending entity 310 can send a V2X message (shown as SecuredMessage 360) to another ITS-S in the intelligent transportation system, such as ITS-S receiving or relaying entity 312. In wishing to send a V2X message, ITS-S sending entity 310 typically creates a V2X message, which includes a certificate (authorization ticket) and a payload (e.g., vehicle current location, speed); computes a fixed-length hash of the variable-length V2X message using a well-known hash algorithm; signs the hash using the ITS-S sending entity’s private key; and appends the signature to the payload and sends the resulting V2X message. In this case, the authorization ticket includes the new FuSa and / or SOTIF guarantee level parameters described above.

[0137] Upon receiving message 360, ITS-S receiving or relaying entity 312 typically applies the certificate authority’s known public key to the signature block of the certificate to verify the sending entity’s identity and the sending entity’s public key.

[0138] ITS-S receiving or relaying entity 312 is pre-programmed with a FuSa (ASIL) level that the receiving vehicle’s designer believes is necessary for a given application. As used herein, this level is designated as the “demanded ASIL level”.

[0139] Thus, when receiving message 360, ITS-S receiving or relaying entity 312 will check to determine if the message satisfies the demanded ASIL level. Referring now to Figure 5 .

[0140] Figure 5 The process starts at block 510 and proceeds to block 512 where ITS-S receiving or relaying entity 312 determines if a V2X message has been received. If not, the process will continue looping to block 512 until a V2X message is received.

[0141] Once a V2X message is received, the process proceeds to block 520 where a check is made to determine if the fusaAssuranceLevel (ASIL) of the V2X transmitter (e.g., ITS-S sending entity 310 discovered from message 360) is greater than or equal to the demanded ASIL level of the receiving entity.

[0142] If so, the process proceeds from block 520 to block 530 where the receiving V2X application can take action on the V2X message content without needing to take any corresponding mitigation action, at least from a FuSa perspective.

[0143] For example, if the V2X application is an emergency braking warning application, then at block 530 the message content is trusted and the brakes can be applied hard, even though this can cause a lesser accident than if the brakes were not applied hard.

[0144] Conversely, if the check at block 520 determines that the fusaAssuranceLevel (ASIL) of the V2X transmitter is lower than the demanded ASIL level of the receiving entity, then mitigation measures can be required as shown at block 540.

[0145] For example, in the case of an emergency braking warning application, the message content at block 540 is less trustworthy than at block 530. In this case, the brakes can still be applied more gently before waiting for further corroborating evidence, such as visual evidence of a vehicle ahead applying its brakes in an emergency manner.

[0146] In some cases, the greater the difference between the authenticated fusaAssuranceLevel and the demanded ASIL level, the more cautious the receiving entity is in reacting to the message, and thus the degree to which the message can be responded to can be reduced. For example, if there is a large difference between the two levels, the vehicle can not apply any braking, but can instead pre-charge the brakes. This can involve, for example, priming the hydraulic system, and increasing the force and speed at which the brakes are depressed when a human driver or autonomous robot does depress the brakes. Other options are possible.

[0147] From block 530 or block 540, the process proceeds to block 550 and ends.

[0148] Similarly, if the message 360 contains a sofitAssuranceLevel, the receiving entity can check to determine if that level is “SOTIF-accepted release of evidence.” Referring now to Figure 6 .

[0149] Figure 6 The process of FIG. 6 begins at block 610 and proceeds to block 612, where the ITS-S receiving or relaying entity 312 determines whether a V2X message has been received. If not, the process will continue to loop to block 612 until a V2X message is received.

[0150] Once a V2X message is received, the process will proceed to block 620, where a check is made to determine if the sofitAssuranceLevel is “SOTIF-accepted release of evidence.” If so, the process proceeds from block 620 to block 630, where the receiving V2X application can proceed to the V2X message content without taking any corresponding mitigation measures. For example, using an emergency braking warning application, the received message content is trustworthy, and the brakes can be depressed with force, even though this can result in a less severe accident than if the brakes were not depressed with force.

[0151] Conversely, if the check of block 620 determines that the sofitAssuranceLevel is “not SOTIF-accepted release of evidence,” the process proceeds from block 620 to block 640, where mitigation measures can be required. For example, in the case of an emergency braking warning application, the message content is less trustworthy. The brakes can be braked more gently until further evidence is confirmed that the vehicle in front is actually braking in an emergency.

[0152] From block 630 or block 640, the process proceeds to block 650 and ends.

[0153] Further, if the message 360 contains a combination of assurance levels, such as (cybersecurity) assurance level, fusaAssuranceLevel, and / or sotifAssuranceLevel, the receiving entity can check to determine if these levels meet the minimum requirements. Referring now to Figure 7 .

[0154] Figure 7 The process begins at block 710 and proceeds to block 712, where the ITS-S receiving or relaying entity 312 determines if a V2X message has been received. If not, the process will continue to loop to block 712 until a V2X message is received.

[0155] Once a V2X message is received, the process proceeds to block 720, where a check is made to determine if all assurance levels meet the minimum requirements determined by the designer of the entity hosting the V2X receiver. For example, the minimum requirements can include a SOTIF assurance level of “acceptable release,” an ASIL level above a certain value, a cybersecurity level above a certain value.

[0156] If so, the process proceeds from block 720 to block 730, where the receiving V2X application can take action on the V2X message content without taking any corresponding mitigation measures. For example, using an emergency braking warning application, the received message content is trustworthy and the brakes can be slammed, even though this can cause a less severe accident than if the brakes were not slammed.

[0157] Conversely, if the check at block 720 determines that the minimum requirements are not met, the process proceeds from block 720 to block 740, where mitigation measures can be required. For example, in the case of an emergency braking warning application, the message content is less trustworthy. The brakes can be applied more gently until further evidence is confirmed that the vehicle ahead is actually braking in an emergency.

[0158] The mitigation measures of block 740 can depend on the degree to which the minimum requirements are not met. For example, in one embodiment, the degree of mitigation measures to be taken is the greatest mitigation measure of any of the specified “unequal tests” in functional safety, SOTIF, and cybersecurity, as defined in Figure 5 and Figure 6 .

[0159] In another embodiment, if multiple tests fail, the specified mitigation is even greater than the mitigation for any individual test failure. For example, in one embodiment, when an individual FuSa test or an individual SOTIF test fails, the brakes can be applied more gently. However, if both the FuSa and SOTIF “unequal tests” fail, the vehicle can not apply the brakes at all, but can pre-charge the brakes, which means that when the human driver or automated machine finally applies the brake pedal, the brakes can be faster and have enhanced force.

[0160] From block 730 or block 740, the process proceeds to block 750 and ends.

[0161] Aggregate Assurance Level

[0162] In another embodiment, for each of cybersecurity, FuSa, and / or SOTIF, an aggregate assurance level (AAL) can be provided, rather than providing assurance level subdivisions in a message such as message 360.

[0163] One example of an aggregate assurance level is shown in Table 10 below.

[0164]

[0165] Table 10: Example of Possible Aggregate Assurance Levels

[0166] However, the example of Table 10 is for illustration only, and other similar aggregate table designs will be apparent to those skilled in the art in view of this disclosure. Thus, the example of Table 10 is for illustration only of how a potentially large set of combinations can be reduced to a smaller number of aggregate assurance levels.

[0167] In further embodiments, the AAL numbers in Table 10 can be associated with words that indicate a trust level, such as “low,” “medium,” “high,” and so on.

[0168] With such aggregate assurance levels, the certificate format currently defined in IEEE 1609.2 and the corresponding ETSI specification can remain unchanged, but the meaning of assuranceLevel can be redefined. In particular, assuranceLevel can be associated with an aggregate assurance level, rather than with the cybersecurity (TAL) level currently used.

[0169] In particular, in the existing scheme, the assurance level associated with a given V2X module specification ID is stored in a database accessible from the registration authority. In the embodiments described herein, the meaning of this assurance level will change.

[0170] A message associated with such a change can be as follows. Reference is made to Figure 2When the authorization authority 216 sends the registration authority 214 an AuthorizationValidationRequest message 232, the registration authority 215 responds with an AuthorizeationValidationResponse message 234, which includes confirmedSubjectAttributes, one of which is now the assuranceLevel with a new meaning. The assuranceLevel is provided in the authorization ticket provided by the IT S-S to the entity 210 by the authorization authority 216.

[0171] At the receiving entity, a decision needs to be made as to what action should be taken based on the new given "trust level" or "aggregated assurance level". As used herein, the terms "trust level" and "aggregated assurance level" can be used interchangeably, as can similar terms.

[0172] Such a decision based on a given trust level is shown in Figure 8 Figure 8 An emergency braking warning application scenario is shown. However, the use of an emergency braking warning application is provided as an example only, and other applications can similarly use the aggregated assurance level or trust level.

[0173] Figure 8 The process of FIG. 8 begins at block 810 and proceeds to block 812, where the receiving entity determines whether a V2X message has been received. If not, the process will continue to loop to block 812 until a V2X message is received.

[0174] Once a V2X message is received, the process will proceed to block 820, where a check is made to determine whether the authentication trust level of the received message is greater than or equal to 3. If so, the process can proceed from block 820 to block 822, where the receiving V2X application can take action on the V2X message content without taking any corresponding mitigation action. In the example of an emergency braking warning application, the message content is trusted and the brakes can be slammed, even though this can cause a lesser accident than if the brakes were not slammed.

[0175] Conversely, if the authentication trust level is not greater than or equal to 3, the process will proceed to block 830, where a check will be made to determine whether the authentication trust level is equal to 2. If so, the process proceeds to block 832, where some mitigation action can be taken. For example, the brakes can be tapped before further corroboration, such as visual evidence that the vehicle ahead actually slammed the brakes, is available.

[0176] ​If the check of block 830 determines that the authentication trust level is not equal to 2, then the process proceeds to block 840, where the authentication trust level must be equal to 1. Then, the process proceeds to block 842, where more severe mitigation measures can be taken. For example, the vehicle can not apply any braking, but can pre-charge the brakes. Pre-charging the brakes can include priming the hydraulic system, and increasing the force and speed at which the brakes are depressed when a human driver or autonomous robot does depress the brakes.

[0177] From blocks 822, 832, or 842, the process proceeds to block 850 and ends.

[0178] Regarding encoding of the aggregate assurance level or trust level, all of the methods discussed above regarding Figure 3 or Figure 4 encoding of the assurance level in a certificate can be applied to encoding of the aggregate assurance level and trust level.

[0179] This includes redefining the meaning of the assurance level in a certificate in one embodiment.

[0180] In another embodiment, the encoding can include the aggregate assurance level or trust level as an item in the appPermissionsAndAssurance information element.

[0181] In another embodiment, encoding of the aggregate assurance level can include such an item in the SSP information element, for example as Figure 4 described. Specifically, if the aggregate assurance level or trust level approach is used, this information can also be encoded within the octet associated with the SSP. For each possible PSID / SSP combination, the same encoding for the assurance level(s) can be selected.

[0182] Handling privacy concerns

[0183] In some cases, privacy can be a concern with the above-described embodiments. Specifically, adding a FuSa level or SOTIF level to a certificate can reduce the privacy of a vehicle transmitting a V2X message. This problem can be more pronounced for different applications if there are different values. This information, combined with other static or semi-static information in the message, can provide a “fingerprint” that is specific to a particular vehicle model, making vehicle tracking easier.

[0184] In a first embodiment, one option to overcome the privacy concern is to issue two sets of authorization tickets / anonymity certificates to the ITS-S. The first set of tickets has an authorization level, while the other set does not. In this case, the set with the security assurance level is used when the message to be transmitted is guaranteed to have such a security assurance level. For example, when the V2X message is used to support a road safety application, or if the message content is incorrect, it can impact safety.

[0185] If a message is to be sent that is not considered safety critical, a certificate can be used that does not reveal this information about the transmitting vehicle. In this approach, the vehicle needs two sets of temporary certificates, which will increase the number of certificates needed by the vehicle.

[0186] In a first embodiment, safety assurance information can be provided when transmitting a Decentralized Environmental Notification Message (DENM) emergency brake warning message. Such a message can cause the receiving vehicle to initiate.

[0187] Instead, the safety assurance information can be waived by four periodic CAM / BSM messages that provide status updates and can be considered less safety critical.

[0188] In another embodiment, the “aggregated assurance” level approach described with respect to Table 10 can have a privacy advantage in that there are fewer data elements in the message fingerprint of the vehicle. In other words, if the only assurance information included in the message is that the overall trust is high from a selection of high, medium, or low, and the details included in the fingerprint are few, it is difficult to distinguish or track the vehicle because the “high” trust setting is common to many vehicles.

[0189] Other assurance levels can be defined that are applicable to each application or use case, and these levels will also reduce the ability to track vehicles based on the fingerprint because this assurance aspect of the fingerprint is the same for all vehicles using the fingerprint. However, a drawback of this approach is the need for industry agreement, which can or can not happen, and can result in delays, depending on whether the transmitter designer can make some independent decision on the assurance to be provided, and the receiver designer can also make some independent decision on how to handle the message based on the assurance level claimed by the transmitter.

[0190] Optionally, if the transmitting vehicle has a higher assurance level than the minimum required for the application, either determined by the transmitter designer or determined by some industry consensus by some industry association, the certificate can include an indication of the lower assurance level, where the motivation for this is to better protect privacy. Specifically, many or most vehicles will adopt such a lower assurance level, thereby reducing the risk of a unique “fingerprint” of the transmitting vehicle.

[0191] Using a lower assurance level can also change the behavior of the registration authority and / or the authorization authority, resulting in the authorization authority issuing an authorization ticket for a given assurance level that is lower than the assurance performance that the V2X transmitter is certified for. Either the registration authority or the authorization authority can lower the assurance level.

[0192] SOTIF assurance provided in the V2X message body

[0193] In another embodiment, as an alternative to providing security assurance information (such as FuSa and / or SOTIF) in the certificate, this information can be provided in the V2X message body.

[0194] In particular, the V2X message body can be enhanced with an information element indicating the SOTIF level. For example, this can be a binary value taking one of “Product intended functional safety excluded from release by independent auditing CA” or “Independent auditing CA did not exclude product’s intended functional safety from release”.

[0195] In other examples, the V2X message body can be enhanced with an information element indicating an aggregated security assurance level. In this case, for example, the aggregation can be done across functional safety and SOTIF.

[0196] In another example, the V2X message body can be enhanced with an information element indicating an aggregated network security and safety assurance. In this case, the aggregation can be done between functional safety, SOTIF and network security. One example of such an aggregation is shown below with respect to Table 11.

[0197] Trust level Guaranteed authentication requirements 1 (Low) FuSa ASIL level A or SOTIF "no release accepted proof" 2 (Medium) ASIL level between B and C and SOTIF "release accepted" 3 (High) ASIL level D and SOTIF "release accepted"

[0198] Table 11: Example of possible “trust level” definitions

[0199] However, the example of Table 11 is for illustration purposes only, and in other embodiments different definitions of such trust levels are possible.

[0200] Hardware

[0201] The V2X entity, V2X client, registration authority, certificate authority, authorization authority or network server or node can be any type of computing device. For example, with respect to Figure 9 , a simplified computing device is provided that can perform the above-described embodiments.

[0202] In Figure 9 , the computing device 910 includes a processor 920 and a communication subsystem 930, where the processor 920 and the communication subsystem 930 cooperate to perform the methods of the embodiments described herein.

[0203] The processor 920 is configured to execute programmable logic, which can be stored together with data on the computing device 910, and in Figure 9The memory 940 is shown in the example of FIG. 9 as being internal to the computing device 910. The memory 940 can be any tangible, non-transitory computer- readable storage media, such as DRAM, Flash, optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art. In one embodiment, the processor 920 can also be implemented entirely in hardware and need not have any stored program to perform the logical functions.

[0204] Alternatively or in addition to the memory 940, the computing device 910 can access data or programmable logic from external storage media, such as through the communication subsystem 930.

[0205] The communication subsystem 930 allows the computing device 910 to communicate with other devices or network elements.

[0206] In one embodiment, communication between the various elements of the computing device 910 can be through an internal bus 960. However, other forms of communication are possible.

[0207] The embodiments described herein are examples of structures, systems or methods having elements corresponding to the elements of a technology of this application. The written description can enable one skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of a technology of this application. Thus, the intended scope of the technology of this application is not limited to the embodiments described herein but is in accordance with the scope of the claims, including other structures, systems or methods that are within the scope of the claims.

[0208] Although operations are described in a particular, sequential order, this should not be understood as requiring that such operations be performed in the described order, or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products. In some circumstances, functions can be performed in hardware, and such solutions can be equivalent in function to software solutions.

[0209] Also, techniques, systems, subsystems, and methods described and illustrated in the various implementations as discrete or separate can be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as separate from other items or determining entities can be implemented as integrated with these other items or entities without departing from the scope of the present disclosure. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and can be made without departing from the scope of the present disclosure.

[0210] While the above detailed description has shown, described, and pointed out the fundamental novel features of the disclosure as applied to various implementations, it will be understood that various omissions and substitutions and changes in the form and details of the systems described can be made by those skilled in the art without departing from the spirit of the disclosure. Furthermore, the order of method steps can be altered and the order of steps is not dependent on their order in the claims.

[0211] When sending a message to or from an electronic device, such operations can not be immediate or directly from a server. They can be delivered synchronously or asynchronously from a server or other computing system infrastructure that supports the devices / methods / systems described herein. The steps described above can include, in whole or in part, synchronous / asynchronous communications with the devices / infrastructure. Further, the communications can be from the electronic device to one or more endpoints on a network. These endpoints can be served by servers, distributed computing systems, stream processors, and the like. Content delivery networks (CDNs) can also provide the communications to the electronic device. For example, rather than a typical server response, the server can also provide or instruct data for a content delivery network (CDN) to await later download by the electronic device, such as a subsequent activity of the electronic device. Thus, data can be sent directly from a server or other infrastructure, such as a distributed infrastructure or a CDN, that is part of the system or independent of the system.

[0212] Generally, a storage medium can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (DRAM or SRAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and flash memory; a magnetic memory device including a tape, a hard disk drive, a floppy disk; another magnetic medium; an optical medium, including a compact disk, a digital video disk (DVD), and the like; and the like. Note that the above instructions can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on a plurality of computer-readable / machine-readable storage media distributed in a large system having possibly a plurality of nodes. Such computer-readable or machine-readable storage medium is considered to be a part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be either located on a machine that runs the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

[0213] In the above description, numerous details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations can be practiced without some or all of these details. Other implementations can include modifications and variations from the details discussed. The appended claims are intended to cover such modifications and variations.

Claims

1. A method at an Intelligent Transportation System, ITS, entity, the method comprising: receiving a message from a second ITS entity, the message containing a safety assurance indication, the safety assurance indication relating to at least one of functional safety of a transmitter of the second ITS entity and safety of an intended function of the second ITS entity in an authorization ticket or an authorization certificate issued by an authorization authority, the safety assurance indication specifying that at least one of hardware and software at the second ITS entity that caused the message to be generated is authenticated as an indicated value; and using information from the message and the indicated value within the safety assurance indication, performing an action at the ITS entity based on requirements of an application at the ITS entity.

2. The method of claim 1, wherein the safety assurance indication is at least one of a functional safety assurance level indication and an intended function safety assurance level indication.

3. The method of claim 1, wherein: when the safety assurance indication relates to the functional safety of the transmitter of the second ITS entity, the safety assurance indication is an aggregation of a functional safety assurance level indication and at least one of: an intended function safety assurance level indication; and a network safety assurance level indication; and when safety assurance indication relates to the safety of the intended function of the second ITS entity, the safety assurance indication is an aggregation of the intended function safety assurance level indication and at least one of: the functional safety assurance level indication and a network safety assurance level indication.

4. The method of claim 1, wherein the authorization ticket is issued by the authorization authority based on an independent third party that verifies the safety assurance indication.

5. The method of claim 1, wherein the safety assurance indication is associated with a particular application or service.

6. The method of claim 1, wherein the safety assurance indication is encoded in an octet for a Service Specific Permission, SSP.

7. The method of claim 1, wherein the message is one of a plurality of messages received at the ITS entity, wherein only messages that convey safety information include the safety assurance indication.

8. The method of claim 1, wherein performing the action comprises: responding to the message at the ITS entity when the safety assurance indication is at or above a minimum threshold level; and mitigating a response to the message at the ITS entity when the safety assurance indication is below the minimum threshold level.

9. The method of claim 8, wherein the message includes a plurality of safety assurance indications, and wherein a degree of mitigation of the response depends on a number of safety assurance indications that are below the minimum threshold level.

10. An Intelligent Transportation System, ITS, entity, the ITS entity comprising: a processor; and a communication subsystem, wherein the ITS entity is configured to: ​ ​ receive, using the communication subsystem, a message from a second ITS entity, the message including a safety assurance indication, the safety assurance indication relating to at least one of functional safety of a transmitter of the second ITS entity and safety of an intended function of the second ITS entity in an authorization ticket or authorization certificate issued by an authorization authority, the safety assurance indication specifying that at least one of hardware and software at the second ITS entity that generated the message being generated is authenticated as an indicated value; and perform, using the processor, an action at the ITS entity based on requirements of an application at the ITS entity using information from the message and the indicated value in the safety assurance indication.

11. The ITS entity of claim 10, wherein the authorization ticket is issued by the authorization authority based on an independent third party that verifies the safety assurance indication.

12. The ITS entity of claim 10, wherein the safety assurance indication is at least one of a functional safety assurance level indication and an intended function safety assurance level indication.

13. The ITS entity of claim 10, wherein: when the safety assurance indication relates to the functional safety of the transmitter of the second ITS entity, the safety assurance indication is an aggregation of a functional safety assurance level indication and at least one of: an intended function safety assurance level indication; and a network safety assurance level indication; and when safety assurance indication relates to the safety of the intended function of the second ITS entity, the safety assurance indication is an aggregation of the intended function safety assurance level indication and at least one of: the functional safety assurance level indication and a network safety assurance level indication.

14. The ITS entity of claim 10, wherein the safety assurance indication is associated with a particular application or service.

15. The ITS entity of claim 10, wherein the safety assurance indication is encoded in an octet for a service specific permission, SSP.

16. The ITS entity of claim 10, wherein the message is one of a plurality of messages received at the ITS entity, wherein only messages that convey safety information include the safety assurance indication.

17. The ITS entity of claim 10, wherein the ITS entity is configured to perform the action by: responding to the message at the ITS entity when the safety assurance indication is at or above a minimum threshold level; and mitigating a response to the message at the ITS entity when the safety assurance indication is below the minimum threshold level.

18. The ITS entity of claim 17, wherein the message includes a plurality of safety assurance indications, and wherein a degree of the mitigating the response depends on a number of safety assurance indications that are below the minimum threshold level.

19. A computer readable medium for storing instruction code that, when executed by a processor of an intelligent transportation system, ITS, entity, causes the ITS entity to: receiving a message from a second ITS entity, the message including a safety assurance indication relating to at least one of functional safety of a transmitter of the second ITS entity in an authorization ticket or authorization certificate issued by an authorization authority and safety of an intended function of the second ITS entity, the safety assurance indication specifying that at least one of hardware and software at the second ITS entity that causes the message to be generated is authenticated as an indicated value; and performing an action at the ITS entity based on requirements of an application at the ITS entity using information from the message and the indicated value in the safety assurance indication.

Images