WO2007079698A1 - Procédé et système d'authentification d'entité, procédé et système d'authentification de bout en bout et centre d'authentification - Google Patents

Procédé et système d'authentification d'entité, procédé et système d'authentification de bout en bout et centre d'authentification Download PDF

Info

Publication number
WO2007079698A1
WO2007079698A1 PCT/CN2007/000141 CN2007000141W WO2007079698A1 WO 2007079698 A1 WO2007079698 A1 WO 2007079698A1 CN 2007000141 W CN2007000141 W CN 2007000141W WO 2007079698 A1 WO2007079698 A1 WO 2007079698A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
entity
security level
eac
authentication
Prior art date
Application number
PCT/CN2007/000141
Other languages
English (en)
French (fr)
Inventor
Yanmei Yang
Jiwei Wei
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 WO2007079698A1 publication Critical patent/WO2007079698A1/zh

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security

Definitions

  • Entity authentication method and system end-to-end authentication method and system, certification center
  • the present invention relates to a general authentication technology, and more particularly to a method and system for entity authentication, a method and system for end-to-end authentication, and an Entity Authentication Center (EAC).
  • EAC Entity Authentication Center
  • FIG. 1 is a schematic diagram of a prior art end-to-end communication authentication architecture. As shown in FIG. 1, the architecture is applicable to different mobile network standards, and its role is to establish mutual trust relationships between different types of entities, which is a true sense. Universal authentication framework.
  • the network element involved in the authentication architecture shown in Figure 1 is divided into three business entities: Service Subscriber (SS), Service Subscriber and Provider (SSP), Service Provider (SP), Service Provider (SP).
  • SSP Service Subscriber
  • SP Service Provider
  • SP Service Provider
  • EAC Entity Subscription Database
  • ESD Entity Subscription Database
  • the service entity is a general term for the service provider entity and the service request entity, including SS, SSP, and SP.
  • the SS can only apply for services, which are generally ordinary mobile users;
  • the SSP can be an ordinary mobile user or a third-party application server (AS, Application Server);
  • the SP is the AS of the carrier network or the SP of the external network;
  • EAC It is used to complete the negotiation and authentication process of the authentication method with other service entities, and accepts the query of the authentication status of other service entities by a certain service entity;
  • the ESD is used to store the subscription information of the business entity, and the subscription information may include the service contracted by the business entity.
  • the service providing entity provides services to other business entities, or the service requesting entity requests services from other business entities, it should first have a contractual relationship with the network and store the contract information in the ESD; and each business entity in the network Before communicating with other business entities, you need to negotiate the authentication method with the EAC and complete the authentication process for the identity.
  • the negotiation process of the authentication mode is initiated by the service entity, and the service entity carries its own identity identifier in the authentication request message and sends it to the EAC.
  • the EAC selects an authentication mode according to the local preset policy and the subscription information of the service entity, and returns the authentication mode and related authentication information to the service entity that initiates the authentication request.
  • the service entity sends an acknowledgement message to the EAC to indicate that the negotiation process ends.
  • the business entity and the EAC are authenticated according to the negotiated authentication method.
  • the authentication is bidirectional.
  • the service entity requesting the authentication and the EAC share a key, that is, the shared key Ks, and the EAC will assign the temporary identity to the service entity according to the subscription information of the service entity that requests the authentication and the corresponding validity period: 1) If the service entity requesting authentication is SS, the EAC assigns an intermediate service request identifier (ISR-ID) to the SS; 2) if the service entity requesting authentication is an SP, the EAC assigns an intermediate authentication query identifier (IAC) to the SP.
  • ISR-ID intermediate service request identifier
  • SP an intermediate authentication query identifier
  • the EAC assigns an ISR-ID and an IAC-ID to the SSP; the trust relationship established by the authentication has an expiration date, and when the validity period expires, the business entity needs to The EAC re-authentication process establishes a new trust relationship.
  • the EAC After the service entity and the EAC complete the authentication, the EAC sends the assigned temporary identity and the validity period to the service entity requesting the authentication. Thereafter, the communication between the service entity and the EAC uses the shared key Ks between the service entity and the EAC generated by the authentication process. Protect.
  • the business request entity After the business request entity completes the EAC certification process, it can provide real business Body request business.
  • the SP or SSP receives the service request message, if the SP or SSP has completed the EAC authentication process and obtains a valid IAC-ID or ISR-ID and IAC-ID, the ISR-ID of the service request entity and its own The IAC-ID is carried in the query request message, and the EAC is queried for the authentication status of the service request entity; otherwise, the SP or the SSP should first go to the EAC for authentication and the key negotiation process before requesting the EAC to query the authentication status of the service request entity.
  • the EAC After receiving the query request, the EAC first queries the ISR-ID of the service requesting entity and the IAC-ID or ISR-ID and the IAC-ID of the service providing entity, and has the corresponding rights, and then according to the two. Related information, using a shared key Ks negotiated by the service requesting entity and the EAC and an encryption algorithm of the authentication method to calculate a derivative key for protecting the service communication between the service request entity and the service providing entity, and deriving the derivative key The key is sent to the service provider entity. At the same time, the service requesting entity also calculates the derived key by using the shared key Ks negotiated by the service requesting entity with the EAC and the encryption algorithm of the authentication mode obtained after negotiation. In this way, both the service requesting entity and the service providing entity obtain the same derived key, and use the derived key to protect each other's communication.
  • the universal certification framework shown in Figure 1 is applicable to a wide range of business entities.
  • different services may have different security requirements.
  • a service with a high security level requires sufficient security for communication between the service providing entity and the service requesting entity.
  • the security of the communication depends not only on the authentication method.
  • the authentication protocol and the security of the encryption algorithm also depend on the security of the key used.
  • the establishment of trust between business entities is based on the trust between the business entity and the EAC.
  • the derived key used for communication between business entities is calculated by the shared key Ks negotiated by the business entity and the EAC.
  • Ks is also required to have high security. Therefore, the EAC is required to be able to provide different security levels for the business entity and generate a shared key Ks of different security levels, thereby being an entity.
  • Inter-communication provides derived keys of different security levels.
  • the existing universal authentication framework does not classify the security level between the EAC and the service entity for authentication and key agreement, so that the EAC cannot provide the security entity with different security level certifications, so that the service security level is not met.
  • the generation of a key does not make it easier for operators to charge more reasonable and accurate services for services with different security levels, which cannot be well adapted to the needs of business development. Summary of the invention
  • Embodiments of the present invention provide a method and system for entity authentication, a method and system for end-to-end authentication, and an entity authentication center (EAC), which can provide different security levels for business entities to meet business security. Level requirements, well adapted to the needs of business development.
  • EAC entity authentication center
  • An entity authentication method when a business entity initiates authentication to an EAC, the method includes:
  • the EAC Obtaining, by the EAC, a security level for performing authentication with the service entity, and acquiring an authentication mode supported by the EAC and the service entity and meeting the security level; the EAC and the service entity are obtained according to the The authentication mode is authenticated and a shared key is generated, the security level is assigned to the shared key, and the shared key and the security level are stored in association;
  • the business entity associates a shared key generated by itself and the security level.
  • the EAC acquires a security level for performing authentication with the service requesting entity, and an authentication mode supported by the service requesting entity and conforming to the security level.
  • the EAC and the service request entity Performing authentication according to the obtained authentication mode and separately generating a shared key, the EAC assigning the security level to the generated shared key, and the EAC and the service requesting entity respectively generate a shared key generated by each Security level association storage;
  • the shared request key of the service requesting entity that meets the security level requirement of the requested service is used to generate a derivative for protecting service communication between the service requesting entity and the service providing entity. Key.
  • An entity authentication system includes: an entity authentication center EAC and a service entity; the EAC obtains a security level for performing authentication with the service entity, and obtains the obtained authentication method and the business entity for authentication. Generating a shared key, allocating the security level to the generated shared key, and associating and storing the generated shared key and the security level;
  • the service entity authenticates with the EAC according to the authentication mode obtained by the EAC, generates a shared key, and associates the generated shared key with the security level.
  • An end-to-end authentication system including: an entity authentication center EAC, a service requesting entity, and a service providing entity;
  • the EAC obtaining, by the EAC, a security level for performing authentication with the service requesting entity, obtaining an authentication mode supported by the EAC and the service request entity, and meeting the security level, and the service request entity according to the
  • the obtained authentication mode is authenticated and generates a shared key
  • the security level is assigned to the generated shared key
  • the generated shared key and the security level are stored in association;
  • the service requesting entity requests the service Generating a derived key for protecting service communication between the service requesting entity and the service providing entity by using a shared key of the service requesting entity that meets a security level requirement of the requested service; authenticating and generating a shared secret Key, associating the generated shared key and the security level, and Generating a derived key for protecting service communication with the service providing entity by using a shared key of the service requesting entity that meets a security level requirement of the requested service when requesting a service;
  • the service providing entity provides a service for the service requesting entity and protects communication with the service requesting entity by using the derived key generated by the EAC.
  • An entity certification center EAC including:
  • a first unit obtaining a security level for performing authentication with the service entity, and obtaining an authentication mode supported by the EAC and the service entity;
  • the second unit performs authentication according to the authentication method acquired by the first unit and generates a shared key, allocates a security level acquired by the first unit to the generated shared key, and associates and stores the generated shared key and the security grade. .
  • the embodiment of the present invention selects an authentication method that meets the security level requirement according to the security level required by the service in the authentication process, and performs authentication between the EAC and the service entity requesting authentication, and after establishing the authentication.
  • the embodiment of the present invention divides the security level between the EAC and the service entity for authentication and key agreement, so that the EAC provides the service entity with different security level authentication, which facilitates the operator to adopt different services for different security level requirements.
  • the billing strategy is used for billing, which is well adapted to the needs of business development.
  • the communication parties may use the shared key that meets the current service security level requirement to provide a derivative key that meets the service security level requirement for the communication between the service entities, thereby ensuring the different business entities.
  • Different 'business communications establish trust relationships at different security levels.
  • 1 is a schematic diagram of a prior art end-to-end communication authentication architecture
  • 2 is a flowchart of an EAC implementing authentication in an embodiment of the present invention
  • FIG. 3 is a flowchart of a service entity requesting authentication from an EAC in an embodiment of the present invention
  • FIG. 4 is a flowchart of implementing service communication between an SS and an SP in an embodiment of the present invention
  • FIG. 5 is a schematic diagram of SS and SP in the embodiment of the present invention
  • the entity authentication center acquires a security level for performing authentication between the service entity requesting authentication, and according to the obtained security level, the correspondence between the preset security level and different authentication modes, and the corresponding entity of the service entity.
  • the subscription information is obtained by obtaining an authentication method supported by the entity authentication center and the service entity and meeting the security level requirement; the entity authentication center and the service entity perform authentication according to the acquired authentication mode and negotiate to generate a shared key, and the entity authentication center generates
  • the shared key is assigned a security level, a temporary identity is assigned to the service entity requesting the authentication, and the temporary identity, the shared key, and the security level of the shared key are associated and stored in the entity authentication center and the service entity.
  • FIG. 2 is a flowchart of an EAC implementing authentication in an embodiment of the present invention.
  • a correspondence between a security level and different authentication modes is set in an EAC, and the correspondence may be stored in a security level database. It is assumed that a service entity requesting authentication has been connected to the network. There is a contractual relationship and the subscription information is stored in the ESD.
  • This embodiment of the invention includes the following steps:
  • Step 200 The EAC obtains a security level for performing authentication between the service entity requesting authentication, and queries the security level database according to the obtained security level to select an authentication mode that meets the security level requirement and is supported by the EAC;
  • the subscription information of the business entity selects the authentication method supported by the business entity.
  • the method for obtaining the security level of authentication between the service entity requesting authentication is: selected by the service entity requesting authentication and reported to the EAC, or selected by the EAC, and the specific implementation is as follows: If the security level is selected by the business entity and reported to the EAC, the EAC queries the preset security level database according to the reported security level to obtain the authentication mode supported by the EAC corresponding to the security level.
  • the authentication method can be divided into four levels: high, high, normal, and low.
  • the authentication method includes an authentication protocol and an encryption algorithm.
  • the authentication protocol and encryption algorithm can be represented by simple fields, such as an English letter a plus a 4-bit numeric field to indicate the authentication mode.
  • aOOOl indicates 3G authentication and key agreement based on the User Service Identity Module (USIM) (AKA). ), a0010 indicates authentication based on the subscriber identity module (SIM), aOOll indicates the combination of SIM and transport layer security (TLS) authentication, aOlOO indicates public-private-key authentication plus DH key exchange, etc.; an English letter k plus A 4-bit digital field is used to represent the encryption algorithm, such as kOOOl for Advanced Encryption Standard-256 (AES-256) algorithm, kOOlO for AES-128 algorithm, kOOll for Gongyue Encryption-2048 (SA-2048) algorithm, kOlOO for RSA- The 1024 algorithm, kOlOl represents the Data Encryption Standard-64 (DES-64) algorithm.
  • DES-64 Data Encryption Standard-64
  • the service entity should carry the public identity (UID, Public Identity) of the service providing entity in the authentication request, and the EAC determines the service type according to the UID, and queries the preset service security level list to obtain The security level corresponding to the service type, and then the security level database is queried according to the obtained security level, and the EAC-supported authentication mode that meets the security level requirement reported by the service entity requesting the authentication is obtained.
  • the security level requirement reported by the service entity is determined by the UID carried in the authentication request.
  • the UID is an identity that is used to contact other service entities.
  • the same service entity can provide different services. Different types of services correspond to different UIDs. That is, different types of services can be distinguished by UIDs.
  • the correspondence between the storage security level and different service types can be preset in EAC or ESD.
  • both the business entity and the EAC select the service security level, select a security level with a higher security level as the current security level, and then query the security according to the current security level.
  • the rating database obtains the EAC-supported authentication method that meets the current security level requirements.
  • the EAC determines the authentication mode supported by the service entity according to the subscription information of the service entity that is authenticated by the request stored in the ESD.
  • the general service entity requests authentication, it will provide its own PID to the EAC.
  • the EAC queries the ESD for the contract information associated with the PID according to the PID, and obtains the authentication mode supported by the service entity from the subscription information.
  • Another method for the EAC to obtain the authentication mode of the service entity is that the service entity carries the authentication mode supported by the service entity in the authentication request message initiated by the EAC.
  • Step 201 The EAC selects an authentication mode supported by both the EAC and the service entity from the authentication mode supported by the security level, and returns the authentication mode to the service entity that requests the authentication.
  • the EAC selects an authentication method that is also supported by the service entity and that meets the requirements of the security level for authentication between the service entity requesting authentication.
  • the EAC fails to obtain an authentication method that is also supported by the service entity and meets the security level requirement, or fails from the self-supported authentication method that meets the security level requirement, If the service entity also supports the authentication mode, the EAC returns an error indication to the service entity requesting the authentication, indicating that the authentication fails.
  • the process of mutual authentication between the EAC and the service entity requesting authentication and the process of generating the shared key Ks in this step are completely consistent with the prior art, and it is emphasized here that the present invention
  • the EAC and the service entity requesting authentication are authenticated by using an authentication method that meets the required security level, and this embodiment of the present invention allocates the share for the shared key Ks generated by the negotiation.
  • the security level of the key is the Ks security level.
  • the Ks security level can be identified by two methods: One method is to use a separate security level field to indicate the Ks security level. For example, writing 0 in the security level field indicates that the security level is high, and writing 1 indicates that the security level is Higher, write 2 indicates that the security level is normal, write 3 indicates that the security level is low, and the other method is to assign a temporary identity to the user that can distinguish the Ks security level, that is, different temporary identifiers represent different
  • the security level such as the temporary identity of the shared key Ks with a high security level, contains the character "HIG", for example:
  • the temporary identity corresponding to a high security level shared key Ks can be identified as: HIG.RAND@ operator .com. -
  • Each business entity and EAC may share multiple shared keys Ks, and each shared key Ks may correspond to different security levels.
  • Step 203 The service entity requesting authentication receives the authentication related information from the EAC and the security level of the shared key and stores it in association with the generated shared key.
  • the corresponding temporary identity, validity period, shared key, and security level of the shared key are saved in the EAC and the service entity requesting authentication, so as to be in the service request.
  • the security requirements for different services are protected by using derived keys generated by shared keys of different security levels.
  • this embodiment of the present invention further includes: when the service requesting entity applies for the service service to the service providing entity, the service requesting entity first queries whether it has saved the security according to the current service.
  • the shared key Ks of the level requirement may be the security level of the service requirement indicated by the service providing entity to the service requesting entity; or may be obtained by the service requesting entity before the application for the service service by other means, for example, the service requesting entity itself saves the service security A full-level list, so that the service request entity obtains the security level requirement of the service to be applied by querying the service security level list before requesting a certain service.
  • the service requesting entity checks the Ks security level required for the service to be applied for, the service requesting entity sends the temporary identity associated with the Ks security level to the service provider. If the service requesting entity checks that it does not have the Ks security level required for the service to be applied, the service requesting entity renegotiates with the EAC and assigns a Ks security level that meets the security level required for the current service to be applied, and then the Ks The temporary identity corresponding to the security level is sent to the service providing entity.
  • the service providing entity may obtain the derived key of the shared key Ks by the following method 1:
  • Method 1 The service providing entity sends its temporary identity and UID, the temporary identity of the service requesting entity, and the Ks security level to the EAC.
  • the EAC verifies the legality of the service requesting entity, such as checking the validity of the temporary identity, Ks security. Whether the level is real, if legal, the service request entity communicates with the service providing entity according to the temporary identity of the service requesting entity, the temporary identity of the service providing entity, and the shared key Ks associated with the temporary identity of the service requesting entity. The derived key is used and returned to the service provider entity. If not, the EAC returns an error message to the service provider entity.
  • Method 2 If the service requesting entity sends an authentication request message to the EAC, in addition to carrying the PID of the service requesting entity, the authentication request message carries the UID corresponding to the applied service, and the EAC can be classified according to the service security level by the EAC.
  • the query obtains the security level corresponding to the UID. If the service providing entity corresponding to the UID has completed the authentication process of the EAC, the temporary identity of the service providing entity may be obtained, and then the service request entity associated with the security level is queried. Temporary identity and shared key After the shared key and the temporary identity of the service requesting entity and the service providing entity are calculated, the derived key is directly pushed (Push) to the service providing entity.
  • the service requesting entity generates a derivative key according to the shared key Ks corresponding to the security level of the applied service, so that the service request entity and the service providing entity protect the communication by using the derived key that meets the current service security level requirement.
  • Different business entities can establish trust relationships of different security levels for communication of different services.
  • FIG. 3 is a flowchart of a service entity requesting authentication from an EAC in the embodiment of the present invention.
  • a service entity requesting authentication selects a security level requirement for authentication, and a service entity requesting authentication has a contract relationship with the network.
  • the subscription information is stored in the ESD, and the embodiment includes the following steps:
  • Step 300 to step 301 The service entity requesting the authentication selects the security level of the authentication mode, and the selected security level and the PID of the service entity are carried in the authentication request message and sent to the EAC.
  • the method for requesting the authenticated service entity to select the security level of the authentication may be: for the service request entity, selecting a security level set by the service request entity through a preset user interface, or selecting a security level required by the service, or selecting a service request entity The security level set by the preset user boundary and the higher security level required by the service; for the service providing entity, the security level required by the service is selected.
  • the service request entity may return the corresponding Ks security level information to the service request entity when the service request entity requests the service service from the service providing entity, or may be the service entity requesting Before the authentication is obtained by other means, for example, the service entity searches for the requirement of the Ks security level corresponding to a certain service by using a list of service security levels saved by itself.
  • the authentication request message may also carry the authentication capability information of the service entity, that is, the supported authentication mode.
  • the authentication request message also carries the UID of the service to be accessed.
  • Step 302 Step 303: The EAC searches for the authentication mode supported by the service entity, including the authentication protocol, the encryption algorithm, and other related parameters, and obtains the authentication supported by the service entity, according to the PID of the service entity that is requested to be authenticated. the way.
  • the EAC selects an authentication mode supported by both the user and the service entity from the authentication mode supported by the service entity, and returns the authentication mode supported by the two parties to the service entity that requests the authentication.
  • the EAC queries the security level database stored in the EAC to select an authentication method that meets the requirements of the security level for authentication between the service entities requesting authentication.
  • the EAC selects an authentication method that is also supported by the EAC from the authentication modes supported by the service entity.
  • the EAC fails to obtain an authentication method that is also supported by itself and meets the requirement of the security level for authentication between the service entity requesting authentication, the EAC requests the service entity to be authenticated. An error indication is returned indicating that the authentication failed.
  • Step 306 After receiving the authentication mode from the EAC that meets the current security level requirements, the service entity requesting the authentication returns an acknowledgement response message to the EAC.
  • This step can be omitted.
  • Step 307 - Step 308 The EAC and the service entity requesting authentication perform mutual authentication and negotiation to generate a shared key Ks by using the authentication modes supported by the two parties, and the EAC allocates a Ks security level for the generated shared key, and requests authentication.
  • the service entity allocates a temporary identity and a validity period of the shared key Ks, and associates the temporary identity, the shared key Ks, the validity period, and the Ks security level of the shared key and stores the temporary identity, the validity period, and the share.
  • the Ks security level of the key is sent to the business entity requesting the authentication.
  • the service entity requesting authentication receives the temporary identity from the EAC, the validity period of the shared key Ks, and The Ks security level of the shared key is stored in association with the shared key Ks.
  • the SS requests the service from the SP as an example, and the flow chart of the two embodiments shown in FIG. 4 and FIG. 5 is combined to describe the method for implementing the service communication between the SS and the SP.
  • FIG. 4 is a flowchart of implementing service communication between an SS and an SP in an embodiment of the present invention, and sending a service request message to the SP through the SS to implement service communication between the SS and the SP, specifically including the following steps:
  • Step 400 The SS sends a service request message to the SP, where the service request message carries the temporary identity of the SS and the UID corresponding to the service of the SS application.
  • a security level field for storing the security level required for the SS to perform authentication is set in the temporary identity.
  • the SS can search for the security level corresponding to the UID of the requested service through the list of service security levels saved by itself, and find the temporary identity associated with the shared key Ks that meets the security level, and the temporary identity carrying the Ks security level.
  • the identity is sent to the service provider entity.
  • the service request message may carry the security level information corresponding to the shared key Ks, that is, the security level information corresponding to the shared key Ks is sent as a separate security level parameter indication.
  • SP may also send only the temporary identity associated with the shared key Ks to the SP.
  • Step 401 The SP queries the preset service security level list according to the received UID to obtain the security level requirement of the service corresponding to the UID, and determines the security level or SS carried in the temporary identity identifier from the SS. Whether the security level meets the security level requirement of the current application service, if yes, proceeds to step 405; otherwise, rejects the SS service request or proceeds to step 402.
  • the SP may also directly perform step 405 without determining whether the security level sent by the SS meets the security level requirement of the service corresponding to the UID.
  • the SP determines whether the security level sent by the SS meets the security level requirement of the service corresponding to the UID, if the security level carried in the temporary identity of the SS is higher than or equal to the security level requirement corresponding to the UID, the indication is met; otherwise, , incompatible.
  • the security level carried in the temporary identity identifier of the SS is in accordance with the security level requirement of the current application service.
  • Steps 402 to 404 The SP returns an indication of the security level required by the service requested by the SS to the SS; the SS searches for the temporary identity and other related information associated with the shared key Ks that meets the security level requirement according to the associated information stored by the SS, and The temporary identity associated with the shared key Ks is returned to the SP.
  • Step 405 The SP sends a query request to the EAC, and sends the temporary identity of the SS and the temporary identity of the SS to the EAC.
  • the EAC queries whether it stores the information stored in association with the temporary identity of the SS. If it is stored, the SP verifies. SS is legal; otherwise, SS is illegal. In this embodiment, it is assumed that the verification of the SS is legal.
  • the SP may simultaneously send the current UID to the EAC, and the EAC checks whether the security level sent by the SS meets the service requirement. Specifically, the EAC obtains the security level requirement corresponding to the UID according to the received UID query service security level list, and then checks whether the security level corresponding to the temporary identity of the SS meets the requirement; otherwise, the EAC returns an authentication query failure response to the SP.
  • the temporary identity does not match the security level requirement, and instructs the SS to re-initiate the authentication request of the security level to the EAC to obtain a new shared key Ks and temporary identity, etc. that meet the security level requirement. information.
  • the EAC can The SP searches for the information stored in the association according to the temporary identity of the SS provided by the SP, and the SP queries and obtains the security level corresponding to the temporary identity of the service request entity from the EAC, and determines according to the security level corresponding to the UID of the service requested by the SS. Whether the security level associated with the temporary identity of the SS meets the needs of the service. If it does not, the service cannot be requested.
  • Step 406 After the EAC verifies that the SS is legal, the derived key is generated by using the shared key Ks and related information associated with the received temporary identity of the SS. At the same time, the SS generates a derived key using the shared key Ks associated with the temporary identity sent to the SP and associated information.
  • Step 407 The EAC sends the generated derivative key used to protect the service communication to the
  • Step 408 The SP saves the received derivative key and returns a service request success response to the SS.
  • the SP receives an authentication query failure response from the EAC, the SP returns a corresponding service request failure response to the SS. In this embodiment, it is assumed that the SP returns a service request to the SS for a successful response.
  • Step 409 After the SS receives the service request success response, the SS and the SP use the derived key to protect the service communication between the two.
  • the SP also determines whether the security level reported by the SS is true according to the information sent by the EAC.
  • FIG. 5 is a flowchart of implementing service communication between an SS and an SP in an embodiment of the present invention.
  • the SS sends an authentication request message to the EAC to implement service communication between the SS and the SP, which specifically includes the following steps:
  • Step 500 When the SS sends an authentication request message to the EAC, in the authentication request message, It also carries the PID of the SS and the UID corresponding to the applied service.
  • the authentication request message may also carry the authentication capability information of the service entity, that is, the supported authentication mode.
  • Step 501 After receiving the authentication request message, the EAC obtains a security level corresponding to the received UID by querying the preset service security level list, and if the temporary identity identifier of the SP is obtained by using the information stored in association with the security level, The SP has been authenticated at the EAC and is legal. In addition, through the PID of the SS, all the temporary identities of the SS can be detected, and then, according to the service security level corresponding to the UID, it is determined whether there is a storage associated with the security level. The temporary identity of the SS, if yes, proceeds to step 509; otherwise, steps 502 to 508 are performed to re-authenticate the SS.
  • step 502 if the temporary identity assigned by the EAC to the SS can only be used once, that is, the SS implements the service communication between the SS and the SP by sending an authentication request message to the EAC, and must authenticate with the EAC for the request.
  • the temporary identity is assigned by the EAC, and the step can be omitted, and step 502 is directly executed.
  • the temporary identity of the SS stored in the security level associated with the UID is stored in the EAC.
  • Step 502 to step 504 The EAC selects an authentication mode supported by the EAC that meets the security level requirement according to the security level corresponding to the UID.
  • the EAC obtains the authentication mode supported by the SS from the stored subscription information according to the PID of the SS, that is, the SS. Supported authentication protocols, encryption algorithms, and other related parameters.
  • the EAC selects the authentication mode supported by both EAC and SS from the authentication mode supported by the security level, and returns the authentication mode to the SS. After receiving the authentication mode, the SS returns an acknowledgement response message to the EAC.
  • EAC Returns an error indication to the SS.
  • Step 508 The SS and the EAC perform mutual authentication by using the selected authentication mode. After the authentication succeeds, the two parties obtain the shared key Ks, and calculate the derived key by using the generated shared key Ks and other parameters in the EAC and the SS respectively.
  • Step 509 The EAC returns an authentication success response to the SS, where the response carries the ISR-ID of the SS that meets the current service security requirement, the validity period of the shared key Ks, and the corresponding security level.
  • Both EAC and SS store the shared key Ks, the ISR-ID of the SS, the validity period, and the corresponding security level.
  • Step 510 The EAC sends the generated derived key and the ISR-ID of the SS to the SP to which the service corresponding to the UID belongs, and the SP stores the received derivative key and the ISR-ID of the SS, and can return the confirmation to the EAC. Response message.
  • Step 511 When the SS applies for the service to the SP, if the derived key associated with the ISR-ID of the SS has been saved in the SP, the SS and the SP may be protected by using the derived key associated with the ISR-ID of the SS. Business communication between the two parties.
  • Embodiments of the present invention also provide an entity authentication system that includes an E AC and a business entity.
  • the authentication between the EAC and the service entity is initiated by the service entity, and the EAC obtains the security level of authentication with the service entity, and obtains the authentication mode supported by the EAC and the service entity and conforms to the security level. Then, the EAC authenticates with the service entity according to the obtained authentication mode, and negotiates to generate a shared key. The EAC allocates a security level to the generated shared key, allocates a temporary identity to the service entity, and associates the allocated storage with the storage entity.
  • the system also includes entity subscription data
  • the library ESD stores a list of service security levels for storing correspondence between security levels and service types and subscription information of the business entity.
  • the EAC can obtain the security level of authentication with the business entity in one of the following ways:
  • the security level of the authentication between the EAC and the EAC is selected by the service entity and reported to the EAC.
  • the service entity may select a security level set by a preset user interface, or select a security required by the service. Level, or select a security level set by the preset user interface and a security level higher than the security level required by the service as the security level for authentication;
  • the EAC selects the security level for authentication with the service entity.
  • the service entity provides the public identity UID to the EAC;
  • the EAC determines the service type according to the UID provided by the service entity, and queries the service security level of the ESD storage.
  • the list obtains the security level corresponding to the service type;
  • the security level of the authentication may be reported to the EAC by the service entity, and the service entity provides the UID to the EAC.
  • the EAC determines the service type according to the UID, and obtains the security level corresponding to the service type according to the service level list, and selects A security level reported by the business entity and a security level higher in the security level acquired by itself are used as security levels for authentication with the business entity.
  • the EAC After obtaining the security level of the authentication with the service entity, the EAC can query the subscription information of the service entity stored in the entity subscription database, and obtain the authentication mode supported by the EAC and the service entity and meet the security level.
  • Embodiments of the present invention also provide a system for end-to-end authentication, the system including an EAC, a service requesting entity, and a service providing entity.
  • the EAC is configured to obtain a security level for authentication with the service requesting entity, and obtain the recognition that the EAC and the service requesting entity support and meet the security level.
  • the service requesting entity performs authentication according to the obtained authentication mode and generates a shared key between the two, and the obtained shared key is allocated to secure the authentication with the service requesting entity.
  • Level assigning a temporary identity to the service requesting entity, and associating and storing the assigned temporary identity, the generated shared key, and the security level of the shared key;
  • the EAC determines that the service requesting entity has a temporary identity that meets the security level requirement of the requested service
  • the temporary identity of the service requesting entity that meets the security level requirement of the requested service is adopted.
  • the identifier and its associated shared key generate a derivative key for protecting the service communication between the service request entity and the service providing entity, and send the generated key to the service providing entity; if it is determined that the service request entity does not have the requested service
  • the temporary identity of the security level requirement informs the service requesting entity to re-initiate the authentication, and when the service requesting entity re-initiates the authentication, generates a new shared key, allocates a new temporary identity to the service requesting entity, and uses the The new temporary identity and the new shared key generate a new derived key that is sent to the service provider entity.
  • the service requesting entity may perform authentication with the EAC according to the authentication mode obtained by the EAC and generate a shared key, and associate the temporary identity identified by the EAC, the generated shared key, and the security level of the shared key, and Deriving a secret identifier for the service communication entity and the associated shared key of the service request entity according to the security level requirement of the requested service when requesting the service, and generating a derivative for protecting the service communication between the service request entity and the service providing entity key.
  • the service providing entity provides services to the service requesting entity and protects communication with the service requesting entity with a derived key generated by the EAC.
  • Embodiments of the present invention also provide an entity authentication center EAC including a first unit and a second unit.
  • the first unit is used to obtain authentication between the EAC and the business entity.
  • the security level, and the authentication methods supported by both the EAC and the business entity are obtained, and the obtained authentication mode is sent to the second unit.
  • the second unit performs authentication with the service entity according to the authentication method acquired by the first unit, generates a shared key, assigns a security level to the generated shared key, allocates a temporary identity to the service entity, and associates the temporarily assigned identity with the storage. , the generated shared key and the security level of the shared key.
  • the EAC further includes a third unit, configured to determine a service type according to the public identity UID provided by the service entity when the service entity requests the service, and send the determined service type to the first unit, so that the first unit obtains the first The security level corresponding to the type of service determined by the three units.
  • the EAC may also include a fourth unit. When the service entity requests the service, the fourth unit is configured to obtain the temporary identity and the shared key of the service entity stored in the second unit in association with the security level corresponding to the service requested by the service request entity, and use the acquired shared secret. The key generates a derived key; otherwise, the business entity is required to re-authenticate.
  • the fourth unit may further determine whether the service entity of the request service has a temporary identity that meets the security level requirement of the requested service, and if yes, acquire the temporary identity and the security level in the second unit. Associate the stored shared key, generate the derived key using the obtained shared key, and send the generated derived key to the service entity that provides the service; otherwise, the business entity is required to re-authenticate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

