Operator-assisted key establishment

Abstract

The invention relates to a method and system for key distribution and encryption/decryption. An encryption key (K.sub.enc) is derived in a terminal. The encryption key is applied by the terminal for encrypting at least a part of data included in an application message for an application server transmitted over a network. The terminal and the network both have access to a first key (K.sub.1). The terminal and the server both have access to a second key (K.sub.2). The encryption key is derived at the terminal using the first key and the second key. The first key or the derivative thereof is received at the server. The encryption key for decrypting the application message encrypted by the terminal is derived in the server using the shared second key and the received first key of the derivative thereof.

Claims

1. A terminal for deriving a cryptographic key, the terminal comprising: a processor configured for deriving the cryptographic key using a first key and a second key, wherein the first key is received by the terminal from a network node in a network or derived by the terminal based on a parameter received from the network node, wherein at least one of the first key or the parameter is generated by the network; wherein the cryptographic key is applicable by the terminal for at least one of encrypting at least a part of data included in an application message for an application server transmitted over the network or authenticating the part of data included in the application message, wherein the terminal and the network both have access to the first key, wherein the terminal and the application server both have access to the second key, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

2. The terminal according to claim 1, wherein deriving the cryptographic key using the first key and the second key comprises: deriving a partial key using the first key and a parameter associated with a communication session between the terminal and the network; and deriving the cryptographic key using the partial key and the second key.

3. A Universal Subscriber Identity Module configured for use within a terminal, the Universal Subscriber Identity Module comprising a processor configured for deriving a cryptographic key using a first key and a second key, wherein the first key is received by the Universal Subscriber Identity Module from a network node in a network or derived by the Universal Subscriber Identity Module based on a parameter received from the network node, wherein at least one of the first key or the parameter is generated by the network; wherein the cryptographic key is applicable by the terminal for at least one of encrypting at least a part of data included in an application message for an application server transmitted over the network or authenticating the part of data included in the application message, wherein the Universal Subscriber Identity Module and the network both have access to the first key, wherein the Universal Subscriber Identity Module and the application server both have access to the second key, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

4. An application server for deriving a cryptographic key, the server configured for storing a second key, the application server comprising: a processor configured for obtaining a first key or a derivative of the first key, and for deriving the cryptographic key using the obtained first key or the derivative of the first key and the second key, wherein the cryptographic key is applicable by the application server for at least one of decrypting at least a part of data included in an application message for the application server transmitted from a terminal over a network or authenticating the part of data included in the application message, wherein the terminal and the network both have access to the first key, wherein the second key is shared between the terminal and the application server, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

5. The application server according to claim 4, wherein the derivative of the first key comprises a partial key derived using the first key and a parameter associated with a communication session between the terminal and the network.

6. The application server according to claim 4, wherein obtaining the first key or the derivative of the first key comprises: at least one of: (i) receiving the first key or the derivative of the first key from the network, or (ii) receiving the application message including the first key or the derivative of the first key, and extracting the first key or the derivative of the first key from the received application message.

7. One or more non-transitory computer-readable storage media including instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising: deriving a cryptographic key using a first key and a second key, wherein the first key is received from a network node in a network or derived based on a parameter received from the network node, wherein at least one of the first key or the parameter is generated by the network, wherein the cryptographic key is applicable by a terminal for at least one of encrypting at least a part of data included in an application message for an application server transmitted over the network or authenticating the part of data included in the application message, wherein the terminal and the network both have access to the first key, wherein the second key is shared between the terminal and the application server, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

8. One or more non-transitory computer-readable storage media including instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising: obtaining a first key or a derivative of the first key; retrieving a second key from a storage on an application server; and deriving a cryptographic key using the obtained first key or the obtained derivative of the first key and the second key, wherein the cryptographic key is applicable by the application server for at least one of decrypting at least a part of data included in an application message for the application server transmitted from a terminal over a network or authenticating the part of data included in the application message, wherein the terminal and the network both have access to the first key, wherein the second key is shared between the terminal and the application server, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

9. A method for deriving a cryptographic key in a terminal, the method comprising: deriving the cryptographic key using a first key and a second key, wherein the first key is received by the terminal from a network node in a network or derived by the terminal based on a parameter received from the network node, wherein at least one of the first key or the parameter is generated by the network, wherein the cryptographic key is applicable by the terminal for at least one of encrypting at least a part of data included in an application message for an application server transmitted over the network or authenticating the part of data included in the application message, wherein the terminal and the network both have access to the first key, wherein the second key is shared between the terminal and the application server, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

