WO2021104651A1

WO2021104651A1 - Devices and methods providing contextualized identity for privacy-preserving communications

Info

Publication number: WO2021104651A1
Application number: PCT/EP2019/083167
Authority: WO
Inventors: Xun XIAO; Artur Hecker
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2019-11-29
Filing date: 2019-11-29
Publication date: 2021-06-03

Abstract

A communication device, in particular for use in Vehicle-to-everything (V2X) applications is described, which is configured to receive, from one or more infrastructure entities, Context Data (CD) entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and send a message, wherein the message is signed based on a subset of the received CD entries. Further, an infrastructure entity is configured to connect to one or more communication devices, in particular User Equipment (UE), generate, for each communication device, a set of CD entries, wherein each CD entry is specified for that communication device and is indicative of a spatiotemporal context of that communication device, and send a message to a communication device, the message indicating the set of CD entries specified for that communication device, signed with the private key of the infrastructure entity.

Description

DEVICES AND METHODS PROVIDING CONTEXTUALIZED IDENTITY FOR PRIVACY-PRESERVING COMMUNICATIONS

TECHNICAL FIELD

The present disclosure relates generally to the field of wireless mobile communication, and particularly to infrastructure contextualized identity for secure and privacy preserving Vehicle-to-Everything (V2X) communications. To this end, the present disclosure presents a communication device, in particular a UE, for use in Vehicle-to- everything (V2X) applications. The communication device receives context data entries from infrastructure entities, and sends a message that is signed based on a subset of the received CD entries. Further, the present disclosure presents an infrastructure entity for generating CD entries that are specified for that communication device. BACKGROUND

Generally, the emerging field of V2X communications will not be successful without the consideration of the typical cyber-threats. As with any communications between remote, software-driven objects, typical security issues are well described within the Dolev-Yao threat model, which assumes, in short, that attackers carry all the messages. This includes, for example, replay, man-in-the-middle, impersonation, data modification, snooping attacks, etc. Another possible attack is denial-of-service, where given entities get cut off from possibly critical services. Additional threat scenarios are also known, for example, from ad-hoc and sensor networks research, and involve so- called collusion, warp/wormhole and mafia fraud attacks.

Though variants of different such attacks are proven to be technically possible in computer and telecom networks, in particular in the wireless networks, there are also straightforward commercial, societal, reputational, comfort and time incentives for the attackers in the V2X communications reality context, for example:

• A driver in hurry could forge particular V2X messages to free up his lane, • A fraudster could produce forged message sequences to justify his innocence after an accident,

• “Script kiddies” or interest groups could slow down, block or redirect traffic at will, including remotely,

• drivers could impersonate as other drivers, e.g., at toll collection points, and

• Traffic control systems could be tricked to believe in more dense traffic by creating “phantom cars”.

With the increasing reliance on Information Technology (IT) and software and the well- established understanding of the reality of IT operations in the open environments, such as public networks but also public roads, these issues, if not resolved, have the potential to completely prevent V2X communications from ever taking off in practice.

Furthermore, at the same time, the privacy of the users (in particular of the drivers and the passengers of the cars, possibly also of the payload of trucks) deserves a special consideration, as the Intelligent Transport System (ITS) security measures should not be abused to track users, to establish driver logbooks or to unilaterally produce driver profiles from the security data.

Conventional devices and methods are based on introducing strong entity authentication schemes, e.g., based on per object vetted long-term identifiers (service by authorization after authentication). Here, every participant in the system (e.g., vehicles or infrastructure objects or entities such as traffic control systems, active road signs, etc.) obtains a unique, long-term identifier along with a unique proof valid for that exact identifier from some well-known, accepted authority.

Equipped with these, the participants use cryptographic network protocols (e.g., Datagram Transport Layer Security (D)TLS, Internet Protocol Security (IPsec), etc.) to mutually prove to each other their identities (mutual authentication) and, usually, to establish a shorter term message communication context in form of directed communication session keys exclusively available to and mutually agreed by exact those participants, who successfully went through the authentication. The authorizations to service usage, message sending, etc., are derived from this identity (valid/invalid, vehicle or infrastructure, type of operation, etc.), usually by set operations. The object- bound session keys are an engineering measure meant to increase the computational efficiency of the protection measures: without the session keys, the long-term credentials can be used to, for example, digitally sign messages sent by that entity.

SUMMARY

However, conventional devices and methods have the following disadvantages: Unclear trust model·. The existing schemes require the previous certification by a commonly trusted third party or a pre-configured group of such, e.g., in the form of root certificates of usable Public Key Infrastructures (PKIs) and their certification authorities. For instance, in the naturally international, multi-vendor V2X context involving multiple industry branches (car producers, public works companies for road and bridge construction, toll collect system providers and, generally, IT suppliers for road information/control systems) and different stakeholders (drivers, car manufacturers, and states (public) sector) agreeing on one single authority is not realistic. For instance, while the cars of manufacturer X can be only certified as such by this manufacturer, it is difficult for a car manufactured by Y to correctly verify X’s identity, as Y might not be equipped with X’s authority certificates. A typical solution for this is to establish a federation of the PKIs under some higher-level authority (e.g., the country) or cross certification of X and Y. As there are more than 20 competing car manufacturers, cross- certification is not realistic.

The situation is even worse in the given V2X scope, as cars by manufacturer X can drive in different countries and can cross borders. Furthermore, a car can be re-sold privately. Therefore, it is hard to foresee, in which countries any car will be used. Yet, different countries might have utterly different regulations for personal data protection, cryptography usage, tracking, etc. It would be extremely difficult to reunite such different policies under one single authority or a federation of the latter. In most cases, cross-certification between countries can be ruled out as well, for political or practical reasons.

The final situation, therefore, can be expected to be similar to the Web trust model, where each web browser is shipped with a user-extensible list of root certificates of the typically encountered PKIs, which act as authorities to confirm website identities. The web browser uses these authority root certificates to authenticate the different web sites presenting authority-signed certificates. Unfortunately, this model, even though well- established, is prone to many problems, exactly related to the actual lack of trust in the authorities: as the number of the accepted authorities increases, the security gets diluted or “washes out”. Indeed, it is not immediately clear, which authority certified a validated web site; more importantly, users do not understand, what the authority actually vets. In practice, the authorities only vouch for identities (in the case of Web, for the Fully Qualified Domain Names, FQDN), but not for the content of the website or the actual operations of the service behind it. With all this, a correctly verified web site does not have to function correctly; it can even be straightforward malicious. Users know this from experience and tend to disregard all security -related warnings as unimportant.

However, what works on the web, where the worst risks include financial fraud and loss of private data, might not be sufficient in the road context, where targeted attacks can lead to city- or country -wide havoc and human casualties. As the road infrastructure is a critical infrastructure, loose trust bindings seem insufficient: the verified identity of the car does not directly prove the appropriateness of its actions. In spite of the deterrence by successive fines due to the accountability of actions, drivers are known to produce situations more favorable to them by specific misbehavior.

Privacy for security sacrifice: By introducing long-term vetted identities used in V2X exchanges, the current schemes, and in particular the standard schemes, introduce new privacy risks. Indeed, any verifier could get important insights into the long-term identity information of the vehicles. Moreover, by combining this information with the visible behavior (e.g., from European Telecommunications Standards Institute (ETSI) Intelligent Transport Systems (ITS) Cooperative Awareness Message (CAM) or from direct observation through cameras), this, therefore, introduces new, unprecedented possibilities for driver tracking, behavior pattern collections, driver fingerprinting and wide-area traffic observation, which are considered illegal in some countries (e.g., Germany).

The ITS system tries to address these issues by relying on a whole list of vetted identities for any road participant and by rotating the identities as pseudonyms. However, in practice, it is very difficult to enforce privacy of drivers in systems based on strong entity authentication, as by design there are some central entities obtaining this data, which it would need to promise not to try to combine with other data, etc. This leads to only weak privacy guarantees.

Lack of relevance indicators : Although the current schemes allow different types of V2X communications, they do not address the important question of relevance. In a dynamic environment of Intelligent Transportation Systems (ITS) with changing participant sets, it is not crucial to know, who exactly sent the message, but, rather, whether this particular message corresponds to a real event and is of any interest to a receiver. While the conventional methods are preoccupied with the integrity and authenticity of messages, they do not solve the problem, whether a producing vehicle could have observed the event and whether any receiving vehicle should be interested in that at all.

In the conventional solutions, a participant has to run through many calculations and checks, just to find out that a message might come from an authentic, authorized vehicle yet moving, e.g., in an opposite direction, or on a parallel, lower, higher or otherwise inaccessible road, etc. Given the periodicity of the specified communications (e.g., CAM messages in ITS) and a high number of vehicles, e.g., in a dense, urban environment, it is not unreasonable to expect ITS participants to constantly receive messages, many of which are irrelevant for them. At the same time, given the actual complexity of the road infrastructure in the modem, hyper-urban environments, straightforward geographic position checks, as obtained, e.g., from positioning systems or high resolution image maps, may not be enough to judge the irrelevance of events from parallel roads, viaducts, tunnels, etc., as the longitude/latitude are in the same range. In practice, a receiving participant may need to judge the relevance through the comparison of the actual event information and its own position and direction (keywords: movement vector, bounding box). As ITS messages are meant for automatic processing, semantic decisions are a considerable technical barrier. They might result in many useless alerts to drivers in practice.

