Creation of cryptographic key

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

Authentication / Cryptographic Key Delivery Protocol (AKA) is a challenge-response protocol that uses symmetric cryptography. The main purpose of AKA includes mutual authentication by two entities communicating with each other and establishment of a cryptographic key to protect the communication exchanged between them. One variant of AKA is UMTS AKA, which is included in the security architecture standardized by 3GPP for 3G mobile communication networks in the technical specification Non-Patent Document 1.

The basic concept of UMTS AKA is shown in Figure 1. With reference to this figure, the UMTS AKA protocol runs between the user equipment (UE) and the network entity (NE). The network entity initiates AKA by sending a user authentication request to the UE. Along with the request, a random number challenge or random code (RAND) and authentication token (AUTN) are sent to the UE. Upon receiving the RAND and AUTN, the UE calculates, among other things, the secret key (CK, Cipher Key) and the integrity key, which is then used for the secret and integrity functions.

3GPP has also embarked on the standardization of so-called "beyond 3G" communication networks. System Architecture Revolution (SAE) and Long Term Evolution (LTE) are two aspects closely related to networks beyond 3G. Compared to traditional 3G networks, SAE / LTE based networks can impose advanced and / or many security requirements. For example, more encryption keys may be needed to protect communications at various levels. In another standard-related document, Non-Patent Document 2, 3GPP recommends a key hierarchy to derive more cryptographic keys used in SAE / LTE.

Figure 2 shows this key hierarchy. At the top of the hierarchy is key K, which is a long-term cryptographic key shared between the UE's general-purpose subscriber identification module (USIM) and the authentication center (AuC) located in the network. The next lower level is the pair of cryptographic keys CK, IK derived by the UE, especially by the USIM within the UE, in the same or similar manner as the UMTS AKA operation described above. Further down in the hierarchy is the key K, which is derived by the UE from CK, IK, and some other parameters if necessary._ASMEIs. When derived, K_ASMEIs transferred from AuC to the access network, especially to the Access Securing Management Entity (ASME) of the SAE / LTE network, and then shared between the UE and the network. When the access network is based on LTE technology, ASME functions are handled by the Mobility Management Entity (MME).

Key K_ASMEAnd its "lower" key in the hierarchy can be derived by applying some cryptographic function. For example K_ASME= KDF (CKTheIK, 0x02ThePMLN_IDThe <other parameters>) And here, KDF is based on the Key Derivation Function (KDF) of the General Bootstrapping Architecture (GBA). One GBA KDF is specified in Non-Patent Document 3.

GBA KDF can utilize cryptographic hash functions such as the Secure Hash Algorithm (SHA) hash function. Of the many SHA hash functions, SHA-256 is a highly secure variant. This is because collision resistance is taken into consideration and it behaves like a pseudo-random function. As the name suggests, SHA-256 is a hash function of a secure hash algorithm with a digest (output) length of 256 bits. PLMN_ID is the identifier of the network that provides the service to the UE.

It has been recognized that it is not sufficient for GBA KDF functions to be based primarily solely on CK and IK to achieve a high level of security. The rationale for this is the risk that a given UE may get the same CK twice, or two different UEs may get the same CK. In such cases, the "uniqueness" of the input to the KDF is uncertain (same K)._ASME) Collisions between different UEs can occur.

The general view is that if x = y, then KDF (x) will certainly produce the same key as KDF (y), but the opposite is not always true. That is, it may happen that KDF (x) = KDF (y) even if x y. However, this is unlikely, as KDF is recommended to be based on SHA-256, which is designed to be collision resistant as described above. Therefore, with respect to the technique described herein, it can be assumed without any problem that KDF (x) = KDF (y) holds only when x = y. With this assumption, the techniques described herein are focused on ensuring the "uniqueness" of the input to the KDF.