10. The method according to claim 9, wherein deriving the cryptographic key using the first key and the second key comprises: deriving a partial key using the first key and a parameter associated with a communication session between the terminal and the network; and deriving the cryptographic key using the partial key and the second key.

11. A method for deriving a cryptographic key in an application server, the method comprising: obtaining a first key or a derivative of the first key; retrieving a second key from a storage in the application server; and deriving the cryptographic key using the obtained first key or the obtained derivative of the first key and the second key, wherein the cryptographic key is applicable by the application server for at least one of decrypting at least a part of data included in an application message for the application server transmitted from a terminal over a network or authenticating the part of data included in the application message, wherein the terminal and the network both have access to the first key, wherein the second key is shared between the terminal and the application server, wherein the network comprising the network node does not have access to the second key and the cryptographic key, and wherein the network is a telecommunications network connecting the terminal to the application server.

12. The method according to claim 11, wherein the derivative of the first key comprises a partial key derived using the first key and a parameter associated with a communication session between the terminal and the network.

13. The method according to claim 11, wherein obtaining the first key or the derivative of the first key comprises: at least one of: (i) receiving the first key or the derivative of the first key from the network, or (ii) receiving the application message including the first key or the derivative of the first key, and extracting the first key or the derivative of the first key from the received application message.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) In the drawings:

(2) FIG. 1 is a schematic illustration of a 4G telecommunications network connecting terminals to an application server;

(3) FIG. 2 is a schematic illustration of authenticating a terminal to a network according to prior art;

(4) FIGS. 3A-3C are schematic illustrations of a terminal, an application server, and a network node, respectively, according to an embodiment of the invention; and

(5) FIGS. 4-6 provide schematic illustrations of key distribution operations in accordance with various embodiments of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

(6) FIG. 1 shows a schematic illustration of a telecommunications network 1. The telecommunications network 1 allows data sessions between a server 2 and a terminal 3 over a data network 4, wherein access of the terminal to the telecommunications network 1 is wireless.

(7) In the telecommunications network of FIG. 1, three generations of telecommunications networks are schematically depicted together for purposes of brevity. A more detailed description of the architecture and overview can be found in 3GPP TS 23.002 which is included in the present application by reference in its entirety.

(8) The lower branch of FIG. 1 represents a GPRS or UMTS telecommunications network comprising a Gateway GPRS Support Node (GGSN), a Serving GPRS Support Node (SGSN) and a Radio Access Network (RAN). For a GSM/EDGE radio access network (GERAN), the RAN comprises a Base Station Controller (BSC) connected to a plurality of Base Station Transceivers (BTSs), both not shown. For a UMTS radio access network (UTRAN), the RAN comprises a Radio Network Controller (RNC) connected to a plurality of NodeBs), also not shown. The GGSN and the SGSN are conventionally connected to a Home Location Register (HLR) that contains subscription information of the terminals 3. In the figure, the HLR is combined with an authentication centre (AuC) for authenticating terminals 3 in the network.

(9) The upper branch in FIG. 1 represents a next generation telecommunications network, commonly indicated as Long Term Evolution (LTE) or Evolved Packet System (EPS). Such a network comprises a PDN Gateway (P-GW) and a Serving Gateway (S-GW). The E-UTRAN of the EPS comprises evolved NodeBs (eNodeBs or eNBs) providing wireless access for a terminal 3 that is connected to the S-GW via a packet network. The S-GW is connected to a Home Subscriber Server HSS and a Mobility Management Entity MME for signalling purposes. The HSS includes a subscription profile repository and an authentication centre (AuC).

(10) Further information of the general architecture of a EPS network can be found in 3GPP TS 23.401.

(11) Whereas the invention as defined in the appended claims is generally applicable to all of the above-described networks, a more detailed description of embodiments of the invention will be provided below for an LTE network. Persons skilled in the art will readily recognize adaptations necessary to implement the ideas discussed herein in other networks and architectures.

(12) For an LTE network, the MME is the network node typically controlling the connection between the telecommunications network 1 and the terminal 3. It should be appreciated that the telecommunications network 1 generally comprises a plurality of MMES, wherein each of the MMES is connected typically to several BSCs/RNCs to provide a packet service for terminals 3 via several eNodeBs.