实体认证方法及系统、 端到端认证方法及系统、 认证中心 技术领域
本发明涉及通用鉴权技术， 尤指一种实体认证的方法及系统、 一种 端到端认证的方法及系统、 一种实体认证中心 （ EAC , Entity Authentication Center )。 发明背景 '
图 1是现有技术端到端通信认证架构的示意图， 如图 1所示， 该 架构适用于不同移动网络标准，其作用在于为在不同类型的实体间建 立相互信任关系， 是一个真正意义上的通用鉴权框架。 图 1所示的认 证架构涉及到的网络元素除了三种业务实体：业务定购者（SS , Service Subscriber )、业务定购 /提供者（ SSP , Service Subscriber and Provider )、 业务提供者 （SP, Service Provider )外， 在运营商网络中， 还包括一 个 EAC和一个实体签约数据库（ ESD, Entity Subscription Database )。
其中， 业务实体是业务提供实体与业务请求实体的统称， 包括 SS、 SSP和 SP三种类型。 SS只能申请服务，一般为普通的移动用户； SSP 可以是普通的移动用户， 也可以是第三方的应用服务器 （AS， Application Server ); SP为运营商网络的 AS或外部网络的 SP; EAC 用于完成和其它业务实体进行认证方法的协商及认证的过程，并且接 受某个业务实体对其它业务实体认证情况的查询； ESD用于存储业务 实体签约信息， 签约信息可以包括业务实体签约的服务， 或业务实体 提供的服务， 或业务实体签约的服务及提供的服务等， 以及业务实体 支持的认证方式及其它认证信息等，业务实体的签约信息与业务实体 的私有身份标识（ΡΠ), Private Identity ) 关联保存。 业务提供实体在为其它业务实体提供业务，或者业务请求实体向 其它业务实体请求业务之前， 应该首先已经与网络存在签约关系， 并 将签约信息存放于 ESD 中； 并且， 网络中每个业务实体在与其他业 务实体进行通信之前， 需要先与 EAC协商认证方式， 并完成对身份 的认证过程。
认证方式的协商过程由业务实体发起，业务实体将自身身份标识 携带在认证请求消息中发送给 EAC。 EAC根据本地预设策略和该业 务实体签约信息， 选择一种认证方式， 并将该认证方式及相关认证信 息返回给发起认证请求的业务实体， 该业务实体向 EAC发送确认信 息表示协商过程结束。
业务实体与 EAC 间按照协商的认证方式进行认证， 该认证是双 向的。 认证结束后， 请求认证的业务实体和 EAC共享一个密钥即共 享密钥 Ks， 并且 EAC将根据请求认证的业务实体的签约信息给该业 务实体分配临时身份标识以及相应的有效期： 1 ) 若该请求认证的业 务实体是 SS ,则 EAC向该 SS分配一个中间业务请求标识（ ISR-ID ); 2 )若该请求认证的业务实体是 SP, 则 EAC向该 SP分配一个中间认 证查询标识 （IAC-ID ); 3 ) 若该请求认证的业务实体是 SSP, 那么 EAC向该 SSP分配一个 ISR-ID和一个 IAC- ID; 认证建立的信任关 系存在一个有效期， 当过了有效期， 业务实体需要与 EAC之间进行 重认证过程， 建立新的信任关系。
业务实体与 EAC完成认证后， EAC将分配的临时身份标识以及 有效期发送给请求认证的业务实体， 此后该业务实体与 EAC之间的 通信采用认证过程生成的业务实体与 EAC 间的共享密钥 Ks进行保 护。
在业务请求实体完成到 EAC的认证过程后， 便可向业务提供实 体请求业务。 SP或 SSP收到业务请求消息后， 如果 SP或 SSP 已经 完成到 EAC的认证过程并获得有效的 IAC-ID或 ISR-ID和 IAC-ID, 便可将业务请求实体的 ISR- ID以及自身的 IAC-ID携带在查询请求消 息中， 向 EAC查询业务请求实体的认证情况； 否则， SP或 SSP应先 到 EAC进行认证以及密钥协商过程后， 才能向 EAC请求查询业务请 求实体的认证情况。
EAC收到查询请求后， 首先根据业务请求实体的 ISR- ID以及业 务提供实体的 IAC- ID或 ISR- ID和 IAC- ID, 查询二者有'；殳有相应的 权限， 然后根据二者的相关信息， 利用业务请求实体与 EAC协商的 共享密钥 Ks及认证方式的加密算法为二者计算一个用于保护业务请 求实体和业务提供实体之间业务通信的衍生密钥，并将该衍生密钥发 送给业务提供实体。 与此同时， 业务请求实体也利用业务请求实体与 EAC协商的共享密钥 Ks以及协商后得到的认证方式的加密算法计算 得到衍生密钥。 这样， 业务请求实体与业务提供实体均荻得相同的衍 生密钥， 并利用该衍生密钥对相互间的通信进行保护。
图 1所示的通用认证框架适用的范围很广， 可以适用于各种不同的 业务实体。 在实际应用中， 不同的业务可能有不同的安全需求， 比如高 安全級别的业务要求业务提供实体与业务请求实体之间的通信具有足 够的安全性， 通信的安全程度不仅取决于认证方式即认证协议以及加密 算法的安全， 还取决于所采用的密钥的安全性。
通用鉴权框架中，业务实体之间信任的建立是以业务实体与 EAC之 间的信任为基 的， 业务实体之间通信采用的衍生密钥是利用业务实体 与 EAC协商的共享密钥 Ks计算得到的，要生成高安全等级的衍生密钥， 需要 Ks也具有较高的安全性。 因此， 要求 EAC能够对业务实体提供不 同安全等级的认证， 并且生成不同安全等级的共享密钥 Ks， 从而为实体 间通信提供不同安全等级的衍生密钥。而现有的通用鉴权框架未对 EAC 与业务实体间的认证与密钥协商划分安全等级， 使 EAC 不能为业务实 体提供不同安全等级的认证， 从而得不到符合业务安全等级需求的ί>Τ生 密钥， 也不便于运营商对不同安全等级需求的业务进行更合理、 更精确 的计费， 不能很好地适应业务发展的需求。 发明内容
本发明的实施例提供了一种实体认证的方法及系统、 一种端到端认 证的方法及系统、 一种实体认证中心 （EAC ), 能够为业务实体提供不 同安全等级的认证， 符合业务安全等级需求， 很好地适应业务发展的需 求。
本发明实施例的技术方案具体是这样实现的：
一种实体认证的方法， 当业务实体向 EAC发起认证时， 该方法包 括：
所述 EAC获取与所述业务实体之间进行认证的安全等级， 并获取 所述 EAC与所述业务实体均支持的且符合所述安全等级的认证方式； 所述 EAC与所述业务实体按照获得的认证方式进行认证并生成共 享密钥， 为所述共享密钥分配所述安全等级， 并关联存储所述共享密钥 和所述安全等级；
所述业务实体关联存储自身生成的共享密钥和所述安全等级。
一种端到端的认证方法， 应用于包括实体认证中心 EAC、 业务请求 实体和业务提供实体的系统， 该方法包括：
所述业务请求实体向所述 EAC发起认证时， 所述 EAC获取与所述 业务请求实体之间进行认证的安全等级、 以及与所述业务请求实体均支 持的且符合所述安全等级的认证方式； 所述 EAC 与所述业务请求实体 按照获得的认证方式进行认证并分别生成共享密钥， 所述 EAC 为所生 成的共享密钥分配所述安全等级， 所述 EAC 和所述业务请求实体分别 将各自生成的共享密钥与所述安全等级关联存储；
所述业务请求实体请求业务时， 采用所述业务请求实体的符合所请 求的业务的安全等级需求的共享密钥生成用于保护所述业务请求实体 和所述业务提供实体之间业务通信的衍生密钥。
一种实体认证系统， 包括： 实体认证中心 EAC和业务实体； 所述 EAC, 获取与所述业务实体之间进行认证的安全等级， 获取所 照所获取的认证方式与所述业务实体进行认证并生成共享密钥， 为所生 成的共享密钥分配所述安全等级， 并关联存储所生成的共享密钥和所述 安全等級；
所述业务实体， 按所述 EAC获取的认证方式与所述 EAC进行认证 并生成共享密钥， 关联存储所生成的共享密钥和所述的安全等级。
一种端到端的认证系统， 包括： 实体认证中心 EAC、 业务请求实体 和业务提供实体；
所述 EAC， 获取与所述业务请求实体之间进行认证的安全等级， 获 取所述 EAC 与所述业务情求实体均支持的且符合所述安全等级的认证 方式， 与所述业务请求实体按照所获得的认证方式进行认证并生成共享 密钥， 为所生成的共享密钥分配所述安全等级， 并关联存储所生成的共 享密钥和所述安全等级； 当所述业务请求实体请求业务时， 采用所述业 务请求实体的符合所请求的业务的安全等级需求的共享密钥生成用于 保护所述业务请求实体和所述业务提供实体之间业务通信的衍生密钥； 认证并生成共享密钥， 关联存储所生成的共享密钥和所述安全等级， 并 在请求业务时采用所述业务请求实体的符合所请求的业务的安全等级 需求的共享密钥生成用于保护与所述业务提供实体之间业务通信的衍 生密钥；
所述业务提供实体， 为所述业务请求实体提供业务并用所述 EAC 生成的衍生密钥保护与所述业务请求实体之间的通信。
一种实体认证中心 EAC, 包括：
第一单元， 获取与业务实体之间进行认证的安全等级， 并获取所述 EAC和所述业务实体均支持的认证方式；
第二单元， 按照第一单元所获取的认证方式进行认证并生成共享密 钥， 为所生成的共享密钥分配第一单元获取的安全等级， 并关联存储所 生成的共享密钥和所述安全等级。 .
由上述技术方案可见， 本发明的实施例通过在认证过程中， 按照 业务要求的安全等级选择符合该安全等级需求的认证方式，在 EAC与 请求认证的业务实体间进行认证，并为建立认证后协商生成的共享密 钥分配安全等级。本发明的实施例对 E AC与业务实体间的认证与密钥 协商划分了安全等级， 使 EAC为业务实体提供了不同安全等级的认 证，方便了运营商对不同安全等级需求的业务采取不同的计费策略进 行计费， 很好地适应了业务发展的需求。
本发明的实施例进一步地， 在请求业务过程中， 通信双方可以采 用符合当前业务安全等级要求的共享密钥为业务实体间通信提供符 合业务安全等级需求的衍生密钥，保证了不同业务实体间不同'业务的 通信建立不同安全级别的信任关系。 附图简要说明
图 1是现有技术端到端通信认证架构的示意图； 图 2是本发明实施例中 EAC实现认证的流程图；
图 3是本发明实施例中业务实体向 EAC请求认证的流程图； 图 4是本发明实施例中 SS与 SP之间实现业务通信的流程图； 图 5是本发明实施例中 SS与 SP之间实现业务通信的流程图。 实施本发明的方式
在本发明的实施例中， 实体认证中心获取与请求认证的业务实体之 间进行认证的安全等级， 并根据获得的安全等级、 预设的安全等级与不 同认证方式的对应关系以及该业务实体的签约信息， 获取实体认证中心 与该业务实体均支持的且符合安全等级要求的认证方式； 实体认证中心 与该业务实体按照所获取的认证方式进行认证并协商生成共享密钥， 实 体认证中心为生成的共享密钥分配安全等级、 为请求认证的业务实体分 配临时身份标识， 并在实体认证中心和该业务实体中关联存储所述临时 身份标识、 共享密钥和该共享密钥的安全等级。
图 2是本发明实施例中 EAC实现认证的流程图， 在 EAC中设置安 全等级与不同认证方式的对应关系， 该对应关系可以存储在一安全等级 数据库中； 假设请求认证的业务实体已经与网絡存在签约关系并将签约 信息存储于 ESD中， 本发明这一实施例包括以下步骤：
步骤 200: EAC获取与请求认证的业务实体之间进行认证的安全等 级， 并根据获得的安全等级， 查询所述安全等级数据库选择符合该安全 等级需求的且又是 EAC 支持的认证方式； 并根据该业务实体的签约信 息选择该业务实体支持的认证方式。
获取与请求认证的业务实体之间进行认证的安全等级的方法为： 由 请求认证的业务实体选定并上报给 EAC, 或由 EAC来选择， 具体实现 如下： 如果安全等级由业务实体选定并上报给 EAC, 则 EAC按照上报的 安全等级查询预设的安全等级数据库， 获得该安全等级对应的 EAC 支 持的认证方式。 比如可以将认证方式按照安全等级分为： 高、 较高、 一 般、 低四种安全等级等。 在本发明的这一实施例中， 所述认证方式包括 认证协议和加密算法。认证协议、加密算法可以通过简单的字段来表示， 比如用一个英文字母 a加一个 4bit的数字字段来表示认证方式，如 aOOOl 表示基于用户业务身份模块（USIM ) 的 3G认证与密钥协商 （AKA )、 a0010表示基于用户身份模块（SIM )的鉴权、 aOOll表示 SIM与传输层 安全（ TLS )相结合的鉴权、 aOlOO表示基于公私钥鉴权加 DH密钥交换 等； 一个英文字母 k加一个 4bit的数字字段来表示加密算法， 如 kOOOl 表示高级加密标准 -256 ( AES-256 ) 算法、 kOOlO表示 AES-128算法、 kOOll表示公月加密 -2048 ( SA-2048 ) 算法、 kOlOO表示 RSA-1024算 法、 kOlOl表示数据加密标准- 64 ( DES-64 ) 算法等。
如果安全等级由 EAC选择，，则业务实体在认证请求中应携带业务 提供实体的公开身份标识（UID, Public Identity ), EAC根据该 UID确 定业务类型， 并查询预设的业务安全等级列表， 获取该业务类型对应的 安全等级， 然后根据获得的安全等级查询安全等级数据库， 获得符合请 求认证的业务实体上报的安全等级需求的 EAC支持的认证方式。 此处， 业务实体上报的安全等级需求由认证请求中携带的 UID确定。 其中， UID是用于与其它业务实体进行联系的身份标识， 同一业务实体可以 提供不同的业务， 不同类型的业务对应不同的 UID, 即通过 UID能 够区分出不同的业务类型； 业务安全等级列表用于存储安全等级与不 同业务类型的对应关系， 可预设在 EAC或 ESD中。
如果业务实体和 EAC都选择了业务安全等级， 则选择安全等级较 高的一个安全等级作为当前安全等级， 然后根据当前安全等级查询安全 等级数据库获取符合当前安全等级需求的 EAC支持的认证方式。
同时， EAC根据 ESD中存储的该请求认证的业务实体的签约信息， 确定该业务实体支持的认证方式。 一般业务实体请求认证时， 都会将自 身 PID提供给 EAC, EAC根据该 PID从 ESD中查询该 PID关联的签约 信息， 并从该签约信息中获得该业务实体支持的认证方式。
EAC 获取业务实体的认证方式的另外一种方法是， 业务实体在向 EAC发起的认证请求消息中携带该业务实体支持的认证方式。
步骤 201 : EAC从符合该安全等级需求的自身支持的认证方式中， 选择 EAC和该业务实体双方均支持的认证方式， 并将该认证方式返回 给请求认证的业务实体。
EAC 从所述业务实体支持的认证方式中选择自身同时也支持的且 符合与请求认证的业务实体之间进行认证的安全等级的需求的认证方 式。
如果在所述该业务实体支持的认证方式中， EAC未能获得自身也支 持的且符合安全等级需求的认证方式， 或者， 从符合该安全等级需求的 自身支持的认证方式中， 未能获得该业务实体也支持的认证方式， 则 EAC向请求认证的业务实体返回错误指示， 指示此次认证失败。
步骤 202: EAC与请求认证的业务实体间通过所述双方支持的认证 方式进行互认证并协商生成共享密钥， EAC为生成的共享密钥分配获取 的安全等级、 为请求认证的业务实体分配认证相关信息， 如临时身份标 识及共享密钥的有效期， 将所述认证相关信息、 所分配的共享密钥和该 共享密钥的安全等级关联存储， 并将所述认证相关信息和该共享密钥的 安全等级发送给请求认证的业务实体。
本步骤中 EAC 与请求认证的业务实体间的互认证过程以及协商生 成共享密钥 Ks的过程与现有技术完全一致， 这里强调的是， 在本发明 的这一实施例中， EAC与请求认证的业务实体之间是利用符合要求的安 全等级的认证方式进行的认证， 并且， 本发明的这一实施例会为协商生 成的共享密钥 Ks分配该共享密钥的安全等级即 Ks安全等级。
可以通过下面两种方法来标识 Ks安全等级： 一种方法是采用一 个单独的安全等级字段来表示 Ks安全等级， 比如安全等级字段中写 入 0表示安全等级为高、 写入 1表示安全级别为较高、 写入 2表示安 全级别为一般、 写入 3表示安全级别为低等； 另一种方法是为用户分 配一个可以区分出 Ks安全等级的临时身份标识， 即不同的临时身份 标识代表不同的安全等级， 比如安全等级为高的共享密钥 Ks对应的 临时身份标识包含字符" HIG"， 比如： 可将一个高安全等级的共享密 钥 Ks对应的临时身份标识为： HIG.RAND@ operator.com。 - 每个业务实体与 EAC可能共享多个共享密钥 Ks, 各共享密钥 Ks 可以对应不同的安全等级。
步驟 203:请求认证的业务实体接收来自 EAC的认证相关信息和该 共享密钥的安全等级并与所生成的共享密钥关联存储。
根据本发明的这一实施例， 针对不同业务需求， 在 EAC和请求认 证的业务实体中均保存了对应的临时身份标识、 有效期、 共享密钥和该 共享密钥的安全等级， 以便在业务请求中针对不同业务的安全需求采用 不同安全等级的共享密钥生成的衍生密钥对通信进行保护。
在图 2所示认证方法的基础上，本发明的这一实施例还进一步包括： 业务请求实体向业务提供实体申请业务服务时，业务请求实体首 先要查询自身是否已经保存了符合当前业务的安全等级需求的共享 密钥 Ks。业务对 Ks安全等级的需求可以是业务提供实体向业务请求 实体指示的业务要求的安全等级；也可以是业务请求实体通过其它方 式在申请业务服务之前获得的，比如业务请求实体自身保存有业务安 全等级列表，这样在业务请求实体请求某项业务之前通过查询该业务 安全等级列表， 获得要申请的业务的安全等级需求。
如果业务请求实体检查自身存在要申请的业务所需的 Ks安全等 级， 则业务请求实体将该 Ks安全等级关联的临时身份标识发送给业 务提供者。 如果业务请求实体检查自身不存在要申请的业务所需的 Ks安全等级， 则业务请求实体与 EAC重新协商并分配一个符合当前 要申请的业务所需的安全等级的 Ks安全等级， 然后将该 Ks安全等 级对应的临时身份标识发送给业务提供实体。
业务提供实体在接收到来自业务请求实体的所述 Ks安全等级对 应的临时身份标识之后， 可通过下述方法一获得共享密钥 Ks的衍生 密钥：
方法一： 业务提供实体将自身的临时身份标识和 UID、 业务请求 实体的临时身份标识以及 Ks安全等级发送给 EAC, EAC验证业务请 求实体的合法性， 比如检查临时身份标识的有效性， Ks 安全等级是 否属实等， 如果合法， 则根据业务请求实体的临时身份标识、 业务提 供实体的临时身份标识、以及与业务请求实体的临时身份标识关联的 共享密钥 Ks生成业务请求实体与业务提供实体通信用的衍生密钥， 并返回给业务提供实体。 如果不合法， 则 EAC向业务提供实体返回 错误信息。
方法二： 如果业务请求实体向 EAC发送认证请求消息时， 在该 认证请求消息中除了携带该业务请求实体的 PID外，还携带有所申请 的业务对应的 UID , 则可由 EAC根据业务安全等级列表查询获得该 UID对应的安全等级，如果 UID对应的业务提供实体已经完成在 E AC 的认证过程， 则可以获知该业务提供实体的临时身份标识， 然后再查 询与该安全等级关联的业务请求实体的临时身份标识和共享密钥，通 过该共享密钥以及业务请求实体和业务提供实体的临时身份标识计 算出衍生密钥后直接推送（Push ) 给业务提供实体。
同时， 业务请求实体根据申请的业务的安全等级对应的共享密钥 Ks生成衍生密钥， 这样， 业务请求实体和业务提供实体间采用符合当前 业务安全等级要求的衍生密钥对通信进行保护， 保证了不同业务实体间 能够为不同业务的通信建立不同安全级别的信任关系。
图 3是本发明实施例中业务实体向 EAC请求认证的流程图， 在本 实施例中， 假设由请求认证的业务实体选择认证的安全等级要求， 请求 认证的业务实体已经与网絡存在签约关系并将签约信息存储于 ESD中， 该实施例包括以下步骤：
步骤 300〜步骤 301 : 请求认证的业务实体选择认证方式的安全等 级， 将选定的安全等级及该业务实体的 PID携带在认证请求消息中发送 给 EAC。
请求认证的业务实体选择认证的安全等级的方法可以是：对于业 务请求实体，可以选择业务请求实体通过预设的用户界面设置的安全 等级、 或者选择业务所需求的安全等级、 或者选择业务请求实体通过 预设的用户界设置的安全等级和业务所需求的安全等级中较高的一 个安全等级； 对于业务提供实体， 选择业务所需求的安全等级。
业务实体获得业务对 Ks安全等级的需求的方式， 可以是业务请求 实体向业务提供实体请求业务服务时， 由业务提供实体返回相应的 Ks 安全等级信息给业务请求实体； 也可以是业务实体在请求认证之前通过 其它方式获得， 比如业务实体通过自身保存的业务安全等级列表， 查询 某项业务对应的 Ks安全等级的需求。
该认证请求消息中还可以携带业务实体的鉴权能力信息即支持的 认证方式。 另外， 如果采用由 EAC选择认证方式的安全等级的方式， 则该认证请求消息中还要携带所要访问的业务的 UID。
步骤 302―步骤 303: EAC根据请求认证的业务实体的 PID在 ESD 存储的签约信息中查询该业务实体支持的认证方式， 包括认证协议、 加 密算法和其它相关参数， 并获得该业务实体支持的认证方式。
步骤 304 ~步驟 305:匹配 EAC与所述业务实体均支持的认证方式。 EAC从所述业务实体支持的认证方式中，选择自身和该业务实体双方均 支持的认证方式， 并将该双方均支持的认证方式返回给请求认证的业务 实体。
EAC查询自身存储的安全等級数据库，选择符合与请求认证的业务 实体之间进行认证的安全等级的需求的认证方式， EAC从所述业务实体 支持的认证方式中选择自身同时也支持的认证方式。
如果在所述该业务实体支持的认证方式中， EAC未能获得自身也支 持的且符合与请求认证的业务实体之间进行认证的安全等级的需求的 认证方式， 则 EAC 向请求认证的业务实体返回错误指示， 指示此次认 证失败。
步骤 306:请求认证的业务实体接收到来自 EAC的符合当前安全等 级需求的认证方式后， 向 EAC返回确认响应消息。
本步綠可以省略。
步骤 307 -步骤 308: EAC与请求认证的业务实体间通过所述双方 均支持的认证方式进行互认证并协商生成共享密钥 Ks, EAC为生成的 共享密钥分配 Ks安全等级、 为请求认证的业务实体分配临时身份标识 及共享密钥 Ks的有效期， 将所述临时身份标识、 共享密钥 Ks、 有效期 和该共享密钥的 Ks安全等级关联存储并将所述临时身份标识、 有效期 和该共享密钥的 Ks安全等级发送给请求认证的业务实体。 请求认证的 业务实体接收来自 EAC的所述临时身份标识、共享密钥 Ks的有效期和 该共享密钥的 Ks安全等级并与共享密钥 Ks关联存储。
在上述业务实体实现认证的基础上， 以 SS向 SP请求业务为例， 结 合图 4和图 5所示的两个实施例流程图，具体描述 SS与 SP之间实现业 务通信的方法。
图 4是本发明实施例中 SS与 SP之间实现业务通信的流程图， 通过 SS向 SP发送业务请求消息来实现 SS与 SP之间的业务通信，具体包括 以下步聚：
步驟 400: SS向 SP发送业务请求消息， 该业务请求消息中携带有 SS的临时身份标识及 SS申请的业务对应的 UID。
本步骤中， 假设临时身份标识中设置有用于存储 SS进行认证所需 的安全等级的安全等级字段。 SS可通过自身保存的业务安全等级列表， 查找与所请求业务的 UID对应的安全等级，并找到符合该安全等级的共 享密钥 Ks关联的临时身份标识， 将该携带有 Ks安全等级的临时身份标 识发送给业务提供实体。
若临时身份标识中未设置安全等级字段， 在所述业务请求消息中可 以携带共享密钥 Ks对应的安全等级信息， 即共享密钥 Ks对应的安全等 级信息作为一个单独的安全等级参数指示发送给 SP ,也可以只发送与共 享密钥 Ks关联的临时身份标识给 SP。
步驟 401: SP根据接收到的 UID, 查询自身预设的业务安全等级列 表获得与该 UID对应的业务的安全等级需求， 并判断来自 SS的临时身 份标识中携带的安全等级或 SS直接发来的安全等级是否符合当前申请 业务的安全等级需求， 若符合， 则进入步骤 405; 否则， 拒绝 SS的业务 请求或者进入步骤 402。
在本步骤中， SP也可以不判断 SS发来的安全等级是否符合 UID对 应的业务的安全等级需要， 而直接执行步骤 405。 当 SP判断 SS发来的安全等级是否符合 UID对应的业务的安全等级 需要时， 若 SS的临时身份标识中携带的安全等級高于或等于所述 UID 对应的安全等级需求， 则表明符合； 否则， 不符合。 本实施例中， 支设 SS 的临时身份标识中携带的安全等级符合当前申请业务的安全等级需 求。
步骤 402〜步骤 404: SP向 SS返回 SS申请的业务所需的安全等 级指示； SS 根据自身存储的关联信息查找符合该安全等级需求的共 享密钥 Ks关联的临时身份标识和其它相关信息， 并向 SP返回与共 享密钥 Ks关联的临时身份标识。
如果 SS找不到符合安全等级需求的 Ks, 则需要重新到 EAC协 商一个符合安全等级需求的 Ks。
步骤 405: SP向 EAC发送查询请求， 将自身的临时身份标识， SS的临时身份标识发送给 EAC, EAC查询自身是否存储有与 SS的 临时身份标识关联存储的信息， 若存储有， 则验证出 SS是合法的； 否则， SS是不合法的。 本实施例中， 假设对 SS的验证是合法的。
若 SP没有判断 SS发来的安全等级是否符合 UID对应的业务的安 全等级需要， 则在步骤 405中， SP可以同时将当前 UID发送给 EAC, 由 EAC检查 SS发送的安全等级是否符合业务的要求， 具体包括： EAC根据接收到的 UID查询业务安全等级列表获得该 UID对应的安 全等级需求， 再检查 SS的临时身份标识对应的安全等级是否符合要 求； 否则， EAC向 SP返回认证查询失败响应， 并指明失败原因， 比 如， 临时身份标识与安全等级需求不匹配， 并指示 SS重新向 EAC发 起该安全等级的认证请求，以获得满足该安全等级要求的新的共享密 钥 Ks和临时身份标识等信息。
另夕卜，如果 SS的临时身份标识中没有携带安全等级，则 EAC可以 根据 SP提供的 SS的临时身份标识查找自身关联存储的信息， SP从 EAC中查询并获得该业务请求实体的临时身份标识对应的安全等级， 并根据 SS所请求业务的 UID对应的安全等级判断与 SS的临时身份 标识关联的安全等级是否符合业务需要， 如果不符合， 则不能请求该 业务。
步骤 406: EAC验证 SS合法后， 利用与接收到的 SS的临时身 份标识关联的共享密钥 Ks及相关信息生成衍生密钥。 与此同时， SS 利用与发送给 SP的临时身份标识关联的共享密钥 Ks及相关信息生 成衍生密钥。
步骤 407: EAC 将生成的用于保护业务通信的衍生密钥下发给
SP。
步骤 408: SP保存接收到的衍生密钥并向 SS返回业务请求成功 响应。
需要说明的是， 若 SP收到来自 EAC的认证查询失败响应， 则 SP向 SS返回相应的业务请求失败响应。 本实施例中， 假设 SP向 SS 返回业务渚求成功响应。
步骤 409: SS收到业务请求成功响应后， SS与 SP使用衍生密钥 保护两者之间的业务通信。
当然， 在本实施例中， 如果步骤 400中 SS将 Ks对应安全等级 通过一个单独的参数上报给 SP， SP还要根据 EAC发来的信息判断 SS上报的安全等级是否属实。
图 5是本发明实施例中 SS与 SP之间实现业务通信的流程图，通过 SS向 EAC发送认证请求消息来实现 SS与 SP之间的业务通信， 具体包 括以下步驟：
步骤 500: SS向 EAC发送认证请求消息时， 在认证请求消息中， 同时携带有 SS的 PID以及申请的业务对应的 UID。
该认证请求消息中还可以携带业务实体的鉴权能力信息即支持 的认证方式。
步骤 501 : EAC收到认证请求消息后， 查询预设的业务安全等级 列表获得与接收到的 UID对应的安全等级， 若通过与安全等级关联 存储的信息， 能获得 SP的临时身份标识， 则表明 SP已完成在 EAC 的认证， 是合法的； 另外， 通过 SS的 PID， 可以查出 SS的所有临时 身份标识， 然后， ； ^据 UID对应的业务安全等级， 判断是否存在与 该安全等级关联存储的 SS的临时身份标识，若存在，则进入步骤 509; 否则， 执行步骤 502〜步骤 508, 重新对 SS进行认证。
在本步驟中，如果 EAC为 SS分配的临时身份标识只能使用一次， 即 SS通过向 EAC发送认证请求消息来实现 SS与 SP之间的业务通信 时， 必须与 EAC为此次请求进行认证并由 EAC分配临时身份标识， 则 该步骤可以省略， 直接执行步骤 502。
本实施例中， 4艮设 EAC中存储有与所述 UID对应的安全等级关 联存储的 SS的临时身份标识。
步骤 502 ~步骤 504: EAC根据所述 UID对应的安全等级， 选择 符合该安全等级需求的 EAC支持的认证方式； EAC根据 SS的 PID 从存储于 的签约信息中获取 SS支持的认证方式， 即 SS支持的 认证协议、 加密算法和其它相关参数。
步骤 505 ~步骤 507: 匹配 EAC与 SS均支持的认证方式。 EAC 从符合该安全等级需求的自身支持的认证方式中，选择 EAC和 SS双 方均支持的认证方式， 并将该认证方式返回给 SS , SS收到认证方式 后， 向 EAC返回确认响应消息。
如果不存在二者均支持的符合该安全等级的认证方式， 则 EAC 向 SS返回错误指示。
步骤 508: SS和 EAC利用所选的认证方式进行互认证， 认证成 功后， 双方获得共享密钥 Ks, 并且在 EAC和 SS分别利用生成的共 享密钥 Ks以及其它参数计算出衍生密钥。
步驟 509: EAC向 SS返回认证成功响应， 响应中携带符合当前 业务安全需求的 SS的 ISR-ID, 共享密钥 Ks的有效期和相应的安全 等级。 EAC和 SS均将共享密钥 Ks、 SS的 ISR-ID、 有效期以及相应 的安全等级关联保存。
步骤 510: EAC将生成的衍生密钥及 SS的 ISR-ID发送给 UID 对应的业务所属的 SP，该 SP将收到的衍生密钥及 SS的 ISR-ID关联 存储， 并可以向 EAC返回确认响应消息。
步骤 511 : 当 SS向 SP申请业务时， 若该 SP中已经保存了与 SS 的 ISR-ID关联的衍生密钥，那么 SS与 SP可以使用与该 SS的 ISR- ID 关联的衍生密钥来保护双方的业务通信。
本发明的实施例还提供了一种实体认证系统， 该系统包括 E AC和 业务实体。
在该系统中， EAC 与业务实体之间的认证由业务实体发起， EAC 获取与业务实体之间进行认证的安全等级， 并获取该 EAC 与业务实体 均支持的且符合所述安全等级的认证方式， 然后， 该 EAC 与业务实体 按照所获取的认证方式进行认证并协商生成共享密钥， EAC为所生成的 共享密钥分配安全等级， 为该业务实体分配临时身份标识， 并关联存储 所分配的临时身份标识、 所生成的共享密钥和该共享密钥的安全等级， 之后， 将所分配的临时身份标识和该共享密钥的安全等级发送给业务实 体， 业务实体将接收到的该 EAC所分配的临时身份标识和该共享密钥 的安全等级与所生成的共享密钥关联存储。 该系统还包括实体签约数据 库 ESD, 存储用于保存安全等级与业务类型之间对应关系的业务安全等 级列表及该业务实体的签约信息。
在本实施例中， 该 EAC可以通过以下方式之一获取与业务实体之 间进行认证的安全等级：
由业务实体选定与所述 EAC之间进行认证的安全等级并上报给该 EAC, 在这种方式中， 业务实体可以选择通过预设的用户界面设置的安 全等级， 或选择业务所需求的安全等级， 或选择通过预设的用户界面设 置的安全等级和业务所需求的安全等级中等级高的一个安全等级作为 进行认证的安全等级；
由 EAC选定与业务实体进行认证的安全等级， 在这种方式中， 业 务实体向 EAC提供公开身份标识 UID; EAC根据该业务实体提供的 UID 确定业务类型，查询所述 ESD存储的业务安全等级列表获取该业务类型 对应的安全等级；
另外， 还可以由业务实体进行认证的安全等级并上报给 EAC, 同时 业务实体向 EAC提供 UID, 由 EAC根据该 UID确定业务类型， 并根据 业务等级列表获取该业务类型对应的安全等级， 并选择该业务实体上报 的安全等级和自身获取的安全等级中等级高的一个安全等级作为与业 务实体之间进行认证的安全等级。
在获取与业务实体进行认证的安全等级之后， EAC可以查询实体签 约数据库中存储的业务实体的签约信息， 获取该 EAC 与该业务实体均 支持的且符合该安全等级的认证方式。
本发明的实施例还提供了一种端到端认证的系统， 该系统包括 EAC、 业务请求实体和业务提供实体。
在该系统中， EAC用于获取与业务请求实体之间进行认证的安全等 级， 获取该 EAC 与该业务请求实体均支持的且符合所述安全等级的认 证方式， 与该业务请求实体按照所获得的认证方式进行认证并生成二者 之间的共享密钥， 为所生成的共享密钥分配所获取的与所述业务请求实 体之间进行认证的安全等级， 为该业务请求实体分配临时身份标识， 并 关联存储所分配的临时身份标识、 所生成的共享密钥和该共享密钥的安 全等级；
当该业务请求实体请求业务时， 若 EAC判断该业务请求实体具有 符合所请求的业务的安全等级需求的临时身份标识， 则采用该业务请求 实体的符合所请求的业务的安全等级需求的临时身份标识及其关联的 共享密钥生成用于保护该业务请求实体和该业务提供实体之间业务通 信的衍生密钥， 并发送给业务提供实体； 若判断该业务请求实体不具有 符合所请求的业务的安全等级需求的临时身份标识， 则通知该业务请求 实体重新发起认证， 并在该业务请求实体重新发起认证时， 生成新的共 享密钥， 为业务请求实体分配新的临时身份标识， 使用该新的临时身份 标识和新的共享密钥生成新的衍生密钥发送给业务提供实体。
业务请求实体可以按所述 EAC获取的认证方式与该 EAC进行认证 并生成共享密钥， 关联存储该 EAC 所分配的临时身份标识、 所生成的 共享密钥和该共享密钥的安全等级， 并在请求业务时采用该业务请求实 体的符合所请求的业务的安全等级需求的临时身份标识及其关联的共 享密钥生成用于保护该业务请求实体和该业务提供实体之间业务通信 的衍生密钥。
业务提供实体为该业务请求实体提供业务并用 EAC 生成的衍生密 钥保护与该业务请求实体之间的通信。
本发明的实施例还提供了一种实体认证中心 EAC, 包括第一单元和 第二单元。
在该系统中， 第一单元用于获取 EAC与业务实体之间进行认证的 安全等级， 并获取 EAC和业务实体均支持的认证方式， 并将获取的认 证方式发送给第二单元。 第二单元按照第一单元所获取的认证方式与业 务实体进行认证并生成共享密钥， 为所生成的共享密钥分配安全等级， 为业务实体分配临时身份标识， 并关联存储分配的临时身份标识、 所生 成的共享密钥和该共享密钥的安全等级。 该 EAC还包括第三单元， 用 于在业务实体请求业务时，根据该业务实体提供的公开身份标识 UID确 定业务类型， 并将确定的业务类型发送给第一单元， 以便第一单元获取 该第三单元确定的业务类型对应的安全等級。 该 EAC还可以包括第四 单元。 当业务实体请求业务时， 第四单元用于获取第二单元中与该业务 请求实体请求的业务对应的安全等级关联存储的该业务实体的临时身 份标识和共享密钥， 使用所获取的共享密钥生成衍生密钥； 否则， 要求 该业务实体重新进行认证。
在本实施例中， 第四单元可进一步判断该请求业务的业务实体是否 具有符合所请求业务的安全等级需求的临时身份标识， 如果具有， 则获 取第二单元中与该临时身份标识和安全等级关联存储的共享密钥， 使用 所获取的共享密钥生成衍生密钥， 并将所生成的衍生密钥发送给提供该 业务的业务实体； 否则， 要求该业务实体重新进行认证。
在上述实施例的流程中， 已经对该实体认证系统中各组成部分、 端 到端认证系统的各組成部分、 以及 EAC 的功能做了详细说明， 此处不 再进一步描述。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的 保护范围， 凡在本发明的精神和原则之内所做的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求书
1. —种实体认证的方法， 其特征在于， 当业务实体向实体认证中 心 EAC发起认证时， 所述方法包括：
所述 EAC获取与所述业务实体之间进行认证的安全等级， 并获取 所述 EAC与所述业务实体均支持的且符合所述安全等级的认证方式； 所述 EAC与所述业务实体按照获得的认证方式进行认证并生成共 享密钥， 为所述共享密钥分配所述安全等级， 并关联存储所述共享密钥 和所述安全等级；
所述业务实体关联存储自身生成的共享密钥和所述安全等级。
2. 根据权利要求 1所述的方法， 其特征在于， 所述 EAC获取与所 述业务实体之间进行认证的安全等级， 包括： 所述业务实体选定认证的 安全等级并上报给所述 EAC。
3. 根据杈利要求 1所述的方法， 其特征在于， 所述 EAC获取与所 述业务实体之间进行认证的安全等级， 包括：
所述业务实体向所述 EAC提供公开身份标识 UID, 所述 EAC根据 所述 UID确定业务类型， 并通过查询用于存储安全等级与业务类型之 间对应关系的业务安全等级列表， 获取所述业务类型对应的安全等級。
4.根据权利要求 1所述的方法， 其特征在于， 所述 EAC获取与所 述业务实体之间进行认证的安全等级， 包括：
所述业务实体选定认证的安全等级并上报给所述 EAC;
所述业务实体向所述 JBAC提供公开身份标识 UID, 所述 EAC根据 所述 UID确定业务类型， 并通过查询用于存储安全等级与业务类型之 间对应关系的业务安全等级列表， 获取所述业务类型对应的安全等级； 所述 EAC选择所述业务实体上报的安全等级与自身获取的安全等 等级。
5. 根据权利要求 2或 4所述的方法， 其特征在于， 所述业务实体选 定认证的安全等级并上报给所述 EAC 包括： 将所述业务实体选定的安 全等级信息携带在认证请求消息中发送给所述 EAC。
6.根据权利要求 1所述的方法， 其特征在于， 所述业务实体关联存 储自身生成的共享密钥和所述安全等级包括：
所述 EAC将所述安全等级发送给所述业务实体；
所述业务实体接收来自所述 EAC 的安全等级， 将接收到的安全等 级与自身生成的共享密钥关联存储。
7.根据权利要求 1至 6所述的方法，其特征在于，所述业务实体为： 业务请求实体或业务提供实体。
8.根据权利要求 1所述的方法， 其特征在于， 所述 EAC生成共享 密钥时为所述业务实体分配临时身份标识并提供给所述业务实体；
所述安全等级为： 设置于所述临时身份标识中的一个字段或者作为 单独的安全等级参数；
所述临时身份标识与所述安全等级和共享密钥关联存储。
9. 一种端到端的认证方法， 应用于包括实体认" ^中心 EAC、 业务 请求实体和业务提供实体的系统， 其特征在于， 该方法包括：
所述业务请求实体向所述 EAC发起认证时， 所述 EAC获取与所述 业务埼求实体之间进行认证的安全等级、 以及与所述业务请求实体均支 持的且符合所述安全等级的认证方式； 所述 EAC 与所述业务请求实体 按照获得的认证方式进行认证并分别生成共享密钥， 所述 EAC 为所生 成的共享密钥分配所述安全等级， 所述 EAC和所述业务请求实体分别 将各自生成的共享密钥与所述安全等级关联存储； 所述业务请求实体请求业务时， 采用所述业务请求实体的符合所请 求的业务的安全等级需求的共享密钥生成用于保护所述业务请求实体 和所述业务提供实体之间业务通信的衍生密钥。
10. 根据权利要求 9所述的方法， 其特征在于， 所述业务请求实体 请求业务时， 如果所述业务请求实体具有符合所请求的业务的安全等级 需求的共享密钥， 则采用所述共享密钥生成所述衍生密钥。
11. 根据权利要求 10 所述的方法， 其特征在于， 所述方法进一步 包括： 如果所述业务请求实体不具有符合所请求的业务的安全等级需求 的共享密钥， 则所述业务请求实体重新向所述 EAC发起认证。
12. 根据权利要求 11 所述的方法， 其特征在于， 如果所述业务请 求实体重新向所述 EAC发起认证， 则所述 EAC和所迷业务请求实体生 成新的共享密钥， 使用所述新的共享密钥生成新的衍生密钥。
13. 居权利要求 9所述的方法， 其特征在于， 所述业务请求实体 请求业务时， 所述业务请求实体向所述 EAC发起认证， 获得符合所请 求业务的安全等级需求的共享密钥， 所述业务请求实体和所述 EAC分 别采用所述共享密钥生成所述衍生密钥， 并由所述 EAC提供所述衍生 密钥给所述业务提供实体。
14. 居权利要求 10所述的方法， 其特征在于， 所述 EAC与所述 业务请求实体生成共享密钥时， 所述 EAC 为所述业务请求实体分配与 所述共享密钥及所述共享密钥的安全等级相关联的临时身份标识； 所述 业务请求实体请求业务时， 包括：
所述业务请求实体向所述 EAC请求业务， 并提供所述业务对应的 公开身份标识 UID;
所述 EAC查找得到所述 UID对应的安全等级， 并判断是否存有符 合所述安全等级需求的临时身份标识， 若有， 则所述 EAC和所述业务 请求实体分别釆用符合所述安全等级需求的共享密钥生成所述衍生密 钥， 并由所述 EAC提供所述衍生密钥给所述业务提供实体。
15. 根据权利要求 10所述的方法， 其特征在于， 所述 EAC与所述 业务请求实体生成共享密钥时， 所述 EAC 为所述业务请求实体分配与 所述共享密钥及所述共享密钥的安全等级相关联的临时身份标识； 所述 业务请求实体请求业务时， 包括：
所述业务请求实体查找到本地存储的符合所请求业务的安全等级 需求的临时身份标识， 向所述业务提供实体请求业务， 并提供所述业务 对应的 UID和所述临时身份标识给所述业务提供实体；
判断所述业务请求实体的临时身份标识对应的安全等级与所述 UID 对应的安全等级是否相符， 若相符， 则所述 EAC和所述业务请求实体 分别采用符合所述安全等级需求的共享密钥生成所述衍生密钥， 并由所 述 EAC提供所述衍生密钥给所述业务提供实体。
16. 根据权利要求 15 所述的方法， 其特征在于， 所述判断所述业 务请求实体的临时身份标识对应的安全等级与所述 UID 对应的安全等 级是否相符， 包括：
所述业务提供实体从所述 EAC 中查询得到所述业务请求实体的临 时身份标识对应的安全等级，并判断查询到的安全等级与所述 UID对应 的安全等级是否相符； 或者，
所述业务提供实体向所述 EAC提供所述业务请求实体的临时身份 标识和所述 U1D, 由所述 EAC判断所述临时身份标识对应的安全等级 与所述 UID对应的安全等级是否相符。
17. 根据权利要求 15 所述的方法， 其特征在于， 所述业务请求实 体进一步向所述业务提供实体提供安全等级；
所述判断所述业务请求实体的临时身份标识对应的安全等级与所 述 UID对应的安全等级是否相符， 包括：
所述业务提供实体判断所述业务请求实体提供的安全等级与所述 UID对应的安全等级是否相符， 若相符， 则提供所述业务请求实体的临 时身份标识给所述 EAC, 由所述 EAC判断所述临时身份标识是否合法。
18. 一种实体认证系统， 其特征在于， 所述系统包括： 实体认证中 心 EAC和业务实体；
所述 EAC, 获取与所述业务实体之间进行认证的安全等级， 获取所 述 EAC 与所述业务实体均支持的且符合所述安全等级的认证方式， 按 照所获取的认证方式与所述业务实体进行认证并生成共享密钥， 为所生 成的共享密钥分配所述安全等级， 并关联存储所生成的共享密钥和所述 安全等级；
所述业务实体， 按所述 EAC获取的认证方式与所述 EAC进行认证 并生成共享密钥， 关联存储所生成的共享密钥和所述的安全等级。
19.根据权利要求 18所述的系统， 其特征在于，
所述业务实体， 选定与所述 EAC之间进行认证的安全等级并上报 给所述 EAC;
所述 EAC, 获取来自所述业务实体选定的认证的安全等级。
20.才艮据权利要求 18所述的系统， 其特征在于， 所述系统进一步包 括实体签约数据库 ESD,存储用于保存安全等级与业务类型之间对应关 系的业务安全等级列表；
所述 EAC, 查询所述实体签约数据库， 获取与所述业务实体之间进 行认证的安全等级、 以及所述 EAC 与所述业务实体均支持的且符合所 述安全等级的认证方式。
21. 根据权利要求 20所述的系统， 其特征在于，
所述业务实体， 提供公开身份标识 UID; 所述 EAC， 根据所述业务实体提供的 UID确定业务类型， 查询所 述 ESD存储的业务安全等级列表获取所述业务类型对应的安全等级。
22. 根据权利要求 20所述的系统， 其特征在于，
所述业务实体， 选定认证的安全等级并上报给所述 EAC;
所述 EAC, 根据所述业务实体提供的 UID确定业务类型， 查询所 述 ESD存储的业务等级列表获取所述业务类型对应的安全等级，并选择 所述业务实体上报的安全等级和自身获取的安全等级中等级高的一个 安全等级作为与所述业务实体之间进行认证的安全等级。
23. 一种端到端的认证系统， 其特征在于， 所述系统包括： 实体认 证中心 EAC、 业务请求实体和业务提供实体；
所述 EAC, 获取与所述业务请求实体之间进行认证的安全等级， 获 取所述 EAC 与所述业务请求实体均支持的且符合所述安全等级的认证 方式， 与所述业务请求实体按照所获得的认证方式进行认证并生成共享 密钥， 为所生成的共享密钥分配所述安全等级， 并关联存储所生成的共 享密钥和所述安全等级； 当所述业务请求实体请求业务时， 釆用所述业 务请求实体的符合所请求的业务的安全等级需求的共享密钥生成用于 保护所述业务请求实体和所述业务提供实体之间业务通信的衍生密钥； 所述业务请求实体， 按所述 EAC获取的认证方式与所述 EAC进行 认证并生成共享密钥， 关联存储所生成的共享密钥和所述安全等级， 并 在请求业务时采用所述业务请求实体的符合所请求的业务的安全等级 需求的共享密钥生成用于保护与所述业务提供实体之间业务通信的衍 生密钥；
所述业务提供实体， 为所述业务请求实体提供业务并用所述 EAC 生成的衍生密钥保护与所述业务请求实体之间的通信。
24. 根据权利要求 23所述的系统， 其特征在于， 所述 EAC若判断 所述业务请求实体具有符合所请求的业务的安全等级需求的共享密钥， 则采用所述共享密钥生成所述衍生密钥。
25. ^^据权利要求 24所述的系统， 其特征在于， 所述 EAC若判断 所述业务请求实体不具有符合所请求的业务的安全等级需求的共享密 钥， 则通知所述业务请求实体重新发起认证。
26. 才艮据权利要求 25所述的系统， 其特征在于， 所述 EAC在所述 业务请求实体重新发起认证时， 生成新的共享密钥， 并使用所述新的共 享密钥生成新的衍生密钥。
27. 一种实体认证中心 EAC, 其特征在于， 包括：
第一单元， 获取与业务实体之间进行认证的安全等级， 并获取所述 EAC和所述业务实体均支持的认证方式；
第二单元， 按照第一单元所获取的认证方式进行认证并生成共享密 钥， 为所生成的共享密钥分配第一单元获取的安全等级， 并关联存储所 生成的共享密钥和所述安全等级。
28.根据权利要求 27所述的 EAC, 其特征在于， 所述 EAC进一步 包括：
第三单元，根据请求业务的业务实体提供的公开身份标识 UID确定 业务类型；
所述第一单元， 获取所述第三单元确定的业务类型对应的安全等 级。
29.根据权利要求 27所述的 EAC, 其特征在于， 所述 EAC进一步 包括：
第四单元， 所述业务实体请求业务时获取所述第二单元中与所述业 务实体请求的业务对应的安全等级关联存储的共享密钥， 使用所获取的 共享密钥生成衍生密钥。
30.根据权利要求 29所述的 EAC,其特征在于，所述第四单元若判 断所述请求业务的业务实体具有符合所请求业务的安全等级需求的共 享密钥， 则获取所述第二单元中存储的共享密钥， 使用所获取的共享密 钥生成衍生密钥。
PCT/CN2007/000141 2006-01-13 2007-01-15 Procédé et système d'authentification d'entité, procédé et système d'authentification de bout en bout et centre d'authentification WO2007079698A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610001154A CN101001144B (zh) 2006-01-13 2006-01-13 一种实体认证中心实现认证的方法
CN200610001154.8 2006-01-13

