WO2021151730A1

WO2021151730A1 - An apparatus for forwarding encrypted messages

Info

Publication number: WO2021151730A1
Application number: PCT/EP2021/051098
Authority: WO
Inventors: Joachim Kross
Original assignee: Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2020-01-28
Filing date: 2021-01-20
Publication date: 2021-08-05
Anticipated expiration: 2022-07-28

Abstract

There is provided an apparatus comprising means for: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

Description

An apparatus for forwarding encrypted messages

FIELD

[0001] Various example embodiments relate to forwarding of encrypted messages. BACKGROUND

[0002] Big amount of data, e.g. encrypted data, is exchanged in various applications, such as in intelligent transport systems. There is a need to improve the data exchange between entities.

SUMMARY [0003] According to some aspects, there is provided the subject-matter of the independent claims. Some embodiments are defined in the dependent claims.

[0004] According to a first aspect, there is provided an apparatus comprising means for: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

[0005] According to an embodiment, selecting one or more recipients based on the recipient identification data comprises identifying one or more transport addresses associated with the recipient identification data; and forwarding the encrypted message to the selected one or more recipients comprises forwarding the encrypted message to the one or more identified transport addresses associated with the recipient identification data.

[0006] According to an embodiment, the recipient identification data further comprises an indication of security material needed to decrypt the encrypted message.

[0007] According to an embodiment, the apparatus further comprises means for determining whether an encryption approach used to obtain the encrypted message is asymmetric encryption and/or symmetric encryption, or some other encryption. [0008] According to an embodiment, the encryption approach is symmetric encryption, and the apparatus further comprises means for storing or updating association of one or more transport addresses with the recipient identification data.

[0009] According to an embodiment, the encrypted message is a platoon management message.

[0010] According to an embodiment, the encrypted message is a platoon control message.

[0011] According to an embodiment, the apparatus further comprises means for detecting that a stored association of one or more transport addresses with the recipient identification data is not updated within a pre-defmed time period; and removing, in response to the detecting, the stored association.

[0012] According to an embodiment, the apparatus further comprises means for identifying a new association between a transport address and recipient identification data; and forwarding the new association to another relay of message exchange. [0013] According to an embodiment, the apparatus further comprises means for receiving a new association from another relay of message exchange; and storing the new association and associating the new association with the another relay of message exchange.

[0014] According to an embodiment, the means comprises at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0015] According to a second aspect, there is provided a method comprising: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

[0016] According to an embodiment, selecting one or more recipients based on the recipient identification data comprises identifying one or more transport addresses associated with the recipient identification data; and forwarding the encrypted message to the selected one or more recipients comprises forwarding the encrypted message to the one or more identified transport addresses associated with the recipient identification data.

[0017] According to an embodiment, the recipient identification data further comprises an indication of security material needed to decrypt the encrypted message.

[0018] According to an embodiment, the method further comprises determining whether an encryption approach used to obtain the encrypted message is asymmetric encryption and/or symmetric encryption, or some other encryption.

[0019] According to an embodiment, the encryption approach is symmetric encryption, and the method further comprises storing or updating association of one or more transport addresses with the recipient identification data.

[0020] According to an embodiment, the encrypted message is a platoon management message.

[0021] According to an embodiment, the encrypted message is a platoon control message.

[0022] According to an embodiment, the method further comprises detecting that a stored association of one or more transport addresses with the recipient identification data is not updated within a pre-defmed time period; and removing, in response to the detecting, the stored association. [0023] According to an embodiment, the method further comprises identifying a new association between a transport address and recipient identification data; and forwarding the new association to another relay of message exchange.

[0024] According to an embodiment, the method further comprises receiving a new association from another relay of message exchange; and storing the new association and associating the new association with the another relay of message exchange.

[0025] According to a third aspect, there is provided an optionally non-transitory computer readable medium comprising program instructions that, when executed by at least one processor, cause an apparatus to at least to perform: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

[0026] According to a further aspect, there is provided a computer program configured to cause the method in accordance with at least the second aspect and its embodiments to be performed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Fig. 1 shows, by way of example, an intelligent transport system;

[0028] Fig. 2 shows, by way of example, a message data structure; [0029] Fig. 3 shows, by way of example, a block diagram of an apparatus;

[0030] Fig. 4 shows, by way of example, a flow graph of a method for forwarding a message;

[0031] Fig. 5 shows, by way of example, message exchange in platooning;

[0032] Fig. 6 shows, by way of example, forwarding messages encrypted with a pre- shared symmetric key;

[0033] Fig. 7 shows, by way of example, forwarding messages encrypted with public asymmetric key; and

[0034] Fig. 8 shows, by way of example a process flow in a relay for information exchange. DETAILED DESCRIPTION

[0035] Intelligent transport systems (ITS) and cooperative ITS (C-ITS) refer to applications using wireless communication between vehicles, vehicle to vehicle communication (V2V), and between vehicles and smart road infrastructure, vehicle-to- smart road infrastructure communication (V2I), for increasing traffic safety and efficiency. V2V and V2I communications are collectively known as V2X communication, i.e. vehicle to everything communication, wherein X may be e.g. a vehicle, infrastructure or network. Other terms for ITS communication are e.g. Car2X i.e. car to everything, wherein X may be e.g. a car, infrastructure or network, dedicated short-range communications (DSRC), and ITS-G5 which refers to a wireless local area network (WLAN) based radio access layer in the 5 GHz band.

[0036] Platooning is a method for driving a group of vehicles together. The first vehicle in a platoon may see further ahead using e.g. line-of-sight (LOS) technologies such as radar and camera. Vehicles in the platoon may be orchestrated to e.g. accelerate or break simultaneously. For example, when the first vehicle detects any anomalies it may inform the other vehicles in the platoon facilitating orchestrated braking. In platooning, it is important to be able to communicate between vehicles in a secure manner.

