Technical Field

The present disclosure relates to apparatus, methods and systems for obtaining security data relating to a telecommunications connection and/or controlling the bearer security of a telecommunications connection.

Background

Legacy 2G bearer security can present a security weakness for telecommunications devices operating on GSM (Global System for Mobile Communications) or GPRS (General Packet Radio Service). Use of null encryption (A5/0, GEA/0) or old, weak encryption (A5/2, A5/1 or GEA1/GEA2) exposes data traffic to interception risks and the risk of "hijacking" by false base stations. If such a false base station can persuade a device to connect to it (rather than the real network), then an attacker may be able to read data in transit from or to the device, or send malicious packets to damage or take control of the device. This may represent a security risk for Machine-to-Machine (M2M) devices, many of which run on GSM or GPRS.

A number of network operators now support GEA3, which is a stronger GPRS encryption algorithm, and some also utilise the A5/3 encryption algorithm. However, it can be difficult, or sometimes impossible, for devices and service providers to tell whether those stronger security algorithms are being used, or to detect occasions where they are not used (which may represent potential attack vulnerabilities). In particular, where a device is subscribed to a particular service provider, but is connected on a GSM connection on a visited network, the service provider may not be able to determine if A5/3 or GEA3 encryption algorithms are in use since that information may be held in the visited network and not disclosed to the home network.

Even if a security weakness is detected, it is not always clear what countermeasures could or should be deployed. For example, should the device unilaterally detach from a weakly secured (nor not secured) GSM connection; should it attempt to select an alternative base station (perhaps with poorer signal strength), an alternative network operator or select a 3G connection? What happens if it can't find a better base station/network operator/connection? It may be preferable for a number of different device types, for example, low power M2M devices, to support enhanced bearer security (ideally terminating deep within the core network, and preferably the home network), rather than having the device and service negotiate "over-the-top" security - that is, additional security implemented at a different layer in the protocol stack, such as network, transport or application layer. However, this may require the device or service being able to tell whether enhanced bearer security is in place, or if it is as secure as desired (for example, what algorithms are in force), or if the end-points are satisfactory. As explained above, this may be very difficult, if not impossible.

