Cryptographic key generation

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

Background of the invention [0002] The Authentication and Key Agreement (AKA) is a challenge-response protocol that uses symmetric cryptography. The main goals of AKA include mutual authentication by two objects communicating with each other and setting cryptographic keys to protect two-way exchanged communications. The AKA variant is UMTS AKA, contained in the security architecture standardized by 3GPP for the 3G mobile telecommunications network in the Technical Specification 3G TS 33.102.

[0003] The basic concept of UMTS AKA is shown in Fig. 1. Referring to this figure, the UMTS AKA protocol is run between user equipment (UE) and a network object (NE). The network object initiates 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 RAND and AUTN, among others, UE calculates the cipher key (CK) and integrity key (IK), and then uses them for encryption and integrity functions.

[0004] 3GPP is also undergoing standardization of so-called "B3G" telecommunications networks (beyond 3G). The evolution of the System Architecture Evolution (SAE) and the evolution of LTE (Long Term Evolution) are two closely related aspects of the B3G network. Compared to traditional 3G networks, a SAE / LTE network may impose higher security requirements and / or more security requirements. For example, more cryptographic keys may be needed to secure communications at different levels. In a document related to another standard - 3GPP TR 33.821, 3GPP recommended a key hierarchy for deriving more cryptographic keys for use in SAE / LTE.

[0005] Fig. 2 shows this key hierarchy. At the very top of the hierarchy is the K key, a long-term cryptographic key common to the Module that uniquely identifies the USIM (Universal Subscriber Identity Module) user equipment (UE) and the AuC (Authentication Center) located on the network. The level below is the CK and IK cryptographic key pair, which are output by the UE, in particular through its USIM cards, in the same or similar way as the UMTS AKA operation listed above. Even lower in the hierarchy is the KASME key, which is derived by the UE from CK, IK and, if necessary, other parameters. After removal, KASME is transferred from the AuC to the access network, in

- in particular to the ASME (Access Securing Management Entity) SAE / LTE network, and then shared between the UE and the network. If the access network is based on LTE technology, ASME functions are supported by MME (Mobility Management Entity).

[0006] The KASME key and the "below" keys in its hierarchy can be derived by using a specific cryptographic function. E.g,

KASME = KDF (CK || IK, 0x02 || PLMN_ID || <other_parameter>) with KDF based on the key derivation function (KDF) of the generic bootstrapping architecture (GBA). One GBA KDF is specified in 3G TS 33.220.

[0007] GBA KDF may use cryptographic hash functions, such as hash functions of the secure hash algorithm (Secure Hash Algorithm). Among the many SHA hash functions, SHA-256 is a very safe variant because it is considered to be conflict resistant and acts like a pseudo-random function. As the name suggests, SHA-256 is a hash function of a hash algorithm with a hash length (output) of 256 bits. PLMN_ID is the identifier of the UE serving network.

[0008] To achieve a high level of protection, it has not proved sufficient that the GBA KDF function is based mainly only on CK and IK. The reason for this is the risk that a given UE may receive the same CK twice, or two different user equipment (UE) may obtain the same CK. In such cases, the "uniqueness" of KDF entries is weakened and various conflicts may occur between user equipment (EU) (using the same KASME).

[0009] The general observation is that although it is certain that KDF (x) produces the same key as KDF (y) if x = y, the inverse may not always apply. This means that even if x ψ y can happen, it still KDF (x) = KDF (y). However, this is unlikely to occur because it is recommended that the KDF be based on SHA-256, which, as already mentioned, is resistant to conflicts. So, for the technique described here, one can safely assume that KDF (x) = KDF (y) if and only if x = y. This assumption allows the technique described here to focus on ensuring the "uniqueness" of KDF entries.

[0010] The GBA KDF specification standardization body (SAGE Special Algorithm Group of Experts operating in ETSI) noticed the above problem and recommended the inclusion of the User's Private Identification Number (IMPI) of the user equipment in <another_parameter> to avoid conflicts between different user equipment (EU) . Another recommendation may also be to include a random code, such as RAND, in the other parameter. This is described in the communication statement from ETSI / SAGE for 3GPP SA3 (in 3GPP document No. S3 - 030219).

[0011] However, it was found that the above-mentioned recommendations still do not guarantee the "uniqueness" of entering KDF. This is due to the following property analysis

