WO2008006306A1 - Procédé et dispositif de dérivation d'une clé interface locale - Google Patents

Procédé et dispositif de dérivation d'une clé interface locale Download PDF

Info

Publication number
WO2008006306A1
WO2008006306A1 PCT/CN2007/070025 CN2007070025W WO2008006306A1 WO 2008006306 A1 WO2008006306 A1 WO 2008006306A1 CN 2007070025 W CN2007070025 W CN 2007070025W WO 2008006306 A1 WO2008006306 A1 WO 2008006306A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
uicc
naf
local interface
terminal
Prior art date
Application number
PCT/CN2007/070025
Other languages
English (en)
French (fr)
Inventor
Yanmei Yang
Shuhua Cao
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.
Priority to CN2007800003031A priority Critical patent/CN101317359B/zh
Priority to EP07721648.9A priority patent/EP2037621B1/en
Publication of WO2008006306A1 publication Critical patent/WO2008006306A1/zh
Priority to US12/348,534 priority patent/US8559633B2/en
Priority to US14/013,912 priority patent/US9467432B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
    • 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

Definitions

  • the present invention relates to the field of general authentication framework (GAA) technology, and more particularly to a method and apparatus for generating a local interface key.
  • GAA general authentication framework
  • GAA is a general structure used by various application service entities to complete the verification of user identity.
  • the universal authentication framework can be used to check and verify the identity of users corresponding to the service.
  • the foregoing multiple application services may be multicast or broadcast services, user certificate services, information provision services, or proxy services.
  • FIG la is a schematic diagram of the structure of the general authentication framework of the prior art.
  • the universal authentication framework is usually performed by the user, the service function (BSF) entity that performs the initial check and verification of the user identity, the home subscriber server (HSS), and the network service.
  • BSF service function
  • HSS home subscriber server
  • NAF Application
  • the BSF solid cartridge is referred to as a BSF
  • the NAF solid cartridge is referred to as a NAF.
  • the BSF is used for mutual authentication with the user.
  • the mutual authentication process is a process of mutually authenticating the identity and generating a shared key between the BSF and the user.
  • the mutual authentication process is also called a Bootstrapping process or a GBA process, and is said to be implemented with the BSF.
  • the user of the GBA process is a user with GBA function; the HSS stores a profile file for describing user information, and the HSS also has the function of generating authentication information; NAF can represent different network service application entities, and the user needs When a certain service is implemented, the NAF corresponding to the service must be accessed and communicated with the NAF.
  • the interface between the entities is shown in Figure la.
  • the BSF is connected to the NAF through the Zn interface.
  • the user connects to the BSF or NAF through the user terminal (UE).
  • the UE and the BSF are connected through the Ub interface. Between the UE and the NAF. Connected via the Ua interface.
  • you can put BSF, NAF and HSS are collectively referred to as the network side.
  • the user When the user needs to use a certain service, if the user knows that the service needs to go to the BSF for the GBA process, the user directly goes to the BSF for mutual authentication. Otherwise, the user first contacts the NAF corresponding to the service, if the NAF uses GAA universal authentication. The framework, and finds that the user has not yet reached the BSF for mutual authentication, and the NAF notifies the user to the BSF for mutual authentication to verify the identity.
  • the step of GBA (mutual authentication) between the user and the BSF includes: the user sends an authentication request to the BSF; after receiving the authentication request, the BSF first obtains the authentication information of the user from the HSS; after the BSF obtains the authentication information, The user performs mutual authentication and key agreement to complete the mutual authentication of the identity between the user and the BSF and the generation of the shared key Ks.
  • the BSF also defines an expiration date (Key-lifetime) for the shared key Ks, so that Ks Make regular updates.
  • the shared key Ks is used as a root key to derive a key for encrypted communication.
  • the BSF then assigns a session transaction identifier (B-TID) to the user.
  • B-TID session transaction identifier
  • the B-TID is associated with Ks and can be used to identify the Ks and also the validity period of the Ks.
  • the user After receiving the B-TID, the user sends a connection request to the NAF again, and the B-TID is carried in the request message, and the user side calculates the derived key Ks_NAF according to Ks.
  • the NAF After receiving the connection request, the NAF first queries the local B-TID for the user. If the NAF cannot query the B-TID locally, the NAF queries the BSF. The query message carries the NAF identifier (NAF_ID). And ⁇ - ⁇ If the BSF cannot query the B-TID locally, the NAF is notified that there is no information about the user. At this time, the NAF will notify the user to re-authenticate the authentication to the BSF.
  • NAF_ID NAF identifier
  • the Ks derived key Ks_NAF is calculated by using the same algorithm as the user side, and a successful response message is sent to the NAF, and the successful response includes the B-TID required by the NAF, and the The derived key Ks_NAF corresponding to the B-TID, and the expiration date set by the BSF for the key.
  • the NAF After receiving the success response message from the BSF, the NAF considers the user to be a BSF-authenticated user and NAF. The user also shares the key Ks_NAF derived from Ks.
  • the NAF and the user perform encrypted communication through Ks_NAF in the subsequent communication process.
  • the GBA process can be divided into the GBA_ME process and the GBAJJ process.
  • the key Ks_NAF will be generated, and the Ks_NAF will be stored in the mobile device (ME); for the GBAJJ process, two keys will be generated.
  • One of them is the key of the user identity module UICC in the mobile device, that is, Ks_int_NAF, and the other is the key of the ME, that is, Ks_ext_NAF.
  • WLAN wireless local area network
  • PDA personal digital assistant
  • PC personal computer
  • GPRS General Packet Radio Service
  • a user can have a variety of terminal devices, and these terminal devices share user information corresponding to one user terminal (UE) of the user, such as the UICC of the UE (the GSM User Identity Module (SIM) can be used on the UICC.
  • SIM User Identity Module
  • USIM User identity module
  • Figure lb is a schematic diagram of the GAA framework in a state where the NAF application client and the GBA client are separated.
  • a mobile user has multiple terminal devices, such as a mobile phone, and other terminal devices such as a PC, a WLAN UE, a palmtop computer, and the like. And these terminal devices use the same The UE user information accesses the network service.
  • the NAF application client is not on the UICC, but on one or a few peripheral terminal devices other than the UICC.
  • the GBA client is still on the UICC.
  • the terminal device before the terminal device establishes a secure connection with the network, the terminal device must obtain relevant confidential information in the UICC, so as to ensure that the terminal device can securely access the network or carry out corresponding services, that is, the terminal device and the UICC need to transmit some information.
  • Confidential information such as the information of the UICC required for the two-way authentication of the terminal device and the network, and the key information that the terminal device needs to use when conducting the service.
  • the local interface U L0 between the terminal device and the UICC must provide security, to ensure the transfer of information between the terminal device and the UICC without leaking, not to be illegally obtained. Only the security of the local interface is protected, and the security of the entire network can be fully guaranteed.
  • the terminal device is referred to as a terminal to use an application, and it is checked that there is no Ks_Local required for communication with the UICC corresponding to the application, or the terminal checks that it has Ks_Local required for communication with the UICC corresponding to the application.
  • the Ks_Local negotiation process is initiated when there is no Ks_Local corresponding to the application in the UICC.
  • FIG. 2 is a flowchart of the local interface key negotiated between the UICC and the terminal in the prior art, and specifically includes the following steps: Step 200: Terminal The UICC is requested to perform a complete GBA process and a GB A_U process associated with the NAF key center to generate the associated keying material.
  • the NAF key center is a server for negotiating a communication key between the terminal and the UICC.
  • the shared key Ks between the terminal/UICC and the BSF is negotiated through the GBA process and the GBAJJ process, and the key Ks_int_NAF corresponding to the B_TID and NAF identifier (NAF_ID) stored in the UICC is negotiated.
  • Step 201 The terminal requests the UICC for the B_TID related to the Ks_int_NAF generated in the GB A process.
  • the terminal carries the required Ks_Local, such as the terminal identifier (Terminal_ID), in the request. Relevant information, such as the logo of the application.
  • Step 202 The UICC derives Ks_Local by using its stored Ks_int_NAF and the received TerminaUD.
  • UICC is derived from Ks_int_NAF and related information from the terminal.
  • Ks_Local and store the Ks_Local.
  • this step may also be performed after step 210.
  • Step 203 The UICC sends a B_TID related to Ks_int_NAF to the terminal, and may also include a NAF_ID.
  • Step 204 The terminal performs mutual authentication with the NAF and establishes a tunnel.
  • a TLS-based Hypertext Transfer Protocol (HTTPS) tunnel or the like is established through a certificate method, etc., and the specific implementation is well known to those skilled in the art, and the related materials can be referred to, and details are not described herein again.
  • HTTPS Hypertext Transfer Protocol
  • Step 205 The terminal sends a local key establishment request to the NAF key center through the established HTTPS tunnel.
  • the local key establishment request carries TerminaUD and the obtained 8_ ⁇ 10, and may also carry information such as NAF_ID.
  • Step 206 The NAF sends an authentication request to the BSF, where the authentication request carries the B_TID and its own NAF_ID.
  • Step 207 The BSF sends an authentication response to the NAF, where the authentication response carries information such as Ks_int_NAF and related information such as the life cycle of the Ks_int_NAF.
  • Step 208 The NAF checks, according to the TerminaUD, that the terminal can access the network through the UICC, uses Ks_int_NAF and related information, derives Ks_Local by using the same algorithm as in the UICC, and defines a life cycle for the Ks_Local.
  • Step 209 The NAF sends the derived Ks_Local and its life cycle to the terminal through the HTTPS tunnel.
  • Step 210 The terminal stores the received Ks_Local and its life cycle. At this point, the terminal shares Ks_Local with the UICC and uses the Ks_Local for secure communication.
  • the existing JACC and terminal negotiation Ks_Local method has the following problems:
  • Ks_Local is derived from Ks_int_NAF.
  • the terminal loses Ks_Local due to network-side interrupt communication such as shutdown, if the terminal initiates the application corresponding to the Ks_Local again, it will initiate Figure 2.
  • the entire negotiation process is shown. However, in this case, the Ks and related derivative keys saved on the UICC have not expired. If a new Ks_Local is renegotiated according to the process shown in Figure 2, a complete GBA process will be executed again, so that the existing Ks secrets are made.
  • the key and derived keys are not fully utilized, resulting in an overly cumbersome process and wasted resources.
  • Ksjocal can be re-derived by using the existing Ks key and the derived key during the validity period of the existing Ks key and the derived key. That is, when the Ks_Local in the terminal and the UICC is invalid or is about to be invalid, but the Ks_int_NAF derived from the Ks_Local is in the valid period, the Ks_int_NAF is used to re-derive Ks_Local. However, since the parameters of the calculation key are the same as those in the process of negotiating the lost Ks_Local, the Ksjocal derived this time is the same as the Ks_local derived from the previous one. Such processing reduces the communication between the UICC and the terminal to some extent. Security Level. Summary of the invention
  • an object of the embodiments of the present invention is to provide a method and an apparatus for generating a local interface key, which can simply acquire a local interface key and ensure a security level of communication between the UICC and the terminal.
  • a method for generating a local interface key comprising the following steps:
  • A generating variable parameters
  • B Deriving a local interface key according to the generated variable parameter and a related parameter for calculating a local interface key.
  • a terminal includes at least a variable parameter generating module and a sending module, wherein the variable parameter generating module is configured to generate a variable parameter;
  • the sending module is configured to send the generated variable parameters to the UICC or the network side.
  • a UICC includes at least a first receiving module and a first processing module, where the first receiving module is configured to receive variable parameters from the terminal;
  • the first processing module is configured to derive the local interface key using the received variable parameters.
  • An NAF includes at least a second receiving module and a second processing module, where the second receiving module is configured to receive variable parameters from the terminal;
  • the second processing module is configured to derive the local interface key using the received variable parameters.
  • the solution of the present invention utilizes the generation of variable parameters, and derives the local interface key according to the generated variable parameters and the relevant parameters for calculating the local interface key.
  • the relevant parameters for calculating the local interface key are known.
  • the method of the invention encapsulates the implementation process of the terminal acquiring the local interface key, saves the time for negotiating the Ks_Local, thereby saving system resources.
  • the present invention combines variable parameters such as random numbers or time stamps, and valid key information such as root key Ks, Ks_int_NAF derived from Ks, and re-derived to obtain a local interface key, ensuring between the UICC side and the terminal.
  • the security level of communication is possible.
  • the UICC side refers to the UICC itself and the device to which the UICC belongs. Therefore, by applying the method of the present invention, the key can be reused to derive a different Ks_local during the validity period of the Ks or its derived key, without having to re-execute a complete GBA process every time the Ksjocal is updated, thereby saving the negotiation Ks_Local. Time, as well as system resources.
  • Figure la is a schematic diagram of the structure of the GAA
  • Figure lb is a schematic diagram of the GAA framework in a state where the NAF application client and the GBA client are separated;
  • FIG. 2 is a flow chart of negotiating a local interface key between a UICC and a terminal in the prior art
  • FIG. 3 is a flowchart of acquiring a local interface key by the terminal of the present invention
  • FIG. 4 is a flowchart of Embodiment 1 of the present invention for acquiring a local interface key
  • FIG. 5 is a flowchart of Embodiment 2 of the present invention for acquiring a local interface key
  • FIG. 7 is a flowchart of Embodiment 4 of the present invention for acquiring a local interface key
  • FIG. 8 is a flowchart of Embodiment 5 of the present invention for acquiring a local interface key.
  • the implementation of the embodiment of the present invention is: generating a variable parameter, and deriving a local interface key according to the generated variable parameter and calculating a related parameter of the local interface key.
  • FIG. 3 is a flowchart of obtaining a local interface key by the terminal of the present invention.
  • the NAF key center in the present invention is a NAF entity.
  • Step 300 The terminal acquires key related information, and uses the obtained key related information to request the network side to establish a local interface key.
  • the terminal may obtain the key related information by requesting from the UICC side, and the key related information may be key identification information such as 8_0, key life cycle, and the like.
  • the UICC side may be the UICC itself or a device to which the UICC belongs.
  • Step 301 The network side queries the valid key information by using the received key related information, and derives the local interface key by using the key information and the generated variable parameter.
  • Ks_int_NAF or Ks using a variable parameter such as a random number or timestamp or the value of the synchronization counter, and Ks_int_NAF, derives a Ks_Local that is different from the previous derived Ks_local, or uses a variable parameter such as a random number or a timestamp.
  • Step 302 The network side sends the derived local interface key to the terminal.
  • the method further comprises: the UICC side itself deriving Ks_Local with a valid Ks_int_NAF and a variable parameter identical to the network side and storing, or using a valid Ks and a variable parameter identical to the network side, Ks_int_NAF which is different from the previous derived Ks_int_NAF is derived, and Ks_Local is derived by using the Ks_int_NAF.
  • the terminal may first determine whether it has the Ks_Local corresponding to the application to be used, and if yes, send a query request to the UICC side to check whether the Ks_Local in the UICC side is valid, and may be in the UICC.
  • a counter is set in the side to determine whether the Ks_Local is valid. If the counter is 0 or null (NULL), it indicates that the Ks_Local is invalid, and an invalid response is returned. Then the terminal initiates a new key negotiation process; otherwise, the Ks_Local is valid, directly Applying communication between the Ks_Local and the UICC side;
  • Ks_Local can be. It should be noted that even if the Ks_Local corresponding to the currently used application in the UICC has not expired, the new Ks_Local can be obtained through the flow shown in FIG. 3.
  • Embodiment 1 takes the UICC side as the UICC as an example, and describes a specific implementation of the method of the present invention in combination with several embodiments.
  • Embodiment 1 In the case where the NAF related key is valid as Ks_int_NAF, it is assumed that the variable parameter is the random number RAND.
  • Embodiment 4 is a flow chart of Embodiment 1 of the present invention for acquiring a local interface key, and the following steps are included:
  • Step 400 The terminal queries the UICC for the 8_ ⁇ 10 associated with the Ks_int_NAF generated in the GB A process, and may further request the local interface key derivation indication.
  • the query request may carry all or one of Terminal_ID, Terminal_appli_ID, random number RAND.
  • the terminal needs to generate the random number RAND required to derive the local interface key and store it.
  • the generated method belongs to the prior art, and is not described here.
  • the random number RAND may also be separately carried in a local key derivation instruction and sent to the UICC, that is, the local interface key derivation instruction is not executed in this step, but is in a separate local key derivation instruction form in other steps. send.
  • the terminal may further include the step of checking whether there is a valid Ks on the UICC side. If there is no Ks or the existing Ks has expired, then a complete GBA process needs to be initiated to negotiate a new Ks. At this time, since the terminal can obtain the B-TID information, the process of querying the B-TID of the Ks_int_NAF in step 400 can be omitted, or the Ks_int_NAF query process can be performed before the UICC is required to calculate the Ksjocal, so as to know whether the available Ks_int_NAF exists in the UICC.
  • Step 401 The UICC derives Ks_Local and stores it by using the Ks_int_NAF generated in the GB A_U process and the received random number RAND.
  • the GBA_U key derivation process needs to be performed.
  • the GBAJJ process may be executed by the UICC after receiving the local key derivation instruction; or may receive a local key derivation instruction before receiving a
  • the GBAJJ key derivation instruction is executed by the UICC. This step may be performed after step 402 or 408. At this time, the local key derivation instruction in step 400 may be executed after step 402 or 408, and is performed before this step.
  • Step 402 The UICC sends a B_TID corresponding to the Ks_int_NAF generated in the GB A process, and may further include a life cycle corresponding to the Ks_int_NAF to the terminal.
  • the UICC when the UICC returns the B_TID to the terminal, and further includes the life cycle, the UICC sends its own UICC identifier (UICC_ID) and the identifier of the application of the UICC (UICC_appli_ID) to the terminal.
  • UICC_ID UICC identifier
  • UICC_appli_ID the identifier of the application of the UICC
  • the step may further include: determining, by the terminal according to the life cycle corresponding to the Ks_int_NAF, whether the Ks_int_NAF expires, if not, proceeding to step 403; if it expires, triggering the GBA process, and then returning to step 400.
  • Step 403 The terminal performs mutual authentication with the NAF key center and establishes a secure tunnel such as an HTTPS tunnel.
  • Step 404 The terminal sends a local interface key establishment request to the NAF key center through the established HTTPS tunnel.
  • the local key establishment request carries a Terminal_ID, a Terminal_appli_ID, a obtained B_TID, a UICCJD, a UICC_appli_ID, and a random number RAND stored by the terminal.
  • the NAF key center can generate a valid local interface key for different applications.
  • Step 405 to step 406 The NAF key center queries the valid Ks_int_NAF corresponding to the 8_10, and derives the Ks_Local with the valid Ks_int_NAF and the received random number RAND and allocates the life cycle of the Ks_Local.
  • the information about participating in the derived Ks_Local also includes other related information such as Terminal_ID, Terminal_appli_ID, UICCJD, UICC_appli_ID, etc.
  • the specifically derived algorithm is not related to the present invention and will not be described in detail herein.
  • the UICC and NAF key centers use the same derived algorithm to derive Ks_Local.
  • This step directly uses the stored key information, that is, the valid Ks_int_NAF derived Ks_Local, to implement the process of obtaining the local interface key by the terminal, which saves the time for negotiating the Ks_Local, thereby saving network resources.
  • this step uses a random number, even if the Ks_int_NAF is the same, the derived Ks_Local is different, which ensures the security level of communication between the terminal and the UICC.
  • the NAF key center may request the key information from the BSF. This is not in the scope of the present invention, and may refer to the existing solution. I won't go into details here.
  • the method further includes: the NAF key center may query whether the terminal is restricted to use the UICC to access the network by using the Terminal_ID and the UICC_ID, and the query mode belongs to the prior art, and may be The NAF key center maintains a database that stores which terminals a UICC allows to be used, or stores information about which terminals a UICC does not allow. If the device is allowed to access the network, Ks_Local is derived using Ks_int_NAF and related information, otherwise, a response indicating that the terminal does not have the right to access the network with the UICC is returned.
  • Step 407 The NAF key center sends a local key establishment response to the terminal through the tunnel, where the response carries the B_TID, the derived Ks_Local, and its life cycle.
  • Step 408 The terminal stores the received Ks_Local and its life cycle.
  • the terminal and the UICC share the Ks_Local and use the Ks_Local for secure communication.
  • Embodiment 2 the case where the NAF related key is valid as Ks_int_NAF.
  • variable parameters are generated by the terminal.
  • two possible timelines for generating variable parameters are listed: (1) The UICC precedes the NAF key.
  • Ks_Local When the heart derives Ks_Local, when the UICC derives Ks_Local, it generates the variable parameter as the parameter of the derived Ks_Local, and passes the variable parameter to the NAF key center through the terminal.
  • the NAF key center also uses the variable parameter as a derivative.
  • NAF key center precedes UICC derived Ks_Local, NAF key center generates this when it derives Ks_Local
  • the variable parameter is used as a parameter for deriving Ks_Local, and the variable parameter is passed to the UICC through the terminal.
  • the UICC also uses the variable parameter as a parameter of the derived Ks_Local, and uses the same derivative algorithm as the NAF key center to generate the NAF secret.
  • the Ks_Local; the variable parameter may be the same when the BSF calculates the Ks_int_NAF and then passes it to the UICC through the terminal.
  • the UICC uses the Ks stored by itself and the received variable parameter to derive Ks_int_NAF, and receives the derived local interface secret. When the key is requested, the Ks_int_NAF is used to derive Ks_local.
  • FIG. 5 is a flowchart of Embodiment 2 of the present invention for acquiring a local interface key.
  • the NAF key center is preceded by the UICC derived Ks_Local as an example, and the implementation method is specifically described, including the following steps:
  • Step 500 The terminal requests, from the UICC, a B_TID and a key life cycle related to Ks_int_NAF generated in the GB A process, and the request may carry TerminaUD and Terminal_appli_ID.
  • the terminal may further include the step of checking whether there is a valid Ks on the UICC side. If there is no Ks or the existing Ks has expired, then a complete GBA process needs to be initiated to negotiate a new Ks. At this time, since the terminal can obtain the B-TID information, the process of searching for the B-TID of the Ks_int_NAF in steps 500, 501 may be omitted, or the Ks_int_NAF query process may be performed before the UICC is required to calculate the Ksjocal, so as to know whether the UICC is available or not. Ks_int_NAF.
  • Step 501 The UICC sends information such as a B_TID and a life cycle corresponding to the Ks_int_NAF generated in the GB A process to the terminal.
  • the UICC sends its own UICC_ID and UICC_appli_ID to the terminal.
  • Step 502 The terminal performs mutual authentication with the NAF and establishes an HTTPS tunnel.
  • Step 503 The terminal sends a local key establishment request to the NAF key center through the established HTTPS tunnel.
  • the local key establishment request carries a Terminal_ID, a Terminal_appli_ID, a obtained B_TID, a UICC_ID, and a UICC_appi_ID. In this way, the NAF key center can generate a valid local interface key for different applications.
  • the valid Ks_int_NAF and the generated random number RAND are used to derive Ks_Local and allocate the life cycle of the Ks_Local.
  • the NAF key center In this step, the NAF key center generates a random number RAND and stores it.
  • the method for generating the random number RAND belongs to the prior art, and details are not described herein again.
  • This step directly uses the stored key information, that is, the valid Ks_int_NAF derived Ks_Local, to implement the process of obtaining the local interface key by the terminal, which saves the time for negotiating the Ks_Local, thereby saving network resources.
  • this step uses a random number, even if the Ks_int_NAF is the same, the derived Ks_Local is different, which ensures the security level of communication between the terminal and the UICC.
  • the NAF key center requests the key information from the BSF. This is not in the scope of the present invention, and may refer to the existing solution. I won't go into details here.
  • the method further includes: the NAF key center may query whether the terminal is restricted to use the UICC to access the network by using the Terminal_ID and the UICC_ID. If the device is allowed to access the network, use Ks_int_NAF and related information derive Ks_Local, otherwise, a response indicating that the terminal has no right to access the network with the UICC is returned.
  • Step 506 The NAF key center sends a local key establishment response to the terminal through the HTTPS tunnel, and the response carries the 8s D. 10, the random number RAND stored in the NAF key center itself, and the derived Ks_Local and its life cycle. .
  • Step 507 The terminal stores the received Ks_Local and its life cycle.
  • Step 508 The terminal sends a Ks_Local request to the UICC, where the request carries a Terminal_ID, a Terminal_appli_ID, and a random number RAND from the NAF key center.
  • Step 509 The UICC derives the Ks_Local and stores it by using the valid Ks_int_NAF generated in the GB A_U process and the received random number RAND.
  • GBAJJ process may be performed in this step or in any step before step 508.
  • the terminal and the UICC share the Ks_Local and use the Ks_Local for secure communication.
  • variable parameter RAND for calculating the local interface key in the flow shown in FIG. 5 can also be generated by the UICC or the terminal. If the variable parameter RAND is generated by the UICC, then steps 508 and 509 may be performed before step 502, and after successful execution, the UICC sends the UICC generated RAND value to the terminal. The terminal sends the RAND value to the network side in step 503, so that the network side calculates the local key using the same RAND value.
  • step 503 the RAND value generated by the terminal needs to be sent to the network side, so that the network side calculates the local key by using the same RAND value.
  • the NAF related key Ks_int_NAF is invalid and Ks is valid.
  • Embodiment 3 of the terminal for acquiring a local interface key includes the following steps:
  • Step 600 The terminal requests Ks related information to the UICC, where the request may carry the Terminal_ID and the Terminal_appli_ID, and may also carry the terminal to indicate the current time value.
  • Step 601 The UICC searches for the locally existing Ks, and the life cycle corresponding to the Ks and the B -TID is returned to the terminal.
  • the UICC can query whether there is a valid Ks locally according to the timestamp, and if yes, send the life cycle and the B_TID corresponding to the Ks to the terminal, and go to step 603; otherwise, enter Step 602.
  • the UICC compares the timestamp and the life cycle to determine the validity of the Ks. If the life cycle is greater than the timestamp, it indicates that it is valid; otherwise, it means invalid.
  • Step 602 Initiate the GBA process to generate a valid Ks.
  • the triggering of the GBA process in this step may have multiple situations: If the terminal is the ME to which the UICC belongs, the GBA process is directly initiated by the ME; if the terminal is a peripheral terminal connected to the UICC through an external interface, then the peripheral terminal may be The UICC sends an instruction, and then the UICC sends an active command to the ME to trigger the GBA process, or the UICC finds that there is no valid Ks, sends an active command to the ME to trigger the GBA process, or the peripheral terminal directly sends a command to the ME to trigger the GBA process; It is also possible that the terminal itself initiates the GBA process.
  • the purpose of the GBA process is to generate a Ks that is stored in the UICC.
  • Step 603 The terminal performs mutual authentication with the NAF and establishes an HTTPS tunnel.
  • Step 604 The terminal sends a local key establishment request to the NAF key center through the established HTTPS tunnel.
  • the local key establishment request carries the B_TID generated by the GBA process in step 602 or returned by the UICC to the terminal, and the Terminal_ID, Terminal_appli_ID, UICC_ID, UICC_appi_ID, and the random number RAND that may be carried by the terminal or UICC.
  • the NAF key center can generate a valid local interface key for different applications.
  • Step 605 The NAF key center requests Ks_int_NAF from the BSF, and the request may carry the received B_TID and the random number RAND, and its own NAF_ID.
  • the random number may be sent by the terminal in step 604, or may be generated by the NAF key center.
  • Step 606 The BSF derives the Ks_int_NAF by using parameters such as Ks, NAF_ID, and random number RAND corresponding to the B_TID, and allocates the life cycle corresponding to the Ks_int_NAF, and sends the Ks_int_NAF and its life cycle to the NAF key center.
  • parameters such as Ks, NAF_ID, and random number RAND corresponding to the B_TID
  • the random number RAND is used to make the Ks_int_NAF derived from Ks different from the previous used Ks_int_NAF.
  • Step 607 The NAF key center derives Ks_Local by using the received Ks_int_NAF.
  • the NAF key center further includes: Before using the valid Ks_int_NAF to derive the Ks_Local, the NAF key center may query the terminal to use the UICC to access the network through the TerminaUD and the UICC_ID. If the device is allowed to access the network, Ks_int_NAF and related information are used to derive Ks_Local, otherwise, a response indicating that the terminal does not have the right to use the UICC to access the network is returned.
  • Step 608 The NAF key center sends a local key establishment response to the terminal through the HTTPS tunnel, where the response carries 8_0, Ks_Local, and its lifetime.
  • Step 609 The terminal stores the received Ks_Local and its life cycle.
  • Step 610 The terminal sends a Ks_Local request to the UICC, where the request carries a Terminal-ID and a Terminal_appli_ID.
  • Step 611 The UICC first derives Ks_int_NAF by using parameters such as Ks and NAF_ID, random number RAND, etc., and then uses the Ks_int_NAF to derive Ks_Local and stores it.
  • the UICC and NAF key centers use the same derived algorithm to derive Ks_Local.
  • the step of the UICC deriving the Ks_int_NAF by using the parameters such as Ks, NAF_ID, and random number RAND in steps 610-611 may also be performed at any step after step 602 before step 610.
  • the flow of this embodiment is only one of them, and does not limit the order in which the terminal interacts with the UICC, and interacts with the terminal and the network side.
  • the terminal and the UICC share the Ks_Local and use the Ks_Local for secure communication.
  • the method for obtaining the Ks_Local in the first embodiment and the second embodiment is: using a variable parameter such as a random number or a time stamp, and a valid Ks_int_NAF in the key information.
  • the Ks_Local is different from the previous derived Ksjocal
  • the third method of obtaining the Ks_Local is: using a variable parameter such as a random number or a timestamp, and Ks in the key information to derive the Ks_int_NAF from the previous derivation. Not the same Ks_int_NAF, and then use this Ks_int_NAF to derive Ks_Local.
  • the UICC side and the BSF calculate the variable parameter of the Ks_int_NAF by using the variable parameter and the Ks, which may be generated by the NAF key center and carry the request message in step 605, except for the terminal generated in this embodiment.
  • the BSF is sent to the BSC, and then sent to the UICC side through steps 608, 609, and 610. It can also be generated by the BSF in step 606, and sent to the UICC side through subsequent steps.
  • the process of acquiring the Ks_Local is not required, and the process of acquiring the Ks_Local is obtained, and the local interface key is obtained in a single manner, thereby saving the time for negotiating the Ks_Local, thereby saving network resources;
  • the Ks_Local obtained by participating in the derivation is different from the previous Ks_Local, which guarantees the security level of communication between the UICC and the terminal.
  • steps 600 to 602 in the third embodiment may be added before the implementation of the first embodiment and the second embodiment.
  • the steps 400 to 401 in the first embodiment are performed. It can be omitted, and steps 500 to 501 in the second embodiment can be omitted.
  • the Ks_Local can be obtained, and the UICC can also be used.
  • the interaction obtain information related to Ks_Local, such as 8_ ⁇ 10 and the application-related identifier, and directly obtain the Ks_Local corresponding to the 8_ ⁇ 10 from the NAF key center by using the obtained related information.
  • the implementation method will be described in detail below with reference to Embodiment 4 and Embodiment 5.
  • Embodiment 4 A case where Ks_Local exists in the UICC and has not expired.
  • FIG. 7 is a flowchart of Embodiment 4 of the terminal for acquiring a local interface key according to the present invention, which includes the following steps:
  • Step 700 The terminal initiates a query Ks_Local request to the UICC, where the request carries a Terminal-ID and a Terminal_appli_ID.
  • Step 701 The UICC queries the Ks_Local corresponding to the Terminal_ID and the Terminal_appli_ID, and the UICC carries the Ks_Local lifetime in the query response and sends the response to the terminal.
  • the query response also carries UICC_ID and UICC_appli_ID.
  • the UICC notifies the terminal that there is no Ks_Local, and then the terminal obtains the method shown in the first embodiment, the second embodiment, or the third embodiment. Ks_Local.
  • Step 702 The terminal determines, according to the lifetime of the received Ks_Local, and the time mechanism of the terminal, that the Ks_Local has not expired, and requests the Ks_Local from the NAF key center.
  • the terminal obtains the Ks_Local by using the method shown in the first embodiment, the second embodiment, or the third embodiment.
  • the terminal sends a request to the UICC to delete the old Ks_Local and initiate a new Ks_Local. Delete the old Ks_Local and send it
  • the new Ks_Local request can be sent as a message or sent in two; or, the terminal only sends a request to delete the old Ks_Local to the UICC; or the terminal only sends a request to the UICC to establish a new Ks_Local.
  • Step 703 The terminal performs mutual authentication with the NAF and establishes an HTTPS tunnel.
  • Step 704 The terminal requests Ks_Local from the NAF key center through the established HTTPS tunnel.
  • the request carries Terminal_ID, Terminal_appli_ID, UICCJD and UICC_appli_ID.
  • Step 705 After the NAF key center queries the Ks_Local corresponding to the information carried in the request, the Ks_Local and its life cycle are returned to the terminal in the HTTPS tunnel.
  • the terminal and the UICC share the Ks_Local and use the Ks_Local for secure communication.
  • step 701 since the transmission lifetime is unencrypted, the attacker may illegally modify the life cycle when the UICC sends the lifetime of the Ks_Local to the terminal. Therefore, in step 704, in order to ensure that the UICC and the terminal can share the effective After the Ks_Local, the NAF key center queries the Ks_Local, it further verifies the life cycle of the Ks_Local, and determines whether the Ks_Local expires.
  • FIG. 8 is a flowchart of Embodiment 5 of the terminal for acquiring a local interface key according to the present invention, which includes the following steps:
  • Step 800 The terminal initiates a query Ks_Local request to the UICC, where the request carries a Terminal-ID and a Terminal_appli_ID.
  • Step 801 The UICC queries the Ks_Local corresponding to the TerminaUD and the Terminal_appli_ID, and the UICC sends the UICC_ID and the UICC_appli_ID in the query response to the terminal to notify the terminal that the Ks_Local of the terminal query exists in the UICC. It should be noted that if the Ks_Local corresponding to the TerminaUD and the Terminal_appli_ID is not stored in the UICC, the UICC notifies the terminal that there is no Ks_Local, and then the terminal obtains the method shown in the first embodiment, the second embodiment, or the third embodiment. Ks_Local.
  • Step 802 The terminal performs mutual authentication with the NAF and establishes an HTTPS tunnel.
  • Step 803 The terminal requests Ks_Local from the NAF key center in the established HTTPS tunnel.
  • the request carries Terminal_ID, Terminal_appli_ID, UICCJD and UICC_appli_ID.
  • the terminal obtains the Ks_Local by using the method shown in the first embodiment, the second embodiment, or the third embodiment.
  • the terminal and the UICC share the Ks_Local and use the Ks_Local for secure communication.
  • the terminal if the terminal loses Ks_Local due to shutdown, etc., and the Ks_Local is stored in the UICC and the Ks_Local is not expired, the terminal only needs to request the lost key from the NAF key center.
  • the method does not need to perform the entire key negotiation process again, and the method further completes the process of acquiring the Ks_Local, thereby implementing the method for obtaining the local interface key by the invention.
  • a terminal including at least a variable parameter generating module and a sending module, where
  • a variable parameter generation module is configured to generate a variable parameter
  • the sending module is configured to send the generated variable parameters to the UICC or the network side.
  • a UICC is further provided, including at least a first receiving module and a first processing module, where the first receiving module is configured to receive variable parameters from the terminal;
  • the first processing module is configured to derive the local interface key using the received variable parameters.
  • a NAF is further provided, including at least a second receiving module and a second processing module, wherein the second receiving module is configured to receive variable parameters from the terminal;
  • the second processing module is configured to derive the local interface key using the received variable parameters.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Description

生成本地接口密钥的方法及装置 技术领域
本发明涉及通用鉴权框架（GAA )技术领域， 特别是指一种生成本 地接口密钥的方法及装置。 发明背景
在第三代无线通信标准中， GAA是多种应用业务实体使用的一个用 于完成对用户身份进行验证的通用结构， 应用通用鉴权框架可实现对应 用业务的用户进行检查和验证身份。 上述多种应用业务可以是多播或广 播业务、 用户证书业务、 信息即时提供业务等， 也可以是代理业务。
图 la为现有技术通用鉴权框架结构示意图， 如图 la所示， 通用鉴 权框架通常由用户、 执行用户身份初始检查验证的服务功能（BSF ) 实 体、 归属用户服务器（HSS )和网络业务应用 （NAF ) 实体组成。 下文 中将 BSF实体筒称为 BSF, 将 NAF实体筒称为 NAF。 其中， BSF用于 与用户进行互认证， 该互认证过程为互相验证身份， 同时生成 BSF与用 户的共享密钥的过程， 该互认证过程也称为 Bootstrapping过程或 GBA 过程， 称能够与 BSF实现 GBA过程的用户为具备 GBA功能的用户； HSS中存储用于描述用户信息的描述（Profile )文件， 同时 HSS还兼有 产生鉴权信息的功能； NAF可以代表不同的网络业务应用实体， 用户要 实现某种业务时， 必须访问该业务对应的 NAF并与该 NAF进行通信。 各个实体之间的接口如图 la所示， BSF与 NAF之间通过 Zn接口连接； 用户通过用户终端（ UE )与 BSF或 NAF连接， UE与 BSF之间通过 Ub 接口连接， UE与 NAF之间通过 Ua接口连接。 本文中， 可以将 BSF、 NAF及 HSS统一称为网络侧。
用户需要使用某种业务时， 如果用户知道该业务需要到 BSF进行 GBA过程， 则直接到 BSF进行互鉴权， 否则， 用户会首先和该业务对 应的 NAF联系， 如果该 NAF使用 GAA通用鉴权框架， 并且发现该用 户还未到 BSF进行互认证过程， NAF则通知该用户到 BSF进行互鉴权 以验证身份。
用户与 BSF之间的 GBA (互鉴权 ) 的步骤包括： 用户向 BSF发出 鉴权请求； BSF接到鉴权请求后， 首先到 HSS获取该用户的鉴权信息； BSF 获得鉴权信息后与用户进行双向认证以及密钥协商， 完成用户和 BSF之间身份的互相认证及共享密钥 Ks的生成， BSF还为共享密钥 Ks 定义了一个有效期限即生存周期（ Key-lifetime ) ,以便 Ks进行定期更新。 共享密钥 Ks是作为根密钥来使用的， 用于衍生出加密通信的密钥。
之后， BSF分配一个会话事务标识（ B-TID )发送给用户， 该 B-TID 与 Ks相关联， 可以用于标识 Ks, 还包含了 Ks的有效期限。
用户收到 B-TID后， 重新向 NAF发出连接请求， 且请求消息中携 带了该 B-TID, 同时用户侧根据 Ks计算出衍生密钥 Ks_NAF。
NAF收到连接请求后， 先在本地查询是否有用户携带的该 B-TID, 如果 NAF不能在本地查询到该 B-TID, 则向 BSF进行查询， 该查询消 息中携带了 NAF标识（ NAF_ID )和 Β-ΤΠ 如果 BSF不能在本地查询 到该 B-TID, 则通知 NAF没有该用户的信息， 此时， NAF将通知用户 到 BSF重新进行认证鉴权。 BSF查询到该 B-TID后， 使用与用户侧相 同的算法计算出 Ks的衍生密钥 Ks_NAF, 并向 NAF发送成功的响应消 息， 该成功的响应中包括 NAF所需的 B-TID、 与该 B-TID对应的衍生 密钥 Ks_NAF、 以及 BSF为该密钥设置的有效期限。 NAF收到 BSF的 成功响应消息后，就认为该用户是经过 BSF认证的合法用户， 同时 NAF 和用户也就共享了由 Ks衍生的密钥 Ks_NAF。
之后， NAF和用户在后续的通信过程中通过 Ks_NAF来进行加密通 信。
当用户发现 Ks即将过期，或 NAF要求用户重新到 BSF进行鉴权时， 用户就会重复上述的步骤重新到 BSF进行互鉴权，以得到新的共享密钥 Ks及衍生密钥 Ks_NAF。
这里需要说明的是， GBA过程可以分为 GBA_ME过程和 GBAJJ 过程， 对于 GBA_ME过程， 将会产生密钥 Ks_NAF, 该 Ks_NAF存储 于移动设备（ME ) 中； 对于 GBAJJ过程， 将会产生两个密钥， 其中一 个是移动设备中的用户身份模块 UICC的密钥即 Ks_int_NAF,另一个是 ME的密钥即 Ks_ext_NAF。
随着网络技术的发展， 以及市场需求的推动， 网络融合已经成为人 们关注的焦点。 从未来发展的角度来看， 多种网络融合对于用户来说， 可使用任意终端设备如移动台、 PDA (个人数字助理）、 PC (个人电脑)等 通过任意方式接入网络如无线局域网（WLAN )、数字用户线路 （DSL)、 通用分组无线业务（GPRS ) 等， 而且号码可唯一、 帐单可唯一。 这就 意味着一个用户可以具备多种终端设备， 并且这些终端设备共享该用户 的一个用户终端（ UE )对应的用户信息， 如 UE的 UICC ( UICC上可以 为 GSM用户身份模块（ SIM)、 通用用户身份模块（ USIM )等）和 ME 对应的用户信息， 在这种情况下， 这就不仅仅是 UICC或者 ME可以安 全接入网络， 而且还需要保证其它终端设备也要通过 UICC安全的接入 网络。
图 lb是 NAF应用客户端和 GBA客户端分离状态下的 GAA框架示 意图， 某个移动用户具备多个终端设备， 如除了手机以外， 还具备其它 终端设备如 PC机， WLAN UE, 掌上电脑等， 而这些终端设备采用同一 个 UE用户信息访问网络业务， NAF应用客户端并不在 UICC上， 而是 在 UICC 以外的某一个或者某几个外围终端设备上， GBA客户端仍在 UICC上。
基于上述情况， 在终端设备与网络建立安全连接之前， 终端设备必 须获得 UICC中的相关机密信息，从而来保证终端设备能够安全接入网络 或者开展相应的业务， 即终端设备与 UICC间需要传送一些机密信息， 比 如终端设备与网络进行双向认证所需要的 UICC的信息、终端设备开展业 务时需要使用的密钥信息等等。 因此，终端设备与 UICC之间的本地接口 UL0必须提供安全保护， 能够保证终端设备与 UICC之间传送的信息不泄 漏、 不被非法获得。 只有本地接口的安全性得到保护， 整个网络的安全 性才能得以完全保证。
终端设备下文筒称为终端要使用某应用时， 检查到自身不存在与该 应用对应的与 UICC通信所需要的 Ks_Local时，或者终端检查到自身存在 与该应用对应的与 UICC通信所需要的 Ks_Local , 而 UICC中不存在与该 应用对应的 Ks_Local时， 将会发起 Ks_Local协商过程， 图 2是现有技术 UICC与终端之间协商本地接口密钥的流程图， 具体包括以下步骤： 步骤 200: 终端请求 UICC进行一次完整的 GBA过程， 及与 NAF密钥 中心相关的 GB A_U过程， 从而产生相关的密钥资料。
NAF密钥中心是用于协商终端与 UICC间通信密钥的服务器。
本步骤中， 通过 GBA过程及 GBAJJ过程， 协商了终端/ UICC与 BSF 间的共享密钥 Ks , 及保存在 UICC中与 B_TID , NAF标识（ NAF_ID )对 应的密钥 Ks_int_NAF。
步骤 201： 终端向 UICC请求与 GB A过程中生成的 Ks_int_NAF相关的 B_TID。
终端在请求中携带有终端标识（ Terminal_ID )等衍生 Ks_Local所需 相关信息， 如应用的标识等。
步骤 202: UICC利用自身存储的 Ks_int_NAF及接收到的 TerminaUD 等衍生 Ks_Local。
本步骤中， UICC利用 Ks_int_NAF和来自终端的相关信息衍生
Ks_Local, 并且存储该 Ks_Local。
需要说明的是， 本步骤也可以在步骤 210之后执行。
步骤 203: UICC向终端发送与 Ks_int_NAF相关的 B_TID, 还可能包 括 NAF_ID。
步骤 204: 终端与 NAF进行双向认证并建立隧道。 如通过证书方式 等建立基于 TLS的超文本传输协议（HTTPS ) 隧道等， 具体实现属于本 领域技术人员公知技术， 可参见相关资料， 这里不再赘述。
步骤 205: 终端通过建立好的 HTTPS隧道， 向 NAF密钥中心发送本 地密钥建立请求。
该本地密钥建立请求中携带有 TerminaUD和获得的8_丁10, 也可能 携带有 NAF_ID等信息。
步骤 206: NAF向 BSF发送认证请求， 该认证请求中携带有 B_TID和 自身的 NAF_ID。
步骤 207 : BSF向 NAF发送认证响应， 该认证响应中携带有 Ks_int_NAF和相关信息如 Ks_int_NAF的生命周期等信息。
步骤 208： NAF根据 TerminaUD检查该终端可以通过该 UICC接入网 络后， 利用 Ks_int_NAF和相关信息， 采用与 UICC中相同的算法衍生 Ks_Local, 并为该 Ks_Local定义一个生存周期。
步骤 209: NAF通过 HTTPS隧道，将衍生的 Ks_Local及其生存周期发 送给终端。
步骤 210: 终端存储接收到的 Ks_Local及其生存周期。 至此， 终端与 UICC共享了 Ks_Local, 并利用该 Ks_Local进行安全通 信。
现有 UICC与终端间协商 Ks_Local的方法存在的问题是：
Ks_Local是由 Ks_int_NAF衍生的， 在 Ks_int_NAF密钥有效期内， 终 端因与网络侧中断通信如关机等原因造成 Ks— Local丟失时， 如果该终端 再次发起该 Ks_Local所对应的应用， 则将会发起图 2所示整个协商过程。 然而， 在这种情况下， UICC上保存的 Ks以及相关衍生密钥还没有过期， 如果按照图 2所示流程重新协商一个新 Ks_Local,会重新执行一次完整的 GBA过程， 使得已有的 Ks密钥及衍生密钥没有得到充分利用， 造成了过 于繁瑣的过程， 浪费了资源。
现有技术中可以在已有 Ks密钥及衍生密钥有效期内， 允许采用已有 的 Ks密钥及衍生密钥重新衍生 Ksjocal。 也就是在终端与 UICC中的 Ks_Local无效或者即将无效， 但衍生该 Ks_Local的 Ks_int_NAF处于有效 期时， 采用该 Ks_int_NAF重新衍生 Ks_Local。 但是， 由于计算密钥的参 数与协商丟失的 Ks_Local的过程中的参数相同， 所以此次衍生出的 Ksjocal与前一次衍生的 Ks_local相同， 这样的处理在一定程度上降低了 UICC与终端间通信的安全等级。 发明内容
有鉴于此， 本发明实施例的目的在于提供一种生成本地接口密钥的 方法及装置， 能够简单地获取本地接口密钥， 保证 UICC与终端间通信 的安全等级。
为达到上述目的， 本发明实施例的技术方案具体是这样实现的： 一种生成本地接口密钥的方法， 该方法包括以下步骤：
A、 生成可变参数； B、 根据生成的可变参数， 及计算本地接口密钥的相关参数衍生本 地接口密钥。
一种终端， 至少包括可变参数生成模块和发送模块， 其中， 可变参数生成模块用于生成可变参数；
发送模块用于将生成的可变参数发送给 UICC或网络侧。
一种 UICC, 至少包括第一接收模块和第一处理模块， 其中， 第一接收模块用于接收来自终端的可变参数；
第一处理模块用于利用接收到的可变参数衍生本地接口密钥。
一种 NAF, 至少包括第二接收模块和第二处理模块， 其中， 第二接收模块用于接收来自终端的可变参数；
第二处理模块用于利用接收到的可变参数衍生本地接口密钥。
由上述技术方案可见， 本发明方案利用生成可变参数， 并根据生成 的可变参数， 及计算本地接口密钥的相关参数衍生本地接口密钥。 计算 本地接口密钥的相关参数为已知的。 本发明方法筒化了终端获取本地接 口密钥的实现过程，节省了协商 Ks_Local的时间，从而节约了系统资源。 同时， 本发明结合可变参数如随机数或时间戳， 以及有效的密钥信息如 根密钥 Ks、 由 Ks衍生得到的 Ks_int_NAF, 重新衍生以获取本地接口密 钥， 保证了 UICC侧与终端间通信的安全等级。 所述 UICC侧指 UICC 本身和 UICC所属设备。 因此应用本发明方法， 可以使得在 Ks或其衍 生密钥的有效期内可以重用该密钥衍生不同的 Ks_local, 而不必在每次 更新 Ksjocal都去重新执行一次完整的 GBA过程，节省了协商 Ks_Local 的时间， 以及系统资源。 附图简要说明
图 la是 GAA结构示意图; 图 lb是 NAF应用客户端和 GBA客户端分离状态下的 GAA框架示 意图；
图 2是现有技术 UICC与终端之间协商本地接口密钥的流程图； 图 3是本发明终端获取本地接口密钥的流程图；
图 4是本发明终端获取本地接口密钥的实施例一的流程图； 图 5是本发明终端获取本地接口密钥的实施例二的流程图； 图 6是本发明终端获取本地接口密钥的实施例三的流程图； 图 7是本发明终端获取本地接口密钥的实施例四的流程图； 图 8是本发明终端获取本地接口密钥的实施例五的流程图。 实施本发明的方式
本发明实施例的实现是： 生成可变参数， 并根据生成的可变参数， 及计算本地接口密钥的相关参数衍生本地接口密钥。
为使本发明的目的、 技术方案及优点更加清楚明白， 以下参照附图 并举较佳实施例， 对本发明进一步详细说明。
图 3 是本发明终端获取本地接口密钥的流程图， 本发明中的 NAF 密钥中心即为 NAF实体， 当终端使用某应用时， 包括以下步骤：
步骤 300: 终端获取密钥相关信息， 并利用获得的密钥相关信息， 向网络侧请求建立本地接口密钥。
本步骤中终端可以通过向 UICC侧请求， 以获取密钥相关信息， 该 密钥相关信息可以是密钥标识信息如8_ 0, 密钥生命周期等。 这里， UICC侧可以是 UICC本身， 也可以是 UICC所属设备。
步骤 301: 网络侧利用接收到的密钥相关信息查询有效的密钥信息， 利用该密钥信息及产生的可变参数衍生本地接口密钥。
本步骤中， 网络侧查询与接收到的密钥相关信息对应的有效的 Ks_int_NAF或 Ks, 利用一可变参数如随机数或时间戳或者同步计数器 的值， 以及 Ks_int_NAF, 衍生出与前一次衍生的 Ks_local 不相同的 Ks_Local, 或者利用一可变参数如随机数或时间戳， 以及 Ks, 衍生出与 前一次衍生的 Ks_int_NAF不相同的 Ks_int_NAF,再利用该 Ks_int_NAF 衍生 Ks_Local。
步骤 302: 网络侧将衍生的本地接口密钥发送给终端。
在步骤 302之前或之后， 该方法进一步包括， UICC侧自身利用有 效的 Ks_int_NAF和一与网络侧相同的可变参数衍生 Ks_Local并存储， 或者利用有效的 Ks和一与网络侧相同的可变参数， 衍生出与前一次衍 生的 Ks_int_NAF 不相同的 Ks_int_NAF, 再利用该 Ks_int_NAF衍生 Ks_Local。
进一步地， 在步骤 300之前， 终端可以先判断自身是否保存有与当 前要使用的应用对应的 Ks_Local, 若保存有， 则向 UICC侧发送查询请 求， 查看 UICC侧中该 Ks_Local是否有效， 可以在 UICC侧内设置一个 计数器来判断该 Ks_Local是否有效， 如果计数器为 0或者空（ NULL ), 则表示该 Ks_Local无效，返回无效响应，之后终端发起新的密钥协商过 程； 否则， 表示该 Ks_Local有效， 直接应用该 Ks_Local与 UICC侧之 间通信；
若未保存， 则进一步查询 UICC 侧中与当前要使用的应用对应的 Ks_Local是否过期， 若过期， 则执行图 3所示流程； 若未过期， 则终端 直接向 NAF密钥中心请求与当前应用对应的 Ks_Local即可。 需要说明 的是， 即使 UICC中与当前要使用的应用对应的 Ks_Local未过期， 也可 以通过图 3所示的流程来获取新的 Ks_Local。
下面以 UICC侧为 UICC为例， 结合几个实施例描述本发明方法的 具体实现。 实施例一， NAF相关密钥如 Ks_int_NAF有效的情况， 假设可变参 数为随机数 RAND。
图 4是本发明终端获取本地接口密钥的实施例一的流程图， 包括以 下步骤：
步骤 400： 终端向 UICC查询与 GB A过程中生成的与 Ks_int_NAF相关 的8_丁10, 也可以进一步请求本地接口密钥衍生指示。
该查询请求中可能携带有 Terminal_ID、 Terminal_appli_ID、 随机数 RAND全部或者其中之一。
本步骤中， 终端需要生成衍生本地接口密钥所需的随机数 RAND并 存储， 生成的方法属于现有技术， 这里不再赘述。 需要说明的是， 随机 数 RAND还可以单独携带在一条本地密钥衍生指令中发送给 UICC , 即本 地接口密钥衍生指令不在本步骤执行， 而是在其他步骤以一条单独本地 密钥衍生指令形式发送。
需要说明的是， 本步骤之前或者本步骤之后还可能包括终端检查 UICC侧是否存在有效的 Ks的步骤。 如果不存在 Ks或者存在的 Ks已经过 期， 那么需要发起一个完整的 GBA过程， 协商出一个新的 Ks。 此时， 由 于终端可以获得 B-TID信息， 则步骤 400查询 Ks_int_NAF的 B-TID的过程 可以省略， 也可以在要求 UICC计算 Ksjocal之前执行 Ks_int_NAF查询过 程， 以便知道 UICC中是否存有可用的 Ks_int_NAF。
步骤 401： UICC利用 GB A_U过程中生成的 Ks_int_NAF及接收到的随 机数 RAND, 衍生 Ks_Local并存储。
如果 UICC中没有可用的 Ks_int_NAF, 那么需要执行 GBA_U密钥衍 生过程， 该 GBAJJ过程可能在收到本地密钥衍生指令之后， 由 UICC执 行； 也可能在收到本地密钥衍生指令之前， 收到一个 GBAJJ密钥衍生指 令后由 UICC执行。 本步骤可以在步骤 402或者 408之后执行， 此时， 步骤 400中所述本 地密钥衍生指令可以在步骤 402或者 408之后执行， 本步骤之前执行。
步骤 402： UICC将与 GB A过程中生成的 Ks_int_NAF对应的 B_TID , 还可以进一步包括 Ks_int_NAF对应的生存周期发送给终端。
本步骤中， 在 UICC向终端返回 B_TID, 还可以进一步包括生存周期 时， UICC将自身的 UICC标识符 （UICC_ID ) 及 UICC的应用的标识 ( UICC_appli_ID )发送给终端。
本步骤还可以进一步包括： 终端根据 Ks_int_NAF对应的生存周期判 断 Ks_int_NAF是否过期， 若未过期， 则继续执行步骤 403; 若过期， 则 触发 GBA过程， 之后返回步骤 400。
步骤 403 : 终端与 NAF密钥中心进行双向认证并建立安全隧道如 HTTPS隧道。
本步骤具体实现方法很多， 属于现有技术， 这里不再详述。
步骤 404: 终端通过建立好的 HTTPS隧道， 向 NAF密钥中心发送本 地接口密钥建立请求。
该本地密钥建立请求中携带有 Terminal_ID、 Terminal_appli_ID、 获 得的 B_TID、 UICCJD、 UICC_appli_ID以及终端存储的随机数 RAND。 这样， NAF密钥中心可以对于不同的应用产生一个有效的本地接口密 钥。
步骤 405 ~步骤 406: NAF密钥中心查询自身存储的与该8_丁10对应 的有效 Ks_int_NAF , 利用该有效的 Ks_int_NAF及接收到的随机数 RAND 衍生 Ks_Local并分配该 Ks_Local的生存周期。 需要说明的是， 参加衍生 Ks_Local的信息还包括其它相关信息如 Terminal_ID、 Terminal_appli_ID、 UICCJD, UICC_appli_ID等， 具体衍生的算法与本发明无关， 这里不再 详述。 UICC和 NAF密钥中心使用相同的衍生算法衍生 Ks_Local。
本步骤直接利用存储的密钥信息即有效的 Ks_int_NAF衍生 Ks_Local , 筒化了终端获取本地接口密钥的实现过程， 节省了协商 Ks_Local的时间， 从而节约了网络资源。 此外， 本步骤通过使用一随机 数，即使在 Ks_int_NAF相同的情况下，衍生出来的 Ks_Local也是不同的， 保证了终端与 UICC间通信的安全等级。
需要说明的是， 如果 NAF密钥中心不存在该 B_TID对应的 Ks_int_NAF即 Ks_int_NAF无效， 则 NAF密钥中心会向 BSF请求该密钥信 息， 这种情况不属于本发明范畴， 可以参考现有方案， 这里不再赘述。
本步骤中， 在利用该有效的 Ks_int_NAF衍生 Ks_Local之前， 进一步 包括： NAF密钥中心可以通过 Terminal_ID和 UICC_ID, 查询该终端是否 受限利用该 UICC接入网络， 查询方式属于现有技术，可以是在 NAF密钥 中心维护一个数据库，该数据库存储某个 UICC允许被哪些终端使用，或 者存储某个 UICC不允许被哪些终端使用的信息。如果允许该设备接入网 络， 则利用 Ks_int_NAF和相关信息衍生 Ks_Local, 否则， 返回指示该终 端无权利用该 UICC接入网络的响应。
步骤 407: NAF密钥中心通过隧道， 向终端发送本地密钥建立响应， 该响应中携带有 B_TID、 衍生得到的 Ks_Local及其生存周期。
步骤 408： 终端存储接收到的 Ks_Local及其生存周期。
至此， 终端与 UICC就共享了 Ks_Local, 并利用该 Ks_Local进行安全 通信。
实施例二， NAF相关密钥如 Ks_int_NAF有效的情况。
本实施例与实施例一的不同之处在于， 参与衍生 Ksjocal的可变参 数的产生实体不同。 在实施例一中， 可变参数由终端产生。 而本实施例 中， 列举了产生可变参数的两种可能及时机： （1) UICC先于 NAF密钥中 心衍生 Ks_Local时， UICC在衍生 Ks_Local时， 自身产生该可变参数作为 衍生 Ks_Local的参数， 并将该可变参数通过终端传递给 NAF密钥中心， NAF密钥中心也将该可变参数作为衍生 Ks_Local的一个参数， 并采用与 111( (相同的衍生算法生成与 111( (相同的 Ks_Local。 (2) NAF密钥中心先 于 UICC衍生 Ks_Local时， NAF密钥中心在衍生 Ks_Local时， 自身产生该 可变参数作为衍生 Ks_Local的参数， 并将该可变参数通过终端传递给 UICC, UICC也将该可变参数作为衍生 Ks_Local的一个参数， 并采用与 NAF密钥中心相同的衍生算法生成与 NAF密钥中心相同的 Ks_Local; 可 变参数也可能是 BSF计算 Ks_int_NAF时生成后通过终端传递给 UICC的， UICC利用自身保存有的 Ks及接收到的可变参数衍生 Ks_int_NAF, 并在 收到衍生本地接口密钥请求时， 利用该 Ks_int_NAF衍生 Ks_local。
图 5是本发明终端获取本地接口密钥的实施例二的流程图， 实施例 二中以 NAF密钥中心先于 UICC衍生 Ks_Local为例， 具体描述实现方法， 包括以下步骤：
步骤 500： 终端向 UICC请求与 GB A过程中生成的与 Ks_int_NAF相关 的 B_TID及密钥生存周期， 该请求中可以携带 TerminaUD 、 Terminal_appli_ID。
需要说明的是， 本步骤之前或者本步骤之后还可能包括终端检查 UICC侧是否存在有效的 Ks的步骤。 如果不存在 Ks或者存在的 Ks已经过 期， 那么需要发起一个完整的 GBA过程， 协商出一个新的 Ks。 此时， 由 于终端可以获得 B-TID信息，则步骤 500, 501中查寻 Ks_int_NAF的 B-TID 的过程可以省略， 也可以在要求 UICC计算 Ksjocal之前执行 Ks_int_NAF 查询过程， 以便知道 UICC中是否存有可用的 Ks_int_NAF。
步骤 501： UICC将与 GB A过程中生成的 Ks_int_NAF对应的 B_TID及 生存周期等信息发送给终端。 本步骤中， 在 UICC向终端返回8_丁10及 Ks_int_NAF的生存周期时， UICC将自身的 UICC_ID及 UICC_appli_ID发送给终端。
步骤 502： 终端与 NAF进行双向认证并建立 HTTPS隧道。
本步骤具体实现方法很多， 属于现有技术， 这里不再详述。
步骤 503: 终端通过建立好的 HTTPS隧道， 向 NAF密钥中心发送本 地密钥建立请求。
该本地密钥建立请求中携带有 Terminal_ID、 Terminal_appli_ID、 获 得的 B_TID、 UICC_ID以及 UICC_appi_ID。 这样， NAF密钥中心可以对 于不同的应用产生一个有效的本地接口密钥。
步骤 504 ~步骤 505: NAF密钥中心查询自身存储的与该 B_TID对应 的有效 Ks_int_NAF、 生成一随机数 RAND, 利用该有效的 Ks_int_NAF及 生成的随机数 RAND衍生 Ks_Local并分配该 Ks_Local的生存周期。
本步骤中， NAF密钥中心生成随机数 RAND并存储，该随机数 RAND 的生成的方法属于现有技术， 这里不再赘述。
本步骤直接利用存储的密钥信息即有效的 Ks_int_NAF衍生 Ks_Local , 筒化了终端获取本地接口密钥的实现过程， 节省了协商 Ks_Local的时间， 从而节约了网络资源。 此外， 本步骤通过使用一随机 数，即使在 Ks_int_NAF相同的情况下，衍生出来的 Ks_Local也是不同的， 保证了终端与 UICC间通信的安全等级。
需要说明的是， 如果 NAF密钥中心不存在该 B_TID对应的 Ks_int_NAF或 Ks_int_NAF无效， 则 NAF密钥中心会向 BSF请求该密钥信 息， 这种情况不属于本发明范畴， 可以参考现有方案， 这里不再赘述。
本步骤中， 在利用该有效的 Ks_int_NAF衍生 Ks_Local之前， 进一步 包括： NAF密钥中心可以通过 Terminal_ID和 UICC_ID, 查询该终端是否 受限利用该 UICC接入网络。 如果允许该设备接入网络， 则利用 Ks_int_NAF和相关信息衍生 Ks_Local, 否则， 返回指示该终端无权利用 该 UICC接入网络的的响应。
步骤 506: NAF密钥中心通过 HTTPS隧道， 向终端发送本地密钥建 立响应， 该响应中携带有8_丁10、 NAF密钥中心自身存储有的随机数 RAND, 衍生得到的 Ks_Local及其生存周期。
步骤 507： 终端存储接收到的 Ks_Local及其生存周期。
步骤 508 : 终端向 UICC发送生成 Ks_Local请求， 该请求中携带有 Terminal_ID、 Terminal_appli_ID以及来自 NAF密钥中心的随机数 RAND。
步骤 509： UICC利用 GB A_U过程中生成的有效的 Ks_int_NAF及接收 到的随机数 RAND , 衍生 Ks_Local并存储。
UICC和 NAF密钥中心使用相同的衍生算法衍生 Ks_Local。
需要说明的是， GBAJJ过程可以在本步骤中执行，也可以在步骤 508 之前的任何步骤执行。
至此， 终端与 UICC就共享了 Ks_Local, 并利用该 Ks_Local进行安全 通信。
需要说明的是，图 5所示流程中计算本地接口密钥的可变参数 RAND 也可以由 UICC或终端生成。 若是由 UICC生成可变参数 RAND, 那么步 骤 508和步骤 509可在步骤 502之前执行， 并在执行成功后 UICC向终端发 送 UICC生成的 RAND值。 终端在步骤 503中将该 RAND值发给网络侧， 以便网络侧采用相同的 RAND值计算本地密钥。
若是由终端生成可变参数 RAND值， 那么如实施例一所述， 以上步 骤即可以按照实施例 5的顺序执行， 又可以将步骤 508和步骤 509放在步 骤 502之前， 或者与 502~507同时执行。 当然在步骤 503中需要将终端产 生的 RAND值发给网络侧， 以便网络侧采用相同的 RAND值计算本地密 钥。 实施例三， NAF相关密钥 Ks_int_NAF无效且 Ks有效的情况。
图 6是本发明终端获取本地接口密钥的实施例三的流程图， 包括以 下步骤：
步骤 600 : 终端向 UICC请求 Ks相关信息， 该请求中可以携带 Terminal_ID、 Terminal_appli_ID , 还可以携带终端表示当前时间值的时 步骤 601 : UICC查找本地存在的 Ks , 并将该 Ks对应的生存周期及 B-TID返回给终端。
如果来自终端的请求中携带有时间戳， UICC可根据该时间戳查询本 地是否存在有效的的 Ks, 如果存在， 则将该 Ks对应的生存周期及 B_TID 发送给终端， 进入步骤 603, 否则， 进入步骤 602。
UICC对比时间戳和生存周期， 判断该 Ks的有效性， 若生存周期大 于时间戳则表示有效； 否则， 表示无效。
步骤 602: 发起 GBA过程， 以产生一个有效的 Ks。
本步骤中 GBA过程的触发可能有多种情况： 如果终端就是 UICC所 属 ME, 那么直接由 ME发起 GBA过程； 如果终端是一个通过外部接口连 接到 UICC上的外围终端， 那么可能是由外围终端向 UICC发指令， 然后 UICC向 ME发主动式命令触发 GBA过程， 或者 UICC发现没有有效的 Ks 后， 向 ME发主动式命令触发 GBA过程， 或者外围终端直接向 ME发命令 触发 GBA过程； 之外， 也有可能就是终端自身发起 GBA过程。
GBA过程的目的就是为了产生一个 Ks, 存储在 UICC中。
步骤 603： 终端与 NAF进行双向认证并建立 HTTPS隧道。
本步骤具体实现方法很多， 属于现有技术， 这里不再详述。
步骤 604: 终端通过建立好的 HTTPS隧道， 向 NAF密钥中心发送本 地密钥建立请求。 该本地密钥建立请求中携带有步骤 602中 GBA过程产生的或 UICC 返回给终端的 B_TID, 以及 Terminal_ID、 Terminal_appli_ID、 UICC_ID、 UICC_appi_ID, 以及可能携带终端或 UICC生成的随机数 RAND。 这样， NAF密钥中心可以对于不同的应用产生一个有效的本地接口密钥。
步骤 605: NAF密钥中心向 BSF请求 Ks_int_NAF,该请求中可能携带 有接收到的 B_TID和随机数 RAND , 以及自身的 NAF_ID。 其中随机数可 能是步骤 604中终端发来的， 还可能是 NAF密钥中心生成的。
步骤 606: BSF利用 B_TID对应的 Ks、 NAF_ID、 随机数 RAND等参 数衍生 Ks_int_NAF并分配该 Ks_int_NAF对应的生存周期， 将该 Ks_int_NAF及其生存周期发送给 NAF密钥中心。
本步骤中， 利用该随机数 RAND , 使得由 Ks衍生的 Ks_int_NAF与前 一次使用的 Ks_int_NAF不同。
步骤 607: NAF密钥中心利用接收到的 Ks_int_NAF衍生 Ks_Local。 本步骤中， NAF密钥中心在利用该有效的 Ks_int_NAF衍生 Ks_Local 之前， 进一步包括： NAF密钥中心可以通过 TerminaUD和 UICC_ID, 查 询该终端是否受限利用该 UICC接入网络。如果允许该设备接入网络， 则 利用 Ks_int_NAF和相关信息衍生 Ks_Local, 否则， 返回指示该终端无权 利用该 UICC接入网络的响应。
步骤 608: NAF密钥中心通过 HTTPS隧道， 向终端发送本地密钥建 立响应， 该响应中携带有8_ 0、 Ks_Local及其生存周期。
步骤 609: 终端存储接收到的 Ks_Local及其生存周期。
步骤 610: 终端向 UICC发送生成 Ks_Local请求， 该请求中携带有 Terminal—ID、 Terminal_appli_ID。
步骤 611 : UICC首先利用 Ks和 NAF_ID、 随机数 RAND等参数衍生 Ks_int_NAF, 之后再利用该 Ks_int_NAF衍生 Ks_Local并存储。 UICC和 NAF密钥中心使用相同的衍生算法衍生 Ks_Local。
需要说明的是， 如果随机数 RAND是由终端或 UICC生成， 那么步骤 610 ~611中 UICC利用 Ks、 NAF_ID、随机数 RAND等参数衍生 Ks_int_NAF 的步骤也可在步骤 610之前步骤 602之后任何一步执行。 本实施例流程只 是其中一种，并不限制终端和 UICC交互，与终端、与网络侧交互的顺序。
至此， 终端与 UICC就共享了 Ks_Local, 并利用该 Ks_Local进行安全 通信。
从上述实施例一、 实施例二和实施例三可见， 实施例一和实施例二 获取 Ks_Local的方法为： 利用一可变参数如随机数或时间戳， 以及密钥 信息中的有效 Ks_int_NAF , 衍生出与前一次衍生的 Ksjocal不相同的 Ks_Local, 而实施例三获取 Ks_Local的方法为： 利用一可变参数如随机 数或时间戳， 以及密钥信息中的 Ks, 衍生出与前一次衍生的 Ks_int_NAF 不相同的 Ks_int_NAF, 再利用该 Ks_int_NAF衍生 Ks_Local。
需要说明的是， UICC侧和 BSF利用可变参数以及 Ks计算 Ks_int_NAF 的可变参数， 除了本实施例中所述终端产生， 还可以由 NAF密钥中心产 生， 并携带在步骤 605中的请求消息中发给 BSF, 随后通过步骤 608、 步 骤 609、 步骤 610发给 UICC侧； 还可以由 BSF在步骤 606产生， 并通过后 续步骤发给 UICC侧。
以上实施例中，不需要执行完整的 GBA过程，筒化了获取 Ks_Local 的流程， 筒单地获取了本地接口密钥， 节省了协商 Ks_Local的时间， 从 而节约了网络资源； 同时， 通过可变参数参与衍生而获得的 Ks_Local 与前一次使用的 Ks_Local是不同的，保证了 UICC与终端间通信的安全 等级。
需要说明的是， 在执行实施例一和实施例二之前， 还可以增加实施 例三中的步骤 600 ~步骤 602 , 此时， 实施例一中的步骤 400 ~步骤 401 可以省略， 实施例二中的步骤 500 ~步骤 501可以省略。
除此之外， 对于终端由于关机等操作而造成未过期的 Ks_Local丟失 的情况， 在终端需要使用某应用时， 除了可以采用上述实施例一至实施 例三的方法获取 Ks_Local外， 还可以通过与 UICC的交互， 获取与 Ks_Local相关的信息如8_丁10和应用相关标识， 并利用获得的相关信息 直接向 NAF密钥中心请求与该8_丁10对应的 Ks_Local即可。 下面结合实 施例四和实施例五详细描述实现方法。
实施例四， UICC中存在 Ks_Local且未过期的情况。
图 7是本发明终端获取本地接口密钥的实施例四的流程图， 包括以 下步骤：
步骤 700 : 终端向 UICC发起查询 Ks_Local请求， 该请求中携带有 Terminal—ID和 Terminal_appli_ID。
步骤 701 : UICC查询自身存储的，与 Terminal_ID和 Terminal_appli_ID 对应的 Ks_Local, 则 UICC将该 Ks_Local的生存周期携带在查询响应中发 送给终端。 该查询响应中还携带有 UICC_ID和 UICC_appli_ID。
需要说明 的是， 如果 UICC 中 未存储与 TerminaUD和 Terminal_appli_ID对应的 Ks_Local,则 UICC会通知终端不存在 Ks_Local, 之后终端会采用实施例一、 或实施例二、 或实施例三所示的方法来获取 Ks_Local。
步骤 702: 终端根据接收到的 Ks_Local的生存周期，及终端自身的时 间机制， 确定该 Ks_Local未过期后， 向 NAF密钥中心请求该 Ks_Local。
需要说明的是， 如果该 Ks_Local已过期， 则终端会采用实施例一、 或实施例二、 或实施例三所示的方法来获取 Ks_Local。
只要终端确定该 Ks_Local已过期， 那么， 终端向 UICC发送删除旧的 Ks_Local以及发起建立新的 Ks_Local的请求。 删除旧的 Ks_Local以及发 起建立新的 Ks_Local两个请求， 可以作为一条消息发送， 也可以分两条 发送； 或者， 终端只向 UICC发送删除旧的 Ks_Local的请求； 或者终端只 向 UICC发送建立新的 Ks_Local的请求。
步骤 703： 终端与 NAF进行双向认证并建立 HTTPS隧道。
本步骤具体实现方法很多， 属于现有技术， 这里不再详述。
步骤 704: 终端通过建立好的 HTTPS隧道， 向 NAF密钥中心请求 Ks_Local。 该请求中携带有 Terminal_ID、 Terminal_appli_ID , UICCJD 及 UICC_appli_ID。
步骤 705： NAF密钥中心查询到与请求中携带的信息对应的 Ks_Local 后， 在 HTTPS隧道中， 将该 Ks_Local及其生存周期返回给终端。
至此， 终端与 UICC就共享了 Ks_Local, 并利用该 Ks_Local进行安全 通信。
在步骤 701中， 由于传输生存周期是未加密的， UICC在向终端发送 Ks_Local的生存周期时， 攻击者可能非法修改该生存周期， 因此， 在步 骤 704中， 为了确保 UICC与终端能够共享有效的 Ks_Local, NAF密钥中 心在查询到该 Ks_Local后， 进一步对该 Ks_Local的生存周期进行验证， 判断该 Ks_Local是否过期。
实施例五， UICC中存在 Ks_Local且未过期的情况。
图 8是本发明终端获取本地接口密钥的实施例五的流程图， 包括以 下步骤：
步骤 800: 终端向 UICC发起查询 Ks_Local请求， 该请求中携带有 Terminal—ID和 Terminal_appli_ID。
步骤 801 : UICC查询自身存储的，与 TerminaUD和 Terminal_appli_ID 对应的 Ks_Local, 则 UICC将自身 UICC_ID和 UICC_appli_ID携带在查询 响应中发送给终端， 以告知终端， UICC中存在终端查询的 Ks_Local。 需要说明 的是， 如果 UICC 中 未存储与 TerminaUD和 Terminal_appli_ID对应的 Ks_Local,则 UICC会通知终端不存在 Ks_Local, 之后终端会采用实施例一、 或实施例二、 或实施例三所示的方法来获取 Ks_Local。
步骤 802: 终端与 NAF进行双向认证并建立 HTTPS隧道。
本步骤具体实现方法很多， 属于现有技术， 这里不再详述。
步骤 803 : 终端在建立好的 HTTPS隧道中， 向 NAF密钥中心请求 Ks_Local。 该请求中携带有 Terminal_ID、 Terminal_appli_ID , UICCJD 及 UICC_appli_ID。
步骤 804 ~ 步骤 805： NAF密钥 中心查询到与接收到的 Terminal_appli_ID对应的 Ks_Local , 并确定该 Ks_Local未过期后， NAF 密钥密钥中心通过 HTTPS隧道，将该 Ks_Local及其生存周期返回给终端。
需要说明的是， 如果该 Ks_Local已过期， 则终端会采用实施例一、 或实施例二、 或实施例三所示的方法来获取 Ks_Local。
至此， 终端与 UICC就共享了 Ks_Local, 并利用该 Ks_Local进行安全 通信。
从实施例四和实施例五可见， 如果终端因关机等原因造成 Ks_Local 丟失， 而 UICC内还存储有该 Ks_Local且该 Ks_Local未过期时， 终端只需 向 NAF密钥中心请求丟失的密钥即可， 而不需要再次进行整个密钥协商 过程， 该方法更进一步的筒化了获取 Ks_Local的流程， 从而实现了本发 明筒单获取本地接口密钥的方法。
结合本发明方法， 还提供一种终端， 至少包括可变参数生成模块和 发送模块， 其中，
可变参数生成模块用于生成可变参数；
发送模块用于将生成的可变参数发送给 UICC或网络侧。 还提供一种 UICC, 至少包括第一接收模块和第一处理模块， 其中， 第一接收模块用于接收来自终端的可变参数；
第一处理模块用于利用接收到的可变参数衍生本地接口密钥。
还提供一种 NAF, 至少包括第二接收模块和第二处理模块， 其中， 第二接收模块用于接收来自终端的可变参数；
第二处理模块用于利用接收到的可变参数衍生本地接口密钥。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的 保护范围， 凡在本发明的精神和原则之内所做的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种生成本地接口密钥的方法， 其特征在于， 该方法包括以下 步骤：
A、 生成可变参数；
B、 根据生成的可变参数， 及计算本地接口密钥的相关参数衍生本 地接口密钥。
2、 根据权利要求 1 所述的方法， 其特征在于， 所述可变参数由终 端生成， 所述本地接口密钥由用户集成电路卡 UICC侧衍生， 所述步骤 B具体包括：
UICC侧收到终端发送的所述可变参数；
UICC侧根据所述可变参数及计算本地接口密钥的相关参数衍生所 述本地接口密钥。
3、 根据权利要求 1 所述的方法， 其特征在于， 所述可变参数由终 端生成， 所述本地接口密钥由网络侧衍生， 所述步骤 B具体包括： 网络侧收到终端发送的所述可变参数以及从 UICC侧获取的密钥标 识信息；
网络侧根据所述可变参数、 密钥标识信息及计算本地接口密钥的相 关参数衍生所述本地接口密钥。
4、根据权利要求 1所述的方法，其特征在于，所述可变参数由 UICC 侧生成， 所述本地接口密钥由 UICC侧衍生， 所述步骤 B具体包括：
UICC侧根据所述可变参数及计算本地接口密钥的相关参数衍生所 述本地接口密钥。
5、根据权利要求 1所述的方法，其特征在于，所述可变参数由 UICC 侧生成， 所述本地接口密钥由网络侧衍生， 所述步骤 B具体包括： 网络侧收到终端发送的从 UICC侧获取的密钥标识信息以及可变参 数；
网络侧根据所述可变参数、 密钥标识信息及计算本地接口密钥的相 关参数衍生所述本地接口密钥。
6、 根据权利要求 1 所述的方法， 其特征在于， 所述可变参数由网 络侧生成， 所述本地接口密钥由 UICC侧衍生， 所述步骤 B具体包括： 所述 UICC侧收到终端发送的从网络侧获取的所述可变参数； 所述 UICC侧根据所述可变参数及计算本地接口密钥的相关参数衍 生所述本地接口密钥。
7、 根据权利要求 1 所述的方法， 其特征在于， 所述可变参数由网 络侧生成， 所述本地接口密钥由网络侧衍生， 所述步骤 B具体包括： 所述网络侧收到终端发送的从 UICC侧获取的密钥标识信息； 网络侧根据所述可变参数、 密钥标识信息及计算本地接口密钥的相 关参数衍生所述本地接口密钥。
8、 根据权利要求 7 所述的方法， 其特征在于： 所述网络侧衍生本 地接口密钥具体包括：
所述网络侧中的 BSF根据 Ks以及所述可变参数衍生 NAF相关密 钥， 所述 Ks为 UICC用户和 BSF之间的共享密钥；
根据所述 NAF相关密钥及计算本地接口密钥 Ks_local的相关参数 衍生本地接口密钥。
9、 根据权利要求 7 所述的方法， 其特征在于： 所述网络侧衍生本 地接口密钥具体包括：
所述网络侧中的 BSF根据 Ks衍生 NAF相关密钥，所述 Ks为 UICC 用户和 BSF之间的共享密钥；
根据所述 NAF 相关密钥、 所述可变参数及计算本地接口密钥 Ksjocal的相关参数衍生本地接口密钥。
10、 根据权利要求 7、 8或 9所述的方法。 其特征在于， 所述可变 参数由所述网络侧中的通用自引导鉴权框架服务功能实体 BSF或网络 应用功能实体 NAF生成。
11、 根据权利要求 10所述的方法， 其特征在于， 若所述生成可变 参数由所述网络侧中的通用自引导鉴权框架服务功能实体 BSF生成，所 述网络侧衍生本地接口密钥具体包括：
所述网络侧中的网络应用功能实体 NAF将从所述终端获得的密钥 标识信息发送至 BSF;
BSF根据 Ks、 获得的密钥标识信息及所述可变参数衍生 NAF相关 密钥， 并发送至 NAF, 所述 Ks为 UICC用户和 BSF之间的共享密钥；
NAF根据获得的 NAF相关密钥及计算本地接口密钥的相关参数衍 生所述本地接口密钥。
12、 根据权利要求 10所述的方法， 其特征在于， 若所述可变参数 由所述网络侧中的 NAF生成， 所述网络侧衍生本地接口密钥的步骤具 体包括：
NAF根据该可变参数及计算本地接口密钥 Ks_local的相关参数衍生 所述本地接口密钥。
13、 根据权利要求 12所述的方法， 其特征在于， 所述 NAF根据所 述可变参数及计算本地接口密钥 Ks_local的相关参数衍生所述本地接口 密钥之前， 还包括：
所述 NAF将从所述终端获得的密钥标识信息发送至所述网络侧中 的 BSF;
BSF根据 Ks、 获得的密钥标识信息衍生 NAF相关密钥， 并发送至 NAF, 所述 Ks为 UICC用户和 BSF之间的共享密钥。
14、 根据权利要求 2 ~ 9 中任意一项所述方法， 其特征在于， 所述 UICC侧为用户身份模块 UICC , 或者 UICC所属设备。
15、 一种终端， 其特征在于， 至少包括可变参数生成模块和发送 模块， 其中，
可变参数生成模块用于生成可变参数；
发送模块用于将生成的可变参数发送给 UICC或网络侧。
16、 一种 UICC, 至少包括第一接收模块和第一处理模块， 其中， 第一接收模块用于接收来自终端的可变参数；
第一处理模块用于利用接收到的可变参数衍生本地接口密钥。
17、 一种 NAF, 至少包括第二接收模块和第二处理模块， 其中，
PCT/CN2007/070025 2006-07-04 2007-05-17 Procédé et dispositif de dérivation d'une clé interface locale WO2008006306A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN2007800003031A CN101317359B (zh) 2006-07-04 2007-05-17 生成本地接口密钥的方法及装置
EP07721648.9A EP2037621B1 (en) 2006-07-04 2007-05-17 Method and device for deriving local interface key
US12/348,534 US8559633B2 (en) 2006-07-04 2009-01-05 Method and device for generating local interface key
US14/013,912 US9467432B2 (en) 2006-07-04 2013-08-29 Method and device for generating local interface key

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNA2006100984222A CN101102190A (zh) 2006-07-04 2006-07-04 生成本地接口密钥的方法
CN200610098422.2 2006-07-04

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/348,534 Continuation US8559633B2 (en) 2006-07-04 2009-01-05 Method and device for generating local interface key

Publications (1)

Publication Number Publication Date
WO2008006306A1 true WO2008006306A1 (fr) 2008-01-17

Family

ID=38922936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/070025 WO2008006306A1 (fr) 2006-07-04 2007-05-17 Procédé et dispositif de dérivation d'une clé interface locale

Country Status (4)

Country Link
US (2) US8559633B2 (zh)
EP (1) EP2037621B1 (zh)
CN (2) CN101102190A (zh)
WO (1) WO2008006306A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113543124A (zh) * 2020-04-14 2021-10-22 中国电信股份有限公司 密钥分发方法、系统和卡应用

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2210436A1 (en) 2007-10-05 2010-07-28 InterDigital Technology Corporation Techniques for secure channelization between uicc and a terminal
KR20120005050A (ko) * 2008-04-07 2012-01-13 인터디지탈 패튼 홀딩스, 인크 보안 세션 키 발생
CN101572694B (zh) * 2008-04-29 2012-09-05 华为技术有限公司 媒体流密钥的获取方法、会话设备与密钥管理功能实体
CN102625302B (zh) 2008-06-23 2016-03-30 华为技术有限公司 密钥衍生方法、设备及系统
EP2580701A4 (en) * 2010-06-10 2016-08-17 Ericsson Telefon Ab L M USER EQUIPMENT AND ITS CONTROL METHOD
JP5803112B2 (ja) * 2011-01-14 2015-11-04 ソニー株式会社 無線端末装置、情報処理装置、通信システムおよび無線端末装置の制御方法
CN102917351B (zh) * 2011-08-05 2015-04-01 中国移动通信集团公司 在用户识别卡中实现应用的方法、装置以及用户识别卡
CN102932784B (zh) * 2011-08-12 2015-12-02 华为技术有限公司 终端的通信方法和设备
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US9100175B2 (en) 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US9036820B2 (en) * 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US10498530B2 (en) 2013-09-27 2019-12-03 Network-1 Technologies, Inc. Secure PKI communications for “machine-to-machine” modules, including key derivation by modules and authenticating public keys
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US10700856B2 (en) 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
US9853977B1 (en) 2015-01-26 2017-12-26 Winklevoss Ip, Llc System, method, and program product for processing secure transactions within a cloud computing system
WO2016153977A1 (en) 2015-03-22 2016-09-29 Apple Inc. Methods and apparatus for user authentication and human intent verification in mobile devices
US11080414B2 (en) * 2015-05-22 2021-08-03 Huawei Device Co., Ltd. Cryptographic unit for public key infrastructure (PKI) operations
US10172000B2 (en) * 2016-03-17 2019-01-01 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10158991B2 (en) * 2016-03-17 2018-12-18 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
CN106888092B (zh) * 2016-09-12 2019-06-25 中国移动通信有限公司研究院 信息处理方法及装置
CN113015159B (zh) * 2019-12-03 2023-05-09 中国移动通信有限公司研究院 初始安全配置方法、安全模块及终端
CN115362656A (zh) * 2020-04-03 2022-11-18 苹果公司 应用功能密钥派生和刷新

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6198823B1 (en) * 1998-03-24 2001-03-06 Dsc Telecom, L.P. Method for improved authentication for cellular phone transmissions
CN1444755A (zh) * 2000-05-26 2003-09-24 格姆普拉斯公司 使控制器之间的数据交换安全
CN1456993A (zh) * 2003-05-30 2003-11-19 武汉理工大学 一种用户计算机之间交换密钥的方法
US20040102181A1 (en) * 2000-11-27 2004-05-27 Gunther Horn Method and apparatus to counter the rogue shell threat by means of local key derivation

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7151830B2 (en) * 2002-12-24 2006-12-19 International Business Machines Corporation Method, system, program product and state machine representation for encrypting and decrypting a message
WO2006084183A1 (en) * 2005-02-04 2006-08-10 Qualcomm Incorporated Secure bootstrapping for wireless communications
US20060206710A1 (en) * 2005-03-11 2006-09-14 Christian Gehrmann Network assisted terminal to SIM/UICC key establishment
US20060291660A1 (en) * 2005-12-21 2006-12-28 Telefonaktiebolaget Lm Ericsson (Publ) SIM UICC based broadcast protection
US20070101122A1 (en) * 2005-09-23 2007-05-03 Yile Guo Method and apparatus for securely generating application session keys

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6198823B1 (en) * 1998-03-24 2001-03-06 Dsc Telecom, L.P. Method for improved authentication for cellular phone transmissions
CN1444755A (zh) * 2000-05-26 2003-09-24 格姆普拉斯公司 使控制器之间的数据交换安全
US20040102181A1 (en) * 2000-11-27 2004-05-27 Gunther Horn Method and apparatus to counter the rogue shell threat by means of local key derivation
CN1456993A (zh) * 2003-05-30 2003-11-19 武汉理工大学 一种用户计算机之间交换密钥的方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
3GPP: "Generic bootstrapping architecture (Release 7)", 3GPP TS 33.220 V7.4.0, June 2006 (2006-06-01), pages 27 - 32, 35, 40 - 41, XP008104574 *
See also references of EP2037621A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113543124A (zh) * 2020-04-14 2021-10-22 中国电信股份有限公司 密钥分发方法、系统和卡应用

Also Published As

Publication number Publication date
EP2037621B1 (en) 2020-08-26
US9467432B2 (en) 2016-10-11
CN101317359A (zh) 2008-12-03
EP2037621A1 (en) 2009-03-18
CN101317359B (zh) 2012-02-01
EP2037621A4 (en) 2009-08-12
CN101102190A (zh) 2008-01-09
US8559633B2 (en) 2013-10-15
US20090116642A1 (en) 2009-05-07
US20140007207A1 (en) 2014-01-02

Similar Documents

Publication Publication Date Title
WO2008006306A1 (fr) Procédé et dispositif de dérivation d'une clé interface locale
US20200195445A1 (en) Registration method and apparatus based on service-based architecture
US8275355B2 (en) Method for roaming user to establish security association with visited network application server
RU2414086C2 (ru) Аутентификация приложения
US7941121B2 (en) Method for verifying the validity of a user
US8312278B2 (en) Access authentication method applying to IBSS network
CN101156352B (zh) 基于移动网络端到端通信的认证方法、系统及认证中心
WO2007085175A1 (fr) Procédé, système d'authentification et centre d'authentification reposant sur des communications de bout en bout dans le réseau mobile
WO2007022731A1 (fr) Procede, systeme et equipement de negociation de cle de cryptage dans une trame de verification universelle amelioree
EP1933498B1 (en) Method, system and device for negotiating about cipher key shared by ue and external equipment
EP1705828B1 (en) A method of obtaining the user identification for the network application entity
TW201244437A (en) Secure bootstrapping for wireless communications
WO2006097041A1 (fr) Forme d'authentification generale et procede pour mettre en place l'authentification
WO2008006312A1 (en) A realizing method for push service of gaa and a device
WO2010091563A1 (zh) Wapi终端证书的管理方法、装置及系统
WO2012094879A1 (zh) 一种mtc服务器共享密钥的方法及系统
WO2009074050A1 (fr) Procede, systeme et appareil d'authentification de dispositif de point d'acces
WO2012075814A1 (zh) 一种mtc组设备的应用密钥管理方法及系统
WO2007104248A1 (en) Method, system, apparatus and bsf entity for preventing bsf entity from attack
WO2008098510A1 (fr) Procédé et appareil d'acquisition d'informations de contrôleur d'accès dans un réseau local sans fil
WO2007147354A1 (fr) Procédé et système pour extraire une clé de messagerie instantanée
CN213938340U (zh) 5g应用接入认证网络架构
CN102694779B (zh) 组合认证系统及认证方法
WO2007025484A1 (fr) Procede de negociation de mise a jour pour cle d'autorisation et dispositif associe
WO2012000313A1 (zh) 一种家庭网关认证方法和系统

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780000303.1

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07721648

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007721648

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: RU