In view of the above-mentioned problems and disadvantages, embodiments of the present disclosure aim to improve the conventional devices and methods. An objective is to improve the security and privacy of ITS systems. To improve the security, the integrity of the messaging system and the question of contextual competence of any given participant to send any particular event report should be considered. Related to this, also the relevance of any ITS message to any given recipient should be considered. The users should be allowed to rapidly fdter out incorrect or irrelevant information. The objective is achieved by the embodiments provided in the enclosed independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.

The disclosure, at least in some parts, focuses on the privacy consideration for communication devices (e.g., moving vehicles or V2X devices carried onboard of the latter). For example, the privacy of the communication devices may be under the control of the communication device (the users of the communication devices).

Embodiments of the invention may provide the following advantages:

• Communication devices (e.g., vehicles) do not need long-term identities, which may help to improve the ITS privacy.

• There is no need for a commonly trusted authority or washed out, nay-saying trust models, etc.

• There is no need for the (complex) private key enrollment of the vehicles or V2X devices onboard of the latter.

• Sending V2X devices can prove their competence to testily of a particular event.

• Receiving V2X devices can verify the relevance of the event to them. A first aspect of the invention provides a communication device, in particular for use in Vehicle-to-everything (V2X) applications, the communication device being configured to receive, from one or more infrastructure entities, Context Data (CD) entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and send a message, wherein the message is signed based on a subset of the received CD entries.

The communication device may be, or may be incorporated in, for example, a UE. The communication device (e.g., the UE, a vehicle, a user of the communication device, a driver of the vehicle, etc.), in the V2X context, may have privacy needs. The infrastructure entity may be, or may be incorporated in, an infrastructure object, a base station, a road side unit, a car vendor provider (V2X App provided by a car vendor), a particular control plane function (e.g. a dedicated V2X enabled AMF) of the 3GPP core network, etc.. The infrastructure entity may be an entity that may not have privacy needs (e.g., public networks, public road infrastructures, and infrastructure objects, etc.). Consequently, long-term identities may only be used for public infrastructure entities, while it does not rely on entity or on attribute authentication for, e.g., the vehicles (or messages stemming from vehicles).

The communication device may receive the CD entries from one or more infrastructure entities. For example, the communication device may collect the CD entries from different infrastructures entities including, e.g., a road authority, a mobile network operator, etc. Besides, as long as it is using the same temporary identifier, these records may be combined in the same trace. Moreover, a vehicle may also use several temporary identifiers, producing several traces and use them. Moreover, all following exchanged ITS messages may include this context, for example, by cryptographically binding it to the message content, etc.

The CD entries for the communication device are indicative of a spatiotemporal context of the communication device. For example, the CD entries may be specifically generated for the (current) existing space and/or time information of the communication device, e.g., the location information and/or specific time information of the communication device. A spatiotemporal context may be (current) existing space and/or time information of the communication device, for example the location information and/or specific time information of the communication device. Furthermore, the communication device may use (sign the message) directly based on the CD entries, or use the CD entries, for example, for generating context information and include the context information to the message (e.g., for signing the message), or the like.

The ITS system may be divided in privacy-critical and privacy -uncritical entities. The privacy critical entities may include, e.g., cars, trucks, pedestrians, and more generally, objects moving with the users (i.e., drivers and/or passengers), if these objects participate in the ITS system exchanges. In the following, the privacy critical entities are generally called “vehicles”, which should not be wrongly misinterpreted as “only cars”. The privacy uncritical entities are parts of the public infrastructure involved in the ITS system (e.g., public networks/roads, road poles/delineators, network base stations, traffic control systems, toll collect points, etc.). In the following, privacy- uncritical entities are generally referred to as infrastructure entities.

Hereinafter, the terms “communication device” and “UE” and “vehicles” are used interchangeably. It should, however be clear, that the communication device can be any device suitable for establishing a communication, for instance in a telecommunication network. Such communication device may, in some implementations, be part of a vehicle or also a standalone device. Also, hereinafter, the terms “infrastructure entities” and “infrastructure objects” are used interchangeably. Also, hereinafter, the terms “CD entries” and “context information” are used interchangeably, which may refer to CD entries included, or generated based on the context information.

The communication device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein. In an implementation form of the first aspect, the CD entries are received over a limited channel.

In particular, the “limited” channel only means that communication on this channel is not reaching all system participants but only a (small) subset of these participants. Moreover, the infrastructure entities may build up limited channels with any requesting entity. For example, a vehicle moving along different infrastructure entities, which it can identify as legitimate using the authority information it possesses, may anonymously obtain signed context information from the infrastructure entities over the established limited channels. The context information records may be issued to a randomly generated, temporary identifier of that vehicle. Unlike in conventional ITS systems, this random and temporary identifier does not need to be vetted by any common authority (the transient public key is not signed by any PKI). Also, it may be disposed at any time, along with the context information collected for it. Furthermore, as long as the vehicle keeps the same temporary identifier, the time series of context information records issued for it may produce a trace, i.e., a spatiotemporal trajectory. Also, a correctly looking trace is hard to forge, and it becomes harder to forge over time, as long as the same temporary identifier is used.

The limited channel may be a secure channel (e.g., built up using the existing credentials of the communication device, if anyhow available) or a physically limited channel.

A secure channel may be a special limited channel that guarantees that there are only two verified participants on the (logical) channel; such a guarantee classically requires mutual authentication of participants, which is not always possible, as, in this disclosure, vehicles do not need to have long-term credentials.

A physically limited channel, e.g., a limited reach radio channel, may be built up using typical physical and link layer protocols. Such a channel does not have the guarantees of a secure channel, as it is possible that several entities are in the radio reach, but it also does not require long-term credentials, so as to be able to communicate. To further limit the reach, particular physical layer configurations (e.g., emission strength), protocols (e.g., NFC) and/or equipment (e.g., sector antennae), or some suitable physical layer targeting could be additionally used where applicable and supported by the network interface hardware and software (e.g., beam forming, visible or infrared light communications). In addition to the properties of the wireless channel, as implemented by the wireless channel hardware and software, the process of building up this channel may involve distance bounding protocols. The distance bounding protocols may use precise time measurements, so as to limit the maximum distance between a sender and a recipient. Therefore, distance bounding protocols can help to further limit the channel with distance guarantees.

In a further implementation form of the first aspect, the CD entries comprise one or more of: a random number or nonce sent from the communication device to a determined infrastructure entity, a signature of an infrastructure entity, a transient public key of the communication device, a transient identifier, in particular a temporary identifier of the communication device, a set of CD entries received from the one or more infrastructure entities, a certificate of an infrastructure entity.

In a further implementation form of the first aspect, the sent message indicates the subset of the received CD entries of the communication device and determined information.

In particular, it may be possible to contextualize (e.g., based on the CD entries) the V2X communications and to further use that context for verification purposes. For example, a communication device may select a determined information (e.g., a specific information, a predefined information, an event, an accident to be reported, a road condition information, etc.). Moreover, the subset of the received CD entries may be used for signaling that determined information and a message may be sent, which may be verified.

For example, it may not be crucial for V2X participants to know, who exactly sends or receives V2X messages. The validity of the message may be verified based on the subset of the CD entries. In other words, the “identity” of a vehicle may be, e.g., replaced by its V2X context (e.g., road name, position on the road, direction, speed, etc.), which the vehicle collects over time from the infrastructure entities that it encounters. The CD entries may be established securely (i.e., in a tamper-proof, hard to forge manner). The subset of CD entries may be bound to the actual V2X messages in an un-separable manner. For example, by establishing such context, it may be possible to establish the relative locality of senders and recipients to the reported event.

In a further implementation form of the first aspect, the communication device is further configured to send, to an infrastructure entity, a determined CD entry and/or determined information, and request the determined CD entry and/or determined information to be signed, receive, from the infrastructure entity, the determined CD entry and/or the determined information that is signed for the communication device, and sign the message based on the signed determined CD entry and/or the signed determined information.

In a further implementation form of the first aspect, the communication device is further configured to send, to the at least one other device, the message signed based on the signed determined CD entry and/or the signed determined information, and receive, from the at least one other device, a message indicating a verification state of the sent message.

In a further implementation form of the first aspect, the communication device is further configured to send, to a determined infrastructure entity, a message indicating a transient identifier, in particular temporary identifier of the communication device, and request a determined CD entry of the determined infrastructure entity to be signed for that transient identifier, in particular temporary identifier.

The transient identifier may be volatile, unconfirmed, and/or unvetted. The transient identifier is, in particular, not signed. A transient identifier can be produced and destroyed at will. The transient identifier may be a public key generated by a public -private key pair generating procedure, according to the used asymmetric cryptosuite. The used cryptosuite may use protocols of any well-established public key cryptosystem (e.g. El Gamal, DSS or RSA), it may use elliptic curve cryptography (ECC).

In a further implementation form of the first aspect, the communication device is further configured to receive, from another device, a message indicating a determined information, evaluate, based on its own CD entries, a competence of the other device for sending the determined information, and/or determine, based on its own CD entries, a relevance of the determined information to the communication device, in particular an interest for the received determined information.

In particular, the subset of the CD entries may be used for proving the competence of the other devices sent a message (information related to an observed event, e.g., an accident) by signing the sent message content with the subset of the CD entries.