- 3 protections of the GBA KDF function and its use in SAE / LTE for one and the same UE (e.g. one and the same IMPI).

[0012] First, the following basic construction is considered:

KDF (CK, IMPI).

[0013] Since it was assumed that IMPI = IMPI '(when the UE is constant), this basic construction will lead to a conflict of two inputs (CK, IMPI), (CK', IMPI ') if and only if CK = CK'.

[0014] Secondly, another construction is considered that is closer to the actual GBA KDF:

KDF (CK || IK, IMPI).

[0015] However, the inclusion of IK in the inputs does not change the above conflict property, as one might suppose at first. That is, KDF (CK || IK, IMPI) will be equal to KDF (CK '|| IK', IMPI) if and only if CK = CK '. To understand why the inclusion of IK would be of no avail, you need to consider how CK and IK are produced by a cryptographic algorithm executed on the EU.

[0016] The typical cryptographic algorithm on the UE side is the MILENAGE algorithm, which is shown in Fig. 9. In Fig. 9, Ek is the Advanced Encryption Standard (AES) algorithm, also known as the Rijndael algorithm, using the K key (stored in AuC and USIM user equipment). Let us now consider what will happen if CK = CK '. Because AES is a permutation (unambiguous mutual mapping), it means that the intermediate value (appearing with the thick arrow) is clearly determined by the result of f3, which turns out to be CK. This means, however, that the value with the thick arrow during CK production must be the same as the value present at the same location when CK 'was produced. This in turn means that the values ​​appearing as input to f4 must be the same, and therefore the same values ​​of f4 must be present. As is the case, f4 means IK. Thus, it was shown that CK = CK 'if and only if IK = IK'.

[0017] Next, an "improved" design is considered as recommended by the standardization body (SAGE), ie inclusion of RAND at the inputs:

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

[0018] Assume that CK = CK '(and therefore IK = IK'). There is hope that the use of RAND will ensure uniqueness. However, this is not true. Consider again the "relevant" part of the MILENAGE algorithm, which CK and IK generated from RAND: as shown in Fig. 9, there is a situation where the value with the thick arrow corresponding to RAND is the same as that corresponding to RAND '. However, AES (Ek) is permutation, so the inputs must also be the same, i.e. RAND = RAND '. (The fact that AES is dependent on K does not help, since it is assumed that the UE is stable and thus the same K will appear in both cases.)

[0019] 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, PLMN_ID may also be included in the inputs, but since it is very likely that the UE will remain several times in the same network, this parameter PLMN_ID cannot be invoked to ensure uniqueness.

[0020] An alternative approach to trying to avoid conflict could be to use an algorithm other than AES for cryptographic processing of algorithms f3 and f4. The above analysis was based in particular on the fact that AES is a permutation. It would therefore be possible to use non-mutation (many-to-one mapping) instead of AES. This is problematic for two reasons. First, existing USIM cards must be adapted to suit 3GPP SAE architecture. Secondly, by choosing a non-mutation function, there is indeed a greater likelihood that two outputs, e.g. f3, will conflict.

[0021] The non-uniqueness of the entries can be a serious security problem.

Because the conflict occurs if and only if RAND = RAND ', and because RAND has 128 bits, it is anticipated that the conflict will occur after about 2^Λ( 128/2) = 2^Λ64 credentials (this is known as the "birth paradox"). It is obvious that it is lower than the target GBA security level (which is 128 bits). For LTE, the matter is even worse because it is required for LTE to provide a 256-bit security level. Thus, the high probability of conflict is a significant obstacle to ensuring the required level of security in SAE / LTE.

[0022] WO 2005/032201 A relates to an improved security structure for cryptography in mobile telecommunications systems. The 3GPP 33.105 change request, version 3.4.0, applies to calculating the anonymity key during resynchronization.

Summary [0023] Accordingly, there is a need for a solution that avoids the above-mentioned conflicts. The solution should also work perfectly with already deployed USIM cards and not require replacement of all USIM cards. The disclosure of the invention provides such a solution according to the independent claims. Various embodiments of the solution are set out in the dependent claims.

[0024] According to a first embodiment, a method for generating a cryptographic key is defined. The method includes, among others, the following functions: the cryptographic key is used, among others, to protect communication between two objects. This method is implemented by the first object. This method creates the part of the key authentication and reconciliation procedure that is initiated by the second object. The method includes 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 by running the key authentication and reconciliation procedure; and the second parameter either contains or is derived from a token having a different value each time the authentication and reconciliation procedure