[0037] Fig. 1 shows, by way of example, cooperative vehicle to everything (C-V2X) communications. A platoon may comprise a number of vehicles, e.g. vehicles 101, 102, 103, 104. Various sensors 131, 132, 133, 134 may be installed in the vehicles, e.g. a radar and/or one or more cameras. The vehicles may exchange information through a relay 100 of message exchange, e.g. the edge cloud, or multi-access edge computing (MEC). This relay may be named as a GeoService. The GeoService may receive messages from different message senders, e.g. vehicle stations, e.g. the vehicles 101, 102, 103, 104, and forward the messages to message recipients, e.g. other vehicles or user equipments, or e.g. to traffic lights 110, 111, or to a building such as a parking house 120.

[0038] Transmission mechanisms relying on the short-range nature as well as broadcast nature of WLAN may define the recipients of information based on location of the participants. In other words, participants that are within a certain geographic area may be defined as the recipients. For example, those participants that are within WLAN transmission range, or within the broadcast transmission range, of the sender may be defined as the recipients. There also exist mechanisms how participants beyond the transmission range of an original sender can be reached by leveraging other participants in between as forwarders. For example, in case of the European telecommunications standards institute (ETSI) Cooperative Awareness (CA) service, each vehicle periodically broadcasts e.g. its location, speed, heading, and other dynamic and static data, e.g. type of vehicle, size of vehicle, etc. Other vehicles in the vicinity receive these broadcasts and thus become aware of other vehicles in their vicinity. This awareness of other vehicles may be used in applications such as passing assistant or lane merge assistant. [0039] Side-link communication in a cellular network, so-called PC5 interface in long term evolution (LTE) network and 5G network, enables direct communication from one cellular user equipment (UE) to other cellular UEs in its vicinity. These communication mechanisms are rather short range and mostly broadcast in nature. Other cellular broadcast communication mechanisms are e.g. evolved multimedia broadcast multicast service (eMBMS) and single cell point-to-multipoint (SC-PTM). These communication mechanisms, as well as unicast point-to-point cellular communication, may be challenging to use in vehicle-to-vehicle communication, since they might not enable to implicitly address all vehicles within a certain geographical area centered on the vehicle wanting to share information that the WLAN-based approach supports.

[0040] A component in the network that acts as a relay for information exchange, or message exchange, may be applied. This component may be named as a message forwarding entity, or as a GeoService, a GeoServer, or similar. GeoService may be thought as a layer 2 emulator, i.e. emulator in the protocol layer that transfers data between adjacent network nodes. All the vehicles may send the messages they want to be disseminated to the relay, e.g. the GeoService, and then the GeoService may forward that message or information to the appropriate recipients. The GeoService may identify potential appropriate recipients based on the message comprising information about the position of the sender. The GeoService may extract this information from messages it receives and may build a point cloud of active senders. Those active senders may be assumed to be also receivers.

[0041] When the GeoService receives a message from a vehicle at a certain position, the GeoService may check in its database what suitable other recipients are in the sender’s vicinity. Then, the GeoService may send a replica of the message to each recipient identified. A similar approach is also envisioned for broadcast dissemination via e.g. eMBMS, in which case, however, no single recipients will be identified, but rather the cells in which the information shall be broadcast because they contain suitable recipients.

[0042] Each GeoService entity may serve a specific geographic area covering a certain number of cells of the cellular network, e.g. because the GeoService entity is running on an edge cloud that serves a certain set of cells of the cellular network. In such cases, neighboring GeoService entities are envisioned to communicate with each other in order to forward messages from a sender served by one GeoService entity to recipients that are in the vicinity of the sender, but due to aspects of cell coverage may be served by a neighbouring GeoService. In this kind of inter-GeoService communication the neighboring GeoService entities may exchange, e.g. periodically or event-based, a description of their individual coverage areas with each other. When they need to determine to which recipients to forward a message to, they may, in addition to consulting their own local geolocation database with potential recipients they serve themselves, check whether there might be potential recipients based on geography that are however served by a neighboring GeoService. If there are, then the forwarding of the message to such recipients may be performed by cooperation of the involved GeoService entities. This may involve the GeoService having received the message from a sender it serves forwarding the message to identified neighbour GeoService entities, which then in turn may forward the message to relevant individual recipients based on their geolocation.

[0043] The messages may be signed to protect against tampering and to support some sort of authorization and authentication. The messages may be encrypted to provide confidentiality. That data that is protected by signing and/or encryption may also include the parts of the message where the geolocation of the sender is located. Fig. 2 shows an example of a format of ETSI C-ITS message 200 with secure data structure comprising geolocation information as part of the GeoNetworking extended header.

[0044] Even if a recipient, or forwarder, such as GeoService, does not have the needed information to e.g. verify the signature of the signed message, it may still be able to access the plaintext and the geolocation information comprised in the signed message. Thus, e.g. the GeoService may still build its geolocation database that it needs to perform its layer 2 emulation functionality, and may identify suitable recipients based on the geolocation of the sender.

[0045] However, the geolocation information contained in an encrypted message might not be accessible unless one is party to the corresponding security association, i.e. in possession of the needed security material such as decryption keys. This is not an issue with a WLAN-based system, wherein it may be assumed that the intended recipient s) are within broadcast range of the sender, and that they will have the needed security material to further process the contents of the message. Other entities may also be able to receive such messages, but if they don’t have the needed security material to decrypt the message, it may be determined that they are not intended recipients. Thus, those other entities may discard or ignore such messages. It may be assumed that the encrypted messages are intended for a limited number of recipients.