Determining the competence of the sender may include determining, whether the sender could have observed, witnessed or experienced, what the sender is communicating. For example, the competence of the sender device (e.g., the vehicle really has passed this point at the reported time) may be verified by checking the correctness of the message signature and the semantic correspondence of the CD entries and the reported event (i.e., the determined information).

Determining the interest of the recipient to receive such information may include determining, whether the communicated information can be of any interest to the particular V2X receiver.

For example, the interest of the receiver device (checking the relevance of the reported information) may be done by processing its own movement vector, planned trajectory (e.g. from the navigation system), etc. (e.g., if the receiver device (vehicle) is also heading in the direction of the reported accident). In a further implementation form of the first aspect, the communication device is further configured to receive a message from another device, the message indicating determined information describing an event, concatenated with a set of CD entries received from one or more infrastructure entities the other device passed by.

In a further implementation form of the first aspect, the communication device is further configured to verify a validity of the received message based on performing one or more of: determining, whether all CD entries are correctly signed by some infrastructure entity, determining, whether public keys included in all CD entries are the same public key, determining, whether the signatures of all CD entries can be verified with the same public key of the other device, determining, whether the context data in the included CD entries indicates a competence of the other device to send the included actual message content.

In particular, the CD entries are usually not all signed by the same infrastructure entity, since this would indicated that the communication device is not moving. Also, the CD entries may be signed by different infrastructure entity, e.g. one CD entry may stem from an active road sign, another one from a paid toll system, the third one from a serving network base station, and yet another one from the manufacturer of a vehicle driving in parallel to the communication device.

In an embodiment, if the communication devices already possess long-term identifier (e.g. from a classical ITS system, from its manufacturers, etc.), it can also play the role of an infrastructure entity, i.e. they can in principle confirm the position of some unidentified object at some point in time.

In a further implementation form of the first aspect, each CD entry of the communication device is valid for one or more of a predefined time period, a predefined geographical location, a unique identifier of a device.

In a further implementation form of the first aspect, the communication device is a UE supporting CIE Function (CIEF), in particular a vehicle, wherein the infrastructure entity is based on a 3GPP core network function, in particular an Access and Mobility Management Function, AMF, supporting the CIG Function (CIGF), or a road infrastructure, in particular a Reflector Post (RP) supporting the CIGF, or a service provider supporting the CIGF, or an IEEE 802. lip Road Side Unit (RSU) with CIGP, in particular a backend authentication server of the IEEE 802.1 lp.

In a further implementation form of the first aspect, the communication device is further configured to receive, from the AMF, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and send a message, wherein the message is signed based on a subset of the received CD entries.

In a further implementation form of the first aspect, the communication device is further configured to send a signal to one or more RPs, receive, from at least one RP, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and send a message, wherein the message is signed based on a subset of the received CD entries.

In a further implementation form of the first aspect, the communication device is further configured to send a request to the service provider, receive, from the service provider, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and send a message, wherein the message is signed based on a subset of the received CD entries.

In a further implementation form of the first aspect, the communication device is further configured to connect to an authenticator (AP), and send a unique identifier to the AP in order to be authenticated, send, to one or more APs, local information of the communication device, in order to be forwarded to a backend authentication server, receive, via at least one AP, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and send a message, wherein the message is signed based on a subset of the received CD entries.

A second aspect of the invention provides a method for a communication device, in particular for use in Vehicle-to-everything (V2X) applications, the method comprising receiving, from one or more infrastructure entities, Context Data (CD) entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and sending a message, wherein the message is signed based on a subset of the received CD entries. In an implementation form of the second aspect, the CD entries are received over a limited channel.

In a further implementation form of the second aspect, the CD entries comprise one or more of: a random number or nonce sent from the communication device to a determined infrastructure entity, a transient public key of the communication device, a signature of an infrastructure entity, a transient identifier, in particular a temporary identifier of the communication device, a set of CD entries received from the one or more infrastructure entities, a certificate of an infrastructure entity.

In a further implementation form of the second aspect, the sent message indicates the subset of the received CD entries of the communication device and determined information.

In a further implementation form of the second aspect, the method further comprises sending, to an infrastructure entity, a determined CD entry and/or determined information, and requesting the determined CD entry and/or determined information to be signed, receiving, from the infrastructure entity, the determined CD entry and/or the determined information that is signed for the communication device, and signing the message based on the signed determined CD entry and/or the signed determined information.

In a further implementation form of the second aspect, the method further comprises sending, to the at least one other device, the message signed based on the signed determined CD entry and/or the signed determined information, and receiving, from the at least one other device, a message indicating a verification state of the sent message.

In a further implementation form of the second aspect, the method further comprises sending, to a determined infrastructure entity, a message indicating a transient identifier, in particular temporary identifier of the communication device, and requesting a determined CD entry of the determined infrastructure entity to be signed for that transient identifier, in particular temporary identifier.

In a further implementation form of the second aspect, the method further comprises receiving, from another device, a message indicating a determined information, evaluate, based on its own CD entries, a competence of the other device for sending the determined information, and/or determining, based on its own CD entries, a relevance of the determined information to the communication device, in particular an interest for the received determined information.

In a further implementation form of the second aspect, the method further comprises receiving a message from another device, the message indicating determined information describing an event, concatenated with a set of CD entries received from one or more infrastructure entities the other device passed by.

In a further implementation form of the second aspect, the method further comprises verifying a validity of the received message based on performing one or more of: determining, whether all CD entries are signed by the same infrastructure entity, determining, whether public keys included in all CD entries are the same public key, determining, whether the signatures of all CD entries can be verified with the same public key of the other device, determining, whether all CD entries in all CD entries providing a competence of the other device sending the message.

In a further implementation form of the second aspect, each CD entry of the communication device is valid for one or more of a predefined time period, a predefined geographical location, a unique identifier of a device.

In a further implementation form of the second aspect, the communication device is a UE supporting CIE Function (CIEF), in particular a vehicle, wherein the infrastructure entity is based on: a 3 GPP core network function, in particular an AMF, supporting the CIG Function, CIGF, or a road infrastructure, in particular a Reflector Post, RP, supporting the CIGF, or a service provider supporting the CIGF, or an IEEE 802.1 lp RSU, with CIGP, in particular a backend authentication server of the IEEE 802.1 lp.

In a further implementation form of the second aspect, the method further comprises receiving, from the AMF, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and sending a message, wherein the message is signed based on a subset of the received CD entries. In a further implementation form of the second aspect, the method further comprises sending a signal to one or more RPs, receiving, from at least one RP, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and sending a message, wherein the message is signed based on a subset of the received CD entries.

In a further implementation form of the second aspect, the method further comprises sending a request to the service provider, receiving, from the service provider, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and sending a message, wherein the message is signed based on a subset of the received CD entries.

In a further implementation form of the second aspect, the method further comprises connecting to an authenticator (AP), and sending a unique identifier to the AP in order to be authenticated, sending, to one or more APs, local information of the communication device, in order to be forwarded to a backend authentication server, receiving, via at least one AP, CD entries, wherein each of the CD entries is for the communication device and is indicative of a spatiotemporal context of the communication device, and sending a message, wherein the message is signed based on a subset of the received CD entries.

A third aspect of the invention provides an infrastructure entity configured to connect to one or more communication devices, in particular User Equipment (UE), generate, for each communication device, a set of Context Data (CD) entries, wherein each CD entry is specified for that communication device and is indicative of a spatiotemporal context of that communication device, and send a message to a communication device, the message indicating the set of CD entries specified for that communication device, signed with the private key of the infrastructure entity.

The infrastructure entity may be, or may be incorporated in, an infrastructure object, a base station, a road side unit, a car vendor provider (V2X App provided by a car vendor), a particular control plane function (e.g. a dedicated V2X enabled AMF) of the 3GPP core network, etc. For example, the infrastructure entities may be, or may include, active infrastructure entity, passive infrastructure entity, etc.

The active infrastructure entity may be, for example, a powerful and an electrically powered infrastructure object. It may store some state and might have backbone online connectivity to their infrastructure. Examples include network base stations or toll collect stations. The active infrastructure entity may proactively send their advertisements, i.e., without a previous request. They can do so periodically or based on some trigger (e.g., crossing some line, driving over some plate, etc.). These advertisements may be sent by a particular protocol or carried within other protocol messages that these objects already implement, if suitable.

The passive infrastructure entity may be, for example, a presumed resource-constrained entity and may operate, e.g., with a battery of a limited capacity, solar energy, or possibly without any power source. The passive infrastructure entity may not require any connectivity, except the local connectivity to the UE (to the vehicles over the limited channel). Examples include road posts, delineators, road signs, etc. In all cases, to limit the power consumption requirements, these objects do not send periodic advertisements, but rather act as “cryptographic reflectors”, which answer the requests sent by vehicles. In the case without power supply, they must harvest the energy from the message received from the vehicle.

The active infrastructure entity may be designed to add ITS functionality to other infrastructures (e.g., telecom networks). The passive infrastructure entity may be designed to be able to deploy cost-efficient road-side ITS infrastructures.

A fourth aspect of the invention provides a method for an infrastructure entity, the method comprising connecting to one or more communication devices, in particular User Equipment (UE), generating, for each communication device, a set of Context Data (CD) entries, wherein each CD entry is specified for that communication device and is indicative of a spatiotemporal context of that communication device, and sending a message to a communication device, the message indicating the set of CD entries specified for that communication device, signed with the private key of the infrastructure entity.