(13) In an M2M environment, a single server 2 normally is used for communication with a large number of terminals 3. Individual terminals 3 can be identified by individual identifiers, such as an IP address, an International Mobile Subscriber Identity (IMSI) or another terminal identifier.

(14) Before the terminal 3 can access services provided by the network or transmit application messages to the server via a network node such as the MME node for the LTE network, the terminal 3 needs to be authenticated to the network. A manner for providing such authentication is known, but is briefly summarized in FIG. 2 where the terminal 3 is represented as comprising an M2M device and USIM.

(15) As shown in FIG. 2, in step 1, the terminal 3 initiates the attach procedure to inform the telecommunications network that it wants to access network's services by transmitting an Attach Request containing terminal's IMSI to the MME. In step 2, the MME transmits a request to the HSS. Upon receipt of the Attach Request, the HSS generates a random number RAND, a network authentication token AUTN, a session key K.sub.ASME, and a Response XRES. The network authentication token AUTN has the purpose of allowing the terminal to authenticate the network thereby preventing so-called a “false base station” attack, wherein malicious base station which in reality does not belong to the network. The AUTN includes the result of performing an XOR operation on a sequence number SQN and a secret Anonymity Key AK, SQN⊕AK. An Authentication Management Field AMF and a Message Authentication Code MAC are used for authenticating the message to the terminal 3. In step 3, the HSS transmits the RAND, the K.sub.ASME, the XRES, and the AUTN to the MME. The MME stores these parameters. In step 4, the MME transmits the RAND, the AUTN, and the KSI.sub.ASME to the terminal 3, which, in step 5, passes the RAND and the AUTN to it's USIM and, in response, in step 6, obtains a response RES derived by the USIM. In step 7, the terminal 3 generates the session key K.sub.ASME based on the Integrity Key IK, Cipher Key CK, Serving Network identity SN id, Sequence Number SQN, and Anonymity Key AK. Integrity Key IK and Cipher Key CK are the cryptographic keys generated during AKA by the USIM, and are used in UMTS to protect the communication of UTRAN. In LTE, CK and IK are used as the basis for K.sub.ASME. In step 8, the terminal 3 transmits the RES to the MME. In the last step of the authentication procedure, step 9, the MME checks whether the terminal-generated RES matches the network-generated XRES stored in the MME. When the terminal-generated RES matches the network-generated XRES, the terminal 3 is authenticated to the network and the session key K.sub.ASME shared between the terminal 3 and the MME can be used to encrypt data transmitted from the terminal 3 to the MME. A more detailed description of the authentication procedure is provided in 3GPP TS 33.102 and 3GPP TS 33.401.

(16) Once the terminal 3 has been authenticated with the network, in step 10, the MME stores the security context for the communication session and the terminal 3 may transmit data to the network, including transmitting application messages to the server over the network. The security context may also be stored in the terminal 3.

(17) Now the terminal 3 may setup a PDP Context to communicate to the server 2. In order to secure the communication the terminal 3 and server 2 may setup a secure tunnel. Such secure tunnel, however, provides significant overhead in establishing cryptographic keys and maintaining secure tunnel, as described above. As also described above, the mobile network operator may assist the establishing of session keys between the terminal 3 and the server 2 by implementing GBA, but this also introduces significant overhead.

(18) FIG. 2 illustrates that after a while, the terminal 3 is detached from the network (i.e., the terminal 3 is offline). However, in step 11, the terminal 3 may transmit small amount of data encapsulated in a signalling message by using the method described in WO2010/049437. In step 12, the MME obtains the security context using KSI.sub.ASME and checks NAS-MAC of the signalling message to make sure the message comes from the authenticated terminal, and, in step 13, transmit the data to the server 2, along with the identification of the particular terminal sending the data (M2M_ID). Such data is either sent completely unencrypted or is sent encrypted using a key derived from the session key K.sub.ASME from the terminal 3 to the MME, where the MME decrypts data and forwards it to the server 2 unencrypted. As described previously, these approaches are inappropriate when a particular application demands that the data is encrypted for the entire path between the terminal and the server and when a particular application demands that the MME may not have access to the data.

(19) The present invention is based on the insight that the session key K.sub.ASME, the random number RAND, or other unique parameters established between the terminal 3 and the MME in a particular communication session between the terminal 3 and the MME and stored in step 10 of FIG. 2 or newly generated for a new attachment of the terminal to the network may be reused to derive an encryption key for encrypting data transmitted from the terminal 3 to the server 2.

