Cyptographic key generation

ES 2 637 313 T3

DESCRIPTION

Cryptographic key generation

Technical field

The present invention generally relates to a technique for generating cryptographic keys. In particular, the invention relates to a cryptographic key generation technique that provides a high level of security.

Background

The Key Authentication and Agreement (AKA) protocol is a challenge-response based protocol that uses symmetric cryptography. The main goals of AKA include mutual authentication by two entities communicating with each other and the establishment of cryptographic keys to protect the communication exchanged between them. A variant of AKA is the AKA of UMTS, included in the security architecture standardized by 3GPP for 3G mobile communication networks in 3G Technical Specification TS 33.102.

The basic concept of UMTS AKA is shown in Fig. 1. With reference to this figure, the UMTS AKA protocol runs between a user equipment (UE) and a network entity (NE). The network entity initiates the AKA by sending a user authentication request to the UE. Along with the request, a random challenge, or random code (RAND), and an Authentication Token (AUTN) are sent to the UE. Upon receipt of the RAND and AUTN, the UE, among other things, calculates an Encryption Key (CK) and an Integrity Key (IK) and then uses them for encryption and integrity functions.

3GPP is also undertaking the standardization of so-called “beyond 3G” communication networks. System Architecture Evolution (SAE) and Long Term Evolution (LTE) are two closely related aspects of the network beyond 3G. Compared to conventional 3G networks, an SAE / LTE-based network may impose higher or / or more security requirements. For example, more cryptographic keys may be needed to secure communication at different levels. The 3GPP has recommended, in another document related to the standard, the TR 33.821 of the 3GPP, a hierarchy of keys to derive more cryptographic keys for use in SAE / LTE.

Fig. 2 shows this hierarchy of keys. At the top of the hierarchy is a K key, a long-term cryptographic key shared between the UE's Universal Subscriber Identity Module (USIM) and the Authentication Center (AuC) that resides on the network. One level lower is a pair of cryptographic keys CK and IK that are derived by the UE, particularly by the USIM thereof, in the same or similar way as the AKA operation of the UMTS mentioned above. Further down the hierarchy is a KASME key that is derived by the UE from the CK, IK, and, if necessary, some other parameters. Once derived, the KASME is transferred from the AuC to the access network, particularly to the Access Security Management Entity (ASME) of the SAE / LTE network, and is then shared between the UE and the network. When the access network is based on LTE technology, the ASME functionalities are managed by a Mobility Management Entity (MME).

The KASME key, and the keys "below" it in the hierarchy, can be derived by applying a certain cryptographic function. For example,

KASME = KDF (CK || IK, 0x02 || PLMN_ID || <other_parameter>) where KDF is based on a Generic Initialization Architecture (GBA) key derivation function (KDF). A GBA KDF is specified in 3G TS 33.220.

The GBA KDF can make use of cryptographic key generation functions such as the Secure Key Generation Algorithm (SHA) key generation functions. Among the many SHA key generation functions, SHA-256 is a highly secure variant since it is considered collision resistant and acts as a pseudo-random function. As its name suggests, SHA-256 is a Secure Key Generation Algorithm key generation function with a summary (output) length of 256 bits. The PLMN_ID is an identifier of the network serving the UE.

It has been found that to achieve a high level of security, it is not enough to base the GBA KDF function primarily on CK and IK only. The rationale for this is the risk that a given UE might get the same CK twice, or two different UE might get the same CK. In such cases, the "uniqueness" of the inputs to the KDF is low, and a collision can occur between different UEs (using the same KASME).

As a general observation, while it is true that KDF (x) produces the same key as KDF (y) if x = y, the inverse may not always hold. That is, even if x A y, it can still happen that KDF (x) = KDF (y). However, this is an unlikely event since the KDF is recommended to be based on SHA-256 which, as mentioned, is designed to be collision resistant. Thus, for the technique described herein, it can be safely assumed that KDF (x) = KDF (y) if and only if x = y. This assumption

ES 2 637 313 T3 allows the technique described herein to focus on ensuring the "uniqueness" of the inputs to the KDF.

The GBA KDF specification standardization body (ETSI / SAGE, the Special Algorithm Expert Group) has pointed out the above issue and recommended including the UE Private User Identity (IMPI) in <other_parameter> to avoid collisions between different UEs. As an additional recommendation, a random code such as RAND can also be included in <other_parameter>. This is described in a statement of coordination from ETSI / SAGE to SA3 of the 3GPP (in the document number S3-030219 of the 3GPP).

However, it has been found that the above recommendations may still not guarantee the “uniqueness” of the entries to the KDF. This can be seen from the discussion above of the security property of the GBA KDF function and its use in SAE / LTE for one and the same UE (eg one and the same IMPI).

First of all, the following basic construction is considered:

KDF (CK, IMPI).

Since it has been assumed that IMPI = IMPI '(when the UE is fixed), this basic construction will lead to collision for two inputs (CK, IMPI), (CK', IMPI ') if and only if CK = CK'.

Second, another construction is considered, which is closer to the actual GBA KDF:

KDF (CK || IK, IMPI).

However, includingIK within the entries does not change the above collision property as one might initially believe. That is, KDF (CK || IK, IMPI) will be equal to KDF (CK '|| IK', IMPI) if and only if CK = CK '. To understand why including IK would not help, it is necessary to consider how CK and IK are produced by the cryptographic algorithm executed in the UE.

