Identifying a communication device in a serving network
By requiring a cryptographic commitment from communication devices to their identifiers, the serving network verifies the device's identity using a home network-provided key, addressing the challenge of verifying roaming devices and protecting against untrustworthy home networks.
Patent Information
- Application Number
- PCT/TR2025/050330
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-03-29
- Filing Date
- 2025-03-31
- Publication Date
- 2025-10-02
AI Technical Summary
Serving networks face challenges in verifying the identity of roaming communication devices while avoiding the burden of maintaining authentication credentials and protecting against untrustworthy home networks.
The serving network requires a communication device to cryptographically commit to its identifier, enabling verification of the device's association with the correct identifier through a commitment mechanism, using a cryptographic key provided by the home network to ensure the deconcealed identifier matches the concealed one.
This approach provides assurance to the serving network about the device's identity, protecting against malicious home networks and ensuring correct association without the need to maintain authentication credentials, while allowing reliance on the home network for authentication.
Smart Images

Figure TR2025050330_02102025_PF_FP_ABST
Abstract
Description
[0001] IDENTIFYING A COMMUNICATION DEVICE IN A SERVING NETWORK
[0002] TECHNICAL FIELD
[0003] The present application relates generally to a communication device and a serving network of the communication device, and relates more particularly to an identifier associated with the communication device for identifying the communication device in the serving network.
[0004] BACKGROUND
[0005] In the context of a communication network, mutual authentication is a security process to obtain cryptographic assertion that a communication device and the communication network are the entities they claim to be. The network cryptographically authenticates a communication device so the network can be certain that the services are being provided to a legitimate communication device, the communication device’s user cannot deny his or her bill, and one user cannot impersonate another user. Similarly, the communication device authenticates the network so that an unauthorized party cannot successfully engage with it.
[0006] In early generations of communication networks, a communication device would transmit an identifier associated with the communication device, such as an International Mobile Subscriber Identifier (IMSI), over the air interface to the communication network, as a way to identify itself as being a legitimate device. However, the transmission of such an identifier over the air interface in the clear risked jeopardizing user privacy, e.g., as the location of the user could be tracked by tracking use of that identifier. In later generations of communication networks, then, the communication device encrypts its identifier, at least in part, before transmitting it to the communication network. This conceals the communication device’s identifier for privacy protection. The non-concealed version of the identifier may be referred to as a Subscription Permanent Identifier (SUPI) whereas the concealed version of the identifier may be referred to as a Subscription Concealed Identifier (SUCI).
[0007] In a roaming situation where a communication device roams away from a home network to which the communication device holds a subscription, the serving network that serves the roaming communication device heretofore relies on the home network to perform authentication of the communication device on the serving network’s behalf. The communication device in this scenario transmits its concealed identifier to the serving network over the air interface, to avoid revealing the non-concealed identifier over the air interface. Rather than deconcealing the concealed identifier itself, though, the serving network heretofore relies on the home network to perform deconcealment as part of authenticating the communication device. The home network then provides the corresponding non-concealed identifier to the serving network. This avoids the impractical requirement for the serving network to have direct relations with each subscriber, instantiated via credentials for deconcealment that would have to be stored and tediously maintained. However, requiring the serving network to rely on the home network for identifier deconcealment and device authentication requires the serving network to trust the home network and renders the serving network susceptible to malfeasant, malicious, or otherwise untrustworthy home networks. These and other situations create risk that the serving network could end up associating a communication device with an identifier different than the one that was actually associated with the concealed identifier that the communication device presented to the serving network.
[0008] Challenges thereby exist for how to provide a serving network with assurance about the identifier associated with a communication device, while at the same time relieving the serving network from the burden of maintaining credentials for authentication.
[0009] SUMMARY
[0010] According to some embodiments herein, a serving network requires a communication device to cryptographically commit to being associated with a certain identifier, e.g., a certain Subscription Permanent Identifier (SUPI). The serving network exploits such commitment to ensure that the communication device is associated with that identifier. Some embodiments thereby advantageously still allow the serving network to rely on the home network to authenticate the communication device, so as to avoid the burden of maintaining authentication credentials for the device, while also providing the serving network with assurance about the identifier associated with he communication device. Some embodiments may also be applicable to guard the serving network against an untrustworthy home network.
[0011] In one or more embodiments, for example, when the communication device provides a concealed identifier (e.g., Subscription Concealed Identifier, SUCI) to the serving network, the serving network requires the communication device to also provide a commitment which cryptographically commits the communication device to a corresponding non-concealed identifier, e.g., a corresponding SUPI. The serving network may open and verify the device’s commitment in order to verify that the communication device is in fact associated with that non-concealed identifier. The opening and the verification may be one and the same step. In some embodiments, this may protect the serving network from the home network accidentally or maliciously misrepresenting the non-concealed identifier associated with the communication device.
[0012] More particularly, embodiments herein include a method performed by a serving network node in a serving network of a communication device. The method comprises obtaining a concealed identifier associated with the communication device. The method also comprises obtaining a commitment that cryptographically commits the communication device to being associated with an identifier. The method also comprises obtaining a cryptographic key from a home network of the communication device. The method also comprises deconcealing the concealed identifier using the cryptographic key in order to obtain a deconcealed identifier. The method also comprises performing, or requesting another network node in the serving network to perform, verification of the commitment using the cryptographic key, wherein verification of the commitment verifies whether or not the identifier to which the commitment cryptographically commits the communication device is the deconcealed identifier.
[0013] Other embodiments herein include a method performed by a communication device. The method comprises transmitting a commitment to a serving network of the communication device, based on an indication that the serving network requires the communication device to transmit the commitment. In some embodiments, the commitment includes a concealed identifier and a tag. In some embodiments, the concealed identifier cryptographically conceals, at least in part, an identifier associated with the communication device. In some embodiments, the tag cryptographically commits the communication device to being associated with the identifier.
[0014] Other embodiments herein include a method performed by a home network node in a home network of a communication device. The method comprises receiving, from a serving network of the communication device, a commitment that cryptographically commits the communication device to being associated with an identifier. The method also comprises generating a cryptographic key usable by the serving network to verify the commitment. The method also comprises transmitting the cryptographic key to the serving network.
[0015] Other embodiments herein include a serving network node in a serving network of a communication device. The serving network node is configured to obtain a concealed identifier associated with the communication device. The serving network node is also configured to obtain a commitment that cryptographically commits the communication device to being associated with an identifier. The serving network node is also configured to obtain a cryptographic key from a home network of the communication device. The serving network node is also configured to deconceal the concealed identifier using the cryptographic key in order to obtain a deconcealed identifier. The serving network node is also configured to perform, or requesting another network node in the serving network to perform, verification of the commitment using the cryptographic key, wherein verification of the commitment verifies whether or not the identifier to which the commitment cryptographically commits the communication device is the deconcealed identifier.
[0016] Other embodiments herein include a communication device configured to transmit a commitment to a serving network of the communication device, based on an indication that the serving network requires the communication device to transmit the commitment. In some embodiments, the commitment includes a concealed identifier and a tag. In some embodiments, the concealed identifier cryptographically conceals, at least in part, an identifier associated with the communication device. In some embodiments, the tag cryptographically commits the communication device to being associated with the identifier.
[0017] Other embodiments herein include a home network node in a home network of a communication device. The home network node is configured to receive, from a serving network of the communication device, a commitment that cryptographically commits the communication device to being associated with an identifier. The home network node is also configured to generate a cryptographic key usable by the serving network to verify the commitment. The home network node is also configured to transmit the cryptographic key to the serving network.
[0018] Embodiments herein also include corresponding computer programs, and carriers of those computer programs.
[0019] BRIEF DESCRIPTION OF THE DRAWINGS
[0020] Figure 1 is a block diagram of a serving network and a home network of a communication device according to some embodiments.
[0021] Figure 2 is a block diagram of commitment verification according to some embodiments.
[0022] Figure 3 is a call flow diagram of a procedure for a communication device to connect to, register with, and / or receive service from the serving network according to some embodiments.
[0023] Figure 4 is a call flow diagram of an authentication procedure for authenticating a communication device according to some embodiments.
[0024] Figure 5 is a table of a committing scheme according to some embodiments.
[0025] Figure 6 is a logic flow diagram of a key generation, ciphertext generation, and MAC- tag value generation according to some embodiments.
[0026] Figure 7 is a call flow diagram of processing performed by a serving network node, home network, and user equipment according to some embodiments.
[0027] Figures 8A-8B are a logic flow diagrams of a method performed by a serving network node according to other embodiments.
[0028] Figure 9A is a logic flow diagram of a method performed by a communication device according to some embodiments.
[0029] Figure 9B is a logic flow diagram of a method performed by a home network node according to some embodiments. Figure 10 is a block diagram of a communication device according to some embodiments.
[0030] Figure 11 is a block diagram of a network node according to some embodiments.
[0031] Figure 12 shows an example of a communication system in accordance with some embodiments.
[0032] Figure 13 is a block diagram of a UE in accordance with some embodiments.
[0033] Figure 14 is a block diagram of a network node in accordance with some embodiments.
[0034] Figure 15 is a block diagram of a virtualization environment in accordance with some embodiments.
[0035] DETAILED DESCRIPTION
[0036] Figure 1 shows a serving network 10S and a home network 10H of a communication device 12, e.g., in the form of a user equipment (UE). The communication device 12 holds a subscription to receive communication service from the home network 10H, but may be out of coverage of the home network 10H or otherwise unable to receive service from the home network 10H directly. As such, the communication device 12 is to be served by the serving network 10S, e.g., according to a roaming agreement between the home network 10H and the serving network 10S.
[0037] In this context, the communication device 12 must identify itself to the serving network 10S, e.g., as part of a procedure to connect to, register with, and / or receive service from the serving network 10S. The communication device 12 could do so by indicating to the serving network 10S an identifier 18 with which the communication device 12 is associated. Such an identifier 18 may for instance be a username. Or, as another example, the identifier 18 may be a Subscription Permanent Identifier (SUPI) which identifies a subscription to the home network 10H and indirectly identifies a subscriber associated with the communication device 12, e.g., where the subscriber owns the subscription to the home network 10H and may or may not be the current user of the communication device 12. Note here that the subscription or subscriber identified by a SUPI is associated with the communication device 12 at least in the sense that the SUPI and credentials for the subscription are embedded or inserted into the communication device 12, or are stored on a smart-card such as a Universal Subscriber Identifier Module (USIM) that is insertable into, embedded on, or otherwise associated with the communication device 12. The communication device 12 however avoids revealing the identifier 18 with which the communication device 12 is associated over the air interface.
[0038] Towards this end, the communication device 12 transmits a concealed identifier 18C to the serving network 10S, e.g., within a request 16 to initiate a procedure to connect to, register with, and / or establish a signaling connection with the serving network 10S. The concealed identifier 18C cryptographically conceals, at least in part, the identifier 18 associated with the communication device 12. Where the identifier 18 is a SUPI for example, the concealed identifier 18C may be (or be at least a part of) a concealed SUPI, e.g., contained in a Subscription Concealed Identifier (SUCI) as otherwise specified in 3GPP TS 33.501 v18.4.0. For instance, with the identifier 18 being a SUPI in International Mobile Subscriber Identifier (IMSI) format, the concealed identifier 18C may cryptographically conceal at least the Mobile Subscriber Identification Number (MSIN) associated with the communication device 12. Cryptographic concealment may be realized in some embodiments by encryption, e.g., the concealed identifier 18C may include an encrypted version of at least a part of the identifier 18 associated with the communication device 12.
[0039] The serving network 10S however is not itself equipped to de-conceal the concealed identifier 18C, at least not without assistance from the home network 10H. This advantageously avoids burdening the serving network 10S with the task of storing and maintaining credentials for such de-concealment. Instead, the serving network 10S relies on the home network 10H to assist with this. The serving network 10S accordingly relays the concealed identifier 18C to the home network 10H, e.g., in a request for the home network 10H to authenticate the communication device 12 on the basis of the concealed identifier 18C. According to some embodiments, a home network node 14H in the home network 10H returns a cryptographic key 22 that the home network 10H represents as being usable by the serving network 10S to deconceal the concealed identifier 10C, e.g., premised on the home network 10H having authenticated the communication device 12 on the basis of the concealed identifier 18C. This cryptographic key 22 may be the same one as, or otherwise correspond to, the key that the communication device 12 used to generate the concealed identifier 10C. The serving network 10S may then deconceal the concealed identifier 10C using the cryptographic key 22, in order to obtain a deconcealed identifier 18P.
[0040] Embodiments herein notably provide assurance to the serving network 10S that this deconcealed identifier 18P is actually the identifier 18 associated with the communication device 12. Some embodiments do so by enabling the serving network 10S to verify that the deconcealed identifier 18P is the same identifier that was concealed by the concealed identifier 18C provided by the communication device 12 to the serving network 10S. In doing so, some embodiments for example protect the serving network 10S against the home network 10H accidentally or maliciously sending the serving network 10S a cryptographic key 22 that, when used by the serving network 10S to deconceal the concealed identifier 18C, would reveal a deconcealed identifier 18P that is different than the identifier 18 with which the communication device 12 is actually associated. Some embodiments herein thereby enable the serving network 10S to rely on the home network 10H for authentication of the communication device 12, while at the same time protecting the serving network 10S against associating the communication device 12 with a deconcealed identifier 18P that is different than the identifier 18 actually associated with the communication device 12.
[0041] As shown in Figure 1 , the serving network 10S in some embodiments requires that the communication device 12 provide the serving network 10S with a commitment 16. The communication device 12 generates this commitment 16 (e.g., as a function of the cryptographic key 22) in a way that cryptographically commits the communication device 12 to being associated with the identifier 18. This committal is binding in the sense that the communication device 12 and / or the home network 10H cannot later on represent the communication device 12 as being associated with a different identifier. In some embodiments, the commitment 16 may cryptographically bind the concealed identifier 18C to the identifier 18 concealed by the concealed identifier 18C. This way, after the communication device 12 provides the serving network 10S with the concealed identifier 18C, the communication device 12 is committed to being associated with the identifier 18 concealed by that concealed identifier 18C.
[0042] The commitment 16 may thereby advantageously enable the serving network 10S to perform commitment verification 24, in order to verify whether or not the deconcealed identifier 18P is actually the identifier 18 associated with the communication device 12. That is, the commitment enables the serving network 10S to verify whether the deconcealed identifier 18P (deconcealed using the cryptographic key 22 provided by the home network 10H) is the same as the identifier 18 concealed by the concealed identifier 18C provided by the communication device 12, e.g., whether the commitment 16 binds the concealed identifier 18C to the deconcealed identifier 18P. Or, in still other words, the commitment 16 enables the serving network 10S to verify whether or not the identifier 18 to which the commitment 16 cryptographically commits the communication device 12 is the deconcealed identifier 18P deconcealed using the cryptographic key 22 provided by the home network 10H.
[0043] In some embodiments, for example, the concealed identifier 18C is included or encoded within the commitment 16 itself, along with a tag 16T. The tag 16T cryptographically commits the communication device 12 to being associated with the identifier 18. The tag 16T may for instance be a Message Authentication Code (MAC) tag that is computed as a function of the cryptographic key 22 and the identifier 18, e.g., as a function of the concealed identifier 18C that is in turn a function of the identifier 18. Regardless, inclusion of the concealed identifier 18C and the tag 16T in the commitment 16 means that the commitment 16 effectively binds the concealed identifier 18C to the identifier 18 that the concealed identifier 18C conceals.
[0044] Figure 2 shows one approach. In these embodiments, the commitment 16 includes the concealed identifier 18C, e.g., such that obtaining the concealed identifier 18C is performed by or as part of obtaining the commitment 16. The serving network 10S in this case first performs ‘opening’ of the commitment 16, i.e., commitment opening 24A. For convenience, commitment opening 24A may be represented as performing the function Open (K, comm), where comm is the commitment and K is the cryptographic key 22. Commitment opening 24A may involve de-concealing the concealed identifier 16C using the cryptographic key 22, e.g., deconcealing may be performed as part of commitment opening 24A. Where the concealed identifier 18C is encrypted, for example, de-concealing he concealed identifier 18C may involve decrypting the concealed identifier 18C using the cryptographic key 22. Such decryption may be performed directly with the cryptographic key 22 or be performed only indirectly using some keying material securely derived therefrom, e.g., using a deterministic key derivation function (KDF) or a pseudo random function (PRF). Decryption may for instance be performed according to a function Dec(K', c), where Dec is a decryption function, c is the concealed identifier 18C, and K' is a decryption key derived from the cryptographic key 22. With deconcealment conditioned on obtaining the cryptographic key 22 (and perhaps the decryption key derived therefrom), the commitment 16 may advantageously hide the identifier 18 to which the communication device 12 has committed, e.g., so as to be a hiding commitment. Either way, commitment opening 24A produces the deconcealed identifier 18P, e.g., Open(K, comm) = ID', where ID' is the deoncealed identifier 18P.
[0045] Having opened the commitment 16 to reveal the deconcealed identifier 18P, the serving network 10S in Figure 2 performs commitment verification 24. Commitment verification 24 verifies the commitment 16. Commitment verification 24 may involve invoking the function C heck (K, ID', comm), which may in turn invoke the function Verif(K", ID', tag), where ID' is the deoncealed identifier 18P and K" is a derived key derived from the cryptographic key 22. In any event, this verification involves tag recreation 24B. Tag recreation 24B generates a recreated tag 16C as a function of the cryptographic key 22 and the deconcealed identifier 18P. Tag recreation 24B may generate the recreated tag 16C also as a function of the commitment 16 itself. In some embodiments, for example, the tag 16C is generated is a verifiable one-way function of at least a portion of the deconcealed identifier 18P, e.g., where the one-way function may be a hash function, a keyed hash function, a message authentication code (MAC) function, a pseudo-random function, a keyed encryption function, or a key derivation function (KDF). In one specific case, this verifiable one-way function may be a keyed hash, where the cryptographic key 22 or a key derived therefrom is the key of the keyed hash.
[0046] Regardless, commitment verification 24 further involves performing a comparison 24C in order to compare the recreated tag 16C to the tag 16T included in the commitment 16. A verification decision 24D is performed based on the result 24R of this comparison 24C. In some embodiments, the decision 24D involves determining whether or not the tag 16T included in the commitment 16 matches or otherwise corresponds to the recreated tag 16C. The tag 16T included in the commitment 16 matches the recreated tag 16C if the identifier 18 to which the commitment 16 cryptographically committed the communication device 12 is the deconcealed identifier 18P. The result 24R of this comparison forms the basis of the verification decision 24D regarding whether or not the commitment 16 is verified. Commitment verification 24 may then provide the result of the verification decision 24D as the verification result 24V.
[0047] In these and other embodiments, the commitment 16 may be constructed using a committing encryption algorithm such as a committing authenticated encryption algorithm. For example, the concealed identifier 18C may be a ciphertext of the committing authenticated encryption algorithm and the commitment 16 may be constructed as the authentication tag of such an algorithm. In these and other embodiments, the cryptographic key 22 may be the commitment key for the committing encryption algorithm as derived from a key encapsulation mechanism (KEM) or an Elliptic Curve Integrated Encryption Scheme (ECIES). The algorithm may be symmetric or asymmetric in nature.
[0048] Note that commitment verification 24 in Figure 2 may be performed by a single node in the serving network 10S, e.g., serving network node 14S. Or, in other embodiments, commitment verification 24 may be performed collaboratively or collectively across multiple nodes in the serving network 10S. In some embodiments, for example, the serving network node 14S in Figure 1 performs, or requests another network node in the serving network 10S to perform, commitment verification 24.
[0049] No matter the particular manner of commitment verification 24, the serving network 10S is some embodiments conditions its provision of service to the communication device 12 on successful verification of the commitment 16. In these embodiments, for example, the serving network 10S may make a decision of whether or not to provide service to the communication device 12 based on whether or not the verification 24 of the commitment 16 is successful, and then provide or reject service to the communication device 12 according to the decision. Such decision may be made by the serving network node 14S itself, or may be made by another network node in the serving network 10S which receives the result of the verification 24 from the serving network node 14S. In these and other embodiments, then, where the communication device 12 transmits a request 15 to initiate a procedure to connect to, register with, and / or establish a signaling connection with the serving network 10S, the serving network 10S may accept or reject the request 15 depending respectively on whether the verification 24 of the commitment 16 succeeds or fails. In fact, the serving network 10S may reject the request 15 if the verification 24 fails, even if the home network 10H indicates that the communication device 12 was successfully authenticated. These embodiments generally reflect the notion that the serving network 10S must be able to associate the communication device 12 with an identifier in order to provide service to the communication device 12. Successful verification of the commitment 16 provides the serving network 10S with the confidence it needs to associate the communication device 12 with the identifier 18.
[0050] In some embodiments, though, the serving network 10S may further bolster its confidence by receiving a home network provided identifier 18H from the home network 10H. The home network provided identifier 18H may be the de-concealed identifier as represented by the home network 10H as having been deconcealed from the commitment 16. In this case, verification 24 of the commitment 16 may further comprise verifying whether the deconcelaed identifier 18P is the same as the home network provided identifier 18H.
[0051] Especially in these embodiments where the serving network 10S conditions its provision of service to the communication device 12 on successful verification of the commitment 16, the serving network 10S may require the communication device 12 to provide the serving network 10S with such a commitment 16. The serving network 10S may for example transmit, to the communication device 12, an indication that the commitment 16 is required as a condition for the serving network 10S to provide service to and / or establish a signaling connection with the communication device 12. This indication may be broadcast, e.g., in System Information (SI), or may be transmitted via dedicated signaling to the communication device, e.g., in a response to any request 15 that lacks the required commitment 16.
[0052] In some embodiments, then, the serving network 10S (via the same or a different serving network node) may determine whether or not the commitment 16 has been provided, e.g., for the concealed identifier 18C. If no commitment 18 has been provided, the serving network 10S may send an indication to the communication device 12 that the commitment 18 is required, e.g., in order for the serving network 10S to provide service to and / or establish a signaling connection with the communication device 12. In some embodiments, the serving network 10S receives the commitment 18 after or responsive to such indication. Indeed, in some embodiments, the communication device 12 determines, based on the indication, whether or not the communication device 12 needs to send the commitment 18 to the serving network 10S, and sends the commitment 18 based on determining that the communication device 12 needs to send the commitment 18 to the serving network 10S.
[0053] In support of these embodiments, the communication device 12 may provide an indication to the serving network 10S that the communication device 12 has provided the commitment 16. For example, in some embodiments where the concealed identifier 18C is contained in a SUCI, the SUCI includes an indication that the SUCI is a committing SUCI which includes (or accompanies) the commitment 16. The commitment 16 in these and other embodiments may be a part of the SUCI or may be separate from the SUCI.
[0054] Note that Figure 1 showed the serving network node 14S as receiving the concealed identifier 18C and the commitment 16 from the communication device 12 and as receiving the cryptographic key 22 from the home network 10H directly. However, this need not be the case. In fact, the serving network node 14S may receive the concealed identifier 18C and / or the commitment 16 from the communication device 12 or another network node in the serving network 10S. Similarly, the serving network node 14S may receive the home cryptographic key 22 from the home network 10H or from another network node in the serving network 10S.
[0055] Note, too, that the serving network node 14S in some embodiments may be dedicated to commitment verification 24, or may implement a network function (NF) or NF service dedicate for commitment verification 24. For example, the serving network node 14S may receive a request to perform commitment verification 24 from another network node, and may respond with the result of the commitment verification 24. In this case, the commitment 16 may be included in the request, e.g., possibly also with the concealed identifier 18C.
[0056] Consider now some example implementations in a context where the serving network 10S and the home network 10H are each a 5G network, the communication device 12 is a user equipment (UE), the serving network node 14S implements a Security Anchor Function (SEAF), the home network node 14H implements an Authentication Server Function (AUSF), the identifier 18 is a SUPI, the concealed identifier 18C is a concealed SUPI contained in a SUCI, and commitment verification 24 is performed as part of or during an authentication procedure (e.g., an Authentication and Key Agreement, AKA, procedure such as a 5G-AKA procedure). Exemplified elements are referenced with the corresponding reference number, e.g., the SUPI will be referred to as SUPI 18 as an example of the identifier 18.
[0057] In such an implementation, some embodiments enable the SEAF to verify that the SUPI that it deconceals corresponds to the concealed SUPI contained in the SUCI received from the UE. This guards against an attack where the subscriber and home network 10H collude to cheat the serving network 10S on the subscriber identifier, e.g., as may happen in the context of a malicious state actor. This proves impactful especially for safeguarding Lawful Intercept (LI) functionality. Furthermore, this preserves the ability of the serving network to provide personalized services, and to perform some performance optimizations. Notably, some embodiments also enable the serving network 10S to better protect itself and understand who is using the services it provides.
[0058] Some embodiments provide these advantages even without requiring the serving network 10S to authenticate the UE explicitly. This is advantageous because it avoids the serving network 10S having to have a direct relation, instantiated via credentials, with each UE. Instead, the serving network 10S may continue to rely on the home network 10H to perform authentication on its behalf, but without having to blindly trust that the home network 10H will provide keying material for deconcealing the SUPI that actually corresponds to the UE-provided SUCI.
[0059] Generally, some embodiments enable the serving network 10S to verify that the deconcealed SUPI corresponds to the SUCI (comprising the encrypted SUPI) received from the UE 12. This is achieved by requiring the subscriber to commit to its identity in the initialization. The commitment 16 can at the end of the protocol be opened by the serving network 10S to verify that the received subscriber identity corresponds to the one initially committed to.
[0060] Some embodiments thereby provide a commitment mechanism of the subscriber identity to the serving network 10S. This may include using a committing authenticated encryption scheme and a verification step in a network authentication procedure, e.g., based on the AKA-protocol. In one such embodiment, the UE includes a commitment of the SUPI to the serving network 10S in initialization of authentication. Then, at the end of a successful challenge response protocol, the home network 10H sends the cryptographic key 22 to the serving network 10S. The serving network verifies that the SUPI it decrypts using the cryptographic key 22 received from the home network corresponds to the commitment 16 of the SUPI from the UE.
[0061] Certain embodiments may provide one or more of the following technical advantage(s). Some embodiments mitigate a SUPI forgery attack on the serving network 10S where the UE and the home network collude, as described above. The effect of such an attack can be devastating and can, e.g., prevent lawful intercept functions. Some embodiments may require only minor changes to the 5G-AKA protocol, in particular the protocol flow is not affected. Moreover, some embodiments that use symmetric cryptography only add simple symmetric key operations, meaning it is very efficient and has an advantage in post-quantum settings.
[0062] More particularly, consider a realization of some embodiments for the 5G-AKA protocol, though embodiments herein are not limited to this protocol.
[0063] Figure 3 shows a procedure for the UE to connect to, register with, and / or establish a signaling connection with the serving network 10S. This procedure is the initialization of the authentication procedure with identity commitment. As part of this procedure, the UE 12 includes a commitment 16 of the SUPI 18 to the serving network 10S in initialization of authentication. In Figure 3, the commitment 16 is shown as the commit element in the first message. In other embodiments not shown, though, the commitment 16 may be (or be included as a part of) the SUCI, so that it is not conveyed in a separate information element (IE) of the message. That is, even though the commit and the SUCI are written as two separate information elements, they could be instantiated by one and the same information element, e.g., the output from a committing authenticated encryption algorithm can act as both a commitment and a concealed subscription identifier. Either way, the SEAF 14S in Figure 3 keeps or stores the commitment 16 (commit), at least temporarily, for use as described below. The SEAF 14S meanwhile initializes the authentication procedure by sending an Authenticate Request to the AUSF 14H in the home network 10H. The AUSF 14H in turn transmits an Authentication Get Request to the UDM / ARPF / SIDF, where UDM stands for Unified Data Management, ARPF stands for Authentication Repository and Processing Function, and SIDF stands for Subscription Identifier De-concealing Function. The UDM / ARPF / SIDF deconceals the SUCI to obtain the SUPI and selects the authentication method for authenticating the UE 12.
[0064] Figure 4 shows the rest of the authentication procedure that the serving network 10S initializes based on the procedure in Figure 3. The UDM / ARPF generates an authentication vector (AV) according to a challenge response protocol (Step 1) and transmits an Authentication Get Response as a response to the Authentication Get Request in Figure 3 (Step 2). The Authentication Get Response includes the AV, possibly also the SUPI, and notably also includes a key Kcommit which exemplifies the cryptographic key 22. The AUSF 14H stores the expected response XRES* from the AV (Step 3), calculates HXRES* (Step 4), and transmits an Authenticate Response as a response to the Authenticate Request in Figure 3. The Authenticate Response includes the AV. The SEAF 14S in turn sends an Authentication Request to the UE 12 (Step 6). The UE 12 calculates an authentication response (RES*) (Step 7) and transmits RES* in an Authentication Response message (Step 8). The SEAF 14S calculates HRES* and compares it to HXRES* (Step 9). The SEAF 14S then transmits an Authenticate Request message with RES* to the AUSF 14H (Step 10). The AUSF 14H verifies the RES* (Step 11). The AUSF 14H transmits an Authenticate Response to the SEAF 14S along with a result of the verification, optionally the SUPI 18, and the cryptographic key Kcommit. Accordingly, then, at the end of a successful challenge response protocol, the home network 10H sends the cryptographic key 22 to the SEAF 14S. This is illustrated in Figure 4 by including Kcommit in message 2 and 12.
[0065] Note, though, that in other embodiments the serving network 10S requests a Kcommit from the home network 10H, and the home network 10H provides such to the serving network 10S if it has one. The serving network 10S may choose not to accept the UE 12 if no Kcommit is obtained from home network 10H (depending on serving network policy).
[0066] In any event, the SEAF 14S in the serving network 10S then decrypts the SUPI 18 using the cryptographic key 22, and verifies that the deconcealed SUPI 18P corresponds to the commitment 16 of the SUPI 18 from the UE 12. This is performed in Step 13 in Figure 4. The signaling structure presented should be viewed as an example of an instantiation of some embodiments. It should be noted that the commit element that the UE 12 sends to the SEAF 14S may be sent in another message. The receiving entity in the serving network 10S may be another function than the SEAF. The verification step (13) may be performed by another node or function in the serving network 10S, in which case that entity may obtain the commit element from the UE 12, or from the SEAF or another function in the serving network 10S. Alternatively or additionally, the Kcommit element may be generated by another function than the UDM / ARPF.
[0067] One realization of some embodiments is to use a committing authenticated encryption scheme. There are many schemes for committing authenticated encryption (See, Bellare, et al., “The Landscape of Committing Authenticated Encryption”). In order to minimize changes to the 3GPP 5G-AKA protocol, some embodiments propose one option to use a committing encryption scheme (which may be authenticated encryption), e.g., as the one presented in Grubbs et al., “Message Franking via Committing Authenticated Encryption”. This scheme includes an encryption function, a decryption function and a verification function. The scheme makes use of a single key for protection. In a concrete example, where the encryption function is an authenticated encryption function, the scheme derives an authentication key from the single key and also an encryption key using a Key Derivation Function (KDF). These keys are then used for message encryption, authentication and verification of that the ciphertext indeed corresponds to the plaintext.
[0068] By instantiating the scheme as follows, message authentication by HMAC-SHA256, encryption by AES 128 and KDF by ANSI-X9.63-KDF, some embodiments provide a committing authenticated encryption scheme with desired security properties making use of the basic cryptographic primitives specified in the 5G-AKA technical specification (See, 3GPP TS 33.501 V18.4.0). Whatever scheme is chosen, it can be used for encrypting / decrypting the SUPI / SUCI. The commitment commit and cryptogrpahic key Kcommit that is added to the protocol in Figures 3-4 are then given by the authentication tag and the key material to the KDF for the committing encryption scheme. The added verification step 13 uses the verification function in the scheme.
[0069] Another option is to keep the SUPI / SUCI as is and include a separate element in a message that contains the commit. The commit may be represented as an authentication tag (as output from a message authentication algorithm).
[0070] The SUPI / SUCI may contain an indication of whether it is a committing SUPI / SUCI. That indication may indicate to the serving network 10S whether to accept running authentication with the UE 12 or whether to reject the connection earlier than that. The serving network 10S may indicate to the UE 12 that using a committing SUPI / SUCI is required to connect to the serving network 10S. The serving network 10S may indicate to the UE 12 that a commitment to the identity 18 is required in addition to sending the SUCI in order to connect to the serving network 10S. The indication may also be carried in a separate information element (IE) in the same message as the SUCI or in a separate message that can be connected to the SUCI, e.g., because it is part of the same NAS procedure.
[0071] The key, i.e., Kcommit, for commit may be established using ECIES (See, 3GPP TS 33.501 V18.4.0). It may be established using a Key Encapsulation Mechanism (KEM), e.g., the NIST post quantum resistant KEMs (See, NIST “Post-Quantum Cryptography”).
[0072] More particularly, the UE 12 create a commitment (commit) to its identity 18 and cryptographic key Kcommit 22 using some commitment scheme. In the context of 5G-AKA, the commitment 16 is created as the (MAC) tag of the encrypted identity and the cryptographic key 22 is the key material used to derive the encryption key and MAC key in the authenticated encryption.
[0073] With reference to the table in Figure 5, K is the key material used to derive encryption key and MAC key using Key Derivation Function. At encryption the ciphertext C and tag T is created by the UE 12 as the commitment 16 to the identity M. This commitment 16 is sent to the serving network 10S. Later in the protocol, the serving network 10S receives the key K from the home network 10H, derives Ke, and decrypts the ciphertext C using the derived key according to decKeCl) in order to obtain the deconcealed SUPI as M. Next, the serving network will now verify that M is the committed identity 18. The serving network 10S derives the encryption key and MAC key, and recreates the tag T to see that it matches T received from UE 12 earlier. If it matches, the serving network 10S can be sure that the deconcealed identity M is the same as the UE 12 sent encrypted in C at the start of the protocol.
[0074] A different realization could be that the UE 12 creates a commitment (commit) to its identifier (SUPI) using a commitment scheme and adds the opening key / randomness (Kcommit) to the information that gets encrypted to SUCI. The UE 12 sends commit and SUCI to serving network 10S. The serving network 10S sends SUCI to home network who can decrypt the SUCI and after a successful authentication process sends Kcommit 22 to the serving network 10S. The serving network 10S can open commit using Kcommit and verify that it corresponds to what the SUCI conceals.
[0075] In still other alternative embodiments, a client identifies itself by encrypting its longterm identifier (which is not mobile network SUPI, but may for example be a login-user name in a fixed cable network that is connected to some controlling home-network). In these and other embodiments, the encryption may be an RSA encryption of the username. The client sends the encrypted user name and a commitment to the username to the serving cable network. The commitment can be a hash of the username, e.g., SHA-3 or SHA-2 or some other cryptographic hash function. The opening key would then correspond to the username. The serving cable network receives the user name, hashes it with the hash function and sees whether it matches the hash the client sent earlier.
[0076] Consider now some additional context for further implementation examples.
[0077] Some embodiments herein are based on a symmetric encryption scheme. A symmetric encryption scheme is a pair of algorithms Enc(k, m) and Dec(k, c), where k is a key, m is a message and c is a ciphertext. Enc(k, m) encrypts message m with key k and produces a ciphertext c. Dec(k, c), decrypts the ciphertext c with the key k and returns the decrypted message. For correct encryption schemes, encrypting m with k and then decrypting the returned ciphertext c with k returns m again.
[0078] An authenticated encryption scheme is a pair of algorithms AEEnc(k, m) and AEDec(k, c), where k, m and c are as for encryption schemes. Authenticated encryption schemes behave as encryption schemes, with the additional requirement that if the ciphertext c was not properly generated by AEEnc(k, m), e.g., c has been manipulated by an attacker, then AEDec(k, c) will detect this and return a special error symbol, which should be interpreted as that AEDec rejected the ciphertext c.
[0079] A special class of authenticated encryption schemes are committing authenticated encryption schemes. Intuitively, they are authenticated encryption schemes that ensures that if c was produced by AEEnc(k, m), then AEDec(k’, c) will return the special error symbol unless k = k’. There are many variations of this concept, but this is the main property, on top of what authenticated encryption schemes provide, that is relevant herein.
[0080] An asymmetric encryption scheme is a pair of algorithms AEnc(pubk, m) and ADec(privk, c), where pubk is a public key, m is a message, privk is a private key and c is a ciphertext. AEnc(pubk, m) encrypts message m with public key pubk and produces a ciphertext c. ADec(privk, c), decrypts the ciphertext c with the private key privk and returns the decrypted message. For correct asymmetric encryption schemes, encrypting m with pubk and then decrypting the returned ciphertext c with privk returns m again. Note that AEnc / ADec is different from AEEnc / AEDec despite the similar names.
[0081] A message authentication code (MAC) is a pair of algorithms Tag(k, m) and Verif(k, m, tag), where k is a key, m is a message, and tag is a secure fingerprint of the message. Tag(k, m) creates the secure tag of message m, and Verif(k, m, tag) returns true if the tag was securely generated by Tag(k, m). The canonical way to realize Verif when Tag is a deterministic algorithm, is to invoke Tag on inputs k and m, and then comparing the result to tag. Invoking Verif is colloquially referred to as verifying the tag. MACs that are such that an attacker cannot find k’ or m’ different from k or m such that Tag(k, m) = Tag(k’, m’), are called committing MACs below.
[0082] Key derivations separate keys from one another. Separation is necessary when keys are used for different purposes or by different parties. The intuition is that an operation using one key should not be endangered because an attacker knows another key. This should hold even if the two keys are derived from the same base key. A common example is to derive an encryption key and a MAC key from the same base key. If an attacker gets hold of the encryption key, the integrity protection provided by the MAC is then still maintained. Keys can be derived in many ways. Two common examples of deriving keys are by applying a key derivation function (KDF) or a pseudo random function (PRF) to the base key and some input that is unique (or highly likely to be unique) to each of the derived keys. Referring to the encryption and MAC example again, the encryption key could be derived from a base key k as PRF(k, 1) and the MAC key could be derived as PRF(k, 2).
[0083] Hybrid encryption schemes (sometimes also called KEM-DEMs for Key Encapsulation Mechanism / Data Encryption Mechanism) combine symmetric encryption with asymmetric encryption as follows. Say that A wants to send a secure message m to B, and A has access to B’s public key. A can then generate a random key k through some process that depends on B’s public key and that is reproducible by B, and then A can invoke AEnc(k, m) to obtain a cipher text to send to B. An example of such a k-generation process is the one used in ECIES, which is reused in 3GPP for SUCI generation (See 3GPP TS 33.501 V18.4.0). The generated random encryption key is represented by the box Eph enc key in the figure below. The ECIES scheme also generates an ephemeral MAC-key and computes a MAC over the encrypted data. The generated MAC key is represented by the box Eph mac key in the figure below.
[0084] Figure 6 shows a hybrid encryption scheme, encrypting the SUPI to get a SUCI (i.e., to get a concealed SUPI), according to some embodiments. See, e.g., 3GPP TS 33.501 .
[0085] A commitment scheme is a triple of algorithms Commit(k, m), Open(k, comm) and Check(k, m, comm), where k is a key, m is a message and comm is a commitment to m. Commit(k, m) generates a commitment comm using key k, Open(k, comm) returns m, and Check(k, m ,comm) checks whether Commit(k, m) = comm. In general, commitment schemes can use different algorithms, but this specific version is sufficient to explain some embodiments. Intuitively, Commit locks the choice of m so that whoever presented the commitment cannot later claim that it committed to a different m. As an allegory, one can imagine that m is locked in box that is given to another party. The other party may invoke Open, to retrieve the value inside the box, and Check to verify that m is indeed what was locked inside the box (committed to) previously.
[0086] A commitment scheme is correct if Commit(k, m) produces a commitment comm such that Open(k, comm) returns m and Check(k, m, comm) returns true. Commitment schemes create hiding and binding commitments. A hiding commitment is secure when the message being bound is prohibitively difficult to obtain from the commitment without access to the key k, c.f., encryption and decryption algorithms. A binding commitment is secure when the party committing to m cannot later claim that it committed to m’ without Check returning false.
[0087] Commitment schemes can be built from encryption schemes and committing MACs as follows.
[0088] Commit(k, m) invokes Enc(k’, m) and Tag(k”, m), where k’ and k” are securely derived from k, to generate a ciphertext c and a MAC-tag tag, and then constructs the commitment comm as the tuple (c, tag). The derivation of k’ and k” can for example be done using a deterministic key derivation function (KDF) or pseudo random function (PRF).
[0089] Open(k, comm) derives k’ the same way that Commit did and invokes Dec(k’, comm), returning its result.
[0090] Check(k, m, comm) derives k” the same way that Commit did and invokes Verif(k”, m, tag), returning its result.
[0091] This class of constructions will be called encrypt-MAC commitments below.
[0092] Commitment schemes can be built from committing authenticated encryption schemes as follows:
[0093] Commit(k, m) invokes AEEnc(k, m)
[0094] Open(k, comm) invokes AEDec(k, comm), returning its result.
[0095] Check(k, m, comm) invokes AEDec(k, m, comm) and returns true if the result is not the special error symbol, and false otherwise. If Open(k, comm) returns the special error symbol, then that symbol is input to Check as m, and Check will return false.
[0096] Commitment schemes can be constructed in many other ways as well.
[0097] In Figure 7, the SN is the Serving Network 10S and the HN is the Home Network 10H. The SN 10N includes the SEAF function as an example of serving network node 14S. The HN 10H includes the AUSF and UDM / ARPF functions. The user equipment (UE) exemplifies the communication device 12.
[0098] The UE generates a commitment key k, as an example of cryptographic key 22, by calling the Generate function with the public key of the HN 10H. In 5G this may for example correspond to all the steps generating the Eph shared key in Figure 6. The UE then encrypts its identifier 18 shown as UE ID, which could for example be the SUPI in 5G using the generated key k. The result is an encrypted UE ID, e.g., in the form of a concealed identifier 18C (SUCI). The UE also computes a MAC-tag over the encrypted UE ID, so as to obtain the tag 16T. The generation of k and the encryption of the UE ID can be viewed as a hybrid encryption scheme as outlined above. The UE then constructs a commitment 16 to the SUPI by encoding the encrypted SUPI and the MAC-tag into an element comm, exemplifying the commitment 16. The comm may for example be the SUCI in 5G. Comm may contain more information than only the encrypted SUPI and the MAC-tag. The UE sends comm to the serving network, which stores it. The SN 10S then forwards comm to the HN 10H. The HN 10H generates the commitment key k by calling the Generate function with its private key. The HN 10S may also optionally open comm and / or verify it, as an example of commitment verification 24. The HN 10H then sends the commitment key k (and optionally the opened commitment interpreted as a SUPI) to the SN 10S. The SN 10S can then use k to open and verify the stored comm.
[0099] In some embodiments where the HN 10H sends the opened commitment interpreted as a SUPI to the SN 10S, the SN 10S may optionally also verify that the SUPI it received from the HN 10H is the same as the one it obtained by opening comm (bold elements in Figure 7). Note here that the UE ID” will be valid if CheckO returns true. From that perspective, an SN may not need the optional elements in Figure 7, i.e., the verification that UE ID’ = UE ID " is strictly not necessary. However, one can expect that UE ID’ will be sent from HN 10H to the SN 10S also in 6G because it was sent in 5G, and standards may not want to rely solely on the CheckO procedure (belt and suspenders approach). When that is done, an HN implementation may intentionally or accidentally send an UE ID’ that differs from the (de)concealed UE ID”. The verification UE ID ” = UE ID ‘ then detects whether the HN 10H sent an invalid UE ID’ or not. One could argue that the SN 10S should not rely on UE ID’, but only on UE ID” in this situation. But implementations may, due to human mistake or some other reason, base processing decisions on UE ID’, and to prevent that any such flaws enter the system, performing the optional verification would be helpful.
[0100] Note further that Box (2) in Figure 7 represents still another alternative herein. In this case, the commitment verification 24 is performed using the home network provided identifier 18H (as de-concealed by the home network 10H), rather than the deconcealed identifier 18P that was deconcealed by the serving network 10S.
[0101] In view of the modifications and variations herein, Figures 8A-8B depict a method performed by a serving network node 14S in a serving network 10S of a communication device 12 in accordance with particular embodiments. The method includes obtaining a concealed identifier 18C associated with the communication device 12 (Block 800). The method also includes obtaining a commitment 16 that cryptographically commits the communication device 12 to being associated with an identifier 18 (Block 810). The method also includes obtaining a cryptographic key 22 from a home network 10H of the communication device 12 (Block 820). The method also includes deconcealing the concealed identifier 18C using the cryptographic key 22 in order to obtain a deconcealed identifier 18P (Block 830). The method also includes performing, or requesting another network node in the serving network 10S to perform, verification 24 of the commitment 16 using the cryptographic key 22, wherein verification 24 of the commitment 16 verifies whether or not the identifier 18 to which the commitment 16 cryptographically commits the communication device 12 is the deconcealed identifier 18P (Block 840).
[0102] In some embodiments, the commitment 16 includes the concealed identifier 18C and a tag that cryptographically commits the communication device 12 to being associated with the identifier 18. In some embodiments, obtaining the concealed identifier 18C comprises obtaining the commitment 16. In some embodiments, deconcealing the concealed identifier 18C comprises, or is performed as part of, opening the commitment 16 using the cryptographic key 22. In some embodiments, said verification 24 of the commitment 16 comprises generating a recreated tag as a function of the cryptographic key 22 and the deconcealed identifier 18P, comparing the recreated tag to the tag included in the commitment 16, and determining whether or not the tag included in the commitment 16 matches the recreated tag according to said comparing, wherein the tag included in the commitment 16 matches the recreated tag if the identifier 18 to which the commitment 16 cryptographically committed the communication device 12 is the deconcealed identifier 18P. In some embodiments, generating the recreated tag comprises deriving a derived cryptographic key from the cryptographic key 22, and computing the recreated tag as a function of the derived cryptographic key and the deconcealed identifier 18P. In some embodiments, the tag is a Message Authentication Code, MAC, tag that is a function of the cryptographic key 22 and the identifier 18.
[0103] In some embodiments, verification 24 of the commitment 16 verifies whether or not the commitment 16 binds the concealed identifier 18C to the deconcealed identifier 18P.
[0104] In some embodiments, the concealed identifier 18C is an encrypted identifier. In some embodiments, deconcealing the concealed identifier 18C comprises deriving a decryption key from the cryptographic key 22, and decrypting the encrypted identifier using the derived decryption key.
[0105] In some embodiments, the commitment 16 is constructed using a committing authenticated encryption algorithm. In some embodiments, the commitment 16 includes an authentication tag of the committing authenticated encryption algorithm. In some embodiments, the authentication tag cryptographically commits the communication device 12 to being associated with the identifier 18. In some embodiments, the cryptographic key 22 is a commitment key of the committing authenticated encryption algorithm, and the concealed identifier 18C is a ciphertext of the committing authenticated encryption algorithm.
[0106] In some embodiments, the commitment 16 is received from the communication device 12 in, during, or as part of a procedure to establish a signaling connection between the communication device 12 and the serving network 10S. In some embodiments, the commitment 16 is received from the communication device 12 in a request 15 to initiate the procedure to establish the signaling connection. In some embodiments, the method further comprises rejecting the request 15 to initiate the procedure if the verification 24 of the commitment 16 fails. In other embodiments, the method further comprises accepting the request 15 to initiate the procedure if the verification 24 of the commitment 16 succeeds.
[0107] In some embodiments, the method further comprises, after or responsive to receiving the commitment 16 from the communication device 12, initiating an authentication procedure in which the communication device 12, the serving network 10S, and the home network 10H participates, wherein the cryptographic key 22 is received from the home network 10H in, during, in connection to, or as part of the authentication procedure (Block 850).
[0108] In some embodiments, the method further comprises, based on successful verification 24 of the commitment 16, associating the identifier 18 with the communication device 12 (Block 860).
[0109] In some embodiments, the method further comprises making a decision of whether or not to provide service to the communication device 12 based on whether or not the verification 24 of the commitment 16 is successful (Block 870), and providing or rejecting service to the communication device 12 according to the decision (Block 880).
[0110] In some embodiments, the concealed identifier 18C is at least a part of a Subscription Concealed Identifier, SUCI. In some embodiments, the SUCI includes an indication that the SUCI is a committing SUCI which includes, or accompanies, the commitment 16, and the identifier 18 is a Subscription Permanent Identifier, SUPI.
[0111] In some embodiments, the method further comprises transmitting, to the communication device 12, signaling indicating that a commitment 16 to an identifier 18 associated with the communication device 12 is required as a condition for the serving network 10S to provide service to and / or establish a signaling connection with the communication device 12 (Block 890).
[0112] In some embodiments, the method further comprises receiving a home network provided identifier 18H from the home network 10H, and verification 24 of the commitment 16 further comprises verifying whether the deconcelaed identifier 18P is the same as the home network provided identifier 18H (Block 895).
[0113] Figure 9 depicts a method performed by a communication device 12 in accordance with other particular embodiments. The method includes transmitting a commitment 16 to a serving network 10S of the communication device 12, based on an indication that the serving network 10S requires the communication device 12 to transmit the commitment 16 (Block 900). In some embodiments, the commitment 16 includes a concealed identifier 18C and a tag. In some embodiments, the concealed identifier 18C cryptographically conceals, at least in part, an identifier 18 associated with the communication device 12. In some embodiments, the tag cryptographically commits the communication device 12 to being associated with the identifier 18.
[0114] In some embodiments, the method further comprises deriving a cryptographic key 22 from a public key of a home network 10H of the communication device 12 (Block 910), and generating the concealed identifier 18C and the tag using the cryptographic key 22 (Block 920). In some embodiments, said generating comprises generating the concealed identifier 18C by deriving an encryption key from the cryptographic key 22 and encrypting the identifier 18 using the encryption key, and generating the tag by deriving a derived cryptographic key from the cryptographic key 22 and generating the tag as a function of the derived cryptographic key and the concealed identifier 18C.
[0115] In some embodiments, the commitment 16 cryptographically binds the concealed identifier 18C to the identifier 18.
[0116] In some embodiments, the commitment 16 is constructed using a committing authenticated encryption algorithm. In some embodiments, the tag is an authentication tag of the committing authenticated encryption algorithm, and the concealed identifier 18C is a ciphertext of the committing authenticated encryption algorithm.
[0117] In some embodiments, the commitment 16 is transmitted in, during, or as part of a procedure to establish a signaling connection between the communication device 12 and the serving network 10S. In some embodiments, the method further comprises, in association with the procedure, participating in an authentication procedure in which the communication device 12, the serving network 10S, and a home network 10H of the communication device 12 participates. In some embodiments, the commitment 16 is transmitted in a request 15 to initiate the procedure to establish the signaling connection, wherein the request 15 is rejected if verification 24 of the commitment 16 fails.
[0118] In some embodiments, the concealed identifier 18C is at least a part of a Subscription Concealed Identifier, SUCI. In some embodiments, the SUCI includes an indication that the SUCI is a committing SUCI which includes, or accompanies, the commitment 16, and the identifier 18 is a Subscription Permanent Identifier, SUPI.
[0119] In some embodiments, the method further comprises receiving, from the serving network 10S, signaling that includes the indication that the serving network 10S requires the communication device 12 to transmit the commitment 16, wherein the indication is an indication that the commitment 16 is required as a condition for the serving network 10S to provide service to and / or establish a signaling connection with the communication device 12 (Block 930).
[0120] Figure 9B depicts a method performed by a home network node 14H in a home network 10H of a communication device 12 in accordance with other particular embodiments. The method includes receiving, from a serving network 10S of the communication device 12, a commitment 16 that cryptographically commits the communication device 12 to being associated with an identifier 18 (Block 1000). The method also includes generating a cryptographic key 22 usable by the serving network 10S to verify the commitment 16 (Block 1010). The method also includes transmitting 930 the cryptographic key 22 to the serving network 10S (Block 1020).
[0121] In some embodiments, the commitment 16 includes a concealed identifier 18C and a tag. In some embodiments, the concealed identifier 18C cryptographically conceals, at least in part, the identifier 18 associated with the communication device 12, and the tag cryptographically commits the communication device 12 to being associated with the identifier 18. In some embodiments, the commitment 16 is constructed using a committing authenticated encryption algorithm. In some embodiments, the tag is an authentication tag of the committing authenticated encryption algorithm, and wherein the concealed identifier 18C is a ciphertext of the committing authenticated encryption algorithm. In some embodiments, the method further comprises deconcealing the concealed identifier 18C as part of opening the commitment 16 using the cryptographic key 22, in order to obtain a deconcealed identifier 18P (Block 1030), and transmitting the deconcealed identifier 18P to the communication device 12 (Block 1040).
[0122] In some embodiments, the commitment 16 is received from the serving network 10S in, during, in connection to, or as part of a procedure to establish a signaling connection between the communication device 12 and the serving network 10S.
[0123] In some embodiments, the method further comprises, after or responsive to receiving the commitment 16, participating in an authentication procedure in which the communication device 12, the serving network 10S, and the home network 10H participates. In some embodiments, the cryptographic key 22 is sent to the serving network 10S in, during, in connection to, or as part of the authentication procedure (Block 1050).
[0124] In some embodiments, the commitment 16 includes a concealed identifier 18C. In some embodiments, the concealed identifier 18C cryptographically conceals, at least in part, the identifier 18 associated with the communication device 12. In some embodiments, the concealed identifier 18C is at least a part of a Subscription Concealed Identifier, SUCI. In some embodiments, the SUCI includes an indication that the SUCI is a committing SUCI which includes, or accompanies, the commitment 16, and the identifier 18 is a Subscription Permanent Identifier, SUPI.
[0125] Embodiments herein also include corresponding apparatuses. Embodiments herein for instance include a communication device 12 configured to perform any of the steps of any of the embodiments described above for the communication device 12.
[0126] Embodiments also include a communication device 12 comprising processing circuitry and power supply circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the communication device 12. The power supply circuitry is configured to supply power to the communication device 12.
[0127] Embodiments further include a communication device 12 comprising processing circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the communication device 12. In some embodiments, the communication device 12 further comprises communication circuitry.
[0128] Embodiments further include a communication device 12 comprising processing circuitry and memory. The memory contains instructions executable by the processing circuitry whereby the communication device 12 is configured to perform any of the steps of any of the embodiments described above for the communication device 12.
[0129] Embodiments moreover include a user equipment (UE). The UE comprises an antenna configured to send and receive wireless signals. The UE also comprises radio frontend circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the communication device 12. In some embodiments, the UE also comprises an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry. The UE may comprise an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry. The UE may also comprise a battery connected to the processing circuitry and configured to supply power to the UE.
[0130] Embodiments herein also include a network node 14S or 14H configured to perform any of the steps of any of the embodiments described above for the network node 14S or 14H.
[0131] Embodiments also include a network node 14S or 14H comprising processing circuitry and power supply circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the serving network node 14S or the home network node 14H. The power supply circuitry is configured to supply power to the network node 14S or 14H.
[0132] Embodiments further include a network node 14S or 14H comprising processing circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the serving network node 14S or the home network node 14H.. In some embodiments, the network node 14S or 14H further comprises communication circuitry.
[0133] Embodiments further include a network node 14S or 14H comprising processing circuitry and memory. The memory contains instructions executable by the processing circuitry whereby the network node 14S or 14H is configured to perform any of the steps of any of the embodiments described above for the serving network node 14S or the home network node 14H..
[0134] More particularly, the apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and / or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.
[0135] Figure 9B for example illustrates a communication device 12 as implemented in accordance with one or more embodiments. As shown, the communication device 12 includes processing circuitry 1010 and communication circuitry 1020. The communication circuitry 1020 (e.g., radio circuitry) is configured to transmit and / or receive information to and / or from one or more other nodes, e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the communication device 12. The processing circuitry 1010 is configured to perform processing described above, e.g., in Figure 8A-8B, such as by executing instructions stored in memory 1030. The processing circuitry 1010 in this regard may implement certain functional means, units, or modules.
[0136] Figure 11 illustrates a network node 14S or 14H as implemented in accordance with one or more embodiments. As shown, the network node 14S or 14H includes processing circuitry 1110 and communication circuitry 1120. The communication circuitry 1120 is configured to transmit and / or receive information to and / or from one or more other nodes, e.g., via any communication technology. The processing circuitry 1110 is configured to perform processing described above, e.g., in Figure 9A and / or Figure 9B, such as by executing instructions stored in memory 1130. The processing circuitry 1110 in this regard may implement certain functional means, units, or modules. Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs.
[0137] A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.
[0138] Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.
[0139] In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of an apparatus, cause the apparatus to perform as described above.
[0140] Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. This computer program product may be stored on a computer readable recording medium.
[0141] Figure 12 shows an example of a communication system 1200 in accordance with some embodiments.
[0142] In the example, the communication system 1200 includes a telecommunication network 1202 that includes an access network 1204, such as a radio access network (RAN), and a core network 1206, which includes one or more core network nodes 1208. The access network 1204 includes one or more access network nodes, such as network nodes 1210a and 1210b (one or more of which may be generally referred to as network nodes 1210), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1202 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1202 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1202, including one or more network nodes 1210 and / or core network nodes 1208.
[0143] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 1210 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1212a, 1212b, 1212c, and 1212d (one or more of which may be generally referred to as UEs 1212) to the core network 1206 over one or more wireless connections.
[0144] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1200 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1200 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.
[0145] The UEs 1212 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1210 and other communication devices. Similarly, the network nodes 1210 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1212 and / or with other network nodes or equipment in the telecommunication network 1202 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1202.
[0146] In the depicted example, the core network 1206 connects the network nodes 1210 to one or more host computing systems, such as host 1216. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1206 includes one more core network nodes (e.g., core network node 1208) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1208. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).
[0147] The host 1216 may be under the ownership or control of a service provider other than an operator or provider of the access network 1204 and / or the telecommunication network 1202. The host 1216 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.
[0148] As a whole, the communication system 1200 of Figure 12 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.
[0149] In some examples, the telecommunication network 1202 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1202 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1202. For example, the telecommunications network 1202 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs. In some examples, the UEs 1212 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1204 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1204. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E- UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).
[0150] In the example, the hub 1214 communicates with the access network 1204 to facilitate indirect communication between one or more UEs (e.g., UE 1212c and / or 1212d) and network nodes (e.g., network node 1210b). In some examples, the hub 1214 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1214 may be a broadband router enabling access to the core network 1206 for the UEs. As another example, the hub 1214 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1210, or by executable code, script, process, or other instructions in the hub 1214. As another example, the hub 1214 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1214 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 1214 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1214 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1214 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.
[0151] The hub 1214 may have a constant / persistent or intermittent connection to the network node 1210b. The hub 1214 may also allow for a different communication scheme and / or schedule between the hub 1214 and UEs (e.g., UE 1212c and / or 1212d), and between the hub 1214 and the core network 1206. In other examples, the hub 1214 is connected to the core network 1206 and / or one or more UEs via a wired connection. Moreover, the hub 1214 may be configured to connect to an M2M service provider over the access network 1204 and / orto another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1210 while still connected via the hub 1214 via a wired or wireless connection. In some embodiments, the hub 1214 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1210b. In other embodiments, the hub 1214 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1210b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.
[0152] Figure 13 shows a UE 1300 in accordance with some embodiments. The UE 1300 presents additional details of some embodiments of the UE 1212 of Figure 1. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB- loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.
[0153] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).
[0154] The UE 1300 includes processing circuitry 1302 that is operatively coupled via a bus 1304 to an input / output interface 1306, a power source 1308, a memory 1310, a communication interface 1312, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 13. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.
[0155] The processing circuitry 1302 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1310. The processing circuitry 1302 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1302 may include multiple central processing units (CPUs).
[0156] In the example, the input / output interface 1306 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1300. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.
[0157] In some embodiments, the power source 1308 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1308 may further include power circuitry for delivering power from the power source 1308 itself, and / or an external power source, to the various parts of the UE 1300 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1308. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1308 to make the power suitable for the respective components of the UE 1300 to which power is supplied.
[0158] The memory 1310 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1310 includes one or more application programs 1314, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1316. The memory 1310 may store, for use by the UE 1300, any of a variety of various operating systems or combinations of operating systems.
[0159] The memory 1310 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1310 may allow the UE 1300 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1310, which may be or comprise a device-readable storage medium.
[0160] The processing circuitry 1302 may be configured to communicate with an access network or other network using the communication interface 1312. The communication interface 1312 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1322. The communication interface 1312 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1318 and / or a receiver 1320 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1318 and receiver 1320 may be coupled to one or more antennas (e.g., antenna 1322) and may share circuit components, software or firmware, or alternatively be implemented separately.
[0161] In the illustrated embodiment, communication functions of the communication interface 1312 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11 , Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.
[0162] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1312, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).
[0163] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.
[0164] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 1300 shown in Figure 13.
[0165] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.
[0166] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.
[0167] Figure 14 shows a network node 1400 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).
[0168] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O- RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).
[0169] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).
[0170] The network node 1400 includes a processing circuitry 1402, a memory 1404, a communication interface 1406, and a power source 1408. The network node 1400 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1400 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1400 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1404 for different RATs) and some components may be reused (e.g., a same antenna 1410 may be shared by different RATs). The network node 1400 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1400, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z- wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1400.
[0171] The processing circuitry 1402 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1400 components, such as the memory 1404, to provide network node 1400 functionality.
[0172] In some embodiments, the processing circuitry 1402 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1402 includes one or more of radio frequency (RF) transceiver circuitry 1412 and baseband processing circuitry 1414. In some embodiments, the radio frequency (RF) transceiver circuitry 1412 and the baseband processing circuitry 1414 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1412 and baseband processing circuitry 1414 may be on the same chip or set of chips, boards, or units.
[0173] The memory 1404 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1402. The memory 1404 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1402 and utilized by the network node 1400. The memory 1404 may be used to store any calculations made by the processing circuitry 1402 and / or any data received via the communication interface 1406. In some embodiments, the processing circuitry 1402 and memory 1404 is integrated.
[0174] The communication interface 1406 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 1406 comprises port(s) / terminal(s) 1416 to send and receive data, for example to and from a network over a wired connection. The communication interface 1406 also includes radio front-end circuitry 1418 that may be coupled to, or in certain embodiments a part of, the antenna 1410. Radio front-end circuitry 1418 comprises filters 1420 and amplifiers 1422. The radio front-end circuitry 1418 may be connected to an antenna 1410 and processing circuitry 1402. The radio front-end circuitry may be configured to condition signals communicated between antenna 1410 and processing circuitry 1402. The radio front-end circuitry 1418 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1418 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1420 and / or amplifiers 1422. The radio signal may then be transmitted via the antenna 1410. Similarly, when receiving data, the antenna 1410 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1418. The digital data may be passed to the processing circuitry 1402. In other embodiments, the communication interface may comprise different components and / or different combinations of components.
[0175] In certain alternative embodiments, the network node 1400 does not include separate radio front-end circuitry 1418, instead, the processing circuitry 1402 includes radio front-end circuitry and is connected to the antenna 1410. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1412 is part of the communication interface 1406. In still other embodiments, the communication interface 1406 includes one or more ports or terminals 1416, the radio front-end circuitry 1418, and the RF transceiver circuitry 1412, as part of a radio unit (not shown), and the communication interface 1406 communicates with the baseband processing circuitry 1414, which is part of a digital unit (not shown). The antenna 1410 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1410 may be coupled to the radio front-end circuitry 1418 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1410 is separate from the network node 1400 and connectable to the network node 1400 through an interface or port.
[0176] The antenna 1410, communication interface 1406, and / or the processing circuitry 1402 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1410, the communication interface 1406, and / or the processing circuitry 1402 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.
[0177] The power source 1408 provides power to the various components of network node 1400 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1408 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1400 with power for performing the functionality described herein. For example, the network node 1400 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1408. As a further example, the power source 1408 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.
[0178] Embodiments of the network node 1400 may include additional components beyond those shown in Figure 14 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1400 may include user interface equipment to allow input of information into the network node 1400 and to allow output of information from the network node 1400. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1400. In some embodiments providing a core network node, such as core network node 108 of FIG. 12, some components, such as the radio front-end circuitry 1418 and the RF transceiver circuitry 1412 may be omitted. Figure 15 is a block diagram illustrating a virtualization environment 1500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1500 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.
[0179] Applications 1502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.
[0180] Hardware 1504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1508a and 1508b (one or more of which may be generally referred to as VMs 1508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1506 may present a virtual operating platform that appears like networking hardware to the VMs 1508.
[0181] The VMs 1508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1506. Different embodiments of the instance of a virtual appliance 1502 may be implemented on one or more of VMs 1508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. In the context of NFV, a VM 1508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1508, and that part of hardware 1504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1508 on top of the hardware 1504 and corresponds to the application 1502.
[0182] Hardware 1504 may be implemented in a standalone network node with generic or specific components. Hardware 1504 may implement some functions via virtualization. Alternatively, hardware 1504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1510, which, among others, oversees lifecycle management of applications 1502. In some embodiments, hardware 1504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1512 which may alternatively be used for communication between hardware nodes and radio units.
[0183] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.
[0184] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.
[0185] Some embodiments herein may be enumerated as follows:
[0186] Group Y Embodiments
[0187] In some embodiments, node = AUSF / SEAF, client = UE, and home network = UDM / APRF.
[0188] 1 . A method of a node in a serving network for identification of a client, the method comprising:
[0189] - obtaining a concealed identifier associated with the client;
[0190] - obtaining a commitment to the identifier;
[0191] - participating in an authentication of the client;
[0192] - obtaining an opening key for the commitment;
[0193] - opening the commitment using the opening key:
[0194] - obtaining the identifier:
[0195] - verifying that the commitment binds the concealed identifier to the identifier; and
[0196] - associating the identifier with the client.
[0197] 2. A method as in claim 1 , where the identifier is a SUPI
[0198] 3. A method as in any of the claims above where the commitment is at least part of a SUCI 3a. A method as in any of the claims above where the concealed identifier is at least part of a SUCI.
[0199] 4. A method as in claims 1-2 above where the commitment is separate from the SUCI.
[0200] 5. A method as in any of the claims above where the commitment is constructed using a committing encryption algorithm. 6. A method as in claim 5 and where the committing encryption algorithm is a symmetric key algorithm.
[0201] 7. A method as in any of the claims above where the key for the committing encryption algorithm is derived from a key encapsulation mechanism (KEM).
[0202] 8. A method as in any of the claims above where the authentication involves three parties
[0203] 9. A method as in any of the claims above where the authentication further comprises obtaining authentication information from a home network sharing a credential with the client
[0204] 10. A method as in claim 9 where the authentication information is an authentication vector (AV)
[0205] 11 . A method as in claim 9-10 where the authentication further comprises verifying information obtained from the client with information obtained from the home network.
[0206] 11a. A method as any of the above claims further comprises sending a request for an opening key.
[0207] 11 b. A method as in claim 11 a further comprising determining whether the client should be granted network service if no opening key can be obtained.
[0208] Group Z Embodiments
[0209] In some embodiments, node = AUSF / SEAF, client = UE, and home network = UDM / APRF.
[0210] 12. A method of a client for identification, the method comprising:
[0211] - sending a concealed identifier to a node;
[0212] - determining the need for sending a commitment to the identifier; and
[0213] - only sending the commitment if determined needed
[0214] 12b. A method according to claim 12 where the determination comprises obtaining an indication of the need for commitment
[0215] 12c. A method according to any of claim 12-12b where the determination comprises obtaining an indication of the need for commitment.
[0216] 12d. A method according to 12-12c where the commitment is at least part of the concealed identifier.
[0217] 12e. A method according to 12-12d where the concealed identifier is a SUCI.
[0218] 12f. A method according to 12-12e where the identifier is a SUPI.
[0219] Group ZZ Embodiments
[0220] In some embodiments, node = AUSF / SEAF, client = UE, and home network = UDM / APRF.
[0221] 13. A method of a node in a home network for identification of a client, the method comprising: - obtaining a concealed identifier associated with the client, where the client can produce a commitment for said identifier;
[0222] - participating in an authentication of the client;
[0223] - deriving an opening key for the commitment;
[0224] - sending the opening key and the identifier to a serving network node.
[0225] 13b. A method as in claim 13, where the node in the home network obtain at least part of the commitment to the identifier;
[0226] ... Dependent claims corresponding to claims 2-11
[0227] Group ZZZ Embodiments
[0228] In some embodiments, node = AMF / AUSF / SEAF, client = UE, and home network = UDM / APRF.
[0229] 25. A method of a node in a serving network for enforcing identification of a client, the method comprising:
[0230] - obtaining a concealed or unconcealed identifier associated with the client;
[0231] - determining whether a commitment is associated with the identifier or not;
[0232] - if the determining results negative, sending to the client an indication that a commitment is required for access
[0233] REFERENCES
[0234] 1. The Landscape of Committing Authenticated Encryption. Bellare, Hoang, Wu
[0235] 2. Message Franking via Committing Authenticated Encryption. Grubbs, Lu, Ristenpart
[0236] 3. Security architecture and procedures for 5G System (3GPP TS 33.501 version 18.4.0 Release 18) htps: / / csrc.nist. gov / Proiects / Post-Ouantum-CrvDtograpliv / Post-Ouantum-CrvDtograDliv-
[0237] Standardization
Claims
CLAIMS1 . A method performed by a serving network node (14S) in a serving network (10S) of a communication device (12), the method comprising: obtaining (800) a concealed identifier (18C) associated with the communication device (12); obtaining (810) a commitment (16) that cryptographically commits the communication device (12) to being associated with an identifier (18); obtaining (820) a cryptographic key (22) from a home network (10H) of the communication device (12); deconcealing (830) the concealed identifier (18C) using the cryptographic key (22) in order to obtain a deconcealed identifier (18P); and performing (840), or requesting another network node in the serving network (10S) to perform, verification (24) of the commitment (16) using the cryptographic key (22), wherein verification (24) of the commitment (16) verifies whether or not the identifier (18) to which the commitment (16) cryptographically commits the communication device (12) is the deconcealed identifier (18P).
2. The method of claim 1 , wherein the commitment (16) includes the concealed identifier (18C) and a tag that cryptographically commits the communication device (12) to being associated with the identifier (18), wherein obtaining the concealed identifier (18C) comprises obtaining the commitment (16).
3. The method of claim 2, wherein deconcealing the concealed identifier (18C) comprises, or is performed as part of, opening the commitment (16) using the cryptographic key (22).
4. The method of any of claims 2-3, wherein said verification (24) of the commitment (16) comprises: generating a recreated tag as a function of the cryptographic key (22) and the deconcealed identifier (18P); comparing the recreated tag to the tag included in the commitment (16); and determining whether or not the tag included in the commitment (16) matches the recreated tag according to said comparing, wherein the tag included in the commitment (16) matches the recreated tag if the identifier (18) to which the commitment (16) cryptographically committed the communication device (12) is the deconcealed identifier (18P).
5. The method of claim 4, wherein generating the recreated tag comprises: deriving a derived cryptographic key from the cryptographic key (22); and computing the recreated tag as a function of the derived cryptographic key and the deconcealed identifier (18P).
6. The method of any of claims 2-5, wherein the tag is a Message Authentication Code, MAC, tag that is a function of the cryptographic key (22) and the identifier (18).
7. The method of any of claims 1-6, wherein verification (24) of the commitment (16) verifies whether or not the commitment (16) binds the concealed identifier (18C) to the deconcealed identifier (18P).
8. The method of any of claims 1-7, wherein the concealed identifier (18C) is an encrypted identifier, wherein deconcealing the concealed identifier (18C) comprises: deriving a decryption key from the cryptographic key (22); and decrypting the encrypted identifier using the derived decryption key.
9. The method of any of claims 1-8, wherein the commitment (16) is constructed using a committing authenticated encryption algorithm, wherein the commitment (16) includes an authentication tag of the committing authenticated encryption algorithm, wherein the authentication tag cryptographically commits the communication device (12) to being associated with the identifier (18), wherein the cryptographic key (22) is a commitment key of the committing authenticated encryption algorithm, and wherein the concealed identifier (18C) is a ciphertext of the committing authenticated encryption algorithm.
10. The method of any of claims 1 -9, wherein the commitment (16) is received from the communication device (12) in, during, or as part of a procedure to establish a signaling connection between the communication device (12) and the serving network (10S).11 . The method of claim 10, wherein the commitment (16) is received from the communication device (12) in a request (15) to initiate the procedure to establish the signaling connection, wherein the method further comprises: rejecting the request (15) to initiate the procedure if the verification (24) of the commitment (16) fails; or accepting the request (15) to initiate the procedure if the verification (24) of the commitment (16) succeeds.
12. The method of any of claims 10-11 , further comprising, after or responsive to receiving the commitment (16) from the communication device (12), initiating (850) an authentication procedure in which the communication device (12), the serving network (10S), and the home network (10H) participates, wherein the cryptographic key (22) is received from the home network (10H) in, during, in connection to, or as part of the authentication procedure.
13. The method of any of claims 1-12, further comprising, based on successful verification (24) of the commitment (16), associating (860) the identifier (18) with the communication device (12).
14. The method of any of claims 1-13, further comprising: making (870) a decision of whether or not to provide service to the communication device (12) based on whether or not the verification (24) of the commitment (16) is successful; and providing or rejecting (880) service to the communication device (12) according to the decision.
15. The method of any of claims 1-14, wherein the concealed identifier (18C) is at least a part of a Subscription Concealed Identifier, SUCI, wherein the SUCI includes an indication that the SUCI is a committing SUCI which includes, or accompanies, the commitment (16), and wherein the identifier (18) is a Subscription Permanent Identifier, SUPI.
16. The method of any of claims 1-15, further comprising transmitting (890), to the communication device (12), signaling indicating that a commitment (16) to an identifier (18) associated with the communication device (12) is required as a condition for the serving network (10S) to provide service to and / or establish a signaling connection with the communication device (12).
17. The method of any of claims 1-16, further comprising receiving (895) a home network provided identifier (18H) from the home network (10H), and wherein verification (24) of the commitment (16) further comprises verifying whether the deconcelaed identifier (18P) is the same as the home network provided identifier (18H).
18. A method performed by a communication device (12), the method comprising: transmitting (900) a commitment (16) to a serving network (10S) of the communication device (12), based on an indication that the serving network(10S) requires the communication device (12) to transmit the commitment (16); wherein the commitment (16) includes a concealed identifier (18C) and a tag; wherein the concealed identifier (18C) cryptographically conceals, at least in part, an identifier (18) associated with the communication device (12); and wherein the tag cryptographically commits the communication device (12) to being associated with the identifier (18).
19. The method of claim 18, further comprising generating the commitment (16) by: deriving (910) a cryptographic key (22) from a public key of a home network (10H) of the communication device (12); and generating (920) the concealed identifier (18C) and the tag using the cryptographic key (22).
20. The method of claim 19, wherein said generating comprises: generating the concealed identifier (18C) by deriving an encryption key from the cryptographic key (22) and encrypting the identifier (18) using the encryption key; and generating the tag by deriving a derived cryptographic key from the cryptographic key (22) and generating the tag as a function of the derived cryptographic key and the concealed identifier (18C).21 . The method of any of claims 18-20, wherein the commitment (16) cryptographically binds the concealed identifier (18C) to the identifier (18).
22. The method of any of claims 18-21 , wherein the commitment (16) is constructed using a committing authenticated encryption algorithm, wherein the tag is an authentication tag of the committing authenticated encryption algorithm, and wherein the concealed identifier (18C) is a ciphertext of the committing authenticated encryption algorithm.
23. The method of any of claims 18-22, wherein the commitment (16) is transmitted in, during, or as part of a procedure to establish a signaling connection between the communication device (12) and the serving network (10S).
24. The method of claim 23, further comprising, in association with the procedure, participating in an authentication procedure in which the communication device (12), the serving network (10S), and a home network (10H) of the communication device (12)participates.
25. The method of any of claims 23-24, wherein the commitment (16) is transmitted in a request (15) to initiate the procedure to establish the signaling connection, wherein the request (15) is rejected if verification (24) of the commitment (16) fails.
26. The method of any of claims 18-25, wherein the concealed identifier (18C) is at least a part of a Subscription Concealed Identifier, SUCI, wherein the SUCI includes an indication that the SUCI is a committing SUCI which includes, or accompanies, the commitment (16), and wherein the identifier (18) is a Subscription Permanent Identifier, SUPI.
27. The method of any of claims 18-26, further comprising receiving (930), from the serving network (10S), signaling that includes the indication that the serving network (10S) requires the communication device (12) to transmit the commitment (16), wherein the indication is an indication that the commitment (16) is required as a condition for the serving network (10S) to provide service to and / or establish a signaling connection with the communication device (12).
28. A method performed by a home network node (14H) in a home network (10H) of a communication device (12), the method comprising: receiving (1000), from a serving network (10S) of the communication device (12), a commitment (16) that cryptographically commits the communication device (12) to being associated with an identifier (18); generating (1010) a cryptographic key (22) usable by the serving network (10S) to verify the commitment (16); and transmitting (1020) the cryptographic key (22) to the serving network (10S).
29. The method of claim 28, wherein the commitment (16) includes a concealed identifier (18C) and a tag, wherein the concealed identifier (18C) cryptographically conceals, at least in part, the identifier (18) associated with the communication device (12), and wherein the tag cryptographically commits the communication device (12) to being associated with the identifier (18).
30. The method of claim 29, wherein the commitment (16) is constructed using a committing authenticated encryption algorithm, wherein the tag is an authentication tag of the committing authenticated encryption algorithm, and wherein the concealed identifier (18C) is a ciphertext of the committing authenticated encryption algorithm.31 . The method of any of claims 29-30, further comprising: deconcealing (1030) the concealed identifier (18C) as part of opening the commitment (16) using the cryptographic key (22), in order to obtain a deconcealed identifier (18P); and transmitting (1040) the deconcealed identifier (18P) to the communication device (12).
32. The method of any of claims 28-31 , wherein the commitment (16) is received from the serving network (10S) in, during, in connection to, or as part of a procedure to establish a signaling connection between the communication device (12) and the serving network (10S).
33. The method of any of claims 28-32, further comprising, after or responsive to receiving (1050) the commitment (16), participating in an authentication procedure in which the communication device (12), the serving network (10S), and the home network (10H) participates, wherein the cryptographic key (22) is sent to the serving network (10S) in, during, in connection to, or as part of the authentication procedure.
34. The method of any of claims 27-33, wherein the commitment (16) includes a concealed identifier (18C), wherein the concealed identifier (18C) cryptographically conceals, at least in part, the identifier (18) associated with the communication device (12), wherein the concealed identifier (18C) is at least a part of a Subscription Concealed Identifier, SUCI, wherein the SUCI includes an indication that the SUCI is a committing SUCI which includes, or accompanies, the commitment (16), and wherein the identifier (18) is a Subscription Permanent Identifier, SUPI.
35. A serving network node (14S) in a serving network (10S) of a communication device (12), the serving network node (14S) configured to: obtain a concealed identifier (18C) associated with the communication device (12); obtain a commitment (16) that cryptographically commits the communication device (12) to being associated with an identifier (18); obtain a cryptographic key (22) from a home network (10H) of the communication device (12); deconceal the concealed identifier (18C) using the cryptographic key (22) in order to obtain a deconcealed identifier (18P); and perform, or request another network node in the serving network (10S) to perform, verification (24) of the commitment (16) using the cryptographic key (22),wherein verification (24) of the commitment (16) verifies whether or not the identifier (18) to which the commitment (16) cryptographically commits the communication device (12) is the deconcealed identifier (18P).
36. The serving network node (14S) of claim 35, configured to perform the method of any of claims 2-17.
37. A communication device (12) configured to: transmit a commitment (16) to a serving network (10S) of the communication device (12), based on an indication that the serving network (10S) requires the communication device (12) to transmit the commitment (16); wherein the commitment (16) includes a concealed identifier (18C) and a tag; wherein the concealed identifier (18C) cryptographically conceals, at least in part, an identifier (18) associated with the communication device (12); and wherein the tag cryptographically commits the communication device (12) to being associated with the identifier (18).
38. The communication device (12) of claim 37, configured to perform the method of any of claims 19-27.
39. A home network node (14H) in a home network (10H) of a communication device (12), the home network node (14H) configured to: receive, from a serving network (10S) of the communication device (12), a commitment (16) that cryptographically commits the communication device (12) to being associated with an identifier (18); generate a cryptographic key (22) usable by the serving network (10S) to verify the commitment (16); and transmit the cryptographic key (22) to the serving network (10S).
40. The home network node (14H) of claim 39, configured to perform the method of any of claims 29-34.41 . A computer program comprising instructions which, when executed by at least one processor of a serving network node (14S), causes the serving network node (14S) to perform the method of any of claims 1-17.
42. A computer program comprising instructions which, when executed by at least oneprocessor of a communication device (12), causes the communication device (12) to perform the method of any of claims 18-27.
43. A computer program comprising instructions which, when executed by at least one processor of a home network node (14H), causes the home network node (14H) to perform the method of any of claims 28-34.
44. A carrier containing the computer program of any of claims 41-43, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.
Citation Information
Patent Citations
Methods for providing regulation compliant privacy and related apparatuses
US20220086620A1