The GBA KDF specification standards body (ETSI / SAGE, Special Algorithm Experts Group) has focused on the above issues and set the UE's private user identifier (IMPI) to <other parameters> to avoid conflicts between different UEs. It is recommended to include it. As a further recommendation, random code such as RAND may also be included in <other parameters>. This is explained (in Non-Patent Document 4) in the liaison statement from ETSI / SAGE to 3GPP SA3.

However, it has been discovered that the above recommendations still cannot guarantee the "uniqueness" of the input to the KDF. This can be seen from the following analysis of the security characteristics of the GBA KDF function and its usage in SAE / LTE for one and the same UE (eg, one and the same IMPI).

First, the following basic structure is considered: KDF (CK, IMPI).

Since it is assumed that IMPI = IMPI ́ (if the UE is constant), this basic structure is for and only if CK = CK ́, then two inputs (CK, IMPI). , (CK ́, IMPI ́) will lead to a collision.

Second, another structure is considered, which is closer to the actual GBA KDF: KDF (CKTheIK, IMPI).

However, including IK in the input does not change the above collision characteristics, as you might believe at first. That is, KDF (CKTheIK, IMPI) will be equal to KDF (CK ́The IK ́, IMPI) only if CK = CK ́. To understand why including IK does not help, we need to consider how cryptographic algorithms performed on the UE produce CK and IK.

A typical UE-side cryptographic algorithm is the Milenage algorithm shown in Figure 9. In Figure 9, Ek shows the Advanced Encryption Standard (AES) algorithm, also known as the Rheindal algorithm, which uses the key K (stored in the AuC and UE USIM). Now consider what happens when CK = CK ́. Since AES is a permutation (one-to-one correspondence), this implies that the median (occurred in the thick arrow) is uniquely determined by the output of f3, which happens to be CK. However, this implies that the value in the thick arrow when creating CK must be the same as the value that occurs in the same place where CK ́ is created. Similarly, this means that the values that occur as inputs to f4 must be the same, and as a result the same values of f4 must occur. Because this happens, f4 is IK. Therefore, it is shown that CK = CK ́ only when IK = IK ́ and only in that case.

Next, consider including an "improved" structure, ie RAND, in the input that follows the recommendations of the standards body (SAGE): KDF (CKTheIK, RANDTheIMPI).

Suppose CK = CK ́ (hence IK = IK ́). It is expected that uniqueness is guaranteed by using RAND. However, this is not true. Again, we consider the "relevant" part of the millenage algorithm that produced CK and IK from RAND. As shown in Figure 9, there are situations where the value on the thick arrow corresponding to RAND is the same as that corresponding to RAND ́. But again AES (Ek) is a permutation, so that both inputs should still be equal. That is, RAND = RAND ́. (The fact that AES depends on K does not help, because a certain UE is assumed and therefore the same K will occur in both cases.)

In other words, it is shown that (CK The IK, RAND The IMPI) = (CK ́The IK ́, RAND ́The IMPI) only when and only when RAND = RAND ́. In the case of SAE / LTE, PLMN_ID may also be included in the input, but this parameter PLMN_ID is unreliable for the purpose of guaranteeing uniqueness, as it is quite possible that the UE will stay in the same network several times. ..

An alternative approach to avoiding conflicts could be to use a different algorithm than AES for the cryptographic processing of the f3 and f4 algorithms. In particular, the above analysis was based on the fact that AES is a substitution. Therefore, it could be possible to use non-substitution (many-to-one correspondence) instead of AES. This is a problem for two reasons. First, the existing USIM must be adapted to suit the 3GPP SAE architecture. Second, choosing a non-permutation function actually increases the chances of two outputs, for example f3, colliding.

Lack of input uniqueness can be a serious security issue. Collisions occur only when RAND = RAND ́, and since RAND is 128 bits, the collision is about 2^(128/2)=2⁶⁴Expected to occur after multiple certifications (this is the so-called "birthday paradox"). Obviously, this is below the GBA's target security level (which is 128-bit). Even worse for LTE. That's because LTE needs to provide a 256-bit security level. Therefore, a high collision probability is a serious obstacle to providing the security level required in SAE / LTE.