- the 5 key is initiated by the second object for the first object (in other words, the token value is never the same for any two authentication and key reconciliation procedures); and using the key derivation function to generate a cryptographic key based on the specified parameters.

[0025] The expression "parameter contains X" may mean that the variable X, in its string type form, forms a parameter or part thereof. The expression 'parameter is derived from X' may mean that the parameter is the result of applying certain functions, such as mathematical functions, to at least the variable X. Examples of such functions include, but are not limited to, arithmetic operations, logic operations, chain operations, and their various combinations. Arithmetic operation can mean addition, subtraction, multiplication, etc., and all their reasonable combinations.

[0026] The logical operation may be AND [functor I], OR [functor LUB], exclusive OR (xOR) [OR excluding], NOT [functor NO], etc., and all their reasonable combinations. The chain operation can be Concatenation, Reverse, Replace, etc., and all their reasonable combinations. In addition, you can combine arithmetic operation, logic operation, and chain operation.

[0027] In particular, the token mentioned above may contain a sequence number or be derived from the sequence number (SQN), indicating how many times the authentication and key reconciliation procedure was initiated by the second entity for the first entity. With each initialization, SQN can be incremented by a second object. This mechanism ensures that the token has a different value for each initiated authentication and key reconciliation procedure.

[0028] A token can take many forms. In one case, the SQN itself can be a token. Alternatively, the token may be derived from an SQN using an algorithm involving certain mathematical operations, such as at least one of arithmetic operations, logical operations and chain operations. For example, the token may contain or be derived from an Identification Token (AUTN) built by a second object that is based on SQN and is delivered to the first object. This design and delivery can be part of the key authentication and reconciliation procedure.

[0029] In particular, the token may include an functor OR exclusive sequence number (SQN) and anonymity key (AK). More specifically, the token may be a concatenation of an exclusive OR sequence (SQN) and anonymity key (AK), Authentication and Key Management Field (AMF) and Message Authentication Code (MAC). This concatenation can be expressed as:

token = AUTN = (SQN xOR AK) || AMF || MAC or token = function (AUTN) = function ((SQN xOR AK) || AMF || MAC).

[0030] The second parameter may further include a random challenge or random code, or be derived from a random challenge or random code (RAND). RAND can be generated by the second object and delivered to the first object as part of the key authentication and reconciliation procedure. The second parameter may further include the identifier of the first object or be derived from the identifier of the first object. This identifier may be the Private User Identity Identification Number (IMPI) or the International Mobile Subscriber Identity (IMSI). Furthermore, the second parameter may also include a telecommunications network identifier or be derived from the telecommunications network identifier, in particular the serving network of the first object. For example, the identifier may be the PLMN_ID (Public Land Mobile Network Identifier).

[0031] In particular, the second parameter may be derived from the concatenation 0x02, PLMN_ID, RAND, IMPI or IMSI, and a token. This can be expressed as:

0x02 || PLMN_ID || RAND || IMPI || token.

[0032] When the token means SQN alone, the above becomes:

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

and when the token means AUTN, the above becomes:

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

[0033] With respect to the first parameter used in this method, this parameter comprises or is derived from a set of cryptographic keys that were obtained by means of the first object by performing the key authentication and reconciliation procedure. A set of cryptographic keys can be derived from the cipher key (CK) and integrity key (IK), or contain them.

[0034] CK and IK may be a cipher key and an integrity key calculated by the first entity based on AUTN and RAND. AUTN and RAND can be delivered from a second facility. This calculation as well as AUTN and RAND delivery can form parts of the key authentication and reconciliation procedure.

[0035] In one embodiment, the first parameter may be derived from or include a CK and IK concatenation. This can be expressed mathematically as:

CK || IK.

[0036] The method described herein generates a cryptographic key. This key can be shared by at least the first object and the second object in any subsequent communication between them. In some implementations, the key may be KASME as defined in the "key hierarchy" of Fig. 2, which may be common to the first object and the ASME (Access Security Management Entity) of the second object.

[0037] This method may be extended to include the use of one or more other key derivation functions to generate more keys

- 7 cryptographic. Such generation is based on or uses a cryptographic key generated by the basic, non-extended method described above, e.g. KASME.

