WO2006050663A1 - Procede de definition de code de securite - Google Patents

Procede de definition de code de securite Download PDF

Info

Publication number
WO2006050663A1
WO2006050663A1 PCT/CN2005/001872 CN2005001872W WO2006050663A1 WO 2006050663 A1 WO2006050663 A1 WO 2006050663A1 CN 2005001872 W CN2005001872 W CN 2005001872W WO 2006050663 A1 WO2006050663 A1 WO 2006050663A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile terminal
skey
security key
network device
random number
Prior art date
Application number
PCT/CN2005/001872
Other languages
English (en)
Chinese (zh)
Inventor
Kunyang Dong
Zhengwei Wang
Chunyan Zhou
Zhiming Zhu
Tianzhen Huang
Jie Kong
Shangbin Wang
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2006050663A1 publication Critical patent/WO2006050663A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement

Definitions

  • 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
  • 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.
  • SM subscriber identity module
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • CDMA code division multiple access.
  • 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.
  • 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.
  • 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.
  • 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.
  • EEO devices device identification registers
  • MEI international mobile device identity
  • the mobile terminal logs in every time.
  • 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.
  • 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.
  • 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.
  • 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.
  • the applicant continues to propose a method of setting a security key. Summary of the invention
  • 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.
  • 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.
  • 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.
  • 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
  • the network device and the mobile terminal generate a security key in a mutually matching manner.
  • step b includes:
  • the network device 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;
  • 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.
  • the network device or 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.
  • 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.
  • the security key setting method of the present invention ensures the security of the set security key itself.
  • FIG. 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.
  • FIG. 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
  • Fig. 1 shows a flow chart of a first embodiment of a security key setting method according to the present invention.
  • the mobile terminal transmits a Set Security Key (SKEY) command to the HLR/AUC on the network side.
  • 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.
  • 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.
  • the HLR 7AUC generates a random number ( RAND ) upon receipt of the command.
  • RAND random number
  • HLR/AUC uses its own random number generator to generate a RAND.
  • the HLR/AUC 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.
  • 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.
  • the SKEY setup success command here can also be forwarded through the MSC/VLR.
  • 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.
  • 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.
  • 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.
  • the mobile terminal 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.
  • step 101 is not necessary, and the HLR/AUC can actively generate the RAND and initiate the subsequent process.
  • 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.
  • 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.
  • 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.
  • the mobile terminal 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.
  • 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.
  • 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.
  • 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.
  • RAND is generated by the HLR/AUC, and the RAKD is transmitted to the mobile terminal.
  • RAND can also be generated by the mobile terminal and RAND is sent to the HLR/AUC.
  • the second embodiment of the present invention is proposed, and the flow thereof is as shown in FIG.
  • the mobile terminal first generates a RAND.
  • a mobile terminal generates its own RAND using its own random number generator.
  • the mobile terminal sends a Set SKEY command to the HLR/AUC, and includes the RAND in the command.
  • 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.
  • 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.
  • 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.
  • the SKEY setting success command here can also be forwarded through the MSC/VLR.
  • 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.
  • 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.
  • 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.
  • step 202 the mobile terminal can directly send RAND to the HLR/AUC without including the RAND in the set SKEY command.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobile terminal 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a set SKEY command is first sent by the mobile terminal to the HLR 7AUC.
  • 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.
  • step 302 after receiving the command, the HLR/AUC generates SKEY using one of CK, IK, and KI, or any combination thereof.
  • 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.
  • the 'SKEY setting success command here' can also be forwarded through the MSC/VLR.
  • 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.
  • the mobile terminal directly uses one of CK, IK or KI as the SKEY.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobile terminal 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.
  • 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.
  • the mobile terminal sends a Set SKEY command to the HLR/AUC.
  • 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.
  • the HLR/AUC uses the CK, IK, and KI, or any combination thereof, to generate the SKEY.
  • step 403 after generating the SKEY, the HLR/AUC encrypts the SKEY by CK to form a ciphertext of the SKEY.
  • the HLR/AUC sends the SKEY ciphertext to the mobile terminal.
  • 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.
  • 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.
  • the mobile terminal generates a SKEY using one of CK, I, and KI, or any combination thereof.
  • step 502 the mobile terminal encrypts the SKEY with its own CK to form a ciphertext of the SKEY.
  • step 503 the mobile terminal sends the SKEY ciphertext to the HLR/AUC.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobile terminal 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • SKEY For the generation of SKEY, you can learn from the KI information stored in the SIM card or USM card.
  • the security terminal 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.
  • the HLR After receiving the message, the HLR initiates a UE-Security-Auth-Req message carrying the random number RA D2.
  • the UE 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.
  • the HLR 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.
  • the message should be canceled from the network side, or the above message can be used, but the sending direction is reversed.
  • 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 security terminal 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.
  • the security terminal 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.
  • the MSC/SGS 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.
  • 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.
  • the HLR will close the security function set for the original security terminal and restart the user card.
  • the above authentication set may also be referred to as an authentication tuple, and may also be referred to as an authentication vector.
  • 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.
  • ⁇ "the MSC/VLR device should be the SGSN.
  • 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.
  • 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.
  • 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.
  • 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.
  • the terminal and the network side respectively store a pair of symmetric keys, which are usually the same for symmetric keys.
  • 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. .
  • 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.
  • 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.
  • 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.
  • the mobile terminal 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 1101 first, a SKEY corresponding to the authentication of the mobile terminal is saved in the device and the mobile terminal.
  • 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.
  • step 1102 the network device first generates an RAND when generating authentication information for a mobile terminal.
  • step 1103 the network device generates authentication information using the SKEY and the generated RAND corresponding to the mobile terminal.
  • the network device transmits the authentication information to the corresponding mobile terminal.
  • 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.
  • the SQN saved by itself is updated using the received AUTN.
  • Fig. 12 shows a fourth embodiment of the authentication process.
  • step 1201 the SKEY corresponding to the authentication of the mobile terminal is first saved in the HLR/ATJC and the mobile terminal.
  • the HLR 7AUC generates a RAMD using its own random number generator.
  • the HLR/AUC calculates XRES, CK, and IK using its own stored authentication key (KI) and its own generated RAND.
  • 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.
  • the HLR/AUC combines the MAC and the known SQN into an AUTN.
  • 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.
  • the HLR/AUC groups RAND, AUTN, XRES CK, and IK into an authentication set.
  • the HLR/AUC sends the authentication set to the MSC/VLR.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the SQN saved by the received AUTN is used to update the saved SQN.
  • 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.
  • steps 1301-1313 and steps 1201-1213 are identical, and the description will not be repeated.
  • the mobile terminal transmits RAND to the user card.
  • the user card generates XRES, CK, and IK using its own KI and the received RAND.
  • the user card transmits the generated XRES to the mobile terminal.
  • the mobile terminal transmits the XRES received from the subscriber card to the MSC/VLR.
  • 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.
  • the mobile terminal 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.
  • 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.
  • the mobile terminal 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.
  • SRES2g Signed Response Symbol Response
  • KC2g Cipher Key
  • the relevant derivation method has suggestions in the relevant protocols in the existing 3GPP, and will not be described here.
  • 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.
  • step 1401 the SKEY corresponding to the mobile terminal authentication is first saved in the HLR/AUC and the mobile terminal.
  • step 1402 HL /AUC uses its own random number generator to generate a RAND.
  • 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.
  • 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.
  • HL /AUC combines the MAC and the known SQN into AUTO.
  • 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.
  • the HLR/AUC groups RAND, AUTN, XRES, CK, and IK into an authentication set.
  • the HLR/AUC sends the authentication set to the MSC/VLR.
  • 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.
  • 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.
  • 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.
  • the predetermined condition may be that the difference between the SQN in the AUTN and the self-saved SQN is within a predetermined range. ⁇
  • 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.
  • the SQN saved by the received AUTN is used to update the saved SQN.
  • 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.
  • 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.
  • 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.
  • the network device such as the MSC/VLR
  • 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.
  • 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.
  • the HLR/AUC 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.
  • the non-secure terminal when a user card used in a secure terminal is inserted into a non-secure terminal, 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.
  • 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.
  • the algorithm for generating the response value may be different.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé permettant de définir un code de sécurité dans un réseau de communication mobile, comprenant au moins les étapes suivantes: un terminal mobile ou un équipement génère un nombre aléatoire, puis transmet ce nombre aléatoire à l'autre partie, et l'équipement réseau et le terminal mobile définissent chacun le code de sécurité fondé sur ce nombre aléatoire. Dans un mode de réalisation différent, le terminal mobile définit le code de sécurité et transmet une commande de définition de code de sécurité à l'équipement réseau, puis l'équipement réseau génère le code de sécurité selon un procédé identique à celui du téléphone mobile après avoir reçu cette commande 'définir code de sécurité'.