A fifth aspect of the invention provides a computer program which, when executed by a computer, causes the method of second aspect and/or fourth aspect to be performed.

In some embodiments, the computer program can be provided on a non-transitory computer-readable recording medium.

Note that the present invention does not challenge, obsolete or revoke existing long term identifiers: wherever vehicles, on-board units, drivers or smartphones already have long-term credentials, these can still be used in the respective scopes, in which these were established. For instance, if a car of manufacturer X is registered as Cl with the backend system of X (e.g., for drive assistance, infotainment and car maintenance services, etc.), this car may still be able to use Cl and the existing conventional solutions to get access to the services proposed by X for Cl. Besides, the backend system of X may implement the devices and methods of the present invention and play a role of an additional infrastructure provider.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which FIG. 1 is a schematic view of a communication device, according to an embodiment of the present invention;

FIG. 2 is a schematic view of an infrastructure entity, according to an embodiment of the present invention;

FIG. 3 is a schematic view of a diagram illustrating a CIGP interaction procedure;

FIG. 4 is a schematic view of a diagram illustrating a CIEP interaction procedure; FIG. 5 is a schematic view of a diagram illustrating contextualized identifiers with overlapped time windows;

FIG. 6 is a schematic view of a diagram illustrating the communication device communicating with an AMF in a 3 GPP core network function;

FIG. 7 is a schematic view of a diagram illustrating the communication device communicating with public road infrastructures;

FIG. 8 is a schematic view of a diagram illustrating the communication device communicating with a Car manufacturer OTT service provider;

FIG. 9 is a schematic view of a diagram illustrating the device being a UE supporting CIEF and the infrastructure object supporting an IEEE 802.11 Authentication Procedure;

FIG. 10 is a flowchart of a method for a communication device, according to an embodiment of the invention; and FIG. 11 is a flowchart of a method for an infrastructure entity, according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the description of the embodiments, the used notations are summarized in Table. 1 as follow:

Table 1. Notations of Cryptographical Operations

FIG. 1 is a schematic view of a communication device 100, according to an embodiment of the present invention.

The communication device 100 is in particular for use in V2X applications. The communication device 100 is configured to receive, from one or more infrastructure entities 110, CD entries 111, 112, wherein each of the CD entries 111, 112 is for the communication device 100 and is indicative of a spatiotemporal context of the communication device 100. Optionally, the CD entries may be based on object context data, context information, etc., without limiting the present discourse to a specific method of generating CD entries or different types of CD entries.

