Patent Application
20230007491
The present disclosure relates to a system, methods and nodes for managing a communication network subscription identifier that is associated with a device. The present disclosure also relates to a computer program and a computer program product configured, when run on a computer to carry out methods for managing a communication network subscription identifier that is associated with a device.
The “Internet of Things” (IoT) refers to devices enabled for communication network connectivity, so that these devices may be remotely managed, and data collected or required by the devices may be exchanged between individual devices and between devices and application servers. Such devices, examples of which may include sensors and actuators, are often, although not necessarily, subject to severe limitations on processing power, storage capacity, energy supply, device complexity and/or network connectivity, imposed by their operating environment or situation, and may consequently be referred to as constrained devices.
Mobile communication networks are increasingly used by IoT devices, and continuing dramatic increase in the use of these devices for a wide range of services is expected in the coming years. One obstacle to this growth in the use of IoT devices is the cost of the devices, and in particular the cost of the Universal Integrated Circuit Card (UICC) and embedded UICC (eUICC) technologies that are used to hold and protect subscriber credentials. These credentials are used in the authentication process that enables access to a mobile network. The cost of such technologies is almost on par with the cost of the modem of the IoT device.
Implementing Subscriber Identification Module (SIM) functionality through UICC and eUICC technologies is thus prohibitively expensive in the context of realizing a vision of several tens of billions of mobile connected devices in the near future. Alternative solutions to the UICC and eUICC have been proposed to address this cost issue. Such solutions include integrated UICC (iUICC) and Machine Communication Identity Module (MCIM). These solutions would lower cost significantly by implementing the SIM functions in circuitry that is integrated in the device modem or main processing chip. While addressing the cost issues associated with UICC and eUICC, the iUICC and MCIM offer lower strength subscription protection owing to their tightly integrated nature. It is very difficult, if not impossible, to fully apply strict security assurance procedures like Common Criteria in iUICC and MCIM, as it is very hard to have the circuitry for the SIM functions fully isolated from the rest of the chip. A strict security assurance for the whole chip would be an insurmountably difficult task that would also be extremely costly.
When using tightly integrated SIM solutions, there is therefore an increased risk of subscription fraud that could arise from credentials being exfiltrated from a device and cloned into another device. An additional complication for device owners when considering subscription fraud prevention is that device testing, device repair and management of broken devices all require a degree of control over which subscription identifiers are used in test and replacement devices.
US 20110014939 discloses a method for detection of subscription fraud on the basis of location information in a local network. However, location information may not be sufficient to detect fraudulent use of credentials in all use cases, and in addition, the method of US 20110014939 fails to account for situations in which a device may be roaming, and so connected to a visited network as opposed to its home network.
It is an aim of the present disclosure to provide a system, methods, nodes and computer readable medium which at least partially address one or more of the challenges discussed above. It is a further aim of the present disclosure to provide a system, methods, nodes and computer readable medium which cooperate to ensure that cloned subscription credentials may not be used to obtain network access authentication.
According to a first aspect of the present disclosure, there is provided a system for managing a communication network subscription identifier associated with a device. The system comprises a Core Network node configured to provide a subscription identifier for the device to a Device Management node with management responsibility for the device and a Verification node configured to receive from the Device Management node the subscription identifier and a characteristic of the device, and to bind the subscription identifier to the characteristic such that the subscription identifier is uniquely associated with the characteristic. The system further comprises a Network Access node configured to obtain the subscription identifier from the device. The Verification node, Network Access node and Core Network node are configured to cooperate to verify that the device from which the Network Access node obtained the subscription identifier is in possession of the characteristic that is bound to the subscription identifier.
According to another aspect of the present disclosure, there is provided a method for managing a communication network subscription identifier associated with a device. The method, performed by a Verification node, comprises receiving, from a Device Management node with management responsibility for the device, a subscription identifier for the device and a characteristic of the device, binding the subscription identifier to the characteristic such that the subscription identifier is uniquely associated with the characteristic, and storing the bound subscription identifier and characteristic in a memory.
According to another aspect of the present disclosure, there is provided a method for verifying a communication network subscription identifier associated with a device. The method, performed by the device, comprises receiving a parameter from a Network Access node, generating, on the basis of the received parameter, a parameter for sending to the Network Access node, and sending the generated parameter to the Network Access node. The method further comprises performing a cryptographic calculation on at least one of the received parameter or the generated parameter using a characteristic of the device, wherein the characteristic of the device has been bound to a subscription identity associated with the device such that the subscription identifier is uniquely associated with the characteristic.
According to another aspect of the present disclosure, there is provided a method for verifying a communication network subscription identifier associated with a device. The method, performed by a Network Access node, comprises sending a verification request to a Network node, the verification request comprising a subscription identifier presented by the device, and receiving a response from the Network node, the response comprising at least one of: a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic, a parameter on which a cryptographic calculation has been performed using such a characteristic, or an identification of a Verification node from which either the device characteristic or parameter may be obtained. The method further comprises sending a parameter to the device, receiving a parameter from the device, and checking that the received parameter matches an expected received parameter for the device. At least one of the parameter sent to the device or the parameter received from the device comprises a parameter on which a cryptographic calculation has been performed using a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic.
According to another aspect of the present disclosure, there is provided a method for verifying a communication network subscription identifier associated with a device. The method, performed by a Core Network node, comprises receiving a verification request from a Network Access node, the verification request comprising a subscription identifier presented by the device, and sending a response to the Network Access node, the response comprising at least one of: a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic, a parameter on which a cryptographic calculation has been performed using such a characteristic, or an identification of a Verification node from which either the device characteristic or parameter may be obtained.
According to another aspect of the present disclosure, there is provided a method for verifying a communication network subscription identifier associated with a device. The method, performed by a Verification node, comprises receiving a verification request from a Network node, the verification request comprising a subscription identifier presented by the device and retrieving from a memory a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. The method further comprises sending a response to the Network node, the response comprising at least one of: the retrieved device characteristic, or a parameter on which a cryptographic calculation has been performed using the retrieved characteristic.
According to another aspect of the present disclosure, there is provided a method for verifying a communication network subscription identifier associated with a device.
The method, performed by a Verification node, comprises receiving, from a Network Access node, information about a characteristic of the device and a subscription identifier presented by the device and comparing the received information about a characteristic to a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. The method further comprises, responsive to a request for a result of the comparison, sending a result of the comparison to at least one of the Network Access node, a Core Network node, and/or a Device Connection Service.
According to another aspect of the present disclosure, there is provided a computer program and a computer program product configured, when run on a computer to carry out methods for managing and/or verifying a communication network subscription identifier that is associated with a device as set out above.
According to another aspect of the present disclosure, there is provided a Verification node, Device, Network Access node and Core Network node, the nodes comprising processing circuitry configured to carry out methods for managing and/or verifying a communication network subscription identifier that is associated with a device as set out above.
For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:
Aspects of the present disclosure propose a system, methods and nodes that may cooperate to detect that cloned credentials are being used in an attempt to access a communication network, and consequently may prevent a device seeking to use such credentials from accessing the network. Aspects of the present disclosure propose binding a subscription identifier to a characteristic of a device with which the identifier is to be used, such that the subscription identifier is uniquely associated with the device characteristic. When the subscription identifier is presented by a device seeking network access, the binding between subscription identifier and device characteristic may be verified to ensure that the device presenting the subscription identifier is in possession of the characteristic to which the subscription identifier is bound. The nature of the device characteristic to which a subscription identifier is bound may vary according to different examples of the present disclosure. Two categories of device characteristic are proposed in the present disclosure: behavioural characteristics and permanent identities.
IoT devices are life-cycle managed through some form of Device Management system. In addition to collecting application related data (e.g. sensor data) the Device Management system manages Software updates to correct bugs or address security vulnerabilities. In order to secure the link between the device and the Device Management system, and to enable a user to claim and maintain ownership of the device, IoT devices are often equipped with a device identity that is permanent and independent of a mobile network to which the device may connect, and consequently independent of the operator of such a network. The permanent device identity comprises a permanent device identifier (PDI) and at least one associated credential. A permanent device identity of this nature may be distinguished from a subscription identity, which comprises a subscription identifier such as an International Mobile Subscriber Identity (IMSI), which is assigned by a communication network to subscribers to the network. The permanent device identity is not used for network access authentication, and remains unchanged even if a subscription identity (including a subscription identifier) for the device is updated, for example if the device is to be connected to another network owned by another MNO. Permanent device identities are used by the Device Management system for identifying individual devices, even if the device management system may also be aware of and make use of a subscription identifier allocated to a device. Permanent device identities lend themselves much more readily to strong protection against exfiltration of the identity credentials which may be comprised in the identity. Cloning of a permanent device identity may therefore be considered to be practically infeasible.
According to one example of the present disclosure, during a phase in which a device is registered in a device management system, and a subscription is arranged for the device, a permanent device identity may be bound to a subscription identifier for the device, such as an IMSI, and may also be bound to use or behavioural characteristics including mobile network cell information, and network functions that the device owner wishes the device to have. The permanent device identity is bound to the subscription identifier via its component permanent device identifier. As the permanent device identity is for all practical purposes not cloneable, and is bound (via its identifier) to the subscription identifier associated with the device, it is possible to check this binding before, during or after authentication by a network authentication agent. This check may discover that the binding is correct, or that the binding is incorrect, or that during network registration the same IMSI appears again but with a different permanent device identifier bound to it. Such a “re-binding” may be blocked or may trigger a fraud alarm that blocks network access until proper authorisation is established and the previous registered device management owner confirms the rebinding is correct and the device should be allowed to access the network.
In some circumstances, a device may not be provided with a permanent device identity but only a device identifier, which may be permanent or non-permanent. Some mobile devices, for example, are only provided with an International Mobile Equipment Identity (IMEI), which can be changed or cloned and so is not a basis for a secure binding between device and subscription identity. In such circumstances, it may be desirable to use a behavioural device characteristic for binding to the subscription identifier assigned to a device. The behavioural characteristic may be provided by a Device Connection Service (DCS) when the device is registered. The behavioural characteristic may for example include information, provided by the device owner (or in some cases the manufacturer of the device), about how the device connects to the network. Such information may, for example, be obtained from a Manufacturer Usage Description (MUD). This behaviour may then be observed by the DCS when the device connects to the network and/or during registration, in order to enable a comparison with the behaviour characteristic bound to the subscriber identifier presented by the device. For example, a device owner can indicate that a device is a stationary device such as a temperature sensor or a pump valve controller, in which case the DCS can record the network cell number and other network characteristics for binding to the subscriber identifier assigned to the device. In further examples, a behavioural characteristic may also encompass environmental factors, which may in some examples be linked to location, including altitude, temperature, electricity, land air and/or underwater deployments etc. Any such factors may be provided on registration of a device and observed when the device connects to the network.
When a device connects to a communication network, the DCS may observe the network characteristics of the connecting device and pass this to a Verification Node for comparison with the behavioural characteristic bound to the subscription identifier presented by the device. The Verification Node is a new functional service entity, which may be implemented on a physical or virtual node and may in some examples be co-located with one or more other services. The Verification node compares an observed behavioural characteristic from the DCS with a stored behavioural characteristic that is bound to the subscription identifier presented by the device, and performs an analysis to determine whether the connectivity is normal (observed and bound behavioural characteristics are consistent) or is potentially fraudulent (mismatch between the observed and bound behavioural characteristics). If a potential fraud is detected, the Verification node may push an alarm condition to a Network Access node, such as a Network Access Authentication Function (NAAF). Alternatively a Network Access node such as a NAAF may pull a verification result from the Verification node when it performs network access verification.
In some circumstances, the Network Access node for a particular device may be in a visited network, for example as a visited network Mobility Management Entity (MME) in a 4G network. In such circumstances, only the home network knows that a presented subscription identifier is associated with a device for which a Verification node service is available. To inform the Network Access node, the home network, for example a Core Network node such as a Home Subscription Server (HSS), may push a Unique Resource Identifier (URI) of the appropriate Verification node to the visiting network. The URI may be included with the authentication information that the home network pushes to the visited network under existing attach procedures. In other examples, for example in which a behavioural characteristic is bound to a subscription identifier, the DCS may have connection information that will be used for verification of a binding. In such examples, the home network (for example a Core Network node such as a HSS) may contact the DCS and pull connection information for provision to the Verification node to allow the Verification node to perform a binding check. If the binding check is unable to confirm that the device is in possession of a bound characteristic, the visiting network may be informed using standard network procedures that access should not be granted.
Referring to
According to examples of the present disclosure, the Core Network node may comprise a Home Subscription Server (HSS) in a 4G network, or the appropriate functionality of an Authentication Server Function (AUSF) or Unified Data Management (UDM) in a 5G network. The Verification node may comprise a new functional entity providing verification services as discussed above and in greater detail below. According to examples of the present disclosure, the Network Access node may comprise a Network Access Authentication Function (NAAF), Mobility Management Entity (MME) or Access Management Function (AMF), and may be located in a home or visited network. It will be appreciated that the nodes of the system 200 comprise functional entities that may be deployed on one or more physical or virtual nodes.
The nodes of the system 200 cooperate to provide binding by the Verification node 230 of a subscription identifier to a device characteristic, and to verify that a device presenting the subscription identifier is in possession of the characteristic bound to the identifier. As noted above, binding a characteristic to a subscription identifier comprises creating a unique association between these two elements. In some examples, the unique association may be immutable. In some circumstances, it may be required to re-bind a subscription identifier to a new device characteristic, for example in the event of testing of different devices with the same IMSI, replacement of a broken device with the same IMSI, subscription transfer between devices, etc. In such circumstances, the immutable nature of the binding between subscription identifier and device characteristic means that such a “re-binding” is in fact the creation of a new association for the subscription identity, which may be approved by the Device Management node through a signature, and not an updating of an existing binding. This distinction is discussed in greater detail below.
In some examples of the present disclosure, the Verification node 230, Network Access node 220 and Core Network node 210 may be configured to cooperate to verify that the device from which the Network Access node 220 obtained the subscription identifier is in possession of the characteristic that is bound to the subscription identifier by performing at least one of:
In some examples of the present disclosure, the Verification node 230, Network Access node 220 and Core Network node 210 may be configured to perform a cryptographic calculation using the characteristic that is bound to the subscription identifier, cause the device to perform a corresponding cryptographic calculation using a characteristic in its possession, and use the results of the cryptographic calculations to verify that the characteristic that is bound to the subscription identifier is the same as the characteristic that is in the possession of the device during a network authentication procedure for the device. In further examples, the performance and use of the cryptographic calculations may take place before or after a network authentication procedure.
In some examples of the present disclosure, the device that is in possession of a characteristic and presenting a subscription identifier may be a constrained device. For the purposes of the present disclosure, a constrained device comprises a device which conforms to the definition set out in section 2.1 of IETF RFC 7228 for “constrained node”. According to the definition in IETF RFC 7228, a constrained device is a device in which “some of the characteristics that are otherwise pretty much taken for granted for Internet nodes at the time of writing are not attainable, often due to cost constraints and/or physical constraints on characteristics such as size, weight, and available power and energy. The tight limits on power, memory, and processing resources lead to hard upper bounds on state, code space, and processing cycles, making optimization of energy and network bandwidth usage a dominating consideration in all design requirements. Also, some layer-2 services such as full connectivity and broadcast/multicast may be lacking”. Constrained devices are thus clearly distinguished from server systems, desktop, laptop or tablet computers and powerful mobile devices such as smartphones. A constrained device may for example comprise a Machine Type Communication device, a battery powered device or any other device having the above discussed limitations. Examples of constrained devices may include sensors measuring temperature, humidity and gas content, for example within a room or while goods are transported and stored, motion sensors for controlling light bulbs, sensors measuring light that can be used to control shutters, heart rate monitors and other sensors for personal health (continuous monitoring of blood pressure etc.) actuators and connected electronic door locks. IoT devices may comprise examples of constrained devices. Examples of the present disclosure may provide particular advantages when implemented in connection with constrained devices, owing to the trend in such devices toward integration of SIM function circuitry into a main processing chip and the security risks associated with such integration, as discussed in greater detail above.
It will be appreciated that the system 200 described above comprises a plurality of different nodes, each of which performs respective method steps in order to carry out the cooperation that achieves the above discussed functionality.
Referring to
Referring still to
In step 406, the Verification node receives, from a Core Network node, a subscription identifier binding policy and a subscription identifier to which the policy applies. The binding policy may specify under what circumstances a new binding may be created for a subscription identifier, or conditions that must be fulfilled for a binding to take place (certificate or signature required etc.).
In step 410, the Verification node receives, from the Device Management node with management responsibility for the device, a subscription identifier for the device and a characteristic of the device. The characteristic of the device received from the Device Management node may comprise at least one of a behavioural characteristic or a permanent device identity.
A behavioural characteristic may for example include information, provided by the device owner, about how the device connects to the network. For example, a device owner can indicate that a device is a stationary device and a behavioural characteristic for the device may include information about a location from which the device is expected to connect, such as mobile network cell information. A behavioural characteristic may additionally or alternatively include network functions that the device owner wishes the device to have, or any other information relating to how the device connects to and interacts with the network. The behavioural characteristic may then be observed by a Device Connection Service (DCS) for comparison with a bound behavioural characteristic.
A permanent device identity, as discussed above, comprises a permanent device identifier and a credential. A permanent device identity is independent of a mobile network to which the device may connect, and consequently is independent of the operator of such a network. A permanent device identity, and its constituent permanent device identifier, may thus be distinguished from a subscription identifier, such as an International Mobile Subscriber Identity (IMSI), which is assigned by a communication network to subscribers to the network. Permanent device identities are used by a device management system for identifying individual devices, even if the device management system may also be aware of and make use of a subscription identifier allocated to a device. A credential that is part of a permanent device identity, and therefore associated with the corresponding permanent device identifier, may in some examples comprise a device specific public key associated with a corresponding device specific private key, or may be a device specific symmetric key.
Referring still to
If binding of the subscription identifier received from the Device Management node to the characteristic received from the Device Management node is consistent with the subscription identifier binding policy, the Verification node proceeds, in step 420, to bind the subscription identifier to the characteristic such that the subscription identifier is uniquely associated with the characteristic. In step 430, the Verification node stores the bound subscription identifier and characteristic in a memory. In the case of a characteristic comprising a permanent device identity, the Verification node may bind the permanent device identity to the subscription identifier using the permanent device identifier part of the permanent device identity. In this manner, the permanent device identifier is explicitly bound to the subscription identifier, and via this binding, the entire permanent device identity, including the credential that is also part of the permanent device identity and is associated with the permanent device identifier, is also bound to the subscription identifier.
The steps of the methods 300 and/or 400 thus enable a Verification node to bind a subscription identifier assigned to a device by a Core Network node of a communication network to a characteristic of the device. The binding may be subject to various checks to ensure that the binding should go ahead, and creates a unique association between the subscription identifier and the characteristic, which association may be immutable. In some examples, the association may be a new association for a subscription identifier that has already been bound to a different device characteristic in the past. This situation is referred to as a “re-binding”, and may be subject to additional restrictions set out in a subscription identifier binding policy or imposed directly through a confirmatory check with a mobile network operator via a Core Network node or with a Device Management node.
The methods 300 and/or 400 may be complimented by methods carried out at a device, a Network Access node, a Core Network node a Device Management node and the Verification node, in order to verify that a device presenting a subscription identifier is in possession of the device characteristic to which the identifier has been bound by the Verification node. This is discussed in further detail below.
The method 500 further comprises the device performing, at step 530, a cryptographic calculation on at least one of the received parameter or the generated parameter using a characteristic of the device, wherein the characteristic of the device has been bound to a subscription identity associated with the device such that the subscription identifier is uniquely associated with the characteristic. The device characteristic may for example comprise a permanent device identity, bound via a permeant device identifier of the permanent device identity, as discussed above. The cryptographic calculation may be performed using the credential of the permanent device identity, which may comprise a public and private key pair or a symmetric key.
According to different examples of the present disclosure, performing a cryptographic calculation on at least one of the received parameter or the generated parameter using a characteristic of the device may comprise any one or more of:
According to different examples of the present disclosure, the device may for example decrypt an encrypted RAND parameter before performing AKA, EAP-AKA or EAP-AKA′, or may encrypt a generated RES parameter before sending this to the Network Access node, or the device may sign or generate a MAC for either the RAND or RES. Example implementations of the method 500 are illustrated in the message flow diagrams in
According to further examples of the present disclosure, the device may additionally derive a device specific key from the device characteristic in the form of a permanent device identity. For example, the device may derive a device specific symmetric key for use in encrypting or decrypting parameters. The device specific symmetric key may be derived from a device secret (such as device private key or symmetric key part of the device identity credential) that is a component part of the permanent device identity and is associated with the permanent device identifier. In other examples, the device may use a device private key comprised in the permanent device identity and associated with the permanent device identifier to decrypt a parameter received by the device and encrypted by another entity using a corresponding device public key. In further examples of the present disclosure, the device may additionally carry out process steps of an authentication procedure such as AKA, EAP-AKA or EAP-AKA′ according to existing or future standardised procedures.
Referring to
In step 620, the Network Access node receives a response from the Network node. As illustrated in step 620a, the response comprises at least one of:
In some examples, if the response comprises an identification of a Verification node from which either the device characteristic or parameter may be obtained, then the Network Access node may send a new verification request to the identified Verification node in order to obtain the device characteristic or parameter, before continuing with the method steps set out below.
In some examples, the Network node may then perform a cryptographic calculation in step 630 on at least one of a parameter to be sent to the device or an expected parameter to be received from the device, the calculation performed using the bound device characteristic received in step 620. The characteristic may for example be a permanent device identity, bound via its constituent permanent device identifier as discussed above, and the cryptographic calculation may be performed using the permanent device identifier of the permanent device identity, a device specific key derived from a device secret or credential associated with the permanent device identifier and comprised within the permanent device identity, or a device public key of a public/private key pair associated with the permanent device identifier and comprised within the permanent device identity. In the case of an implementation of the method 600 as part of an Authentication procedure, the parameter for sending to the device may be a RAND parameter and the expected parameter to be received from the device may be an XRES parameter. Performing a cryptographic calculation on a parameter using a characteristic of the device may comprise at least one of generating a MAC for the parameter using the characteristic and/or encrypting or decrypting the parameter using the characteristic. In the case of generating a MAC for the parameter using the characteristic, that MAC is then saved for comparison (in step 670) with a MAC received from the device in step 650, as discussed below.
In step 640, the Network Access node sends a parameter to the device. As discussed above, this may for example be a RAND parameter sent as part of an Authentication procedure or as a post-Authentication challenge. The parameter may in some examples have been encrypted, by the Network Access node or by another entity such as a Core Network node, using the bound device characteristic. In step 650, the Network Access node receives a parameter from the device. This may for example be a RES parameter generated by the device as part of an Authentication procedure or a response to a post-Authentication challenge. In other examples, the parameter may comprise a MAC generated by the device using the device's characteristic and based on the parameter sent by the Network Access node to the device. As illustrated in step 640a, at least one of the parameter sent to the device in step 640 or the parameter received from the device in step 650 comprises a parameter on which a cryptographic calculation has been performed using a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. The cryptographic calculation may be been performed by the Network Access node, if it has been performed on the parameter sent to the device, or by the device, if it has been performed on the parameter received from the device. As discussed above, the bound characteristic may comprise a permanent device identity, which comprises a permanent device identifier and a credential. The permanent device identity may have been bound to the subscription identifier via its permanent device identifier, and the cryptographic calculation may be performed using the credential of the permanent device identity, which credential is associated with the permanent device identifier.
In step 660, the Network Access node may perform a cryptographic calculation on the parameter received from the device using the device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. As discussed above, performing a cryptographic calculation on a parameter using a characteristic of the device may comprise at least one of generating a MAC for the parameter using the characteristic and/or encrypting or decrypting the parameter using the characteristic. For example, the Network Access node may encrypt the parameter received from the device, or may decrypt the parameter received from the device. In other examples, the Network Access node may compute a MAC on the parameter received from the device and store this MAC for comparison with a received MAC in step 670.
In step 670, the Network Access node checks that the received parameter matches an expected received parameter for the device. This checking may take different forms, depending upon the nature of the parameter received from the device, and in some examples, the checking may itself comprise performing a cryptographic calculation on the received parameter, as discussed below.
In the case of a received parameter in the form of a MAC, the expected received parameter may comprise a MAC which has been received by the Network Access node from a Core Network node (such as a HSS for the device) or has been calculated by the Network Access node in step 630 or 660 and stored for use in the comparison of step 670. The received or calculated MAC may be compared with the MAC received from the device.
In the case of a received parameter in the form of a RES, or a response to a post-Authentication challenge, the expected received parameter may comprise an XRES received as part of an Authentication Vector from a Core Network node, or an expected response value corresponding to the post-Authentication challenge. The received RES or response may be compared with the XRES or expected response.
In the case of a received parameter in the form of an encrypted RES or encrypted response to a post-Authentication challenge, an expected received parameter in the form of an XRES or expected response may have been encrypted by the Network Access node in step 660. Alternatively, the XRES or expected response may have been received in encrypted form by the Network Access node form a Core Network node or Verification node. The Network Access node may then directly compare the encrypted received RES or encrypted received response with the encrypted XRES or encrypted expected response.
In the case of a received parameter in the form of a signature, checking that the received parameter matches an expected parameter in step 670 may comprise computing a hash of the signed data and decrypting the signature to retrieve an expected hash of the signed data. The public key is used that corresponds to the private key used to sign the data. Checking further comprises comparison of the computed hash with the expected hash. Thus in the example of a received parameter comprising a signature, a cryptographic calculation is performed on the parameter received from the device by both the device (in generating the signature) and the Network Access node (in verifying the signature).
As mentioned above, the Network node to which the verification request is sent in step 610 may be a Core Network node or may be a Verification node. In the case of the Core Network node, the Core Network node is a part of a communication network that has issued the subscription identifier, and the Network Access node may be a part of the same communication network or a different communication network. The Network Access node may hence be a part of a Visited network, with the Core Network node being part of the Home network for the device. If the Core Network node provides only an identification of a Verification node in response to the verification request, then the Network Access node may send a new verification request to the Verification node in order to obtain the device characteristic or parameter, before completing the method.
The method 600 may be implemented in different ways. For example, the Network Access node may receive from a Core Network node or a Verification node component elements of a permanent device identity, including for example a permanent device identifier and a device specific key, an expected MAC, an encrypted XRES, an encrypted RAND, etc. The Network Access node may send to the device a RAND or an encrypted RAND and may receive from the device a signature, a MAC, a RES, an encrypted RES etc. The nature of the check performed in step 670 may be determined by the nature of the parameters exchanged as discussed above. For example, the Network Access node may check, using the device public key, a signature generated by the device using its device private key, or may compare a MAC received from the device with a MAC received from the Network node or computed by the Network Access node in step 630 or 660. The Network Access node may alternatively compare an encrypted RES received from the device with an encrypted XRES or compare a RES received from the device with an XRES (for example if the Network Access node sent an encrypted RAND to the device). In the various different examples, the Network Access node performs some kind of comparison between a parameter received from the device and an expected value of such a parameter, and a cryptographic calculation using the bound characteristic is or has been performed on either the parameter that is sent to the device or the parameter that has been received from the device. The comparison enables the Network Access node to confirm that the device is in possession of the bound characteristic, for example because it was able to accurately decrypt an encrypted RAND and generate the correct RES, or because it has correctly encrypted RES, or correctly generated a MAC or signature.
Referring to
Referring to
In step 812, the Core Network node may send a verification request to a Verification node, the verification request comprising the subscription identifier received from the Network Access node. As illustrated at 812a, the verification request sent to the Verification node may further comprise a parameter (for example retrieved from a memory) and a request for the Verification node to perform a cryptographic calculation on the parameter using the device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. The parameter may for example be a parameter for inclusion in an Authentication Vector (AV) for the device, such as a RAND or XRES parameter.
In step 814, the Core Network node may receive a response from the Verification node, the response comprising at least one of:
The device characteristic bound to the subscription identifier may comprise component elements of a permanent device identity, including for example a permanent device identifier and a device specific key. The device specific key may be a device specific public key which is associated with a corresponding device specific private key, or may be a device specific symmetric key. The permanent device identity may be bound to the subscription identifier via its constituent permanent device identifier.
In step 816, the Core Network node may perform a cryptographic calculation on a parameter for sending to the Network Access node using the device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. The cryptographic calculation may for example be performed using the device specific key of the permanent device identity. This may be the case for example if the Verification node has returned the device characteristic rather than a parameter on which a cryptographic calculation has already been performed. As discussed above, performing a cryptographic calculation on a parameter using a characteristic of the device may comprise at least one of generating a MAC for the parameter using the characteristic and/or encrypting or decrypting the parameter using the characteristic.
As mentioned above, the parameter on which a cryptographic calculation is performed (by the Verification node or the Core Network node) may be retrieved by the Core Network node from a memory as being associated with the subscriber identifier presented by the device. Thus in an authentication procedure, the Core Network node may retrieve an appropriate RAND, XRES etc. for populating an Authentication Vector, and may then either encrypt such a parameter or calculate a MAC for such a parameter using a device characteristic returned by the Verification node, or may request this operation be performed by the Verification node, before sending the parameter to the Network Access node.
In step 820, the Core Network node sends a response to the Network Access node, the response comprising at least one of:
The identification of the Verification node from which either the device characteristic or parameter may be obtained may comprise a URI of the Verification node, which may be a URI received from the Verification node in step 802.
It will be appreciated that the performance of steps 802 and/or 812 to 816 may be dependent upon a particular implementation of the method. For example, if the Core Network node is configured to send an identification of a Verification node in the response at step 820, then the Core Network node may omit one or more of steps 812 to 816.
In step 920, the Verification node retrieves from a memory a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. The device characteristic may comprise component elements of a permanent device identity, including for example a permanent device identifier and a device specific key, where the device specific key may be a device specific public key which is associated with a corresponding device specific private key, or may be a device specific symmetric key. The permanent device identity may be bound to the subscription identifier via its permanent device identifier.
In step 930, the Verification node, may, in some examples, perform a cryptographic calculation on a parameter relating to the subscription identifier using the retrieved device characteristic. This parameter may be the parameter received with the verification request.
As discussed above, performing a cryptographic calculation on a parameter using a characteristic of the device may comprise at least one of generating a MAC for the parameter using the characteristic and/or encrypting or decrypting the parameter using the characteristic.
In step 940, the Verification node sends a response to the Network node, the response comprising at least one of the retrieved device characteristic, and/or a parameter on which a cryptographic calculation has been performed using the retrieved characteristic. The parameter on which the cryptographic calculation has been performed may be the parameter received in the verification request.
Referring to
In step 1020, the Verification node compares the received information about a characteristic to a device characteristic that has been bound to the subscription identifier presented by the device such that the subscription identifier is uniquely associated with the characteristic. In step 1030, responsive to a request for a result of the comparison, the Verification node send a result of the comparison to at least one of the Network Access node, a Core Network node and/or a Device Connection Service.
It will be appreciated that according to the method 1000, a direct comparison between a bound characteristic and a presented characteristic is performed at the Verification node. This comparison may be appropriate in examples in which a behavioural characteristic is bound to a subscription identifier. The Verification node may thus compare an expected location with an actual location (via cell identification) or any other expected with actual behaviour in accessing the network. In examples in which a permanent device identifier characteristic is bound to the subscription identifier, comparison between parameters may be carried out in the Network Access node, but this may not be a direct comparison between bound and presented characteristics, but rather a comparison of a parameter value presented by the device with an expected value for that parameter. The parameter exchange between the device, Network Access node, Core Network node and Verification node is such that the device will only have been able to obtain the correct value of the parameter sent to and compared by the Network Access node if it is in possession of the correct characteristic.
The method 1000 performed by the Verification node may be complimented by methods performed by a Core Network node and a Network Access node. For example, a Network Access node may forward connection information for a device to a DCS and the DCS may send that connection information to the Verification node. According to different examples, a Core Network node may according to different embodiments, register for monitoring of a connection by a device to the communication network. The Core Network node may request and receive a verification response from a Verification node relating to a connection by a device to the network. This may be the request that prompts the Verification node to send a result of its comparison to the Core Network node in step 1030 of the method 1000. The Core network node may alternatively send a Verification node URI to another network entity such as a Network Access node or DCS, so allowing those entities to request a verification result directly from the Verification node. In still further examples, the Core Network node may receive a report of a failed verification and suspected misuse of a subscription identifier, for example from a DCS that has contacted the Verification node, and forward the report to a Network Access node so that the Network Access node may block network access for the device.
Referring to
As described above, examples of the methods 300 to 1100 cooperate to enable the efficient detection of use of cloned credentials to access a network. A device characteristic is bound to a subscription identifier assigned to the device, and the binding is verified by ensuring that a device presenting the subscription identifier is in possession of the bound characteristic. A device that is not in possession of the bound characteristic may be prevented from accessing the network, if the verification is performed during an authentication procedure, or may have network access suspended or denied, if the verification is performed after authentication. The above described methods illustrate different options for binding and verification, according to whether the device characteristic that is bound to a subscription identifier is a permanent device identity, bound via its constituent permanent device identifier, or a behavioural characteristic. Each of these options is discussed in further detail below, with reference to example implementations of the methods illustrated via the message flow diagrams shown in
The example implementations illustrated in
As discussed above, the two options illustrated by
A device manufacturer of a UE registers device identities for the UE in a database (illustrated as DevDDB in
Specifically, the IMSI assigned to the device may be bound together with the permanent device identifier of the permanent device identity. The permanent device identifier is a piece of data that names or enumerates the identity credentials in the (name) space of all possible identifiers that are in use. As the device identity is not cloneable, and is uniquely associated with the IMSI, it is possible during, prior to, or after the authentication by the NAAF, to discover that the binding of the device identifier is not correct, or that during registration the IMSI appears again but with a different device identifier to be bound with. Such a re-binding can either be blocked or trigger a fraud alarm that temporarily blocks re-binding until proper authorisation is established and the previous registered device management owner grants permission for the re-binding to proceed. It will be appreciated that as the VS is under control of the MNO, it is always the MNO that takes the final decision to approve or disapprove the (re-binding), for example by providing a binding policy to the VS (as illustrated in step 150 of
Re-binding of a subscription identifier to a different device may be appropriate in a range of different circumstances relating to testing, handling of broken devices and repair. Legitimate rebinding use case may include:
In many circumstances, a re-binding will be authorised by a device owner and may also be authorised (double signed) by an operator. An unlock process may be used to unlock a temporarily blocked subscription in the event that a warning was triggered for a device that was not making fraudulent use of credentials.
During registration of the device in the device management system, illustrated at steps 120 to 290, the device is provided with a subscription by the MNO. This can be done in various ways, for example, using the Remote SIM Provisioning, RSP, protocol(s) as specified by the GSMA, illustrated at step 170. As illustrated in
Registration of the public key of the device management owner, which key can be used to check a signature accompanying a bind or re-bind instruction, step 100. Information to be passed to the VS is given to the HSS, step 110.
Registration in (remote) verification service (VS) of the pair IMSI and Permanent Device Identifier (PDI), step 240. The VS will only register a binding with this information if it is signed by the device manager, step 250. This device manager has previously registered the device in its system and organized a SIM credential for the device using existing or future procedures. Through binding of the PDI to the IMSI, the entire permanent device identity, including the PDI and the associated credential, is bound to the IMSI.
Locking of the binding against a new registration of same IMSI with another PDI, step 270.
If the binding is a rebinding, then the VS checks the incoming binding request for a confirmation of the rebinding.
The VS stores information regarding the binding (IMSI, IMEI, etc.) for later use as well as a device specific key DKey, step 290. In one example, DKey is the public key of the device identity, i.e. the public key associated with the PDI. In other examples, DKey may also be a symmetric key in order to fit with existing network authentication protocols and parameter lengths. However, DKey should be strongly linked to the PDI and may, for example, be securely derived from a device secret associated with the PDI. The derived key should then be established by an interaction between the VS and the UE or (less secure) a device database such as DevDDB where the secrets are available, and which can deliver the DKey. An example derivation of a symmetric DKey is described in detail below.
In
Binding verification can be performed in different ways, for example by the HSS, by the VS at attachment or by the VS after attachment. Binding verification by the VS may be automatically triggered when the device requests network access (for example through a DCS) or the NAAF (for example in an MME) can request binding verification by the VS. Binding verification may comprise checking that the authentication challenge response is encrypted using the DKey at the UE. The NAAF may compare the encrypted authentication challenge response to the expected (encrypted) response. In order to be able to do this, the NAAF may obtain the encrypted expected response from the HSS authentication vector or may obtain DKey (from the HSS or the VS) and encrypt the expected response. In another alternative, the UE may decrypt an encrypted rand challenge RAND during or after authentication. In this case, response verification by the NAAF against the expected response as delivered by the HSS implies that the device, in case of asymmetric keys being used, must have the correct private key associated with PDI and, in case of symmetric keys being used, must have correct DKey associated with PDI, and that the device therefore holds the correct subscribed credentials.
In some examples, the device and/or HSS may provide a MAC or digital signature to the NAAF, and hence to the visited network, as proof of the binding. If the NAAF is in a visited network, then only the home network knows that the subscription is associated with a device for which a VS service is available. In order to inform the NAAF of this fact, the home network (HSS) may push the URI of the VS to the NAAF together with the authentication information (AV) that the home network pushes to the visited network during an attach process. Alternatively, the home network may provide a public verification key that the visited network can use to verify the device signature. Further details of binding verification are provided below with reference to
Here the NAAF in the (visited) network expects the UE to deliver an extra field in a response of the AKA procedure, where this extra field is a digital signature (in the case of an asymmetric key pair associated with PDI where the private key is used to sign) or MAC (in the case a symmetric key associated with PDI where the symmetric key (DKey) is used in calculation of the MAC). The digital signature or MAC is computed on the random RAND in the AKA or the ordinary response RES. The NAAF can check this additional response field using information, from the VS or the HSS, about the correct device public key (in case of a signature) or the expected extra response field value (in case of a MAC). This option would be appropriate for situations in which the subscription credentials are traditional AKA type including EAP-AKA variants. This option may also be used in situations where network authentication is based on EAP-TLS as recently standardized for use in 5G systems. The are many possibilities of EAP-TLS exchanged data from device to network on which the signature or MAC may be computed, e.g. the resulting EMSK.
Another approach to verifying an explicit binding is to encrypt the random challenge value in the authentication procedure. The UE decrypts the encrypted random challenge and recovers the correct RAND to be used in the authentication procedure. The UE (or the SIM inside the UE) computes the authentication response which is sent to the NAAF.
Variant 1: In this variant, which covers two alternatives, there is no change required to an existing NAAF. In a first alternative, the HSS fetches from the VS a derived key DKey and uses this key to encrypt the RAND. The HSS provides the encrypted RAND to the NAAF in the AV and the NAAF sends this to the UE. The UE decrypts the RAND to obtain RAND such that normal AKA authentication can be performed. The NAAF may be unaware of passing on an encrypted RAND and may thus perform as specified for existing 3G, 4G and 5G networks. In a second alternative, the VS may perform the encryption of the RAND using DKey, the RAND having been provided to the VS by the HSS with a request for the VS to perform the encryption. The encrypted RAND may then be passed via the NAAF to the UE as in the first alternative. In both the above discussed alternatives, a device that uses a cloned subscription credential will not be in possession of or able to generate the same DKey as is used to encrypt the RAND (as it will not have the correct permanent device identity) and so will be unable to decrypt the RAND properly before passing it to the authentication procedures.
Variant 2: In this variant, which also covers two alternatives, changes to existing NAAFs are required. In a first alternative, RAND is encrypted using DKey by the NAAF, where DKey is obtained from VS. The UE decrypts the RAND to obtain RAND so that normal AKA authentication can be performed. In a second alternative, the VS performs encryption of RAND using DKey upon request from NAAF. This second alternative is illustrated in
Instead of encrypting the random challenge value in the authentication procedure to verify an explicit binding, it is possible to encrypt the expected result XRES. After computing the ordinary authentication response RES in the AKA procedure, the UE encrypts RES with a derived symmetric key (DKey). The NAAF has received the encrypted response as the expected response XRES (encrypted), or may encrypt a received XRES using an appropriate key. At the UE side this derived key is derived from the private key or secret key associated with PDI. For example, this derivation may include parameters about the MME the NAAF is associated with (for example string “MME-MNO-name”) and the RAND in the authentication challenge the NAAF sends to the UE. The NAAF may obtain via the MME the derived key from either the VS or the HSS. The VS may also perform encryption of XRES using DKey upon request from the NAAF where the NAAF provides the XRES (that it obtained from HSS). It will be appreciated that the VS and HSS are supposed to have authenticated the MME and know the proper MME parameters in accordance with an agreement that allows the MME to access the VS or HSS services. If the NAAF is provided with an encrypted XRES, then the verification of the binding may be transparent to the NAAF, as the NAAF performs its usual comparison of RES and XRES values without knowledge that these values are encrypted. This variant is illustrated in
Another approach to verifying an explicit binding is to perform a post authentication challenge-response flow. According to this approach, the UE proves possession of PDI associated private/secret key upon request. This may typically involve the UE signing a parameter using the PDI associated key. The parameter may be a challenge (which may be the RAND used in latest authentication or a new random value sent to the UE) and may involve the IMSI value. This approach is illustrated in
In some of the examples above illustrated by
DKey=KDF(device secret, H=hash (‘UE RANDOM’ concatenated with ‘VS parameters’))
Where KDF and hash are a key derivation functions such as HKDF, as specified by IETF in RFC 5869, and cryptographic hash function, respectively. Examples of suitable hash functions include SHA256 or SHA3. The random value UE RANDOM and VS parameters may be used to ensure that different VSs get different DKeys and that for a new registration a new DKey will be used. It may be assumed that the UE stores the hash result H so it later can re-derive DKey. The random value UE RANDOM is generated by the UE to ensure that a dishonest VS cannot obtain a derived key that another VS has legitimately obtained. VS parameters can be for example the name of the VS or its DNS address or a date, tax/vat number, etc.
In some examples, if there are circumstances that mean using the device private key directly is less favourable, it is possible to generate a key automatically based on MNO characteristics. The same procedure as a Trusted Platform Module (TPM) can regenerate a public-private pair using an internal (secret) seed and an external random value.
Binding and verification of binding using a behavioural characteristic are illustrated in
Binding during device registration is illustrated in
As discussed above with reference to
Binding verification in the case of a behavioural characteristic may also be achieved in arrange of different ways, and three alternatives are illustrated in
In another alternative, illustrated in
In another alternative, illustrated in
In some examples, the processor or processing circuitry 1502, 1602, 1702, 1802, 1902 described above may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 1502, 1602, 1702, 1802, 1902 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory 1504, 1604, 1704, 1804, 1904 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive etc.
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
It will be appreciated that examples of the present disclosure may be virtualised, such that the nodes described herein may be instantiated across one or more virtual nodes in a cloud environment, and the methods and processes described herein may be run in a cloud environment.
Aspects of the present disclosure thus provide methods and nodes performing such methods that enable the binding of one or more characteristics associated with a device to a subscription identifier assigned to the device. The one or more characteristics may include a permanent device identifier and/or device behavior in the network. Examples of the methods and nodes herein also enable efficient verification that a device seeking to connect or connected to the network is in possession of the device characteristic that is bound to the subscription identifier presented by the device. A device failing to demonstrate possession of a bound characteristic may be refused access to the network. Control over network access is no longer entirely coupled to the hardware and procedural security of the (e)UICC. Aspects of the present disclosure thus offer more cost effective iUICC solutions, mitigating the risk associated with introducing subscription credential storage solutions in devices that have higher risk of compromise that could lead to subscription fraud. In addition, examples of the present disclosure support effective binding and rebinding procedures for device and subscription credentials, giving device owners better assurance that acquired subscription credentials only can be used for their devices, and supporting a range of use cases including testing and replacement of devices.
The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.
It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2019/082879 | 11/28/2019 | WO |