<p><nplcit num="1"><text>3G TS33.102</text></nplcit><nplcit num="2"><text>3GPP TR33.821</text></nplcit><nplcit num="3"><text>3G TS33.220</text></nplcit><nplcit num="4"><text>3GPP document number S3-030219</text></nplcit></p>

<p> Therefore, a solution to avoid the above-mentioned collision is required. The solution also ideally works with USIMs already distributed and should not require replacement of all USIMs.</p>

<p> According to the first aspect, a method for generating an encryption key is provided. Cryptographic keys are used specifically to secure communication between two entities. This method is executed by the first entity. The method forms part of a distributed security operation initiated by a second entity. The method comprises providing at least two parameters, the first parameter comprising or being derived from a set of cryptographic keys calculated by the first entity by performing a security action. The second parameter either has or is derived from a token that has a different value for the first entity each time the second entity initiates a security action (in other words, the value of the token is never for any two security actions. Not the same). The method involves applying a key derivation function to generate a cryptographic key based on the parameters provided.</p><p> The expression "parameter comprises X" can mean that the variable X forms the parameter or a part thereof in the string form. The expression "parameters are derived from X" can mean that the parameters are at least the result of applying a given function, such as a mathematical function, to the variable X. Examples of functions include, but are not limited to, arithmetic operations, logical operations, string operations, and any combination thereof. Arithmetic operations can be addition, subtraction, multiplication, etc., or any meaningful combination of these. Logical operations can be AND, OR, exclusive OR (xOR), NOT, etc., or any meaningful combination of these. The string operation can be concatenation, inversion, substitution, etc., or any meaningful combination of these. In addition, arithmetic operations, logical operations, and string operations can be combined.</p><p> In particular, the token described above may include or be derived from a sequence number (SQN) indicating the number of security actions initiated by the second entity for the first entity. At each start, the SQN can be increased by a second entity. This mechanism ensures that the token has a different value for each security action initiated.</p><p> Tokens can take many forms. In one case, the SQN itself can be a token. Alternatively, tokens can be derived from SQN using algorithms that involve a given mathematical operation, such as at least one of arithmetic, logical, and string operations. For example, the token may include or be derived from an authentication token (AUTN) created by the second entity based on the SQN and delivered to the first entity. This creation and delivery can be part of a security operation.</p><p> In particular, the token may have an exclusive OR with the SQN and the Anonymity Key (AK). More specifically, the token can be the exclusive OR of the SQN and the anonymous key (AK), the authentication / key management field (AMF), and the concatenation of the message authentication code (MAC). This connection is Token = AUTN = (SQN xOR AK) The AMF The MAC Or Token = function (AUTN) = function ((SQN xOR AK) The AMFThe MAC) Can be expressed as.</p><p> The second parameter can further include a random number challenge or random code (RAND) or can be derived from the RAND. The RAND can be generated by the second entity and delivered to the first entity as part of the security action. The second parameter can still include or be derived from the identifier of the first entity. This identifier can be a private user identifier (IMPI) or an international mobile subscription identifier (IMSI). Still further, the second parameter comprises or can be derived from an identifier of the communication network and in particular the serving network of the first entity. For example, this identifier can be a public terrestrial mobile network identifier (PLMN_ID).</p><p> Specifically, the second parameter comprises or can be derived from a concatenation of 0x02, PLMN_ID, RAND, IMPI or IMSI, and tokens. is this, 0x02 The PLMN_ID The RAND The IMPI The token Can be expressed as. If the token is the SQN itself, the above 0x02 The PLMN_ID The RAND The IMPI The SQN And if the token is AUTN, the above 0x02 The PLMN_ID The RAND The IMPI The AUTN Will be.</p><p> With respect to the first parameter used in this method, this parameter may include or be derived from a set of cryptographic keys obtained by the first entity by performing a security action. A set of cryptographic keys may include or be derived from a secret key (CK) and an integrity key (IK).</p><p> CK and IK can be a secret key and an integrity key calculated by the first entity based on AUTN and RAND. AUTN and RAND can be delivered from the second entity. AUTN and RAND distribution as well as this calculation can form part of the security operation.</p><p> In one implementation, the first parameter has a concatenation of CK and IK, or can be derived from this concatenation. This can be mathematically expressed as CKTheIK.</p><p> The method described herein generates an encryption key. This key can be shared by at least the first and second entities in any subsequent communication between them. In one implementation, this key is the K referenced in the "key hierarchy" in Figure 2._ASMEIt can be shared by the access security management entity (ASME) of the first entity and the second entity.</p><p> The method can be extended to have one or more additional key derivation functions applied to generate many cryptographic keys. Such generation is an encryption key generated by the basic non-extending method described above, eg K_ASMEBased on or use this.</p><p> The cryptographic keys generated in the extended way are a set of cryptographic keys to protect non-access stratum (NAS) traffic, a set of cryptographic keys to protect radio resource control (RRC) traffic, and a user plane (UP). ) A set of encryption keys to protect traffic, and a K to derive at least one of the encryption keys to protect RRC traffic and the encryption keys to protect UP traffic._eNBCan include at least one of an intermediate encryption key, such as. To facilitate the understanding of these keys, reference is made to Figure 2, which illustrates the key hierarchy used in SAE / LTE.</p><p> Specifically, the set of encryption keys for protecting NAS traffic is the key for protecting NAS traffic with an encryption algorithm (K)._NASenc) And another key (K) to protect the NAS traffic with the integrity algorithm_NASint) And at least one of them can be provided. Similarly, the set of encryption keys for protecting RRC traffic is the key for protecting RRC traffic with an encryption algorithm (K)._RRCenc) And another key (K) to protect RRC traffic with an integrity algorithm_RRCint) And at least one of them can be provided. In addition, the set of encryption keys for protecting UP traffic is the key for protecting UP traffic with an encryption algorithm (K)._UPenc) Can be provided.</p><p> For the techniques described herein, the "first entity" can be a user device such as a mobile station. The "second entity" can be an entity located within the communication network and therefore can be a "network entity". In particular, the second entity can be located within the SAE / LTE network.</p><p> The second entity can include an authentication center (AuC) / home subscriber server (HSS) and a mobility management entity (MME). The MME may be responsible for initiating a security action on the first entity. The generated encryption key is generated by AuC / HSS and can be shared by the first entity and the MME. AuC / HSS can increment the SQN each time a security action is initiated, especially for the first entity. In addition, AuC / HSS can also create AUTNs based on SQNs.</p><p> The security actions referred to herein can be performed in conjunction with a first entity and a second entity. For example, security actions can be based on AKA procedures such as the UMTS AKA protocol.</p><p> The key derivation function referenced in this method can be a general purpose bootstrapping architecture (GBA) key derivation function. The general-purpose bootstrapping architecture key derivation function can employ the Secure Hash Algorithm (SHA) hash function. In particular, a hash function (SHA-256) of a secure hash algorithm with a 256-bit length digest can be employed.</p><p> According to another aspect, computer program products are provided. The computer program product comprises a computer code portion for performing the steps of the method described herein when the computer program product is run on a computer system for a computer. Computer program products can be stored on computer-readable recording media.</p><p> In general, the solution can be implemented with a hardware, software, or integrated hardware / software approach.</p><p> For hardware implementation, devices are provided that are configured to generate cryptographic keys for communication entities. The device can perform security operations, and cryptographic key generation can be part of it. The device comprises a first component configured to provide at least two parameters. The first parameter includes or is derived from a set of cryptographic keys calculated by the communication entity by performing a security action. The second parameter either comprises or is derived from a token having a different value each time a security action is initiated for the communication entity. The apparatus further comprises a second component configured to execute a key derivation function to generate an encryption key based on the parameters provided. As mentioned above, tokens can take many possible forms.</p><p> The token either comprises an SQN indicating the number of security actions initiated for the communication entity, or can be derived from this SQN. In one implementation, the SQN itself is a token. Alternatively, tokens can be derived from SQN using algorithms that involve at least one of arithmetic, logical, and string operations. For example, the token may include or be derived from an AUTN created based on the SQN and delivered to the communication entity. Here, this creation and delivery forms part of the security action. For example, the token can be the exclusive OR of the SQN and the anonymous key (AK), the authentication / key management field (AMF), and the concatenation of the message authentication code (MAC). In particular, this is Token = AUTN = (SQN xOR AK) The AMF The MAC Can be expressed as.</p><p> In addition to the token, the second parameter may further comprise or be derived from this RAND. RANDs can be delivered to communication entities as part of a security action. In addition, the second parameter may include or be derived from the identifier of the communication entity. An example of this identifier is the communication entity's private user identifier (IMPI). Still further, the second parameter comprises or can be derived from the identifier of the serving network of the communication entity. This identifier could be a public terrestrial mobile network identifier (PLMN_ID).</p><p> A specific example of the second parameter comprises or can be derived from a concatenation of 0x02, PLMN_ID, RAND, IMPI or IMSI, and tokens. For example, the second parameter is 0x02 The PLMN_ID The RAND The IMPI The token Can be expressed as. If the token is SQN, the above 0x02 The PLMN_ID The RAND The IMPI The SQN And if the token is AUTN, the above 0x02 The PLMN_ID The RAND The IMPI The AUTN Will be.</p><p> As mentioned above, the first parameter may include or be derived from a set of cryptographic keys. In particular, this set of cryptographic keys may include a secret key (CK) and an integrity key (IK) calculated by the communication entity as part of the security operation. Alternatively, the set of cryptographic keys can be derived from the secret and integrity keys.</p><p> As a particular implementation, the first parameter may include a CK-IK concatenation, which can be expressed as CKTheIK, or may be derived from this concatenation.</p><p> The device can not only generate an encryption key based on the provided first and second parameters, but also generate an additional encryption key based on the generated encryption key. In doing so, the device may be configured to apply one or more additional key derivation functions to generate additional encryption keys based on the generated encryption keys.</p><p> These "further cryptographic keys" are a collection of cryptographic keys for the protection of non-access stratum (NAS) traffic, a collection of cryptographic keys for the protection of radio resource control (RRC) traffic, and user plane (UP) traffic. A set of encryption keys to protect RRC traffic, and K to derive at least one of the encryption keys to protect RRC traffic and the encryption key to protect UP traffic._eNBIt may have at least one of the intermediate encryption keys, such as.</p><p> The communication entity referred to above can be a user device such as a mobile station (eg, a mobile phone or network card).</p><p> According to a further aspect, a user device is provided with the device presented above. The user device can be a mobile station.</p><p> Still further aspect, a system comprising the above-mentioned user equipment is provided. The system also includes network entities. Network entities can be used within SAE / LTE networks. Network entities can include AuC / HSS and MME. MME may be responsible for initiating security operations on user equipment. AuC / HSS can generate encryption keys. The generated encryption key can be shared between the user device and the MME. AuC / HSS can increment the SQN each time a security operation is initiated, especially for user equipment. In addition, AuC / HSS can also create AUTNs based on SQNs.</p>