[0038] Cryptographic keys generated by the extended method may include at least one of the cryptographic key sets to protect the traffic of the NAS (Non-Access Stratum) signaling protocol; a set of cryptographic keys to protect RRC (Radio Resource Control) traffic; a set of cryptographic keys to protect the movement of the UP User Plane; and an intermediate cryptographic key, such as KeNB, for outputting cryptographic keys to protect RRC traffic and / or cryptographic keys to protect UP traffic. To facilitate the understanding of these keys, reference is made to Fig. 2, which illustrates the hierarchy of keys used in SAE / LTE.

[0039] In particular, a set of cryptographic keys for protecting NAS traffic may include a key for protecting NAS traffic using an encryption algorithm (KNASenc) and / or another key for protecting NAS traffic using an integrity algorithm (KNASint). Similarly, a set of cryptographic keys for protecting RRC traffic may include a key for protecting RRC traffic using an encryption algorithm (KRRCenc) and / or another key for protecting RRC traffic using an integrity algorithm (KRRCint). In addition, a set of cryptographic keys for protecting UP traffic may include a key for protecting UP traffic using an encryption algorithm (KUPenc).

[0040] For the technique described herein, the "first object" may be user equipment, such as a mobile station. The "second object" can be an object located inside a telecommunications network, hence the "network object". In particular, the second object can be located on the SAE / LTE network.

[0041] The second object may comprise an AuC (Authentication Center) / HSS (Home Subscriber Server) and MME (Mobility Management Entity) server. MME may be responsible for initiating the authentication procedure and key agreement for the first object. Generated cryptographic keys can be generated using AuC / HSS and common to the first object and MME. AuC / HSS can increment SQN, especially each time the authentication and key agreement procedure is initiated for the first object. In addition, AuC / HSS can also build AUTN based on SQN.

[0042] The authentication and key agreement procedure referred to herein can be performed cooperatively by the first and second objects. For example, the key authentication and reconciliation procedure may be based on the UMTS AKA protocol.

[0043] The key deriving function determined by this method may be a function of deriving the generic bootstrapping (GBA) architecture key. The generic bootstrap architecture key output function can use the hash of the hash algorithm (SHA). In particular, the hash function of the hash algorithm with a hash length of 256 bits (SHA-256) may be used.

[0044] According to another embodiment, a computer program product is provided. The computer program product includes parts of the program code for performing the steps of the method described herein when the computer program product is run on a computer system for a computer device. The computer program product may be stored on a computer readable medium.

[0045] In general, this solution can be used in practice with the help of hardware, software or a method combining hardware / software.

[0046] In the case of a hardware embodiment, a device adapted to generate cryptographic keys for the communication object is provided. The device contains, among others, the following functions: the device can perform the key authentication and reconciliation procedure, which includes generating a cryptographic key. This device includes a first element adapted to provide at least two parameters, the first parameter may include a set of cryptographic keys or be derived from a set of cryptographic keys calculated by the communication object by starting the authentication and key reconciliation procedure, and the second parameter may contain a token or be derived from a token of a different value each time, when the authentication and key agreement procedure for the communication object is initiated. The device further includes a second component adapted to perform a key extraction function to generate a cryptographic key based on specific parameters. As mentioned above, a token can take many potential forms.

[0047] The token may contain SQN or be derived from SQN, indicating how many times the authentication and key reconciliation procedure for the communication object has been initiated. In one embodiment, the SQN itself is a token. Alternatively, the token may be derived from SQN using an algorithm comprising at least one of arithmetic operations, logic operations and chain operations. For example, the token may contain or be output from AUTN, which is built on the basis of SQN and delivered to the communication object, this construction and delivery forming parts of the security operation. For example, the token may be a concatenation of the 'OR exclusive' OR sequence number (SQN) and anonymity key (AK), Authentication and key management field (AMF) and message authentication code (MAC). In particular, it can be expressed as:

token = AUTN = (SQN xOR AK) || AMF || MOTHER.

[0048] In addition to the token, the second parameter may include RAND or be derived from RAND. RAND can be delivered to the communication object as part of the security operation. In addition, the second parameter may include the communication object identifier or be derived from the communication object identifier. An example of an identifier is the private user identification number (IMPI) of a communication object. In addition, the second parameter can be derived from the identifier

- 9 serving network communication object, or include it. This identifier may be the PLMN_ID identifier.

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

0x02 || PLMN_ID || RAND || IMPI || token.