For example, the CD entries 111, 112 specified for the communication device 100 may be generated based on context descriptor of an infrastructure entity (objCD). The context descriptor of an infrastructure entity may include different information elements to describe the ITS relevant context information of that infrastructure entity. For example: objCD = (48°10'35.3"N 11°32'25.7"E) | DE-B304 | 10.1 | 13:14:33 CEST | 12345, where the objCD here comprises respectively: the geographic coordinates (latitude, longitude), the country code for the road that this object is part of (here: German federal road 304), the official road kilometer of that road at which the object resides, the exact current time and a sequence number. Different fields are concatenated into one string (as per notation in this document; in any given implementation, different data structures could be used).

The communication device 100 is further configured to send a message 101, wherein the message 101 is signed based on a subset of the received CD entries 111.

The message 101 may be signed using the CD entries (e.g., the objCD), directly, generating a context information (Cl) of the communication device 100 (e.g., Vehicle A) based on the CD entries and/or the objCD, etc., without limiting the present discloser to a specific method of signing the message (or using the received CD entries).

For example, the message 101 may be signed based on the set of set of CD entries which may be or may include the generating Cl of the communication device 100 and/or the objCD.

The Cl of the communication device 100 may be the concatenation of different context information records (Cli). The context information records may be CD entries (objCD entries) received from the infrastructure entities, personalized for the requesting communication device 100. The Cl of the communication device 100 (i.e., exemplary being the vehicle A) could be defined the following way:

CI(A) = CI(A)i I ... I CI(A)n, where CI(A)i = ( nonceA | pubKa | objCDi | certObji ){privKi}, where nonceA is the nonce from communication device’s request, pubKa is the temporary public key of the communication device 100 (e.g. vehicle A), objCDi is the objCD, certObji the certificate and privKi the private key of the ith infrastructure entity 110. The communication device 100 may be capable of executing typical cryptographic operations, e.g., public key operations or cryptographic hashing. For example, it may create a random temporary identifier in the form of a public -private key pair, (privKa and pubKa) of the communication device 100 (e.g., vehicle A).

After some time, the communication device 100 may discard some of the CD entries (objCD may be removed from the CI(A)), e.g., in case of road change they have no semantical meaning anymore, when arriving at the final destination, or just because of the expiration, CD entries may be discarded.

Moreover, since the CD entries (e.g., the context information) may be bound to one temporary identity A, the release of the latter should result in discarding the CD entries.

Optionally, the communication device 100 may not need any ITS-specific long-term identifier. For example, it may possible to dynamically create a transient identifier for the communication device 100.

Optionally, the communication device 100 may have a list of registered long-term identities with some service providers, such as with its network provider, with its toll collect company, with its backend service, with its application store, etc. In this case, the communication device 100 is assumed to be able to build up “limited channels” to the latter services using its long term credentials and the suitable protocols (classically, e.g., using private keys, certificates, TLS, etc.).

The communication device 100 may comprise a circuitry (not shown in FIG. 1). The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein. Reference is now made to FIG. 2, which is a schematic view of an infrastructure entity 110, according to an embodiment of the present invention.

The infrastructure entity 110 configured to connect to one or more communication devices 100, in particular UE.

The infrastructure entity 110 configured to generate, for each communication device 100, a set of CD entries 111, 112, wherein each CD entry 111, 112 is specified for that communication device 100 and is indicative of a spatiotemporal context of that communication device 100.

Optionally, the infrastructure entity 110 may generate CD entries such that, depending on the capabilities of the infrastructure entity, other semantical elements may be added to, or some elements may be removed from the CD entries (e.g., from the objCD when generating the CD entries based on the objCD).

The infrastructure entity 110 may generate the CD entries such that different CD entries (e.g., objCDs of a series) can be semantically combined (i.e., put in an at least partial order, yielding, for example, a trajectory in time or in sequence numbers). For that, the format of CD entries (e.g., objCDs) and its semantics (e.g., information model) must be well-known to all participants, i.e., beyond one single infrastructure type (e.g., as an information element defined in an ITS standard), and there should be some minimal subsets of common element types with known semantics.

The infrastructure entity 110 is further configured to send a message 114 to a communication device 100, the message 114 indicating the set of CD entries 111, 112 specified for that communication device 100, signed with the private key 113 of the infrastructure entity 110.

The message 114 indicating the set of CD entries 111, 112 specified for that communication device 100, may be signed with the private key 113 of the infrastructure entity 110. The infrastructure entity 110 may be capable of executing typical cryptographic operations, e.g., public key operations or cryptographic hashing, for example, for signing (with its private key 113) the message 114 indicating the set of CD entries 111, 112 specified for that communication device 100.

Optionally, the infrastructure entity 110 has a unique object identifier, called objID. The infrastructure entity 110 may be preconfigured with its private key privKObj, a certificate certObj issued for its objID (e.g., X.509 certificate), comprising a binding of this objID to the public key of the infrastructure entity 110 through the signature of an issuer. Moreover, the issuer (i.e., the CA of the PKI) is assigned by the owner of the infrastructure in question, for example, for public roads, it could be the regional road authority, the ministry of transport and the like. The latter authorities are presumed to be publicly known, i.e., their information and their root certificates can be discovered in suitable directories, over particular protocols like DNSSEC, on the Web, etc.

Besides the security configuration, the infrastructure entity 110 has its object context descriptor, called objCD (which may be used for generating the CD entries 111, 112).

Optionally, both the security and the context information can be fixed and preconfigured to the infrastructure entity 110. Alternatively, they can be dynamically obtained (e.g., calculated, updated (e.g. from object’s backend and/or using from other infrastructures, like GPS, GLONASS, GALILEO, etc.).

The infrastructure entity 110 may comprise a circuitry (not shown in PIG. 2). The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein. References are made to FIG. 3 and FIG. 4 which are a schematic view of a diagram illustrating a CIGP interaction procedure (FIG. 3) and a schematic view of a diagram illustrating a CIEP interaction procedure (FIG. 4).

There may be two operational phases. For example, the first phase may be a context information generation phase. Here, the communication device 100 (e.g., a vehicle A) generates a context (by receiving the CD entries 111, 112) securely over time/space/protocol by interacting with different infrastructure entities 110.

The second phase may be a context information exchange phase. Here, all system participants, notably e.g. vehicles (i.e. communication devices 100), can securely exchange alerts, notifications or any noticeable events securely using the existing context.

Moreover, two protocols may be defined, which use three types of messages as follow:

• I2V_*: these are messages sent from the infrastructure entities 110 to the communication device 100 (e.g. the vehicles)

• V2I_*: these are messages sent from the communication device 100 (e.g. the vehicles) to the infrastructure entities 110.

• V2V_*: these are messages sent from the communication device 100 (e.g. vehicles) to other communication devices (e.g. other vehicles).

The I2V_* and V2I_* messages may be used by a Context Information Generation Protocol (CIGP). The V2V_* messages may be used by a Context Information Exchange Protocol (CIEP). The CIGP may be implemented by the context information generation function (CIGF). Equivalently, the CIEP protocol may be implemented by the context information exchange function (CIEF).

The V2I Phase: Context Information Generation (Protocol and Function): this phase requires the setup on communication device 100 (e.g. vehicle) and infrastructure entity 110 described above. In this phase, the communication device 100 (e.g. a moving vehicle) receives the CD entries (i.e., collects a number of context information records) from the infrastructure entities 110. The interactions of the communication device 100 and several infrastructure entities 110 based on the CIGP is presented at bellow with reference to FIG. 3.

At step S301, the infrastructure entity 110 sends an I2V HELLO message to the communication device 100 (vehicle A).

For example, for active infrastructure entities 110, it may be possible to announce their objCDs, e.g., periodically or based on some events using the I2V_HELLO message. These announcements are not personalized, in the sense that they inform any receiving entity about some relevant current road context, but they are not particularly issued to that communication device 100, so that they are not suitable for building the communication device’s context trace. By its nature, the I2V HELLO message is public and must include precise time mark. It also includes a random number (nonceObj). In addition, the I2V HELLO message can include some notifications coming from the infrastructure. The I2V_HELLO can be checked by any entity by verifying the correct signature with the included public key and the validity of the included certificate.

A typical operation may be an interaction between a communication device 100 and an infrastructure entity 110. Here, a two-way protocol is presented, triggered by a V2I_HELLO message and answered by an I2V_CONTEXT message (e.g., at steps S304 and S305). Moreover, it may also be a three way handshake including the I2V HELLO message, or a four way handshake where a communication device 100 initially triggers the overall process by including an empty V2I_HELLO message.

At step S302, the communication device 100 (e.g. the vehicle A) sends a V2I_HELLO message to the infrastructure entity or object 110 (InfraObj 01).

Moreover, at step S303, the communication device 100 sends a V2I_HELLO message to the infrastructure entity or object 310 (InfraObj Ox).

In the V2I HELLO message, the communication device 100 is requesting the objCD of the infrastructure entity 110 to be signed for its temporary identifier. In this message, the communication device 100 provides a random number (nonce), its temporary public key and signs all that by its temporary private key. This operation proves that the communication device 100 is in possession of a private key for the displayed public key.

The content of nonce depends on the given situation. It needs to be unique or related to something concerning the current situation, e.g., it could be required to be the current time stamp (as all communication devices are supposed to have access to the precise time) or to reflect the more broad road context (use geographic position or previously received nonces from the same infrastructure) to avoid general replay attacks. If the communication device 100 has previously received the nonceObj, then nonce in the V2I HELLO to the same object could simply be the value of nonceObj incremented by 1.

At step S304, the infrastructure entity 110 sends an I2V_CONTEXT message to the communication device 100 (vehicle A). Moreover, at step S305, the infrastructure entity or object 310 sends an I2V_CONTEXT message to the communication device.

For example, the I2V_CONTEXT is the message used by the infrastructure entity 110, 310 to transmit its objCD to the requesting communication device 100. Within this message, the objCD is bound to communication device’s transient public key, and the object certificate. The message is signed by the private key of the infrastructure entity 110, 310.

With reference to FIG. 4, during the V2V phase, Context Information Exchange (Function and Protocol), the following operation may be performed. The diagram 400 shows the exchanges of two communication devices including vehicle A (the communication device 100) and the vehicle B 420, once a sufficient context information is established for the communication device 100.

At step 401, the communication device 100 sends a V2V_MSG to the vehicle B 420.

For example, the V2V_MSG may be sent by the communication device 100 and signed by its temporary private key contains the actual description of the event (Msginfo), concatenated with the relevant subset of the CD entries (for example, the Cl records such as the geo-spatially close/recent to the actual reported event) and the temporary public key of the communication device 100.

Moreover, every receiving communication device may now verify this message (for example, several intermediary steps of S421 to S424 may be performed), which is exemplarily discussed based on vehicle B 210, as follow:

At step S421, the vehicle B 420 verifies all CD entries (for example based on verifying all Cli within the received message, checking the signature chains, i.e., the correct signature of the message with the included public key of the authoring infrastructure object, and the validity of the included certificate for that public key).

At step S422, the vehicle B 420 checks that all CD entries (e.g., all Cli) are issued for the same temporary public key (here: pubKa);

At step S423, the vehicle B 420 uses pubKa to verify the overall received message signature.

At step S424, the vehicle B 420 now verifies the matching of the included context to its own road context (e.g., is the vehicle driving in the same direction, on the same road, etc.), and, if suitable, to the reported event (e.g., if the vehicle B 420 is also going to reach the point of the reported event).

Note that the latter verification of the CD entries may be automated, for example, as long as the format of objCD included in the context information records are generally defined (e.g. standard). For example, the receiving vehicles can directly read the included road designation and rapidly judge if the sender is driving on the same road.

Finally, if required, another vehicle (say vehicle B 420) can answer or confirm this message with sending a V2V_MSG_ACK. For example, at step 402, the vehicle B 420 sends the V2V_MSG_ACK to the vehicle A (the communication device 100).

Reference is made to FIG. 5 which is a schematic view of a diagram illustrating contextualized identifiers with overlapped time windows.

Moreover, a CD entry lifecycle may also be provided. For example, communication devices 100 may manage the received CD entries, as they see fit. For instance, by the scheme defined in the diagram 500 of FIG. 5, the CD entries (a context information record (Cli)) is only valid within a particular spatiotemporal context. In other words, it expires after some time and semantically loses its meaning, e.g., once a determined communication device (vehicle) changes the road, moves away from a record position, etc.

Because of this, it is recommended that the communication device 100 uses a FIFO- type of memory structure to keep a fixed number of the most recently received context information records. Once the structure is full, every new record will be put at the head, while the oldest record may be discarded.

Moreover, since the CD entries are bound to temporary identities, the whole CD entries (e.g., the context information Cl (or context trace)) should be disposed of, when an existing temporary identifier is discarded. However, doing so would result in a delay, until this communication device 100 has collected enough new context information records to be able to convince recipients of its competence. Also, without its own context trace, it might be harder for a communication device 100 to decide, whether it is interested in a received event, even though it would be able to verify the correctness of the context-based signature. To overcome this problem, a (simple) method may be based on using several random identifiers and to establish context information records for all of them in parallel, when passing by an infrastructure entity 110 (or for example, infrastructure entities 310, 510, 520, 530, 540). The established time series then could overlap to produce some kind of sliding window. In the diagram 500 of FIG. 5, it is assumed that the CD entries are based on contextualized identifiers.

The same infrastructure entity or object (e.g. iok+i) can be used with several temporary identifiers (tii, tb) to obtain context information records. When tii is discarded, the tb already has the context record of iok+i, therefore enabling the communication device 100 to communicate its events/observations and to validate its interest without delays.

In the following sections, the implementation of the CIGF and CIEF is discussed in any given embodiment. Moreover, it is further discussed the details of the limited channels of any particular embodiment, how it can be used, which limitations apply, and, notably, how CIGP can be transported over the limited channel.

Reference is made to FIG. 6 which is a schematic view of a diagram 600 illustrating the communication device 100 communicating with the infrastructure entity 110 being an AMF in a 3 GPP core network function.

The used 3GPP mobile networks may be based on UMTS, LTE, 5G, etc.

A 3GPP network (3G/4G/5G) may be extended with the functionality proposed in this disclosure and implement an “infrastructure entity” 110, which provide CD entries (context information records). Communication devices (in the following “Vehicles”) 100, 620, 630 may use the 3 GPP User Equipment (UE) functionality and the 3 GPP communication protocols and procedures accordingly.

In practice, vehicles (e.g., vehicle Va 100, Vb 620, and Vc 630) in this scope may be either internal car communication systems using mobile cellular communications, additional mobile cellular gadgets/accessories or 3G, 4G, 5G, etc., smartphones. Therefore, on the vehicle side, the CIGF_V may be implemented as a data-service using application using for CIGP transport either a special control channel, or (preferably) a particular or a default bearer in the 4G or the V2X service provisions in 5G. As it is shown in diagram 600 of FIG. 6, in 5G, the infrastructure part of the CIGF, i.e., CIGF_I, may be (easily) implemented on the AMF (e.g., as a special AMF flavor) or an additional core network function. The position on the AMF is practical, as the AMF has access to both the access network information (e.g., over which cell tower/base station/gNB) the request came from, including, if necessary, RAN-level information with regard to received signal strength, etc., and to the core network information such as registration data, etc.

Moreover, after getting the temporary identifier, i.e., CI_a in the diagram 600 of FIG. 6, from the infrastructure entity 110 (the AMF 110) that will provide infrastructure entity information, the sending Vehicle Va’s CIEF_S (e.g., incorporated in the communication device 100 which is the Va 100) sends messages protected with its Cl (i.e. CIa), i.e., the Va’s CIEF_S sends to the receiving CIEF_R by signing message with its transient private key (privKa) and corresponding CIa. Moreover, the CIEF_R semantically verifies Va’s used CI_a against the message content and whether passes it to its CIEF_S. Furthermore, messages are delivered to the vehicles in delivery domains, e.g., to CIEF_R on Vb, CIEF_R on vehicles outside of the delivery domains (e.g., Vc 630) are not even notified.

Note that, the UE registration does not even have to finish, i.e., it is imaginable that AMF hands out this information to unknown/unauthenticated UEs. The UE will not have any service from the mobile network but get return of signed objCDs.

Reference is made to FIG. 7 which is a schematic view of a diagram illustrating the communication device communicating with public road infrastructures.

The communication device 100 is a UE Va 100.

For example, a road infrastructure may also be extended with the functionality proposed in this disclosure and implement “infrastructure objects”, which provide context information records. Vehicles in this embodiment may use NFC or energy harvesting communication technology. As shown in diagram 700 of FIG. 7, communication device 100 (e.g. a vehicle Va 100) receives CD entries (gets Cl) from the road infrastructure (e.g., RPs 110, 710a, 710b, 710c along the road). Moreover, the Va 100 proactively keeps sending non-private low energy signals while driving. The NFC reflector of every RP reflects back objCDs using its CIGF providing the context information if the vehicle Va is close enough. The NFC reflectors can be implemented by existing technologies such as using energy harvesting and so on; Similarly, communication device 100 (Va 100) collects a time series of reflected and signed context information from RPs as its CL Vehicle Va’s CIEF signs message Msg with its privKa with CI_a and broadcasts Msg with existing V2V communication possibility; Nearby vehicles’ CIEF_R (e.g., Vb 620 and Vc 630) receive it.

Furthermore, the CIEF Rs verify the signature of the included objCDs stemming from RPs, by using, e.g., root certificates, if ok, CIEF_R verifies the same pubKa in all included objCDs; If ok, CIEF R further verifies the signature of message content with pubKa included; If ok, CIEF R verifies if the objCD part of matches its own context semantically,

Example: objCD = (48°10'35.3"N 11°32'25.7"E) | DE-B304 | 10.1 | 13:14:33 CEST |

12345

Vehicles (e.g. Vc) out of the context ignore the message. The objCD context in the message is naturally different as what objCDs they observed thus the information is irrelevant.

Reference is made to FIG. 8 which is a schematic view of a diagram 800 illustrating the communication device communicating with a Car manufacturer OTT service provider.

For example, the backends of car vendors may be used. The car manufacturers could also be extended with the functionality proposed in this disclosure and implement to infrastructure entity 110 (“infrastructure objects”), which provide context information records. Vehicles may use 3GPP User Equipment (UE) functionality and only use 3GPP communication protocols and procedures to access the mobile network system but the actual services are from car manufacturer OTT service providers. In diagram 800 of FIG. 8, the communication device 100 (e.g. a vehicle Va 100) sends a request to infrastructure entity 110 (a V2X App 110) provided by its manufacturer (e.g., a car produced by a given manufacturer uses an App from that given manufacture). ObjCDs are generated directly by the V2X App with respect to the trusted onboard data provided from the client App such as sensed information by the sensors on the car, locations of the car projected to the high resolution map; time and date. The ObjCDs are signed by the V2X App and sent back to the car, however CIGF strips all car identifiers to preserve privacy and rather uses a random public key provided by CIGF_V, albeit the car is enrolled with the backend and the message can be issued in a personalized manner. The communication device 100 collects a time series of objCDs and generates its Cl a. Vehicle (Vc 630) from another vendor (Vendor Y V2X App 810) can verify the message by using public key of the trusted vendors, following the same procedure of CIEF, which will not be repeated again.

Reference is made to FIG. 9 which is a schematic view of a diagram illustrating the device being a UE supporting CIEF and the infrastructure object supporting an IEEE 802.11 Authentication Procedure.

The IEEE 802.1 lp road-side units may also be used. For example, the embodiment within 802.1 lp is different from the previous cases, as it requires entity authentication with a backend server, which blocks us to use the infrastructure to generate CIs. Authentication method can be any IEEE 802. IX compliant method (e.g. EAP-TTLS).

Here, the CIGP messages can be defined as a new EAP method interacting with backend authentication server 920. After associating with an AP (authenticator), the communication device 100 (vehicle A) sends an anonymous identifier for authentication. Then the authentication server 920 triggers the CIGP over EAP. The communication device 100 sends its local information to the passing APs, which further forward the local information from the communication device 100 to backend authentication server, along with its own information. The backend authentication server judges the overall information and, if found appropriate, signs the information and return with objCDs to the communication device 100 via APs. After generating CIs, vehicles follow the same way for V2V communication. Concrete procedure is illustrated in diagram 900 of FIG. 9. At step S901, the communication device 100 (vehicle A) performs a probe request/response with the infrastructure entity 110 (RSU 01).

At step S902, the communication device 100 (vehicle A) performs a probe request/response with the infrastructure entity 910 (RSU Ox).

At step S903, the communication device 100 (vehicle A) performs an AP authentication request/response with the infrastructure entity 110 (RSU 01).

At step S904, the communication device 100 (vehicle A) performs an AP authentication request/response with the infrastructure entity 910 (RSU Ox).

At step S905, the communication device 100 (vehicle A) performs an association request/response with the infrastructure entity 110 (RSU 01).

At step S906, the communication device 100 (vehicle A) performs an association request/response with the infrastructure entity 910 (RSU Ox).

At step S907, the communication device 100 (vehicle A) sends the client hello message to the infrastructure entity 110 (RSU 01).

At step S908, the infrastructure entity 110 (RSU 01) sends the client hello message to the authentication server 920.

At step S909, the communication device 100 (vehicle A) sends the client hello message to the infrastructure entity 910 (RSU Ox).

At step S910, the infrastructure entity 910 (RSU Ox) sends the client hello message to the authentication server 920.

At step S911, the authentication server 920 sends the Auth-Server hello message to the infrastructure entity 110 (RSU 01). At step S912 the infrastructure entity 110 (RSU 01) sends the Auth-Server hello message to the communication device 100.

At step S913, the authentication server 920 sends the Auth-Server hello message to the infrastructure entity 910 (RSU Ox).

At step S914 the infrastructure entity 910 (RSU Ox) sends the Auth-Server hello message to the communication device 100.

At step S915, the communication device 100 (vehicle A) sends the V2I hello message to the infrastructure entity 110 (RSU 01).

At step S916, the infrastructure entity 110 (RSU 01) sends the V2I hello message to the authentication server 920.

At step S917, the communication device 100 (vehicle A) sends the V2I hello message to the infrastructure entity 910 (RSU Ox).

At step S918, the infrastructure entity 910 (RSU Ox) sends the V2I hello message to the authentication server 920.

At step S919, the authentication server 920 sends the I2V CONTEXT message to the infrastructure entity 110 (RSU 01).

At step S920 the infrastructure entity 110 (RSU 01) sends the 12 V CONTEXT message to the communication device 100.

At step S921, the authentication server 920 sends the I2V CONTEXT message to the infrastructure entity 910 (RSU Ox).

At step S922 the infrastructure entity 910 (RSU Ox) sends the I2V CONTEXT message to the communication device 100. FIG. 10 shows a method 1000 according to an embodiment of the invention for a communication device 100, in particular for use in V2X applications. The method 1000 may be carried out by the communication device 100, as it is described above.

The method 1000 comprises a step 1001 of receiving, from one or more infrastructure entities 110, CD entries 111, 112, wherein each of the CD entries 111, 112 is for the communication device 100 and is indicative of a spatiotemporal context of the communication device 100.

The method 1000 further comprises a step 1002 of sending a message 101, wherein the message 101 is signed based on a subset of the received CD entries 111.

FIG. 11 shows a method 1100 according to an embodiment of the invention for an infrastructure entity 110. The method 1100 may be carried out by the infrastructure entity 110, as it described above.

The method 1100 comprises a step 1101 of connecting to one or more communication devices 100, in particular UE.

The method 1100 further comprises a step 1102 of generating, for each communication device 100, a set of CD entries 111, 112, wherein each CD entry 111, 112 is specified for that communication device 100 and is indicative of a spatiotemporal context of that communication device 100.

The method 1100 further comprises a step 1103 of sending a message 114 to a communication device 100, the message 114 indicating the set of CD entries 111, 112 specified for that communication device 100, signed with the private key 113 of the infrastructure entity 110.

As discussed, the embodiments of the present invention may improve the security, the privacy and the integrity of the messaging system in the wireless mobile communication systems. Without limiting the present disclosure, in the following several scenarios discussing the security and the privacy of the wireless mobile communication systems are presented, for example, the discussed effects may be achieved by using the communication device 100 and/or the infrastructure entity 110 and/or the method 1000 and/or the method 1100, without limiting the present disclosure to a specific device, method or a specific scenario. Reference to a “vehicle” or “vehicles” in the following may be a reference to a communication device 100 or communication devices 100, according to embodiments of the invention.

Basic security protection : for example, by using the above discussed protocols, devices and methods, it may be possible to protect against typical attacks from the ITS domain. Here, similar to the DY model, it may be assumed that the adversary carries the message. Note that the attacker is an outsider in these attacks, i.e., it is assumed the adversary does not have access to the authority of the infrastructure entity, and does not have access to key material in the infrastructure entities.

In principle, vehicles are considered outsiders, as they are not required to possess any preliminary long-term credentials or secret keys for this solution to work. It is assumed that the adversaries have a limited resource, for example, they are not omnipresent, and they cannot be at several physical positions at the same time. Metaphorically, the adversary here is a single car or truck with communicating objects on board. It could be standing anywhere next to the road or moving along the road with typical car speeds.

Message confidentiality : the solution proposed here does not (explicitly) address message confidentiality. If message confidentiality is required, secure channels should be used. For example, it may be considered that ITS systems mostly require message integrity.

Message forging: the message forging may be producing a correctly looking message starting from nothing, i.e., without any input. Moreover, depending on the type, some messages in this protocol may be forged by an adversary. • It is trivial for any participant to forge V2I_HELLO messages, as the included digital signature only proves the possession of the used temporary private/public key pair, but everybody can produce its own private/public key pair. This is by design: the V2I_HELLO message is designed in a way to allow any entity to initiate it. Consequently, it is considered uncritical: it only results in a publicly known context information record, and there is no gain in forging such messages, as, in particular, the vehicles ignore these messages completely.

• In contrast, it is hard for any adversary, and in particular for a vehicle, to produce a correctly looking message of the type I2V_* (i.e., coming from an infrastructure entity), as it cannot produce a correct signature without having a valid certificate from a well-known infrastructure authority.

• Moreover, in order to be able to produce a correctly looking V2V message, vehicles must include sufficient spatiotemporal context information issued to the same temporary identity. An individual adversary can only obtain such context information, when it successfully receives context information records from different infrastructure objects. That means the vehicle must have passed by close enough (i.e., within the reach of the limited channel) to those infrastructure objects at some point in time, which therefore can be parameterized to serve as a proof that the vehicle must have been moving (e.g., driving with some minimum speed) along some route. Such parametrization can define limits for time and space deviations acceptable for any particular reported event type. Obtaining this proof may be (exactly) the purpose of this solution, as this proves the competence of the vehicle to send some information from this route.

Message falsification : the message falsification may be or may include a modification of a message, originally produced by some other system participant: · For all I2V_* messages: this is difficult to achieve because of the verifiable digital signature (check that the certificate is valid and verify the message signature using the public key in the certificate). • For all V2V_* messages: any change would also require a change of the included signature. The signature may (only) be changed if the adversary can substitute the private/public key pair. To achieve that, an adversary needs to substitute all included context information records by his own ones. This is possible, because e.g., any vehicle would have its own context information, which it could use instead of the included one. However, this is equivalent to that vehicle producing its own V2V_* message with a different content. Therefore, this falsification is somehow useless, as any vehicle with sufficient context information are, by design, capable of sending V2V_* messages. Note that in case of a particular event report, bound to some locations, additionally to the above, the adversary would need to include CL from witness infrastructure objects “close” in space- time to the reported event. Therefore, overall, this situation would be equivalent to two vehicles on the road (and potentially close to some area) reporting different things. This is therefore beyond the classical security questions treated by ITS security or this solution alike, as the vehicles may indeed disagree, have different observations or conclusions, etc.

• For V2I_HELLO messages: the falsification is possible by replacing the public key. This is equivalent to message forging and is not considered a problem.

Identity usurpation (passing for an infrastructure entity or another vehicle): the first situation is that participants (vehicles or other infrastructure entities) cannot usurp the identity of some infrastructure object, as all of its messages are digitally signed by a certified key pair. Usurping its identity would require either obtaining a valid certificate from the responsible authority, or getting access to the private key of the object. Both are considered beyond the threat model discussed here.

The second situation is usurping the identity of another vehicle. There is no long-term identity of another vehicle to be usurped. All vehicles create several temporary identities and exchange them, as the situation changes. An adversary can try to take over the temporary identity of a vehicle (i.e., its public key). To do that, an adversary would need to use the same public key in its V2I_* to get context information records, and to later use all that in the V2V_* messages. However, to do this, the adversary would need to guess the private key from the public key, which, by design, is considered computationally impossible. An adversary, therefore, can only use a different public/private key pair. This, however, is equivalent to any vehicle creating a new temporary identity and is not considered a problem. See the discussion on “Incorrect behavior” below.

Replay attacks : generally, in a replay attack an intercepted (recorded) message is resent by an adversary at some later point in time. Note that any message can be recorded and resent according to the threat model, therefore here we rather analyze the impact of replay on a per message basis:

• I2V HELLO messages are required to include a time mark, which is designed to minimize the impact of replay. A replayed message would be detected (as too old), and can be ignored. If these messages are replayed within the expiration time window, they could be considered less harmful (somebody repeats an information, which is still valid). Besides, to detect replay attacks, the message includes a nonceObj, i.e., a random number from an infrastructure object. This number should be unpredictable and used once, an infrastructure object can achieve that by selecting a random number from a large subset or by using some strategies to avoid collisions (e.g., increasing random numbers, etc.). To check this, therefore, vehicles should store any seen nonceObj per infrastructure object during the expiration time window. This data can be discarded after the expiration. · The V2I_HELLO message may include a random number (i.e., a nonce), which should be used once and only once. However, it is complex to track the non duplication of it for separate infrastructure objects (and impossible for the stateless ones without backbone connection). Thus, it is generally possible for an adversary to replay a correctly signed message sent by some other vehicles. To limit replay attacks further, we require that nonce be bound to some rules: e.g. it could be a data structure holding a time mark, and/or the actual road- relative or absolute position in addition to a random number. Also, we require it to reflect an optionally previously received nonceObj. These methods are meant to contextualize V2I HELLO as much as possible; at least the time mark should be available even for a very initial message. In the situations, where the adversary would still succeed with replaying, this adversary would get back a context information record signed for the temporary identity in the replayed request. An adversary therefore could collect context information records meant for some other temporary identities. However, note that an adversary would not be able to send any V2V_* messages by using this context, as the adversary does not have a private key to correctly sign the message. Furthermore, all collected context information records will naturally expire after a while. Besides, to record such messages, given that all channels are limited (or secure), the adversary would need to actually physically follow some victims or actually use the roads. The adversary, therefore, puts himself in risk with regard to classical traffic control and law enforcement methods.

• V2V_MSG: an adversary can replay recorded V2V_MSG, however without any changes. By design, the V2V_MSG messages include context information and are only valid within the latter. This strongly mitigates any replay attacks beyond the context, while repeating them within the context validity (i.e. close to the place and time of the last sender, event, etc.) is not considered harmful.

Man-in-the-middle (MitM): in the MitM attacks, an adversary relays and changes messages between two legitimate system participants to achieve some goals. MitM attacks are generally possible in this scheme, as vehicles are not authenticated by design. However, passing for a vehicle makes no sense in this scheme, as it is equivalent to creating a new temporary identity, and message content confidentiality is not a goal of this solution.

If vehicles fail to verify the authenticity of the infrastructure objects thoroughly (as this was already reported for Web sites, which have a similar trust model), then this solution would completely fail, as it would be possible for attackers to disseminate falsified context information records to some participants. We believe that the issue here is different from the Web or WiFi access, as ITS systems would not be operated by human users, but rather checks and verifications would be done by automatic agents, which would rigorously verify the cryptographically bound trust chains.

To mitigate MitM attacks, two additional mechanisms can be integrated with this solution:

• Use of distance bounding: here, any entity would enforce a cap on the maximum distance between sender and recipient, therefore forcing a possible MitM adversary into particular geospatial position and increasing the overall risk situation for the adversary. The applicability depends on the embodiment.

• Cryptographic binding of the message of this solution to the actual channel underneath, similar to what is proposed in RFC6677 or RFC7029. This depends on the actual embodiment.

Denial of service : denial of service is generally possible, wherever a service is offered. In this specific case, the V2I_HELLO can be easily forged. An adversary can send storms of V2I HELLO messages, effectively blocking other users from obtaining the context information record from that infrastructure object (i.e. denying service for them). As the V2I_HELLO messages are not authenticated, the adversary will likely not be held accountable for these. However, this requires an adversary to produce and send many messages over limited channels, which puts him in the ITS context (requires his physical presence) and makes him visible (e.g. from the radio perspective). Typical countermeasures (network monitoring, rate limiting, channel limiting, etc.) can be considered within the infrastructures.

Advanced security protection: here, more advanced attacks are discussed, e.g. attacks by insiders, attacks by collusion, etc.

Insider Attack: a legitimate system participant could be “misbehaving” to achieve some goals. According to our classification, infrastructure objects and vehicles could misbehave.

• The misbehavior of the infrastructure objects could be due to physical tampering with it or due to misconfiguration/failure resulting in wrong behaviors. Whatever the cause, a rogue infrastructure object could do some geospatially limited harms by disseminating misleading context information. Vehicles could easily filter context information e.g. by majority votes or by the semantics. To be successful with wrong context distribution, an adversary would need to take over many infrastructure objects, at one point putting it at par with the infrastructure authority. Our scheme does not provide any protection against this, as we believe that this is out of scope of ITS communication service protection means.

• Vehicles moving along the road within a given context could try to outplay the system by distributing false or misleading information, correctly signed with the context information. This could involve lies/dis information, exaggerations, wrong testimony, etc. Our scheme provides twofold countermeasures against this:

^■ Prevention/protection: receiving vehicles are required to do semantic comparisons of the included context information and the message context

(e.g. of the reported event). This is meant to prevent wrong witness reports on areas outside of the reported context.

^■ Deterrence: our scheme forces attackers to follow the actual road for a while. Actually, the better the attacker wants to succeed, the longer the attacker should keep the same temporary identity while moving over the road. Therefore, even though by design our scheme does not provide any identity information of the attacker, the logs and records of the contextualized V2V_MSG messages sent by the attacker can be used e.g. by road authorities or law enforcement in addition to classical traffic control (e.g. video observation, etc.) and law enforcement means to correctly identify any misbehaving users by correlating this data in case of need.

Worm hole / warp : in a worm hole or warp attack, two (remote) adversaries could collude to obtain and disseminate the remote context of the users. While it is hard to oversee all possible threat scenarios here, note that the situation is similar to the usual authentication-based ITS schemes, as colluding users could also communicate classically protected ITS messages from remote platforms and vice versa. The particular reliance on context may seem to change this situation. A colluding adversary could request context information for a temporary identifier of a remote user and pass it one to it for dissemination. However, if that remote adversary suddenly starts disseminating V2V_* messages signed with remote contexts, this will be understood as an intrusion and will be stopped.

The colluding users could also make infrastructure objects’ messages (12 V_*) suddenly appear on the other side. For instance, an adversary at location A could intercept V2I HELLO request of some vehicles at this location, send it on to his colluding partner at the location B, receive the I2V_CONTEXT for that identity and hand it over to the adversary at the location A, to be sent as an answer to the originally requesting vehicle. This vehicle therefore could be led to a wrong belief with regard to its location.

However, such attacks are not easy in practice: colluding adversaries would need to be driving within different real contexts and make sure that infrastructure objects are in the vicinity at the right moment, and make sure that the warped messages arrive at the receiving vehicle before the possible real answers from the local infrastructure objects. All this increases the engineering complexity. Besides, our scheme is not supposed to replace positioning, but to protect ITS communication systems. So-called Distance Bounding Protocols at the level of the limited channel could help prevent such attacks.

Similarly, colluding adversaries could produce a convincing context information for a physical car that never was at this location. However, this is beyond the purpose and assurances of our scheme. For instance, an added or onboard unit of a car could be installed in another car, resulting in a similar effect.

Mafia fraud : classical mafia fraud attacks explicitly target distance bounding protocols. In these attacks, a MitM attacker tries to break the distance bounding by proving to an honest verifier that an honest remote participant (“prover”) is close by or by pretending to be that honest participant. These attacks are not specific to our scheme. Research has suggested mechanisms to protect distance bounding against mafia fraud. Transposing the idea to the solution proposed here, the principle of the attack is still relevant, especially for the V2V case (as in our solution, anonymous vehicles do not prove any position to the infrastructure objects, and vs., infrastructure objects simply send their signed objCD): it makes sense for a MitM attacker to try to prove to a verifier (a vehicle) that another vehicle (prover) is close by, so as to create an impression of a different context. A MitM attacker can indeed easily replay a V2V_MSG from some vehicle A to some other vehicle B. However, a MitM attacker will not be able to change the context information records within this message, as these are issued to a temporary identifier and protected by the verifiable signatures of the infrastructure objects. It is also not possible to change the actual message, as the message and the context information records are bound together by the signature corresponding to the temporary identifier.

Different from the mafia fraud attacks against distance bounding protocols, where location privacy of both participants is considered paramount and, hence, only the relative distance is bounded, in our scheme we use signed, absolute positions in space/time from public infrastructure objects, which do not have privacy expectations.

Privacy improvement (privacy preserving): by design, the infrastructure objects are presumed public and do not have privacy considerations. Hence, the privacy question is only applicable to vehicles in our scheme. For the latter, the management of the temporary identifiers puts a very strong privacy guarantee in the hands of the owner of the personal data, e.g. of the vehicle owner or user.

Notably, the question of when to produce (e.g. on ignition, on road change, on navigation route re-calculation, periodically), and how to use a given temporary identifier (how long, with which infrastructure, when to drop, etc.) is directly related to the privacy considerations of the vehicle owner/user. Some owners/users might decide to never use the same identifier with different infrastructures, and to exchange each of them very often; another owner might decide to limit interactions with infrastructure objects (of the same authority), and to rather mix different authorities’ contexts. This can be easily presented to the user as a privacy preference setting. It is important to note that whatever the decision of the owner/user, the overall privacy situation is always better, as the context information bound to a particular temporary identifier will always eventually expire by the scheme construction so that there is no incentive to keep context records beyond the particular road situation. In practice, we expect that several temporary identifiers will be used at the same time to produce several overlapping time series.

The only exception to this rule is that owners/users might decide to keep a particular trace as a log e.g. in case of an accident, if they believe that the log can help them gain a better position in a potential dispute. This is comparable to the situation with a dash camera, which always keeps the last couple of minutes of the video recording, except if the dash cam recognizes an accident, in which case it copies the current recording to a safe log to prevent it from being overwritten.

Note that in the proposed scheme, the privacy considerations with regard to personal data can be enforced by the owner of this personal data.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A communication device, in particular for use in Vehicle-to-everything, V2X, applications, the communication device being configured to: receive, from one or more infrastructure entities (110), Context Data, CD, entries

(111, 112), wherein each of the CD entries (111, 112) is for the communication device (100) and is indicative of a spatiotemporal context of the communication device (100), and send a message (101), wherein the message (101) is signed based on a subset of the received CD entries (111).

2. The communication device (100) according to claim 1, wherein: the CD entries (111, 112) are received over a limited channel.

3. The communication device (100) according to claim 1 or 2, wherein: the CD entries (111, 112) comprises one or more of: a random number or nonce sent from the communication device (100) to a determined infrastructure entity (110), a transient public key of the communication device (100), a signature of an infrastructure entity (110), a transient identifier, in particular a temporary identifier of the communication device (100), a set of CD entries (111, 112) received from the one or more infrastructure entities (110), a certificate of an infrastructure entity (110).

4. The communication device (100) according to one of claims 1 to 3, wherein: the sent message (101) indicates the subset of the received CD entries (111, 112) of the communication device (100) and determined information.

5. The communication device (100) according to one of claims 1 to 4, further configured to: send, to an infrastructure entity, a determined CD entry and/or determined information, and request the determined CD entry and/or determined information to be signed, receive, from the infrastructure entity, the determined CD entry and/or the determined information that is signed for the communication device, and sign the message based on the signed determined CD entry and/or the signed determined information.

6. The communication device (100) according to claim 5, further configured to: send, to the at least one other device (120), the message signed based on the signed determined CD entry and/or the signed determined information, and receive, from the at least one other device (120), a message indicating a verification state of the sent message.

7. The communication device (100) according to one of claims 1 to 6, further configured to: send, to a determined infrastructure entity (110), a message indicating a transient identifier, in particular temporary identifier of the communication device (100), and request a determined CD entry of the determined infrastructure entity (110) to be signed for that transient identifier, in particular temporary identifier.

8. The communication device (100) according to one of claims 1 to 7, further configured to: receive, from another device (120), a message indicating a determined information, evaluate, based on its own CD entries (111, 112), a competence of the other device (120) for sending the determined information, and/or determine, based on its own CD entries (111, 112), a relevance of the determined information to the communication device (100), in particular an interest for the received determined information.

9. The communication device (100) according to one of claims 1 to 8, further configured to: receive a message from another device (120), the message indicating determined information describing an event, concatenated with a set of CD entries received from one or more infrastructure entities the other device passed by.

10. The communication device (100) according to claim 9, further configured to: verify a validity of the received message based on performing one or more of: determining, whether all CD entries are signed by the same infrastructure entity, determining, whether public keys included in all CD entries are the same public key, determining, whether the signatures of all CD entries can be verified with the same public key of the other device, determining, whether all CD entries in all CD entries providing a competence of the other device sending the message.

11. The communication device (100) according to one of claims 1 to 10, wherein: each CD entry (111, 112) of the communication device (100) is valid for one or more of a predefined time period, a predefined geographical location, a unique identifier of a device.

12. A method (1000) for a communication device (100), in particular for use in Vehicle-to-everything, V2X, applications, the method (1000) comprising: receiving (1001), from one or more infrastructure entities (110), Context Data,

CD, entries (111, 112), wherein each of the CD entries (111, 112) is for the communication device (100) and is indicative of a spatiotemporal context of the communication device (100), and sending (1002) a message (101), wherein the message (101) is signed based on a subset of the received CD entries (111).

13. An infrastructure entity (110) configured to: connect to one or more communication devices (100), in particular User Equipment, UE, generate, for each communication device (100), a set of Context Data, CD, entries (111, 112), wherein each CD entry (111, 112) is specified for that communication device (100) and is indicative of a spatiotemporal context of that communication device (100), and send a message (114) to a communication device (100), the message (114) indicating the set of CD entries (111, 112) specified for that communication device (100), signed with the private key (113) of the infrastructure entity (110).

14. A method (1100) for an infrastructure entity (110), the method (1100) comprising: connecting (1101) to one or more communication devices (100), in particular User Equipment, UE, generating (1102), for each communication device (100), a set of Context Data, CD, entries (111, 112), wherein each CD entry (111, 112) is specified for that communication device (100) and is indicative of a spatiotemporal context of that communication device (100), and sending (1103) a message (114) to a communication device (100), the message (114) indicating the set of CD entries (111, 112) specified for that communication device (100), signed with the private key (113) of the infrastructure entity (110).

15. A computer program product including program code for performing the method according to any one of claims 12 and/or 14, when the program code is run by a processor.