[0046] It may depend on the specific message type whether protection such as message signing and/or message encryption apply to that message type. The protection of the message may be defined in a security profile. Usually, either all communication in a specific deployment is protected, i.e. with each message protected as governed by the security profile relevant for the message type, or all messages are unprotected. For example, when CA messages, i.e. CAMs, are protected, they are signed, while other messages, such as some of those used in context of platoon management and control, would be encrypted.

[0047] In addition to layer 2, i.e. the GeoNetworking layer, parts of the messages, e.g. C-ITS messages, may be protected at some other layer, e.g. higher in the protocol stack, e.g. at the facilities layer. When the protection, e.g. encryption, is applied at the facilities layer, the GeoService may access the geolocation information comprised in the message provided that there is no encryption at the GeoNetworking layer.

[0048] When the GeoService receives messages encrypted at the GeoNetworking layer, it might not be able to extract the geolocation of the sender of the message that it would need to determine the list of potential recipients based on a message-type-specific vicinity around the sender. This is because the GeoService is not considered as part of the communication relationship, as it is acting as layer 2 emulator, and does not have nor be able to obtain the needed security material to decrypt the message contents. Thus, GeoService might not be able to forward the message as part of its layer 2 emulation, i.e. it might not be able to perform its layer 2 emulation functionality. GeoService might not be able to perform its layer 2 emulation functionality within its own coverage area nor in situations where cooperation with neighboring GeoService entities might be needed.

[0049] As shown in Fig. 2, the geolocation needed by GeoService for geolocation- based forwarding of the message(s) is comprised in the GeoNetworking extended header. The GeoNetworking extended header is part of the data that is encrypted and included in an encrypted form in the GeoNetworking secured packet structure.

[0050] One option may be to send the encrypted message to all potential recipients known to the GeoService entity. The recipients, for whom the message is not intended, may ignore the message, since they might not be able to decrypt it, as discussed above. However, broadcasting to all potential recipients served by the GeoService entity may cause waste of resources. In addition, there may be malicious senders performing attacks, i.e. the attackers may cause an overload of the system that may result in a denial-of-service condition.

[0051] In case where encryption is applied to parts of a C-ITS message above the GeoNetworking layer, and there is no encryption at the GeoNetworking layer, the GeoService may be able to forward messages based on geolocation information comprised in those messages. However, messages with encrypted content may be, in general, intended for a small number of recipients. Thus, forwarding of the messages based on geolocation information would be a waste of resources, e.g. processing on GeoService side for the geo location matching and communication channel capacity. This is because the geolocation- based forwarding may select a much larger number of potential recipients than the actual number of intended recipients. For example, in case of the platooning, there may be a pre determined maximum number of vehicles in the platoon. Thus, the maximum number of intended recipients may be the total number of vehicles minus 1, i.e. minus the sending vehicle. For example, the maximum number of vehicles may be set to 31, and then the maximum number of intended recipients would be 30, while geolocation-based forwarding could result in the messages to be sent to 100s or even 1000s of recipients.

[0052] There is provided an apparatus and a method for enabling forwarding of encrypted messages to selected recipients. The apparatus capable of performing the method as disclosed herein is described first.

[0053] Fig. 3 shows, by way of an example, an apparatus capable of performing the method as disclosed herein. Illustrated is device 300, which may comprise, for example, a network node, a server such as a relay of message exchange, or a mobile communication device, e.g. a user equipment (UE). Comprised in device 300 is processor 310, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor 310 may comprise, in general, a control device. Processor 310 may comprise more than one processor. Processor 310 may be a control device. A processing core may comprise, for example, a Cortex-A8 processing core manufactured by ARM Holdings or a Steamroller processing core designed by Advanced Micro Devices Corporation. Processor 310 may comprise at least one Qualcomm Snapdragon and/or Intel Atom processor. Processor 310 may comprise at least one application-specific integrated circuit, ASIC. Processor 310 may comprise at least one field-programmable gate array, FPGA. Processor 310 may be means for performing method steps in device 300. Processor 310 may be configured, at least in part by computer instructions, to perform actions.

[0054] A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with embodiments described herein. As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor s) or a portion of a microprocessor s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0055] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0056] Device 300 may comprise memory 320. Memory 320 may comprise random- access memory and/or permanent memory. Memory 320 may comprise at least one RAM chip. Memory 320 may comprise solid-state, magnetic, optical and/or holographic memory, for example. Memory 320 may be at least in part accessible to processor 310. Memory 320 may be at least in part comprised in processor 310. Memory 320 may be means for storing information. Memory 320 may comprise computer instructions that processor 310 is configured to execute. When computer instructions configured to cause processor 310 to perform certain actions are stored in memory 320, and device 300 overall is configured to run under the direction of processor 310 using computer instructions from memory 320, processor 310 and/or its at least one processing core may be considered to be configured to perform said certain actions. Memory 320 may be at least in part comprised in processor 310. Memory 320 may be at least in part external to device 300 but accessible to device 300.

[0057] Device 300 may comprise a transmitter 330. Device 300 may comprise a receiver 340. Transmitter 330 and receiver 340 may be configured to transmit and receive, respectively, information in accordance with at least one cellular or non-cellular standard. Transmitter 330 may comprise more than one transmitter. Receiver 340 may comprise more than one receiver. Transmitter 330 and/or receiver 340 may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, 5G, long term evolution, LTE, IS-95, wireless local area network, WLAN, Ethernet and/or worldwide interoperability for microwave access, WiMAX, standards, for example.