The typical UE-side cryptographic algorithm is the Milenage algorithm which is shown in Fig. 9. In Fig. 9, Ek indicates the Advanced Encryption Standard (AES) algorithm, also known as the Rijndael algorithm, which uses the key K (stored in the AuC and the EU USIM). Let us now consider what happens if CK = CK '. Since AES is a permutation (a one-to-one assignment), this implies that the intermediate value (which occurs on the thick arrow) is determined solely by the output of f3 which becomes CK. But this implies that the value of the thick date when the CK occurs must be the same as the value that occurs in the same place when CK 'was produced. This in turn means that the values ​​that occur as input to f4 must be the same and consequently, the same values ​​of f4 must occur. As is often the case, f4 is IK. In this way it has been shown that CK = CK 'yes and only if IK = IK'.

Next, an “improved” construction according to the recommendation of the standardization body (SAGE), that is, that includes the RAND in the inputs, is considered:

KDF (CK || IK, RAND || IMPI).

We assume that CK = CK '(and thus IK = IK'). The use of RAND is expected to ensure uniqueness. However, this is not true. Let's consider again the “relevant” part of the Milenage algorithm that produced the CK and IK from the RAND: As shown in Fig. 9, there is a situation where the value in the thick arrow corresponding to the RAND is the same than the one corresponding to RAND '. But again, AES (Ek) is a permutation so that the inputs must be equal, that is RAND = RAND '. (The fact that AES is dependent on K does not help since a fixed UE is assumed and thus the same K will occur in both cases.)

