EP3412015A1 - Contrôle de la sécurité d'un support dans une connexion de télécommunications - Google Patents

Contrôle de la sécurité d'un support dans une connexion de télécommunications

Info

Publication number
EP3412015A1
EP3412015A1 EP17704061.5A EP17704061A EP3412015A1 EP 3412015 A1 EP3412015 A1 EP 3412015A1 EP 17704061 A EP17704061 A EP 17704061A EP 3412015 A1 EP3412015 A1 EP 3412015A1
Authority
EP
European Patent Office
Prior art keywords
security
request
communications connection
device management
network entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP17704061.5A
Other languages
German (de)
English (en)
Inventor
Nicholas Bone
Timothy Snape
Peyman DERAKHSHAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone IP Licensing Ltd
Original Assignee
Vodafone IP Licensing Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone IP Licensing Ltd filed Critical Vodafone IP Licensing Ltd
Publication of EP3412015A1 publication Critical patent/EP3412015A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition

Definitions

  • 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.
  • 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).
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • null encryption A5/0, GEA/0
  • old, weak encryption A5/2, A5/1 or GEA1/GEA2
  • 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.
  • M2M Machine-to-Machine
  • GEA3 is a stronger GPRS encryption algorithm, and some also utilise the A5/3 encryption algorithm.
  • 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.
  • 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.
  • 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.
  • 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.
  • a terminal such as a UE or M2M device
  • 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
  • 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').
  • the device management client is configured to: interface with a device
  • the device management entity for example, a device management server
  • 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.
  • 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.
  • security parameters 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
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the device baseband is configured to: provide an application programming interface for receiving the request for the current settings of one or more security
  • 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
  • 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 baseband is further configured to: communicate to the
  • 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.
  • 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
  • the functionality of the device baseband may be accommodated with any suitable changes or modifications to the existing standards.
  • 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.
  • 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 .
  • a device management entity for example, a device management server
  • 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
  • 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
  • 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.
  • 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.
  • a security end-point network entity for example, a security end-point network entity, such as an eNode B, SGSN, RNC, MME or HSE
  • 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
  • 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.
  • a terminal for example, a UE or M2M device
  • the communications connection being carried by a telecommunications bearer and secured using bearer security
  • 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.
  • 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
  • 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
  • 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 security end-point network entity (for example an eNode B, SGSN, RNC, MME or HSE ) in communication with a terminal via a security end-point network entity (for example an eNode B, SGSN, RNC, MME or HSE ) in communication with a terminal via a security end-point network entity (for example an eNode B, SGSN, RNC, MME or HSE ) in communication with a terminal via a security end-point network entity (for example an eNode B, SGSN, RNC, MME or HSE ) in communication with a terminal via a security end-point network entity (for example an eNode B, SGSN, RNC, MME or HSE ) in communication with a terminal via a security end-point network entity (for example an eNo
  • the security end-point network entity being configured to:
  • a further entity for example, a further networked entity, such as a home network entity and/or a device management entity, etc.
  • a further networked entity such as a home network entity and/or a device management entity, etc.
  • 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.
  • a network entity for example, a home network entity and/or a DM entity, etc
  • 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
  • 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
  • a terminal for example, a UE or M2M device
  • a security end-point network entity for example, an eNode B, SGSN, RNC, MME or HSE
  • 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
  • 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 .
  • the device management client need not necessarily have interrogated the device baseband to determine security data.
  • 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.
  • 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
  • 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.
  • a security end-point network entity for example, an eNode B, SGSN, RNC, MME or HSE
  • a terminal for example, a UE or M2M device
  • the security end-point network entity being configured to: receive a security request from a further entity (for example, a home
  • 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.
  • a network entity for example, a home network entity and/or DM entity
  • a security end-point network entity for example, an eNode B, SGSN, RNC, MME or HSE
  • 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
  • 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.
  • 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
  • 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
  • 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.
  • DM device management
  • 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).
  • 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).
  • 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
  • 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.
  • 2G for example, GSM, EDGE or GPRS
  • 3G for example, UTMS
  • 4G 5G
  • Cellular loT 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.
  • bearer security for example, A5/0, A5/1 , A5/2, GEA/o, GEA/1 or GEA/2
  • 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 eNo
  • 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.
  • a 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).
  • 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?
  • 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?
  • 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).
  • "ciphering status of the communications interface” may be a security parameter
  • "on” and “off” may be the possible settings for that security parameter.
  • "security protocol used to establish encryption keys” may be a security parameter
  • "2G”, “3G”, “4G”, “5G” and “enhanced Cellular loT security” may be the possible settings for that security parameter.
  • 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.
  • FIG. 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.
  • the DM client 12 interrogates the baseband 14 via the privileged API 16 to determine security data in accordance with the explanation above.
  • 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.
  • 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
  • the 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.
  • 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.
  • 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.
  • UlCC Universal Integrated Circuit Card
  • SIM card SIM card
  • 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).
  • 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.
  • 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.
  • 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).
  • further advice for example, a new or updated security policy.
  • 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.
  • 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.
  • weaker encryption algorithms such as A5/2 or GEA1/GEA2
  • a new communications bearer should be selected from any of 3G, 4G or 5G
  • stronger encryption algorithms such as A5/3 or GEA3
  • 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.
  • 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.
  • 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.
  • 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.
  • the DM client 12 may default to maintaining the security policy
  • 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.
  • 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).
  • 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.
  • 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.
  • the security policy may allow for minimal bearer security, thereby maximising coverage options for the terminal 10 and minimising overheads.
  • 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.
  • 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.
  • 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.
  • the DM entity 20 may 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the baseband 14 may attempt to have the encryption algorithm set to either of the requested settings.
  • 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
  • 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.
  • 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.
  • the baseband 14 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.
  • 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.
  • 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.
  • 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
  • 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.
  • a security policy or updated security policy, (as in step (c) earlier) from the DM entity 20.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • FIG 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).
  • 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.
  • 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).
  • 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.
  • existing networking for example, 2G, 3G, 4G or cellular loT
  • future networks for example, 5G
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • API 325 may be provided directly to the DM entity 20, such that API 405 and the home network entity 332 is not required.
  • 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.
  • 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 may be an intermediate entity/application in the API chain.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • any other privileged entity e.g. home network, or privileged end application or server
  • the network API chain or direct API
  • the interface 45 of Figures 1 or 2 to the DM entity 20
  • such a privileged entity may similarly establish control over both ends of the communications connection 315.
  • serving network 30 may be configured to operate in
  • the second aspect of the present disclosure 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the SGSN as may be the case for GEA/x encrypted security
  • the RNC as may be the case for 3G bearers
  • the MME as may be the case for 4G bearers
  • HSE Home Security Endpoint
  • 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des procédés, des systèmes, et un appareil permettant d'identifier et/ou de modifier le niveau de sécurité d'un support prévu pour une connexion de communications (315) entre un terminal (310) et un réseau de desserte (320). Un exemple de procédé comprend les étapes consistant à communiquer, du terminal (310) à une entité de réseau de télécommunications (324) dans le réseau de desserte, une exigence de sécurité comprenant au moins une demande pour au moins un paramètre de sécurité particulier devant être appliqué à un paramètre de sécurité correspondant de la liaison de communications, le paramètre de sécurité définissant un aspect de la sécurité de la connexion de communications. Si au moins un des paramètres de sécurité particuliers requis peut être appliqué au paramètre de sécurité correspondant, l'entité de réseau de télécommunications applique le paramètre de sécurité requis au paramètre de sécurité correspondant.