[0058] Device 300 may comprise a near-field communication, NFC, transceiver 350. NFC transceiver 350 may support at least one NFC technology, such as NFC, Bluetooth, Wibree or similar technologies.

[0059] Device 300 may comprise user interface, UI, 360. UI 360 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 300 to vibrate, a speaker and a microphone. A user may be able to operate device 300 via UI 360, for example to accept incoming telephone calls, to originate telephone calls or video calls, to browse the Internet, to manage digital files stored in memory 320 or on a cloud accessible via transmitter 330 and receiver 340, or via NFC transceiver 350, and/or to play games.

[0060] Device 300 may comprise or be arranged to accept a user identity module 370. User identity module 370 may comprise, for example, a subscriber identity module, SIM, card installable in device 300. A user identity module 370 may comprise information identifying a subscription of a user of device 300. A user identity module 370 may comprise cryptographic information usable to verify the identity of a user of device 300 and/or to facilitate encryption of communicated information and billing of the user of device 300 for communication effected via device 300.

[0061] Processor 310 may be furnished with a transmitter arranged to output information from processor 310, via electrical leads internal to device 300, to other devices comprised in device 300. Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 320 for storage therein. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Likewise processor 310 may comprise a receiver arranged to receive information in processor 310, via electrical leads internal to device 300, from other devices comprised in device 300. Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 340 for processing in processor 310. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.

[0062] Processor 310, memory 320, transmitter 330, receiver 340, NFC transceiver 350, UI 360 and/or user identity module 370 may be interconnected by electrical leads internal to device 300 in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device 300, to allow for the devices to exchange information.

[0063] Fig. 4 shows, by way of example, a flow graph of a method for forwarding a message. The phases of the method may be performed e.g. in device 100, an auxiliary device or a personal computer, for example, or in a control device configured to control the functioning thereof, when installed therein. The device may be the relay of message exchange, such as a GeoService. The method 400 comprises receiving 410 an encrypted message. The method 400 comprises receiving 420 recipient identification data comprising at least an indication of security material used to obtain the encrypted message. The method 400 comprises selecting 430 one or more recipients based on the recipient identification data. The method 400 comprises forwarding 440 the encrypted message to the selected one or more recipients.

[0064] Recipient identification data, or Recipient ID, may comprise an indication of security material used to obtain the encrypted message. The recipient identification data may comprise an indication of security material needed to decrypt the encrypted message. In other words, the data structure carrying the encrypted data may also carry an indication of security material that was used for the encryption and what matching material is needed on receiver side to decrypt the encryption. For example, it may be indicated what symmetric key was used in case of symmetric encryption, or what public key was used in case of asymmetric encryption and thus which corresponding private key needs to be used for decryption.

[0065] Further, there may be an indication of what kind of encryption approach was used, e.g. symmetric and/or asymmetric, or some future encryption approach. This information may be additional meta-information about how to use the cryptographic material.

[0066] The recipient identification data, and possible additional meta-information, may be non-encrypted. This enables the recipient to read them before starting the decryption attempt using the correct decryption approach chosen based on the received information.

[0067] By using the method as disclosed herein, there is no need to change the standardized message formats, protocols or the architecture. Existing implementations, e.g. station implementations, are not affected. By using the method as disclosed herein, messages may be forwarded to the intended recipients. This way, resources may be saved, since the resources are not wasted to sending messages to a large number of unintended recipients. The resources here may mean e.g. processing resources of the relay of message exchange, i.e. the GeoService, processing resources of the receiver side, and/or bandwidth on the radio interface. By using the method as disclosed herein, the messages may be forwarded in a secure and efficient manner.

[0068] Platooning specific messages, or message variations, may be used to detect potential platooning partners, to set up and tear down a platoon or to start or stop an individual vehicle’s membership in a platoon, and to control the operation of the platoon. Modified cooperative awareness messages (CAMs) may be used to detect potential platooning partners. Platoon management messages (PMMs) may be used to set up and tear down a platoon or to start or stop an individual vehicle’s membership in a platoon. Platoon control messages (PCMs) may be used to control the operation of the platoon. [0069] CAMs may be signed messages. CAMs might not contain encrypted content. PMMs used to set up and tear down a platoon may be signed messages, and might not contain encrypted content.

[0070] Encryption may be symmetric and asymmetric. In symmetric-key schemes, the encryption and decryption keys are the same. Communicating parties have the same key, e.g. a pre-shared symmetric key, in order to achieve secure communication. In asymmetric-key schemes, or public-key encryption schemes, the encryption key is published for anyone to use and encrypt messages. However, only the receiving party has access to the decryption key that enables messages to be read. Thus, in asymmetric encryption there are two related keys i.e. a key pair.

[0071] PMM(s) used to start or stop an individual vehicle’s membership in a platoon and PCMs may be encrypted. When a vehicle joins a platoon, two sub-types of PMMs may be involved. One may be encrypted and another may be non-encrypted. The encrypted PMMs may be encrypted using asymmetric encryption algorithms. The encrypted PMMs may be intended for a single specific recipient, and are thus encrypted with a public encryption key belonging to that recipient. The recipient identification data, i.e. the recipient ID, identifies this single recipient. When a vehicle leaves a platoon, a third sub- type of PMM may be used, which may be encrypted symmetrically.

[0072] The encrypted PCMs may be encrypted using symmetric encryption algorithms. The participants in the platoon, e.g. all the participants in the platoon, may have knowledge of a common pre-shared key, which is distributed to them as part of the procedure of joining the platoon. This key may be generated by a platoon leader, which is the vehicle that others join, i.e. start following to form the platoon. It may be assumed that the way the key is generated is unique for a given platoon. The other platoons may use other keys which are different from the key used by the given platoon. Thus, for pre-shared symmetric keys, the recipient identification data, i.e. the recipient ID, may be considered as a kind of group identifier as it in general refers to multiple recipients, usually at least two recipients.