In other words, it has been shown that (CK || IK, RAND || IMPI) = (CK '|| IK', RAND '|| IMPI) if and only if RAND = RAND'. In the case of SAE / LTE, the PLMN_ID can also include the entries, but since the UE is highly likely to stay on the same network multiple times, this PLMN_ID parameter cannot be relied on for the purpose of ensuring uniqueness.

An alternative approach to trying to avoid a collision could be to use an algorithm other than AES for cryptographic processing of algorithms f3 and f4. Specifically, the previous analysis was based on the fact that AES is a permutation. Therefore it would be possible to use a non-permutation (many-to-one assignment) instead of AES. This is problematic for two reasons. First of all, existing USIMs must be adapted to suit the 3GPP SAE architecture. Second, by choosing a non-permutation function, one actually increases the probability that two outputs of say f3 collide.

The lack of uniqueness of the inputs can be a serious security problem. Since the collision will occur if and only if RAND = RAND ', and since RAND is 128 bits, the collision is expected to occur after about 2^Λ(128/2) = 2^Λ64 authentications (this is the so-called "birthday paradox"). Clearly, this is lower than the GBA target security level (which is 128-bit). For LTE the case is even worse, since LTE is required to provide a 256-bit security level. In this way, the high probability of collision is a significant obstacle to providing the required level of safety in SAE / LTE.

ES 2 637 313 T3

Document WO 2005/032201 A refers to an improved security design for cryptography in mobile communication systems, in particular GSM (Global System for Mobile Communication) and UMTS (Universal System for Mobile Telecommunication) systems. US Patent 7,131,006 B1 generally refers to cryptographic techniques for use in a communication network such as a wireless communication network. US Pat. 2003/053629 A1 refers to computer systems that use a cryptographic protocol to communicate protected content material through a Universal Serial Bus (USB - Universal Serial Bus). Document WO 2008/054320 A2 relates to telecommunications systems and encryption of control messages therein. Document WO 2007/062882 A relates to a technique for supplying encryption information related to the service. The 3GPP 33.105 version 3.4.0 modification request refers to an anonymity key calculation during resynchronization.

Compendium

Accordingly, there is a need for a solution that avoids the aforementioned collisions. The solution should also ideally work with already deployed USIMs and not require replacement of all USIMs.

As a solution, the present description provides a method, a computer program product, a device, a user equipment and a system according to the claims appended to the present description.

According to a first aspect, a method is provided for generating a cryptographic key. The key cryptographic is used to, among other things, protect a communication between two entities. The method is carried out by the first entity. The method is part of a distributed security operation such as an Authentication and Key Agreement (AKA) procedure based on an AKA protocol that is initiated by the second entity. The method comprises providing at least two parameters, which as a whole can be viewed as an input to be provided to a key derivation function, in which the first parameter either comprises or is derived from a set of cryptographic keys that have been calculated by the first entity executing the security operation and in which the second parameter either comprises or is derived from a calculated token by a second entity executing the security operation for the first entity. The method further comprises applying or performing the key derivation function to generate the cryptographic key based on the input provided, in which the cryptographic key is an Access Security Management Entity (ASME), KASME key. The token either comprises or is derived from a Sequence Number (SQN) that indicates the number of times the security operation has been initiated by the second entity for the first entity. Furthermore, the input, which comprises the two parameters as a whole, is unique each time the security operation is started by the second entity for the first entity.

The expression "a parameter comprises X" can mean that the variable X, in its string format, forms the parameter or part of it. The expression "a parameter is derived from X" can mean that the parameter is the result of applying certain functions, such as mathematical functions, to at least one variable X. Examples of functions include, but are not limited to, arithmetic operations, logical operations, string operations, and any combination thereof. The arithmetic operation can be addition, subtraction, multiplication, etc. and any significant combination thereof. The logical operation can be AND, OR, Exclusive OR (xOR), NOT, etc. and any significant combination thereof. The string operation can be Concatenation, Invert, Substitute, and so on. and any significant combination thereof. Also, arithmetic operation, logical operation, and string operation can be combined.

The witness can take many forms. In one case, the SQN itself can be the witness. Alternatively, the token can be derived from the SQN using an algorithm that involves certain mathematical operations, such as at least one of a mathematical operation, a logical operation, and a string operation. For example, the token may comprise or may be derived from an Authentication Token (AUTN) constructed by the second entity based on the SQN and delivered to the first entity. This construction and delivery can be part of the security operation. Specifically, the token may comprise a unique OR of the SQN and an Anonymity Key (AK). The Anonymity Key can be a cryptographic key produced by a key generation function, such as the f5 function that uses a random challenge according to the AKA protocol.

More specifically, the token may be a concatenation of the unique OR of the SQN and the Anonymity Key, an Authentication and Key Management Field (AMF) and a Message Authentication Code (MAC). This concatenation can be expressed as token = AUTN = (SQN xOR AK) || AMF || MAC token = function (AUTN) = function ((SQN xOR AK) || AMF || MAC).

The second parameter may further comprise or may be derived from the random challenge or random code (RAND). The RAND can be generated by the second entity and delivered to the first entity as part of the

ES 2 637 313 T3 security operation. The second parameter may still further comprise or may be derived from an identifier associated with the first entity. Therefore, the second parameter can be a concatenation of the

Unique OR of a random challenge (RAND), an identifier associated with the first entity and the token.

The identifier associated with the first entity may comprise or may be derived from an identifier of the first entity. Examples of the identifier of the first entity include the Private User Identity (IMPI) or the International Mobile Subscriber Identity (IMSI) of the first entity. Alternatively, the identifier associated with the first entity may comprise or may be derived from an identifier of a communication network associated with the first entity. An example of such a communication network is a service network of the first entity. The identifier of the communication network may be a Land Mobile Public Network Identifier (PLMN_ID).

Specifically, the second parameter can comprise or can be derived from a concatenation of 0x02, a PLMN_ID, a RAND, an IMPI or IMSI, and the token. This could be expressed as

0x02 || PLMN_ID || RAND || IMPI || witness.

When the witness is the SQN itself, the above becomes

0x02 || PLMN_ID || RAND || IMPI || SQN;

and when the witness is the AUTN, the above becomes

0x02 || PLMN_ID || RAND || IMPI || AUTN.

With respect to the first parameter used in the method, this parameter can comprise or can be derived from a set of cryptographic keys that have been obtained by the first entity executing the security operation. The cryptographic key set may comprise or may be derived from an Encryption Key (CK) and an Integrity Key (IK).

The CK and IK can be the encryption key and the integrity key calculated by the first entity based on an AUTN and a RAND. The AUTN and RAND can be delivered from the second entity. This calculation, as well as the delivery of the AUTN and RAND can form part of the security operation.

In one implementation, the first parameter may comprise or may be derived from a concatenation of the CK and theIK. This can be expressed mathematically as

CK || IK.

The method described herein generates a cryptographic key. This key can be shared by at least the first entity and the second entity, in any subsequent communication between them. In certain implementations, this key may be a KASME referred to in the "key hierarchy" in Fig. 2, which can be shared by the first entity and an Access Security Management Entity (ASME) of the second entity.

The method can be extended to understand the application of one or more additional key derivation functions; therefore, more cryptographic keys can be generated. Such generation relies on, or makes use of, the cryptographic key generated in the basic, unextended method described above, eg, the KASME.

The cryptographic keys generated by the extended method may include at least one of a set of cryptographic keys to protect No Access Stratum (NAS) traffic; a set of cryptographic keys for the protection of Radio Resource Control (RRC) traffic; a set of cryptographic keys for the protection of User Plane (UP) traffic; and an intermediate cryptographic key, such as a KeNB, to derive the cryptographic keys to protect the RRC traffic and / or the cryptographic keys to protect the UP traffic. For an easier understanding of these keys, reference is made to Fig. 2 which illustrates the key hierarchy used in SAE / LTE.

Specifically, the cryptographic key set to protect NAS traffic may comprise a key to protect NAS traffic with an encryption algorithm (KNASenc) and / or another key to protect NAS traffic with an integrity algorithm (KNASint). Similarly, the cryptographic key set for RRC traffic protection may comprise a key to protect RRC traffic with an encryption algorithm (KRRcenc) and / or another key to protect RRC traffic with an integrity algorithm (KRRCint). . Furthermore, the cryptographic key set for UP traffic protection may comprise a key to protect UP traffic with an encryption algorithm.^(KUPenc^).

For the technique described herein, the "first entity" can be user equipment, such as a mobile station. The "second entity" can be an entity located within a communication network, therefore a "network entity". In particular, the second entity can be located in an SAE / LTE network.

ES 2 637 313 T3

The second entity may comprise an Authentication Center (AuC) / Local Subscriber Server (HSS) and a Mobility Management Entity (MME). The MME may be responsible for initiating the security operation for the first entity. The cryptographic keys generated can be generated by the AuC / HSS and can be shared by the first entity and the MME. The AuC / HSS can increase the SQN, particularly each time the security operation is started for the first entity. In addition, the AuC / HSS can also build the AUTN based on the SQN.

The security operation referred to herein can be performed by the first and second entities in a cooperative manner. For example, the security operation can be based on an AKA procedure, such as the AKA protocol.

The key derivation function referred to by the method may be a Generic Initialization Architecture (GBA) key derivation function. A Generic Initialization Architecture key derivation function may employ a Secure Key Generation Algorithm (SHA) key generation function. In particular, a key generation function of the Secure Key Generation Algorithm with a 256-bit length digest (SHA-256) can be employed.

According to another aspect, a computer program product is provided. The computer program product comprises parts of program code for performing the method steps described herein when the computer program product is run on a computer system for a computing device. The computer program product may be stored on a computer-readable notification medium.

According to another aspect, a computer program product is provided. The computer program product comprises parts of program code for performing the method steps described herein when the computer program product is run on a computer system for a computing device. The computer program product may be stored on a computer-readable notification medium.

In general, the solution can be implemented by means of a hardware, software or combined hardware / software approach.

As for a hardware embodiment, a device adapted to generate a cryptographic key for a communications entity is provided. The device is adapted to perform a security operation, of which the cryptographic key generation may be a part thereof. An example of the security operation is the AKA procedure based on the AKA protocol. The device comprises a first component adapted to provide an input to a key derivation function, the input comprising at least two parameters. The first parameter either comprises or is derived from a set of cryptographic keys that have been calculated by the communications entity executing the security operation and the second parameter either comprises or is derived from a token for use by the communications entity , wherein the token comprises or is derived from a sequence number (SQN) indicating the number of times the security operation has been initiated for the communications entity. The device further comprises a second component adapted to execute the key derivation function to generate the cryptographic key based on the input provided. The entry is unique each time the security operation is initialized for the communication entity.

The witness can take many forms. In one case, the SQN itself can be a witness. Alternatively, the token can be derived from the SQN using an algorithm that involves certain mathematical operations, such as at least one arithmetic operation, one logical operation, and one string operation. For example, the token may comprise or be derived from an Authentication Token (AUTN) based on the SQN and provided to the communications entity. This training and witness delivery can be part of the security operation. Specifically, the token may comprise a unique OR of the SQN and an Anonymity Key (AK). The Anonymity Key can be a cryptographic key produced by a key generation function, such as the f5 function that uses a random challenge according to the AKA protocol.

For example, the token can be a concatenation of the unique OR of the SQN and an Anonymity Key (AK), an Authentication and Key Management Field (AMF), and a Message Authentication Code (MAC). Specifically, this can be expressed as a witness = AUTN = (SQN xOR AK) || AMF || MAC.

The second parameter may further comprise or be derived from the random challenge or random code (RAND). The RAND can be provided to the communications entity as part of the security operation. The second parameter may still further comprise or may be derived from an identifier associated with the communications entity. In this case, the identifier may comprise or may be derived from an identifier of the communications entity such as a Private User Identity (IMPI) or an International Mobile Subscriber Identity (IMSI) of the other communications entity. Alternatively, the second parameter may still further comprise or be derived from an identifier of a communication network associated with the communication entity, particularly a service network of the communication entity. This identifier of the communication network may be a Land Mobile Public Network Identifier (PLMN_ID).

ES 2 637 313 T3

A particular example of the second parameter can comprise or can be derived from a concatenation of 0x02, a PLMN_ID, a RAND, an IMPI or an IMSI and the token. For example, the second parameter can be expressed as

0x02 || PLMN_ID || RAND || IMPI || witness.

When the witness is the SQN, the above becomes

0x02 || PLMN_ID || RAND || IMPI || SQN;

and when the witness is the AUTN, the above becomes

0x02 || PLMN_ID || RAND || IMPI || AUTN.

As mentioned above, the first parameter can comprise or can be derived from a set of cryptographic keys. In particular, this set of cryptographic keys can comprise an Encryption Key (CK) and an Integrity Key (IK) that have been calculated by the communications entity as part of the security operation. Alternatively, the cryptographic key set can be derived from the Encryption Key and the Integrity Key.

As a particular implementation, the first parameter can comprise or can be derived from a concatenation of the CK and the IK, which can be expressed as

CK || IK.

The device can generate not only the cryptographic key based on the provided first and second parameters, but also more cryptographic keys based on the generated cryptographic key. In doing so, the device can be adapted to apply one or more additional key derivation functions to generate the most cryptographic keys based on the cryptographic key that has been generated.

These "more cryptographic keys" can comprise at least one of a set of cryptographic keys for the protection of Non-Access Stratum (NAS) traffic, a set of cryptographic keys for the protection of Radio Resource Control (RRC) traffic, a set of cryptographic keys for the protection of User Plane (UP) traffic and an intermediate cryptographic key KeNB to derive the cryptographic keys for the protection of RRC traffic and / or the cryptographic keys for the protection of UP traffic.

The communication entity referred to above can be a user equipment, such as a mobile station (eg a mobile phone or a network card).

According to a further aspect, a user equipment is provided comprising the device presented above. The user equipment can be a mobile station.

According to yet a further aspect, a system is provided comprising the aforementioned user equipment. The system also comprises a network entity. The network entity can be used within a SAE / LTE network. The network entity may comprise an AuC / HSS and an MME. The MME may be responsible for initializing the security operation for the user equipment. The AuC / HSS can generate the cryptographic key. The cryptographic keys generated can be shared by the user equipment and the MME. The AuC / HSS can increase the SQN, particularly every time the security operation is initialized for the user equipment. In addition, the AuC / HSS can also build the AUTN based on the SQN.

According to a further aspect, a method is provided for generating a cryptographic key. The cryptographic key is used to, among others, protect communication between two entities. The method is carried out by the first entity. The method is part of a distributed security operation that is started by the second entity. The method comprises providing at least two parameters, wherein the first parameter either comprises or is derived from a set of cryptographic keys that have been calculated by the first entity executing the security operation; and the second parameter either comprises or is derived from a token that has a different value each time the security operation is started by the second entity for the first entity (in other words, the value of the token is never the same for any two security operations); and applying a key derivation function to generate a cryptographic key based on the provided parameters.

The expression "a parameter comprises X" can mean that the variable X, in its string format, forms the parameter or part of it. The expression "a parameter is derived from X" can mean that the parameter is the result of applying certain functions, such as mathematical functions, to at least the variable X. Examples of functions include, but are not limited to, arithmetic operations, operations logic, string operations, and any combination thereof. The arithmetic operation can be addition, subtraction, multiplication, et., And any significant combinations thereof. The logical operation can be AND, OR, Exclusive OR (xOR), NOT, etc., and any significant combinations thereof. The string operation can be Concatenation, Reversal, Substitution, etc., and any significant combinations thereof. Also, arithmetic operation, logical operation, and string operation can be combined.

ES 2 637 313 T3

In particular, the token mentioned above may comprise or be derived from a sequence number (SQN) indicating the number of times that the security operation has been initiated by the second entity for the first entity. With each initiation, the SQN can be increased by the second entity. This mechanism ensures that the token has a different value for each initiated security operation.

The witness can take many forms. In one case, the SQN itself can be the witness. Alternatively, the token can be derived from the SQN using an algorithm that involves certain mathematical operations, such as at least one of an arithmetic operation, a logical operation, and a string operation. For example, the token may comprise or be derived from an Authentication Token (AUTN) constructed by the second entity based on the SQN and delivered to the first entity. This construction and delivery can be part of the security operation.

Specifically, the token may comprise an exclusive OR of the SQN and an Anonymity Key (AK). More specifically, the token may be a concatenation of the unique OR of the SQN and the Anonymity Key (AK), an Authentication and Key Management Field (AMF), and a Message Authentication Code (MAC). This concatenation can be expressed as token = AUTN = (SQN xOR AK) || AMF || MAC token = function (AUTN) = function ((SQN xOR AK) || AMF || MAC)

The second parameter may further comprise or be derived from a random challenge, or random code (RAND). The RAND can be generated by the second entity and delivered to the first entity as part of the security operation. The second parameter may further further comprise or be derived from an identifier of the first entity. This identifier can be a Private User Identity (IMPI) or an International Mobile Subscriber Identity (IMSI). Even further, the second parameter can comprise or be derived from a communications network identifier and particularly the service network of the first entity. For example, this identifier could be a Public Land Mobile Network Identifier (PLMN_ID).

Specifically, the second parameter can comprise or be derived from a concatenation of 0x02, a PLMN_ID, a RAND, an IMPI or IMSI, and the token. This could be expressed as

0x02 || PLMN_ID || RAND || IMPI || witness.

When the witness is the SQN itself, the above becomes

0x02 || PLMN_ID || RAND || IMPI || SQN;

and when the witness is the AUTN, the above becomes

0x02 || PLMN_ID || RAND || IMPI || AUTN.

With respect to the first parameter used in the method, this parameter comprises or is derived from a set of cryptographic keys that have been obtained by the first entity executing the security operation. The cryptographic key set can comprise or be derived from an Encryption Key (CK) and an Integrity Key (IK).

The CK and IK can be the encryption key and the integrity key calculated by the first entity based on an AUTN and a RAND. The AUTN and RAND can be delivered from the second entity. This calculation as well as the delivery of the AUTN and RAND can be part of the security operation.

In one implementation, the first parameter can comprise or be derived from a concatenation of the CK and IK. This can be expressed mathematically as

CK || IK.

The method described herein generates a cryptographic key. This key can be shared by at least the first entity and the second entity, in any subsequent communication between the two. In certain implementations, this key may be a KASME referred to in the "key hierarchy" of Fig. 2, which may be shared by the first entity and an Access Security Management Entity (ASME) of the second entity.

The method can be extended to understand applying one or more additional key derivation functions to generate more cryptographic keys. Such generation is based on, or makes use of, the cryptographic key generated in the basic, unextended method described above, for example the KASME.

ES 2 637 313 T3

The cryptographic keys generated by the extended method may include at least one of a set of cryptographic keys to protect No Access Stratum (NAS) traffic; a set of cryptographic keys for the protection of Radio Resource Control (RRC) traffic; a set of cryptographic keys for the protection of User Plane (UP) traffic; and an intermediate cryptographic key, such as a KeNB, to derive the cryptographic keys to protect the RRC traffic and / or the cryptographic keys to protect the UP traffic. For an easier understanding of these keys, reference is made to Fig. 2 which illustrates the key hierarchy used in SAE / LTE.

Specifically, the cryptographic key set to protect NAS traffic may comprise a key to protect NAS traffic with an encryption algorithm (KNASenc) and / or another key to protect NAS traffic with an integrity algorithm (KNASint). Similarly, the cryptographic key set for RRC traffic protection may comprise a key to protect RRC traffic with an encryption algorithm (KRRCenc) and / or another key to protect RRC traffic with an integrity algorithm (KRRCint). . Furthermore, the cryptographic key set for UP traffic protection may comprise a key to protect UP traffic with an encryption algorithm.^(KUPenc^).

For the technique described herein, the "first entity" can be user equipment, such as a mobile station. The "second entity" can be an entity located within a communication network, thus a "network entity". In particular, the second entity can be located in an SAE / LTE network.

The second entity may comprise an Authentication Center (AuC) / Residential Subscriber Server (HSS) and a Mobility Management Entity (MME). The MME may be responsible for initiating the security operation. The cryptographic keys generated can be generated by the AuC / HSS and shared by the first entity and the MME. The AuC / HSS can increase the SQN, particularly each time the security operation is started for the first entity. In addition, the AuC / HSS can also build the AUTN based on the SQN.

The security operation referred to herein can be performed by the first and second entities in a cooperative manner. For example, the security operation can be based on an AKA procedure, such as the UMTS AKA protocol.

The key derivation function referred to by the method may be a Generic Initialization Architecture (GBA) key derivation function. A Generic Initialization Architecture key derivation function may employ a Secure Key Generation Algorithm (SHA) key generation function. In particular, a key generation function of the Secure Key Generation Algorithm with a 256-bit length digest (SHA-256) can be employed.

According to a further aspect, a computer program product is provided. The computer program product comprises parts of program code for performing the method steps described herein when the computer program product is run on a computer system for a computing device. The computer program product may be stored on a computer-readable notification medium.

In general, the solution can be implemented through a hardware, software, or combined hardware / software approach.

As for a further physical component embodiment, a device adapted to generate a cryptographic key for a communications entity is provided. The device can perform a security operation, of which the generation of the cryptographic key can be part of it. The device comprises a first component adapted to provide at least two parameters, wherein the first parameter can comprise or be derived from a set of cryptographic keys that have been calculated by the communications entity by executing the security operation, and the second parameter may comprise or be derived from a token that has a different value each time the security operation is initialized for the communications entity. The device further comprises a second component adapted to execute a key derivation function to generate a cryptographic key based on the parameters provided.

As stated above, the witness can take many possible forms. The token may comprise or be derived from an SQN indicating the number of times the security operation has been started for the communications entity. In one implementation, the SQN itself is the witness. Alternatively, the token can be derived from the SQN using an algorithm that involves at least one of an arithmetic operation, a logical operation, and a string operation. For example, the token can comprise or be derived from an AUTN that is built on the basis of the SQN and delivered to the communications entity, where this construction and delivery is part of the security operation. For example, the token may be an exclusive-OR concatenation of the SQN and an Anonymity Key (AK), an Authentication and Key Management Field (AMF), and a Message Authentication Code (MAC). Specifically, this can be expressed as a witness = AUTN = (SQN xOR AK) || AMF || MAC.

ES 2 637 313 T3

In addition to the token, the second parameter can also comprise or be derived from a RAND. The RAND can be delivered to the communications entity as part of the security operation. Furthermore, the second parameter may comprise or be derived from an identifier of the communications entity. An example of the identifier is a Private User Identity (IMPI) of the communications entity. Even further, the second parameter may comprise or be derived from an identifier of the service network of the communication entity. This identifier could be a Public Land Mobile Network Identifier (PLMN_ID).

A particular example of the second parameter may comprise or be derived from a concatenation of 0x02, a PLMN_ID, a RAND, an IMPI or an IMSI, and the token. For example, the second parameter can be expressed as

0x02 || PLMN_ID || RAND || IMPI || witness.

When the witness is the SQN, the above becomes

0x02 || PLMN_ID || RAND || IMPI || SQN;

and when the witness is the AUTN, the above becomes

0x02 || PLMN_ID || RAND || IMPI || AUTN.

As mentioned above, the first parameter can comprise or be derived from a set of cryptographic keys. In particular, this set of cryptographic keys can comprise an Encryption Key (CK) and an Integrity Key (IK) that has been calculated by the communications entity as part of the security operation. Alternatively, the cryptographic key set can be derived from the Encryption Key and the Integrity Key.

As a particular implementation, the first parameter can comprise or be derived from a concatenation of the CK and IK, which can be expressed as

CK || IK.

The device can generate not only the cryptographic key based on the first and second parameters provided, but also more cryptographic keys based on the generated cryptographic key. In doing so, the device can be adapted to apply one or more additional key derivation functions to generate the most cryptographic keys based on the cryptographic key that has been generated.

These "more cryptographic keys" can comprise at least one of a set of cryptographic keys for the protection of Non-Access Stratum (NAS) traffic, a set of cryptographic keys for the protection of Radio Resource Control (RRC) traffic, a set of cryptographic keys for the protection of User Plane (UP) traffic, and an intermediate cryptographic key KeNB to derive the cryptographic keys for RRC traffic protection and / or the cryptographic keys for UP traffic protection.

The communication entity referred to above may be a user equipment, such as a mobile station (eg a mobile phone or a network card).

According to a further aspect, a user equipment is provided comprising the device presented above. The user equipment can be a mobile station.

According to yet a further aspect, a system is provided comprising the aforementioned user equipment. The system also comprises a network entity. The network entity can be used for an SAE / LTE network. The network entity may comprise an AuC / HSS and an MME. The MME may be responsible for initiating the security operation for the user equipment. The AuC / HSS can generate the cryptographic key. The cryptographic keys generated can be shared by the user equipment and the MME. The AuC / HSS can increase the SQN, particularly every time the security operation is started for the user equipment. In addition, the AuC / HSS can also build the AUTN based on the SQN.

Brief description of the drawings

Next, the cryptographic key generation technique will be described with reference to the exemplary embodiments illustrated in the drawings, wherein:

Fig. 1 is a diagram showing the basic concept of the UMTS AKA protocol;

Fig. 2 is a block diagram illustrating a proposed key hierarchy for the SAE / LTE system;

Fig. 3 is a block diagram showing an embodiment of the device;

Fig. 4 is a block diagram showing an embodiment of the system;

Fig. 5 is a block diagram showing an embodiment of the method;

ES 2 637 313 T3

Fig. 6 is a block diagram showing a procedure of UMTS AKA operation,

Generation of an Authentication Vector by a network entity;

Fig. 7 is a block diagram showing another UMTS AKA operation procedure,

Authentication and Establishment of Keys;

Fig. 8 is a block diagram showing the general authentication function performed by the UE as part of the UMTS AKA operation;

Fig. 9 is a block diagram showing a particular cryptographic algorithm for performing the above authentication function in the UE; Y

Fig. 10 is a block diagram showing a particular detail of the above cryptographic algorithm.

Detailed description

In the following description, for purposes of explanation and not limitation, specific details, such as particular sequences of steps, interfaces, and configurations, are set forth below to provide a thorough understanding of the cryptographic key generation technique. It will be apparent to those skilled in the art that the technique can be practiced in other embodiments that depart from these specific details. For example, while the technique will first be described in context with the UMTS AKA protocol and in the SAE / LTE network environment, it will be apparent to skilled persons that the technique can also be practiced in connection with other protocols, architectures, or security environments.

Furthermore, those skilled in the art will appreciate that the functions discussed herein below can be implemented using software that operates in conjunction with a programmed general-purpose computer or microprocessor. It will also be appreciated that while the technique is described first in the form of methods and devices, the technique can also be performed in a computer program product as well as in a system comprising a computer processor and memory coupled to the processor. , wherein the memory is encoded with one or more programs that can perform the function described herein.

Fig. 3 shows an embodiment of a device 100 adapted to generate a cryptographic key for a communications entity (not shown in Fig. 3). The communications entity is adapted to execute a security operation. Device 100 comprises a first component 102 and a second component 104. The first component 102 is adapted to provide at least two parameters, figuratively shown at the dates 106 and 108.

The first parameter 106 comprises or is derived from a set of cryptographic keys 110 and 112. (Although two keys are shown in the figure, the set of cryptographic keys can include any number of keys.) The set of cryptographic keys has been calculated by the communications entity executing the security operation. The derivation of the cryptographic key set 110 and 112 in the first parameter 106 is shown figuratively as a block 114. The second parameter 108 comprises or is derived from a token 116. The token 116 has a different value each time the security operation is started for the communications entity. The derivation of the token 116 in the second parameter 108 is figuratively shown as a block 118. The second component 104 of the device 100 is adapted to execute a key derivation function to generate a cryptographic key 120 based on the parameters 106 and 108 provided. .

Referring to Fig. 4, an embodiment of a system 200 comprising the aforementioned device 100 is shown. Device 100 may be comprised of a communication entity 202, which may be a UE, such as a mobile station. Of course, the communication entity 202 can be any suitable type of communication entity capable of hosting the device 100. In addition, the system comprises a network entity 204, which may reside in an SAE / LTE network. Network entity 204 may comprise an AuC or HSS and an MME. It can also be another communications entity on an SAE / LTE network.

Corresponding to the cryptographic key generation device 100 shown in Figs. 3 and 4, a diagram 300 illustrating an embodiment of a method for generating a cryptographic key is shown in Fig. 5. The generated key is used to protect communication between two entities. The first entity 302 may correspond to the communication entity 202 as shown in Fig. 4, and the second entity 304 may correspond to the network entity 204 of Fig. 4. The first entity can be a UE. However, the implementation is not limited to a UE-network entity scenario. Instead, it can be applied to any two communication entities in general.

The MME may be responsible for initiating the security operation for the communication entity 202. The generated cryptographic keys may be shared by the MME and the communication entity 202.

In particular, the method is performed by the first entity 302 as part of a security operation figuratively illustrated at the date 300 ', which is initiated by the second entity 304 (particularly by

ES 2 637 313 T3 the MME thereof) for the first entity 302. The embodiment itself comprises two steps, 306 and 308. Step 306 provides at least two parameters (106 and 108 of Fig. 3). The first parameter comprises or is derived from a set of cryptographic keys (110 and 112 as shown in Fig. 3) that has been calculated by the first entity 302 executing the security operation 300 '. The second parameter comprises or is derived from a control (116 as shown in Fig. 3) which has a different value each time the security operation 300 'is started by the second entity 304 for the first entity 302. In the second step 308, a key derivation function is applied to generate a cryptographic key (120 as shown in Fig. 3) based on the parameters provided (106 and 108 as shown in Fig. 3).