<figref num="1">It is a figure which shows the basic concept of the UMTS AKA protocol.</figref><figref num="2">It is a block diagram explaining the key hierarchy proposed about the SAE / LTE system.</figref><figref num="3">It is a block diagram which shows the embodiment of an apparatus.</figref><figref num="4">It is a block diagram which shows the embodiment of a system.</figref><figref num="5">It is a block diagram which shows embodiment of the method.</figref><figref num="6">It is a block diagram which shows the authentication vector generation by a network entity which is a procedure of UMTS AKA operation.</figref><figref num="7">It is a block diagram showing authentication / key establishment which is another procedure of UMTS AKA operation.</figref><figref num="8">It is a block diagram which shows the general-purpose authentication function performed by UE as a part of UMTS AKA operation.</figref><figref num="9">It is a block diagram which shows the specific cryptographic algorithm for performing the above-mentioned authentication function in UE.</figref><figref num="10">It is a block diagram which shows the specific details of the above-mentioned cryptographic algorithm.</figref>

The cryptographic key generation technique will be described below with reference to the exemplary embodiments described in the drawings.

The following description describes individual details such as specific step sequences, interfaces, and configurations to provide a complete understanding of cryptographic key generation techniques, for illustration purposes only and not for limitation purposes. .. It will be apparent to those skilled in the art that the technique may be practiced in other embodiments that deviate from these individual details. For example, while the technology is described primarily in the context of the UMTS AKA protocol in a SAE / LTE network environment, those skilled in the art can also implement the technology in connection with other security protocols, architectures, or environments. It will be clear to.