PCT/CN2005/001872 2004-11-09 2005-11-08 Procede de definition de code de securite WO2006050663A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410092775A CN100579274C (zh) 2004-11-09 2004-11-09 安全密钥的设置方法
CN200410092775.2 2004-11-09

Publications (1)

Publication Number Publication Date
WO2006050663A1 true WO2006050663A1 (fr) 2006-05-18

Family

ID=36336209

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001872 WO2006050663A1 (fr) 2004-11-09 2005-11-08 Procede de definition de code de securite

Country Status (2)

Country Link
CN (1) CN100579274C (fr)
WO (1) WO2006050663A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571702B (zh) * 2010-12-22 2014-11-05 中兴通讯股份有限公司 物联网中的密钥生成方法、系统和设备
CN102833722B (zh) * 2012-08-31 2019-05-07 中兴通讯股份有限公司 删除位置消息的处理方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1291390A (zh) * 1998-01-27 2001-04-11 Dsc电信有限合伙公司 动态更新蜂窝话机唯一加密密钥的方法
CN1426185A (zh) * 2001-12-13 2003-06-25 华为技术有限公司 一种自主选择加密算法实现保密通信的方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1291390A (zh) * 1998-01-27 2001-04-11 Dsc电信有限合伙公司 动态更新蜂窝话机唯一加密密钥的方法
CN1426185A (zh) * 2001-12-13 2003-06-25 华为技术有限公司 一种自主选择加密算法实现保密通信的方法