Subsequently, considerable detail is given to explain the cryptographic key generation technique with particular emphasis on how the technique can successfully avoid the key collision between two UEs, or more importantly, between two different executions of the operation. security for one and the same UE.

The generation of cryptographic keys can be part of the UMTS AKA operation. The AKA of UMTS is based on the implementation that the UE, particularly the USIM thereof, and the AuC / HSS in the Residential Environment (HE) of the UE share a user-specific secret key K, certain message authentication functions f1, f2 and certain cryptographic key generation functions f3, f4, f5. Additionally the USIM and AuC / HSS keep track of the counters, or sequence numbers SQNUE and SQNHE respectively to support network authentication. For example, the AuC / HSS can increase the SQNHE, particularly each time the security operation is started for the first entity. The UMTS AKA operation comprises a number of procedures, including Generation of Authentication Vectors (AV), and Authentication and Key Establishment.

The purpose of the AV procedure is to provide the SN / VLR (or MME) with a group of new AVs from the UE HE to perform a number of user authentications. The Generation of Authentication Vectors by the HE is illustrated in Fig. 6. With reference to this figure, upon receipt of a request from the SN / VLR, the AuC / HSS sends an ordered group of n Authentication Vectors aV ( 1 ... n) to the SN / VLR. Each AV comprises a random number (or random challenge) RAND, an expected response XRES, an encryption key CK, an integrity key IK, and an authentication token AUNT.

