GB2551358A

GB2551358A - Low latency security

Info

Publication number: GB2551358A
Application number: GB1610381.4A
Authority: GB
Inventors: Babbage Steven; Bone Nicholas
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2016-06-13
Filing date: 2016-06-13
Publication date: 2017-12-20
Also published as: GB201610381D0

Abstract

Providing a secure communication session between a mobile terminal and a serving network node of a cellular network by sending a key management message between the core network and the serving network node wherein the intermediate security key is generated, derived or recovered within the serving network node. A key management message is sent between the serving network node and the mobile terminal and in response to this message an intermediate key is generated, derived or recovered within the mobile terminal. A session key is generated from the intermediate key and this is used to secure the communication session. Further embodiments include a delegated subscriber server (DSS) of a visiting network deriving a key using key material held in the home subscriber server (HSS) of a subscriber's home network. A further embodiment provides the generation, reception or derivation of a shared secret, using public and private key information, at the mobile terminal and the serving network node. A session key is generated from the shared secret at the mobile terminal and the serving network node.

Description

Low Latency Security

Technical Field of the Invention

The present invention relates to cellular security and in particular, providing reduced latency security, authentication and authorisation.

Background to the Invention

Mobile communications are protected by cryptography (encryption, integrity protection), at least over the radio interface where they would otherwise be rather easy to intercept or impersonate (spoof). This cryptography uses keys, which exist both in the mobile device and somewhere in the network. For better security, these keys should be updated sufficiently often.

Agreeing an updated set of keys generally requires some communication between the network and the mobile device. 5G networks are expected to support aggressive latency requirements for some services (e.g. <10ms or even <1ms latency for services requiring advanced automation). The attempt to achieve these targets may compromise system security, or else entail a completely new security architecture compared to previous generations of mobile network. 3GPP security mechanisms include authentication and key agreement, with periodic re-authentication (which requires round trips to a home network), signalling to a core network to manage security associations and session key updates, secure handovers between cells, and basic cryptographic operations of encryption and decryption, creation and verification of MACs etc.

However, authentication to the home network becomes extremely difficult within a round trip of <10 ms (limited at least by the speed of light where the home network can be at most 1500 km away). Core network signalling is very challenging within a round trip of <1 ms (core network nodes can be at most 150 km away). Even basic crypto-operations become a challenge with <1 ms round trip time. For example, if 10% of the allowable latency is consumed by the crypto, then this requires at most 25 micro-seconds for each send and receive operation, or at most 12.5 micro-seconds for each crypto operation; compare that with http://csrc.nist.gov/qroups/ST/lwc-workshQp2015/presentations/session7-vincent.pdf (retrieved 9 June 2016)

To explain this problem in more detail, it is worth considering existing approaches for dealing with cryptographic keys in cellular networks. Second generation (2G), third generation (3G) and fourth generation (4G) mobile communications networks all use a long-lived key and at least one short-lived key. The long-lived key is typically fixed for the lifetime of the device and resides only in the Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM) and in a network node called the Authentication Centre (AuC), both of which are highly secure environments. It should be very difficult for an attacker to extract the key from either of them. In GSM (2G), this key is called K,, while in 3G and 4G it is called K. There are one or two short-lived keys, which might also be called session keys. These are used for security over the radio interface. In GSM, the session key is called Kc, and it is used for encryption over the radio interface. In 3G, there is one session key called CK, used for encryption over the radio interface, and another called IK, used for integrity protection of signalling messages over the radio interface. In 4G, there are several encryption and integrity keys to be used with different network nodes. At the device end, the session keys are created in the SIM or USIM and passed to the User Equipment (UE), where they are used. At the network end, the session keys are created in the AuC and passed to other network nodes, where they are used.

In the explanation below, the term “serving node” is used to refer to whichever network node handles the session keys. Typically, the serving node will be the endpoint of radio interface encryption, such that user data is encrypted in the mobile device and decrypted in the serving node, or vice versa. There may be more than one serving node.