Faced with these unknowns, the service provider may be forced to make a pessimistic assumption that because bearer security is unknown or unpredictable, it is also unreliable. The service provider may therefore provide "over-the-top" security anyway. Conversely, a service provider may have a policy of providing "over-the-top" security, regardless of the bearer security. Operating both "over-the-top" security and enhanced bearer security makes the enhanced bearer security irrelevant and results in an increased consumption of device battery power, which may be particularly significant for low-power M2M devices. Similar issues may arise in 5G communications (still under development at the time of filing), for which a number of ultra-low-latency services are currently proposed, such as automated vehicle control, control of manufacturing equipment, remote surgery, highly realistic VR, realtime gaming, etc. Low latency services may be compromised by "over-the-top" security, which might involve complex handshakes, certificate exchanges, etc. In view of this, it may be desirable to use bearer security provided the secure is strong enough and the end-points are safely located. However, again, it can be difficult for the device or service provider to know if the bearer security is sufficiently strong and "over-the-top" security may therefore be provided just in case the bearer security is insufficient. Alternatively, to avoid potentially unreliable bearer security on 2G connections, a device may be required to connect to 3G or 4G, with the expectation that 3G security is always strong on a given operator (for example, that an operator always has strong encryption switched on for 3G/4G). However, this will have implications of limited coverage. "Maps" of GSM security have been developed (for example, https://gsmmao.org/), which may help service providers (for example Vodafone GDSP - Global Data Service Platform) to make decisions about which operator to select when roaming in different parts of the world. However, these maps are fairly crude and cannot easily be used to spot exceptional behaviour (which may indicate a false base station attack, for example).

Furthermore, some custom basebands and software applications (for example,

http://bb.osmocom.org/trac/wiki/Hardware/Phones) are provided for (rooted) consumer devices (for example, Android) to detect when ciphering is in place, and which algorithm is used. Indeed, such devices may be the source of information for the above maps.

However, there is little desire among device manufacturers to root their device simply to obtain this low level information, so device support for this is limited.

In summary, it may be preferable to provide only bearer security or only "over-the-top" security, depending on the device type, the service requirements and the service provider policy, whilst still being sure of the level of security being provided and without restricting the coverage available to the device.

Summary

The present disclosure provides a device management client for operation in a terminal (such as a UE or M2M device), wherein the device management client is configured to: interrogate a device baseband of the terminal to determine security data relating to a communications connection between the terminal and a telecommunications network, wherein the communications connection is carried by a telecommunications bearer and is secured using bearer security, and wherein the security data comprises the security settings for one or more security parameters for defining the security of the communications connection; and determine a device security action to be carried out by the terminal in consideration of the determined security data and a security policy.

The security policy may be indicative of: one or more required security settings for at least one of the said one or more security parameters; and at least one device security action to be carried out if the said one or more security parameters does not satisfy its corresponding required security setting.

The security policy may be indicative of a first device security action and a second device security action, wherein the first device security action is to be carried out if the said one or more security parameters does not satisfy its corresponding required security setting (for example, if the one or more of the security parameters in the security data has a setting that does not meet the requirements set out in the security policy); and the second device security action is to be carried out if the first device security action could not successfully be completed within a period of time (for example, if the first device security action is 'find a new communications bearer', but none are available to the terminal within the predetermined period, the device management client will carry out the second device security action, such as 'break the communications connection'). Preferably, the device management client is configured to: interface with a device

management entity (for example, a device management server) via a device management interface; and obtain the security policy from the device management entity via the device management interface. Further preferably, the device management interface is a secured interface (i.e., allows secure communications between the device management client and the device management entity), secured, for example, according to the GBA protocol, or any other suitable security mechanism/protocol. The device management client may be further configured to: communicate a security report to the device management entity via the device management interface, wherein the security report comprises at least part of the determined security data.

Preferably, the device management client is configured to interrogate the device baseband using an application programming interface provided by the device baseband.

The security data may comprise the security settings for at least one of the following security parameters: ciphering status of the communications connection; integrity protection status of the communications connection; encryption algorithm and encryption key length used for the communications connection; time of most recent encryption key refresh; security protocol used to establish encryption keys; identity of an end-point of a security association of the communications connection; identity claimed by an end-point of a security association of the communications connection; level of the stack at which a security association of the communications connection was established; and/or identifier of a security association of the communications connection.

The device security action may comprise at least one of: maintain the communications connection; break the communications connection; break the communications connection and establish a new communications connection; select a different telecommunications bearer for the communications connection; and/or select a different telecommunications network for the communications connection.

Optionally, the device security action comprises one of: communicate to the device baseband a security request, the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter. In this way, the device management client may make changes to the level of bearer security used for the existing communications connection in order to bring the level of security up to the standards required by the security policy.

The security request may comprise at least one of: a request for ciphering to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for integrity protection to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack.

Optionally, the security request may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings.

The device management client may be further configured to: receive a security response from the device baseband in response to the security request, the security response comprising information identifying the security settings applied to at least one of the security parameters. In this way, the device management client may obtain feedback for whether or not the requested security settings have successfully been applied to the security

parameters.

The communications bearer may be a 2G bearer (for example , GSM, GPRS or EDGE) a 3G bearer (for example UMTS), a 4G bearer (for example, LTE), a 5G bearer or a Cellular loT bearer. It will be appreciated that this is a non-limiting list of potential communications bearers and the present disclosure has the potential to be applied to bearers operating in accordance with other telecommunications standards.

The present disclosure also provides a software program (for example, a non-transitory computer readable medium, a set of computer readable instructions, etc) comprising the device management client provided above. The software program may be configured such that, when executed on a processor (for example, a microprocessor or any other form of logic) of the terminal, the functionality of the device management client described is performed.

The present disclosure also provides a device baseband for operation in a terminal (for example, a UE or M2M device), the device baseband being configured to: receive from a device management client operating in the terminal a request for the current settings of one or more security parameters defining the security of a communications connection between the terminal and a telecommunications network, wherein the communications connection is carried by a telecommunications bearer and is secured using bearer security; and communicate to the device management client the current settings of at least one of the said one or more security parameters.

Preferably, the device baseband is configured to: provide an application programming interface for receiving the request for the current settings of one or more security

parameters.

The one or more security parameters may comprise at least one of: ciphering status of the communications connection; integrity protection status of the communications connection; encryption algorithm and encryption key length used for the communications connection; time of most recent encryption key refresh; security protocol used to establish encryption keys; identity of an end-point of a security association of the communications connection; identity claimed by an end-point of a security association of the communications connection; level of the stack at which a security association of the communications connection was established; and/or identifier of a security association of the communications connection.

The device baseband may be further configured to: receive from the device management client a security request, the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter. The security request may comprise at least one of: a request for ciphering to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for integrity protection to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack.

The security request may comprise at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings. Optionally, the device baseband is further configured to: communicate to the

telecommunications network a security demand comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter, wherein the security demand is based at least in part on the security request received from the device management client; and communicate to the device management client the settings applied by the telecommunications network to at least one of the said one or more security parameters in response to the security demand. This communication with the

telecommunications network may require a change or modification to existing standards. It is not within the scope of this disclosure to suggest how those changes may be

implemented, and the nature of the changes is likely to depend at least on the standards to which they are applied. Nevertheless, the skilled person will appreciate that the functionality of the device baseband may be accommodated with any suitable changes or modifications to the existing standards. Likewise, this communication with the telecommunications network accommodated within any standards still underdevelopment (for example, 5G standards), or any other future standards, in any suitable way.

The security demand may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings. The communications bearer may be a 2G bearer (for example , GSM, GPRS or EDGE) a 3G bearer (for example UMTS), a 4G bearer (for example, LTE), a 5G bearer or a Cellular loT bearer. It will be appreciated that this is a non-limiting list of potential communications bearers and the present disclosure has the potential to be applied to bearers operating in accordance with other telecommunications standards.

The present disclosure also provides a software program (for example, a non-transitory computer readable medium, a set of computer readable instructions, etc) comprising the above disclosed device baseband. The software program may be configured such that, when executed on a processor (for example, a microprocessor or any other form of logic) of the terminal, the functionality of the device baseband provided above is performed.

Optionally, the device baseband may be provided as a patch to an existing baseband module.

The present disclosure also provides a terminal (for example, a UE or M2M device) configured to interface with a telecommunications network (for example, a serving network) via a communications connection, the terminal comprising at least one of: the device management client provided above; and/or the device baseband provided above. The terminal may comprise a processor (for example, a microprocessor, or any other form of logic) and memory, together configured to implement the device management client and/or device baseband provided above.

The present disclosure also provides a device management entity (for example, a device management server) for interfacing with a terminal (for example, interfacing with a DM client of a UE or M2M device), the terminal having a communications connection with a telecommunications network, wherein the communications connection is carried by a telecommunications bearer (such as a 2G, 3G, 4G, 5G or cellular loT) and is secured using bearer security, the device management entity being configured to: communicate a security policy to the terminal via a device management interface between the terminal and device management entity, wherein the security policy is for use by the terminal in determining a device security action to be carried out by the terminal in consideration of security data relating to the communications connection .

The security data may comprise the settings for one or more security parameters for defining the security of the communications connection, and wherein the security policy is indicative of: one or more required security settings for at least one of the said one or more security parameters; and at least one device security action to be carried out if the said one or more security parameters does not satisfy its corresponding required security setting.

The security policy may be indicative of a first device security action and a second device security action, wherein the first device security action is to be carried out if the said one or more security parameters does not satisfy its corresponding required security setting; and the second device security action is to be carried out if the first device security action could not successfully be completed within a period of time: The security policy may be indicative of at least one contingency device security action to be taken by the terminal if the terminal can no longer communicate with the device

management entity via the device management interface. The device management entity may be further configured to receive a security report from the terminal via the device management interface, wherein the security report comprises at least part of the security data determined by the device management client. The security policy may be determined by the device management entity based at least in part on the security report.

Preferably, the device management is further configured to communicate the security policy to the terminal after receiving the security report from the terminal.

The device management entity may further comprise a service interface with a service provider entity, the device management entity being further configured to: compile aggregate reports and/or anomaly reports based at least in part on security reports received from one or more terminals; and communicate the aggregate reports and/or anomaly reports to the service provider entity. The present disclosure also provides a system comprising the terminal provided above and the device management entity provided above, wherein the terminal interfaces with the device management entity via a device management interface.

The present disclosure also provides a method of determining a security action to be taken by a terminal, wherein the terminal interfaces with a telecommunications network via a communications connection that is carried by a telecommunications bearer and is secured using bearer security, and wherein the terminal comprises a device management client, the method comprising: the device management client interrogating a device baseband of the terminal to determine security data relating to the communications connection, wherein the security data comprises one or more security parameters defining the security of the communications connection; communicating a security policy from a device management entity to the device management client via a device management interface; the device management client determining a device security action in consideration of at least the determined security data and the security policy; and the device management client performing the determined device security action. The present disclosure also provides a terminal (for example, a UE or M2M device) for communicating with a telecommunications network entity (for example, a security end-point network entity, such as an eNode B, SGSN, RNC, MME or HSE) via a communications connection, the communications connection being carried by a telecommunications bearer and secured using bearer security, the terminal being configured to: communicate to the telecommunications network entity a security demand comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter of the communications connection, wherein the security parameter defines an aspect of the security of the communications connection.

The security demand may comprise at least one of: a request for ciphering to be turned on; a request for integrity protection to be turned on; a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack. The security demand may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings.

The present disclosure also provides a telecommunications network entity (for example, an eNode B, SGSN, RNC, MME or HSE) for interfacing with a terminal (for example, a UE or M2M device) via a communications connection, the communications connection being carried by a telecommunications bearer and secured using bearer security, the

telecommunications network entity being configured to: receive from the terminal a security demand comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter of the communications connection, wherein the security parameter defines an aspect of the security of the communications connection; and if at least one of the requested particular security settings can be applied to the corresponding security parameter, apply the requested security setting to the corresponding security parameter.

Optionally, the security demand may comprise at least one request for at least two particular security settings to be applied to a corresponding security parameter and an order of preference for the at least two particular security settings, the telecommunications network entity being further configured to: if two or more of the requested particular security settings can be applied to the corresponding security parameter, apply the most preferable security setting to the corresponding security parameter; and if only one of the request particular security settings can be applied to the corresponding security parameter, apply that particular security setting to the corresponding security parameter.

The present disclosure also provides a system comprising: the terminal provided above and the telecommunications network entity provided above, wherein the terminal interfaces with the telecommunications entity via the communications connection.

The present disclosure also provides a method of controlling the bearer security of a communications connection between a terminal (for example a UE or an M2M device) and a serving network, the method comprising: communication from the terminal to a

telecommunications network entity (for example, an eNode B, SGSN, RNC, MME or HSE) in the serving network a security demand comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter of the communications connection, wherein the security parameter defines an aspect of the security of the communications connection; and if at least one of the requested particular security settings can be applied to the corresponding security parameter, the

telecommunications network entity applying the requested security setting to the

corresponding security parameter.

The present disclosure also provides a security end-point network entity (for example an eNode B, SGSN, RNC, MME or HSE ) in communication with a terminal via a

communications connection, the security end-point network entity being configured to:

receive a request for an indication of the settings of one or more security parameters relating to the communications connection from a further entity (for example, a further networked entity, such as a home network entity and/or a device management entity, etc); and provide an indication of the settings of at least one of the said one or more security parameters to the further entity.

The security end-point network entity may be further configured to: check that the further entity is authorised to receive the settings of at least one of the said one or more security parameters; and provide the indication of the settings of at least one of the said one or more security parameters to the further entity only if the further entity is authorised. The at least one security parameter may comprise at least one of: ciphering status of the communications connection; integrity protection status of the communications connection; encryption algorithm and encryption key length used for the communications connection; time of most recent encryption key refresh; security protocol used to establish encryption keys; identity of an end-point of a security association of the communications connection; identity claimed by an end-point of a security association of the communications connection; level of the stack at which a security association of the communications connection was established; and/or identifier of a security association of the communications connection. The security end-point network entity may be further configured to: receive a security request from the further entity, the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter.

The security request comprises at least one of: a request for ciphering to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for integrity protection to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack.

The security end-point network entity may be further configured to: if at least one of the requested particular security settings can be applied to the corresponding security parameter, apply the requested security setting to the corresponding security parameter.

The security request may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings. The security end-point network entity may be further configured to: if two or more of the requested particular security settings can be applied to the corresponding security parameter, apply the most preferable security setting to the corresponding security parameter; and if only one of the request particular security settings can be applied to the corresponding security parameter, apply that particular security setting to the corresponding security parameter The security end-point network entity may be further configured to provide an application programming interface for receiving the request for an indication of the settings of one or more security parameters.

The security end-point network entity may be configured to operate in accordance with any of the 2G, 3G, 4G, 5G or Cellular loT standards. It will be appreciated that this is a non- limiting list of potential communications bearers and the present disclosure has the potential to be applied to bearers operating in accordance with other telecommunications standards.

The present disclosure also provides a network entity (for example, a home network entity and/or a DM entity, etc) for interfacing with a security end-point network entity (for example, an eNode B, SGSN, RNC, MME or HSE), the network entity being configured to: interrogate the security end-point network entity to determine security data relating to a communications connection between the terminal and the security end-point network entity, wherein the communications connection is carried by a telecommunications bearer and is secured using bearer security, and wherein the security data comprises one or more security parameters defining the security of the communications connection.

The network entity may be further configured to interrogate the security end-point network entity using an application programming interface provided by the security end-point network entity.

The security data may comprise at least one of the following security parameters: ciphering status of the communications connection; integrity protection status of the communications connection; encryption algorithm and encryption key length used for the communications connection; time of most recent encryption key refresh; security protocol used to establish encryption keys; identity of an end-point of a security association of the communications connection; identity claimed by an end-point of a security association of the communications connection; level of the stack at which a security association of the communications connection was established; and/or identifier of a security association of the communications connection. The network entity may be further configured to communicate to the security end-point network entity a security request, the security request comprising at least one request for at least one particular security setting for a corresponding security parameter. The security request may comprise at least one of: a request for ciphering to be turned on or off; a request for integrity protection to be turned on or off; a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack.

The security request may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings.

The network entity may be a home network entity and/or a device management entity. The present disclosure also provides a system comprising: the security end-point network entity provided above; and the network entity provided above, wherein the security end-point network entity and the network entity are interfaced with one another.

The present disclosure also provides a method of setting a security level for a

communications connection between a terminal (for example, a UE or M2M device) and a security end-point network entity (for example, an eNode B, SGSN, RNC, MME or HSE), wherein the communications connection is carried by a telecommunications bearer and is secured using bearer security, the method comprising: a network entity (such as a home network entity and/or a DM entity) interrogating the security end-point network entity to determine security data relating to the communications connection, wherein the security data comprises one or more security parameters defining the security of the communications connection; and the network entity communicating a security request to the security end- point network entity, the security request being determined, at least in part, in consideration of the security data, and the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter. The present disclosure also provides a device management client for operation in a terminal (for example, a UE or M2M device), wherein the device management client is configured to: obtain the security policy (for example, by receiving it from a DM entity, or by

requesting/retrieving it from a DM entity), the security policy being indicative of at least one device security action to be carried out by the terminal; and determine, from at least the security policy, the device security action to be carried out by the terminal .

In this instance, the device management client need not necessarily have interrogated the device baseband to determine security data. Instead, the security policy may simply comprise one or more device security actions to be taken by the device, which may be effective where a security attack is in progress and the terminal should take immediate action without having to determine the security data. Determining the device security action from the security policy alone may even be useful where the device management client has determined security data, as it may enable the device management client to take action more quickly, thereby responding to an attack more quickly.

The device security action comprises at least one of: maintain the communications connection; break the communications connection; break the communications connection and establish a new communications connection; select a different telecommunications bearer for the communications connection; and/or select a different telecommunications network for the communications connection.

The device management client may be further configured to: interface with a device management entity via a device management interface; and obtain the security policy from the device management entity via the device management interface (for example, by receiving it from the device management entity without prompting, or by requesting it from the device management entity, optionally at the same time as sending a security report).

The device management client may be further configured to: interrogate a device baseband of the terminal to determine security data relating to a communications connection between the terminal and a telecommunications network, wherein the communications connection is carried by a telecommunications bearer and is secured using bearer security, and wherein the security data comprises one or more security parameters for defining the security of the communications connection.

The security data may comprise at least one of the following security parameters: ciphering status of the communications connection; integrity protection status of the communications connection; encryption algorithm and encryption key length used for the communications connection; time of most recent encryption key refresh; security protocol used to establish encryption keys; identity of an end-point of a security association of the communications connection; identity claimed by an end-point of a security association of the communications connection; level of the stack at which a security association of the communications connection was established; and/or identifier of a security association of the communications connection.

The device management client may be further configured to: interface with a device management entity via a device management interface; and communicate a security report to the device management entity via the device management interface, wherein the security report comprises at least part of the determined security data. Consequently, the device management entity may identify from the security report an attack or anomaly and communicate a security policy to the device management client that instructs the device management client to take immediate device security actions.

The device management client may be further configured to: communicate to a device baseband of the terminal a security request as part of the device security action, the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter that defines at least part of the security of the communications connection.

The security request may comprise at least one of: a request for ciphering to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for integrity protection to be turned on or off (for example, turned on in order to increase the level of security provided by the bearer security, or turned off in order to reduce overheads etc, such as when "over-the-top" security is being used); a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack. The security request may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings. The device management client may be further configured to: receive a security response from the device baseband in response to the security request, the security response comprising information identifying the security settings applied to at least one of the security parameters. The communications bearer may be any of a 2G bearer, a 3G bearer, a 4G bearer, a 5G bearer or a Cellular loT bearer. It will be appreciated that this is a non-limiting list of potential communications bearers and the present disclosure has the potential to be applied to bearers operating in accordance with other telecommunications standards. The present disclosure also provides a software program comprising the device

management client provided above.

The present disclosure also provides a security end-point network entity (for example, an eNode B, SGSN, RNC, MME or HSE) in communication with a terminal (for example, a UE or M2M device) via a communications connection, the security end-point network entity being configured to: receive a security request from a further entity (for example, a home network entity and/or a DM entity), the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter that defines at least part of the security of the communications connection; and if at least one of the requested particular security settings can be applied to the corresponding security parameter, apply the requested security setting to the corresponding security parameter.

In this way, the security end-point network entity may allow for security requests from the further network entity to be accepted without also allowing for the current setting of the security parameters to be interrogated.

The security request may comprise at least one of: a request for ciphering to be turned on or off; a request for integrity protection to be turned on or off; a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack.

The security request may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings.

The security end-point network entity may be further configured to: if two or more of the requested particular security settings can be applied to the corresponding security parameter, apply the most preferable security setting to the corresponding security parameter; and if only one of the request particular security settings can be applied to the corresponding security parameter, apply that particular security setting to the corresponding security parameter The security end-point network entity may be further configured to: provide an application programming interface for receiving the security request to apply settings of one or more security parameters.

The security end-point network entity may be configured to operate in accordance with any of the 2G, 3G, 4G, 5G or Cellular loT standards. It will be appreciated that this is a non- limiting list of potential communications bearers and the present disclosure has the potential to be applied to bearers operating in accordance with other telecommunications standards.

The present disclosure also provides a network entity (for example, a home network entity and/or DM entity) for interfacing with a security end-point network entity (for example, an eNode B, SGSN, RNC, MME or HSE), the network entity being configured to: communicate to the security end-point network entity a security request, the security request comprising at least one request for at least one particular security setting for a corresponding security parameter that defines at least part of the security of the communications connection.

In this way, the network entity may request a change to security settings without first having to interrogate the security end-point network entity in order to determine security data. This may allow the network entity to respond more quickly to attacks and rapidly enact any changes to the security settings that it deems appropriate, regardless of what the current security settings are. The security request comprises at least one of: a request for ciphering to be turned on or off; a request for integrity protection to be turned on or off; a request for one or more particular encryption algorithms to be used; a request for one or more particular encryption key lengths to be used; a request for a maximum allowable key refresh time to be enforced; a request for one or more particular security protocols to be used to establish encryption keys; a request to use one or more particular end-points of a security association of the communications connection; and/or a request to establish a security association of the communications connection at one or more particular levels of the stack. The security request may comprise: at least one request for at least two particular security settings to be applied to a corresponding security parameter, and an order of preference for the at least two particular security settings.

The network entity may be a home network entity and/or a device management entity.

The network entity may be configured to operate in accordance with any of the 2G, 3G, 4G, 5G or Cellular loT standards. It will be appreciated that this is a non-limiting list of potential communications bearers and the present disclosure has the potential to be applied to bearers operating in accordance with other telecommunications standards.

The present disclosure also provides a system comprising: the above provided security end- point network entity; and the above provided network entity, wherein the security end-point network entity and the network entity are interfaced with one another. The present disclosure also provides a method of setting a security level for a

communications connection between a terminal (for example, a UE or M2M device) and a security end-point network entity (for example, an eNode B, SGSN, RNC, MME or HSE), wherein the communications connection is carried by a telecommunications bearer and is secured using bearer security, the method comprising: the network entity communicating a security request to the security end-point network entity, the security request comprising at least one request for at least one particular security setting to be applied to a corresponding security parameter defining at least part of the security of the communications connection. This method may allow rapid reactions to security threats/attacks, where security settings that should help to address the threat/attack may be rapidly requested without time needing to be taken to determine what the current security settings actually are.

Drawings Aspects of the present disclosure are described, by way of example only, with reference to the following drawings, in which:

Figure 1 shows a representation of a system 100 comprising a terminal 10 and device management server 20 configured in accordance with a first aspect of the present disclosure;

Figure 2 shows a representation of a system 200 comprising a terminal 10, a device management server 20 and a serving network 30 in accordance with a second aspect of the present disclosure;

Figure 3 shows a representation of a system 300 comprising a serving network 320 and a home network 330 configured in accordance with a third aspect of the present disclosure; Figure 4 shows a representation of a system 400 comprising a serving network 320 and a home network 330 configured in accordance with a third aspect of the present disclosure; and

Figure 5 shows a representation of a system 500 comprising a serving network 320 and a home network 330 configured in accordance with a third aspect of the present disclosure;

It should be noted that the drawings are highly schematic and are illustrated for simplicity.

Detailed Description

Figure 1 shows a highly schematic representation of a system 100 comprising a terminal 10, a device management (DM) entity 20, a serving network 30 and a service provider entity 40.

The terminal 10 comprises a device management client 12 and a device communications module/baseband 14. The terminal 10 may be any form of telecommunications device capable of interfacing with the serving telecommunications network 30 via a communications connection 35 (as explained in more detail below). For example, the terminal 10 may be a UE (user equipment), such as a mobile telephone, a smartphone, a tablet computer, etc or an M2M device. An M2M device may be any device wherein at least part of the device communications operations are autonomous (i.e., do not require user or operator interaction). For example, an M2M device may be a smart meter that provides utility meter readings autonomously to utility providers via the communications connection 35, or a vehicle control module that autonomously provides sensor readings to a vehicle servicing company via the

communications connection 35. The device management client 12 may be implemented in the application layer of the terminal 10 and may be implemented, for example, as a computer program (for example, one or more computer-readable media) comprising computer readable instructions, or as programmable logic, firmware or a configurable system. The device management client 12 may be implemented in the terminal 10 at the time of manufacture of the terminal 10, or it may be implemented in the terminal 10 at a later date, for example as part of subsequent software provisioning, or a software update, or a firmware update, etc.

The device communications module/baseband 14 (referred to from here on as "baseband") is a module or a collection of modules for handling the terminal side of the communications connection 35, specifically for handling the lower layers of the protocol stack within any given wireless telecommunications standard. It is typically located in the DSP/modulation and coding layer of the terminal 10 and may be configured to handle communication bearers according to any one or more communications standards, such as at least one of 2G (for example, GSM, EDGE or GPRS), 3G (for example, UTMS), 4G, 5G, Cellular loT. The communications connection 35 is secured at least in part using bearer security (for example, A5/0, A5/1 , A5/2, GEA/o, GEA/1 or GEA/2) associated with the communications bearer used for the communications connection 35. The serving network 30 comprises a base station 32 that may be any form of base station, for example a base transceiver station (BTS), a Node B, an eNode B, etc. Communications between the serving network 30 may take place via the communications connection 35 using any suitable communications bearer, for example 2G (GSM, EDGE or GPRS), 3G (for example, UTMS), 4G, 5G, Cellular loT, etc.

In a first aspect of the present disclosure, the baseband 14 is provided with a privileged API 16, which enables the DM client 12 to interrogate the baseband 14 to determine what bearer security is in force on the current communications interface 35. The skilled person will appreciated that the privileged API 16 may be implemented in any suitable way, using any suitable protocols and instructions (for example, "read" instructions), according to the implementation of the DM client 12 and/or the baseband 14 (for example, depending on the manufacturer(s) of any hardware (for example, chips sets) associated with the baseband 14 and/or the communications bearer(s) handled by the baseband 14, etc) and, as such, specific example API configurations are not the subject of this application.

The privileged API 16 may be pre-installed on the terminal 10 (i.e., incorporated at the time of device manufacture), or may be installed in-the-field, for example using secure device management (such as delivery or patch of a custom baseband). By interrogating the baseband 14, the DM client 12 can determine from the baseband 14 security data relating to the communications connection 35. The security data may comprise one or more security parameters that can define the bearer security of the communications connection 35. The security parameters may include any one or more of the following:

• Ciphering status (i.e., is ciphering switched on or off?)

• Integrity protection status (i.e., is integrity protection switched on or off?);

• Encryption algorithm and encryption key length used (i.e., what algorithms and key lengths are being used?);

• Time of most recent encryption key refresh (i.e., when were the keys last

refreshed?);

• Security protocol used to establish encryption keys (i.e., what security protocol was used to establish the keys - 2G, 3G, 4G or 5G security, or enhanced Cellular loT security?);

• Identification of a network side end-point of the communications connection 35 (i.e., what is the end-point of the security association - base station, SGSN, RNC, eNodeB, Home eNodeB, MME, Home Network, other?);

• Identity claimed by a network side end-point of the communications connection 35 (i.e., what identity does the end-point claim?);

• Level of the stack at which a security association of the communications connection 35 was established (i.e., at what level of the stack - for example PHY, MAC, PDCP, IP/Network, Transport, etc - is the security association established? This may be of particular relevance for Cellular loT or 5G, where the stack level might need to vary depending on the use case); and/or

• identifier of a security association of the communications connection 35 (for example, a unique identifier of the security association, such as an identifier based on a digest of the keys and of all the settings reported above. This may enable the DM client 12 more easily to detect changes to the security of the communications connection 35).

Each of these security parameters may have a setting (or an argument). For example, "ciphering status of the communications interface" may be a security parameter, and "on" and "off" may be the possible settings for that security parameter. Likewise, "security protocol used to establish encryption keys" may be a security parameter, and "2G", "3G", "4G", "5G" and "enhanced Cellular loT security" may be the possible settings for that security parameter. Whilst the security data may comprise only one of the security parameters identified above, preferably the security data will comprise more than one security parameter, with a greater number of security parameters generally providing a more accurate indication of the level of security of the communication connection 35. Figure 1 shows step (a) of an example process of the terminal 10 effecting control over the security of the communications connection 35 according to a security policy according to an aspect of the present disclosure. In step (a), the DM client 12 interrogates the baseband 14 via the privileged API 16 to determine security data in accordance with the explanation above.

Having determined the security data, the DM client 12 may prepare a security report, comprising at least part of the determined security data. The security report may optionally also comprise any other useful information, for example an identifier of the terminal 10, the geographic location of the terminal 10, etc. In step (b), the security report is communicated to the DM entity 20 via the device management interface 25.

The DM entity 20 may be any type of DM entity, for example a DM server, or a DM software or hardware module within larger server or collection of servers, and the device

management interface 25 may take any suitable form and utilise any suitable protocols for enabling communication between the DM entity 20 and the DM client 12. Preferably, the device management interface 25 will be a secure interface to prevent an attacker who has compromised the bearer security of the communications connection 35 from reading and/or tampering with the security report. The device management interface 25 may be secured in any suitable way, for example by using Generic Bootstrapping Architecture (GBA) in accordance with 3GPP TS 33.220. In this example, the terminal 10 may further comprise, for example, a Universal Integrated Circuit Card (UlCC), or SIM card, for use in securing the device management interface 25 according to GBA. The representation of the terminal 10 in Figure 1 of the drawings does not include a UlCC for the sake of simplicity and clarity. Having received the security report from the terminal 10 in step (b), the DM entity 20 may determine a security policy for the terminal 10 and then communicate the security policy to the DM client 12 via the device management interface 25 in step (c). The security policy may comprise one or more required security settings for at least one of the security parameters, an indication as to what device security actions should be taken by the DM client 12 depending on the content of the security data. The device security actions may include, for example, breaking the existing communications connection 35 and/or performing one or more of the following actions: seek a new communications connection with the serving network 30; establish a communications connection to a different network; or select a different bearer for the communications connection 35 (for example, 3G rather than 2G). Optionally, the security policy may also indicate what action should be taken if no suitable alternatives to the current communications connection 35 can be found within a particular period of time. For example, two or more device security actions may be indicated, wherein the first device security action is to be attempted, and if that should fail within a period of time (for example, a period of time specified in the security policy, or a period of time set by the terminal 10, such as 0.5 seconds, 1 second, 5 seconds, etc), the second device security action is to be attempted. Optionally, the security policy may also indicate what the DM client 12 should do in the event that the DM entity 20 is not available to receive security reports, since an attacker might try to block the security reports from being sent in step (b) if they cannot read or alter them. For example, the DM client 12 may ordinarily forward the security report to the DM entity 20 with a request for further advice (for example, a new or updated security policy). However, the DM client 12 may need to know what to do in the even that such "further advice" never arrives, as this may be a sign in itself that an attack is in progress.

By way of example, the security policy may indicate what device security action should be taken for different possible settings of at least one parameter of the security data. For example, it may indicate that if weaker encryption algorithms are being used, such as A5/2 or GEA1/GEA2, a new communications bearer should be selected from any of 3G, 4G or 5G, whereas if stronger encryption algorithms are being used, such as A5/3 or GEA3, the current communications connection 35 is sufficiently secure and should be maintained. In this way, the DM client 12 may compare the current setting of each parameter of the security data step-by-step with the requirements set out in the security policy and take whatever device security action is necessary in accordance with the security policy.

In an alternative implementation, the security policy may indicate what setting(s) of at least one security parameter is allowable and what setting(s) of at least one security parameter is not allowable. The security policy may then indicate what device security action should be taken in the event that the current setting of any one or more of the security parameters (or, in an alternative implementation, the current settings of any two or more of the security parameters, or the current settings of any three or more of the security parameters, etc) is deemed unallowable according to the security policy.

Alternatively, the security policy may indicate what setting(s) of at least one security parameter in the security data are allowable and indicate what device security action should be taken in the event that the current setting of any one or more of the security parameters (or, in an alternative implementation, the settings of any two or more of the security parameters, or the settings of any three or more of the security parameters, etc) are unallowable according to the security policy. In this case, the DM client 12 may default to maintaining the communications connection 35 if none of the current settings of the security parameters breach the requirements of the security policy.

Alternatively, the security policy may indicate what setting(s) of at least one security parameter are unallowable and indicate what device security action should be taken in the event that the current setting of any one or more of the security parameters (or, in an alternative implementation, the current settings of any two or more security parameters, or the current settings of any three or more security parameters, etc) are unallowable according to the security policy. Again, the DM client 12 may default to maintaining the

communications connection 35 if none of the current settings of the security parameters breach the requirements of the security policy.

Whilst in this example implementation of the first aspect of the disclosure the DM entity 20 determines the security policy, in an alternative implementation, the security policy may be determined at least in part by a further entity, for example a service provider entity that is in communication with the DM entity 20. For example, the DM server 20 may receive the security policy from the further entity (either after the DM entity 20 has forwarded the security report to the further entity, or independently of any forwarding of the security report - indeed, the DM entity 20 may never forward the security report onto any other entity), and then forward the security policy on to the DM client 12 in step (c). Alternatively, the other entity may send a set of security rules or suggestions, which the DM server 20 may use (optionally in consideration also of the security report) to determine the security policy.

The DM client 12 may carry out the device security action by any suitable means according to the type of terminal 10 and its configuration, for example by instructing the baseband 14 and/or any other modules or components to change the communications connection 35 accordingly.

In this way, control of security policy on a per terminal basis, or across a family of terminals, may be achieved. Consequently, security policies may be tailored to particular environments and/or uses and/or geographical locations, etc of terminal 10. Furthermore, the DM entity 20 may update and alter the security policy of terminals, such that any changes in the security requirements of the network and/or the terminal and/or the service provider, etc (caused, for example, by changes in service provider policy, or changes in serving network 30 policy, or changes in the home network policy, or changes in the use or location of the terminal 10, etc), may be implemented by the security policy. As a result, full visibility of bearer security may be afforded to the terminal 10 and the DM entity 20, where previously it was not, and where weaknesses in the bearer security of the communications connection 35 are identified, control may be exercised over what should be done by the terminal 10 to improve the security of the communications connection 35 to an acceptable level. Thus, it may be ensured that the communications bearer used for the communications connection 35 is providing sufficient levels of security, without having to provide "over-the-top" security. Therefore, increased flexibility is afforded service providers to allow bearer-security to be utilised for the communications connection 35 with confidence that security will be strong enough to meet their requirements, thereby avoiding increased latency and complexity caused by "over-the-top" security. Or, even if the service provider continues to apply "over-the-top" security, they may gain a further assurance that the bearer security is not unusually weak, or anomalous in a suspicious way which indicates an attack in progress. Furthermore, where it is decided that bearer security will not be relied upon, for example because "over-the-top" security will be provided, the security policy may allow for minimal bearer security, thereby maximising coverage options for the terminal 10 and minimising overheads.

Furthermore, this aspect of the present disclosure may be implemented in existing cellular networks without requiring enhancements or alterations to the cellular network, since the serving network 30 and the standards/protocols used for the communications connection 35 are unchanged.

Whilst in the above, the DM entity 20 communicates the security policy to the DM client 12 after receiving the security report, the DM entity 20 may alternatively provide the security policy to the DM client 12 at any time. For example, as an emergency response to an attack in progress, the DM entity 20 may determine a security policy and communicate it to the DM client 12, regardless of whether or not a security report has previously been received, in order to achieve a quick response to an attack in progress. The security policy may be set simply to instruct the DM client 12 to take one or more device security actions, for example select a new network, regardless of the security data determined by the DM client 12, or it may instruct the DM client 12 to take device security action for a particular setting(s) of one or more security parameter that is known to be under attack. In some instances the security policy may be established before a security report is received. However, the security policy may then be quite complicated, such that the DM client 12 (particularly for more straightforward terminals) may be unable to store all of the security requirements and device security actions included in the security report. In this case, it may be preferable for the DM client 12 to send the security report to the DM entity 20, and receive in return a security policy comprising a list of one or more device security actions that the DM entity 20 has determined on the basis of the security report. In this case, the security report would not comprise a set of required security settings for security parameters, but instead a set of one or more device security actions.

Furthermore, in some instances, there may be a grey area in the security policy, such that the DM entity 20 ideally needs to see the security report to make its own decision about what device security actions should be taken to prepare the security policy on that basis (for example, to decide whether what the DM client 12 is seeing is typical or exceptional).

The DM entity 20 may be in communication with only one terminal 10, or a plurality (two or more) of terminals. The DM entity 20 may optionally be in communication with a service provider entity 40 (for example, an M2M operator, such as Vodafone GSDP, or an individual service provider) via a service interface 45. The service provider entity 40 may be any suitable entity, for example a server, or a software or hardware module within a server, etc. The DM entity 20 may provide aggregate reports to the service provider entity 40 that identify expected security behaviour for particular types of terminal 10 and/or particular geographical regions or serving networks. These may help the service provider entity 40 to learn about particular types of terminal 10 and/or particular geographical regions or serving networks, for example which serving networks have particular types of encryption turned on (such as GEA/3, GEA/4, A5/3 or A5/4) and how often such algorithms are selected.

The DM entity 20 may additionally or alternatively provide anomaly reports to the service provider entity 40 that identify terminals 10 that are not behaving as expected. This may allow further investigations to be conducted to determine what may be going wrong with those terminals 10.

Such reporting to the service provider entity 40 may enable the service provider entity 40 to create and/or expand/improve mapping of generally expected bearer security behaviour (for example, what particular serving networks usually deliver) and detect anomalies, which may represent false base station attacks, or misconfigured equipment. Causes of anomalies may consequently be investigated further and corrected. Whilst Figure 1 of the drawings shows a representation of the service interface 45 and the service provider entity 40, it will be appreciated that these are optional elements to the system 100 and may be omitted.

The above described aspects of the present disclosure may be particularly beneficial where the serving network 30 is a visited network and the DM entity 20 is either part of, or is in communication with, the home network of the terminal 10, since it enables some degree of control of the security of the communications connection 35 to be maintained by the home network. However, the above described aspects may still be of use where the serving network 30 is the home network as it provides a further mechanism by which the home network may exercise control over the security of the communications connection 35.

A modification of the above described first aspect of the present disclosure is provided in a second aspect of the present disclosure. The second aspect of the present disclosure is represented by system 200 in Figure 2, where like features have the same reference numerals as used in Figure 1.

In the second aspect of the present disclosure, the baseband 14 is further configured to receive from the DM client 12 via the privileged API 16 a security request, whereby the DM client 12 requests that particular settings are used for one or more of the security parameters. Steps (a) to (c) may be carried out as explained above, but the device security action determined by the DM client 12 may additionally, or alternatively, include requesting particular settings of security parameters that the DM client 12 would like to be applied to the communications connection 35 in order to improve the security of the communications connection 35.

The security policy received in step (c) - or any security policy received in advance, prior to any of steps (a) to (c) - may indicate settings of security parameters that should be met by the communications connection 35. Where the DM client 12 determines from the security data that one or more of the settings has not been met, the device security action may include a request to change the setting of at least one security parameter so that the requirements of the security policy can be fulfilled. In step (d), the DM client 12

communicates the security request to the baseband 14 via the privileged API 16. Such a request may be viewed as a "write" action, whereas the an interrogation in step (a) may be viewed as a "read" action. However, if the DM client 12 has received the security policy in advance, it may perform step (d) without previously performing step (a). The security parameters for this aspect of the present disclosure are the same as those identified in respect of the first aspect described above. The request may include one or a plurality of requested settings for a single security parameter, or one or a plurality of requested settings for each of two or more security parameters. Where two or more settings are requested for a particular security parameter (for example, a requested setting of A5/3 or A5/4 encryption for the encryption algorithm security parameter), the baseband 14 may attempt to have the encryption algorithm set to either of the requested settings. Optionally, where two or more settings are requested for a particular security parameter, the request may further include an order of preference for the settings, such that the baseband 14 may attempt to have the most preferable setting applied to the security parameter, but indicate a 2 ^nd preference if the most preferable should not be possible. This may be achieved either by the baseband 14 trying each preference in turn, or the different settings and their

preferences may be communicated from the baseband 14 to the serving network 30 in the demand (explained below). The DM client 12 may optionally indicate in the request that it does not care what a particular security parameter is set to (for example, the request may indicate that any key refresh period is acceptable).

The request will not always request an increase in the level of bearer security, but may in some instances request that the setting of at least one security parameter be changed to decrease the level of security provided. For example, the request may include a request for ciphering to be turned off, or for the encryption algorithm to be set to one that is less secure, etc. This may be the case where low overheads and/or minimal latency are desired and security is not a major concern, or where a decision has been made to use "over-the-top" security, such that more straightforward security settings with lower latency and/or overheads may be utilised for the bearer security.

Having received the request in step (d), the baseband 14 prepares a demand that is based on the request and in step (e) communicates the demand to the security end-point network entity 34 (referred to from hereon as the network entity 34) in the serving network 30 via the communications connection 35. The network entity 34 may be any entity within the serving network 30 or the home network that has the authority to establish or change the settings of the security parameters defining the security of the communications connection 35. For example, it may be a software or hardware module within an eNodeB, SGSN, RNC, MME or Home Security Endpoint (HSE), or a standalone security server or module, or any other suitable module or server(s) within the serving network 30 or home network. The demand may include all or part of the subject matter of the request received in step (d). Having received the demand, the network entity 34 may attempt to apply the demanded settings. However, it will be appreciated that sometimes it will not be possible to apply a demanded setting, for example where the serving network 30 does not support the demanded setting.

In step (f), the baseband 14 may report to the DM client 12 what settings have been applied to the security parameters (analogously to step (a)). The baseband 14 may indicate which aspects of the security request have been met (and which, if any, preferences in the security request were achieved) and/or which aspects of the security request have not been met. Alternatively, the baseband 14 may simply indicate what the settings are for the security parameters and allow the DM client 12 to determine the extent to which the security request was met. This report from the baseband 14 may be in response to a further interrogation from the DM client 16, or upon elapse of a particular period of time after communicating the demand in step (e), or in response to any other suitable trigger. Optionally, the serving network 30 or home network may communicate a report to the baseband 14 to indicate which aspects of the demand have been met and/or which have not.

The DM client 12 may then assess the effectiveness of its security request and determine if any further device security actions should be undertaken in consideration of the security policy (for example, if one or more of the security parameters still breaches the requirements of the security policy, the DM client 12 may determine to undertake a further device security action, such as breaking the communications connection 35, or seeking a new

communications bearer, or seeking a new serving network, etc). The DM client 12 may also send a security report - or a further security report - to the DM entity 20 (as in step (b), described earlier) and, optionally, receive a security policy, or updated security policy, (as in step (c) earlier) from the DM entity 20. Again, even if the service provider continues to apply "over-the-top" security, they may gain a further assurance that the bearer security is not unusually weak, or anomalous in a suspicious way which indicates an attack in progress. Or, alternatively, the service provider who is happy with "over-the-top" security may be able to reduce the overheads of bearer security in some ways e.g. to reduce power consumption at the terminal 10.

The second aspect of the present disclosure provides very similar benefits to the first aspect as described above as it may be ensured that the communications bearer used for the communications connection 35 is providing sufficient levels of security, without having to provide "over-the-top" security. Therefore, increased flexibility is afforded to service providers to allow bearer-security to be utilised for the communications connection 35 with confidence that security will be strong enough to meet their requirements, thereby avoiding increased latency and complexity caused by "over-the-top" security, without overly restricting the coverage available to the terminal 10.

In addition to the benefits of the first aspect, the second aspect may provide the further benefit of allowing the terminal 10 a greater degree of control over the security of the communications connection 35. In particular, the terminal 10 may be able to improve the level of security of the existing communications connection 35 to meet the requirements of the security policy, without having to establish a new communications connection or seek a new communications bearer, etc. This may be particularly beneficial in scenarios

(particularly for M2M devices) where only one serving network and/or one communications bearer may be available to the terminal 10. Furthermore, in the event that a decision has been made to use "over-the-top" security, the security policy may be set to allow the terminal 10 flexibility in respect of networks and/or communications bearers that it may use (thereby maximising coverage), but encourage the preferential use of security parameter settings that minimise latency and overheads.

Since the second aspect of the present disclosure requires a change in communications between the terminal 10 and the serving network 30, it may be implemented in existing networking (for example, 2G, 3G, 4G or cellular loT) with changes/enhancements to the standards and protocols of those networks. It may be implemented in future networks (for example, 5G) by setting the standards and protocols accordingly during the design process. In a third aspect of the present disclosure, APIs may be used on the network side to allow for network side interrogation of security levels of the communications connection 35 and/or network side security requests to be made for changes to the settings of security parameters associated with the communications connection. The third aspect of the present disclosure may thus be viewed as a network side implementation of the first and/or second aspects.

Figure 3 shows a schematic representation of a system 300 according to the third aspect. The system comprises a terminal 310, a visited network 320 and a home network 330. The terminal 310 may be the same type as terminal 10 of the first or second aspects, or may be any other type of terminal (for example, any type of UE or M2M device). The terminal 310 is associated with the home network 330 (i.e., that is the network to which the terminal 310 is subscribed) and has a communications connection 315 with the visited network 320. The visited network 320 comprises a base station 322 (corresponding to the base station 32 of Figures 1 and 2) and security end-point network entity 324 (referred to from hereon as a visited network entity 324), which is coupled to the base station 322. The home network 330 comprises a home network entity 332.

The visited network entity 324 provides an API 325 to the home network entity 332. API 325 is similar to the privileged API 16 in the first and second aspects and enables the home network entity 332 to interrogate the visited network 320 to determine security data. The home network entity 332 may determine security data in the same way as described above in respect of the first aspect (for example., via a "read " function of the API 325) and may identify the terminal 310 for which it desires information during the interrogation (for example, using an IMSI associated with the terminal 310, or by any other identification means).

Additionally, and especially if the API 325 allows for it, the home network entity 332 may also issue a security request (for example, via a "write" function of the API 325) to the visited network 320 in the same way as described above in respect of the second aspect.

The home network entity 332 may utilise the security data it has determined in order to set the security policy for the terminal 310 (either setting the security policy itself, or by sending a security report to a DM server in order for the DM server to set the security policy), to be issued to the terminal 310 via a DM server (in the same way as explained earlier in respect of aspect 1). This may be particularly useful if the API 325 does not allow for security requests to be issued to it. If the terminal 310 is of the same type as terminal 10 described in respect of the first or second aspect of the present disclosure, the DM client 12 may then determine a device security action to be carried out based on the security policy and the security data (which the DM client 12 may have determined for itself, or which may have been sent to the DM client 12 along with the security policy).

Consequently, the home network 330 is able to specify security preferences for the terminal 310 (per IMSI or per authentication event), or to require that a minimum security level is enforced, or at least to find out (via the "read" function) what level was established.

The API 325 may be implemented in any suitable way, for example depending on the nature of the visited network entity 324, the manufacturer of the visited network entity 324, the operator of the visited network 320, etc. Since it requires a change to network side communications, the API 325 may be implemented in existing networking (for example, 2G, 3G, 4G or cellular loT) with changes/enhancements to the standards and protocols of those networks. It may be implemented in future networks (for example, 5G) by setting the standards and protocols accordingly during the design process.

The visited network entity 324 may be any type of network entity configured to provide API 325. For example, it may form part of an eNodeB (in which case the visited network entity 324 would form part of, for example be a module of, the base station 322), or part of an MME or security entity in the visited network 320, or any other server(s) and/or software or hardware modules in the visited network 320. Likewise, the home network entity 332 may be any type of network entity in the home network 330, for example a security

server/module, or a service provider server/module, or any other server(s) and/or software or hardware modules in the home network 330.

Whilst in this implementation, and in the implementations shown in Figures 4 and 5 and described below, the security end-point network entity is in the visited network 320, it may alternatively be any network entity where the security of the communications connection 315 ends, potentially outside of the visited network 320. For example, it may be in the home network, in which case the security end-point network entity may still provide an API to another network entity (such as the API 405 to the DM entity 20). Figure 4 shows a further system 400 according to the third aspect of the present disclosure. System 400 is the same as system 300 in Figure 3, but further includes the DM server 20 of the first and second aspects. An API 405 is provided by the home network entity 332 towards the DM entity 20. The API 325 and API 405 may form a chain of APIs that can enable the DM entity 20 to interrogate the visited network 320 and/or issue security requests to the visited network 320 as described above in respect of the home network entity 332 in Figure 3. Alternatively, where the security on the communications connection 315 terminates in the home network itself, for example at the Home Security Endpoint (HSE), the DM entity 20 may use the API 405 directly to interrogate and/or issue security requests to the home network The home network entity 332 may be configured to check that the DM entity 20 has suitable permissions to enquire about the security of communications connection 315 and/or to issue security requests in respect of communications connection 315 (for example, the DM server 20 may have that permission for certain IMSIs or subscriptions, but not for others). In an alternative implementation, API 325 may be provided directly to the DM entity 20, such that API 405 and the home network entity 332 is not required. In a further alternative implementation, an API may be provide by any of the visited network entity 324, or the home network entity 332, or the DM server 20 towards an end application or service. Again, this could be done via a chain of APIs (for example, with API 325 and API 405 chained together and the DM entity 20 offering the final API in the chain to the end application). Again, the provider of the final API may be configured to check that the end application or service has suitable permissions for a given terminal or subscription.

Permissions may optionally be checked by any or all links in the chain.

In a further alternative, an API may be provided from any other networked system or application towards a further application or system (potentially even back to the device management client 12 on the terminal 10, or to a different device client, or a web-based managed system, etc). Again, this may be done by chaining APIs together and checking permissions at any or all links in the chain. It can be appreciated that there any many options for enabling access to various different networked systems or applications. However, in each instance, the visited network entity 324 or home network entity 332 provides an API towards a different networked entity or application, wherein the different networked entity or application may be the final

entity/application in the API chain, or it may be an intermediate entity/application in the API chain.

It will be appreciated, therefore, that the third aspect provides to network side entities similar benefits of visibility and/or control over the bearer security of the communications connection 315 to that of the first and/or second aspect. Consequently, the same technical advantages as described earlier in respect of the first and/or second aspects may likewise be achieved by the third aspect of the present disclosure.

Figure 5 shows a system 500 that is a particular implementation of the system 400. In system 500, the terminal is the terminal 10 described in respect of the first aspect or the second aspect. The DM entity 20 may determine security data for itself (by interrogating the visited network entity 324 via a direct API (not shown in Figure 5), or via the chain of API 405 and API 325). It will be appreciated that in an alternative implementation, any length of API chain may be present between the DM server 20 and the visited network entity 324 with any number of intermediate system/applications in the chain. The DM client 12 may also determine security data via the privileged API 16 (step (a) in the first aspect), either in response to an instruction from the DM entity 20, or of its own volition. The DM client 12 may send a security report to the DM entity 20 (step (b) in the first aspect), such that the DM entity 20 can have confirmation of the security level of the communications connection 315 from both ends of the communications connection 315. It may also enable the DM entity 20 to obtain independent confirmation (using a unique security association identifier included in the security data and security report) that the same security association (with the same keys) is set at each end of the communications connection 315. This may help the DM entity 20 to detect man-in the-middle attacks.

Furthermore, the DM entity 20 may issue a security request to the visited network entity 324 via the API chain (or a direct API) and also issue the security policy to the DM client 12 (step (c) of the first aspect). Where the terminal 10 is configured according to the second aspect of the present disclosure, the DM client 12 may then issue its security request to the baseband 14, wherein the DM client 12 security request is the same or compatible with the security request issued by the DM entity 20. In this way, the DM entity 20 may establish control over both ends of the communications connection 315, thus reducing the risk of security levels being "bid down" by a man-in-the-middle attack.

It will be appreciated that any other privileged entity (e.g. home network, or privileged end application or server) which has access to the network API chain (or direct API) as well as to the interface 45 of Figures 1 or 2 (to the DM entity 20) can similarly obtain independent confirmation of bearer security level from both the network API and the device API.

Additionally, or alternatively, such a privileged entity may similarly establish control over both ends of the communications connection 315.

It will be appreciated that the serving network 30 may be configured to operate in

accordance with the second aspect of the present disclosure and/or the third aspect of the present disclosure. That is to say, it may be configured to receive a security demand from the terminal 10 in accordance with the second aspect. Additionally or alternatively, it may be configured to provide the API 325 in accordance with the third aspect of the present disclosure.

In the above, various APIs have been described in respect of both the terminals and network entities. It will be appreciated that an API is a set of routines, protocols or tools by which a particular module or entity may provide an interface, or to grant access to some aspect(s) of its functionality, to a different module or entity. Whilst APIs are one particular way in which this may be achieved, the present disclosure is not limited only to APIs, but encompasses any alternative means to API by which a module or entity may provide an interface, or grant access to some aspect(s) of its functionality, to another module or entity as described earlier. Whilst the various connections and interfaces between entities and modules of the present disclosure are represented in the drawings as direct connections or interfaces, it will be appreciated that any number of intervening entities or modules may be present, for example communications routing entities, etc. Furthermore, whilst each module or entity (for example, the DM entity, the base station, etc) is represented in the drawings as a single entity, it will be appreciated that their functionalities may be distributed between two or more hardware components, either co-located or located in different geographical locations.

Likewise, whilst the baseband 14 and the DM client 12 are represented as separate modules, it will be appreciated that they may nevertheless be implemented on the same chip/processor/memory and merely represent separate functional modules.

Furthermore, Figure 1 of the drawings shows the communications connection 35 ending at the base station 32 in the serving network 30, this is not intended to limit the first aspect of the present disclosure to the base station 32 always being the security end-point of the communications connection 35. Likewise, Figures 2 to 5 show the communications connections 35 and 315 passing through the base stations 32 and 322 to the security end- point network entity 34 and 324. However, this is not intended to limit the security end-point of the communications connections 35 and 315 always to those examples. In some instances, the security end point will be at the base station 32 or 322, in which case the security end-point network entity will be the base station 32 or 322. However, in alternative instances, the communications connection 35 and 315 may terminate at any other security end-point network entity, for example the SGSN as may be the case for GEA/x encrypted security, or the RNC as may be the case for 3G bearers, or the MME as may be the case for 4G bearers, or the Home Security Endpoint (HSE), or any other security end-point network entity, either in the home or visited network. In these alternative instances, the

communications connection 35 and 315 may be considered to run through the base station 32 or 322 to the security end-point network entity (and optionally through any one or more intervening network entities).