The AuC / HSS begins with the generation of a new sequence number SQN and an unpredictable RAND challenge. The following values ​​are then calculated:

- a MAC message authentication code = f1 (SQN || RAND || AMF) where f1 is a message authentication function;

-an expected response XRES = f2 (RAND) where f2 is a message authentication function (possibly truncated);

- an encryption key CK = f3 (RAND) where f3 is a key generation function;

- an integrity key IK = f4 (RAND) where f4 is a key generation function; Y

-an anonymity key AK = f5 (RAND) where f5 is a key generation function.

Finally the authentication token AUTN = (SQN xOR AK) || AMF || MAC. It can be built by the AuC / HSS. Here, the AK is an anonymity key used to hide the SQN since the latter can expose the identity and location of the UE. SQN concealment is to protect against passive attacks. The use of the AK can be optional. When AK is not used, AK = 000.0 can be used figuratively instead.

The group of AVs is sent back to the requesting SN / VLR in an authentication response. Each AV is valid for one (and only one) authentication and key agreement between the SN / VLR and the USIM.

The next procedure of the UMTS AKA operation, Authentication and Key Establishment, is to mutually authenticate and establish the encryption and integrity keys between the SN / VLR and the UE. This process is illustrated in Fig. 7. With reference to this figure, when the SN / VLR initiates an authentication and key agreement, it selects the next AV in the group and sends the RAND and AUTN parameters to the UE. The USIM checks if the AUTN can be accepted and, if applicable, produces a RES response which is sent back to the SN / VLR. In particular, the UE procedures are shown in Fig. 8.

