The present invention relates to the field of wireless communications, and in particular to relaying architectures in the context of cellular networks, like the UMTS Long Term Evolution (LTE) or LTE Advanced (both included in 4G), New Radio (NR) (5G) or other cellular networks or mobile communication networks.
In conventional cellular networks, a primary station serves a plurality of secondary stations located within a cell served by this primary station. Wireless communication from the primary station towards each secondary station is done on downlink channels. Conversely, wireless communication from each secondary station towards the primary station is done on uplink channels. The wireless communication can include data traffic (sometimes referred to User Data), and control information (also referred sometimes as signalling). This control information typically comprises information to assist the primary station and/or the secondary station to exchange data traffic (e.g. resource allocation/requests, physical transmission parameters, information on the state of the respective stations).
In the context of cellular networks as standardized by 3GPP, the primary station is referred to a base station, or a gNodeB (or gNB) in 5G (NR) or an eNodeB (or eNB) in 4G (LTE). The eNB/gNB is part of the Radio Access Network RAN, which interfaces to functions in the Core Network (CN). In the same context, the secondary station corresponds to a mobile station, or a User Equipment (or a UE) in 4G/5G, which is a wireless client device or a specific role played by such device. The term “node” is also used to denote either a UE or a gNB/eNB.
In the 3GPP, it has been introduced the role of a relay node as shown on
Additionally, in such systems, as depicted on
In 3GPP SA2, communication models and procedures are being discussed and agreed for relay-based systems. These procedures are included in TR 23.752. In 3GPP SA3, security solutions and procedures are being discussed and agreed for relay-based systems. These procedures are included in TR 33.847.
For instance, Solution #28 in TR 23.752 describes a mechanism for the Remote UE to discover a Layer-3 UE-to-Network Relay and establish a PC5 unicast connection with a UE-to-Network relay. This mechanism does not require interaction with the core network during operation.
For instance, Solution #32 in TR 33.847 describes a mechanism for the Remote UE to protect its PDU parameters from the UE-to-Network relays so that only authorized relays have access to them. This solution requires interaction with the core network.
The current solution discussed in Solution #28 in TR 23.752 presents the advantage that it does not require interaction with the CN during discovery. However, it also presents some problems, for example related to KI #16 in TR 33.847. It has not been solved how to avoid the pre-configuration of slicing information (problem 1). Also, this solution requires the PDU session parameters being transported in the clear (problem 2). A possible solution to these issues in TR 33.847 is Solution #32. However, this solution requires communication over the core network in the course of the operation (problem 3) in order to achieve the protection of privacy of PDU parameters.
One aim of the present invention is to alleviate the above-mentioned problems.
Another aim of the present invention is to propose a method for communicating in a network that allows a secure set up for the establishment of a protocol data unit (PDU) session for a secondary station.
Still another aim of the invention is to propose a method of a secondary station for communicating in a network which requires minimal interaction with the Core Network once in operation.
To this end, it is proposed in accordance with a first aspect of the invention, it is proposed a method for operating a system as claimed in claim 1, and its variants in the dependent claims.
Thus, in accordance with the first aspect of the invention, the secondary station and the relay station gets the required security elements from the Core Network, e.g., a signed public key bound to the receiving UE, at an early stage, for example in the initial connection to the cell. In a later phase, for example during the operation of the network, the secondary station and the relay station can establish a secure exchange and authentication for starting a PDU session.
In exemplary embodiments described in the following, the configuration parameters included in the first message and in the second message can be Relay Service Codes (RSCs). However, these configuration parameters may also be different parameters or a combination of parameters such as any one or more of the following:
In accordance with a second aspect of the invention, it is proposed a method for operating a relay station as claimed in claim 18
In accordance with a third aspect of the invention, it is proposed a method for operating a secondary station as claimed in claim 19.
In accordance with a fourth aspect of the invention, linked to the second aspect of the invention, it is proposed a relay station as claimed in claim 20.
In accordance with a fifth aspect of the invention, linked to the third aspect of the invention, it is proposed a secondary station as claimed in claim 21.
In accordance with a sixth aspect of the invention, it is proposed a computer program product comprising code means for producing the steps of the method of the first, second or third aspects of the invention when run on a computer device.
Thus, in accordance to the first aspect of the invention, it is proposed a method for operating a communication system including a primary station linked to a Core Network, said primary station serving a cell, a relay station served by the primary station and a secondary station served by the primary station, the method comprising the steps of
In accordance with the second aspect of the invention, it is proposed a method for operating a relay station adapted for communicating in a network, including a primary station linked to a Core Network, said primary station serving a cell, and a secondary station served by the primary station, wherein the relay station is served by the primary station, the method comprising the steps of
In accordance with the third aspect of the invention, it is proposed a method for operating a secondary station adapted for communicating in a communication system including a primary station linked to a Core Network, said primary station serving a cell, a relay station served by the primary station, wherein the secondary station is served by the primary station, the method comprising the steps of
In accordance with the fourth aspect of the invention, it is proposed a relay station adapted for communicating in a network, including a primary station linked to the Core Network, said primary station serving a cell, and a secondary station served by the primary station, wherein the relay station is served by the primary station, the relay station comprising
In accordance with the fifth aspect of the invention, it is proposed a secondary station adapted for communicating in a communication system including a primary station linked to the Core Network, said primary station serving a cell, a relay station served by the primary station, wherein the secondary station is served by the primary station, the secondary station comprising
In accordance to a first option that can be combined with any of the first to fifth aspects of the invention, the first secure message further includes a relay public encryption key and the corresponding relay private encryption key.
Similarly, according to a second option that can be combined with the first to fifth aspects of the invention or with the second option of the invention, the second secure message further includes a secondary station public encryption key, and the corresponding secondary station private encryption key.
In a third option, which can be combined with the second and/or third options, the at least one first secure message includes at least one first Core Network signature from the Core Network generated at least on
Alternatively, a fourth option which can be combined with the second and/or third options, the at least one first secure message includes at least one first Core Network signature from the Core Network generated at least on
In a fifth option of the invention which can be combined with the third or the fourth options, the step of establishing a direct communication includes:
Further to the fifth option which can be combined with the fourth option, the direct communication request includes a secondary station nonce, and wherein the response message signature is generated by applying the relay private encryption key on at least the secondary station nonce.
In addition, in a sixth option which can be combined with the fifth option, the response message signature is generated by applying the relay private encryption key on at least the secondary station nonce, and at least one of the Core Network first signature, the relay public encryption key.
In a seventh option to be combined with the fourth, fifth or sixth option, the response message further includes a relay nonce, and wherein the secondary station transmits communication parameters in a configuration message, said configuration message including a configuration message signature, said configuration message signature being generated by applying the secondary station private encryption key on at least the relay nonce.
In an eighth option to be combined with the seventh option, said configuration message signature is generated by applying the secondary station private encryption key on at least the relay nonce, and at least one of the Core Network second signature, the secondary station public encryption key.
In a ninth option which can be combined with the first to fifth aspects of the invention, wherein the step of establishing a direct communication includes:
In a tenth option which can be combined with any of the aspects and options of the invention, the relay station transmitting the at least one transmitted attribute of the first set of configuration parameters or a service code from the first set of configuration parameters and at least one of the following further information: a data session policy, a data session parameter, the first Core Network signature, a relay public encryption key, and wherein the secondary station establishing a direct communication with the relay station upon determination that the transmitted attribute of the first set of configuration parameters or the transmitted service code is included in the second set of configuration parameters and that the further information is compatible for the upcoming data session.
In an eleventh option to be combined with the tenth option, the transmitted message from the relay station includes a signature applied at least on a time stamp.
In a twelfth option of the invention which can be combined with any of the aspects and options of the invention, the at least one transmitted service code from the first set of configuration parameters is the result of a hashed service code of the first set combined with a transmit nonce, and the relay station further transmit the transmit nonce.
In a thirteenth option of the invention which can be combined with the fifth to tenth options, the method further comprises the secondary station informing the Core Network if the checking of the first Core Network signature fails.
In a fourteenth option, to be combined with the first to fifth aspects of the invention, the relay station establishing a connection with the primary station includes the relay station generating a relay public encryption key and relay private encryption key, sending the relay public encryption key to the primary station for signature by the Core Network, and receiving in the at least one first secure message from the primary station the first set of service codes and a first Core Network Signature based on at least the relay public encryption key.
In a fifteenth option of the invention to be combined with the first to fifth aspects of the invention or with the fourteenth option, the secondary station establishing a connection with the primary station includes the secondary station generating a secondary station public encryption key and a secondary station private encryption key, sending the secondary public encryption key to the primary station for signature by the Core Network, and receiving in the at least one second secure message from the primary station the second set of service codes and a second Core Network Signature based on at least the secondary station public encryption key.
It is noted that the above apparatuses may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet.
It shall be understood that the wireless device, the system, the relay station, the cell station and the method may have similar, corresponding and/or identical preferred embodiments, in particular, as defined in the dependent claims.
It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.
In the following description, solutions addressing problems 1, 2, and 3 are described in various embodiments. These solutions involve in a first embodiment the distribution of information—in particular, a public key bound to each UE (secondary station, also referred to as Remote UE and the relay station, also referred to as a Relay UE)—signed by the CN to each UE. This distribution of information phase happens during the initial provisioning and authorization step, i.e. at an early stage of the connection. The UE can be a Remote UE or a Relay UE. It is also possible that in operation, a considered UE may have to operate alternatively as a Relay UE and as Remote UE. The signed information, including a public key, allows in this first embodiment:
The main benefit of this first embodiment of the invention compared with existing security solutions (Solution #28 in TR 23.752 and Solution #32 in TR 33.847) is that it does not require access to the core network during operation while it operates in a secure way. This means that:
This first embodiment thus offers a solution that is applicable to Solution #28 in TR 23.752 to address the privacy concerns around problems 1 and 2.
Besides, although this first embodiment is described in the context of protection of PDU parameters in the context of KI #16 in TR 33.847, the same techniques and other embodiments building on them can be used to address other problems, for instance, as described in the table below. The detailed description includes multiple embodiments providing solutions to these problems. In particular, it provides improvements to Solution #8 and Solution #31 in TR 33.847. These two solutions are the only ones using public key cryptography in TR 33.847. Solution #8 and Solution #31 address KI #6 and KI #7 respectively.
It is to be noted that the first embodiment of the invention is applicable to protect the confidentiality of other parameters. For instance, the Application Function address as in Solution 21 in TR 33.847.
It is to be noted that this solution can also be used—independently—for security establishment in the PC5 as alternative solution to Solutions #1, #6, #10 and #15 in TR 33.847.
The first embodiment will now be described with reference to
The first embodiment corresponds to the ProSe operation in accordance with the “Discovery Model A”. Indeed, restricted ProSe direct discovery is a process that a UE detects and identifies another UE in proximity using its Radio Access direct radio signals with explicit permission of the UE that is being discovered. In accordance with the discovery model A (“I am here”), two roles of ProSe-enabled UEs are involved in this model: Announcing UE and Monitoring UE. The announcing UE broadcasts discovery messages at pre-defined discovery intervals and the monitoring UEs that are interested in these messages read them and process them. As an alternative, in the Model B (“who is there?”/“are you there?”), two roles of ProSe-enabled UEs are involved: Discoverer UE and Discoveree UE. It is equivalent to “who is there/are you there” since the discoverer UE sends information about other UEs that would like to receive responses from, e.g. the information can be about a ProSe Application Identity corresponding to a group and the members of the group can respond.
In accordance with the first embodiment, as shown on
Some or all of these items can be signed with the relay's private key (PrK_relay).
In
In this description, “I” corresponds to the concatenation operation.
The whole message can then be encrypted with the public key of the relay node PuK_relay, so that these parameters and information are not sent in the clear over the air. As can be seen in
Thus, as explained earlier, during the connection to the Relay UE, neither the Relay UE nor the Remote UE need to communicate with the Core Network for authentication/authorization purposes. All the verification being implemented beforehand, this leads to a smooth and secure connection protocol without assistance from the CN during operation. Thus, even out of coverage UE may be able to securely connect to the PDU session.
As explained earlier, Discovery Model B requires the Remote UE to broadcast in order to connect to a Relay UE. Thus, when implementing a variation of the first embodiment to the specific case of Discovery Model B, at step c, the remote UE would broadcast its configuration parameters such as its RSCs. In the subsequent steps of this alternative, the Relay UE matches the received configuration parameter, e.g. the received RSC with its own ones. If there is a match, then the Relay UE can send its signed RSC, a relay nonce, CN signature related to that relay service code, and/or its public key similar to the subsequent steps in the first embodiment (Model A).
In a variant of the first embodiment, it is possible that the relay UE cannot be traced. To this end, the remote UE might generate an ephemeral public key pair and send it to the relay UE in step e.i. Since this public key pair is ephemeral, it cannot be used to trace the remote UE. The relay UE uses it in step e.ii to encrypt the message so that the relay parameters remain confidential from external (passive) attackers. Thus, the step of establishing a direct communication can include the secondary station generating its own encryption public key and private key. Together with the secondary station nonce, the remote UE can send a direct communication request to the relay station. This first message like in the first embodiment can optionally be secure.
In response to the direct communication request, the relay station sends a response message including a relay public encryption key and/or a first Core Network signature and/or and a response message signature where this message is protected (confidentiality) using the public key received with the direct communication request.
Then, the secondary station can decrypt the received message and check the first Core Network signature included in the response message and the response message signature.
It is to be noted that the above protocol can exchange RSCs in Step c since the discovery messages are small. Another variant of the first embodiment reducing the number of round trips consists in the relay UE broadcasting at that point of time (Step c) its configuration parameters (or part of them), policy, public key, and signature. If this is done, in Step d, the remote UE can already check whether the relay UE policy supports its PDU communication requirements. If it does, it checks the policy and public key validity by verifying the signature. In a subsequent step e according to this variant, the remote UE can decide to establish a PC5 connection as in Solution #28 with the addition that the UE shares its signed PDU session requirements encrypted with the public key of the relay UE. Finally, in step f, the relay UE can decrypt the remote's UE data, and verify its signature. If the verification is correct and the parameters are allowed by its policy, the relay UE will serve the needs of the remote UE.
Here, and anywhere in this document, verifying the signature may include checking the signature itself and also other fields such as an expiration date, issuer, and so on. Note that this might also include retrieving or accessing a revocation list where revoked public keys are included.
Further to this previous variant, the following can be done to (further) mitigate replay attacks: in step 1 c, the relay UE can use its private key to sign at time stamp, such as the current UTC time and optionally the rest of broadcasted information. This signature can also be included step 1 c. In step 1 d, the remote UE verifies the received signature on the UTC time and checks whether this time is recent. This thus avoids the risk of an attacker storing and replaying past messages.
Further to this previous variant, the following can be done to (further) mitigate MitM attacks. The relay UE can use its private key to sign its current location, e.g., GPS coordinates, building name, etc. This information can be included in step 1c. In step 1d, the remote UE verifies the received signature and checks whether the location matches its own one. This avoids the risk of an attacker having compromised a relay device at a specific location and reusing its broadcast messages at multiple locations. This feature can be used independently and standalone.
Since the broadcast of static RSCs can be considered as a privacy risk, another variant of the first embodiment consists in the sending party generating a nonce N and deriving a pseudo-RSC as pRSC=HASH(RSC|N) where HASH is a hash function takes as input the concatenation of RSC and N. The sending party then broadcasts (pRSC, N) (Step c). The receiving party has to apply the hash function to each of the RSCs it has and check whether there is a match. For this approach to be secure and work without collisions, pRSC, RSC, and N should be long enough. If the values can only be small in the discovery message (Step c), the following messages might include another pair (pRSC′, N′) using longer parameters.
In the first embodiment and all the variants discussed previously, if step e.iii fails, the remote UE will abort the connection. The remote UE can then inform the CN about the failed verification, and the relay UE parameters, the next time it is connected. Similarly, if step e.v fails, the relay UE refuses the delivery of the service. The relay UE can inform the CN about the failed verification, and the remote UE parameters. Thus, in case of a security risk being discovered, the Core Network is rapidly informed and =can check the concerned stations.
In a further variant of the first embodiment, the Remote UEs may receive the public keys (or the fingerprints) of the allowed relay UEs already in Step 1.b instead of in step e.ii.1, for example from the Core Network.
As explained in the first embodiment, in Step 1.d, the remote UE checks whether the relay UE supports its PDU requirements by checking whether an RSC matches. This is a one-to-one relationship and resembles a “role-based access control” approach employing pre-defined roles to carry out specific actions. In other words, if relay UE has RSC=x, then relay UE is authorized.
This signed RSC can be seen as an “authorization token”. It can then be considered the proposed operation in which the RSC (the “authorization token” without signature) is distributed in step 1.c to perform a first check that fits the bandwidth needs of the discovery message. The complete “Authorization token” can be distributed in step e.ii, if a match is detected in the previous step. This simple operation—standalone—could be integrated in, e.g. Solution 31 in TR 33.847.
We note that more complex “policies” can be defined in the context of “Attribute-based access control”. Instead of having only RSCs, we can consider more attributes related to the type of device the relay UE is (e.g., is it a private device? Is it public device?), the actions to be performed (e.g., upload of data? Download of data?), the data being accessed (e.g., confidentiality level?), the identifiers of applications, devices, or groups, or the current context (e.g., normal or emergency situation). The receiving party (e.g., remote) can have a policy, e.g., an XACML access control policy that can be used to check whether the sending party (e.g., relay) is authorized or not. This policy can be distributed during provisioning together with other configuration parameters that include any device attributes such as RSCs.
If the solution requires other sets of information or configuration parameters (that can be considered as roles or attributes) during discovery, e.g., as Solution #11 or Solution #8 in TR 23.752, this information can also be signed and distributed by the CN during the initial provisioning. The CN can also distribute during provisioning policies stating which requirements the other party should fulfil to be allowed to act as a relay, remote or peer. The information sent in step e.ii and e.iv might include all or part of the information sent during discovery, including the corresponding CN signature so that upon reception the data can be verified and cross-checked against the policy also received during provisioning.
In Steps 1.a and 1.b the CN generates a key pair for both remote UE and relay UE. Alternatively, the key pair can be generated by the UEs and the public key can be sent to the CN to be signed. The advantage of doing this so is that the CN does not have knowledge of the private key.
In Steps 1.a and 1.b, the CN signs a set of information for both remote UE and relay UE. The CN could also sign multiple sets of information so that the UEs can rotate them, i.e., change regularly, due to privacy reasons.
In Steps 1.a and 1.b, the CN signs public keys for both remote UE and relay UE. These public keys are associated to the corresponding private keys. In a further variant, the key pairs can be sometimes used for public key encryption and sometimes for digital signatures. In general, it is feasible to reuse (in a secure way) the same key pair for both signing and encryption. However, this is not a recommended practice since information leaked, e.g., when encryption might be used to break signatures. Thus, Steps 1.a and 1.b might also include the delivery of multiple, e.g., 2, signed public keys so that each of them can be used for a different purpose, e.g., encryption and signing.
If a remote UE has multiple RSCs for multiple PDU parameters, an option is that the CN signs all that information together. The problem of this approach is that when the remote UE sends this information to the relay UE for verification (message e.iv in
The same applies to the RSCs in the relay. In this case, the RSCs might correspond to the leaves of a Merkle tree. When the relay discloses a specific RSC in message e.ii in
Given above information, the receiving party has to use the path of the Merkle tree, RSCs (and PDU parameters) to check that the information allows recomputing the root of the Merkle tree, and then check the signature.
In all the variants, a suitable signature algorithm can be an Elliptic Curve (EC) Digital Signing Algorithm (DSA).
The information provided in the initial provisioning steps might include a different signature for each piece of information, e.g., for each RSC, for each public-key, for each PDU parameter. The advantage of this is that different pieces of information can be disclosed independently of each other.
In above description, public key encryption has been used. This can be replaced by identity-based encryption (IBE). In IBE, the identity of a UE corresponds to its public key. Given the identity of a UE, the CN uses a master secret to derive the corresponding private key for that UE. An advantage of IBE is that public keys do not need to be exchanged. Another advantage is that the public key serves as the “certificate” itself and only “authorized” parties will receive or be able to decrypt the privacy sensitive content. For instance, assume a relay with identity “RSC=x, expiration_date=2022/02/22”. This is the information that a relay can broadcast and a remote UE can receive. If RSC=x and expiration_date are fine for the remote UE according to a policy that the remote UE has received from the CN during provisioning, the remote UE can use this identity “RSC=x, expiration_date=2022/02/22” of the relay UE as its public key. This means that the remote UE will use this public key to encrypt any privacy sensitive parameters such as PDU parameters and send this encrypted information. Only the relay having the corresponding private key—issued by the core network—will be able to decrypt the information.
In the above description, a UE owns a private key that can be used to prove its identity. However, a digital signature might be too bulky for some implementations, and its verification might require a considerable computational time. This is especially relevant for the discovery messages whose size might be limited in size, e.g., limited to a few hundreds of bits. An alternative solution to this consists in the CN configuring an announcing UE (e.g., a relay device) and monitoring UEs (e.g., a remote UE) with the seed and anchor of a hash chain so that the hash chain links can be used to prove that some broadcasted messages are coming from the announcing UE. Such a solution is relevant, e.g., for the discovery message sent by the announcing UE. This discovery message corresponds to message c. in
This solution focuses on Key Issue #1(Discovery message protection). This solution proposes to reuse the open discovery security mechanism specified in TS 33.303 for 5G ProSe open discovery, as Solution #3 in TR 33.847 does, but enhanced to:
The proposed enhancements are motivated by the fact that in TS 33.303 the integrity protection of the discovery messages over the PC5 interface requires a Discovery User Integrity Key (DUIK). This key is used to compute a Message Integrity Code (MIC). The MIC can be verified at the receiving UE, if the UE has been supplied with the DUIK or at the ProSe Function using the DUIK. In the first case, if the DUIK is supplied to a monitoring UE, the monitoring UE can verify the MIC itself. However, if multiple monitoring UEs receive the same DUIK, it is not feasible to guarantee integrity protection, replay protection or source authenticity, since any of those UEs might be malicious. If the ProSe Function has to check the MIC, this increases the load on the CN and the overall communication latency.
The basic idea of this solution is to complement the usage of the DUIK with a Discovery User Integrity Hash Chain (DUIHC) for source authentication. In the following,
Where,
Including either “j” and/or “Identifiers” in the computation of Hj(input) is optional but makes the solution more resilient against pre-computation attacks. The usage of TRUNCb(A) aims at being able to reduce the communication overhead.
With this, a DUIHC is obtained from a randomly generated seed S as:
S→H
1(S)→H2(S)→H3(S)→ . . . →HN−2(S)→HN−1(S)→HN(S)
Here, the arrow “4” indicates the direction when generating the links H1(S), H2(S), . . . of the hash chain. The last element, HN(S), is the anchor of this DUIHC.
An announcing UE such as a Relay UE is given the seed S of its DUIHC. All monitoring UEs are given the anchor of the DUIHC of the announcing UE. These steps can be done during the authorization and initial provisioning of the devices corresponding to Step a and Step b in
When an announcing UE wants to send an announcing message m at UTC time t, the announcing UE may first compute the current timeslot j as (t−t0)/tDelta implying that the announcing UE has to use DUIHC link HN−j(S). Note that this requires that N-j>0. The announcing UE uses HN−j(S) together with the DUIK to compute the final key used in the creation of the MIC of the message m. This key is denoted as Discovery User Integrity Key and Hash Chain Link (DUIKHCHL) and is computed as:
DUIKHCL=Hash(DUIK|HN−j(S))
The reason for including the DUIK in the derivation of the DUIKHCL is to provide interoperability with the existing TS 33.303 solution. This also ensures that this solution is as secure as the existing one. We note that an alternative is to use only HN−j(S), or a key dependent on it in the computation of the MIC.
The MIC of message m is denoted MICm and computed as:
MICm=MIC(m,DUKHCL)
The announcing UE may also include the previous DUIHC link, namely HN−j+1(S), in the broadcasted announcing message:
m,H
N−j+1(S),MICm
When a monitoring UE receives the above announcing message at time t, the monitoring UE first computes the timeslot j by taking as input the reference time t0 and the timeslot duration tDelta. Then, the monitoring device caches the received message till the next time slot j+1 to receive HN−j(S) in the following announcing message. With WAS), the monitoring UE can check:
The resulting message flows are similar to Solution #3 in TR 33.847 and the open discovery security mechanism specified in TS 33.303. Referring to
Additionally:
The basic idea described above can be similarly applied to restricted discovery Mode A.
The basic idea described above can also be applied to restricted discovery Mode B. This might require that both the Discoveree UE and Discoverer UE can be the owner of a DUIHC to prove their identities based on a policy. Owning a DUIHC is especially relevant for the Discoveree UE if multiple Discoverer UEs can discover the same Discoveree UE and the verification of the response (Response Code) from the Discoverer UE is done locally by the Discoveree UEs.
An alternative method—which can be used with or without the DUICH approach described above—to improve the security guarantees in the discovery message is as follows. In mode B, see TS 33.303, the Discoverer UE is required to send a Query Code to the Discoveree UE. The Discoveree UE has to check its integrity/freshness/source authenticity, and if this verification succeeds, the Discoveree UE replies to the Discoverer UE with a Response Code. The Discoverer UE has to be able to check the integrity/freshness/source authenticity of this message. In TS 33.303, the verification by the Discoveree UE based on the DUIK can only happen locally; however, the DUIK-based verification by the Discoverer UE can happen locally or remotely in the core network based on a match report. This can lead to a situation in which, e.g., if multiple Discoverer UEs can discover the same Discoveree UE, then one of the Discoverer UEs might misbehave and impersonate a Discoveree UE. This situation can be improved by having two DUIKs, a DUIKre from Discoverer UE to Discoveree UE, and a DUIKer from Discovee UE to Discoverer UE. This guarantees that if multiple Discoverer UEs can discover the same Discoveree UE, none of the Discoverer UEs can impersonate the Response Code generated by the Discoveree UE if the MIC of the Response Code is verified by means of a match report. Further details and clarifications on this second point are as follows:
Tdoc S3-212464, submitted to 3GPP SA3 #104e, describes keying procedures for group member and relay discovery. In particular, this Tdoc describes how the UE obtains the necessary security parameters to support group member and relay discovery, in coverage and out of coverage, e.g., for public safety scenarios. In Tdoc S3-212464 the following is described: “group member discovery is a type of restricted discovery and is expected to be supported in coverage and out of coverage. Group member discovery uses provisioned keys to support integrity, confidentiality and non-trackability of the discovery messages. A discovery root key from which other keys can be derived is used to secure over the air discovery and communications. This root key can be provisioned by the 5G DDNMF and/or by the 5G PKMF”. Tdoc S3-212464 further proposes a solution based on TS 33.303 [2] as follows: “for both public safety discovery scenarios—group member discovery and relay discovery—the same solution is provided: a Public Safety Discovery Key (PSDK) is provisioned as the root key that is used for the protection of the Public Safety Discovery messages, and is associated with one or more Discovery Group IDs or respectively Relay Service Codes (RSCs). Both of these identifiers are defined in TS 23.303 [5].” The steps for group member discovery include: “Step 0: The UE connects to the network and obtains authorization from the PCF to perform Group Member discovery. The UE also gets the address of the 5GDDNMF of its HPLMN and/or of the 5G PKMF. Besides the security policy, the following additional parameters are sent to the UE: a set of one or more App-layer Group ID, (ProSe) Layer-2 Group ID, User Info, Discovery Group ID and their validity time(s). Step 1: The UE establishes a secure connection with the 5GDDNMF or the 5G PKMF of its HPLMN. The UE ID is authenticated and authorized by the 5GDDNMF or the 5G PKMF. Step 2: The UE sends a discovery key request to the 5GDDNMF or the 5G PKMF of its HPLMN. In the key request includes at least the following information: UE ID, set of one or more Discovery Group IDs and their validity times. Step 3: The 5GDDNMF or the 5G PKMF checks whether the UE is authorized for group member discovery. Step 4: If the check in step 3 is successful, then the 5GDDNMF or the 5G PKMF generates a Public Safety Discovery Key (PSDK) corresponding to the Discovery Group ID and its PLMN ID. More than one PSDK may be generated, but the overall validity time should match the validity times of the corresponding set of Discovery Group IDs of Step 2. Step 5: The 5GDDNMF or the 5G PKMF sends the key response to the UE. The key response message includes at least the following information: UE ID, PDSK identifier, PDSK, validity time. For Relay discovery, the procedures/steps for the relay discovery are identical to the ones for group discovery described above, with the following exceptions: (i) the UE is now the Remote UE or the UE-to-network Relay; (ii) Instead of parameter Discovery Group ID, the Relay Service Code is used; (iii) Instead of Layer-2 Group ID, the Destination Layer-2 ID is used; and (iv) App-layer Group ID is not used.” The proposed solution Tdoc S3-212464 fails to identify the need of having different keys for the Query Code Security parameters and Response Code Security parameters used during the discovery phase as described in previous embodiments. If a single PSDK is provisioned as the root key that is used for the protection of the Public Safety Discovery messages—as proposed in Tdoc S3-212464—, then even if a key derivation function is applied so that the Query Code Security parameters and Response Code Security parameters have different DUIKs, the involved devices will be able to generate all those keys, and thus, the Discoverer UE might be able to impersonate the Discoveree UE, as described above. To address this security issue, the keying procedures for discovery must distribute different master keys, i.e., different PSDKs, to be used for the derivation of Query Code Security parameters and Response Code Security parameters. For instance, the two different master keys might be PSDK_QCSP and PSDK_RCSP: PSDK_QCSP is used to generate the Query Code Security Parameters (including a DUIK and/or a DUSK and/or a DUCK) and PSDK_RCSP is used to generate the Response Code Security parameters (including a DUIK and/or a DUSK and/or a DUCK). In this way, the impersonation attack is not feasible. PSDK_QCSP and PSDK_RCSP might be generated independently and at random or they might be generated from a master key K by applying a key derivation function. In this last case, K must not be disclosed to the UEs, in particular, remote UE and relay UE since otherwise, the impersonation attack is feasible. The generation or retrieval of these keys can be done at Step 4 above when the corresponding network function in the core network, e.g., the DDNMF or PKMF, has authorized the UE and has identified its role, e.g., whether the UE is a remote UE or a relay UE or both. The distribution of these keys is done in Step 5 above.
In TR 33.847 v0.7.0 (08/2021), Solution #37 is included after SA3 #104e building on a revisited version of Tdoc S3-212464. Solution #37 indicates that the keying procedures for discovery must distribute different master keys. This updated protocol improves somewhat the protocol to avoid the above-described attack since a UE can now receive a number of PDSKs, e.g., two PDSKs, a PDSK for the Query Code Security Parameters and a PDSK for the Response Code Security Parameters. This improves the situation compared with TS 33.303, Section 6.6.7 where the protection of the discovery messages between the UEs is described including the fact that a (single) PDSK is distributed to a UE allowing to generate the discovery keys (DUSK, DUCK, DUIK) from the PDSK by means of Key Derivation Function (KDF). However, the description in TR 33.847 v0.7.0 (08/2021), Solution #37 is still not sufficient. The reason is that a Discoverer UE using match reports must not receive the DUIK used to verify the MIC or any other key that can be used to derive the DUIK. If the PDSK—used to derive the DUIK—is distributed to the UE since it allows generating the DUSK and DUCK, the problem is not solved because the UE has the PDSK, and thus, it can generate the DUIK. Thus, an improved keying procedure applicable to TR 33.847 v0.7.0 (08/2021) consists in distributing to a UE, in particular, to the Discoverer UE:
In TR 33.847 v0.7.0 (08/2021), conclusions are reached after SA3 #104e regarding key issue (KI) #1 and #2. In KI #1, for the restricted ProSe direct discovery scenario, Solution #4 is used as a basis for normative work including the note that “The security keys in the Code-Sending Security Parameters of discover UE and the security keys in the Code-Sending Security Parameters of discoveree UE need to be generated independently and randomly. This ensures that the impersonation of the discoveree UE is not feasible when the discoverer UEs make use of match reports.” Stating that the keys are generated independently and randomly is aligned with above embodiments that require those keys to be different to avoid the impersonation attack. In KI #2, it is stated that: “The conclusion for direct discovery as follows: (1) The discovery keys include a cipher key, an integrity key and a scrambling key. (2) For open discovery, only integrity key will be assigned by the 5G DDNMF and will be used to provide integrity protection of the announce message. (3) For restricted discovery, 5G DDNMF will assign the discovery key(s) based on the requirement of the Prose Service.” The conclusions in KI #2 are insufficient to defeat the impersonation attack mentioned above and not aligned with Solution #4 since the conclusions in KI #2 limit the number of DUIKs to a single one. Thus, conclusions for KI #2 are to be updated stating that: “(1) The discovery keys include at least a cipher key, at least an integrity key and at least a scrambling key.”
Clause 6.3 in TS 33.503 describes the Security for 5G ProSe UE-to-Network Relay Communication. In Security for 5G ProSe Communication via 5G ProSe Layer-3 UE-to-Network Relay, control plane (Clause 6.3.3.3 in TS 33.503), it is stated that “PCF shall provision the authorization policy and parameters for 5G UE-to-Network Relay Discovery and Communication as specified in 5.1.4 in TS 23.304 [2].” In clause 5.1.4 in TS 23.304 it is stated: “Whether the security parameters can be provided by the PCF and details of security parameters will be determined by SA3 WG.” In the first two steps 0a and 0b in the message flow in
Two different entities cannot be in charge of managing the parameters and discovery keys that need to be distributed to both relay UE and remote UE for the discovery procedure to work. Thus, the current specification in TS 33.503 does not solve which entity manages the discovery parameters and keys and which entity authorizes the UEs to obtain the discovery parameters and keys. In particular, a single network function in a single network can be in charge of managing the discovery keys, this might be the PCF or PKMF or DDNMF or another NF in one of the networks.
In a first embodiment overcoming the above-mentioned problem, the remote UE (or relay UE) has registered with its network and seeks authorization for a given network relay service that is provided by a different network, e.g., the network of the relay UE (or remote UE). In this case, the network (e.g., through the AMF or PCF) of the remote UE (or relay UE) will inform the network of the relay UE (or remote UE), in particular, the PCF or a key management function responsible for the discovery keys (e.g., PKMF, DDNMF) of the relay UE (or remote UE), about (the identity of or the requested relay service by) the remote UE (or relay UE). When doing so, the network (e.g., PCF) of the relay UE (or remote UE) will provide the network (e.g., PCF) of the remote UE (or relay UE) with the corresponding discovery parameters and keys for the remote UE (or relay UE). Note that the remote UE's network and relay UE's network could work together to create discovery credentials or keys based on input (e.g. partial keys, UE identities, or network identities) from both networks. Once this is done, the remote UE (or relay UE) can be registered, authenticated and authorized by the network of the remote UE (or relay UE) as described in steps 0a and 0b in the message flow in
In a second embodiment overcoming above problem, the remote UE (or relay UE) has registered with its home network and seeks authorization for a given network relay service that is provided by a different network, e.g., the network of the relay UE (or remote UE). In this case, the network (e.g., through the AMF or PCF) of the remote UE (or relay UE) will inform the network of the relay UE (or remote UE), in particular, the PCF of the relay UE (or remote UE), about the (identity of the) remote UE (or relay UE) and need of a relay service. Furthermore, the network (e.g., through the AMF or PCF) of the remote UE (or relay UE) will inform the remote UE (or relay UE) about the network of the relay UE (or remote UE), in particular, about the AMF or PCF of the relay UE (or remote UE) and/or a key management function in charge of discovery keys, that it has to contact for registration, authentication and authorization in steps 0a and 0b in the message flow in
In a third embodiment that can be combined with the above ones, the network of the relay UE and the network of the remote UE interact to match or align the relay service codes. For instance, in the first embodiment above, when the network of the remote UE (or relay UE) informs the network of the relay UE (or remote UE), about the requested (offered) relay service by the remote UE (or relay UE), the network of the relay UE (or remote UE) might match/align the relay service code of the other network with a relay service code used in its network.
Clause 6.3 in TS 33.503 describes the Security for 5G ProSe UE-to-Network Relay Communication. In Security for 5G ProSe Communication via 5G ProSe Layer-3 UE-to-Network Relay, a user plane (UP) approach (Clause 6.3.3.2 in TS 33.503) and control plane (CP) (Clause 6.3.3.3 in TS 33.503) are described for 5G ProSe Layer-3 UE-to-Network Relay authorization and security establishment.
While the second phase relies on the same discovery protocols, the first and the third phases might involve different protocols or entities (network functions). This can lead to an interoperability issue, e.g., if a UE is configured with discovery parameters/keys based on the UP first phase but then the third phase is CP-based for PC5 authorization and security establishment. The reason for this interoperability issue can be due to the lack of initialization of certain network functions. For instance, interoperability issues between the first phase of the UP-based approach (CP-based approach) and the third phase of the CP-based approach (UP-based approach).
In
In
In
In
In the following, different embodiments are described. Next to KI #16 in TR 33.847, the first embodiment and its variants above also addresses/can be applied to other key issues related to UE-to-network relay including, at least:
The setup described in the first embodiment can be extended to address these key issues. It is possible to exchange a shared secret K′ to secure the PC5 communication link between remote UE and relay UE. One option is that the remote UE generates a shared secret K at random before step e.iv. In step e.iv, it sends K to the relay UE in a secure way by encrypting it. The signature that is included in step e.iv can also have (the encrypted) K as input so that the relay can check the integrity of K. The shared secret K′ is computed, e.g., by applying a KDF on the concatenation of K, N_remote, and N_relay in step e.vi. This is shown in
A suitable approach for key exchange is Elliptic Curve (EC) Diffie Hellman. A suitable approach for public key encryption is EC Integrated Encryption Scheme.
Note that the above paragraph describes a distributed alternative to solutions #1, #6, #10, and #15 in TR33.847 that address KI #9. In those solutions the core network is involved in the generation and distribution of a shared symmetric key between remote UE and relay UE. In particular, the remote UE sends a “Direct Communication Request” to the Relay UE that triggers a further request towards the CN to distribute/generate a shared secret that can be used to secure the PC5 between remote UE and relay UE.
The first embodiment and its variants above also addresses/can be applied to other key issues related to UE-to-UE relay. In UE-to-UE relay scenarios two remote UEs need to communicate to each other, directly, through a relay UE.
We note that in TR 23.752, solution #11 is chosen as baseline for model A discovery and solution #8 is chosen as baseline for model B discovery. In case of solution #11, the discovery information includes: (i) Type=Announcement, (ii) Discovery Type=UE-to-UE Relay Discovery, (iii) Announcer Info (i.e. an upper layer identifier for the UE-R user), (iv) ProSe UE ID of UE-R (i.e. Layer-2 identifier of UE-R), (v) a list of “Target User Info” parameters (or attributes) (including users of UE-1 and UE-2) that have been gathered during Group Member Discovery in step 2. “Target User Info” is an upper layer parameter identifying the target user. To support Layer-2 communication via the stateful UE-to-UE Relay, the “Target User Info” also includes the Layer-2 identifier of the target user's UE. In solution #8 the discovery information is done by sending a “broadcasted” direct communication request, so not a separate discovery message. This direct communication request can include source UE info, target UE info, Application ID, as well as Relay Service Code.
Related work and differences: It is to be noted that Solution #8 in TR 33.847 also uses public keys to address this same scenario. However, the current solution has a number of FFS that are addressed in this solution. Solution #16 also addresses KI #6, although it does not mention public key cryptography directly.
In the following, it is described how solution #8 can be improved by using public key cryptography. Some of these improvements can also be applied to Solution #16.
The first point still to be discussedis about how the public keys are bound to a specific UE. This means that this solution does not provide authentication means and it is prone to Man in the Middle attackers. This is solved in this solution since public keys assigned to the UEs are signed by the CN.
Solution #8 also describes the exchange of public keys in messages 2 and 4 and in step 6 it writes: “The extended link is secured end to end using source UE's and target UE's public key, while the routing information will be left in the clear.” From this description, it seems that it focuses on a Diffie-Hellman key exchange where the secret key equals pr_A*PU_B=pr_B*PU_A, where pr means private key and PU means public key. This solution does not cover therefore ECIES or key encapsulation mechanisms (KEMs), e.g., being standardized by NIST Post Quantum Cryptography (PQC). Examples of PQC KEMs include SABER, Round5, Kyber, or NTRU. The difference in this regard is that in message 2 the source UE sends its public key and upon reception the target UE generates a random key K at random that is encapsulated using the source UE's public key. Message 4 includes an ephemeral public key component from the target UE and the encapsulated key.
Another FFS in Solution #8 is about how to make sure that a DCA message can be trusted. This can be done if the public keys are signed by the CN, as done in the present solution in Steps 1.a and 1.b. As mentioned above, an IBE solution can be used as well.
Solution #8 configures the relay in Step 0 with relay policy/parameters and then in Step 3, if the policy matches and the relay is allowed to relay the message, it does so. This approach has some issues such as.
If this information is successfully verified by the Source UE, the source UE replies with e.iv,a s in the main solution. Note that since the source UE has the public key of the relay, these parameters can be encrypted to ensure privacy. Note that since the public key of the source UE is signed by the CN, the source UE can sign any communication parameters to avoid MitM/replay attacks. Some of those ProSe parameters (e.g. broadcast Layer-2 ID, ProSe Application ID, UE's Application Layer ID, target UE's Application Layer ID, relay applicable indication) might have also been signed directly by the CN and provided to the source UE in Step a0.
Steps in
During operation, two alternatives are considered:
The first embodiment and its variants above also addresses/can be applied to other key issues related to groupcast communication. In particular, this partially relates to KI #13 in TR 33.847 that is about security and privacy of groupcast communication and involves the protection of L2 IDs in terms of linkability, traceability and privacy and also about the integrity/confidentiality of the communication.
Next we present a solution to deal with these issues that builds on Alternative 2 presented above for key issue #7. After performing the steps described in Alternative 2, the relay can check if the UE can join (is authorized) the communication with other UEs that might already be part of a group of UEs. If the UEs are authorized to talk to each other, the relay informs each of the UEs in the group. In particular, assume that a new UE Z has joined. When the relay informs the remote UEs (A, B, . . . ,Y) about a new UE Z joining the group, the relay sends N−1 messages M, a message M to each of the UEs (A, B, . . . ,Y) that were already in the group. This message M is similar to e.iv in
In addition to the above, the relay can handle a master group key K that can be used for communications within the group. The relay generates this master group key K at random that can be distributed to the UEs protected in above messages M and M′. A new master group key can be generated every time a new device joins or leaves the group. A derived group key K′ can be derived as the key derivation function using as inputs K and the nonces of all devices in the group. For instance, a hash function can be applied to the concatenation of K and each of the nonces sorted in increasing value and a counter i. This counter i can be used to rotate K′ over time.
This key can also be used to derive a Destination L2-ID, e.g., by applying a key derivation function on K′ and taking the least significant bits.
Note that this approach for checking the mutual authorization and distribution of a group key means that the relay has to send a total of N−1 messages. This is an improvement compared with a solution in which each UE has to authenticate/authorized to each other that would require an overhead of N{circumflex over ( )}2 messages. Such a benefit is also mentioned in Solution 12, addressing KI #8: “UE1 may be communicating with more than one Target UE over the PC5 unicast link via the UE-to-UE Relay. In that case, all Target UEs must be informed of UE1's new IP address/prefix”.
This solution is shown in
Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated.
As explained throughout the previous embodiments, the proposed variants of the invention can be implemented in a network, for example a cellular network as a 5G network, shown on
A controller 1013, for example a CPU or microcontroller operating with a software is adapted to control the transmitter and the receiver and control the antennas. It is to be noted that some or all of the transmitter, the receiver and the controller may be part of a single baseband processor. In connection with the above described embodiments, the controller is adapted to establish a connection between the relay station 1010 and the primary station 1000. More specifically, the controller 1013 can configure the receiver 1012 for receiving in at least one first secure message from the primary station 1000 a first set of configuration parameters including attributes or service codes
The controller 1013 can control the transmitter 1011 and cause it to transmit at least one transmitted attribute or service code from the first set of configuration parameters. This attribute or service code can be broadcast for reception by other stations, for example like secondary station 1020.
Further, the controller 1013 may be then configured for establishing a direct communication with the secondary station 1020 using the public key upon request from the secondary station, said request being based on the transmitted service message.
Typically, the relay station may be a UE, like a Sidelink compatible UE, which thus can behave as a relay station when configured to. Alternatively, the relay station may also be a another primary station, like an Access Point, or a gNB or a femtocell gNB.
The secondary station 1020 may typically be a UE, and comprises a transmitter 1021, a receiver 1022, both typically coupled to one or more antennas or antenna array. Further, the secondary station 1020 includes a controller 1023 which is adapted to control the receiver 1021, the transmitter 1022 and possibly other elements of the UEs. As for the relay station, the controller 1023 may be a processor or a CPU, and may operate thanks to a software.
The controller 1023 is able to cause the receiver 1021 and the transmitter 1022 to establish a connection with the primary station 1000. This includes for example configuring the receiver 1021 for receiving from the primary station 1000 in at least one second secure message a second set of configuration parameters including attributes or relay service codes linked to an upcoming data exchange with the relay station 1010.
The receiver 1021 may be adapted for receiving at least one transmitted attribute or service code from the relay station 1010 and the controller may be configured for determining whether the transmitted attribute or service code is included in the second set of configuration parameters or fulfil a policy in it and causing the transmitter to establish a direct communication with the relay station 1010 upon determination that the transmitted service code is included in the second set.
The described operations like those indicated in
Number | Date | Country | Kind |
---|---|---|---|
21158459.4 | Feb 2021 | EP | regional |
21171104.9 | Apr 2021 | EP | regional |
21191991.5 | Aug 2021 | EP | regional |
21195383.1 | Sep 2021 | EP | regional |
22155346.4 | Feb 2022 | EP | regional |
22157641.6 | Feb 2022 | EP | regional |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2022/054294 | 2/22/2022 | WO |