[0073] Fig. 5 shows, by way of example, message exchange in platooning between a first vehicle 510 and a second vehicle 520 The first vehicle 510 is the leading vehicle. The second vehicle 520 is the following vehicle. The second vehicle 520 receives 530 a signed CAM from the first vehicle 510. The CAM may be used to broadcast information about the sender to make others aware of the sender. The CAM may comprise information on e.g. its position, speed, heading, vehicle type, etc. The CAM may indicate whether a vehicle is joinable or not, i.e. wheter it is willing and able to accept other vehicles to start following it. The first vehicle 510 is 531 joinable, i.e. willing to accept the second vehicle 520 to the platoon led by the first vehicle. The second vehicle 520 transmits 532 a PMM join request to the first vehicle 510. The PMM join request is signed and comprises a public encryption key of the sender, i.e. the second vehicle. The first vehicle 510 receives the PMM join request, and responses by transmitting 533 a PMM join response. The PMM join response is signed and encrypted with public encryption key of intended recipient. The intended recipient is the sender of the corresponding join request, i.e. the second vehicle in this example. The PMM join response comprises pre-shared symmetric encryption key for PCMs. The symmetric encryption key is generated by the first vehicle 510, i.e. the leading vehicle, and passed down to the second vehicle(s) 520, i.e. to the follower(s). The second vehicle 520 receives the PMM join response. A flag isjoinable=false 534 may indicate that there is already a vehicle following the first vehicle 510, and therefore, the first vehicle might not be able to accept another vehicle to follow it.

[0074] The second vehicle 520 receives 535 the PCM which is encrypted with pre shared symmetric encryption key received in the join response. PCM may comprise information on vehicle’s position, speed, vehicle attributes such as brake performance etc. Information comprised in the PCM may be confidential information, e.g. related to proprietary information of the manufacturer, and/or information that may be used to track vehicles across time and space. Number of vehicles that may read such confidential information may be controlled, e.g. minimized, via encryption of the messages. The second vehicle 520 transmits 536 the PCM to the first vehicle 510. The first vehicle and second vehicle may exchange 537 PCMs, as indicated by the dots in Fig. 5. The second vehicle transmits 538 a PMM leave to the first vehicle, and indicates that it wants to leave from the platoon. The PMM leave is signed. A flag isjoinable=true 539 may indicate that the first vehicle is again able to accept a vehicle to follow it, since the second vehicle 520 has left.

[0075] The GeoService may keep the association of one or more transport addresses, or transport layer addresses, to a recipient ID in a database. Transport layer address may comprise an IP address and a transport layer, e.g. user datagram protocol (UDP), port number. The port number may be a static, well-known one applicable to all recipients, or the port number may be different for each recipient because GeoService may use the source port of incoming messages as destination port for outgoing messages. Transport addresses may comprise any data needed to effectuate sending of a message to a recipient. [0076] In case of asymmetric encryption methods, there may typically be a single transport layer address associated with a given recipient ID.

[0077] In case of symmetric encryption, there may typically be multiple transport layer addresses associated with a given recipient ID, and the recipient ID acts as kind of a group identifier for those multiple transport layer addresses. [0078] Assuming that the database of associations of the transport layer addresses to recipient IDs is already populated, the approach for GeoService to forward an encrypted message may be as follows. The recipient identification data, i.e. the recipient ID may be extracted from the security payload of the incoming message. The one or more transport layer addresses associated with the recipient ID may be identified. The message may be forwarded to all the transport layer addresses found to be associated with the recipient ID.

However, the message might not be forwarded to the transport layer address used as a source in the incoming message. This may be the case in symmetric encryption.

[0079] For populating the database, or refreshing entries within it, the GeoService may take the following approach. If an incoming message is encrypted, it may be checked or determined whether the encryption type is symmetric or asymmetric. If the encryption type is symmetric, the recipient ID may be extracted from the message. An entry may be added or updated in the database associating the transport layer source address of the incoming message with the recipient ID. There may be e.g. at least two transport layer addresses associated with the recipient ID. The encrypted message may be forwarded to all the transport layer addresses found to be associated with the recipient ID.

[0080] If an incoming message is signed, it may be checked whether it contains a public encryption key. Public encryption keys may be contained in the certificate that was used for the signing, or they may be contained as part of the signed payload. The message may even contain public encryption keys in both places. [0081] If there is at least one public encryption key contained in the message, the recipient ID may be derived for each public encryption key contained within the message. The procedure how to do this depends on where the public encryption is located.

[0082] Each derived recipient ID may be associated with the source transport layer address found in the incoming message. For example, a single transport layer address may be associated with the recipient ID. The signed message may be forwarded based on geolocation comprised in it.

[0083] A message may at the same time be protected by encryption as well as by a signature, i.e. both encrypted and signed. The protection layers may encapsulate the actual payload in a nested fashion. It is the outermost protection layer which is to be considered for the above steps. For example, with protection at the GeoNetworking layer, the encryption layer encloses the signature layer. Thus, for the above steps, if the outermost protection layer consists of encryption, then the handling for an encrypted packet is to be followed, even if there also is a signature layer nested inside the encryption layer.

[0084] The recipient ID may be part of the metadata sent alongside the actual encrypted data, and therefore, the recipient ID may be non-encrypted.

