WO2006050663A1

WO2006050663A1 - Method of setting security key

Info

Publication number: WO2006050663A1
Application number: PCT/CN2005/001872
Authority: WO
Inventors: Kunyang Dong; Zhengwei Wang; Chunyan Zhou; Zhiming Zhu; Tianzhen Huang; Jie Kong; Shangbin Wang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2004-11-09
Filing date: 2005-11-08
Publication date: 2006-05-18
Also published as: CN1774125A; CN100579274C

Abstract

A method of setting security key in a mobile communication network includes at least the steps of generating a random number by a mobile terminal or network equipment, then transmitting the random number to the other party, and respectively setting the security key based on the random number in corresponding manner by the network equipment and mobile terminal. Alternatively, the mobile terminal sets the security key and transmits setting-security-key command to the network equipment; and, the network equipment generates the security key in the same manner as that of mobile terminal after receiving the setting-security-key command.

Description

Security key setting method

Technical field

The present invention relates to information security technologies, and in particular to a security key setting method in a mobile communication network. Background of the invention

Most of the current mobile terminals adopt the method of separating the card, that is, the mobile terminal itself and the user card storing the information for the wireless network user of the danger certificate are two independent parts, and they can be combined at the time of use. . The current user card is mainly used for the subscriber identity module card in the wireless communication system, such as the subscriber identity module (SM) card of the Global System for Mobile Communications (GSM) system, the USIM card of the Universal Mobile Telecommunications System (UMTS), and code division multiple access. (CDMA) Communication system UIM card and so on. This method has the advantage of more than 4 points. For example, if the user wants to replace a mobile terminal, he only needs to purchase a new mobile terminal and insert the original SIM card into the new mobile terminal. The information does not need to be changed, so the user does not need to go through any formalities for changing the mobile terminal to the communication carrier. Another advantage of this method is that mobile communication operators can perform mobile services such as number-release work and can be separated from the sales of mobile terminals, thus facilitating the development of mobile services and the relative sales of terminals. Independent: Brings great flexibility to mobile business operations and terminal sales.

However, the use of the machine card separation method brings great convenience to the user, and also causes the mobile terminal to be stolen and robbed. Because in the machine card separation mode, as long as a new SM card is replaced on the stolen mobile terminal, it can be used without any hindrance. In this way, the thief can resell the stolen mobile terminal for profit. In this way, the user not only loses economic benefits, but also needs to go through a series of procedures at the communication operator, such as changing the number of contracts. According to the user, it brings great inconvenience to the user. At the same time, the loss of the mobile terminal, the common information that the user saves in the mobile terminal, such as the directory record, etc., will also be lost, which will cause the user's daily life and work [艮大Impact.

In order to solve the problem that the mobile terminal is easily stolen, a more common method is to set password protection on the mobile terminal. For example, if the power-on password is set on the mobile terminal, the correct power-on password needs to be input every time the power is turned on, and the mobile terminal can perform subsequent operations such as registering with the network. If the power-on password is not entered correctly, the mobile terminal cannot be used normally. In this way, even if the thief gets the user's mobile terminal, it cannot be used and sold because the correct password cannot be entered. Therefore, this method solves the problem that the mobile terminal is easily stolen to some extent. However, for this method, the legitimate user needs to input the password every time the computer is turned on, which will bring great trouble to the legitimate user. Therefore, at present, more than 4 users feel that it is too troublesome to input the power-on password every time and does not set such a power-on password, making this solution difficult for the user to accept and get the actual application, so that the mobile terminal cannot be fundamentally solved. The problem of being stolen.