(20) FIGS. 3A, 3B, and 3C are schematic illustrations of a terminal 3, a network node of the network 1, and a server 2, respectively, according to embodiments of the invention. The functionality of these devices is described in greater detail in association with FIGS. 4-7.

(21) As shown in FIG. 3A, the terminal 3 includes at least a storage 22 for storing a first key K.sub.1 and a storage 24 for storing a second key K.sub.2, where the first key is the secret key shared between the terminal 3 and the MME, and the second key is the secret key shared between the terminal 3 and the server 2. In an alternative embodiment, the first and second keys could be stored in a single storage 22. The storage 22 and/or the storage 24 could be implemented as a secure module such as (U)SIM either within the terminal 3 or outside of the terminal 3 (i.e., be an external storage).

(22) In various embodiments, the first key K.sub.1 may include one or more of the session key K.sub.ASME, the random number RAND, or other unique parameters established between the terminal 3 and the MME in a particular communication session between the terminal 3 and the MME, such as e.g. SQN, AK, SQN⊕AK. The first key K.sub.1 could be either received by the terminal 3 from the MME or derived locally in the terminal 3, possibly based on another parameter received from the MME. The second key K.sub.2 may be e.g. a static secret key shared between the terminal and the server, such as K.sub.M2M.

(23) As further shown in FIG. 3A, the terminal 3 also includes a processor 30 for deriving an encryption key K.sub.enc based on the first and second keys. As illustrated in FIG. 3A and described in greater detail below, there are two alternative techniques that could be implemented in the processor 30 for deriving the encryption key. One technique includes the processor 30 deriving the encryption key directly by applying a generation algorithm A.sub.1 to the first and second keys. Another technique includes the processor 30 first deriving a partial key K.sub.part by applying a generation algorithm A.sub.2 to the first key K.sub.1 and a parameter associated with a communication session between the terminal 3 and the MME, and then deriving the encryption key K.sub.enc by applying a generation algorithm A.sub.3 to the partial key K.sub.part and the second key K.sub.2.

(24) At least part of the functionality of the processor 30 may be included within a USIM within the terminal 3.

(25) In alternative embodiments, one or more of these derivations could be carried out by a processor outside of the terminal 3. For example, in an embodiment where the USIM is used to store one or both of the keys K.sub.1 and K.sub.2 externally to the terminal 3, the USIM could also derive and, possibly, store the partial key K.sub.part and/or the encryption key K.sub.enc.

(26) The terminal 3 further includes an encrypter 33 configured for encrypting at least part of data D to be included in the application message (e.g. the part containing the user data U destined for the server 2) using an encryption algorithm A.sub.4 and the derived encryption key K.sub.enc, thus generating encrypted data ED. The encrypter 33 could, optionally, be included within the processor 30.

(27) The application message AM is formed by including at least the encrypted data ED. In some embodiments, the application message may further include either the first key K.sub.1 or the partial key K.sub.part. Furthermore, preferably, the application message also includes an identifier of the terminal 3, such as the IMSI, which could be transmitted in a manner known per se. The terminal 2 may then transmit the application message to the network node, such as the MME, using a transmitter 34.

(28) FIG. 3B is a schematic illustration of an application server 2. As shown, the server 2 includes at least a processor 40, a storage 45 for storing the second key K.sub.2, and a receiving interface 43, where the receiving interface 43 is configured for receiving the application message AM forwarded by the MME and the processor 40 is configured to derive the encryption key K.sub.enc for decrypting the encrypted part of the application message.

(29) In order to derive the encryption key K.sub.enc, the processor 40 needs to have access to either the first key or the partial key, depending on how the encryption key was derived in the terminal 3. In one embodiment, the first key or the partial key, unencrypted, could be included in the application message generated at the terminal 3 and the processor 40 is configured to extract the first key or the partial key from the application message. In another embodiment, the first key or the partial key could be first encrypted using the second key K.sub.2 as an encryption key and then included in the application message generated at the terminal 3. The server 2 may then extract the first key or the partial key and decrypt it using the second key stored at the server 2. In another embodiment, the server 2 could receive the first key or the partial key, unencrypted, from the network node via a receiving interface 44 or along with the application message via the receiving interface 43. In yet another embodiment, the server 2 could further include a requesting interface 42 for requesting the first key or the partial key from the network node. In such an embodiment, the processor 40 and the requesting interface 42 may be used for authenticating the application server 2 with the network node and, possibly, for transmitting the received IMSI of the terminal 3 from the server 2 to the network node enabling the network node to verify whether the request for the first key or the partial key is authorized. The server 2 would then further contain a receiving interface 44 for receiving the requested first key or partial key.