[0050] When the token is SQN, the above becomes:

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

and when the token means AUTN, the above becomes:

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

[0051] As mentioned above, the first parameter may include a set of cryptographic keys or be derived from a set of cryptographic keys. In particular, this set of cryptographic keys may contain a cipher key (CK) and an integrity key (IK), which were calculated by the communication object as part of the security operation. Alternatively, the cryptographic key set can be derived from the cipher key and the integrity key.

[0052] As a particular implementation, the first parameter may be derived from or include CK and IK concatenation, which may be expressed as:

CK || IK.

[0053] The device can generate not only the cryptographic key based on the specified first and second parameters, but also more cryptographic keys based on the generated cryptographic key. In this way, the device can be adapted to use one or more additional key extraction functions to generate more cryptographic keys based on the cryptographic key that has been generated.

[0054] This "greater number of cryptographic keys" may include at least one cryptographic key set for NAS traffic protection, a cryptographic key set for RRC traffic protection, a set of cryptographic keys for UP traffic protection and an intermediate KeNB cryptographic key for deriving cryptographic keys for traffic protection RRC and / or cryptographic keys to protect UP traffic.

[0055] The communication object referred to above can be user equipment, such as a mobile station (e.g., cellular telephone or network card).

[0056] According to another embodiment, a user equipment is provided comprising the device described above. The user equipment may be a portable station.

[0057] According to yet another embodiment, a system is provided comprising the above-mentioned user device. The system also contains a network object. The network object can be used within the SAE / LTE network. A network object can

- 10 contain AuC / HSS and MME. MME may be responsible for initiating security operations for user equipment. AuC / HSS can generate a cryptographic key. Generated cryptographic keys can be shared between user equipment and MME. AuC / HSS can increment SQN, in particular whenever a security operation is initiated for user equipment. In addition, AuC / HSS can also build AUTN based on SQN.

Brief Description of the Drawings [0058] The technique for generating cryptographic keys will be described below with reference to the embodiments shown in the drawings, in which:

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

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

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

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

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

Fig. 6 is a block diagram illustrating a UMTS AKA operation procedure, generating an authentication vector by a network object;

Fig. 7 is a block diagram illustrating another UMTS AKA operation procedure, authentication and key setting;

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

Fig. 9 is a block diagram showing a specific cryptographic algorithm for performing the above authentication function on a UE; and

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

Detailed Description [0059] In the following description, specific details, for example specific step sequences, interfaces and configurations, are provided to clarify rather than limitations in order to provide a thorough understanding of the cryptographic key generation technique. It will be apparent to those skilled in the art that this technique can be used in other embodiments that deviate from these specific details. For example, although this technique will mainly be described in the context of the UMTS AKA protocol and in the SAE / LTE network environment, it will be obvious to experts in the field that this technique can also be used in practice in conjunction with other security protocols, architectures or environments.

[0060] In addition, those skilled in the art will appreciate that the functions explained below can be performed using software operating in conjunction with programmed

- 11 microprocessor or universal computer. It will also be understood that although this technique is primarily described in the form of methods and devices, this technique can also be embedded in a computer program product as well as in a system comprising a computer processor and memory attached to the processor in which the memory is encoded using one or more programs that may perform the functions disclosed herein.

[0061] Fig. 3 shows an embodiment of a device 100 adapted to generate cryptographic keys for a communication object (not shown in Fig. 3). The communication object is adapted to run security operations. The device 100 includes a first element 102 and a second element 104. The first element 102 is adapted to provide at least two parameters, shown symbolically at arrows 106 and 108.

[0062] The first parameter 106 includes or is derived from the cryptographic key set 110 and 112. (Although two keys are shown in the figure, the cryptographic key set may contain any number of keys.) The cryptographic key set was calculated using a communication object by starting the operation protection. Deriving the cryptographic key set 110 and 112 to the first parameter 106 is symbolically represented as block 114. The second parameter 108 contains or is derived from token 116. Token 116 has a different value each time a security operation is initiated for a communication object. The output of token 116 to the second parameter 108 is symbolically represented as block 118. The second element 104 of the device 100 is adapted to activate the key extraction function to generate a cryptographic key 120 based on the parameters 106 and 108 shown.