In addition, those skilled in the art will appreciate that the functions described below herein can be performed using software that works in conjunction with a programmed microprocessor or general purpose computer. Although the technology is described primarily in the form of methods and devices, the technology may also be embodied in computer program products, as well as in systems with a computer processor and memory coupled to the processor. It will also be understood that it may be transformed. Here, the memory is encoded by one or more programs that perform the functions disclosed herein.

FIG. 3 shows an embodiment of device 100 configured to generate an encryption key for a communication entity (not shown in FIG. 3). Communication entities are configured to perform security actions. The device 100 includes a first component 102 and a second component 104. The first component 102 is configured to provide at least two parameters, as shown figuratively by arrows 106, 108.

The first parameter 106 comprises or is derived from a set of encryption keys 110, 112. (Although the figure shows two keys, the set of cryptographic keys can contain any number of keys.) The set of cryptographic keys is calculated by the communication entity by performing a security action. Derivation of the first parameter 106 from the set of encryption keys 110, 112 is figuratively shown as block 114. The second parameter 108 comprises or is derived from this token 116. Token 116 has a different value each time a security action is initiated for a communication entity. Derivation of the second parameter 108 from token 116 is figuratively shown as block 118. The second component 104 of the device 100 is configured to perform a key derivation function to generate the encryption key 120 based on the parameters 106, 118 provided.