[0085] Adding or updating entries in a database based on potentially unauthenticated data, e.g. in case the signature is not checked, may be considered as a security risk. However, use of the method as disclosed herein may be considered less prone to an attack via resource exhaustion than the geolocation-based forwarding approach. This is because the resources that can be consumed by an attacker may be lower than for the geolocation- based forwarding approach. The soft state approach discussed below may be needed for basic operational purposes and mitigates the resource exhaustion potential of an attacker, since the unused entries may be deleted from the database, e.g. at the earliest possible occasion. As a consequence, the resources and efforts an attacker would need to invest into an attack are much higher than the damage that can be done, thus preventing the attack attempts. For example, an attacker would have to spoof IP addresses of a large number of users in a mobile network to create and maintain a relevant amount of bogus entries in the GeoService database, and then would have to continuously generate traffic for them to maintain the related bogus entries in the database. The GeoService may implement further attack mitigation approaches. For example, each deployment will have a typical maximum amount of expected legitimate entries in the database. If that number is exceeded in operation, then GeoService could trigger mitigation actions. For example, the GeoService may check entries in the new database against authenticated entries in the geolocation database, and purge any entries from the new database that do not relate to legitimate users.

[0086] The approach of having to check every signed message for potentially contained public encryption keys may be streamlined to reduce needed processing of messages. Every signed message does not necessarily comprise a certificate, but probably a reference to a certificate that is expected to be known on the receiver side. This implies that the public encryption key has not changed. It is possible to have a cache of known certificates so that unknown certificates can be detected and only those need to be examined. It is possible to agree beforehand what messages carry the relevant public encryption key. For example, in the platooning example, the PMM Join Response is a response to a preceding PMM Join Request. Thus, it may be defined that the PMM Join Request shall be the one to carry the public encryption key, obviating the need to examine other message types such as CAMs.

[0087] To be able to reduce the perceived overhead of having to scan many signed messages for a potentially included public encryption key, a combined approach may be applied. The recipient ID based dissemination may be used for forwarding messages encrypted with a pre-shared symmetric key. However, for forwarding messages encrypted with a public encryption key, the source IP address, and potentially source UDP port number, may be used to identify the sending entity, e.g. the sending station, in the GeoService’s geolocation database, which keeps both a station’s geolocation as well as its transport layer address. Then, the geolocation of the sender as recorded in the geolocation database is used to forward the encrypted message. If the recipient ID based approach would be used for forwarding messages encrypted with a public encryption key, it would be required the signed messages to be scanned for the public encryption key.

[0088] The benefit of using the source IP address, and potentially source UDP port number, for forwarding the messages is that this still does not require changes to protocols, message formats, or the architecture, and it keeps the security mechanisms intact. However, it incurs the overhead that the message may potentially be sent to a large number of recipients when only a single station is an intended recipient. Knowing the use case in the context of which these encrypted messages are sent might help to reduce this number. For example, in context of platooning, vehicles exchanging messages encrypted in this way can be expected to be in very close proximity. Namely in case a vehicle following another vehicle wants to join the vehicle in front, the vehicle in front would send such a message to the following vehicle only. Thus, it is up to the implementation to decide, for a certain deployment, on the trade-off of being able to send a message encrypted with a public asymmetric encryption key to exactly one station only but having to scan potentially many signed messages for potentially contained public asymmetric encryption keys vs. being able to avoid the afore-mentioned scanning at the cost of having to execute geolocation based forwarding to a potentially large number of recipients when only a single station is the legitimate recipient.

[0089] Fig. 6 shows, by way of example, forwarding messages encrypted with a pre shared symmetric key. Learning of the legitimate recipients and the learning of associations of the transport layer addresses with the recipients IDs is also shown. The GeoService 610 receives 620 PCM encrypted with symmetric key from a first vehicle 612, e.g. vehicle A. The GeoService stores 621 the association of recipient ID to vehicle IP address. The GeoService 610 receives 622 PCM encrypted with symmetric key from a second vehicle 614, e.g. vehicle B. The GeoService stores 623 the association of recipient ID to vehicle IP address. The GeoService forwards 624 the PCM to already known vehicle IP addresses. For example, the PCM received from vehicle B may be forwarded, i.e. transmitted 625, to the vehicle A, since its IP address is already known. The GeoService 610 receives 626 PCM encrypted with symmetric key from a third vehicle 616, e.g. vehicle C. The GeoService stores 627 the association of recipient ID to vehicle IP address. The GeoService forwards 628 the PCM to already known vehicle IP addresses. Thus, the PCM received from vehicle C may be forwarded, i.e. transmitted 629, 630, to the vehicles A and B, since their IP addresses are already known. Thus, the forwarding of the encrypted messages is based on previously learned associations. A certain recipient might not be able to receive data encrypted with a symmetric key until it has itself sent a message encrypted with that key. The first vehicle 612, the second vehicle 614 and the third vehicle 616, i.e. the vehicles A, B and C may be vehicles of the same platoon.

[0090] Fig. 7 shows, by way of example, forwarding messages encrypted with public asymmetric key. GeoService 710 receives 720 from a second vehicle 714, i.e. the following vehicle, a join request comprising public encryption key of the following vehicle. GeoService 710 stores 721 the association of recipient ID, which is derived from the public encryption key, to the vehicle IP address. GeoService 710 transmits 722 a join request comprising public encryption key of the following vehicle to a first vehicle 712, i.e. the leading vehicle. The leading vehicle leads the platoon and the following vehicle is a member of the platoon. The leading vehicle receives the join request and transmits 723 a join response encrypted with public encryption key of the following vehicle to the GeoService 710. The GeoService receives the join request and reads 724 the recipient ID from the encrypted payload. The GeoService identifies 724 the associated vehicle IP address based on the association of the public asymmetric key with the recipient ID being learned earlier. The GeoService forwards 724 the message to the following vehicle, i.e. transmits 725 the joint response encrypted with public encryption key of the following vehicle to the following vehicle. In this example, there is a single legitimate recipient.