Another solution is to build a large number of device identification registers (EDO devices, and put the international mobile device identity (MEI) of the stolen mobile terminal into the corresponding EIR blacklist. Thus, the mobile terminal logs in every time. In the network, the IMEI is reported to the network, and the related network device needs to go to the EIR device to check whether the MEI corresponding to the mobile terminal is added to the blacklist. If the MEI of the mobile terminal is found in the blacklist, the network considers The mobile terminal is a stolen terminal, and the user of the mobile terminal is an illegal user, thereby rejecting the network service. The thief can also profit from the obtained mobile terminal because it cannot be used again, thereby fundamentally solving the mobile terminal. It is easy to be stolen. However, this method requires the construction of a large number of EIR equipment, which requires an increase in the construction of network equipment, which increases the cost of the network operator and also causes inconvenience to the network operator. In addition, by changing the mobile terminal The program causes the mobile terminal to report a fake IMEI when reporting the MEI to the network. Thereby, the network is deceived, so that the network cannot judge whether the mobile terminal is a stolen terminal.

In some current mobile communication networks, such as the Universal Mobile Telecommunications System (UMTS) of the third generation mobile communication network, the user card can authenticate the mobile communication network, and after the authentication succeeds, the user card It can be used normally, and after the authentication fails, the user card cannot be used normally in the mobile communication network. However, this method can only solve the problem of user card security in the mobile terminal, and cannot solve the problem of theft of the mobile terminal itself. For example, after a thief steals a mobile terminal of a legitimate user, the user card of the legitimate user can be replaced with a user card, so that the existing authentication method can successfully authenticate the user card, so that the thief can still use the thief. The stolen mobile terminal cannot prohibit the stolen mobile terminal from continuing to use, so that the anti-theft function of the mobile terminal cannot be achieved. The second generation mobile communication network does not support the terminal authentication of the network separated by the machine card. Therefore, the anti-theft problem cannot be solved.

In order to solve the problem of anti-theft of the mobile terminal, the applicant has proposed to store a security key corresponding to the mobile terminal in the communication network and the mobile terminal, and use the security key to perform authentication on the network by the mobile terminal, thereby Completely solve the problem of anti-theft of mobile terminals. However, at present, there is no technology for setting a security key in the prior art, and therefore the applicant continues to propose a method of setting a security key. Summary of the invention

In view of the above, an object of the present invention is to provide a security key setting method in a mobile communication network to set a consistent security key in two devices of a mobile communication network, thereby implementing authentication using a security key. The technology of the right, and thus the security of the mobile terminal.

The above object of the present invention is achieved by the following technical solutions:

A security key setting method in a mobile communication network includes at least:

a. Generate a random number; ' b. The network device and the mobile terminal set the security key according to the random number in a mutually matching manner.

The generating the random number in step a is generating a random number by the network device. Step b at this point includes:

The network device generates a security key according to the random number generated by itself;

The network device sends the random number to the mobile terminal;

The mobile terminal generates a security key based on the random number received from the network device.

The random number generated in step a is generated by the mobile terminal, and step b includes:

The mobile terminal generates a security key according to the random number generated by the mobile terminal;

The mobile terminal sends the random number to the network device;

The network device generates a security key based on the random number received from the mobile terminal.

The invention also provides a security key setting method in a mobile communication network, which at least comprises:

a mobile terminal sends a set security key command to the network device;

b. The network device and the mobile terminal generate a security key in a mutually matching manner.

Where step b includes:

After receiving the setting security key command, the network device generates a security key, and then sends a security key setting success command to the mobile terminal;

After receiving the security key setting success command, the mobile terminal generates a security key in a manner that matches the security key generation mode of the network device.

The method may further include pre-setting a plurality of security key generation modes in the network device and the mobile terminal, and respectively establishing a setting mode flag, where the network device and the mobile terminal set the security key according to the matching manner according to the setting mode flag. The corresponding setting method generates a security key. The method may further include: the mobile terminal selects one of the plurality of setting modes, and sends the setting mode flag corresponding to the selected setting mode to the network device by using the setting security key command.

The method may further include: the network device selecting a setting mode from the plurality of setting modes, and transmitting, by the security key setting success command, the setting mode flag corresponding to the selected setting mode to the mobile terminal.

After the network device or the mobile terminal generates the security key, it may further comprise the step of checking whether the security key is a weak key, and regenerating the security key if it is determined that the security key is a weak key.

The security key is generated by generating a security key based on one or a combination of any of CK, IK, and KI. And it can be further based on the feature information of the mobile terminal user card and/or the mobile terminal feature information.

The step of synchronizing the respective terminal authentication sequence numbers stored by the network device and the mobile terminal may be further included after the step b.

The network device may be an HLR/AUC, and the method further includes the step of the HLR/AUC generating an authentication key according to the set security key and transmitting the authentication set to the MSC/VLR, the MSC/VLR receiving the The authentication set is saved after the authentication set.

It can be seen from the technical solution of the present invention that one of the network device and the mobile terminal in the mobile communication network first generates a random number, and then sends the random number to the other party, and the two parties generate corresponding correspondence according to the same random number. Security key. In this way, both the network device and the mobile terminal generate security keys that are consistent with each other, so that each of the security keys can be used for related calculation and judgment when performing authentication, thereby improving the effectiveness of the mobile terminal anti-theft, and thus improving The security of the mobile terminal.

In addition, since the network device and the mobile terminal each generate a security key in the security key setting method of the present invention, there is no transmission process of the security key itself between the two devices, such that Even if an illegal user acquires the intermediate transmission information, the determined security key cannot be obtained based on the acquired information. Therefore, the security key setting method of the present invention ensures the security of the set security key itself. BRIEF DESCRIPTION OF THE DRAWINGS

1 is a flow chart of a first embodiment of setting a security key in accordance with the present invention. 2 is a flow chart of a second embodiment of setting a security key in accordance with the present invention. 3 is a flow chart of a third embodiment of setting a security key in accordance with the present invention. 4 is a flow chart of a fourth embodiment of setting a security key in accordance with the present invention. Figure 5 is a flow diagram of a fifth embodiment of setting a security key in accordance with the present invention. Figure 6 is a message flow diagram of the mobile terminal canceling the terminal security function.

Figure 7 is a message flow diagram of the network device canceling the terminal security function.

Figure 8 is a message flow diagram of a mobile terminal and network device update authentication vector.

9 is a flow chart of a first embodiment of an authentication process in accordance with the present invention.

Figure 10 is a flow diagram of a second embodiment of an authentication process in accordance with the present invention.

Figure 11 is a flow diagram of a third embodiment of an authentication process in accordance with the present invention.

Figure 12 is a flow diagram of a fourth embodiment of an authentication process in accordance with the present invention.

Figure 13 is a flow chart of a fifth embodiment of an authentication process in accordance with the present invention.

Figure 14 is a flow chart of a sixth embodiment of the authentication process of the present invention. Mode for carrying out the invention

The invention will be described in detail below with reference to the drawings and specific embodiments.

Fig. 1 shows a flow chart of a first embodiment of a security key setting method according to the present invention. As shown in FIG. 1, in step 101, the mobile terminal transmits a Set Security Key (SKEY) command to the HLR/AUC on the network side. Here the SKEY command can be set through the mobile communication network. The MSC/VLR forwarding in the network, that is, the mobile terminal sends a SKEY command to the MSC/VLR, and then the MSC/VLR sends the command from the mobile terminal to the HLR7AUC. As is well known to those skilled in the art, the HLR and the AUC are usually integrated in one device, which functions as both a home location register and a certificate center, so the device is referred to herein as HLR/AUC _0.

At step 102, the HLR 7AUC generates a random number ( RAND ) upon receipt of the command. For example, HLR/AUC uses its own random number generator to generate a RAND.

In step 103, the HLR/AUC generates a SKEY using one of CK:, IK, and KI, or any combination thereof, and its own generated RAND. For each mobile terminal, the HLR/AUC can pre-store information such as CK, IK, and KI.

In step 104, after generating the SKEY, the HLR/AUC sends a SKEY setting success command to the mobile terminal, where the command includes the generated RAND. Of course, the SKEY setup success command here can also be forwarded through the MSC/VLR.

In step 105, after receiving the SKEY setting success command including the RAND, the mobile terminal generates the SKEY by using a generation method corresponding to the network device, that is, using one of CK:, IK, and KI, or any combination thereof, and receiving from the network. The RAND of the device generates S EY.

The mobile terminal can pre-store information such as CK, IK, and KI, and the mobile terminal can save the information by the mobile terminal and the current user card. Generally, after the mobile terminal successfully logs in to the network and authenticates through the user card, information such as CK and IK can be obtained from the user card, and the KI is generally stored in the user card. Therefore, the process of generating the SKEY by the mobile terminal may be performed by the mobile terminal program and the user card. The latter mentioned mobile terminal can save information such as CK, IK, and KI, and the operation of generating SKEY.

In this embodiment, the HLR/AUC in step 103 can be one of CK, IK, and KI. Or any combination of them and RAND performs algorithm calculation to generate SKEY. In this case, in step 105, the mobile terminal also performs corresponding algorithm calculation on one of CK, IK and KI or any combination thereof and RAND to generate SKEY.

It can be understood that step 101 is not necessary, and the HLR/AUC can actively generate the RAND and initiate the subsequent process. In addition, in step 104, the HLR/AUC can also directly send the AND to the mobile terminal. It can be understood that the network device sends a single RAOT to the terminal, indicating that the network device sets the SKEY successfully, and accordingly, when the setting is unsuccessful, the setting can be back. The failed command does not carry any information.

In addition, various SKEY settings can be pre-stored in the mobile terminal and the network device, and a SKEY setting mode flag is set for each setting mode, for example, the flag of the first SKEY setting mode is set to 1, and the first The settings for the two SKEY settings are set to 2, and so on. In step 101, the mobile terminal may select one of a plurality of setting modes in advance, and send a setting mode flag corresponding to the selected setting mode to the HLR/AUC by setting the SK Y command, and the HLR/AUC uses the setting mode. The SI EY setting method corresponding to the flag is used to generate SKEY. Similarly, after receiving the HLR/AUC RAND, the mobile terminal also uses the same setting method selected by itself to generate SKEY, thus ensuring the consistency of the SKEY generated on both sides.

Of course, one of the plurality of setting modes may be selected by the HLR/AUC, and the SKEY is generated according to the setting mode, and then the setting party flag corresponding to the selected setting mode is sent to the mobile terminal through the SKEY setting success command, and the mobile terminal is SKEY is generated using the SKEY setting method corresponding to the _£ mode flag. This also ensures the consistency of the SKEYs on both sides.

In addition, after generating the SKEY, the HLR/AUC can further check whether the SKEY is a weak key. If yes, then AND is regenerated, and SKEY is regenerated according to the RA > until the SKEY is checked to be not a weak key. If SKEY is checked If it is not a weak key, subsequent processing is performed, that is, the RAND is sent to the mobile terminal through the SKEY setting success command. In cryptography, there are some keys for the same algorithm, which are easier to break than the general key in the key space. Such a key is called a weak key, for example, a binary 128-bit key. A string of "0" keys, a string of "1" keys is generally considered to be a weak key that is easily compromised. To determine whether a key is a weak key, various methods of the prior art can be used, and will not be described in detail herein.

In the first embodiment, RAND is generated by the HLR/AUC, and the RAKD is transmitted to the mobile terminal. In practice, RAND can also be generated by the mobile terminal and RAND is sent to the HLR/AUC. To this end, the second embodiment of the present invention is proposed, and the flow thereof is as shown in FIG.

In the step 201, the mobile terminal first generates a RAND. For example, a mobile terminal generates its own RAND using its own random number generator.

In step 202, the mobile terminal sends a Set SKEY command to the HLR/AUC, and includes the RAND in the command. Here, the SKEY command can be forwarded through the MSC/VLR in the mobile communication network, that is, the mobile terminal sends a SKEY command to the MSC/VLR, and then the MSC/VLR sends the command from the mobile terminal to the HLR/AUC.

In step 203, after receiving the command, the HLR/AUC generates SKEY using one of CK, IK, and KI, or any combination thereof, and RAND received from setting the SKEY command.

In step 204, after generating the SKEY, the HLR/AUC sends a SKEY setting success command to the mobile terminal indicating that the HLR/AUC has successfully set the SKEY. Of course, the SKEY setting success command here can also be forwarded through the MSC/VLR.

In step 205, after receiving the SKEY setting success command, the mobile terminal generates SKEY by using a generation method corresponding to the network device, that is, generating SKEY by using one of CK, IK, and KI or any combination thereof and the RAND generated by itself.

Wherein, in step 203, the HLR/AUC can be one of CK, IK, and KI or it Any combination of them and RAND perform algorithm calculation to generate SKEY. In this case, the mobile terminal in step 205 also performs corresponding algorithm calculation on one of CK, IK and KI or any combination thereof and RAND to generate SKEY.

It can be understood that in step 202, the mobile terminal can directly send RAND to the HLR/AUC without including the RAND in the set SKEY command.

Here, the mobile terminal can also self-produce SKEY after sending the SKEY command, without waiting for the response of the HLR/AUC, that is, the HLR/AUC does not need to send the SKEY setting success command to the mobile terminal, but is moved by the mobile terminal. The terminal and HLR/AUC are automatically set to SKEY. In addition, it can be understood that the mobile terminal can first send the KEY according to the RAND, and then send the RAND to the HLR/AUC, and the HLR/AUC generates the SKEY after receiving the RAMD.

Similar to the first embodiment, various SKEY setting modes can be pre-protected in the mobile terminal and the network device, and a SKEY setting mode is established for each setting mode. In step 202, the mobile terminal may select one of a plurality of setting modes in advance, and send a setting mode flag corresponding to the selected setting mode to the HLR/AUC by setting a SKEY command, and the HLR/AUC uses the setting mode flag. The corresponding SKEY setting method generates SKEY. Similarly, after receiving the SKEY A function command from the HLR/AUC, the mobile terminal also uses the same setting method selected by itself to generate the SKEY, thereby ensuring the consistency of the SKEY generated on both sides.

In addition, after the SLR is generated, the HLR/AUC can further check whether the SKEY_ is a weak key. If yes, the mobile terminal is notified, for example, a key setting failure command is sent to the mobile terminal, and the reason for the failure is a weak key. After the mobile terminal receives the key to the key setting failure command, the RAND is regenerated and resent. RAND, HLR/AUC then regenerate SKEY according to the new RAND until the SKEY is checked to be not a weak key. If the SKEY is not a weak key, it sends a key setting to the mobile terminal. Command.

It can be understood that if the mobile terminal generates the SKEY by itself, the mobile terminal can also determine for itself whether the SKEY is a weak key. If yes, regenerate RAND and regenerate a new SKEY based on RAND until the SKEY is checked for a weak key. The new RAND is then sent to the HLR/AUC, which generates the SKEY based on the RAND.

Of course, it can be understood that both the mobile terminal and the HLR/AUC perform weak key check, and any one of them needs to regenerate RAND when it detects that the generated key is a weak key.

In addition, the mobile terminal may also generate the SKEY first, and then send the RAND to the network device. After receiving the RAND, the network device generates the SKEY by itself, and no longer needs to return the SKEY setting success command to the mobile terminal.

Fig. 3 shows a third embodiment of the present invention in which it is not necessary to generate RAND, but the SKEY is generated directly based on the respective related information currently known. The specific process is shown in Figure 3.

In step 301, a set SKEY command is first sent by the mobile terminal to the HLR 7AUC. Here, the SKEY command can be forwarded through the MSC/VLR in the mobile communication network, that is, the mobile terminal sends a SKEY command to the MSC/VLR, and then the MSC/VLR sends the command from the mobile terminal to the HLR/AUC _0.

In step 302, after receiving the command, the HLR/AUC generates SKEY using one of CK, IK, and KI, or any combination thereof.

In step 303, after generating the SKEY, the HLR/AUC sends a SKEY setting success command to the mobile terminal indicating that the HLR/AUC has successfully set the SKEY. Of course, the 'SKEY setting success command here' can also be forwarded through the MSC/VLR.

In step 304, after receiving the SKEY setting success command, the mobile terminal generates SKEY by using a generation method corresponding to the network device, that is, generating SKEY by using one of CK, IK, and KI or any combination thereof. The HLR/AUC in step 302 can directly use one of CK:, D or KI as the SKEY. In this step, the mobile terminal directly uses one of CK, IK or KI as the SKEY. Alternatively, in step 302, the HLR/AUC may perform an algorithmic calculation on one of CK, IK, and KI, or any combination thereof, to generate an SKEY, in which case the mobile terminal in step 304 also has one of CK, IK, and KI or Any combination of them performs a corresponding algorithm calculation to generate SKEY.

Here, the mobile terminal may also generate the SKEY by itself after sending the SKEY command, without waiting for the response of the HLR/AUC, that is, the HLR/AUC does not need to send the SKEY setting success command to the mobile terminal, but by the mobile terminal. Set SKEY separately from HLR/AUC. In addition, it can be understood that the mobile terminal can be SKEY, and then the SKEY command is sent to the HLR/AUC, and the HLR/AUC generates the SKEY after receiving the command.

Here, various SKEY setting modes can be pre-stored in the mobile terminal and the network device, and a SKEY setting mode flag is established for each setting mode. In step 301, the mobile terminal may select one of a plurality of setting modes in advance, and send a setting mode flag corresponding to the selected setting mode to the HLR/AUC by setting a SKEY command, and the HLR/AUC uses the setting mode flag. The corresponding SKEY setting method is used to generate SKEY. Similarly, after receiving the SKEY success command from HLR/AUC, the mobile terminal also uses the same setting method selected by itself to generate SKEY, thus ensuring the consistency of SKEY generated on both sides.

In addition, after generating the SKEY, the HLR/AUC can further check whether the SKEY is a weak key. If yes, the mobile terminal is notified that both parties regenerate the SKEY until the SKEY is checked to be not a weak key. If the SKEY is checked not to be a weak key, subsequent processing is performed. In addition, it can be understood that the mobile terminal can also determine for itself whether the SKEY is a weak key. If yes, both parties regenerate SKEY until the SKEY is checked. Check is not a weak key.

Fig. 4 shows a fourth embodiment of the invention. At step 401, the mobile terminal sends a Set SKEY command to the HLR/AUC. Here, the SKEY command can be forwarded through the MSC/VLR in the mobile communication network, that is, the mobile terminal sends a SKEY command to the MSC/VLR, and then the MSC/VLR sends the command from the mobile terminal to the HLR/AUC _0.

At step 402, after receiving the command, the HLR/AUC uses the CK, IK, and KI, or any combination thereof, to generate the SKEY.

In step 403, after generating the SKEY, the HLR/AUC encrypts the SKEY by CK to form a ciphertext of the SKEY.

At step 404, the HLR/AUC sends the SKEY ciphertext to the mobile terminal.

In step 405, after receiving the SKEY ciphertext, the mobile terminal decrypts the SKEY ciphertext by using its own CK to obtain the plaintext of the SKEY.

It is of course understood that the HLR/AUC in step 402 can also generate the SKEY by other methods, which is not limited by the present invention. Regardless of the method used to generate the SKEY, as long as the SKEY is encrypted to obtain the ciphertext and the ciphertext is transmitted to the mobile terminal, the mobile terminal decrypts the ciphertext to obtain the SKEY plaintext, which belongs to the embodiment of the fourth embodiment of the present invention. .

Fig. 5 shows a fifth embodiment of the present invention. At step 501, the mobile terminal generates a SKEY using one of CK, I, and KI, or any combination thereof.

In step 502, the mobile terminal encrypts the SKEY with its own CK to form a ciphertext of the SKEY.

In step 503, the mobile terminal sends the SKEY ciphertext to the HLR/AUC.

In step 504, the HLR/AUC uses its own CK pair after receiving the SKEY ciphertext.

The SKEY ciphertext is decrypted to obtain the plaintext of SKEY.

Of course, it can be understood that the mobile terminal in step 501 can also be generated by other methods.

SKEY, the present invention does not limit this. No matter what method is used to generate SKEY, as long as The SKEY is encrypted to obtain the ciphertext and the ciphertext is transmitted to the network device, and the network device decrypts the ciphertext to obtain the SKEY plaintext, which is an embodiment of the spirit of the embodiment.

For the fourth and fifth embodiments, a plurality of SKEY i history modes can be pre-stored in the mobile terminal and the network device, and a SKEY setting mode flag is established for each setting mode. The mobile terminal may select one of a plurality of setting modes in advance, and send a setting mode flag corresponding to the selected setting mode to the HLR/AUC by setting a SKEY command, and the HLR/AUC uses the SKEY setting mode corresponding to the setting mode flag. To generate SKEY. The setting method can also be selected and transmitted to the mobile terminal by the HLR/AUC.

In addition, for the mobile terminal or HLR/AUC that first generates the SKEY, it can be further checked whether the SKEY is a weak key. If so, regenerate the SKEY until the SKEY is checked for a weak key. For example, when it is checked that the generated SKEY is a weak key, a setting method can be replaced to regenerate the SKEY.

The above various methods may further include setting a SKEY startup flag SFLAG. For example, when SFLAG is 1, it indicates that the terminal security function is activated. When SFLAG is 0, the terminal security function is turned off. HLR/AUC and the mobile terminal can set SFLAG to 1 after setting the key SKEY. Of course, you can also disable the terminal security function by setting SKEY to 0. When SKEY is not 0, it indicates that the terminal security function is enabled. In practice, an open/close command can be set to set the value of SFLAG, or SKEY can be set to 0 by setting the clear SKEY setting to achieve the purpose of turning off the terminal security function.

Among the above various methods, the corresponding setting manners can be various. The setting information can be used to determine the parameter information used when generating SKEY. For example: only CK and only ΓΚ, only RAND and CK, only CK and IMSI, only KI and SKEY, and KI and RAND and IMSI, etc. Wait. The setting information can also be used to determine the algorithm information used when generating the SKEY, that is, the different calculations used to generate the SKEY are determined by different setting methods. Law. For example, the ciphertext is obtained by CK encryption IMSI as SKEY, or the IMS is digested by IK to obtain a digest as SKEY, and so on.

In the above various methods, in the case that the network device and the mobile terminal calculate and generate the SKEY, the mobile terminal user card feature information, such as the MSI information, the user card electronic serial number ESN, or the mobile terminal feature may be further considered in the calculation. Information, such as IMEI information, mobile terminal electronic serial number ESN, or both user card feature information and mobile terminal feature information.

In the above various methods, when the mobile terminal calculates the SKEY, it can be completely calculated by the mobile terminal program. At this time, the mobile terminal program should have the corresponding algorithm computing capability; or the calculation can be performed entirely in the user card, that is, the mobile terminal will The information such as RAND is transmitted to the user card, and the user card calculates according to the information of CK, IK, KI, etc., and transmits the obtained SKEY to the mobile terminal program; of course, the user card and the mobile terminal program can also perform correspondingly Calculate to get SKEY. It can be understood that the steps of generating the SKEY by the network device are respectively implemented by the user card and the mobile terminal program, thereby obtaining the SKEY corresponding to the SKEY generated by the network device.

For all of the above embodiments, the step of synchronizing the terminal authentication sequence number msSQN may be further added after the mobile terminal and the network device have set the SKEY. For example, the msSQN may be determined by the network device, and the msSQN is transmitted to the mobile terminal, and then the mobile terminal saves the msS.QN received from the network device, thereby implementing synchronization of the msSQN. Alternatively, after the SKEY is set, the network device and the mobile terminal respectively update their own msSQN, for example, the current value is set to a protocol agreed value, such as 1, and so on, thereby implementing synchronization of the msSQN. Alternatively, the mobile terminal determines the msSQN. value in advance, and adds the msSQN information to the SKEY setting command sent to the network device, and the network sets the msSQN received from the mobile terminal to implement synchronization of the msSQN.

For all embodiments, the HLR/AUC can generate a security key based on the newly set security key. The authentication set used for the right, and the authentication set is sent to the MSC/VLR. The MSC/VLR saves the authentication set after receiving the authentication set, so that the authentication set can be used to implement subsequent authentication. Since the subsequent authentication processing is not the scope of the present invention, a detailed description thereof is omitted here.

After updating the SKEY setting, the HLR/AUC may also delete the end user related information from the MSC/VLR in which the terminal roams. In this way, when the mobile terminal authenticates, the MSC/VLR actively requests the HLR/AUC to send the authentication set. At this time, the HLR/AUC can send the authentication authentication set generated by using the newly set security key to the MSC/VLR. Thus, the purpose of updating the authentication set of the mobile terminal in the MSC/VLR is achieved indirectly.

For the generation of SKEY, you can learn from the KI information stored in the SIM card or USM card. When the user first starts the terminal security function, the security terminal generates a RAND, submits it to the SIM or USM card, and the SM or USM card uses KI and RAKD. The algorithm saved by itself calculates SRES, which can be used as SKEY. HLR/AUC uses KI and RAND to calculate SRES using its own saved algorithm. This SRES can be used as the SKEY corresponding to the terminal stored on the network side.

The mobile terminal can provide an interface to the client to activate, cancel the terminal security function or update the SKEY. After the user enters the corresponding startup password, the mobile terminal can initiate a message to the network, cancel the security function, or update the SKEY. The update SKEY is actually included in the startup terminal security process, and nothing special.

The message flow of the mobile terminal to start and cancel the terminal security function is shown in Figure 6. The message can be carried over the USSD, so there will be no new requirements for the MSC supporting the USSD function.

The UE indicates whether to activate or deactivate the security function in the UE_Security_Request message (the function of updating the SKEY may be included in the startup function), and if the security function is started, the number of tracers generating the SKEY (RA D1 ) needs to be carried in the message.

The MSC does not process any messages related to this and transparently transmits it to the HLR. After receiving the message, the HLR initiates a UE-Security-Auth-Req message carrying the random number RA D2.

When receiving the UE-Security_Auth-Req message, the UE calculates SRES2 according to the KI in RAND2 and SM USIM, and sends SRES2 to the HLR in the UE-Security_Autli_Rsp message.

When the HLR receives the UE_Security_Auth-Rsp message, it verifies that the SRES2 is legal. If it is legal, the HLR performs corresponding processing according to the indication in the UE_Security_Request message. If the UE is in the Security-Request message, it is a request to start the security function. Use the RAND1 in the message to generate the SKEY, and save it in the user data, and then send back the UE_Security_ Response message indicating "Start security function succeeded"; If the UE-Security-Request message is "Cancel security function", delete the corresponding user SKEY of the data, loopback UE—Security—The Response message indicates “cancel the security function successfully”. If the HLR verifies that the SRES2 is invalid, it indicates in the UE-Security_Response message that the corresponding function requested by the UE fails.

In addition, in order to prevent the user from forgetting the password and unable to cancel the security function after starting the security function, the message should be canceled from the network side, or the above message can be used, but the sending direction is reversed. After the operator's customer service hotline confirms the legality of the user's identity through the carrier's customer service hotline, the user can initiate the operation of canceling the security function of the user terminal at the console.

The process of initiating the "cancel terminal security function" from the network side is shown in Figure 7.

After the security terminal starts the security function, cancels the security function or updates the SKey, it needs the authentication vector in the new MSC/SGS. The process of updating the authentication vector can be completed by the HLR and the security terminal. Updating the authentication vector can borrow the Cancel Location and Attach procedures already defined in 3GPP, as shown in Figure 8.

The HLR finds that after successfully starting, canceling the terminal security function or updating the SKey, the HLR Send a Cancel Location message to the MSC/SGSN, and set the Cancellation Type in the message to "Subscription Withdraw". At this time, the MSC/SGSN will immediately delete the context information of the relevant user.

After receiving the Detach Request message sent by the MSC/VLR, the security terminal sends a Detach Accept message. If the security terminal finds that the security function state has changed at this time (for example, from a security state to a non-secure state, or from a non-secure state to a security state, or an SKey update is performed), an attach procedure is automatically initiated; Otherwise, it will be processed as specified in the agreement.

After receiving the attach request of the secure terminal again, the MSC/SGS will go to the HLR to obtain the subscription and authentication data, thereby completing the update of the authentication data.

If the SIM/USIM card that has activated the terminal security function is switched to a non-secure terminal, since the status of the user saved in the HLR is "enabled security function", the non-secure terminal will continue to use the user card to check the network. Right, at this time, the authentication between the user card and the network will not pass. At this time, the MSC will transmit the authentication failure report to the HLR. The HLR will close the security function set for the original security terminal and restart the user card. The authentication process, and update the authentication set in the MSC/VLR, at this time, the non-secure terminal can pass the normal authentication.

If you change the SM/USIM card that has started the terminal security function to another security terminal, the first authentication fails. Therefore, the HLR will close the security function set for the original security terminal and restart the user card. The process of rights, and update the authentication set in the MSC/VLR, so that as long as the user cancels the security function settings in the new mobile terminal, the user can log in to the network normally, and then the user can restart the security function, at this time for the HLR , is equivalent to refreshing SKEY.

The above authentication set may also be referred to as an authentication tuple, and may also be referred to as an authentication vector. It should be noted that the SRES and XRES generated by the mobile terminal indicate that the mobile The response value generated by the terminal in response to the network authentication of the mobile terminal or the user card may be different in 3G and 2G, but the actual meaning of the response value is used for the network to the terminal or the user. The purpose of card authentication is unchanged. Therefore, in some cases, SRES can be written as XRES, or XRES can be written as SRES.

The above MSC/VLR is circuit i or device. For the packet domain network, ^"the MSC/VLR device should be the SGSN.

After the SKEY is set, the mobile terminal can secure its own security by performing authentication on the network, thereby indirectly achieving the anti-theft purpose. Specifically, the following embodiments are included.

In the first embodiment shown in FIG. 9, in step 901, the mobile terminal first saves an SKEY, where the SKEY is the same as the SKE^ stored on the network device side corresponding to itself.

In step 902, after receiving the authentication information from the network device side, the mobile terminal determines whether the authentication of the network is passed according to the authentication information and the SKEY saved by itself. If yes, the mobile terminal can access the network normally in step 903. If it does not pass, it determines its own method and stops its normal use in step 904.

Stopping your normal use here may not allow you to access the network, or directly power off or shut down, etc., and you can also send a short message to inform relatives or friends or security agencies.

Fig. 10 shows a second embodiment of the authentication process. In step 1001, the mobile terminal first saves a SKEY, where the SKEY is consistent with the SKEY of the network device side corresponding to its own SKEY. Generally, the terminal and the network side respectively store a pair of symmetric keys, which are usually the same for symmetric keys.

In step 1002, after receiving the RAND and ^UTN from the MSC/VLR, the mobile terminal calculates a MAC value according to its SKEY and the received RAND, SQ, and compares the calculated MAC value with the MAC value in the AUTN. Is it consistent, if Inconsistent, it is determined in step 1003 that the authentication of the network fails; otherwise, it is determined in step 1004 whether the AUTN is acceptable. If yes, it is determined in step 1005 that the authentication of the network is successful, otherwise in step 1006, the SQN synchronization command is initiated to the network. .

In step 1004, it is determined whether the AUTN is acceptable or not by determining the SQN therein. The mobile terminal and the network side pre-store a synchronized SQN. In this way, when receiving the authentication information of the network side, the terminal determines whether the AUTN can be determined by comparing whether the SQN in the saved SQN and the AUTN meets the predetermined condition. Accepted, the predetermined condition may be that the difference between the SQN in the AUTN and the SQN saved by the mobile terminal itself is within a predetermined range. If the mobile terminal judges that the difference between the SQN in the AUTN and the self-saved SQN is within the predetermined range, it is determined that the AUTN is acceptable, otherwise it is determined that the AUTN is unacceptable.

After the mobile terminal determines that the authentication of the network is passed, it updates the saved SQN by using the SQN in the received AUTN.

In the case where the AUTN includes the AMF, the AMF is further considered in step 1002, for example, using its own SKEY, received RAND, SQN, and AMF to generate a MAC value, where SQN and AMF are carried in the AUTN.

Here, before step 1002, a step of determining whether to perform authentication on the network according to SKEY may be further included. If yes, step 1002 is performed; otherwise, the step of authenticating the network according to SKEY is not performed, that is, according to the existing process. The RAND and the AUTN are sent to the user card, and the user card authenticates the network.

Similarly, the SQN here can use the same SQN as the prior art, that is, the SQN for user card authentication, that is, the SQN corresponding to the network and the user card. For details, refer to the relevant agreement of 3GEP 33.102/29.002. Preferably, however, the present invention additionally provides a separate SQN dedicated to mobile terminal authentication, and the mobile terminal and the HLR/AUC also perform synchronization processing on the SQN. Of course, you can understand that the SQN and user cards are saved separately. The SQN can take the same value.

Fig. 11 shows a third embodiment of the authentication process. In step 1101, first, a SKEY corresponding to the authentication of the mobile terminal is saved in the device and the mobile terminal. Of course, the SKEY saved by the network side device may be the SKEY corresponding to the mobile terminal feature information, or may be corresponding. The SKEY is saved by the IMSI of the user card. The network side device can also save the SKEY according to the user's mobile terminal number MSISDN.

In step 1102, the network device first generates an RAND when generating authentication information for a mobile terminal.

In step 1103, the network device generates authentication information using the SKEY and the generated RAND corresponding to the mobile terminal.

At step 1104, the network device transmits the authentication information to the corresponding mobile terminal.

In step 1105, after receiving the authentication information from the network device side, the mobile terminal determines whether the authentication of the network is passed according to the authentication information and the SKEY saved by itself, and the result is passed. In step 1106, the network can be normally accessed. If not, the normal access to the network is not allowed in step 1107.

After the mobile terminal determines that the authentication of the network is passed, the SQN saved by itself is updated using the received AUTN.

Fig. 12 shows a fourth embodiment of the authentication process. In step 1201, the SKEY corresponding to the authentication of the mobile terminal is first saved in the HLR/ATJC and the mobile terminal.

At step 1202, the HLR 7AUC generates a RAMD using its own random number generator. In step 1203, the HLR/AUC calculates XRES, CK, and IK using its own stored authentication key (KI) and its own generated RAND.

In step 1204, the HLR/AUC generates a MAC using the SKEY "and RAND and SQN of the corresponding mobile terminal stored in advance. The SQN here is currently known, for example, pre-set. At step 1205, the HLR/AUC combines the MAC and the known SQN into an AUTN. In the case where the AUTN includes the AMF, the AMF is further considered in step 1204, such as generating a MAC using SKEY, RAND, SQN, and AMF, where the AMF is also preset. AMF is further considered in step 1205, that is, the MAC, SQN, and AMF are collectively combined into an AUTN.

At step 1206, the HLR/AUC groups RAND, AUTN, XRES CK, and IK into an authentication set.

At step 1207, the HLR/AUC sends the authentication set to the MSC/VLR.

In step 1208, during authentication, the MSC/VLR extracts RAND and AUTN in the corresponding authentication set of the mobile terminal, and sends the authentication information to the mobile terminal as the authentication information of the present invention.

This step may be started by the mobile terminal sending a trigger message to the network side. In actuality, when the mobile terminal initiates a location update request, or a service request, the MSC/VLR initiates an answer request to the terminal, for example, when the mobile terminal starts to log in to the network, the MSC/VLR initiates an authentication request to the terminal.

This step may be initiated by the network side. For example, when the mobile terminal does not initiate a related request for a long time, the network side initiates an authentication process.

In step 1209, after receiving the RAND and AUTN from the MSC/VLR, the mobile terminal calculates a MAC value according to its own S EY and the received RAND and SQN, and compares the calculated MAC value with the MAC value in the AUTN. If they are inconsistent, if they are inconsistent, it is determined in step 1210 that the authentication of the network fails; otherwise, in step 1211, it is determined whether the AUTN is acceptable. If yes, it is determined in step 1212 that the authentication of the network is successful; otherwise, if not acceptable, Then in step 1213, the mobile terminal initiates an SQ synchronization command to the network.

In step 1211, determining whether the AUTN is acceptable may be implemented by determining whether the SQN in the AUTN and the SQN saved by itself satisfy a predetermined condition, and if so, determining AUTN is acceptable, otherwise it is determined that AUTN is unacceptable. For example, the predetermined condition may be that the difference between the SQN in the AUTN and the SQN saved by itself is within a predetermined range.

In step 1213, the mobile terminal sends a synchronization command of the synchronous SQN to the network side, and synchronizes the terminal and the SQN corresponding to the network through the synchronization process. For the description of the SQN synchronization process, refer to the description of the SQN synchronization in the prior art, and refer to the related protocol of the 3GPP 33.102/29.002, and details are not described herein again.

After the mobile terminal determines that the authentication of the network is passed, the SQN saved by the received AUTN is used to update the saved SQN.

In the case where the AUTN includes the AMF, the AMF is further considered in step 1209, for example, using its own SKEY, the received RAND, the SQN, and the AMF to generate a MAC value, where the SQN and the AMF are carried in the AUTN.

The foregoing describes the processing of authenticating the network by the mobile terminal of the present invention. The present invention may further include the process of authenticating the mobile terminal by the network, that is, after step 1212, continuing to perform subsequent authentication of the terminal by the network. step.

In the fifth embodiment, as shown in Fig. 13, steps 1301-1313 and steps 1201-1213 are identical, and the description will not be repeated.

At step 1314, the mobile terminal transmits RAND to the user card.

At step 1315, the user card generates XRES, CK, and IK using its own KI and the received RAND.

At step 1316, the user card transmits the generated XRES to the mobile terminal.

At step 1317, the mobile terminal transmits the XRES received from the subscriber card to the MSC/VLR. At step 1318, the MSC/VLR compares whether the XRES received from the mobile terminal and the corresponding authentication set XRES of the mobile terminal received from the HLR/AUC are consistent. If they are consistent, it is determined in step 1319 that the network authenticates the mobile terminal; otherwise, in step 1320, it is determined that the network failed to authenticate the mobile terminal. Here, in step 1314, in order to be compatible with the existing processing, the mobile terminal can transmit the AUTN while transmitting the RAND, so that the user card can further authenticate the network according to the AUTN and its own KI. In this case, the mobile terminal can set the AUTN sent to the user card to a special value indicating that the mobile terminal authenticates the network, and the user card only uses KI and RAND after determining that the AUTN is the special value. XRES, CK, and IK, and no longer authenticate the network based on AUTN and KI.

When the user card generates XRES, CK, and IK according to KI and RAND, it is also possible to generate only XRES and CK, and then send the generated XRES and CK to the mobile terminal, and the mobile terminal derives IK according to CK.

In the above step 1317, before the mobile terminal sends the XRES received from the user card to the MSC/VLR, it can determine whether the network is a second generation mobile communication network. If yes, the mobile terminal can derive the second according to XRES, CK, IK, etc. SRES2g (Signed Response Symbol Response) and KC2g (Cipher Key) are used to authenticate the network, and the generated SRES2g is used instead of XRES to transmit to the MSC/VLR, and KC2g and the network side are used for encryption and decryption of related communication. The relevant derivation method has suggestions in the relevant protocols in the existing 3GPP, and will not be described here.

Further, XRES, CK, IK can also be generated by SKEY and RAND, and in this case, the sixth embodiment as shown in Fig. 14 is proposed.

In step 1401, the SKEY corresponding to the mobile terminal authentication is first saved in the HLR/AUC and the mobile terminal.

In step 1402, HL /AUC uses its own random number generator to generate a RAND. In step 1403, the HLR/AUC calculates XRES, CK, and IK using the pre-stored SKEY of the corresponding mobile terminal and the RAND generated by itself.

At step 1404, the HLR/AUC generates a MAC using the SKEY and RAND and SQN of the corresponding mobile terminal stored in advance. The SQN here is currently known, such as pre-set Set it up.

At step 1405, HL /AUC combines the MAC and the known SQN into AUTO.

In the case where the AUTN includes the AMF, the AMF is further considered in step 1404, such as using SKEY, RA D SQN, and AMF to generate the MAC, where the AMF is also pre-set. AMF is further considered in step 1405, that is, the MAC, SQN, and AMF are combined into an AUTN.

At step 1406, the HLR/AUC groups RAND, AUTN, XRES, CK, and IK into an authentication set.

At step 1407, the HLR/AUC sends the authentication set to the MSC/VLR.

In step 1408, during authentication, the MSC/VLR extracts the RAND and the AUTN in the corresponding authentication set of the mobile terminal, and sends the authentication information to the mobile terminal as the authentication information of the present invention.

In step 1409, after receiving the RAND and AUTO from the MSC/VLR, the mobile terminal calculates a MAC value according to its SKEY and the received RAND and SQN, and compares the calculated MAC value and the MAC value in the AUTN. Consistently, if not, it is determined in step 1410 that the authentication of the network fails; otherwise, in step 1411, it is determined whether the AUTN is acceptable. If yes, it is determined in step 1412 that the authentication of the network is successful; otherwise, in step 1413, the mobile terminal proceeds to The network initiates an SQN synchronization command.

In step 1411, determining whether the AUTN is acceptable may be implemented by determining whether the SQN in the AUTN and the SQN saved by itself satisfy a predetermined condition. If the predetermined condition is met, determining that the AUTN is acceptable, otherwise determining that the AUT is unreachable' Accepted. For example, the predetermined condition may be that the difference between the SQN in the AUTN and the self-saved SQN is within a predetermined range. ·

When the mobile terminal determines that the SQN is unacceptable, the mobile terminal sends an SQN unacceptable command to the network side, for example, initiates a synchronous SQN synchronization command, and synchronizes the terminal with the corresponding SQN saved by the network through the synchronization process. After the mobile terminal determines that the authentication of the network is passed, the SQN saved by the received AUTN is used to update the saved SQN.

In the case where the AUTN includes the AMF, the AMF is further considered in step 1409, for example, using its own SKEY, received RAND, SQN, and AMF to generate a MAC value, where SQN and AMF are carried in the AUTO.

At step 1414, the mobile terminal generates XRES, CK, and IK using its own SKEY and the received RAND. Send the XRES generated by yourself to the MSC/VLR.

In step 1415, the MSC/VLR compares whether the XRES received from the mobile terminal and the corresponding authentication set XRES of the mobile terminal received from the HLR/AUC are consistent. If they are consistent, it is determined in step 1416 that the network authenticates the mobile terminal; otherwise, in step 1417, it is determined that the network failed to authenticate the mobile terminal.

In the above various methods, when the network device, such as the MSC/VLR, sends the authentication information to the terminal, it may send it once or multiple times. For example, the first transmission of a RANDRAND, the second transmission of the authentication token AUTN. In practice, it will be decided to send several times according to the protocol capabilities of the network. For example, in a UMTS network, the MSC/VLR may send authentication information such as RAND and AUTN to the mobile terminal through an authentication command at a time, and in the second generation mobile communication network, the MSC/VLR may need to pass two or more times. The authentication information such as RAND and AUTN is sent to the mobile terminal through the authentication command of the second generation network.

In the above, after the terminal authentication fails, the authentication failure report may be further notified to the MSC/VLR, and the MSC/VLR notifies the HLR/AUC of the authentication failure report.

After receiving the terminal authentication failure report reported by the MSC/VLR, the HLR/AUC sets the terminal to an insecure state, that is, turns off the security function of the terminal, that is, generates an authentication set according to a normal non-security setting manner. That is, reusing KI completely replaces SKEY to generate an authentication set, and updates the authentication set in the MSC/VLR.

In general, when a user card used in a secure terminal is inserted into a non-secure terminal When the non-secure terminal fails to pass the first authentication of the network by using the user card, the non-secure terminal notifies the HLR/AUC via the MSC/VLR, and the HLR/AUC closes the security of the corresponding terminal. After the function, the authentication set is regenerated, and the authentication set in the MSC/VLR is updated, so that the non-secure terminal can pass the network authentication at the next authentication.

The above authentication set may also be referred to as an authentication tuple or an authentication vector.

It should be noted that the SRES and XRES generated by the mobile terminal indicate the response value generated by the mobile terminal in response to the network authentication of the mobile terminal or the user card. In 3G and 2G, the algorithm for generating the response value may be different. However, its practical significance as a response value is that the purpose for the network to authenticate the terminal or user card is unchanged. Therefore, in some cases, you can write SRES as XRES or XRES as SRES.

The above MSC/VLR device is a circuit domain device, and for a packet domain network, the corresponding MSC/VLR device may be an SGSN.

It is to be understood that the above description is only a preferred embodiment of the present invention, and is not intended to limit the invention, and any modifications, equivalents, improvements, etc., which are within the spirit and scope of the present invention, should be included in Within the scope of protection of the present invention.

Claims

Claim

A security key setting method in a mobile communication network, comprising at least: a. generating a random number;

b. The network device and the mobile terminal set the security key according to the random number in a mutually matching manner.

2. The method according to claim 1, wherein the generating a random number in step a is generating a random number by the network device, and step b comprises:

The network device sends the random number to the mobile terminal;

The mobile terminal generates a security key according to a random number received from the network device.

3. The method according to claim 2, wherein the transmitting, by the network device, the random number to the mobile terminal comprises transmitting the random number in a security key setting success command.

4. The method according to claim 2, wherein after the network device generates the security key, further comprising the step of checking whether the security key is a weak key, and if yes, performing step a; The step of transmitting a random number to the mobile terminal.

The method according to claim 2, wherein before step a, the method further comprises: the mobile terminal sending a set security key command to the network device.

The method according to claim 1, wherein the generating a random number in step a is generating a random number by the mobile terminal, and step b comprises:

The mobile terminal sends the random number to the network device;

7. The method according to claim 1, wherein the generating a random in the step a. The number is generated by the mobile terminal, and step b includes:

The mobile terminal sends the random number to the network device;

The network device generates a security key according to the random number received from the mobile terminal, and sends a security key setting success command to the mobile terminal;

After receiving the security key setting success command returned by the network device, the mobile terminal generates a security key according to the number of P-transmissions generated by the mobile device.

8. The method according to claim 6, wherein after the mobile terminal generates the security key, further comprising the step of checking whether the security key is a weak key, 'if yes, performing step a again; otherwise executing the The step of transmitting a random number to a network device.

The method according to any one of claims 2, 6, or 7, wherein the generating a security key according to a random number is based on a combination of one or any of CK, IK, and KI and The random number is calculated to obtain a security key.

10. The method of claim 9, wherein the calculating further comprises performing based on mobile terminal user card feature information and/or mobile terminal feature information.

11. The method according to claim 1, wherein the method further comprises pre-setting a plurality of security key generation formulas in the network device and the mobile terminal, and separately establishing a setting mode flag, the network device and the mobile The setting of the security key by the terminal according to the random number in a mutually matching manner generates a security key according to the setting manner corresponding to the setting mode flag.

The method according to claim 11, wherein the method further comprises: the mobile terminal selecting one of the plurality of setting modes, and setting the setting mode corresponding to the selected setting mode by setting the security key The key command is sent to the network device.

The method according to claim 11, wherein the method further comprises: the network device selecting a setting mode from the plurality of setting modes, and marking the setting mode corresponding to the selected setting mode by the security key The set success command is sent to the mobile terminal.

14. The method of claim 1 further comprising step b The step of the network device and the mobile terminal synchronizing the respective saved terminal authentication serial numbers is included.

15. The method according to claim 1, wherein the network is configured to be a home location register/verification center HLR/AUC, the method further comprising the HLR/AUC generating an authentication set according to the set security key and The authentication set is sent to the mobile switching center/visit location register MSC/VLR, and the MSC/VLR saves the authentication set after receiving the authentication set.

16. The method according to claim 1, wherein the network device is an HLR/AUC, the method further comprising: HLR/AUC updating a step of the authentication set of the MSC/VLR, or from the The step of deleting the end user phase information in the MSC roaming by the terminal.