(30) Processor 40 may apply algorithm A.sub.5 for decrypting the encrypted part of the application message using the derived encryption key K.sub.enc to obtain the data D.

(31) FIG. 3C is a schematic illustration of a network node, such as the MME in an LTE network, for at least receiving the application message, via a receiving interface 52, from the terminal 3 and transmitting the application message, via a transmitting interface 54, to the server 2. Like the terminal 3, the network node has access to the first key K.sub.1 in storage 50. The first key may either be generated at the MME or received from a further network node (e.g. HSS).

(32) In the embodiments where the terminal 3 does not include the first key or partial key in the application message, the network node may be further configured to transmit the first key or the partial key to the server 2. To that end, the network node may include a processor 51 for deriving the partial key by applying the generation algorithm A.sub.2 to the first key and the parameter associated with a communication session between the terminal 3 and the MME.

(33) FIG. 4 provides a schematic illustration of key distribution operation according to one embodiment of the invention. Following authentication of the terminal 3 to the network as described e.g. in steps 1-9 of FIG. 2, in step 1, the processor 30 of the terminal 3 generates a partial key K.sub.part by applying a key generation algorithm A.sub.2 to the first key and a parameter associated with a communication session between the terminal 3 and the MME, such as e.g. an encryption algorithm identification Alg-ID (ENC).

(34) Some exemplary ways for deriving the partial key K.sub.part include the following:
K.sub.part=A.sub.2(K.sub.ASME,Alg-ID(ENC))  (1)
K.sub.part=A.sub.2(RAND,Alg-ID(ENC))  (2)
K.sub.part=A.sub.2(SQN⊕AK,Alg-ID(ENC))  (3)
K.sub.part=A.sub.2(RAND,SQN⊕AK,Alg-ID(ENC))  (4)
K.sub.part=A.sub.2(SQN,Alg-ID(ENC))  (5)
K.sub.part=A.sub.2(RAND,SQN,Alg-ID(ENC))  (6)

(35) Note that the examples (5) and (6) are only possible when the USIM and the AuC derives the partial key since, for security reasons, SQN and AK are typically only available in these network components.

(36) In step 2, the second key K.sub.2 is retrieved from the storage 24 and the processor 30 applies a key generation algorithm A.sub.3 to the generated partial key K.sub.part and the stored second key K.sub.2 to generate an encryption key K.sub.enc.

(37) The key generation algorithms A.sub.2 and A.sub.3 could comprise key derivation functions (KDF) standardized by 3GPP 33.220.

(38) In step 3, the encrypter 33 of the terminal 3 uses the derived encryption key K.sub.enc to encrypt data D that should be transmitted to the server 2. The terminal 3 then forms an application message by including the data D encrypted under K.sub.enc, E.sub.Kenc (D), and, in step 4, the terminal 3 transmits the application message, via the transmitter 34, to the MME.

(39) In a preferred embodiment, the terminal 3 transmits the application message by initiating the attach procedure by the transmission of an ‘Attach Request’ message to the MME containing the IMSI of terminal 3 and the application message.

(40) In step 5, the processor 51 of the MME generates the partial key K.sub.part by applying the key generation algorithm A.sub.2 to K.sub.1 and Alg-ID(ENC). In one embodiment, the processor 51 may generate the partial key upon receipt in the MME of the application message, e.g. encapsulated in the ‘Attach Request’ message, from the terminal 3 via the receiving interface 52. In an alternative embodiment, the processor 51 may generate the partial key K.sub.part even before receiving the application message from the terminal 3 and store it for future use.

(41) Note that, since the MME does not have access to the SQN and AK but only has access to SQN⊕AK, if SQN or AK were used for the derivation of the partial key, as in the above examples (5) and (6), the HSS/AuC needs to be involved when the MME derives the partial key.