[0091] Fig. 8 shows, by way of example a process flow 800 in a relay for information exchange, e.g. in the GeoService, for learning transport layer address to recipient ID associations, and for forwarding encrypted messages based on the learned associations. The outermost layer of protection may be relevant for deciding which path to follow in the process flow of Fig. 8. For example, even if an encrypted message comprises also a signature, since the encryption encloses the signature, the path for the encrypted message handling would be relevant for the handling for such a message.

[0092] The GeoService receives the message, i.e. the incoming message 802, and determines 804 whether the message is encrypted or not. In case it is encrypted, the GeoService extracts 806 the recipient ID. The recipient ID, or recipient identification data, may comprise an indication of security material used to obtain the encrypted message. The recipient ID may comprise an indication of security material needed to decrypt the encrypted message. The GeoService determines the encryption approach based on the recipient ID. It is determined 808, whether the message is encrypted with pre-shared key. In other words, it is determined whether the encryption approach is asymmetric or symmetric, or some future encryption approach. If the encryption approach is symmetric, i.e. the message has been encrypted with a pre-shared key, the GeoService may add or refresh 810 an entry in a database indicating an association between the recipient ID and the UE transport address, i.e. transport layer address. Then, the GeoService may find 812 UE transport address(es) associated with the recipient ID, and select the one or more recipients based on the recipient ID. Originator of the current message may be ignored. If the message has been encrypted using an asymmetric approach, i.e. using a public asymmetric key, the GeoService may directly find 812 UE transport address(es) associated with the recipient ID, without updating the database. Then, the GeoService forwards 814 the message to UE transport address(es), i.e. to the selected recipients.

[0093] In case the message is not encrypted, it is determined 822 whether the message is signed. If the message has not been signed, the GeoService forwards 824 the message based on geolocation information. If the message has been signed, it is determined 826 whether the message comprises a public encryption key of the sender of the message. If the message does not comprise the public encryption key, the GeoService directly forwards 824 the message to recipient(s) selected based on geolocation information. If the message comprises the public encryption key, the GeoService derives 828 the recipient ID from the message. Then, the GeoService may add or refresh 830 an entry in a database indicating an association between the recipient ID and the UE transport address, i.e. transport layer address. Then, the GeoService may proceed with forwarding 824 the message to recipient s) selected based on geolocation information.

[0094] There may be situations, wherein the stations, e.g. the message sending entities or message receiving entities, that have a need to communicate with each other, are served by different neighboring GeoService entities. In the context of platooning, for example, the station may be a vehicle participating in the platoon. They may be in close geographical proximity, but may be served by different neighboring GeoService entities, e.g. for reasons of mobile network cell structure. To cover those cases, plurality of relays of message exchange, or GeoService entites, may exchange, periodically and/or event-based, a description of their geographical coverage area with each other. Then, when one GeoService forwards a message to recipients in a specific geographic area, it can identify if there might be relevant recipients in that area served by another GeoService. Then, the two GeoServices may interact to effect forwarding of such messages also to recipients served a GeoService entity other than the one where the message originated.

[0095] Thus, also for forwarding of encrypted messages, interaction of neighboring GeoService entities may be needed to reach all relevant recipients. Thus, the following procedures may be needed. [0096] A GeoService entity may learn, or identify, a new association between a transport layer address and recipient identification data, i.e. a recipient ID. In response to the identifying the new association, the GeoService may forward that association to another relay of message exchange, e.g. to relevant neighboring GeoService entity or entities.

[0097] A GeoService may receive a new association from a neighboring GeoService. Then, it may store this association and associate it with the GeoService entity from which it was received. The GeoService may store the association e.g. in a local database, or in a software-internal data structure.

[0098] When a GeoService needs to forward an encrypted message that was received from a locally served station, it may, in addition to checking its database of local associations for transport layer addresses associated with a given recipient ID check the associations received from neighboring GeoService entities. If the recipient ID is found in the received associations, e.g. in this additional local database, it may forward the message to the neighboring GeoService associated with the recipient ID.

[0099] If a GeoService receives an encrypted message forwarded from a neighboring GeoService, it may look into its database of local transport layer address to recipient ID associations. Then, it may forward the message to the identified recipients, just as it would for a message received from a station it serves itself. It may be expected that it will find at least one recipient in its database because the neighboring GeoService only forwarded the message to the local one because the local one had previously informed the neighboring GeoService that it maintains this association. Note that the receiving GeoService usually does not forward the message to further GeoService entities because it may be assumed that the originating GeoService would already have forwarded the message to all of the relevant neighboring GeoService entities.

[00100] The exchange of coverage areas between neighboring GeoService entities may happen rather infrequently as the coverage areas typically change slowly. However, the new recipient IDs that a GeoService learns is beneficial to be conveyed to neighboring GeoService entities immediately. This is because the recipient IDs themselves may be very short-lived. Another reason may be that the stations to be addressed by a specific recipient ID may quickly move from being served by one GeoService to being served by another GeoService. Immediate communication of recipient IDs between neighboring GeoService entities ensures that all relevant recipient stations can be reached even if they move between neighboring GeoService entities.

[00101] GeoService may apply the association learning process based on signed messages received from stations also to signed messages received from neighboring GeoService entities. The association learning process may be applied to the learning of associations related to public asymmetric encryption keys. In this case, some reference to the neighboring GeoService entity may be associated with a recipient ID. The reference may be any suitable reference that enables the GeoService to forward messages to the neighboring GeoService. For example, an ID may be stored in the association table, and when a message is to be forwarded, another table is used to find transport layer information to effectuate the actual forwarding. Or, the reference may be transport layer information itself. This is different compared to previously described association learning process along with encrypted messages with pre-shared symmetric keys, wherein the transport layer address of the originating station would be associated with a recipient ID. Non-encrypted messages may be forwarded between GeoService entities based on the geolocation-based forwarding. For the encrypted messages with pre-shared symmetric keys, the inter- GeoService notification mechanism may be needed.