[0063] Fig. 4 shows an embodiment of the system 200, the above-mentioned device 100 comprising it. The device 100 may be included in a communication unit 202, which may be a UE, e.g. a portable station. Of course, communication object 202 may be any suitable type of communication object capable of accommodating device 100. In addition, the system includes a network object 204 that may be on a SAE / LTE network. The network object 204 may contain AuC or HSS and MME. There may also be another communication object in the SAE / LTE network.

[0064] Fig. 5 is a diagram 300 illustrating an embodiment of a method for generating a cryptographic key, analogous to the cryptographic key generating device 100 shown in Figures 3 and 4. The generated key is used to protect communication between two objects. The first object 302 may correspond to the communication unit 202 as shown in Fig. 4, and the second object 304 may correspond to the network object 204 of Fig. 4. The first facility can be UE. However, the embodiment is not limited to the UE network scenario. Instead, it can apply to any two communication units at all.

[0065] The MME may be responsible for initiating the security operation for the communication object 202. The generated cryptographic keys may be common to the MME and the communication object 202.

[0066] In particular, the embodiment of the method is implemented by the first object 302 as part of the security operation, symbolically depicted by the arrow 300 ', which is initiated by the second object 304 (in particular by its MME) for the first object 302. The example itself the embodiment includes two steps, 306 and 308. Step 306 provides at least two parameters (106 and 108 in Fig. 3). The first parameter includes or is derived from a set of cryptographic keys (110 and 112, as shown in Fig. 3), which were calculated using the first object 302 by running the security operation 300 '. The second parameter includes or is derived from a token (116, as shown in Fig. 3), which has a different value each time the security operation 300 'is initiated by the second object 304 for the first object 302. In the second step 308, the key extraction function was used to generate a cryptographic key (120, as shown in Fig. 3) based on specific parameters (106 and 108, as shown in Fig. 3).

[0067] The following are important details to explain the technique for generating cryptographic keys, with particular emphasis on how this technique can successfully avoid key conflicts between two UEs, or more importantly, between two separate performances of security operations for one and the same UE .

[0068] Cryptographic key generation can be part of UMTS AKA operation. UMTS AKA is based on such an implementation that the UE, especially its USIM, and AuC / HSS in a home environment (HE) UE jointly use a confidential user-specific key, certain f1, f2 message authentication functions and some f3 cryptographic key generation functions , f4, f5. In addition, USIM and AuC / HSS track the counters or SQNUE and SQNHE sequence numbers, respectively, to support network authentication. For example, AuC / HSS may increment SQNHE, especially each time a security operation is initiated for the first object. Operation UMTS AKA includes many procedures, including the generation of authentication vectors (AV) as well as authentication and key setting.

[0069] The purpose of the AV procedure is to provide an SN / VLR (or MME) with a table of new authentication vectors from the user equipment HE to perform multiple user authentications. Creating Authentication Vectors using HE is shown in Fig. 6. Referring to this figure, upon receiving a request from SN / VLR, AuC / HSS sends an ordered series of n AV Authentication Vectors (1 ... n) to SN / VLR. Each AV contains a random number (or random challenge) of RAND, expected XRES response, CK cipher key, IK integrity key and AUTN authentication token.

[0070] AuC / HSS begins by generating a new SQN sequence number and an unpredictable RAND challenge. The following values ​​are then calculated:

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

- expected response XRES = f2 (RAND), where f2 is (probably foreign) the message authentication function;

- cipher key CK = f3 (RAND), where f3 is the key generation function;

- integrity key IK = f4 (RAND), where f4 is the function of generating keys and

- anonymity key AK = f5 (RAND), where f5 is the key generation function.

[0071] Finally, AUTN = (SQN xOR AK) authentication token || AMF || MAC is being built. Can be built by AuC / HSS. Here, AK is the key to anonymity used to hide SQN because the latter can reveal the identity and location of the EU. Hiding SQN is designed to protect against passive attacks. The use of AK may be optional. However, if AK is not used, the value AK = 000 ... 0 can be used symbolically.

[0072] The authentication vector table is sent back to the requesting SN / VLR in the authentication response. Each AV is valid for one (and only one) authentication and key agreement between SN / VLR and USIM.

[0073] The next procedure for the operation of UMTS AKA, authentication and key setting is mutual authentication and establishment of a new cipher and integrity key between SN / VLR and UE. This process is illustrated in Fig. 7. Referring to this figure, when SN / VLR initiates key authentication and handshaking, it selects the next AV from the table and sends RAND and AUTN parameters to the UE. USIM checks if AUTN can be accepted and, if so, produces an RES response that is sent back to SN / VLR. In particular, Fig. 8 shows EU procedures.