Also Published As

Publication number Publication date
CN100579274C (zh) 2010-01-06
CN1774125A (zh) 2006-05-17

Similar Documents

Publication Publication Date Title
EP1758417B1 (fr) Procede d'authentification
JP4688808B2 (ja) 移動体通信システムにおける暗号化の強化セキュリティ構成
JP5784776B2 (ja) 認証能力のセキュアなネゴシエーション
EP2932676B1 (fr) Authentification de réseaux mobiles terrestres publics sur des stations mobiles
EP2296392A1 (fr) Procédé d'authentification, procédé de recertification et dispositif de communication
CN109922474B (zh) 触发网络鉴权的方法及相关设备
US20100135491A1 (en) Authentication method
WO2006128364A1 (fr) Procede et systeme de mise a jour d'une cle secrete
JP2013545367A (ja) ローミングネットワークにおけるアクセス端末識別情報の認証
JP2016533694A (ja) ユーザアイデンティティ認証方法、端末及びサーバ
TW200952424A (en) Authenticating a wireless device in a visited network
JP2014524073A (ja) サービスアクセス認証方法およびシステム
CN113228721B (zh) 通信方法和相关产品
WO2008006312A1 (fr) Procédé de fourniture de service push de gaa et dispositif associé
JP2016111660A (ja) 認証サーバ、端末及び認証方法
WO2011124051A1 (fr) Procédé et système d'authentification de terminal
WO2006047938A1 (fr) Procede permettant a un equipement de reseau de produire un nombre aleatoire d'authentification de carte d'abonne et procede d'authentification
JP6581221B2 (ja) セキュリティエレメントを認証するための少なくとも１つの認証パラメータを置き換える方法及び対応するセキュリティエレメント
EP3550765B1 (fr) Fourniture de services
CN101160784B (zh) 一种密钥更新协商方法及装置
CN108271154B (zh) 一种认证方法及装置
WO2006050663A1 (fr) Procede de definition de code de securite
EP4057659A1 (fr) Procédé de remplacement d'une clé de courant dans un élément de sécurité et élément de sécurité correspondant

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 4764/CHENP/2006

Country of ref document: IN

122 Ep: pct application non-entry in european phase

Ref document number: 05806964

Country of ref document: EP

Kind code of ref document: A1