With reference to Fig. 8, upon receipt of the RAND and AUTN the UE first calculates the anonymity key AK = f5 (RAND) (or uses AK = 000.0) and retrieves the sequence number SQN = (SQN xOR AK) xOR AK. The UE then calculates XMAC = f1 (SQN || RAND || AMF) and compares this with the MAC included in the AUTN. If they are different, the UE sends a user authentication rejection back to the SN / VLR with an indication of the cause and the UE exits the procedure. Otherwise, the UE verifies that the received SQN is in the correct range.

If the SQN is considered to be in the correct range, the UE calculates RES = f2 (RAND) and includes this parameter in a user authentication response back to the SN / VLR. Finally the UE calculates the encryption key CK =

ES 2 637 313 T3 f3 (RAND) and the integrity key IK = f4 (RAND). To improve efficiency, RES, CK and IK could also be calculated earlier at any time after receiving the RAND. The UE may store the RAND for resynchronization purposes.

Upon receipt of the user authentication response the SN / VLR compares the RES with the expected response XRES from the selected authentication vector. If XRES equals RES then user authentication has been accepted. The newly calculated keys CK and IK will then be transferred by the USIM and the SN / VLR to the entities that perform the encryption and integrity functions.

From the above, it can be seen that the UMTS AKA operation is based on a pair (RAND, AUTN) and the AUTN comprises or is derived from a sequence number, SQN, depending on