[0074] Referring to Fig. 8, after receiving 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 next UE calculates XMAC = f1 (SQN || RAND || AMF) and compares it with the MAC which is contained in AUTN. If different, the UE sends the rejection of the user authentication back to the SN / VLR indicating the reason, and the UE aborts this procedure. In addition, the UE checks if the received SQN is within the appropriate range.

[0075] If the SQN is considered to be in the appropriate range, the UE calculates RES = f2 (RAND) and includes this parameter in the user authentication response back to the SN / VLR. Finally, the UE calculates the cipher key CK = f3 (RAND) and the integrity key IK = f4 (RAND). To increase performance, you can also calculate RES, CK and IK in advance at any time after receiving RAND. The UE may store RAND for resynchronization purposes.

[0076] Upon receiving the user authentication response, the SN / VLR compares the RES with the expected XRES response from the selected authentication vector. If XRES is RES, then user authentication has been accepted. Newly calculated

- 14 CK and IK keys will then be transferred using USIM and SN / VLR to objects that perform encryption and integrity functions.

[0077] From the above, it can be seen that the UMTS AKA operation is based on a pair (RAND, AUTN), and AUTN includes or is derived from the SQN sequence number as:

AUTN = (SQN xOR AK) || AMF || MAC where AK is the anonymity key that can be generated by MILENAGE (see Fig. 9) from output "f5" above.

[0078] The following function is the first solution to the conflict problem identified above:

KDF (CK || IK, RAND || IMPI || SQN) where SQN has therefore been included in the entries. Now, even if the two RANDs are the same, i.e. RAND = RAND ', the fact that SQN always increases (e.g. by one) will ensure that the inputs are different, unique or different.

[0079] An alternative solution is to use:

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

[0080] This solution may be simpler to implement because AUTN can be used "as is" from AKA signaling. However, the "uniqueness" of the entries in this case cannot be obvious, because:

AUTN = (SQN xOR AK) || AMF || MAC and even if SQN ψ SQN ', it cannot be immediately seen that (SQN xOR AK), (SQN' xOR AK ') will be different when AK could potentially "cancel" the differences. However, below, expressiveness can be proved (SQN xOR AK).

[0081] Suppose that:

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

[0082] It has already been shown that this means CK = CK ', IK = IK' and RAND = RAND '. It remains to be seen whether AUTN = AUTN 'can be so. This check may translate into checking that:

(SQN xOR AK) || AMF || MAC = (SQN 'xOR AK') || AMF '|| MOTHER'.

[0083] Suppose without loss of generality that AMF = AMF 'and MAC = MAC'. Then it is only necessary to check whether the following could persist:

SQN xOR AK = SQN 'xOR AK'.

[0084] We remind you that RAND = RAND 'is expected. Referring to the MILENAGE algorithm shown in Fig. 9, this means that AK = AK '(as manufactured from the same RANDs). So, it had to be that:

SQN = SQN ',

- 15 which is contradictory, because, as already mentioned, SQN always "increases", and therefore SQN 7 SQN '.

[0085] Thus, it has been proved that the second solution also guarantees the uniqueness of the KDF function entries.

[0086] As a general solution, instead of using SQN or AUTN to achieve uniqueness, any token having a different value can be implemented each time UMTS AKA operation is initiated by the UE network. For example, SQN xOR AK (forming part of AUTN) can be used because (according to the above analysis) it had the required uniqueness property.

[0087] The technique for generating cryptographic keys described above presents many advantages. For example, it guarantees the uniqueness of KDF entries. Therefore, they will successfully avoid conflicts caused by identical entries. Thanks to this technique, the generated cryptographic key is able to meet, for example, high security requirements in SAE / LTE systems. Another advantage is that this technique can be implemented based on already deployed USIM cards, without having to replace USIM. Another special advantage of using AUTN and not SQN is that the invention can be implemented in a mobile terminal (outside USIM).

[0088] Although embodiments of the cryptographic key generation technique are shown in the accompanying drawings and described in the above description, it should be understood that the technique is not limited to the embodiments disclosed herein. The technique is capable of numerous system changes, modifications and substitutions without departing from the scope of the invention.

Prepared and verified

Grażyna Palka

Patent Attorney