WO2013004104A1 - Procédé et système de signature unique - Google Patents

Procédé et système de signature unique Download PDF

Info

Publication number
WO2013004104A1
WO2013004104A1 PCT/CN2012/074932 CN2012074932W WO2013004104A1 WO 2013004104 A1 WO2013004104 A1 WO 2013004104A1 CN 2012074932 W CN2012074932 W CN 2012074932W WO 2013004104 A1 WO2013004104 A1 WO 2013004104A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
terminal
authentication center
center
noncel
Prior art date
Application number
PCT/CN2012/074932
Other languages
English (en)
Chinese (zh)
Inventor
张孟旺
田甜
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2013004104A1 publication Critical patent/WO2013004104A1/fr

Links

Classifications

    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to the field of communications, and in particular to a single sign-on method and system. Background technique
  • the IMS UE has a Universal Integrated Circuit Card (UICC), and the network operator has deployed the General Bootstrapping Architecture (GBA): At this time, the GB A authentication mechanism can be used to freely cooperate with the Alliance. ( Liberty Alliance ) / Open Identity ( OpenID ) combines with single sign-on and interoperability with other existing SSO mechanisms. In this scenario, in order to implement SSO, the operator deploys a large number of GBAs, and at the same time embeds a UICC card in each IMS UE, and uses the information in the GBA and UICC cards to complete the SSO function of accessing the application server to the IMS terminal.
  • GBA General Bootstrapping Architecture
  • the IMS UE has a UICC card, but the operator cannot deploy the GBA. In this case, the UE terminal user needs to be authenticated.
  • the IMS terminal implements the SSO function of the AS application server, authentication and key agreement are used. (Authentication and Key Agreement, AKA) / OpenID combined program. details as follows:
  • the IMS UE sends an authentication request to the application server (Application Server, AS/RP), where the request includes an OpenID identifier; the RP uses the OpenID identifier to discover the final uniform resource locator of the OpenID Provider (OP) ( Uniform/Universal Resource Locater, URL), and redirect the user authentication request to the URL; OP obtains AKA from Home Subscriber Server (HSS) The authentication vector and the user terminal information content based on the IP Multimedia Private Identity (IMI); the OP sends an authentication challenge to the UE by using the AKA authentication method, so that the UE authenticates the network; the UE sends a challenge to the OP to the challenge.
  • AS/RP Application Server
  • the RP uses the OpenID identifier to discover the final uniform resource locator of the OpenID Provider (OP) ( Uniform/Universal Resource Locater, URL), and redirect the user authentication request to the URL; OP obtains AKA from Home Subscriber Server (HSS)
  • HSS Home Subscriber Server
  • IMI IP Multi
  • the UE is authenticated in the OP; the OP sends a flag information asserting that the OpenID identifier belongs to the terminal to the UE, and the assertion is used by the OP to share the shared key between the OP and the RP (the key may be the sharing of the OP and the RP)
  • the key which may also be the key of the OP itself, is redirected; the assertion reaches the RP; if the OP is shared with the RP, the RP directly verifies the signature information and notifies the UE of the verification result. If the OP's own key encryption is used, the RP transmits the duplicate of the assertion to the OP for verification. After the OP is verified, the verification result is notified to the RP, and finally the RP notifies the UE of the verification result.
  • the architecture enables the network operator to act as an OpenID provider to provide authentication services for users accessing the WEB month server.
  • OIM identification in IMS
  • users can provide SSO functionality across IMS and web servers. Allow users to control their public identity identifier on the WEB. By accessing the WEB application controlled by a trusted network operator, the user can improve the security of the user's own information.
  • the IMS UE does not have a UICC card, and the operator does not deploy the GBA.
  • the non-UICC card terminal accesses the IMS network, the probability of this situation increases, and GBA and non-distribution are not deployed.
  • a UICC card users often need to access the IMS network and use IMS-related application services.
  • non-UICC-based IMS-SSO authentication becomes very necessary.
  • the related art has not proposed how to perform the SSO function in this scenario.
  • the main object of the present invention is to provide a single sign-on method and system for supporting authentication of a terminal single sign-on RP without a UICC.
  • a single sign-on method including:
  • the terminal sends a service request to the application server RP;
  • the RP obtains an authentication center address
  • the RP redirects its own authentication request to the authentication center through the terminal, or the RP returns a response to the terminal to instruct the terminal to perform authentication to the authentication center.
  • the authentication center authenticates the terminal by using the session initial protocol summary SIP Digest authentication mode, and redirects the authentication result to the RP through the terminal; in the authentication process using the SIP Digest authentication mode, the authentication Both the center and the terminal generate the shared key using the same hash value and random number;
  • the RP provides a service for the terminal according to the authentication result.
  • the authentication center Before the authentication center authenticates the terminal by using the SIP Digest authentication mode, the authentication center further includes:
  • the authentication center determines whether there is a first shared key K0 with the terminal, and if not, continues the subsequent processing; if yes, directly redirects the authentication result to the RP.
  • the RP obtains the address of the authentication center, redirects the self-authentication request to the authentication center, or the RP returns a response to the terminal for instructing the terminal to perform authentication to the authentication center;
  • the RP authentication request carries the RP identity RP_credential; the terminal follows the redirect message or sends an authentication message to the authentication center;
  • the authentication center authenticates the RP according to the RP identity identifier and saves the authentication result.
  • the authentication center performs authentication on the terminal by using a SIP Digest authentication method, including:
  • the authentication center authenticates the terminal according to a SIP Digest authentication vector corresponding to the terminal.
  • the authentication center obtains and stores the SIP Digest authentication vector corresponding to the terminal from the home subscriber register HSS according to the user identity.
  • the SIP Digest authentication vector includes at least one of the following: a user identity identifier, an authentication algorithm algorithm, a quality guarantee, a scope realm, a hash value H(A1), where H(A1) is identified by a user identity.
  • the realm and password password are composed.
  • the authentication center performs authentication on the terminal by using a SIP Digest authentication method, including:
  • the authentication center generates a random number nonce, and carries the algorithm, and the message of the nonce and the realm is sent to the terminal;
  • the terminal generates a random number cnonce, according to the nonce, the cnonce and a hash value H(A1) generated by the realm, the user identity and the input password, and the response value response is generated by the algorithm, Returning a response message to the authentication center, where the response message carries the cnonce, the nonce, the realm, the response, and the algorithm;
  • the authentication center uses the algorithm to calculate the verification response value Xresponse according to the H(A1), the nonce, and the cnonce, and compares the received response with the Xresponse. If the authentication is the same, the authentication succeeds. Otherwise, the authentication fails; calculate the value of the rspauth parameter of the SIP Digest authentication mechanism.
  • the method further includes: the terminal calculating, according to the H(A1) and the cnonce, a first shared key K0 between the authentication center and the terminal;
  • the method further includes: the authentication center calculates and stores the K0 according to the H(A1) and the cnonce, and calculates an rspauth of the SIP Digest authentication mechanism. Parameter value.
  • the user identity is an open identity identifier OpenID
  • the authentication center is an OpenID provider OP.
  • the user identity is an identity identifier input to the terminal or the terminal is in an Internet Protocol multimedia subsystem.
  • the obtained identity identifier is allocated on the IMS system, and the authentication center is a single sign-on authentication center IdP.
  • the authentication center is the IdP and the authentication center is successfully authenticated when the user identity is an identity that is input to the terminal or an identity that is obtained by the terminal on the IMS system. Next, it also includes:
  • the authentication center generates a random number noncel, and generates a second key K1 according to the noncel and the first shared key K0 between the authentication center and the terminal;
  • the authentication center encrypts the noncel and the authentication result RP_Auth of the RP by using the K0, and obtains a KO (noncel, RP_Auth), and encrypts the K1 and the pair by using a shared key Kr, i between the RP and the RP.
  • the authentication result UE_Auth of the terminal is obtained by Kr, i (K1, UE_Auth); the terminal obtains the K0 (noncel, RP_Auth) by redirecting the terminal to the redirect message of the RP in the authentication center. After the rspauth parameter value and Kr,i(Kl,UE_Auth), redirect Kr,i(Kl,UE_Auth) to the RP;
  • the terminal decrypts the KO (noncel, RP_Auth) to obtain an authentication result for the RP, and the terminal generates an rspauth parameter value in the same manner as the authentication center, compares the generated rspauth and decrypts to obtain an rspauth value, After the network authentication succeeds, the terminal generates a second key K1; and the RP decrypts the Kr, i (K1, UE_Auth), Encrypting the service content by using the K1 and sending the content to the terminal;
  • the terminal decrypts using K1 to obtain the service content.
  • the authentication center is an OP, and the authentication center is successfully authenticated, the method further includes:
  • the authentication center generates a random number noncel, and generates a second key K1 according to the noncel and the first shared key K0 between the authentication center and the terminal;
  • the authentication center encrypts the noncel and the authentication assertion RP_Assert of the RP by using the K0, obtains a KO (noncel, RP_Assert), and encrypts the K1 and the pair by using a shared key ⁇ , ⁇ with the RP.
  • the authentication of the terminal asserts UE_Assert to obtain Kr,o(Kl,UE_Assert);
  • the authentication center sends the 200 OK information carrying the KO (noncel, RP_Auth) and rspauth parameter values to the terminal, and redirects Kr, o (K1, UE_Auth) to the RP, or the terminal is in the authentication center. Redirecting the terminal to the redirect message of the RP to obtain the KO (noncel, RP_Assert), rspauth parameter value, and Kr, o (Kl, UE_Assert), and then Kr, o (Kl, UE_Assert) Directed to the RP;
  • the terminal decrypts the KO (noncel, RP_Assert), obtains an authentication assertion for the RP, and obtains an rspauth parameter value from the message, and the terminal generates an rspauth parameter value in the same manner as the authentication center, and the generated result is compared.
  • the rspauth and the decryption obtain the rspauth value, the terminal completes the authentication of the network, and after the network authentication succeeds, the terminal generates the second key K1; and the RP decrypts the Kr, o (Kl, UE_Assert), using the K1 Encrypting the service content and transmitting to the terminal;
  • the terminal decrypts using K1 to obtain the service content.
  • the authentication center is an OP, and the authentication center is successfully authenticated, the method further includes:
  • the authentication center generates a random number noncel, according to the noncel and the authentication center and
  • the first shared key K0 between the terminals generates a second key K1;
  • the authentication center encrypts the information content such as the noncel with the K0, obtains KO (noncel), encrypts the K1 and the authentication assertion UE_Assert for the terminal by using the shared key ⁇ , ⁇ with the RP, Get Kr,o(Kl,UE_Assert);
  • the authentication center sends the 200 OK information carrying the values of the KO (noncel) and rspauth parameters to the terminal and redirects the Kr, o (K1, UE_Auth) to the RP, or the terminal at the authentication center Redirecting the terminal to the redirect message of the RP to obtain the KO (noncel), rspauth parameter value, and Kr, o (Kl, UE_Assert), and then redirecting Kr, o (Kl, UE_Assert) to the RP;
  • the terminal decrypts the KO (noncel), obtains a noncel, and obtains an rspauth parameter value from the message, and the terminal generates an rspauth parameter value in the same manner as the authentication center, compares the generated rspauth and decrypts the rspauth value,
  • the terminal completes the authentication of the network. After the network authentication succeeds, the terminal generates a second key K1. And, the RP decrypts the Kr, o (K1, UE_Assert), encrypts the service content by using the K1, and sends the content to the Terminal
  • the terminal decrypts using K1 to obtain the service content.
  • a single sign-on system including:
  • a terminal configured to send a service request to the RP, send an authentication request to the authentication center, and generate a shared key by using the same hash value and a random number by the authentication center;
  • the RP is configured to obtain the authentication center address and redirect its own authentication request to the authentication center by using the terminal, or the RP is configured to obtain the authentication center address and return it to the terminal for Instructing the terminal to respond to the authentication center for authentication;
  • the authentication center is configured to authenticate the terminal by using a SIP Digest authentication mode, redirect the authentication result to the RP by using the terminal, and generate a shared key by using the same hash value and random number by the terminal. .
  • the authentication center is further configured to authenticate the RP according to the RP identity and save the authentication result.
  • the authentication center is further configured to generate a secure communication key, and redirect the secure communication key to the RP by using the terminal; the RP is further configured to encrypt the service content by using the secure communication key. And sending to the terminal; the terminal is further configured to generate the secure communication key, and use the secure communication key to decrypt to obtain the service content.
  • the RP redirects the UE's request to the authentication center or sends information to the UE indicating that it needs to authenticate to the authentication center.
  • the authentication center adopts the session initial protocol summary according to the received user identity.
  • the session authentication protocol is used to authenticate the UE and the authentication result is redirected to the RP.
  • FIG. 1 is a flow chart of a single sign-on method according to an embodiment of the present invention.
  • FIG. 2 is a structural block diagram of a single sign-on system according to an embodiment of the present invention.
  • FIG. 3 is a flowchart of a process of implementing a single sign-on authentication to an application server by using an SIP Digest authentication mechanism by an IMS terminal of a non-UICC card according to Embodiment 1;
  • FIG. 4 is an overall architecture diagram of an IMS terminal providing an IMS terminal for a non-UICC card to an application server for single sign-on authentication by using an SIP Digest authentication mechanism provided by an operator according to an embodiment of the present invention
  • FIG. 5 is another single embodiment according to an embodiment of the present invention. Flow chart of the point login method
  • FIG. 6 is a flowchart of a single sign-on authentication of an IMS terminal to an application server of an IMS terminal that implements a non-UICC card by using an SIP Digest authentication mechanism by an operator as an OpenID Provider according to Embodiment 2;
  • FIG. 7 is a schematic diagram of an overall architecture of an IMS terminal to an application server for a single sign-on authentication by an IMS terminal that implements a SIP Digest authentication mechanism by an operator as an OpenID Provider according to an embodiment of the present invention.
  • Step S102 A terminal sends a service request to an RP.
  • Step S104 The RP obtains the IdP address of the authentication center, and redirects the authentication request to the authentication center through the terminal.
  • the RP returns a response to the terminal to indicate that the terminal authenticates to the authentication center.
  • Step S106 The terminal sends an authentication request of the terminal to the authentication center.
  • Step S108 The authentication center authenticates the terminal by using the SIP Digest authentication mode, and redirects the authentication result to the RP through the terminal.
  • Step S110 The RP provides a service for the terminal according to the authentication result.
  • the terminal does not send its own identity information to the RP, the RP does not obtain the identity information of the UE, and does not authenticate the terminal, but uses a certain mechanism to enable the terminal to initiate an authentication request to the terminal to the authentication center. .
  • the RP can be used to perform the authentication by using the two mechanisms.
  • the RP returns the response to the authentication center that the terminal is to the contracted authentication center.
  • the other type authenticates the redirected RP authentication message that is redirected to the authorized authentication center by the RP.
  • the request message is sent to the contract authentication center. This means that the RP redirects its own authentication request to the authentication center through the terminal. In this way, the terminal sends its own authentication request to the authentication center by means of the redirection process.
  • the RP cannot obtain the identity information of the terminal, and the terminal directly authenticates to the trusted authentication center to prevent the user identity information from being leaked to the RP, thereby improving security.
  • the SSO function of the UE to the application server is generally implemented by a combination of Liberty Alliance/OpenID or AKA/OpenID.
  • the two methods only support the authentication of the UICC identity information, and therefore only apply to the UE terminal.
  • the number of UEs that do not have a UICC card is increasing. Therefore, a new mechanism is needed to support the UE terminal of the non-UICC card to implement the SSO function.
  • the method in this embodiment uses SIP Digest authentication.
  • the type of supported user identity is not limited to UICC identity information, and therefore, authentication of a terminal that does not have a UICC can be supported.
  • the network operator can complete the unified authentication of the UE using the AS as a user authentication center provider, and facilitate the access of various application servers to the terminal.
  • the network operator can provide a large number of user groups for the application service provider.
  • the operator can cooperate with the AS provider to better meet the needs of the user group for various application services, and the user accesses the related application server through the trusted network operator. Not only provides users with convenience but also increases the security of user information and also expands the profitability of operators.
  • the authentication center may determine whether there is a first shared key K0 with the UE, and if not, continue the subsequent processing, if yes, skip The authentication center uses the SIP Digest authentication mode to authenticate the UE and directly redirects the authentication result to the RP. Through the above judging steps, the authentication center can directly return the authentication result to the RP to the authenticated UE, thereby improving the processing speed.
  • the RP may also redirect the RP authentication request to the authentication center, where the RP authentication request carries the RP identity RP_credential; the authentication center authenticates the RP according to the RP identity and saves the authentication result.
  • the UE of the non-UICC card can implement the SSO function of the legitimate application server in the IMS network, and the two-way authentication can better ensure the security of the identity information of the IMS terminal, and can correctly identify the non- The application server improves the security of the service.
  • the above user identity may be an open identity (OpenID), and the authentication center may be an OP; or the user identity may be an identity input to the UE or the UE is allocated in an Internet Protocol Multimedia Subsystem (IMS) system.
  • IMS Internet Protocol Multimedia Subsystem
  • the obtained identity, the certificate authority can be a single sign-on authentication center (IdP).
  • the authentication center uses the SIP Digest authentication mode to authenticate the UE.
  • the following processing method is adopted: the authentication center authenticates the terminal according to the SIP Digest authentication vector (SD-AV) corresponding to the terminal.
  • SD-AV SIP Digest authentication vector
  • the (SD-AV) may be obtained and stored by the authentication center from the HSS according to the user identity, where the SD-AV includes at least one of the following: a user identity, an authentication algorithm, a quality assurance, a scope ( Realm ) and a hash value H(A1), where H(A1) consists of the user ID, realm, and password (password).
  • the process of authenticating the terminal by using the SIP Digest authentication mode by the authentication center may include: the authentication center generates a random number nonce, and sends a message carrying algorithms, nonce, and realm to the UE; the UE generates a random number cnonce According to the nonce, the cnonce, and the H(A1) generated by the realm, the user identity, and the previously stored password, the response value is generated by using the algorithm, and the response message is returned to the certificate center, where the response message carries the CNNC, the nonce, the realm, the response And the algorithm; the authentication center uses the algorithm to calculate the verification response value Xresponse according to the stored H(A1), the stored nonce, the received cnonce, and the response to the Xresponse.
  • the authentication center calculates the rspauth value under the SIP Digest authentication mechanism.
  • the operator can provide two-way authentication for both the user and the accessed application server by providing the IdP unified authentication center, which can implement the SSO function in scenario 3 well.
  • the calculation basis of the response may further include: using the same when the UE calculates the response The number of times a nonce is used. Using nonce-count also participates in the response calculation, which can reduce the possibility of replaying attacks.
  • the UE can calculate K0 by using the authentication algorithm according to H(A1) and CNNOce; using SIP Digest in the authentication center.
  • the authentication center can calculate K0 according to the authentication algorithm and store it.
  • the authentication center and the UE may generate a shared key K0 between the two according to the parameters of the authentication process interaction, and the authentication center may determine whether the UE has been authenticated according to whether the shared key is stored.
  • the authentication center is an IdP, and the authentication center is successfully authenticated, the authentication center generates a random number nonce 1 according to the nonce 1 and K0 generate a second key K1; the authentication center uses K0 to encrypt noncel and the RP authentication result RP_Auth to obtain KO (noncel, RP_Auth), and uses the shared key Kr, i between the RP and the RP to encrypt K1 and authenticate the UE.
  • UE_Auth obtains Kr, i (Kl, UE_Auth); the authentication center sends 200 OK information carrying the values of KO (noncel, RP_Auth) and rspauth parameters to the terminal and redirects Kr, i (Kl, UE_Auth) to the RP, or the terminal is
  • the authentication center redirects the terminal to the RP redirect message to obtain KO (noncel, RP_Auth), rspauth parameter value and Kr, i (Kl, UE_Auth) and then redirects Kr, i (Kl, UE_Auth) to the RP;
  • UE decrypts K0 (noncel, RP_Auth) obtains the authentication result of the RP, uses the same method as the authentication center to generate the rspauth parameter value, and compares with the rspauth in the received information to complete the terminal-to-network authentication process;
  • One processing method is that the authentication center generates a random number noncel, and generates a second key K1 according to nonce 1 and K0; the authentication center uses K0 to encrypt noncel and the RP authentication assertion RP_Assert to obtain KO (noncel, RP_Assert), and between the RP and the RP
  • the shared key Kr, i encrypts K1 and authenticates to the UE asserts that UE_Assert gets Kr,o(Kl,UE_Assert); the authentication center sends 200OK information carrying the KO (noncel, RP_Auth) and rspauth parameter values to the terminal and Kr,o (Kl, UE_Auth) is redirected to the RP, or the terminal obtains KO (noncel, RP_Assert), rspauth parameter value, and Kr, o (Kl, UE_Assert) after the authentication center redirects the terminal to the
  • i(Kl, UE_Assert) is redirected to the RP; the UE decrypts K0 (noncel, RP_Assert), obtains the authentication assertion for the RP, and generates the rspauth parameter value in the same way as the authentication center, and compares with the rspauth in the received information.
  • the second key K1 is generated; and, the RP decrypts Kr,o(Kl, UE_Assert), and uses the K1 encryption service content to be sent to the UE; the UE uses K1 to solve the problem. Secret access to service content.
  • Another processing method is that the authentication center generates a random number noncel, and generates a second key K1 according to noncel and K0; the authentication center uses K0 encryption noncel to obtain KO (noncel), and uses the shared key Kr, i between the RP and the RP to encrypt K1.
  • the authentication center sends 200OK information carrying the KO (noncel) and rspauth parameter values to the terminal and redirects Kr,o(Kl,UE_Auth) to the RP, or
  • the terminal redirects the Kr, i (Kl, UE_Assert) to the RP after obtaining the K0 (noncel), rspauth parameter value, and Kr, o (Kl, UE_Assert) in the redirection message redirecting the terminal to the RP in the authentication center;
  • the RP decrypts Kr, o (Kl,
  • the RP authentication result is sent to the terminal UE, and the terminal trusts the authentication center.
  • the authentication center authentication RP passes the information to the UE. If the terminal UE can receive the KO (noncel) from the authentication center, it indicates that the RP authentication is passed. The terminal UE is explicitly notified.
  • the interaction information between the authentication center and the UE, and between the authentication center and the RP is encrypted by using the corresponding shared key to ensure the information exchange security between the authentication center and the UE and the authentication center and the RP.
  • a K1 is generated, so that the service content of the interaction between the UE and the RP is encrypted by using K1, thereby preventing illegal interception of user data, thereby further improving security.
  • the above method adopts the SIP Digest authentication mechanism, which is applicable not only to the authentication of the terminal of the non-UICC but also to the authentication of the UICC terminal, and does not need to configure a large number of GBAs, thereby reducing the deployment of the GBA and the embedded by the network operator.
  • the cost of the UICC card is applicable not only to the authentication of the terminal of the non-UICC but also to the authentication of the UICC terminal, and does not need to configure a large number of GBAs, thereby reducing the deployment of the GBA and the embedded by the network operator. The cost of the UICC card.
  • FIG. 2 is a structural block diagram of a single sign-on system according to an embodiment of the present invention.
  • the system includes: a UE 22, configured to send a request message to the RP 24;
  • the authentication request is redirected to the authentication center 26, and the UE 22 is served according to the authentication result of the authentication center 26.
  • the authentication center 26 is configured to authenticate the UE 22 by using the SIP Digest authentication method, and pass the authentication result to the UE 22. Redirect to RP 24.
  • the Certification Authority 26 is also used to authenticate the RP 24 based on the RP identity and to save the authentication results.
  • the authentication center 26 is an OP; in the case that the user identity is an identity input to the UE or the UE assigns the obtained identity in the IMS system, the authentication center 26 is an IdP. .
  • the authentication center 26 is further configured to generate a secure communication key and redirect the secure communication key to the RP 24 through the UE 22; the RP 24 is also operative to encrypt the service content with the secure communication key and send it to the UE 22
  • the UE 22 is further configured to generate the secure communication key, and use the secure communication key to decrypt to obtain the service content.
  • the UE is an IMS non-UICC card terminal
  • the RP corresponds to an application server to be accessed by the IMS terminal
  • the IdP/OP corresponds to an SSO subsystem provided by the network operator.
  • the specific network element interfaces of some networks that have no impact on the process are not drawn and the supported protocols are not described.
  • the functions and related protocols supported are not shown; the interface reference point between HSS and IdP can implement the Diameter protocol, and the Cx interface in the IMS core network can be reused.
  • Both the UE and the IdP must support the SIP Digest authentication mechanism. Nor is it indicated in the figure; for the sake of brevity, these specific interface reference points are not shown in the figure.
  • the negotiation mechanism of the shared key between the RP and the IdP can be successfully implemented by using the existing mechanism.
  • the IdP authenticates the RP. Now, the mature mechanism has been successfully implemented.
  • Embodiments 1 and 2 described below combine the technical solutions of the above-described plurality of preferred embodiments.
  • Example 1
  • This embodiment provides a method for implementing an SSO function on an application server in a unified IMS network based on a SIP Digest authentication mechanism.
  • a mechanism for mutual authentication of both the UE terminal and the AS server is performed; the UE terminal of the non-UICC card in the IMS network can implement the SSO function for its application server; and has better performance than OpenlD/AKA Universality and security ensure the security of both the UE user terminal and the AS server.
  • FIG. 4 is an overall architecture diagram of an IMS terminal provided by an operator to implement a single sign-on authentication of an IMS terminal of a non-UICC card to an application server by using an SIP Digest authentication mechanism according to an embodiment of the present invention
  • FIG. 3 is a non-UICC card according to Embodiment 1 of FIG.
  • the IMS terminal uses the SIP Digest authentication mechanism to implement a flowchart for the single sign-on authentication process of the application server.
  • This embodiment is based on the architecture shown in FIG. 4, and the flow of the single sign-on method is described in conjunction with FIG. 3, which is as follows:
  • Step 1 The UE terminal sends an HTTP service request to the application server RP.
  • Step 2 The application server RP learns and locates the address of the signed authentication center IdP according to the contract and support relationship with the operator in advance; then the application server RP and the contract authentication center use the prior art to interact and establish a share.
  • Key Kr i.
  • Step 3 The application server RP responds to the UE terminal with a 401 unauthorised HTTPS response, and requests the UE terminal to go to the authentication center for identity authentication.
  • the response includes the authentication center MP address and the RP identity information; or the application server RP redirects the RP.
  • the self-authentication request is sent to the authentication center IdP, and the message carries the RP identity information.
  • the identity authentication information related to any UE terminal is not included in the application server RP, and the RP does not authenticate the UE.
  • Step 4 The UE terminal sends an HTTP authentication request message to the authentication center IdP according to the IdP address, and requests the IdP to perform identity authentication on the UE terminal or the UE terminal sends an authentication request message to the authentication center IdP immediately following the redirect message, where the message carries the identity of the terminal UE. Identification information.
  • Step 5 The IdP authenticates the RP according to the RP identity information (RP_credential), and saves the authentication result RP_Auth to the RP.
  • RP_credential the RP identity information
  • U_credential the transmitted user identity
  • Step 6 The IdP searches for and downloads the corresponding SIP Digest Authentication Vector (SD-AV) and user configuration information according to the user identity (U_credential) received in the previous step. These include U_credential, realm, qop, algorithm, and H(A1), where H(A1) is a hash function value consisting of U_credential, realm, and password.
  • SD-AV SIP Digest Authentication Vector
  • H(A1) is a hash function value consisting of U_credential, realm, and password.
  • the IdP can obtain the HSS address corresponding to the stored user information by querying the SLF to find the corresponding HSS.
  • Step 7 The IdP generates a random number nonce and stores the H(A1) downloaded from the HSS along with the nonce.
  • Step 8 The IdP sends a 401 unauthenticated challenge message to the UE, where the information includes U_credential, realm, qop, algorithm, and nonce.
  • Step 9 The terminal UE generates a random number cnonce. U_credential, realm and password are used to generate H(A1); then H(A1), cnonce, etc. are used to generate the UE and IdP shared key K0.
  • the terminal uses conce for network authentication and avoids the "choice plaintext" attack.
  • the nonce-count is a counter. The user calculates the response every time the same nonce is used. The nonce-count will increase the port. The nonce-count also participates in the response calculation, which reduces the possibility of replay attacks.
  • Step 10 The UE sends a response response to the IdP to the challenge information in step 8.
  • the response information includes cnonce, nonce, response, realm, U_credential, qop, algorithm, Digest-url, and nonce-count.
  • Step 11 The nonce value in the response message is checked by using the stored nonce value. If the check is correct, the IdP calculates the Xresponse by using the received parameters cnonce, nonce-count, qop, and the original stored nonce and H(A1). The calculated Xresponse is compared with the received response value. If the comparison result is the same, the authenticated user passes, otherwise the UE user terminal authentication fails; if the terminal authentication succeeds, the IdP generates the parameter rspauth value according to the SIP Digest authentication mechanism method; The UE and the IdP shared key K0 are generated by H(A1), cnonce, and the like.
  • Step 12 The IdP generates the UE's authentication result information UE_Auth; the IdP generates a random number noncel; then uses K0, noncel, etc. to generate the key K1; the shared key K0 encrypts the noncel and RP_Auth to generate K0 (noncel, RP_Auth) Encrypting K1 and UE_Auth with RP and IdP to generate Kr,i(Kl, UE_Auth).
  • Step 13 The IdP sends the 200 OK information to the UE terminal, and includes information such as the authentication result information UE_Auth, the key life cycle, and the rspauth parameter value of the UE by the IdP, indicating that the authentication is successful to the UE terminal, and the IdP redirects the UE terminal to the RP.
  • the message carries the IdP to generate the UE's authentication result information UE_Auth, the key life cycle, the rspauth parameter value, and Kr,i(Kl, UE_Auth) wait for news.
  • Step 14 The UE terminal decrypts KO (noncel, RP_Auth), obtains the noncel value and the RP authentication result, and obtains the legality of the RP application server. If it is a legitimate application server, the next step is executed sequentially, otherwise, a server illegal notification information is directly returned to the UE terminal; the terminal UE calculates and generates the rspauth parameter value by using the same mechanism as the IdP, and compares with the received rspauth parameter value, If the network is the same, the successful authentication process of the terminal to the network is completed; after the network authentication is successful, the key K1 is generated by using K0, noncel, and the like.
  • KO oncel, RP_Auth
  • Step 15 The redirect message sent by the IdP is redirected to the RP, which carries Kr,i(Kl,UE_Auth).
  • Step 16 After receiving the message, the RP decrypts Kr,i(Kl,UE_Auth) by using the shared key, and the RP obtains the authentication result information and the key K1 of the IdP to the UE terminal.
  • Step 17 The RP determines, according to the UE_Auth, whether to provide the UE with the authorized service content UE_Author; and encrypts the authorization information with the key K1 to generate K1 (UE_Author).
  • Step 18 The RP notifies the UE of the content of the authorization information.
  • Step 19 The UE determines whether the requested service can be obtained according to whether the key K1 can decrypt K1 (UE_Author).
  • Steps 17, 18, and 19 are specific application layer steps, which are optional steps.
  • FIG. 5 is a flowchart of another single sign-on method according to an embodiment of the present invention. As shown in FIG. 5, the method includes:
  • Step S502 The UE sends an authentication request carrying the user identity to the RP, and the RP obtains the address of the corresponding authentication center IdP, and redirects the authentication request to the authentication center.
  • Step S504 The authentication center authenticates the UE by using the SIP Digest authentication mode, and redirects the authentication result to the RP through the UE.
  • Step S506 The RP provides a service for the UE according to the authentication result.
  • the operator unified authentication center OP (SSO) has both OpenlD Provider and SIP Digest authentication capabilities; the terminal UE sends an OpenlD authentication request message carrying an OpenlD identifier to the RP; the RP completes the standardization and locates the OP end point according to the OpenID2.0 protocol. The address process, and the subsequent association process, generates a shared key between the RP and the OP. The RP redirects its own authentication request to the authentication center through the terminal. In this way, the terminal's own authentication request is also redirected to the authentication center.
  • the authentication center since the authentication center performs only one-way authentication on the UE terminal, and the server may have an unauthenticated attack situation, there may be a problem that the security is poor due to the server being illegal. Therefore, the following processing methods can be used:
  • the redirect message sent by the RP to the sign-off authentication center IdP carries the terminal identity and the RP identity under the OpenlD mechanism;
  • the authentication center After obtaining the RP identity by the authentication center in the above manner, the authentication center can authenticate the RP according to the RP identity and save the authentication result.
  • the authentication center may determine whether there is a first shared key K0 with the UE, and if not, continue the subsequent processing, if yes, skip
  • the authentication center uses the SIP Digest authentication mode to authenticate the UE and directly redirects the authentication result to the RP. Through the above judging steps, the authentication center can directly return the authentication result to the RP to the authenticated UE, thereby improving the processing speed.
  • the process of authenticating the UE by using the SIP Digest authentication mode may use the following processing mode: the authentication center authenticates the terminal according to the SIP Digest authentication vector (SD-AV) corresponding to the terminal.
  • SD-AV SIP Digest authentication vector
  • the (SD-AV) may be obtained and stored by the authentication center from the HSS according to the user identity, wherein the SD-AV includes at least the following: a user identity, an algorithm, a quality assurance, a realm, and a A hash value H(A1), where H(A1) is composed of a user identity, a realm, and a password (password).
  • the process of authenticating the terminal by using the SIP Digest authentication mode by the authentication center may include: the authentication center generates a random number nonce, and sends a message carrying algorithms, nonce, and realm to the UE; the UE generates a random number cnonce According to the nonce, the cnonce, and the H(A1) generated by the realm, the user identity, and the previously stored password, the response value is generated by using the algorithm, and the response message is returned to the certificate center, where the response message carries the CNNC, the nonce, the realm, the response And the algorithm; the authentication center uses the algorithm to calculate the verification response value Xresponse according to the stored H(A1), the stored nonce, the received cnonce, and the response to the Xresponse.
  • the authentication center uses the SIP Digest authentication mechanism to calculate the rspauth parameter value.
  • the SIP Digest authentication mechanism the operator can provide unified two-way authentication for both the user and the accessed application server by providing the IdP unified authentication center. Implement the SSO function in scenario 3.
  • the calculation basis of the response may further include: the UE uses the same nonce usage count when calculating the response. Using nonce-count also participates in the response calculation, which can reduce the possibility of replaying attacks.
  • the UE can calculate K0 by using the authentication algorithm according to H(A1) and CNNOce; using SIP Digest in the authentication center.
  • the authentication center can calculate K0 according to the authentication algorithm and store it.
  • certification The center and the UE may generate a shared key K0 between the two according to the parameters of the authentication process interaction, and the authentication center may determine whether the UE has been authenticated according to whether the shared key is stored.
  • the authentication center When the authentication center is an OP and the authentication center is successfully authenticated, the authentication center generates a random number noncel.
  • the first shared key K0 between the noncel and the authentication center and the terminal generates the second key K1;
  • the authentication center uses the K0 encryption noncel and the RP authentication result RP_Auth to obtain KO (noncel, RP_Auth), and the relationship between the RP and the RP
  • the shared key Kr, i encrypts K1 and the authentication result UE_Auth to the terminal, and obtains Kr, i (Kl, UE_Auth);
  • the authentication center sends 200OK information carrying the KO (noncel, RP_Auth) and rspauth parameter values to the terminal and Kr, i (Kl, UE_Auth) is redirected to the RP, or the terminal obtains KO (noncel, RP_Auth), rspauth parameter value, and
  • i(Kl, UE_Auth) is redirected to the RP; the terminal decrypts KO (noncel, RP_Auth), and obtains the authentication result for the RP.
  • the rspauth parameter value is generated in the same way as the authentication center, and is received from the received information. Rspauth comparison, to complete the terminal-to-network authentication process; after the network authentication succeeds, the second key K1 is generated; and, the RP decrypts Kr, i (Kl, UE_Auth), and uses K1 encryption service content to be sent to the terminal; the terminal uses K1 to decrypt Get the service content.
  • the interaction information between the authentication center and the UE, and between the authentication center and the RP is encrypted by using the corresponding shared key to ensure the information exchange security between the authentication center and the UE and the authentication center and the RP.
  • a K1 is generated, so that the service content of the interaction between the UE and the RP is encrypted by using K1, thereby preventing illegal interception of user data, thereby further improving security.
  • FIG. 2 is a structural block diagram of a single sign-on system according to an embodiment of the present invention.
  • the system includes: a UE 22, configured to send an OpenlD authentication request to the RP 24; An authentication request for completing the OpenlD mechanism and redirecting the RP and the UE 22 to the authentication center 26 by the UE 22, and for providing the UE 22 according to the authentication result of the authentication center 26; the authentication center 26 for using the SIP Digest authentication method
  • the UE 22 is authenticated, and the authentication result is redirected to the RP 24 through the terminal.
  • the authentication center 26 is further configured to authenticate the RP 24 based on the RP identity and save the authentication result.
  • the authentication center 26 can also be used to generate a secure communication key and redirect the secure communication key to the RP 24 through the UE 22; the RP 24 is also used to encrypt the service content with the secure communication key and send it to the UE 22; The UE 22 is also used to generate a secure communication key, and decrypt the secure communication key to obtain the service content.
  • FIG. 7 is an overall architecture diagram of an IMS terminal implementing non-UICC card IMS terminal to an application server using the SIP Digest authentication mechanism as an OpenlD Provider according to an embodiment of the present invention
  • FIG. 6 is an operator according to Embodiment 2 as OpenlD.
  • the Provider uses the SIP Digest authentication mechanism to implement a single sign-on authentication flowchart for the IMS terminal of the non-UICC card to the application server.
  • the embodiment is based on the architecture shown in FIG. 7, and the flow of the single sign-on method is described in conjunction with FIG. Said as follows:
  • Step 1 The UE terminal sends an OpenlD authentication request to the RP, where the request carries the OpenlD identifier information of the user.
  • Step 2 The RP normalizes the OpenlD identifier, obtains the OpenlD Provider address according to the identifier RP, and finds the OP endpoint URL.
  • the UE terminal expects to use the URL to complete the authentication, and the RP and the OP use an existing mechanism, such as an association process.
  • Diffie-Hellman key exchange protocol, etc. establish a shared key Kr,o; RP redirects the user OpenlD authentication request And send an RP authentication request to the OP address.
  • the RP identity information and the standard parameter information content in OpenID2.0 are included in the message.
  • Step 3 The RP redirects the user to the OpenlD authentication request and sends the RP authentication request to the OP address.
  • the message includes the RP identity information and the standard parameter information content in OpenID2.0.
  • Step 4 The OpenlD authentication request is redirected to the address of the OpenlD Identity Provider OP. After this step, the OP establishes an association between the user identity and the OpenlD identifier information.
  • Step 5 The OP authenticates the RP according to the RP identity information (RP_credential).
  • the terminal identification information U_credential is used to determine whether the corresponding UE and the OP share the secret in the OP. Key K0. If the shared key exists, jump directly to step 12 for execution, otherwise continue to the next step. In this step, a correlation map between the OpenlD identifier and the end user identity identifier is established.
  • Step 6 The OP searches for and downloads the corresponding SIP Digest Authentication Vector (SD-AV) and user configuration information content according to the user identifier (U_credential) associated with the OpenlD identifier in the previous step.
  • SD-AV SIP Digest Authentication Vector
  • U_credential user identifier
  • H(A1) H(A1) is a hash function value consisting of U_credential, realm, and assword.
  • the OP can obtain the HSS address corresponding to the stored user information by querying the SLF to find the corresponding HSS.
  • Step 7 The OP generates a random number nonce and stores the H(A1) downloaded from the HSS along with the nonce.
  • Step 8 The OP sends a 401 unauthenticated challenge message to the UE, where the information includes U_credential, realm, qop, algorithm, and nonce.
  • Step 9 Generate a random number cnonce.
  • U_credential, realm and password are used to generate H(A1); then H(A1), cnonce, etc. are used to generate the UE and OP shared key K0.
  • the response value is calculated by a one-way hash function F.
  • Response F(H(Al), cnonce, nonce, qop, nonce-count).
  • the terminal uses conce for network authentication and avoids the "choice plaintext" attack.
  • the nonce-count is a counter. The user calculates the response every time the same nonce is used. The nonce-count will increase the port. The nonce-count also participates in the response calculation, which reduces the possibility of replay attacks.
  • Step 10 The UE sends a response response to the challenge information in step 8 to the OP, where the response information includes cnonce, nonce, response, realm, U_credential, qop, algorithm, Digest-url, and nonce-count.
  • Step 11 Use the stored nonce value to check the nonce value in the response message. If the check is correct, the OP calculates the Xresponse using the received parameters cnonce, nonce-count, qo, and the original storage ⁇ nonce and H(A1). , ⁇ ! The search ⁇ Xresponse is compared with the response value. If the comparison result is the same, the authenticated user passes. Otherwise, the UE user terminal fails to authenticate. After the authentication terminal succeeds, the authentication center OP uses the SIP Digest authentication mechanism to calculate the rspauth parameter value. H(A1), cnonce, etc. generate a UE and OP shared key K0.
  • Step 12 Generate authentication assertion information UE_Assert for the UE according to the authentication result of the terminal; OP generates a random number noncel; then generate a key K1 by using K0, noncel, etc.; the shared key K0 encrypts the noncel to generate KO ( Noncel); K1 and UE_Assert are generated by RP and OP shared key encryption to generate Kr,o(Kl,UE_Assert).
  • Step 13 The OP sends 200 OK information to the UE terminal, including information such as K0 (noncel), rspauth parameter value, and key lifetime. Meanwhile, the OP redirects the UE terminal to the RP, and the message carries Kr, o (Kl, UE_Assert). Or the OP sends a redirected UE to the RP message, which carries information such as K0 (noncel), Kr, o (Kl, UE_Assert), rspauth parameter value, and key life cycle.
  • Step 14 The UE terminal decrypts KO (noncel) to obtain a noncel value.
  • the terminal UE calculates and generates an rspauth parameter value by using the same mechanism as the IdP, and compares with the received rspauth parameter value, and the two are identical to complete the terminal to the network.
  • Successful authentication process after successful network authentication, K0, noncel, etc. are used to generate the key Kl.
  • Step 15 The redirect message sent by the OP is redirected to the RP, which carries Kr,o(Kl,UE_Assert) 0
  • Step 16 After receiving the message, the RP decrypts Kr,o(Kl,UE_Assert) by using the shared key, and the RP obtains the UE_Assert and the key K1 of the OP to the UE terminal.
  • Step 17 After the RP verifies the UE_Assert assertion, the RP generates the UE's authorization information UE_Author; and encrypts the authorization information with the key K1 to generate K1 (UE_Author).
  • Step 18 The RP notifies the UE of the content of the authorization information, and carries the information K1 (UE_Author).
  • Step 19 The UE determines whether the requested service can be obtained according to whether the key K1 can decrypt K1 (UE_Author).
  • Steps 17, 18 and 19 are specific application layer steps, which are optional steps.
  • the IMS terminal UE obtains the request service and then requests another application server
  • the IMS terminal user UE authentication request carries the user OpenlD identifier information OpenlD identifier
  • the OP maps the association through the user OpenlD identifier information OpenlD identifier.
  • the terminal identification information is used to find the corresponding K0 key, and it is known whether the user has passed the authentication. If the K0 key is present, the user does not need to perform SIP Digest authentication, and only needs to perform 11 steps; otherwise, the entire authentication process needs to be performed; When the K0 key lifetime expires, it is automatically destroyed.
  • the authenticated user needs to perform SIP Digest authentication again to generate the UE and OP shared key.
  • the UE needs to restart the authentication process if the UE has completed the authentication process. If the K0 life cycle is not reached when the network is restored, the UE may continue to use the K0 for subsequent operations after the network is restored. Otherwise, re-authentication is required.
  • the UE user accesses the RP application server, if the user encounters a special situation such as the user actively shutting down the UE or powering off, the user needs to complete the entire execution process such as registration in the IMS.
  • the solution provided by the embodiment of the present invention can support a terminal list that does not have a UICC.
  • the authentication of the login RP is not required.
  • the method does not need to deploy a large number of GBAs, and the non-UICC terminal can access the IMS network. Therefore, the cost of deploying the GBA and embedding the UICC card by the network operator is reduced, and the consumption of various devices is reduced. And the IMS network related application service can be accessed through SSO.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device, which can be centralized on a single computing device or distributed over a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device so that they may be stored in the storage device by the computing device, or they may be fabricated into individual integrated circuit modules, or multiple modules thereof Or the steps are made into a single integrated circuit module implementation. Thus, the invention is not limited to any specific combination of hardware and software.

Landscapes

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

Abstract

L'invention porte sur un procédé et un système de signature unique. Le procédé comprend les opérations suivantes : un terminal envoie une requête de service à un RP ; le RP acquiert l'adresse d'un centre d'authentification ; le RP redirige une requête d'authentification de celui-ci vers le centre d'authentification par l'intermédiaire du terminal, ou le RP renvoie au terminal une réponse utilisée pour diriger le terminal vers le centre d'authentification afin d'effectuer une authentification ; le terminal envoie la requête d'authentification au centre d'authentification ; le centre d'authentification authentifie le terminal au moyen de l'authentification par condensé SIP, et redirige le résultat d'authentification vers le RP par l'intermédiaire du terminal ; durant l'authentification au moyen de l'authentification par condensé SIP, le centre d'authentification et le terminal utilisent tous les deux une valeur de hachage identique et un nombre aléatoire identique pour produire une clé partagée ; et le RP fournit un service au terminal conformément au résultat d'authentification. Le procédé et le système de la présente invention prennent en charge une authentification RP à signature unique d'un terminal sans UICC.
PCT/CN2012/074932 2011-07-04 2012-04-28 Procédé et système de signature unique WO2013004104A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110185712.1 2011-07-04
CN2011101857121A CN102869010A (zh) 2011-07-04 2011-07-04 单点登录方法及***

Publications (1)

Publication Number Publication Date
WO2013004104A1 true WO2013004104A1 (fr) 2013-01-10

Family

ID=47436491

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/074932 WO2013004104A1 (fr) 2011-07-04 2012-04-28 Procédé et système de signature unique

Country Status (2)

Country Link
CN (1) CN102869010A (fr)
WO (1) WO2013004104A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103259663A (zh) * 2013-05-07 2013-08-21 南京邮电大学 一种云计算环境下的用户统一认证方法
CN104683103B (zh) * 2013-11-29 2018-02-23 ***通信集团公司 一种终端设备登录认证的方法和设备
CN104506555A (zh) * 2015-01-06 2015-04-08 北京艾力泰尔信息技术有限公司 客户端零存储的单点登录方法
CN110035035B (zh) * 2018-01-12 2021-09-17 北京新媒传信科技有限公司 一种单点登录的二次认证方法及***

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101039311A (zh) * 2006-03-16 2007-09-19 华为技术有限公司 一种身份标识网页业务网***及其鉴权方法
CN100550725C (zh) * 2005-06-17 2009-10-14 中兴通讯股份有限公司 一种用户与应用服务器协商共享密钥的方法
WO2010128348A1 (fr) * 2009-05-08 2010-11-11 Telefonaktiebolaget L M Ericsson (Publ) Système et procédé d'utilisation d'une architecture gaa/gba en tant qu'outil de signature numérique

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101022651B (zh) * 2006-02-13 2012-05-02 华为技术有限公司 一种组合鉴权架构及其实现方法
CN101510877B (zh) * 2009-02-25 2012-05-23 中国联合网络通信集团有限公司 单点登录方法和***、通信装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100550725C (zh) * 2005-06-17 2009-10-14 中兴通讯股份有限公司 一种用户与应用服务器协商共享密钥的方法
CN101039311A (zh) * 2006-03-16 2007-09-19 华为技术有限公司 一种身份标识网页业务网***及其鉴权方法
WO2010128348A1 (fr) * 2009-05-08 2010-11-11 Telefonaktiebolaget L M Ericsson (Publ) Système et procédé d'utilisation d'une architecture gaa/gba en tant qu'outil de signature numérique

Also Published As

Publication number Publication date
CN102869010A (zh) 2013-01-09

Similar Documents

Publication Publication Date Title
KR102018971B1 (ko) 네트워크 액세스 디바이스가 무선 네트워크 액세스 포인트를 액세스하게 하기 위한 방법, 네트워크 액세스 디바이스, 애플리케이션 서버 및 비휘발성 컴퓨터 판독가능 저장 매체
US10411884B2 (en) Secure bootstrapping architecture method based on password-based digest authentication
US9015819B2 (en) Method and system for single sign-on
US9490984B2 (en) Method and apparatus for trusted authentication and logon
JP4824813B2 (ja) アプリケーションの認証
JP5688087B2 (ja) 信頼できる認証およびログオンのための方法および装置
JP2017535998A5 (fr)
WO2019085531A1 (fr) Procédé et dispositif d'authentification de connexion de réseau
US9544298B2 (en) Method for certificate-based authentication
CN112312393A (zh) 5g应用接入认证方法及5g应用接入认证网络架构
Younes Securing ARP and DHCP for mitigating link layer attacks
WO2007104248A1 (fr) Procédé, système, appareil et entité à fonction de service d'amorçage aux fins de prévention d'attaques
WO2013044766A1 (fr) Procédé et dispositif d'accès aux services pour un terminal sans carte
WO2013004104A1 (fr) Procédé et système de signature unique
CN105656854B (zh) 一种验证无线局域网络用户来源的方法、设备及***
CN102694779B (zh) 组合认证***及认证方法
CN116321158A (zh) 基于证书的本地ue认证
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
US9485654B2 (en) Method and apparatus for supporting single sign-on in a mobile communication system
JP2015111440A (ja) 信頼できる認証およびログオンのための方法および装置
WO2012129985A1 (fr) Procédé et système pour une ouverture de session unique
KR20130046781A (ko) 무선 네트워크 접속 인증 방법 및 그 시스템
WO2020037958A1 (fr) Procédé, dispositif, système de partage de clé et enregistrement de client basés sur gba
CN102469102B (zh) 单点登录方法及***
WO2013064040A1 (fr) Procédé et système d'authentification combinée pour un sso d'ims

Legal Events

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

Ref document number: 12807587

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12807587

Country of ref document: EP

Kind code of ref document: A1