An embodiment of a system 200 with the device 100 described above is shown with reference to FIG. The device 100 may be included in a communication entity 202 that may be a UE, such as a mobile station. Of course, the communication entity 202 can be any suitable type of communication entity compatible with device 100. In addition, the system comprises network entities 204 that can reside within the SAE / LTE network. Network entity 204 may include AuC or HSS and MME. It can also be another communication entity within the SAE / LTE network.

FIG. 5 shows an embodiment of a method for generating an encryption key corresponding to the encryption key generation device 100 shown in FIGS. 3 and 4. The generated key is used to protect the communication between the two entities. The first entity 302 may correspond to the communication entity 202 shown in FIG. 4, and the second entity 304 may correspond to the network entity 204 of FIG. The first entity can be UE. However, this embodiment is not limited to the scenario between UE and network entities. Instead, it can generally be applied to any two communication entities.

The MME may be responsible for initiating a security action on the communication entity 202. The generated encryption key can be shared by the MME and the communication entity 202.

In particular, an embodiment of the method is performed by the first entity 302 as part of a security action figuratively described by arrow 300 ́. The security action is initiated by the second entity 304 (especially its MME) for the first entity 302. The embodiment itself has two steps 306, 308. Step 306 provides at least two parameters (106 and 108 in Figure 3). The first parameter comprises or is derived from a set of cryptographic keys (110 and 112 shown in FIG. 3) calculated by the first entity 302 by performing security action 300 ́. The second parameter either comprises or is derived from a token (116 shown in FIG. 3) that has a different value each time the security action 300 ́ is initiated by the second entity for the first entity 302. In the second step 308, a key derivation function is applied to generate a cryptographic key (120 shown in Figure 3) based on the parameters provided (116 and 118 shown in Figure 3).