[00102] The database entries with the associations of transport layer addresses to recipient IDs, or neighboring GeoService entity reference to recipient ID(s), may be so called soft state entries. This means that if a particular association is not updated or refreshed within pre-defmed time period, or periodically, by new messages confirming the association, it is removed from the database. For example, if an association of a transport layer address to a particular recipient ID is not updated by new messages confirming the association, it is removed from the database. As an example, the platooning use case may define a timeout, i.e. a time period, after which a station is considered to have left the platoon if no messages have been received from that station during the pre-defmed time period. The timeout of an association entry for a pre-shared symmetric key may be aligned to the timeout value of the underlying protocol. The entries being soft state entries may be beneficial e.g. in mitigating the resource exhaustion potential of a possible attacker, as described above.

[00103] It depends on the use case, which encryption method is used. For example, if multiple recipients should be able to decrypt a message, then symmetric keys may be used rather than asymmetric encryption algorithms. Symmetric keys may also be used to secure communication between e.g. two parties, or even just one direction of communication between two parties. However, asymmetric encryption algorithms may be beneficial to be used for communication between two parties as having to securely distribute the shared key between parties may be avoided.

[00104] In general, it may be possible that a message is encrypted with asymmetric mechanisms, but intended for multiple simultaneous recipients. In this case, the message itself may be encrypted with symmetric algorithms and a shared symmetric key. This shared symmetric key may then be encrypted with the asymmetric public encryption keys of the intended recipients. Then, all those variants of the encrypted key may be included in the message with an indication of the asymmetric key that is needed to decrypt each variant. In such a case, the relevant method above is applied for each single intended recipient as listed in the message.

[00105] It may be that a single message is encrypted using asymmetric encryption and symmetric encryption at the same time, intended for different recipients. In that case, depending on the recipient listed and the encryption method for each of them, the message may be forwarded either based on geolocation or based on recipient ID.

[00106] Even if a single recipient is intended, and asymmetric mechanisms are used, it is not necessary the actual data that is protected by encryption. The actual data may be encrypted with a symmetric key, usually because symmetric mechanisms may be faster and more efficient than asymmetric mechanisms. It may then be the symmetric key that is encrypted using an asymmetric mechanism. The symmetric key may, in general, be shorter and thus faster to encrypt with asymmetric mechanisms than the actual payload to be encrypted. The encrypted encryption key may be conveyed to the recipient alongside the encrypted data. Thus, there may be multiple nested levels of encryption. Further, it may be that a symmetric pre-shared key is not used to directly encrypt the data, but a level of indirection is introduced. This means that the symmetric pre-shared key is used to encrypt another symmetric key, which is then used to encrypt the actual data, and both the encrypted data itself as well as the encrypted encryption key are conveyed to the recipient. Intended recipients may be determined based on the recipient identification data, i.e. the recipient ID. When the recipient ID is concerned, it is referred to the outermost level of encryption. Only the intended recipients may access or open the outermost level of encryption and then proceed to further open the further nested levels of encryption.

Claims

CLAIMS:

1. An apparatus comprising means for: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

2. The apparatus of claim 1, wherein selecting one or more recipients based on the recipient identification data comprises identifying one or more transport addresses associated with the recipient identification data; and forwarding the encrypted message to the selected one or more recipients comprises forwarding the encrypted message to the one or more identified transport addresses associated with the recipient identification data.

3. The apparatus of claim 1 or 2, wherein the recipient identification data further comprises an indication of security material needed to decrypt the encrypted message.

4. The apparatus of any preceding claim, further comprising means for determining whether an encryption approach used to obtain the encrypted message is asymmetric encryption and/or symmetric encryption, or some other encryption.

5. The apparatus of claim 4, wherein the encryption approach is symmetric encryption, and the apparatus further comprises means for storing or updating association of one or more transport addresses with the recipient identification data.

6. The apparatus of any preceding claim, wherein the encrypted message is a platoon management message.

7. The apparatus of any preceding claim, wherein the encrypted message is a platoon control message.

8. The apparatus of any preceding claim, further comprising means for detecting that a stored association of one or more transport addresses with the recipient identification data is not updated within a pre-defmed time period; and removing, in response to the detecting, the stored association.

9. The apparatus of any preceding claim, further comprising means for identifying a new association between a transport address and recipient identification data; and forwarding the new association to another relay of message exchange.

10. The apparatus of any preceding claim, further comprising means for receiving a new association from another relay of message exchange; and storing the new association and associating the new association with the another relay of message exchange.

11. The apparatus of any preceding claim, wherein the means comprises at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the performance of the apparatus.

12. A method comprising: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

13. The method of claim 12, wherein selecting one or more recipients based on the recipient identification data comprises identifying one or more transport addresses associated with the recipient identification data; and forwarding the encrypted message to the selected one or more recipients comprises forwarding the encrypted message to the one or more identified transport addresses associated with the recipient identification data.

14. A computer readable medium comprising program instructions that, when executed by at least one processor, cause an apparatus to at least to perform: receiving an encrypted message; receiving recipient identification data comprising at least an indication of security material used to obtain the encrypted message; selecting one or more recipients based on the recipient identification data; and forwarding the encrypted message to the selected one or more recipients.

15. A computer program configured to cause a method in accordance with at least claim 12 or 13 to be performed.