AUTN = (SQN xOR AK) || AMF || MAC where AK is an anonymity key, which can be produced by Milenage (see Fig. 9) from the "f5" output above.

The function below is a first solution to the collision problem discussed above:

KDF (CK || IK, RAND || IMPI || SQN) where SQNs have been included in the inputs in this way. Now, even if two RANDs are the same, that is, RAND = RAND ', the fact that the SQN always increases (for example, by one) will ensure that the inputs are different, unique, or distinct.

An alternative solution is to use

KDF (CK || IK, RAND || IMPI || AUTN).

This solution may be simpler to implement since the AUTN can be used "as is" from the AKA signaling. However, the “uniqueness” of the inputs in this case may not be obvious since

AUTN = (SQN xOR AK) || AMF || MAC and even if SQN TO SQN ', if it cannot be immediately seen that (SQN xOR AK), (SQN' xOR AK ') will be different as AK could potentially “cancel” the differences. However, later on, the distinction of (SQN xOR AK) can be proved.

Suppose (CK || IK, RAND || IMPI || AUTN) = (CK '|| IK', RAND '|| IMPI || AUTN').

This has already been shown to imply that CK = CK ', IK = IK', and RAND = RAND '. Thus it remains to be checked whether it could be that AUTN = AUTN '. This check can be translated into checking if (SQN xOR AK) || AMF || MAC = (SQN 'xOR AK') || AMF '|| MAC '.