Below, in particular, how the Technology successfully avoids key conflicts between two UEs, or, more importantly, between two different executions of security behavior for one and the same UE. Substantial details are given to explain the cryptographic key generation technique, with emphasis.

Cryptographic key generation can be part of UMTS AKA operation. UMTS AKA has a UE, especially its USIM, and AuC / HSS in the UE's home environment (HE) with a user-specific private key K, predetermined message authentication functions f1, f2, and a predetermined encryption key generation function f3. Based on the implementation of sharing f4 and f5. In addition, USIM and AuC / HSS are counter or sequence number SQN to support network authentication._UE, SQN_HETo manage each. For example, AuC / HSS has an SQN, especially every time a security action is initiated for the first entity._HECan be incremented. The UMTS AKA operation has multiple procedures, including authentication vector (AV) generation, authentication and key establishment.

The purpose of the AV procedure is to provide an array of unused (fresh) AV from the UE HE to the SN / VLR (or MME) to perform multiple user authentications. Authentication vector generation by HE is illustrated in Figure 6. With reference to this figure, upon receiving a request from the SN / VLR, AuC / HSS sends an ordinal array of n authentication vectors AV (1 ... n) to the SN / VLR. Each AV is equipped with a random number (ie, random number challenge) RAND, expected response XRES, secret key CK, integrity key IK, and authentication token AUTN.

AuC / HSS starts by generating an unused sequence number SQN and an unpredictable challenge RAND. Then the following values are calculated: -Message authentication code MAC = f1 (SQNTheRANDTheAMF), where f1 is the message authentication function, -Expected response XRES = f2 (RAND), where f2 is the message authentication function (truncated in some cases), -Hidden key CK = f3 (RAND), where f3 is the key generation function, -Integrity key IK = f4 (RAND), where f4 is the key generation function, -Anonymous key AK = f5 (RAND), where f5 is a key generation function.

Finally, the authentication token AUTN = (SQN xOR AK) The AMFThe MAC is created. It can be created by AUC / HSS. Here, AK is an anonymous key used to keep SQN secret. This is because SQN can expose the UE's identifier and location. SQN concealment is to protect against passive attacks. The use of AK can be optional. If AK is not used, the value AK = 000 ... 0 can be used figuratively instead.

The AV array is returned to the requesting SN / VLR in the authentication response. Each AV is valid for one (and only one) authentication / encryption key delivery between SN / VLR and USIM.

The next procedure for UMTS AKA operation, authentication / key establishment, is mutual authentication between the SN / VLR and UE to establish a new secret key and integrity key. This process is illustrated in FIG. With reference to this figure, when the SN / VLR initiates authentication / encryption key delivery, it selects the next AV from the array and sends the parameters RAND and AUTN to the UE. USIM checks if AUTN is acceptable and, if so, produces a response RES that is returned to the SN / VLR. In particular, the procedure for UE'is shown in FIG.

Upon receiving the RAND and AUTN, the UE first calculates the anonymous key AK = f5 (RAND) (or uses AK = 000 ... 0) and sequence number SQN = (SQN xOR AK), referring to Figure 8. ) Read xOR AK. The UE then calculates XMAC = f1 (SQNTheRANDTheAMF) and compares it to the MAC contained in AUTN. If these are different, the UE will reply to the SN / VLR with an indication of the reason for rejecting the user authentication, and the UE will cancel the procedure. Otherwise, the UE verifies that the received SQN is within 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 the user authentication response returned to the SN / VLR. Finally, the UE calculates the secret key CK = f3 (RAND) and the integrity key IK = f4 (RAND). To improve efficiency, RES, CK, and IK could also be calculated early at any time after receiving the RAND. The UE can remember the RAND for resynchronization.