(42) In step 6, using the transmitting interface 54, the MME forwards the application message to the server 2 as well as the partial key K.sub.part and, optionally, an identification of the terminal 3 transmitting the application message, M2M_ID. In other embodiments, the MME may provide the partial key to the server 2 separately from the application message, e.g. upon receipt of a request from the server 2 to provide the partial key. In any case, the partial key K.sub.part is transferred unencrypted from the MME to the server 2, while the data D is still encrypted by the encryption key K.sub.enc.

(43) It should be appreciated that the attach request from the terminal 3 may or may not be followed by the actual attach to the network. In principle, such a follow up is not required, since the application message was encapsulated in the attach request and passed on to the server 2.

(44) However, in order to allow further data exchange between the terminal 3 and the network, the attach request may be accepted by the network. In that case, additional steps not illustrated in FIG. 4 may be performed in response to the attach request. These additional steps would include a new AKA and setting up a PDP context. These steps could e.g. be performed after step 4 of FIG. 4.

(45) In step 7, at the server 2, the second key K.sub.2 is retrieved from the storage 45 and, by applying the key generation algorithm A.sub.3 to the received partial key K.sub.part and the retrieved second key K.sub.2, the processor 40 generates the encryption key K.sub.enc. In step 8, the server 2 uses the derived encryption key K.sub.enc to decrypt data D transmitted by the terminal 3.

(46) Possibly, the MME only sends the partial key K.sub.part to the server 2 if the server 2 transmits a request to the MME for receiving the partial key (not specifically shown in FIG. 4). Such a request could include a verifier identifying the server 2 and the IMSI of the terminal 3 which was received by the server 2 as a part of the application message. The MME could then verify whether the request is authorized using the verifier and, only upon successful verification, transmit the partial key to the server 2 over the transmitting interface 54.

(47) In FIG. 5, an alternative operation is illustrated. FIG. 5 differs from FIG. 4 in that the terminal 3 provides the partial key K.sub.part to the server 2 itself, thus eliminating the involvement of the MME for deriving and transmitting this key. Steps 1-3 illustrated in FIG. 5 are analogous to steps 1-3 illustrated in FIG. 4 and, therefore, their discussion is not repeated here.

(48) FIG. 5 differs from FIG. 4 in that the terminal 3 forms an application message by including the partial key K.sub.part in the application message, along with the data encrypted under K.sub.enc, E.sub.Kenc (data). This may be done by e.g. concatenating the partial key with the encrypted data.

(49) Steps 1-3 of FIG. 5 are analogous to steps 1-3 of FIG. 4 and, therefore, the detailed discussion associated with these steps is not repeated here. In step 4, the terminal 3 transmits the application message, now also including the partial key K.sub.part, via the transmitter 34, to the MME.

(50) The MME receives the application message AM via the receiving interface 52 and, in step 6, using the transmitting interface 54, the MME forwards the application message to the server 2. Optionally, the MME could also transmit an identification of the terminal 3 transmitting the application message, M2M_ID, to the server 2. However, for all of the embodiments described herein, such identification could also be included within the application message formed in the terminal 3.

(51) In step 6, the partial key K.sub.part is extracted from the application message received over the receiving interface 43, the second key K.sub.2 is retrieved from the storage 45 and, by applying the key generation algorithm A.sub.3 to the extracted partial key K.sub.part and the retrieved second key K.sub.2, the processor 40 generates the encryption key K.sub.enc. In step 7, the server 2 uses the derived encryption key K.sub.enc to decrypt data U transmitted by the terminal 3. Steps 6 and 7 of FIG. 5 are analogous to steps 7 and 8, respectively, of FIG. 4 and, therefore, the detailed discussion associated with these steps is not repeated here.

(52) In FIG. 6, another alternative operation is illustrated. FIG. 6 differs from FIG. 4 in that the processor 30 of the terminal 3 does not derive a partial key K.sub.part, but, instead, derives the encryption key K.sub.enc directly by applying encryption algorithm A.sub.1 to at least the first key K.sub.1 and the second key K.sub.2.

(53) Some exemplary ways for deriving the encryption key K.sub.enc include the following:
K.sub.enc=A.sub.1(RAND,K.sub.M2M,Alg-ID(ENC))  (7)
K.sub.enc=A.sub.1(SQN⊕AK,K.sub.M2M,Alg-ID(ENC))  (8)
K.sub.enc=A.sub.1(RAND,SQN⊕AK,K.sub.M2M,Alg-ID(ENC))  (9)