Publications (1)

Publication Number Publication Date
WO2007079698A1 true WO2007079698A1 (fr) 2007-07-19

Family

ID=38255999

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/000141 WO2007079698A1 (fr) 2006-01-13 2007-01-15 Procédé et système d'authentification d'entité, procédé et système d'authentification de bout en bout et centre d'authentification

Country Status (2)

Country Link
CN (1) CN101001144B (zh)
WO (1) WO2007079698A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009524369A (ja) * 2006-01-24 2009-06-25 ▲ホア▼▲ウェイ▼技術有限公司 モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタ

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330757B (zh) * 2008-07-28 2011-07-13 中兴通讯股份有限公司 一种下一代网络中业务安全等级实现方法
CN101383828B (zh) * 2008-10-13 2011-12-21 中国电信股份有限公司 一种JavaScript对象的调用方法、系统和终端
CN102098297A (zh) * 2010-12-29 2011-06-15 中兴通讯股份有限公司 一种家庭信息机及其认证方法
CN102905258B (zh) * 2011-07-27 2018-03-13 中兴通讯股份有限公司 自有业务认证方法及系统
CN103957103B (zh) * 2014-04-17 2017-07-04 小米科技有限责任公司 安全验证的方法、装置及移动终端
CN105635039B (zh) 2014-10-27 2019-01-04 阿里巴巴集团控股有限公司 一种网络安全通信方法及通信装置
US9832024B2 (en) 2015-11-13 2017-11-28 Visa International Service Association Methods and systems for PKI-based authentication
WO2018058544A1 (zh) * 2016-09-30 2018-04-05 华为技术有限公司 一种业务认证方法、系统及相关设备
CN111865569B (zh) * 2019-04-28 2022-08-26 华为技术有限公司 一种密钥协商方法及装置
EP3906637A4 (en) * 2019-05-09 2022-03-09 Samsung Electronics Co., Ltd. METHOD AND DEVICE FOR ADMINISTRATION AND VERIFICATION OF CERTIFICATES

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1365562A (zh) * 1999-05-28 2002-08-21 艾利森电话股份有限公司 用于保密通信的方法和设备
CN1501656A (zh) * 2002-11-19 2004-06-02 华为技术有限公司 一种选择802.1x认证方式的方法
WO2004073252A1 (ja) * 2003-02-14 2004-08-26 Sony Corporation 認証処理装置及びセキュリティ処理方法
JP2005346310A (ja) * 2004-06-01 2005-12-15 Canon Inc 情報処理装置および方法ならびに情報処理システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1365562A (zh) * 1999-05-28 2002-08-21 艾利森电话股份有限公司 用于保密通信的方法和设备
CN1501656A (zh) * 2002-11-19 2004-06-02 华为技术有限公司 一种选择802.1x认证方式的方法
WO2004073252A1 (ja) * 2003-02-14 2004-08-26 Sony Corporation 認証処理装置及びセキュリティ処理方法
JP2005346310A (ja) * 2004-06-01 2005-12-15 Canon Inc 情報処理装置および方法ならびに情報処理システム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009524369A (ja) * 2006-01-24 2009-06-25 ▲ホア▼▲ウェイ▼技術有限公司 モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタ
US8468353B2 (en) 2006-01-24 2013-06-18 Huawei Technologies Co., Ltd. Method, system and authentication centre for authenticating in end-to-end communications based on a mobile network