Suppose without loss of generality that AMF = AMF 'and MAC = MAC'. Then it is only necessary to check if the following could keep:

SQN xOR AK = SQN 'xOR AK'.

Remember that RAND = RAND 'is expected. With reference to the Milenage algorithm shown in Fig. 9, this implies that AK = AK '(since they were produced from the same RANDs). In this way, it had to be that

SQN = SQN ', which is a contradiction since, as already noted, SQN always "intensifies" and thus SQN ASQN'.

In this way, it is shown that the second solution also guarantees the uniqueness of the inputs to the function

KDF.

As a general solution, instead of using SQN or AUTN to achieve uniqueness, any token that has a different value each time the UMTS AKA operation is started by the network for the UE is feasible. For example, SQN xOR AK (which is part of the AUTN) can be used since it has (through the previous discussion) the required property of uniqueness.

The cryptographic key generation technique described here above has numerous advantages. For example, it guarantees the uniqueness of the KDF entries. Therefore, you successfully avoid orders caused by possible identical entries. With this technique, the generated cryptographic key will be able to meet, for example, the

ES 2 637 313 T3 high level security requirements in SAE / LTE systems. As an added benefit, the technique can be implemented based on already deployed USIMs without requiring any USIM replacement. Another specific advantage with the use of the AUTN rather than the SQN is that the invention can be implemented in the mobile terminal (outside of the USIM).

Although embodiments of the cryptographic key generation technique have been illustrated in the accompanying drawings and described in an aforementioned description, it will be understood that the technique is not limited to the embodiments described herein. The technique is capable of numerous retrofits, modifications and substitutions without departing from the scope of the invention.

Symbols and abbreviations

For the purposes of this document, the following symbols and abbreviations apply:

|| Concatenation xOR OR Exclusive f1 Message authentication function used to calculate MAC f2 Message authentication function used to calculate RES and XRES f3 Key generation function used to calculate CK f4 Key generation function used to calculate IK f5 Generation function of keys used to calculate AK

K Long-term secret key shared between USIM and AuC

3GPP Third Generation Cooperation Project

AES Advanced Encryption Standard

AK Anonymity Key

AKA Authentication Protocol and Key Agreement

AMF Field of Authentication and Key Management

ASME Access Security Management Entity

AUTN Authentication Token

AV Vector Authentication

CK Encryption Key eNB Enhanced Node B

HE Local Environment

HLR Base Position Register

HSS Local Subscriber Server

IK Integrity Key

IMPI Private User Identity

IMSI International Mobile Subscriber Identity

KDF Key Derivation Function

LTE Long Term Evolution

MAC Message Authentication Code

MME Mobility Management Entity

MS Base Station

ES 2 637 313 T3

MSC Mobile Services Switching Center NAS No Access Stratum PLMN Land Mobile Public Network RAND Random challenge 5 CRR Radio Resource Control SAE Evolution of System Architecture YN Service Network SQN Sequence number EU User Equipment 10 UMTS Universal Mobile Telecommunication System UP User Map USIM Universal Subscriber Identity Module VLR Visited Position Register XRES Expected Response fifteen