EP17704061.5A 2016-02-05 2017-02-03 Contrôle de la sécurité d'un support dans une connexion de télécommunications Ceased EP3412015A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1602162.8A GB2547040A (en) 2016-02-05 2016-02-05 Controlling bearer security in a telecommunications connection
PCT/GB2017/050268 WO2017134449A1 (fr) 2016-02-05 2017-02-03 Contrôle de la sécurité d'un support dans une connexion de télécommunications

Publications (1)

Publication Number Publication Date
EP3412015A1 true EP3412015A1 (fr) 2018-12-12

Family

ID=55641919

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17704061.5A Ceased EP3412015A1 (fr) 2016-02-05 2017-02-03 Contrôle de la sécurité d'un support dans une connexion de télécommunications

Country Status (3)

Country Link
EP (1) EP3412015A1 (fr)
GB (1) GB2547040A (fr)
WO (1) WO2017134449A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110830993B (zh) * 2018-08-10 2021-08-20 华为技术有限公司 一种数据处理的方法、装置和计算机可读存储介质
CN114844662B (zh) * 2022-03-01 2024-03-12 天翼安全科技有限公司 一种网络安全策略管理方法、装置及设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101854625B (zh) * 2009-04-03 2014-12-03 华为技术有限公司 安全算法选择处理方法与装置、网络实体及通信系统
US10064221B2 (en) * 2012-03-14 2018-08-28 Telefonaktiebolaget Lm Ericsson (Publ) Determining a transition of a terminal between its idle state and its connected state
US8923815B1 (en) * 2013-10-27 2014-12-30 Konstantin Saprygin Method for detecting changes in security level in mobile networks
CN103763701A (zh) * 2014-01-02 2014-04-30 深圳市共进电子股份有限公司 一种基于无线网络实现通信安全的方法及系统