Upon receiving the user authentication response, the SN / VLR compares the RES with the expected response XRES from the selected authentication vector. If XRES is equal to RES, then the user's authentication is accepted. The newly calculated keys CK, IK will then be transferred by USIM and SN / VLR to the entity performing the confidentiality and integrity functions.

From the above, UMTS AKA operations are based on sets (RAND, AUTN), and UMTS is AUTN = (SQN xOR AK) The AMF The MAC It can be seen that the sequence number SQN is provided or derived from this SQN. Here, AK is an anonymous key and can be created by millenage (see Figure 9) from the output "f5" above.

The following function KDF (CKTheIK, RANDTheIMPITheSQN) Is the first solution to the collision problem mentioned above. Here, the SQN is thus included in the input. Here, the fact that the SQN is always increasing (eg, only 1), even if the two RANDs are the same, ie RAND = RAND ́, will ensure that the inputs are different, unique, or distinguishable. ..

An alternative solution is KDF (CKTheIK, RANDTheIMPITheAUTN) Is to use. This solution can be implemented more simply because AUTN can be used "as is" from AKA signaling. However, the "uniqueness" of the input in this case may not be clear. Because AUTN = (SQN xOR AK) The AMF The MAC And even if SQN SQN ́, it is not immediately apparent that (SQN xOR AK) and (SQN ́ xOR AK ́) are different because AK can cancel the difference in some cases. However, it can be proved that (SQN xOR AK) is different as follows.

(CK The IK, RAND The IMPI The AUTN) = (CK ́The IK ́, RAND IMPI The AUTN ́) Is assumed to hold. It has already been shown that this implies CK = CK ́, IK = IK ́, and RAND = RAND ́. Therefore, it remains to be investigated whether AUTN = AUTN ́ can hold. Examining this is (SQN xOR AK) The AMF The MAC = (SQN ́ xOR AK ́) The AMF ́The MAC ́ Can be replaced by checking if is true.

Let's assume that AMF = AMF ́ and MAC = MAC ́ without loss of generality. Then the following SQN xOR AK = SQN ́ xOR AK ́ It is only necessary to find out if this is possible.

Let us reconsider that RAND = RAND ́ is expected. With reference to the millenage algorithm shown in Figure 9, this implies AK = AK ́ (because they were created from the same RAND). Therefore, SQN = SQN ́ Should be, but this is a contradiction. This is because, as mentioned above, SQN always "steps up", so SQN SQN ́.

Therefore, it is proved that the second solution also guarantees the uniqueness of the input to the KDF function.

As an alternative general solution using SQN or AUTN to achieve uniqueness, any token is available that has a different value each time the network initiates a UMTS AKA operation on the UE. For example, SQN xOR AK (which forms part of AUTN) can be used because it has the required uniqueness properties (by the analysis described above).

The cryptographic key generation techniques described above exhibit a number of advantages. For example, this guarantees the uniqueness of the KDF input. Therefore, it successfully avoids collisions caused by the same possible inputs. Using this technology, the cryptographic keys generated could meet the high level of security requirements of, for example, SAE / LTE systems. As a further advantage, the technology can be implemented based on the already deployed USIM without the need to replace the USIM. Another individual advantage of using AUTN instead of SQN is that the present invention can be implemented in mobile terminals (other than USIM).

Although embodiments of cryptographic key generation techniques have been described in the accompanying drawings and described herein above, it will be appreciated that the techniques are not limited to the embodiments disclosed herein. The present art allows numerous reconstructions, modifications and substitutions without departing from the scope of the invention.