All of 2G, 3G and 4G use an Authentication and Key Agreement (AKA) algorithm, which has two functions (implemented simultaneously). Firstly, the SIM authenticates itself to the network using the long-lived key. In 3G and 4G, the network also authenticates itself to the mobile terminal using the long-lived key. Secondly, new values of the short-lived session keys are derived from the long-lived key. In 4G the second, session key derivation part is a little more indirect and complex, but still essentially the same picture applies.

The short-lived session keys are desirably kept secret, so as to prevent eavesdropping for instance. Nonetheless, these keys are less highly protected than the long-lived key. Session keys are passed from the (U)SIM to the UE and are more exposed than the long lived key for two reasons. Firstly, the UE is less secure than the (U)SIM and secondly, an attacker with access to the interface between the (U)SIM and the UE could read the keys in transit. Similarly at the network, session keys are passed from the AuC to the serving node or nodes, and are more exposed than the long lived key, for similar reasons as at the mobile terminal. The serving nodes are less secure than the AuC and an attacker with access to the signalling interface between the AuC and the serving nodes could read the keys in transit. For these reasons, session keys are typically updated quite frequently.

Strong authentication desirably includes a certain minimum amount of data transmission from the network to the mobile terminal and from the mobile terminal to the network. Since the respective network nodes may be 100s or 1000s of km distant from the UE, each authentication operation therefore involves a communications overhead that is significant for low-latency processes.

An approach that achieves high (or at least acceptable) security with lowered latency is therefore highly desirable.

Summary of the Invention

Against this background, there is provided a method for providing authentication for a roaming mobile terminal in accordance with claim 1. Preferably, Kmed may be stored in a node closer to the mobile terminal. In one example implementation, the mobile terminal may be roaming. Preferably, the serving network node will be closer (or have a shorter / faster signalling path) to the mobile terminal. The serving network node may be a node that provides a direct communication connection between the mobile terminal and cellular network. It may be the mobile base station, eNodeB or other cellular interface. In a roaming example, the serving network node may be a node or base station of a visited network. In a mobile edge computing (MEC) architecture the serving network node may be a node that provides the edge services (i.e. provides direct services to the mobile terminal).

There is also provided a method for providing authentication for a mobile terminal in accordance with claim 9. In one or more example implementations, the session communication security may not be all the way from mobile terminal to DSS. Instead there may be a serving network node in between, and: the DSS may generate an authentication vector, which may include session keys, and send it to the serving network node; the serving network node may send part of the authentication vector (not including the session keys) on to the mobile terminal; the mobile terminal (or the SIM, USIM or equivalent within it) may derive the session keys from the authentication vector it has received and its stored Ki’; now the mobile terminal and the serving network node both have session keys, and can use them to protect the session communications.

There is also provided a method of protecting communications between a serving network node and a mobile terminal, facilitated by a home network node (HSS), in accordance with claim 21. Advantageously, the shared secret, or keys directly derived from the shared secret may be used to encrypt and/or integrity protect subsequent communications. Preferably, the mobile may terminate a conversation or communication with the network unless a message is received by the mobile terminal (which the serving network node can verify came from the home network) confirming that the session is authenticated. Preferably, the mobile terminal may cache the Vpub of the visited network if it receives an authenticated OK message from the home network. Preferably, Vpub may be broadcast.

There is also provided a computer program in accordance with claim 24, a network entity in accordance with claim 25 and a mobile terminal component (such as a UE or a secure/subscriber specific part, like a SIM) in accordance with claim 26. The invention may also be embodied in the form of programmable logic, firmware or other configurable system. Other preferred features are disclosed with reference to the claims and in the description below.

The mobile terminal may be a cellular phone, a smartphone, a feature phone, a tablet or any other cellular device.

Security key management is provided between a cellular network and a mobile terminal. The mobile terminal and an authentication management node of the cellular network both store a common security key (such as the existing, K or K,). A key management message is communicated between the cellular network and the mobile terminal. In response to the communication, an intermediate security key specific to the mobile terminal is generated using the stored common security key. The intermediate key may be stored at a node of the cellular network which is closer to the mobile terminal than the authentication management node. A session security key is generated using the intermediate security key, for securing (by cryptographic and/or integrity protection) a communications session between the cellular network and the mobile terminal.