Also Published As

Publication number Publication date
WO2017134449A1 (fr) 2017-08-10
GB201602162D0 (en) 2016-03-23
GB2547040A (en) 2017-08-09

Similar Documents

Publication Publication Date Title
US10848970B2 (en) Network authentication method, and related device and system
US12003533B2 (en) Mobile communication method, apparatus, and device
CN114080843B (zh) 用于增强5g网络的网络切片和策略框架的装置、系统和方法
CN110786034B (zh) 用于网络切片隐私考虑的方法、用户设备和功能节点
US9706512B2 (en) Security method and system for supporting re-subscription or additional subscription restriction policy in mobile communications
KR102040231B1 (ko) 이동 통신에서 가입 사업자 변경 제한 정책을 지원하는 정책 적용 방법 및 장치
JP5784776B2 (ja) 認証能力のセキュアなネゴシエーション
EP2932676B1 (fr) Authentification de réseaux mobiles terrestres publics sur des stations mobiles
JP5468623B2 (ja) ネットワークにおけるブートストラップ・メッセージを保護するための装置と方法
EP3089496B1 (fr) Procédé et appareil permettant de fournir des informations
US10009760B2 (en) Providing network credentials
JP6775683B2 (ja) 次世代システムの認証
US20150319618A1 (en) Communication security processing method, and apparatus
US11722890B2 (en) Methods and systems for deriving cu-up security keys for disaggregated gNB architecture
EP3412015A1 (fr) Contrôle de la sécurité d'un support dans une connexion de télécommunications
US10492056B2 (en) Enhanced mobile subscriber privacy in telecommunications networks
JP6167229B2 (ja) 無線通信システムにおけるエアインタフェースセキュリティアルゴリズムの選択方法及びｍｍｅ
CN106465117A (zh) 一种终端接入通信网络的方法、装置及通信系统
EP2538707B1 (fr) Procédé de chargement des autorisations d'abonné et équipement associé
US20220232380A1 (en) Method for configuring a radio connection
EP3219066B1 (fr) Système de sécurité matériel pour dispositif radio pour utilisation en spectre sans fil

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180905

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201116

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SNAPE, TIMOTHY

Inventor name: BOURNE, SOPHIE NICOLE

Inventor name: DERAKHSHAN, PEYMAN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20221205