Also Published As

Publication number Publication date
CN101001144B (zh) 2010-05-12
CN101001144A (zh) 2007-07-18

Similar Documents

Publication Publication Date Title
WO2007079698A1 (fr) Procédé et système d'authentification d'entité, procédé et système d'authentification de bout en bout et centre d'authentification
CN109511115B (zh) 一种授权方法和网元
KR102018971B1 (ko) 네트워크 액세스 디바이스가 무선 네트워크 액세스 포인트를 액세스하게 하기 위한 방법, 네트워크 액세스 디바이스, 애플리케이션 서버 및 비휘발성 컴퓨터 판독가능 저장 매체
US8275355B2 (en) Method for roaming user to establish security association with visited network application server
US7941121B2 (en) Method for verifying the validity of a user
CN1681238B (zh) 用于加密通信的密钥分配方法及系统
JP4619788B2 (ja) Ｗｌａｎ相互接続における識別情報の保護方法
JP4000111B2 (ja) 通信装置および通信方法
US9641324B2 (en) Method and device for authenticating request message
CA2552917C (en) A method of obtaining the user identification for the network application entity
US20090240941A1 (en) Method and apparatus for authenticating device in multi domain home network environment
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
WO2019137030A1 (zh) 安全认证方法、相关设备及系统
JP2004046430A (ja) リモートアクセスシステム、リモートアクセス方法、リモートアクセスプログラム及びリモートアクセスプログラムが記録された記録媒体
KR20170106515A (ko) 다중 팩터 인증 기관
WO2006000152A1 (fr) Procede pour la gestion d'equipement d'utilisateur d'acces au reseau au moyen de l'architecture d'authentification generique
WO2009097778A1 (zh) 一种安全接口调用方法、装置及系统
WO2013040957A1 (zh) 单点登录的方法、系统和信息处理方法、系统
CN114938280A (zh) 一种基于非交互零知识证明与智能合约的认证方法及系统
CN107295510B (zh) 基于ocsp实现家庭基站准入控制的方法、设备及系统
WO2009018778A1 (fr) Procédé, dispositif et système pour dispositif sans carte accédant à un réseau personnel
JP2005217679A (ja) 通信相手の認証を行う認証サーバ
WO2011131002A1 (zh) 身份管理方法及系统
WO2007095806A1 (fr) Système d'authentification générale et procédé d'accès à la fonction d'application de réseau du système
WO2007031027A1 (fr) Procede, systeme et appareil de negociation de cle entre ss et sp

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07702073

Country of ref document: EP

Kind code of ref document: A1