The mobile terminal typically comprises: a User Equipment (UE) part; and an associated secure or subscriber-specific part. Typically, the secure or subscriber-specific part comprises a Subscriber Identity Module (SIM) part (which may be a SIM, USIM,, a 5G equivalent of a SIM or USIM, ISIM, SIM application or another subscriber-specific component).

In contrast with the two-level hierarchy of keys in the existing 2G/3G mobile communications security architecture, a three-level key hierarchy is proposed. The common security key is preferably a long-lived key, whilst the intermediate security key is typically short-lived by comparison, but normally longer-lived than existing session keys.

We therefore also refer to the intermediate security key as a medium term key. However, the intermediate security key may be generated in the same way as an existing session key, for example including an AKA procedure based on the long-lived key. In other words, an authentication procedure may be carried out between the cellular network and the mobile terminal using the common security key in response to the key management message (as part of the intermediate key generation). One or more even shorter-lived session keys are generated from the intermediate key and used for session security (encryption/decryption and/or integrity protection). This may be more frequent than generation of the intermediate key. Advantageously, it need not require an AKA procedure. Authentication and session key generation can therefore be separated and/or decoupled in this way. The session key may also be generated in response to the key management message. Using three key hierarchical levels provides a way in which rekeying can be done often enough to satisfy security requirements but with significantly lowered data transmission requirements, greatly reducing battery drain.

By introducing a medium-term key that is preferably securely stored and allowing authentication to be separated from session key derivation, session keys can be updated as frequently as required with lower latency.

At the network, the intermediate security key is normally generated at the authentication management node. It may be stored at one or more of: the authentication management node; a proxy node for the authentication management node; and a serving node of the cellular network, having a Secure Execution Environment (SEE). For the greatest latency benefits, it will be stored at a serving node of the cellular network, because that will typically be physically closer to the mobile terminal, and hence have the shortest signalling path to the mobile terminal. The session security keys are then generated by the node storing the intermediate security key.

At the mobile terminal, the intermediate security key is typically generated at the secure and/or subscriber-specific part. Moreover, it may be stored at the secure and/or subscriber-specific part and it is preferably not passed to the UE part. In the preferred embodiment, the session security key is generated at the secure and/or subscriber-specific part. It may be passed to the UE part, particularly to allow secured communication between the mobile terminal and cellular network.

Brief Description of the Drawing

The invention may be put into practice in various ways, one of which will now be described by way of example only and with reference to the accompanying drawing in which:

Fig. 1 shows a flowchart of a method for providing authentication for a roaming mobile terminal;

Fig. 2 shows a flowchart of a method for providing authentication for a mobile terminal;

Fig. 3 shows a flowchart of a method of protecting communications between a home network (HSS) and a mobile terminal; and

Fig. 4 shows a flowchart of a further method of protecting communications between a home network (HSS) and a mobile terminal.

Detailed Description of the Preferred Embodiments

Some general concepts of secure communications are provided within GB1507708.4 filed 6 May 2015 and EP16168500.3 filed 5 May 2016. Specific reference is made to the concepts in these documents of using a medium-term key. A key idea expanded within this disclosure is to use the medium-term key as well as long-term and short-term keys. In particular, the medium-term key may allow authentication and session key derivation to be separated and brought closer in time and/or distance to the mobile terminal in order to reduce latency. Whenever authentication is performed, a new medium-term (intermediate) key may be derived from the long-term key. Whenever a new session key is demanded (to allow secured communication to take place), a new short-term session key is derived from the medium-term key. The medium term key is stored securely, for example, remaining in the (U)SIM. Some form of key management message may be used to coordinate the derivation of new keys between the mobile terminal and cellular network.

The derivation of a short-term session key from a medium-term key may be only a key derivation operation, not also authentication operation. As a result, the volume of data transmitted to allow session key derivation can be greatly reduced, hence further reducing the latency of this operation. In addition, since the derivation request can be sent in a single message to the mobile terminal, a round-trip protocol is not required, and latency is again lowered..