(54) Similar to the algorithms A.sub.2 and A.sub.3, the key generation algorithm A.sub.1 could comprise key derivation function (KDF) standardized by 3GPP 33.220.

(55) In step 2, the encrypter 33 of the terminal 3 uses the derived encryption key K.sub.enc to encrypt data D that should be transmitted to the server 2. The terminal 3 then forms an application message by including the data D encrypted under K.sub.enc, E.sub.Kenc (D), and, in step 3, the terminal 3 transmits the application message, via the transmitter 34, to the MME.

(56) Similar to the description in FIG. 4, in a preferred embodiment, the terminal 3 transmits the application message by initiating the attach procedure by the transmission of an ‘Attach Request’ message to the MME containing the IMSI of terminal 3 and the application message. The detailed description associated with encapsulating the application message in the ‘Attach Request’ of FIG. 4 is applicable here, and therefore, is not repeated.

(57) In step 4, using the transmitting interface 54, the MME forwards the application message to the server 2 as well as the first key K.sub.1 and, optionally, an identification of the terminal 3 transmitting the application message, M2M_ID. In other embodiments, the MME may provide the first key to the server 2 separately from the application message, e.g. upon receipt of a request from the server 2 to provide the first key. In any case, the first key K.sub.1 is transferred unencrypted from the MME to the server 2, while the data D is still encrypted by encryption key K.sub.enc.

(58) In step 5, at the server 2, the second key K.sub.2 is retrieved from the storage 45 and, by applying the key generation algorithm A.sub.1 to the received first key K.sub.1 and the retrieved second key K.sub.2, the processor 40 generates the encryption key K.sub.enc. In step 6, the server 2 uses the derived encryption key K.sub.enc to decrypt data D transmitted by the terminal 3.

(59) Similar to FIG. 4, optionally, the MME only sends the partial key K.sub.1 to the server 2 if the server 2 transmits a request to the MME for receiving the first key (not specifically shown in FIG. 4). Such a request could include a verifier identifying the server 2 and the IMSI of the terminal 3 which was received by the server 2 as a part of the application message. The MME could then verify whether the request is authorized using the verifier and, only upon successful verification, transmit the first key to the server 2 over the transmitting interface 54.

(60) Alternatively, in the embodiment illustrated in FIG. 6, the terminal 3 could have included the first key in the application message to the server 2. Since the manner in which the first key could be transmitted by the terminal 3 to the server 2 and how the server 2 would then obtain the encryption key is analogous to how the terminal 3 was configured to transmit the partial key in the application message to the server, described in FIG. 5, in the interests of brevity, these discussions are not repeated here.

(61) It should be appreciated that in the above embodiments, authentication and encryption can be used separately. Authentication is not required to be used every time the terminal 3 needs to send data. In some embodiments, every time the network performs a new AKA, new cryptographic session keys K.sub.enc and K.sub.int for securing the data between terminal 3 and server 2 may be generated. However, in other embodiments, there may be no need to generate an encryption key K.sub.enc every time data is exchanged between terminal 3 and the application server 2. The key K.sub.enc can be re-used as often as the terminal 3 or server 2 desires. Both the terminal 3 and the server 2 can request for a new cryptographic session key to be agreed on (e.g. when the key is thought to be compromised or when a set amount of time has elapsed). The network node may then assist the terminal 3 and the server 2 in establishing a new cryptographic session key as described above.

(62) For clarity reasons only the relevant steps of the security procedures are depicted in FIGS. 4-6. Other procedures like the Identity Request, the IMEI check, the Location Update and the Insert Subscriber Data procedures are not included.

(63) Furthermore, the embodiments shown in FIGS. 4-6 can be expanded by adding integrity to the application messages that are sent by the terminal. To that end, data integrity key K.sub.int may be derived and handled in a manner analogous to the encryption key K.sub.enc. Persons skilled in the art that the discussions for the encryption key K.sub.enc are analogous to the discussions with respect to the integrity key K.sub.int, and therefore, are not repeated here. Embodiments are also possible where both an encryption key and an integrity key are generated. In such embodiments, different algorithms and/or different first and/or second keys could be used to derive the encryption key and the integrity key, but the main inventive ideas of the present disclosure are still analogous for both types of keys.

(64) One embodiment of the invention may be implemented as a program product for use with a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory, flash memory) on which alterable information is stored.