The method may be implemented as a computer program (or an alternative hardware, software, firmware or combination thereof, as discussed herein). Also provided may be a network entity of a cellular network and/or a mobile terminal component (UE and/or SIM part), with structural features corresponding with the approach described herein. 1. It may be possible to combine low latency on the user plane with high latency on the signalling plane. User plane latency can be minimized by re-using an old security association (SA), while in the meantime running AKA and acquiring a new security association.

This would still impose a high latency at initial attachment to a network (before the first SA is established), and would require persistent caching of old SAs by both the UE and visited network, so weakening security (there is more risk of an old key leaking and being abused). Further, if either the mobile terminal (UE) or visited network node has purged the old SA, the user plane may have to wait while a new SA is established. This may be unacceptable for some use cases. 2. If low latency is also required on the signalling plane, then the solution of “data efficient re-keying” discussed in 3GPP TR 33.860 {Annex B2) could allow for low latency re-keying of a security association, based on an intermediate key Kmed held by both the visited network and the UE (e.g. within the UICC, SIM or other secure element).

Figure 1 illustrates an example implementation. The UE attempts to join the visited network by providing its subscriber identifier. This is passed to the home network, which in response provides material allowing an intermediate security key (Kmed) specific to the UE to be derived or generated. Kmed is the medium-term key and is derived at the UE and visited network. Session keys are derived based on Kmed and other checks may be made (e.g. SRES=RES). The session keys are short or shorter lived than Kmed.

In the example shown in Figure 1, a key derivation counter (KDCTR) or session key sequence number (SKSN) may be used, which in this example may be two bytes in length but other lengths may be used. KDCTR is equivalent to SKSN in Figure 1. KDCTR starts at 0 whenever a new medium-term key is created, and it will increment. Relatively frequently (once every minute, every 10 minutes, every hour or every day, for example), the mobile device and visited network agree a new incrementing value of KDCTR. There are various ways to do this, as will be discussed below. The mobile device passes the new KDCTR value to the (U)SIM. If the new KDCTR is greater than the previous one, then the SIM derives a new session key from the medium-term key and KDCTR. The (U)SIM then returns the session key to the mobile device (the UE). The session key is then used for encryption on the radio interface. If the new KDCTR is less than or equal to the previous one, the (U)SIM rejects it. That way, even direct control of the mobile device (UE) may not be sufficient to make the (U)SIM release either previous or future values of the session key. As well as the session key used for encryption on the radio interface, there may be another session key used for integrity protection of signalling messages (corresponding with IK in existing 3G implementations).

Unlike with authentication operations in 3G and 4G, it is not necessary to integrity protect the agreement of the new KDCTR value. An attacker might be able to trick the endpoints into raising KDCTR to its maximum value, but the denial of service that that would create would be very short lived and immediately rectified with a new full authentication operation. KDCTR is desirably agreed between the device and the serving node. There are a number of ways that this might be done. For example, it could be sent from the device to the serving node. More preferably (from a device battery perspective), it could be sent from the serving node to the device. Some data efficiency and latency optimisation may be possible, such as: only a few least significant bits are sent from one end to the other, and it is assumed that the remaining bits can be kept synchronised; only a few least significant bits are usually sent from one end to the other, and occasionally a slightly longer message is sent to update the remaining bits; and some sort of already existing packet counter or similar value may be (partially) re-used as the KDCTR. 3. Another low latency solution may be to delegate some of the functions of the HSS to the visited network. We might call it a Delegated Subscriber Server (DSS). There will be only one “real” HSS, but there could be multiple DSSs. Using the GSM term “Ki” for the long term subscriber secret key: • Ki remains only in the HSS.

Each DSS needing to authenticate this subscriber receives a key Ki’, derived from

Ki in a one-way fashion. No DSS should be able to work out the actual Ki, nor the Ki’ that’s provided to any other DSS. • The authentication and key agreement algorithm takes Ki’ as input. The UICC (or its 5G equivalent) also has the necessary information to derive Ki’. • Ki’ could be derived just once for any DSS, or could be refreshed periodically. This example implementation is shown in figure 2. Subscriber identifiers may be sent in advance of the mobile terminal arriving at the visited network. For example, a batch of expected UEs subscriber identities may be sent. This may be used to set up a network slice for a set of devices or roaming devices from a particular home network, for example. 4. A further possible solution could be to use public key authentication of the subscriber, and to replicate the subscriber’s public key from the HSS to the visited network. This would be a major change from previous generations of AKA, but could apply to some 5G-only services.

These solutions would still require a round-trip to the core of the visited network, so would be incompatible with ultra-low latencies (<1 ms). Meeting these ultra-low latency requirements may be unachievable with any real-time solution for AKA (authentication and key agreement). 5. In a further enhancement, temporary sessions may be allowed without full authentication, such that authentication of the session follows later (after transmission/receipt of data has already started) and sessions are torn down if the authentication fails.

As illustrated in figure 3, a further solution is to allow attachment to the (visited) network via a fast key exchange, and then verify a MAC or signature on the key exchange after transmission/receipt of user plane data has already started. As one example: the eNodeB (or equivalent) could persistently broadcast a public key, such as a public Diffie-Hellman (DH) exponent. Any reference to Diffie-Hellman in this disclosure should be understood to include Elliptic Curve Diffie-Hellman. The UE could generate its own key-pair and compute a shared secret (e.g. DH shared secret) while in idle mode. On moving to active mode, the UE could immediately transmit its own public key (signed or MAC’d using the underlying subscription key) and use the shared secret to immediately encrypt/integrity protect data. The eNodeB could then immediately derive the same shared secret, and use this to decrypt/verify data from the UE, while simultaneously referring the UE’s signature or MAC to the HSS (or a DSS) for verification.

Advantageously, once the verification has completed, the UE may be granted more privileged or personalized access (for example to billable services, or to receive mobile terminated calls or messaging, or access to voicemail). A further enhancement is shown in figure 4. To provide some quick authentication (and so reduce the risk of temporary rogue sessions) the UE could use a key-pair that it has previously used with the network, or has pre-emptively registered with the network (e.g. during a previous attachment). Similarly, on handovers between cells, the UE could re-use a previous keypair when connecting to the target eNodeB (and the source eNodeB can pass the UE's public key to the target eNodeB, without a need to refer back to the core). To help protect the subscriber from false base stations, the initial broadcast key should be signed by a visited network private key, and the UE should cache the verified visited network public key from any previous attachment to the same network.

Advantageously, if the UE has a choice of nodes to access, and some of them are signed using a cached key, it may connect to one of those which can be verified. (If none of them can be verified, the UE may attempt to connect to one anyway, and hope authentication subsequently succeeds). Also, if the network can recognize the UE using a cached public key, then it may be able to grant some sorts of personalized access before the verification with the home network has completed.

Timing of crypto-operations on the user plane may is still be a problem, but can be mitigated by: 6. Performing most of the heavy crypto pre-emptively (e.g. in idle mode) and moving the real-time encryption/integrity operations to a lower layer of the stack. 7. For some services, it may be acceptable just to encrypt with a fast stream cipher (and omit integrity protection). 8. Or security of user plane data may need to be dropped entirely for some ultra-low latency services, with only intermittent integrity checks conducted via the signalling plane (for example, to keep track of how many packets/bytes have been transmitted or received by the UE).

These solutions provide either for moderately low latency on the user plane with some cost in security (solution 1), or for moderately fast authentication and key agreement on the signalling plane (solutions 2-4), or for fast key agreement, but with delayed authentication (solution 5).

Solutions 6-8 also address ultra-low latency requirements on the user plane, while accepting some further compromises to security.

The functionality described herein with respect to a SIM need not be implemented only on a SIM. The skilled person will appreciate that alternatives to a SIM are possible. Some or all parts of the functionality described herein with respect to a SIM could be implemented on another component of the mobile terminal, for example in cases where the mobile terminal does not include a SIM part. In particular, the same principle as applied to a SIM could apply if any other secure computation component were used (such as a Trusted Execution Environment or Secure Element) as part of the mobile terminal.

In principle, the session key or keys could be retained in the SIM rather than passing them to the UE. This may mean, though, that all of the encryption, decryption, integrity protection or integrity verification of user traffic or signalling messages would then be carried out by the SIM. In turn, all of the user traffic (which can be at a high data rate) would be passed in real time over the UE-to-SIM interface and back again. Current SIM devices are not equipped to handle such high transfer and processing rates, so this may not currently be a practical approach.

Although the embodiments have been described with the mobile terminal roaming, the mobile terminal may be operating solely within a home network. In this case, the visited network may instead be a serving network node of the home network.

Claims

1. A method for providing authentication for a mobile terminal, wherein the mobile terminal and an authentication management node within a core network of a cellular network both store a common security key, the method comprising the steps of: communicating a key management message between the core network and a serving network node in response to which, an intermediate security key (Kmed) specific to the mobile terminal is generated, derived or recovered within the serving network node; communicating a key management message between the serving network node and the mobile terminal in response to which, the intermediate security key (Kmed) specific to the mobile terminal is generated, derived or recovered within the mobile terminal; and generating a session security key using the intermediate security key (Kmed), for securing a communications session between the serving network node and the mobile terminal.

2. The method of claim 1 further comprising the step of: the mobile terminal providing the serving network node with a subscriber identifier associated with the intermediate security key (Kmed), wherein the key management message between the core network and a serving network node includes the subscriber identifier.

3. The method according to claim 1 or claim 2 further comprising the steps of: generating or selecting a session key sequence number (SKSN); and generating or deriving a new session key from the session key and session key sequence number (SKSN).

4. The method according to any previous claim further comprising the step of protecting communications between the mobile terminal and the serving network node using the session key or new session key.

5. The method of according to any previous claim, wherein the step of generating the session security key is performed in response to the communication of the key management message between the serving network node and the mobile terminal.

6. The method according to any previous claim, further comprising: carrying out an authentication procedure between the serving network node and the mobile terminal using the common security key in response to the communication of the key management message between the serving network node and the mobile terminal.

7. The method of claim 6, wherein an authentication procedure between the mobile terminal and the core network is not carried out when the session security key is generated and/or used.

8. The method according to any preceding claim, wherein the step of generating a session security key comprises: generating a session encryption key using the intermediate security key for encryption and/or decryption of communications session between the serving network node and the mobile terminal; and generating an integrity protection key using the intermediate security key, for integrity protection of the communications session between the serving network node and the mobile terminal.

9. The method according to any previous claim, wherein the serving network node is closer to the mobile terminal than the authentication management node.

10. The method according to any previous claim, wherein a signalling path between the mobile terminal and the serving network node is shorter and/or faster than a signalling path between the mobile terminal and the core network.

11. The method according to any previous claim, wherein the mobile terminal is roaming, the core network is within a home network and the serving network node is within a visited network.

12. A method for providing authentication for a mobile terminal, wherein the mobile terminal and an authentication management node of a first subscriber server both store a common security key (Ki), the method comprising the steps of: providing subscriber identity of the mobile terminal to a first subscriber server (HSS) from a second subscriber server (DSS); deriving, generating or recovering key material (Ki’) from at least the common security key (Ki) associated with the provided subscriber identity; share the key material (Ki’) between the second subscriber server (DSS) and the mobile terminal having the provided subscriber identity; and secure communications between the mobile terminal and the second subscriber server (DSS) using the key material (Ki’) or further key material derived at least from the key material (Ki’).

13. The method according to claim 12, wherein the further key material derived from the key material (Ki’) is shared between the second subscriber server (DSS) and the mobile terminal via a serving network node.

14. The method of claim 12 or claim 13, wherein the mobile terminal is roaming, the first subscriber server (HSS) is within a home network and the second subscriber server (DSS) is within a visited network.

15. The method according to any of claims 12 to 14, wherein the second subscriber server (DSS) performs any of the functions of an AuC, HLR or HSS without further communication with the first subscriber server (HSS).

16. The method according to any of claims 12 to 15, wherein the further key material is a session key.

17. The method according to any of claims 12 to 16, wherein key material (Ki’) is further derived, generated or recovered from an identifier of the second subscriber server (DSS).

18. The method according to any of claims 12 to 17, wherein a plurality of subscriber identities of mobile terminals are provided to the first subscriber server (HSS) from a second subscriber terminal (DSS) at the same time, and further wherein key material (ΚΓ) is derived, generated or recovered for each provided subscriber identity of the plurality of subscriber identities.

19. The method according to any of claims 12 to 18, wherein the key material (Ki’) is derived at the first subscriber server (HSS) and provided to the second subscriber (DSS).

20. The method according to any of claims 12 to 19, wherein the key material (Ki’) is derived at the second subscriber server (DSS),

21. A method of protecting communications between a serving network node and a mobile terminal having an identifier and associated mobile terminal public key (Upub) and corresponding private key (Upriv), the method comprising the steps of: broadcasting by the serving network node (e.g. visited network node) a node public key (Npub) having a corresponding node private key (Npriv); whilst a mobile terminal is idle and/or before communicating on a user plane of the network (e.g. visited network) the mobile terminal: receiving the broadcast node public key (Npub); and generating, receiving or deriving using the node public key (Npub) and the mobile terminal private key (Upriv) a shared secret; generating a session key from the shared secret; the serving network node: receiving or retrieving at the serving network node the mobile terminal public key (Upub), together with associated authentication data; generating, receiving or deriving the shared secret using the node private key (Npriv) and the received mobile terminal public key (Upub); and generating a session key from the shared secret.

22. The method of claim 21 further comprising the step of using the shared secret, or key material derived from the shared secret, to encrypt and/or integrity protect subsequent communications.

23. The method of claim 21 or claim 22 further comprising the steps of: initiating communications between the mobile terminal and the serving network node protected by the session key; authenticating the mobile terminal at a network core (e.g. a home network) based on the identifier of the mobile terminal and authentication data associated with the mobile terminal public key (Upub) (e.g. signature or MAC); and if authenticated then continuing with communications between the mobile terminal and the serving network node (e.g. in a visited network) protected by the session key; and if not authenticated then terminating communications between the mobile terminal and the serving network node.

24. The method of claim 23 further comprising the step of: providing the mobile terminal with further access to data or functions (e.g. more sensitive functions or personalised data) following authentication of the mobile terminal.

25. The method according to any of claims 21 to 24 further comprising the step of the mobile terminal terminating communications unless a message is received by the mobile terminal confirming that the session is authenticated.

26. The method of claim 25, wherein the message is verified as being sent by the network core (e.g. home network HSS).

27. The method according to any of claims 21 to 26, wherein the broadcasted node public key (Npub) is signed by a private key (Vpriv) of the network (e.g. visited network), the private key (Vpriv) having a corresponding public key (Vpub).

28. The method of claim 27, wherein the corresponding public key (Vpub) is broadcast.

29. The method of claim 27 or claim 28 further comprising the step of the mobile terminal caching the corresponding public key (Vpub).

30. The method of claim 29, wherein after caching then providing the mobile terminal with further access to data or functions (e.g. more sensitive functions or personalised data) following authentication of the mobile terminal.

31. The method according to any of claims 27 to 30, wherein whilst the mobile terminal is idle and/or before communicating on a user plane of the network the mobile terminal checks the signature of the node public key (Npub) against the public key (Vpub) of the network.

32. The method according to any of claims 21 to 31 further comprising the step of the mobile terminal selecting (e.g. preferentially) a node where it can verify the signature on the Npub using a cached Vpub.

33. The method according to any of claims 21 to 32, wherein the mobile terminal public key (Upub) is retrieved by the serving network node from a cache of mobile terminal public keys.

34. The method according to any of claims 21 to 33, wherein the mobile terminal public key (Upub) is retrieved by the serving network node from a further node of the network,

35. The method according to any of claims 21 to 34 further comprising the step of a further network node caching the mobile terminal public key (Upub).

36. The method according to any of claims 21 to 35 further comprising the step of providing the mobile terminal public key (Upub) to a further node of the network.

37. The method according to any of claims 21 to 36, wherein the mobile terminal is roaming and wherein the serving network node is a node of a visited network.

38. The method of claim 37, wherein the network core is within a home network.

39. A computer program, configured when operated by a processor to perform the method of any preceding claim.

40 A network entity of a cellular network, configured to operate in accordance with the method of any one of claims 1 to 38.

41. A mobile terminal component, configured to operate in accordance with the method of any one of claims 1 to 38.