TW201225697A - Identity management on a wireless device - Google Patents

Abstract

A wireless device may perform a local authentication yo reduce the traffic on a network. The local authentication may be performed using a local web server and/or a local OpenID provider (OP) associated with the wireless device. The local web server and/or local OP may be implemented on a security module, such as a smartcard or a trusted execution environment for example. The local OP and/or local web server may be used to implement a provisioning phase to derive a session key associated with a service provider from an authentication between the wireless device and the network. The session key may be reusable for subsequent local authentications performed for the service provider locally at the wireless device.

Description

201225697 VI. Description of the Invention: [Technical Field of the Invention] [0001] The present application claims US Provisional Patent Application No. 1.61 of September 20, 2010, and 3,729, and December 3, Application No. 61/428,388, the disclosure of which is incorporated herein in its entirety by reference in its entirety. [Prior Art] _ Cong network users often have multiple usernames and passwords ((4) access to multiple 〇, website authentication). For example, 'Internet users can have a username/Mirma combination' for accessing social networking sites (such as Faceb〇〇k) and another username for accessing email sites (such as Gmaii) / Password combination. While multiple username/password combinations enable user authentication, Internet users find it cumbersome to remember each username/password combination. For example, 'Internet users forget the username/password combination of one of their websites and the result is that they cannot access the website. In order to make the user identification of Internet users less troublesome, a single sign-on method such as GPenId has been proposed. However, single sign-on (SS0) as a web service has several drawbacks when implemented. For example, the user can have a secure channel to the web-based SS0 provider. In addition, users may have limited control over the SS0 provider. Moreover, authentication in SS0 is generated via empty inter-media communication, which can result in network entities (e.g., 〇penID provider (0p) and/or NAF) and/or load on the network itself due to increased traffic. In addition, MN〇 may have to bear the cost of this additional service. SUMMARY OF THE INVENTION 10013373#Single Number A0101 Page 3/Total Page 1013091673-0 201225697 [0003] This section is provided to introduce various concepts in a simplified form and are further described in the Detailed Description. Embodiments of systems, methods, and devices are described herein for use in the secrets at the wireless device to provide a session secret associated with the service provider. A temporary sticky wheel obtained from network authentication between the wireless device and the network entity can be received as described herein. Based on the temporary secret record, a conversation material with the service provider can be obtained. The I-record can be associated with the network entity and configured to perform local authentication at the (4) device. The session key can be shot in the local authentication at the wireless device. This walk-through describes an embodiment of a system, method and apparatus for performing local screening at a wireless device. As described herein, an associated control handle can be received from the service provider, which instructs the service provider to perform an association with the network entity. Authentication information associated with the user of the wireless device can be received. The clock information can be verified at the wireless device, and the signature can be generated based on the associated control code and associated with the service provider (4). The session secret can be derived from the network component between the network entity and the non-synchronous device and configured for: local authentication at the line wireless device. You can use the signature key to sign the identity (4) to indicate that the wireless damage has been verified locally. This section provides an alternative for introducing these concepts in a simplified form, which is further described in the following detailed description. This section is not intended to read key features or essential features of the claimed subject matter, nor is it intended to use the scope of the claimed subject matter. In addition, the subject matter of the request is not limited to any of the shortcomings in any part of the public content (4) 10013373# single number A0101 page 4 / total 100 pages 201225697. [Embodiment] [_When referred to hereinafter, the term "wireless transmitting/receiving unit (wtru)" may include, but is not limited to, user equipment (ϋΕ), mobile station, fixed or mobile subscriber unit, pager, action Telephone, personal digital assistant (PDA), computer, machine-to-machine (device), sensor, femto community, access point' or any other type of device that can operate in a wireless environment. The term "node" may include, but is not limited to, a site controller, an access point (Αρ), a femto community, or any other type of interface device that may operate in a wireless environment. Local or decentralized mobile 0penID provider, smart card, H(e)NB, and/or other type of device implemented on the WTRU. Although the implementation may be described in the context of a 〇penID agreement, the implementation The way can be extended to other single sign-on (ss) protocols and/or federated identity agreements. Similarly, as the 〇penID entity can be described here, OpenlD entities can be extended to perform the same or similar functions. For example, the functions described herein that can be performed by a relying party (Rp) can be performed by any service provider. Local mobile sso protocols, such as local mobile 0penIDs, can allow local modules or entities to perform identity authentication/declaration. Function, which is part of the SSO and/or identity management protocol (eg 〇peniD protocol). The local modules can be smart cards, USIM, UICC, Java cards, smart card web server (SCWS) enabled smart cards. , or other trustworthy entity. Local Move %0 is a term 'used to collectively indicate various implementations, whereby single sign-on (ss〇) and/or 10013373 order number A0101 can be performed by a web-based SS0 server. 5 pages / total 100 pages 1091091673-0 201225697 Part or all of the associated identity management functions are replaced or performed by local-based entities and/or modules that are part or all of the communication device itself, or where such entities/modules are Physically and/or logically located (eg, located locally) in the vicinity of the communication device and/or its users. For example, 'entity or mode Can be embedded in the device, attached to the device, and/or connected to the device by a local interface, wiring, and/or short-range wireless device. Local OpenlD can also be used as a term 'used to indicate a subset of local mobile SS0 implementations' Thus the implementation of SSO and/or identity management is based on the Open ID protocol. For example, local 〇PenII can be used to indicate the functionality of the TOPIi) Provider (or 0penID IdP) that can be executed by a local entity or module. 0P is a term 'an entity or module that is used to indicate the function of a local 〇PenID server on the device. The abbreviation OPloc can be used to represent local 0P. One of the implementations of the local device P can facilitate the authentication of the user and/or device by means of an identity statement with respect to the user and/or device. The statement 4 is sent from the local 0P to the browser running on the device or to the browser agent (BA), which then forwards the statement to the external relying party (in the form) ° in the function provided by the local 0P Mainly limited to providing the identity claim, the local 0P may be referred to as a local claims provider (LAP). The local OP can process, generate, manage, and/or send an identity claim message to one or more external recipients. The identity claim message may declare the verification status of one or more identifiers associated with the user and/or device. For example, in the OpenlD protocol, a third party entity called a relying party (RP) can be one of the recipients of an identity claim message. The local op can also use the signature, encryption key, cryptography, etc. to sign the identity statement > Xiao Xi® 1001337#单号A〇101 Page 6 of 1 Page 1013091673-0 201225697 The local OpenlD method can use one Or multiple encryption keys, such as a root session key. The root session secret may be represented by Krp' and may be a session key used between the RP and the OP. The session key may also be

Kext/int)_NAF or another key stored, for example, in a smart card. The session secret (for example, Krp) can also act as between RP and 0P (from which you can

Export other passwords for session encryption. Session secrets can be derived from associations between the network and wireless devices (for example, local 0Ps). The local OpenlD can also use a claim key or a signing key, which can be represented as Kasc. A signature secret (e.g., Kasc) can be used to sign one or more identity claim messages for authenticating the user and/or device. The signing key (e.g., Kasc) can be derived from a session secret (e.g., 'Krp). The local 〇penID method can also use a service called OpenlD Server Function (OPSF) whose task is to generate, share, and/or distribute the secrets available to the local and/or relying party (RP) ° 0PSF and local 0P can be Observed as an outside gang of separate entities. The 0PSF is also capable of verifying the signatures issued by the local OpenlD, and can be directly obtained, for example, via the public Internet routing RP. The browser on the device can be redirected to the local 0 by modifying the local DNS of the parsing cache on the device. P, so the address of 0PSF is mapped to the local. The local OpenlD method can also use the service represented by ΟΡ-agg' whose task is to facilitate the discovery of local POPs on behalf of the RP. The SS0 protocol, such as OpenlD, can be integrated with the Common Bootstrap Architecture (GBA). GBA is a way to bootstrap application layer keys from the access layer key. The method of integrating OpenlD and GBA may include separate supply phases and/or authentication phases. Certain certificates can be provided for future authentication during the supply phase. The previously provided 10013373# single number A〇1〇l page 7 / 100 page 1013091673-0 201225697 certificate can be used for local declaration of user identity during the authentication phase. Local clocks, such as local authentication to the local 0penID provider (〇p), can reduce air traffic on the network. The local authentication can be performed, for example, after a clocking process between the network and the wireless device. Local 〇p can be associated with a local web server on a wireless device such as a smart card web server (scws). For example, the local OP may include a local web server' or a local web server may be included in the local 〇P or established on the local 〇p. As described herein, the authentication service can be local and can not burden the network itself. A shared secret or session key can be established between a network entity (e.g., 〇peniD server function (0PSF)) and a local 〇p for each rp accessed by the user. The shared secret or session secret wheel may be established from an authentication performed between the network entity and the wireless device' wherein the local OP is associated with the wireless device. Several exemplary mechanisms for establishing such a secret are disclosed herein. If the RP uses associations, they can store secret or session keys for signature verification and can reuse them the next time they access them. However, if the relying party (RP) uses stateless mode, the RP cannot save the secret or session key. Still in this stateless situation, the OP can generate a secret and can safely share it with the 0PSF. Local 〇P can store the secret or session key and reuse it the next time the user accesses the RP. In addition, the 0PSF can store the secret or session key so that 0psF can be used directly for signature verification (e.g., in stateless mode). Network traffic can be reduced by storing and/or reusing confidential or session keys' embodiments described herein. In an exemplary embodiment, local verification may be performed for local 0P. The local OP can be associated with, for example, a smart card web server (SCWS). Total, single number fine 1 Page 8 / Total 100 pages 1013091673-0 10013373» 201225697 The secret or session key used can be used in the network 0PSF entity and the local 0P for the relying party (RP) associated with user access. The room was built. For example, a shared secret or session secret can be established based on authentication between the network and the wireless device and/or local 0P. According to one embodiment, the shared secret or session key may be derived from a network authentication key that is generated from the authentication between the network and the wireless device and/or local OP. The secret or session key can be stored by the local 0P. The shared secret or common key can then be reused (for example for subsequent authentication of the network entity). In an exemplary embodiment, network traffic may be minimized when performing local authentication for local 0P. The user-provided identification word can be sent to the relying party (RP). A redirect can be received from the RP that includes the associated control code in the request parameters. Local requests for authentication of local 0Ps can be sent. The local 0P authentication may occur, the redirection may be received from the local OP, including the associated control code and the signed parameters. In an exemplary embodiment, the Domain Name System (DNS), may be used, lookup . For example, DNS lookups can be used to bypass the SS0 protocol.

J's Bootstrap Function (BSF) client. DNS lookup can be used to discover this

Ground 0penID provider (0P). In addition, MS lookups can be used to bypass GBA modules. In an exemplary embodiment, the binding of the key for the SSO agreement to the GBA derived key may be performed. For example, a session key (eg, Krp) and a signing key (eg, Kasc) can be exported, and/or used to locally move the OpenID protocol, and can be bound to a GBA-derived temporary pad by a cryptographic association (eg, Ks_int_NAF). Session key (for example,

Krp) can be associated with a relying party (RP) through which the signature can be derived 10_7#single number A〇101 帛9 pages/total (10) pages 1013091673-0 201225697 keys (eg 'Kasc). A signature rifle (e.g., Kasc) J is used to sign an identity claim message for user authentication. The temporary secret transmission (Ks_int_NAF) may be a key derived from GBA-U (a UICC-centric GBA procedure within the UICC for application, such as that described in 3GPP TS 33.220). In an exemplary embodiment, a separate secure channel may be established and/or used between the RP and the User Equipment (UE) as part of a five-part protocol (eg, OpenlD Protocol). For example, this town is completed with an independent secure communication channel between the RP and the UE independent of the OP. 14 may allow security between 〇P and user/RP pairs to be separated, and may provide means for limiting the damage caused by security violations of 0P. In an exemplary embodiment, the SSO agreement can be integrated with the authentication and secret protocol. For example, OpenlD may be combined with an Authentication and Secret Recording Protocol (AKA) (e.g., eighty (human) as described in 36?? 15 33.102. The use of a local OpenlD provider associated with a wireless device is described in the embodiments herein ( Identification of 0P). For example, the local (10) may reside in a wireless device 'attached to the wireless device, and/or connected to the wireless device through a local interface, wiring, and/or short-range wireless device. According to one embodiment, the local 0P may be A local web server on the wireless device is associated, such as a smart card web server (SCWS). The local web P may include a local web server. Alternatively or additionally, the local web server may establish 'or local' at the local 0P upper end 0P may be located on a local web server. Embodiments described herein may implement network communications that may be performed using local communications, over air communications, and/or fixed line communications. When implementing local communications, mobile networks Road operator (ΜΝ0) / there is little or no load on the air network, other (fixed line, or non-ΜΝ0) network 10013373 #单号A0101第10页/ Total 100 pages 1013091673 201225697 没有 No traffic on the road, and / or communication within the wireless device. Air communication can be performed on the ΜΝ 0 / air network as a data service (for example, HTTP and / or IP-based communication), And can represent the load on the MN0/air network. With over-the-air communication, the traffic will not be reduced to zero because the user may use the wireless device to access the web service, which generates a considerable amount of traffic so that the user can access the web page. Serving and/or obtaining content. OpenlD is part of the process of user authentication, for example, which increases the traffic of the content acquisition process. The embodiments described herein can be used to reduce the traffic generated by network authentication using over-the-air communication. Traffic may also occur on fixed-line internet and/or existing infrastructure. Fixed-line communications do not increase the load on the ΜΝ0/empty-intermediate network. Figure 1 shows the agreement for OpenlD protocol operation. An exemplary embodiment of a flow. The contract flow may be, for example, a contract flow for a standard OpenlD protocol run. The protocol flow can be used to access a relying party (RP) from a WTRU using a web-based OpenlD 0P feeder (eg myopenid.com). The protocol flow shown in Figure 1 may not involve local traffic, but may Involving air and/or fixed line communications. Traffic offloaded from the air network in FIG. 1 may be for the discovery process at 112 and/or the association between RP 108 and network OP 104 of 114. Fixed line communication. Since the network OP 1 04 can be a web service, the user 102 (eg, a user of a device, browser or other application running on the device, and/or the device itself) and the network OP 104 The communication can be on the empty mediation surface. As shown in FIG. 1, at 110, the user 102 can log in to the relying party 108, for example by using OpenlD. For example, the user 1〇2 can submit the OpenlD identification word to the RP 108. At 112, RP 108 can be passed with 1013091673-0 10013373# single number A0101 page 11 / total 100 pages 201225697

The OpenlD URI 106 communicates to discover the network OpenID Provider (OP) 104. After the network OP 104 is discovered, the RP 108 can perform an association with the network OP 104 at 114. For example, RP 108 and network OP 104 can generate a shared secret. At 116, RP 108 can send a redirect message (e.g., an HTTP redirect message) to user 102 to redirect user 102 to network OP 104. User 102 can send a request for an authentication page (e.g., an HTTP GET request) to network OP 104 at 118. Network OP 104 may send an OP authentication page to user 102 at 120 to authenticate user 102. User 102 can send an authentication credential to network OP 104 at 122. Network OP 104 may send a redirect message (e.g., an HTTP redirect message) to user 102 at 124 to redirect user 102 to RP 108. At 126, user 102 can send a message (e.g., an HTTP GET message) to RP 108 requesting to log in to the service. The message may include a signed identity statement from network OP 104 indicating that user 102 has been authenticated by network OP 104. The RP 108 can allow the user 102 to access its service based on the identity claim message, and at 128, the RP 108 can indicate to the user that the user has logged in and can access the service. According to one embodiment, steps 112 and/or 114 in the protocol flow shown in Figure 1 can be performed over a fixed line internet network, thereby not increasing the load on, for example, the MN0/empty interfacing network. The other steps shown in Figure 1 may be over-the-air communication (which may be performed, for example, on MN0/air network) as data traffic (e.g., HTTP, IP-based communication), and/or may represent a load on the MN0 network. . The traffic will not be reduced to zero because the user 102 may use the device to access the web service, which generates traffic that enables the user 102 to access the web service and/or obtain content. The Open ID is part of the process of user authentication, for example, which will increase the content acquisition process. 10013373#单号 A〇101 Page 12 of 100 1013091673-0 201225697. As described herein, reducing network authentication can reduce the total traffic on the network. Figure 2 shows an exemplary implementation of a traffic flow for OpenID/GBA. As shown in FIG. 2, user equipment (UE) 204 may transmit a user-provided identification word to RP 208 at 210. The RP 208 can obtain an OP address for communication with the network OP/NAF 206 at 212. The RP 208 can (e.g., optionally) establish a shared secret with the network OP/NAF 206 at 214. At 216, RP 208 can redirect UE 204 to network OP/NAF 206. For example, RP 208 can use the OpenID authentication request to redirect the browser on UE 204. At 218, the UE 204 can send an authentication request (eg, an HTTPS GET request) to the OP/NAF 206. At 220, the OFDM/NAF 206 may send an authentication request to the UE 204. At 222, UE 204 and BSF 202 can perform a bootstrap operation as described herein. At 224, UE 204 can send a request message (e.g., an HTTPS request message) to 0P/NAF 206. The request message may include a boot transaction identification word (B-TID). At 226, the OP/NAF 206 may obtain a key and/or related information (e.g., validity period, GUSS, etc.) from the BSF 202 and authenticate the user. The 0P/NAF 206 may send a redirect message to the UE 204 at 228 and redirect the UE 204 to the rp 208. For example, 0P/NAF 206 can redirect the ME browser to RP 208. The redirect message may be sent with an identity authentication statement indicating that the user 204 has been authenticated. At 230, the RP may validate 228 that the authentication assertion received by the UE 204 is valid. As shown in Figure 2, communication can occur over the air network regardless of the association steps between RP and MN0. However, compared to web-based OP, the traffic will increase in OpenID/GBA because the extra steps for authentication (steps 222 and 226) will increase the air data network and for GBA forging 10013373# single number A 〇101 Page 13 of 100 Page 1013091673-0 201225697 Back-end & burdens such as BSF and / or NAF subsystem. Therefore, in the traffic flow not shown in Figure 2, the increase in air traffic and the increase in load on the network entity will occur. Figure 3 illustrates an exemplary embodiment of a protocol flow using native eggs. As shown in FIG. 3, the air traffic can be reduced by offloading the traffic to the local device. For example, the authentication traffic between the user/viewer 302 and the local OP 304 can be performed locally without increasing the air. The burden of network or network services. In addition, discovery and/or Msfl between the Rp 306 and the network 〇p 308 may occur not over the air network and may occur on other infrastructures such as a fixed line public internet. Other sfl tasks shown in Figure 3 can occur, for example, on the air network. The entities shown in FIG. 3 include a user/viewer 302, a local OP 304, a 1^30 6 and a network singapore 8. The user/viewer 〇2 may include a wireless device such as a WTRU, a user associated with the wireless device, and/or a browser or other application running on the wireless device. The local port P3〇4 may be an entity that resides locally on the wireless device or directly connected to the wireless device' which acts as a proxy for a network 驻留p (e.g., network 〇P 308) residing on the network. The local OP 304 can be associated with a local web server (e.g., a smart card web server (SCWS)) residing on the wireless device. The network OP 308 is an OP external to the wireless device in which the local op 304 resides or is connected. For example, network OP 308 can be an OP associated with an MNO and/or a network entity. As shown in FIG. 3, RP 306 can receive a login request from user/browser 302 at 310. The login request may be, for example, a login request using OpenID. At 312, RP 306 and network OP 308 can perform discovery. The discovery may be the discovery of an OP server and/or based on, for example, Ope η II) 10013373# single number λ0101 ^ 14 1 / ^ 100 I 1013091673-0 201225697 identity. The RP 306 can send an association request to the network 308 at 314. 〇p 308 may generate a random, unique association control code A at 316 and/or calculate a signature secret S (e.g., 'Kasc). Network 〇P 308 may send an associated response to RP 306 at 318. » The associated response may include association control code A and/or signature key S (e.g., Kasc). A signature secret S (e.g., ' Kasc) and/or associated control code A may be stored at 320' RP 306. At 322, Rp 306 can send a redirect message to user/browser 302. The redirect message can redirect the user/browser 302 to the local 〇P 304. The redirection message may include an associated control code in the request parameter. " At 324, the user/viewer 302 can perform a local DNS lookup. DNS lookup can be used, for example, to find local 0P 304. At 326, the local 0P 304 can receive a local cone request from the user/viewer 302. At 328, local 0P 304 and user/viewer 302 can perform local user authentication. In local user authentication at 328, the local 0P may send a 0P authentication page to the user/viewer 302 and/or the user/viewer 302 may send authentication information (e.g., authentication credentials) to the local 0P 304. At 330 'local 0P 304, r can be verified, the authentication information (e.g., authentication credentials). At 332 local OP 304

J can also calculate the signature key S (for example, 'Kasc). The signing key s (e.g., Kasc) may be the same key that was calculated by network 0P 308 at 316 and/or stored by RP 306 at 320. The signature secret S can be calculated based on the long-term shared secret or session key K (eg, Krp, K_(ext/int)_NAF, or another key stored in the smart card) and the associated control code A (eg, Kasc) ). The long-term shared secret or session secret record K (for example, Krp, K_(exVint)-NAF, or another secret record stored in the smart card) may be a secret record shared with the network 0P 308. The session secret record 1011091673-0 can be executed from the network between the network and the wireless device associated with the local 0P and/or the local device 100100373#·single number A01〇l page 15/100 pages 201225697 Exported in the road identification. The associated control code A may be a control code generated by the network OP during the association. The signing key S (e.g., Kasc) may be used by the OC 304 at 334 to calculate a signature, which may be included in an identity claim indicating that the local 〇p has locally verified the authentication information from the user/browser 3〇2. At 336, the local OP 304 can send a redirect message to the user/viewer 302. The redirect message may include an associated control code A and/or a signed parameter using the signature calculated at 334. The request can be sent to rp 306 at 338 'user/viewer 3〇2. The request may include a signed identity claim message from the local OP 304. The RP 306 can verify the signature on the identity claim message at 340. For example, rp 306 can use the signature key S (e.g., Kasc) received by network OP 308 at 316 and received by RP 306 at 318 to verify the signature on the identity claim message. If the signature is properly verified at 340, the RP 306 may allow the user/browser 302 to access the service over the network. At 342, the RP 306 can indicate that the user/viewer 302 can access the service by transmitting a 'logged in' page to the user/browser 302. Figure 4 illustrates another exemplary embodiment of a protocol flow using local authentication. As shown in Figure 4, air traffic can be reduced by offloading traffic to the local device. For example, the authentication traffic between the user 4, the browser 404, and/or the local OP 406 can be performed locally without burdening the air network or network service. In addition, discovery and/or associated traffic between RP 408 and network OP 410 may occur not over the air network and may occur on other infrastructure, such as a fixed line public internet. Other services shown in Figure 4 can occur, for example, on the air network. The entities shown in FIG. 4 include a user 4〇2, a browser 404, a local OP 406, an RP 408, and a network 〇p 41〇. User 402 can include a wireless device 10013373#single number A0101 page 16 / total 1 page 1013091673-0 201225697 For example, a WTRU, a user associated with a wireless device, and/or an application executing on a wireless device. The browser 404 can include a web page browser or other application being executed on a wireless device. The local OP 406 may be an entity that resides locally on the wireless device, acting as a proxy for an OP (e.g., network OP 410) residing outside of the wireless device. The local OP 406 can be associated with SCWS residing on the wireless device. Network OP 410 may be an OP located external to the wireless device on which local 〇P 406 resides and/or associated. For example, network OP 410 can be an OP associated with an MNO. As shown in FIG. 4, the user 40 2 may attempt to access the service via the browser 404. For example, at 412, user 402 can access a website associated with RP 408. The user 402 can also provide a user identification word (e.g., OpenlD identification word) to the browser 404 at 412'. At 414, the browser 404 can send a request message (eg, an HTTP message) to the RP 408. The request message may include, for example, OpenID Identity URL ° RP 408 and Network 0P 410 executable 0P server discovery. For example, RP 408 can send a request message (eg, an HTTP GET identity page message) to network OP 410 at 416. The RP 408 can receive a response from the network OP 410 at 418. The response may include, for example, an OpenID 0P server address. At 420, RP 408 can send an association request to network 〇p 410. For example, the association request may include an HTTP post to the network 410p 410. Network 〇p 410 can generate a random, unique associated control code A at 422. At 424, network OP 410 can calculate a signature key s (e.g., Kasc) that is a shared secret with RP 408. The signature key S can be calculated using the associated control code A generated at 422 and a long-term secret or session key κ (e.g., Krp) shared between the network op 41Q and the local OP 406, for example. The session key can be derived from authentication performed between the network and the no-numbering line device (e.g., local 〇p). At 426 A0101 page/100 pages 1013091673-0 201225697, the network OP 410 can send an association response to Rp 4〇8. For example, the associated response may include an HTTP p〇ste associated response at 426 that may include an associated control code eight generated at 422 and/or a signed key 5 (e.g., Kasc) calculated at 424. The RP 408 can generate a temporary flag (n〇nce) and/or a session identifier at 428. At 430, RP 408 can store a signature key S (e.g., Kasc) and/or associated control code A. At 432, RP 408 can include an associated control code a in the message to be sent to browser 404. For example, the associated control code A can be included in a redirect message configured to be sent to the browser 4 〇 4. At 434, the associated control code a can be sent to the browser 4〇4. For example, a redirect message (e.g., an HTTP redirect message) containing the associated control code A can be sent to the browser 404. User 402, browser 404, and/or local 〇p 406 can perform local authentication on devices (e.g., wireless devices) that can communicate with the network. At 436, the browser can perform a local DNS lookup. For example, the DNS lookup can be used to find a local 0P 406. Using the DNS lookup, browser 404 can request a web page URL (e.g., 'opened provider, com'). Using the DNS lookup, the URL can be converted to an IP address. The browser 404 can perform a lookup on a fixed map in the form described in the local list or host. If it does not include a mapping for the requested URL, the device can perform a lookup using the remote Domain Name Server (DNS). At 436, the browser 404 can access the local IP address (e.g., the IP address of the web server associated with the local 0P 406) when the browser 404 requests the page from the OP URL, the OP URL can be The user provides the part as a user identity (eg, Open ID identity). The IP address of the local 0P 406 may be private or local. Therefore, the web server associated with the local 0P can be obtained from the wireless device associated with the local 0P or the number of the single number should be 01 page 18 / total 100 pages 1013091673-0 201225697. The browser 404 can send a message to the local 0P 406 at 438. The message may include parameters that the browser 404 receives from the RP 408. The local OP 406 can send an authentication page to the browser 404 at 440, which can be displayed to the user 40 2 . At 444, the user 402 can enter authentication information (e.g., authentication credentials), and at 446, authentication information (e.g., authentication credentials) can be sent to the browser 404. The local OP 406 can receive authentication information (e.g., authentication credentials) from the browser 404 at 448 and verify the authentication greed (e.g., authentication credentials) at 450. At 452, the local OP 406 can use the session key K (e.g., Krp) shared with the network OP 410 and the associated control code A received at 438 in the redirect parameter to sign the secret S (e.g., 'Kasc). The session secret wheel K (e.g., 'Krp) may be derived from the authentication between the network and the wireless device associated with the local port 406. At 454, the signature secret S (eg, Kasc) can be used to calculate the signature for the identity claim. For example, the signature can be used to indicate that the local OP 406 has verified the authentication information locally. The signature calculated at 454 can be included in the message for browser 404 at 456. For example, the signature can be included as a parameter in the HTTp redirect message. At 458, the redirect message can be sent to the browser 404. The redirect message at 458 can include the associated control code pill and/or can be signed using a signature calculated by using the signing key S (e.g., Kasc). The browser 404 can send a message to the RP 408 at 460 indicating that the user 4〇2 has been properly identified. For example, browser 404 may send an HTTP GET message with an authentication parameter from local 〇p 406, such as a signature and associated control code A ° RP 408 calculated from signature key S (eg, Kasc). The signature can be verified at 462 and stored as a key associated with the associated control code eight 1001337##^ A0101 page 19/100 page 1013091673-0 201225697. User 402 can be identified at 464, and RP 408 can display a page (e.g., an HTTP page) indicating that the user is logged into browser 404 at 466. At 468, the browser 404 can indicate to the user 402 that the user has logged in at the RP 408. Figures 5A and 5B illustrate another exemplary embodiment of a protocol flow using local authentication. As shown in Figure 5, air traffic can be reduced by traffic carried to local devices. For example, the authentication traffic between the user 502, the browser 504, and/or the local OP 506 can be local and does not burden the air network or network services. Additionally, discovery and/or associated traffic between RP 508, network OP-agg 510, and/or OpenID IdP Server (OPSF) 512 may occur not over the air network and may occur on other infrastructure, such as fixed Line public internet. Other traffic as shown in Figures 5A and 5B can occur, for example, over an air network. The entities shown in Figures 5A and 5B include user 502, browser 504, local 0P 506, RP 508, network OP-agg 510, and OpenID IdP Server (OPSF) 512. User 502 can include a wireless device (e.g., a WTRU)' a user associated with the wireless device, and/or an application executing on the wireless device. The browser 504 can include a web page browser or other application being executed on a wireless device. The local port 506 may be an entity that resides locally on the wireless device' which acts as a proxy for the OP (e.g., network OP-agg 510) residing on the network in communication with the wireless device. The local 0P 506 can be associated with a local web server (eg, sews) on the wireless device. The network port P-agg 510 may be an OP located outside the local device and/or associated wireless device. For example, network 0p_agg 510 may be 〇p associated with Dragon 0, such as 网页0 hosted (h〇st) web server °0pSF 512 may also be associated with MN0, such as MN0 related services. 1013091673-0 10013373#Single Number A〇101 Page 20 of 1 As shown in Figures 5A and 5B, at 514, the user 502 can use the browser 504 to access the website associated with the RP 508. At 516, browser 504 can send a message to RP 508. The message at 516 may contain an OpenID identity URL. The message may be, for example, an HTTP message RP 508 may send a discovery message (e.g., an HTTP GET identity page message) to network OP-agg 510 at 518. In response, RP 508 can receive the 0PSF address from network OP-agg 510 at 520. The RP 508 can send an association message (e.g., POST (Post) message) at 522 to the 0PSF 512. Communication between the RP 508 and the 0PSF 512 can occur, for example, via HTTP and/or public internet communication. 〇psf 512 can generate a random 'unique association control code a' at 524. At 526, the 0PSF 512 can calculate the signature key s (eg, Kasc). The signature secret s (e.g., Kasc) can be calculated using the association control code A and the secret or session key K (e.g., Krp) shared with the local 〇p 506. The session secret record K (e.g., 'Krp) can be derived from network authentication performed between the network and the wireless device associated with the local device. The associated control code A and the calculated signature key s (e.g., Kasc) are sent to the RP 508 at 528, 0?8?512. Associations can be established once in a given time period, such as each RP and/or each identity. The RP 508 can include a signature key and/or an associated control code in future communications. A temporary flag and/or session identification word ^ rP 508 may be generated at 530 ' RP 508 to store a signature key δ (e.g., Kasc) and/or associated control code A at 532. At 534, 508? 508 may include an associated control code A in the redirect message for browser 504 and a redirect message at 536. The redirect message may be an HTTP redirect message including parameters' according to embodiments. The parameter includes an associated control code A. A0101 1013091673-0 Page 21 of 1 201225697 User 502, browser 504, and local OP 506 can perform local authentication of user 502 at a wireless device (e.g., a WTRU) capable of communicating with the network. At 538, browser 504 can perform a local DNS lookup. For example, a DNS lookup can be used to find local OP 506. For example, a DNS lookup can be performed as described herein. The browser 504 can send a message (e.g., an HTTP GET message) to the local OP 506 at 540, the message including parameters received from the RP 508. In particular, local OP 506 can receive associated control code A from browser 504. At 542, the local OP 506 can send an authentication page to the browser 504, which can be displayed to the user 502. User 502 can enter authentication information (e.g., authentication credentials) at 544, and browser 504 can receive authentication information (e.g., authentication credentials) from user 502 at 546. The browser 504 can send user authentication information (e.g., authentication credentials) to the local 0P at 548. At 550, the local 0P 506 can verify the authentication information (e.g., authentication credentials). At 552, the local 0P 506 can calculate the signature key S (e.g., Kasc) using the shared secret or session secret K (e.g., Krp) shared with the 0PSF 512 and the associated control code A received in the redirection parameter. At 554, the signature key S (e.g., Kasc) can be used to calculate a signature for signing the identity claim. At 556, the signature can be included as a parameter in a redirect message (e.g., an HTTP redirect message). The signature can be used to indicate to the network that the user has been locally authenticated by the local 0P 506. The redirect message can be sent 558 to the browser 504' and can include parameters, the parameters including the signature. At 558, the redirect message redirects the browser to the RP 508. The redirect message at 558 can be a way for the local 0P 506 to communicate with the RP 508. At 5 6 0, the browser 504 can send a message (eg, an HTTP GET message) to the RP 560. The message includes the parameter 1013091673-0 1()() 13373^ single number received from the local 0P 506. A0101 Page 22 of 100 201225697 number. In particular, the parameters may include a signature indicating that the user has been authenticated locally by the local OP 506. The RP 508 can verify the signature at 562 using the stored associated control code A. At 564, RP 508 can identify user 502 and allow user 502 to access the service via RP 508. The RP 508 can send an indication to the user 502 indicating that the user 502 is logged in at the RP 508. For example, at 566, RP 506 can display a page (e.g., an HTTP page) at browser 504, which indicates to user 502 at 568 that user 502 has logged in. After logging in to the RP 508, the user 502 can access the service via the RP 508. Figures 6A and 6B illustrate another example implementation of a protocol flow using local authentication. As shown in Figures 6A and 6B, air traffic can be reduced by offloading traffic to local devices. For example, the authentication traffic between the user 602, the browser 604, and/or the local 〇p 606 can be local and does not burden the air network or network service. Additionally, discovery and/or associated traffic between RP 608, network OP-agg 610, and/or OpenID IdP server (0PSF) 612 may occur not over the air network and may occur on other infrastructure, such as fixed Line Public Internet Q. Other services shown in Figures 6A and 6B may occur, for example, over the air network. The entities shown in Figures 6A and 6B include user 602, browser 6〇4, and this

Ground 0P 606, RP 608, Network OP-agg 610 and OpenID IdP Feeder (OPSF) 612. User 602 can include a wireless device (e.g., a WTRU), a user associated with the wireless device, and/or an application executing on the wireless device. The browser 604 can include a web page browser or other application being executed on a wireless device. The local 〇p 606 may be an entity residing locally on the wireless device that acts as a proxy for the 〇p that resides outside of the wireless device communication, such as the network 〇P-agg 610. The local 〇P 606 can be associated with SCWS residing on the 10013373#single number A0101 page 23/total 1 page 1013091673-0 201225697 wireless device. The network 〇P-agg 610 is located outside the wireless device where the local device resides. For example, 'network OP-agg 61 0 may be an OP associated with MN0, such as a web server hosted by ΜΝ0. The ()pSF 612 may also be associated with MN0, such as a service associated with MN0. As shown in FIGS. 6A and 6B, at 614, the user 602 can access the website associated with the RP 608 using the browser 604. At 616, browser 604 can send a message to RP 608, which contains the identity (e.g., 'OpenlD Identity URL). The message can be, for example, an HTTP message. The RP 608 can send a discovery message (e.g., an HTTP GET identity page message) to the network 〇P-agg 610 at 618. In response, RP 608 can receive the 0PSF address at 620. At 622, the RP 608 can generate a predecessor flag and/or a session identification word. The RP 608 can send a redirect message (e.g., an HTTP redirect message) to the browser 604 at 624. The redirect message at 624 can include a parameter 'The parameter includes the temporary flag generated at 622 and/or the session identifier user 602, the browser 604, and the local OP 606 can be in a wireless device capable of communicating with the network (eg, The WTRU) performs local authentication. At 626, the browser 604 can perform a local DNS lookup. For example, DNS lookup can be used to find this

Ground 0P 606. For example, a DNS lookup can be performed as described herein. The browser 604 can send a message (e.g., an HTTP GET message) to the local 0P 606 at 628, the message including the set of parameters received from the RP 608. At 630, the local 〇p 606 can send an authentication page to the browser 604, which can be displayed to the user 602. User 602 can enter authentication information (e.g., authentication credentials) at 632, and browser 604 can receive authentication information (e.g., authentication credentials) at 634. The browser 604 can send authentication information (e.g., authentication credentials) to the local 0P 606 at 636. At 638, local 0P 10013373# single number A0101 page 24/100 pages 1013091673-0 201225697 606 can verify the authentication information (eg, authentication credentials). In "〇, the local OP 606 can generate a unique, random association control code. The function f can be a simple function, since s may not be shared with RP 6〇6 or user 6〇2. At 642, the local 0P 606 can be based on The function of the associated control code A and the long-term shared secret or session key κ (eg, ) associated with the 0PSF 61 2 are used to calculate the signature key S (eg, Kasc). For the associated control code a and/or the signature key S The recognition may not expose the session key local 〇p 606 may use a signature key s (e.g., Kasc) to calculate the signature at 644. The signature may also be included in the identity statement at 644. Local 〇p

J 606 can send a redirect message (e.g., an http redirect message) to browser 604 at 646. The redirect message may include parameters including a signature and/or an identity claim computed at 644 by the local 0P 606. The browser 604 can send a message (e.g., an HTTP GET message) to the RP 608 at 648. The message can include parameters received from the local op 606. For example, the parameters may include signatures and/or identity claims calculated by local 0P 606. The RP 608 can communicate directly with the 0PSF 612. For example, RP 608 can send an association message (e.g., a POST message) to OPSF 612 at 650. The message at 650 can be sent, for example, via HTTP and/or a public internet. The associated message may also include parameters including the signature computed by the local 0P 606. The 0PSF 612 may extract the associated control code A from the parameters at 652 and calculate the signature key S (e.g., Kasc). At 654, the 0PSF 612 can use the calculated signature key S (eg,

Kasc) to verify the signature calculated by the local 〇P 606. At 656, the 0PSF 612 can indicate to the RP 608 that the signature is valid. The RP 608 can determine 658 that the identity of the user 602 is valid and display the page (e.g., an ' HTML page) on the browser 604 at 660. At 662, the browser 604 can be 10013373#single number A〇101 page 25 / total 1 page 1013091673-0 201225697 indicates to the user 602 that the user is logged in at Rp 608. In an exemplary embodiment, the cc records generated in the provisioning phase and/or the authentication phase described herein may be bound to a network clock. For example, keys generated during the provisioning phase and/or the authentication phase can be derived from the network authentication key. According to one embodiment, the local identity assertion provided by the local OP can be extended to incorporate into the authentication and key agreement protocol. E.g,

Open ID/GBA can be used in the provisioning phase to establish long-term confidentiality in a negotiated implementation. In another exemplary embodiment, the agreement may be integrated with other authentication protocols that may enable the establishment of a secret in the device (or security module 'eg smart card) and the network so that it can be used by the local 0P (for example, on a security module and/or device). This can be a key from an initial authentication or key agreement agreement or a key derived from these keys. These agreements may include, for example, AKA, IMS based authentication' and/or other authentication and key agreement protocols. Authentication and key agreement agreements can occur in security modules, such as UICC, USIM or smart card based and/or ME eight terminal based environments. The protocol flow may include an initial provisioning phase and/or an authentication phase, wherein the provisioning may occur once within a given time period, and the authentication phase may be used for each subsequent authentication when the key derived from the provisioning phase is valid. In an exemplary embodiment, the message flow may be performed as a provisioning phase when the user logs into the sand (e.g., when the user first logs into the RP). For example, a browser agent (BA) can send a user-provided identification word to the RP. The user-provided identification word can be standardized. For example, the user-provided identification word can be standardized as described in Appendix A.1 of the Open ID specification (TR 33.924). The RP can obtain the address of the OpenlD provider (10013373^^'^0P) and execute the discovery of the endpoint URL that the end user wishes to use for authentication 〇p A0101 Page 26/Total 1 page 1013091673-0 201225697 (Based on the user-provided identification word) °RP and network OP can establish a shared secret (for example, association). According to one example, the Diffie-Hellman key exchange protocol can be used to establish the shared secret. For example, the shared secret enables the network OP to protect and/or verify subsequent messages. The RP may redirect the BA to OP using an OpenID authentication request, which may for example be an Open II) authentication request as described in Chapter 9 of the OpenlD specification. After the redirect, the BA can send a request (eg, an HTTP GET request) to the network OP/NAF. The request (eg, an HTTP GET request) may include an indication of a local claim. This can be done to indicate support for local identity claims, for example, to the network 0P/NAF. In another exemplary embodiment, the BA may avoid sending a request (e.g., an HTTP GET request) when the OP/NAF decides to use the local identity assertion based on the user-provided identifier. The NAF may initiate UE authentication and respond with a challenge requesting the UE to use digest authentication with GBA. For example, the NAF may initiate a UE authentication and respond with an HTTPS response code 401 "Unauthorized",

The Q HTTPS response code may contain a header (e.g., a WWW authentication header) carrying a challenge requesting the UE to use digest authentication with GBA. In an exemplary embodiment, digest authentication with GBA may occur as specified in TS 33.222 with a server-side certificate. If no valid Ks is available, the UE can boot with the BSF, which causes the UE to occupy a valid network key Ks. From the above process, the UE can derive a specific application, such as a specific OpenID, a temporary secret record (for example, Ks_(ext/int)_NAF key). In an exemplary embodiment, the UE may be booted with the BSF as described in TS 33.220. 10013373#单号A0101 Page 27 of 100 1013091673-0 201225697 If there is no valid RP specific session allowance (for example, κ... is OK, Lai Saki W, Ks "ext/int) N_ key) is derived Session key (example 1 such as 'Krp) 'This will result in a specific session secret for a valid RP (eg

The possession of Rrp). In an exemplary embodiment, the temporary key (your n τ, J, Ks_(ext/int)_NAF key) may be an OpenID specific temporary key (eg,

Ks_(ext/lnt)_JAF secret wheel). The derived session secret (eg, κΓΡ) can be critical security (security heart (4)), and the secret record export process. For example, if someone is not able to derive a session secret (eg, Krp) from a signature, then the authentication scheme will be corrupted due to the particular OP_UE trust relationship. Therefore, security terms can be enforced, such as export The session secret (for example) may not produce any information about any information about the Ks used by it. Furthermore, the implicit implementation may be used to maintain and in a Secure Execution Environment (SEE) such as UICC or TrE. A session key is used (eg, κ.... The UE may generate a request to the NAF (eg, an HTTp GET request). The request may carry an authentication header containing a Boot Transaction Identifier (B TID) received from the BSF. In an exemplary embodiment, if push is used, the B_TID cannot be received from the BSF, but the Gpi can include the p_tid that can be used instead of the B-TID. By using the B-TID and the NAF_ID, the NAF can acquire the share. Application-specific NAF key and optionally uss from the BSF at the web service-based zn reference point (if GBA—ϋ temporary key (eg, Ks_(ext/int)—NAF) is used, then support GU SS). In an exemplary embodiment, this may be performed according to the general authentication structure (GAA) and the TS 29.1 09 based on the Diameter protocol-based Zh and Zn interfaces. In addition, the NAF may store 1013091673-0 10013373# No. A 〇 101 Page 28 / Total 1 page 201225697 Store B-TID, encrypted secret and user-provided identification words to allow matching OpenID user sessions and GBA sessions. According to an exemplary embodiment, since OpenID can be based on HTTP, NAF/OpenID server support for web service-based Zn reference points in interactive scenarios can be as specified in TS 29.1 09. For example, it can support Diameter-based implementation of Zn reference points. A valid RP-specific session key (eg, Krp) is available, and the NAF can derive the session key (eg, Krp) from the OpenID specific temporary secret (eg, Ks_(ext/int)_NAF key) 'This will cause the NAF The same valid RP-specific session secret record (eg, Krp) occupied by the UE as described herein is occupied. The same implementation of KDF can be applied as described herein. NAF/ΟΡ can authenticate users for OpenID. The browser redirects to the returned OpenID address. For example, 0P can redirect the ME's browser back to the RP, which has a message identifying the approved claim or authentication failure. The response header can contain multiple definitions that define the authentication statement. Bit, the authentication statement can be protected by the shared secret between the 0P and the RP. The condition that can be protected can be that both the 0P and the RP do not reside in the same network. ^ NAF can respond with a 2K 0K message. In an exemplary embodiment, NAF/ΟΡ may authenticate the user using TS 33 222 section 53 on the Universal Clock Architecture (gAA) and the Network Application Function Access using https. The RP can confirm the statement. For example, Rp can check if the authentication is approved. The authenticated user identity can be provided to Rp in the response message. If a shared secret (association) is established as described herein, it can be used to verify messages from the OC. If the confirmation of the claim and the verification of the message (if a shared secret is used) is successful, the S user can log in to the service of the RP. 1013091673-0 10_A single number deletion 1 page 29 / common coffee page 201225697 In an exemplary embodiment 'When an operator deploys a GBA push instead of a GBA' ΜΝ 0 wishes to establish a shared secret. For example, the embodiments described herein may be replaced by a GBA voucher push message, and the agreement may proceed as described herein. In an exemplary embodiment, as described in the US Non-Provisional No. N0 13/023, No. 985, which is filed on February 9, 1999, is called Method and Apparatus f〇r Trusted Federated Identity. Establish a common key. Figure 7 shows an exemplary embodiment of an operational flow for an authentication phase with a local identity assertion. In an exemplary embodiment, the message flow shown in Figure 7 can be executed when the user logs in to the RP, such as when the user first logs in. The entities shown in Figure 7 include BSF 702, UE 704, Network OP/NAF 706 and RP 708 704 may include a browser agent (ΒΑ) and/or other applications capable of communicating with RP 708. As shown in FIG. 7, UE 704 can transmit a user-provided identification word to RP 708 at 710. The user-provided identification word can be standardized. In an exemplary embodiment, the user-provided identification word may be standardized as described in Appendix A.1 of the OpenlD specification. At 712, RP 708 can obtain the address of OpenlD Provider (0P) 706. The RP 708 can also perform discovery of the OPP endpoint URL based on the user-provided identification word that the end user wishes to use for authentication. At 714, RP 708 and 0P/NAF 706 can establish an association. For example, the association can be established as described in Chapter 8 of the OpenlD specification. The association may be identified by a unique associated control code and a shared session key generated by the OP/NAF 706. The 0P/NAF 706 can derive a common signature key (e.g., Kasc) from the session key (e.g., Krp) and the associated control code. A signature key (for example, Kasc) can follow a specification. For example, the signing key can follow the specification of the OpenID MAC signature in 10 levels 73, 73 numbering hall 01 page 30/100 pages 1013091673-0 201225697. For example, Kasc may be a valid cipher for HMAC-SHA1 or HMAC-SHA256 (as specified in Chapter 6 of ETSI TS 01 22 127 on the transport protocol for smart cards and CAT applications). The secret signature secret record (e.g., Kasc) and associated control code may be passed to the RP 708 at 714. When using OpenID, the association can be used to establish a shared secret signature secret between 0P/NAF 706 and RP 708 for the signature and signature verification process. The shared secret signature secret record may be, for example, an effective secret for HMAC-SHA1 or HMAC-SHA256 specified in OpenID. In an exemplary embodiment, an agreement other than the Diffie-Hellman key exchange protocol can be used to establish a secret. For example, the secret may depend on an agreement other than the Diffie-Hellman exchange agreement' and may be derived from an agreement other than the Diffie-Hellman secret exchange. A secret record created during the Diffie-Hellman process can be used to encrypt a shared secret (when it is passed from 0P/NAF 706 to Rp 7〇8). For example, the shared secret can be encrypted using the Diffie-Hellman process when the 0P/NAF 706 generates a shared secret. In another exemplary embodiment, when TLS protection communication between RP 708 and OP/NAF 706, the shared secret can be sent in plain text. The signing key (e.g., Kasc) can be established as a shared secret and can be derived from the associated control code and session key (e.g., Krp), which can be implemented using any suitable algorithm known in the art. In addition, OP/NAF 706 can generate an associated control code and select a unique and random associated control code. The derived signature secret (eg, Kasc) and secret export process can be critically secure. For example, if someone 'can't export' a session key (e.g., Krp) from a signing key (e.g., Kasc), the authentication scheme will be compromised due to the particular UE-RP trust relationship. Therefore, a security clause of 1 (m3373#single number A0101, page 31/100 pages 1013091673-0 201225697, such as an exported signature key (eg, Kasc) may be implemented without generating a session secret (eg, Krp) regarding usage (eg, Krp) The terms of any information from which it is derived. The RP 708 can redirect the 卯 704 to 0P/NAF 7〇6 using an authentication request (eg, 〇peniD authentication request). For example, Rp 7〇8 can be used in Chapter 9 of the PenID Specification. Defined 〇penII) authentication request. The same associated specific signature secret (e.g., Kasc) established at 714 between 〇p/naf 706 and RP 708 can be derived 704. The associated signature signature (e.g., Kase) can be derived from the session secret record (e.g., Krp) and the associated control code contained in the authentication request. In an exemplary embodiment, implicit implementation may be implemented to maintain and use signature secrets (e.g., Kasc) in a secure entity, such as SEE, UICC, or TrE. The security risk for signature secrets (eg, Kasc) is lower than for session keys (eg, Krp) because signatures are secretly recorded (eg, can be used, for example, for one authentication. At 720, IIE 704 can be approved with authentication) The statement redirects the browser to a return address at RP 708 (eg, a 〇penID address). The response may include defining parameters of an authentication statement that may be protected by a shared secret signature key (eg, Kasc). For example, the response header may Contains a plurality of fields that define an authentication statement that can be protected by a shared secret signature key (eg, Kasc). The RP 708 can validate the identity claim at 722 using a signing key (eg, Kasc). For example, the RP 708 can pass the check statement The signature in the corresponding field of the message is checked to see if the authentication is approved. The authenticated user identity can be provided to Rp 7〇8 in the response message. If the claim is true and the verification of the message is successful, then the user You can log in to the service of Rp 7〇 8. 1013091673-0 10013373#单单A〇101 Page 32 of 100201225697 As described herein, in some exemplary embodiments, local A claim provider, such as a local op', can be integrated with different key protocols and authentication protocols. Figure 8 shows an exemplary implementation of an operational flow for the provisioning phase. In an exemplary embodiment, the provisioning phase It can be executed once in a given time period, and when the key derived from the provisioning phase is valid, the authentication phase can be used for each subsequent local authentication. There is no shared secret before the provisioning phase is initiated (for example, for OpenlD) ) can be established between the network and the local 0P. After the provisioning phase, the local 〇P and the network (for example, 0PSF) can have long-term shared secrets, such as those expressed as Rp specific session secrets (for example, Krp). As shown in Figure 8, at 802, the device and network may have a shared secret key K 808 for authentication and key agreement between the device and the network. As shown at 804, the local device at the device p and the op at the network may not have a shared secret for OpenlD. At 806, the device and the network may use the shared machine K 808 to participate in the authentication and secret protocol agreement. After the successful agreement is run The network and device may have a temporary key Ktmp 816 (e.g., Ks-NAF, CK/IK, etc.) in 810. At 812, the device performs an internal key export that generates an RP-specific session key (e.g., 'Krp) 818. Function. At 814, a network (e.g., 0PSF) key derivation function may also generate an RP specific session key (e.g., Krp) 818. The conference key (e.g., 'Krp) 818 may be based, for example, on a temporary key ( For example, Ktmp) 816 is generated at both the device and the network. Figure 9 illustrates another exemplary embodiment of an operational flow for the authentication phase. In an exemplary embodiment, if a confidential session key (eg, Krp) has been established between the network and the device, then the town executes the 10113091673-0 10013373# single number deletion 1 page 33 / total 100 page 201225697 Identification stage. Based on the RP specific secret session key specific secret or key in the network (for example to sign an identity claim. (eg '0PSF) and device sharing (eg Krp), signature and / or association lasc) can be generated by local 0P And/or any temporary secret mp (eg, 'Ks_(lnt/ext)-NAF) that can be used as a key agreement agreement can be used to derive a key, such as a session that can be used to authenticate (eg, -) authentication) A secret record (for example, Krp) and a signature secret (for example, -c). As shown in Fig. 9, at 9Q2, the device and the network have established an RP-specific shared session read (e.g., Krp), as shown, for example, in FIG. At 9〇4, the network and the network can participate in association establishment (for example, 〇__ is concatenated with its shared association control code and network and/or network 〇p generated shared security. Network and / Or the network Gp may use a secret record export function to derive a signature key (eg, Kasc) available for authentication at 91G. For example, the secret key derivation function may use a session key (eg, Krp) 9〇6 and associated control code. 9〇8 to derive the signature key (eg, 912. The signature key (eg, 'Kasc) may be used at 914 for the associated secret exchange between Rp and the network. The RP may send the associated control code 9〇8 and the authentication at 916. Requesting to a local OP on the device. The local OP may derive a signing key (e.g., Kasc) 912 from the function of using session key (e.g., Krp) 906 and associated control code 908 at 918. At 920, local 〇 p may sign the identity claim using a signing key (eg, Kasc) 912. The signed identity claim may be an identity claim received from the user (eg, via a browser). The RP may be used at 922 by the network and/or The network 〇p exports the signature key (for example, Kasc) 912 to verify by local 〇 p is an identity statement signed with a signature key (eg, 1013091673-0 10013373#single number A0101, page 34/total page 201225697, Kasc). At 924, the user can log in to the service at the RP. In an exemplary embodiment In the AKA operation, the AKA can be integrated by using the CK/IK established in the device (and/or smart card) and the network. The session secret can be derived from the CK/IK by using the appropriate key derivation function. A key (eg, Krp) is provided to the established AKA key to the local 0P on the device (eg, on the security module or smart card of the device). The CK/IK can be input to the key derivation function (similar Figure 8 shows the temporary secret record Ktmp (for example, Ks_(ext/int)_NAF). This causes the network (for example, 0PSF) and the device (for example, the local OP) to have the same session key for the RP ( For example, Krp) Once the session key is established, it can be used as shown in Figure 9. In addition, other protocols can be used, such as IMS-based authentication methods or other authentication and key agreement protocols. Smart Card (SC) or Security Module describes the design Any trusted environment, such as an integrated circuit card (ICC) or USIM, may provide a set of secure operating facilities. According to one embodiment, the UICC may be a network authentication credential used by the SC to maintain usage in the mobile device (eg, The location of the GSM/UMTS). The Smart Card Web Server (SCWS) application may be an SCWS defined by, for example, the Open Mobile Alliance (0). The SCWS is not restricted to use in the UICC and depends on the preferences of the card issuer. For any other smart card. The local user authentication using OpenID, which resides inside the secure element, can be extended to any other SC, such as a general purpose SC. Moreover, any other security environment that can provide a similar interface and/or protected execution for a critically secure implementation can be used for the 1013091673-0 1()() 13373# single number A0101 page 35/ A total of 100 pages 201225697 implementation goals of the implementation. Based on an implementation of the use of sews and thus user authentication, a similar implementation can be made of the 彳(4)stakehGlder mode. In an exemplary embodiment, _ can act as a full identity provider. ΜΝ0 can host (host) as a web service, qiu §, 卯讣 discovery and/or associated point entities. In addition, the face-to-face application is provided to the UICC along with the user's identity. In an exemplary embodiment, a user may have an existing OpenID identification word registered to a third party, such as myopenid c〇m. MN〇 no longer acts as a service provider to the user. ΜΝ0 can transmit data and allow third parties to install op applications on uicc and/or associate their #scws applications. The second party 0P can establish a business relationship with ΜΝ0. Mn〇 can also authorize third parties to manage the rights of 0P applications. ΜN0 may charge the third party 针对p for the service and form a revenue. In another exemplary embodiment, as will be further described herein, the third party OP and/or 可0 may interact with a global platform (GP) compatible smart card in an exemplary embodiment, the concept described may be non-mobile Implemented in the situation, such as an SC issued by a bank. The SC can be used by the 〇peniD identity provider to install the OP application. For example, a bank card can host an NFC booking application and/or an OpenID authentication 〇P application. In this non-mobile scenario, there may be no prior knowledge of the types of devices that the SC can communicate with. TCP/IP may be established over the USB connection of the SC via a local link, SC card reader, NFC communication interface, and the like. The SC may be equipped with an SCWS that may be obtained, for example, by an external terminal. 1013091673-0 Single Number Delete 1 Page 36 / Total 100 Page 201225697 According to one embodiment, the device may include an sc that hosts the SCWS. The 0P application that wants to access the RP website may not be on the same device. According to this embodiment, the SC can be used as an external authentication token. The situation of these split terminals can be combined with the different stakeholder modes described herein. Ο In an exemplary embodiment, a user may own a mobile device that is equipped with a UICC with sews and local 0P installed. The user can access the desired page at the RP using a browser agent (BA) that may be a different device than the mobile device. When the BA accesses the RP and submits an identification word (for example, a local (^61111) identification word) to log in, 1^ can redirect 5 people to the local 0?. For example, the RP can redirect the BA to the URL of the local 〇p. As described herein, a redirect message (e.g., an HTTP redirect message) from the RP to the BA may contain information for the signature on the local 0P application calculation claim message. The content of the message can be transferred to the local device on the mobile device and/or SC. The local 0P can display the authentication page to the user on the mobile device, and the user can authorize and/or authenticate the login. The local 0P can sign an identity claim message. The signed identity claim message can be sent back to the RP, which can alternatively be done by the BA. The RP can verify the signature and the user/BA can log in at the RP. In an exemplary embodiment, the BA may establish a local link to the mobile device, such as via a Bluetooth or WLAN link, and register the device as a device hosting the OP. The browser can send the redirect to the mobile device via a local key that can forward the redirect to the local OP and/or SCWS. The local 0P can authenticate the user to the user credentials ^ the user can use the mobile device to face the 0P. The user can authenticate using, for example, a password, a PIN, biometrics, and/or any other form of authentication. The local 0P may sign the claim message and/or forward the claim message to the BA via the local link. The BA can use this message to authenticate to the RP. In the implementation 10013373^.single number A0101 page 37/total 1 page 1013091673-0 201225697 mode 'BA can act as MITM between, for example, rp and mobile devices. Since the user knows that the user initiated the 〇penID session', the user is able to detect unauthorized requests on the mobile device. Figure 10 shows an exemplary implementation of a protocol flow for a split terminal scenario. As shown in Figure 1, communication between local 〇p 1〇〇2, user/mobile device 1 004 and/or user/BA 1〇〇6 can occur via the local link. The entities shown in FIG. 10 include local 〇P1〇〇2, user/mobile device 1 004, user/BA 1 006, RP 1008, and network 0P 1〇1〇. Local 0P 1002 and user/mobile device 1〇〇4 may be included in and/or associated with the same wireless device, such as a WTRU. The local 0P 1002 can be an entity that resides locally on or associated with the wireless device, and the wireless device acts as a proxy for a network OP (e.g., network 0P 1010) that resides outside of the wireless device. The local 0P can be associated with the SCWS residing on the wireless device. The network 〇p 1〇1〇 can be used as an external 0P, and the local 0P 1002 resides on the device or is locally associated with it. For example, Network 1 can be associated with an OP. At 1012, the user/BA 1006 can send a login request to the RP 1008. A login request can be made using 〇penID according to one embodiment. At 1014, RP 1〇〇8 and the network 〇p 1〇1〇 can perform the discovery of the 饲p feeder on the network. The discovery can be performed, for example, based on the 〇penlD identity. The Rp 1008 can send an association request to the network at 1016. The Rp can receive an association response from the network 〇p 1 〇 1 10 at 1018. The association response may include an association control code A and/or a signature key S (e.g., Kasc). At 1 020'RP 1〇〇8, a redirect message can be sent to the user/BA 10013373#single number A〇101 page 38/total 100 page 1 006 〇1013091673-0 201225697 The redirect message can be configured to be redirected on the device The browser goes to the local op 1 002. The redirect message has a parameter containing the associated control code A. At 1 022, the user/mobile device 1 004 can establish a local link with the user/BA 1006. User/BA 1 006 can send a local request for authentication to local 0P 1 002 at 1024. At 1 026, local authentication can be performed between local 0P 1002 and user/mobile device 1 004. For example, local authentication can be performed as described herein. At 1028, local 0P 1 002 can send a redirect message to the user /BA 1 006. The redirect message redirects the browser to the user /BA 1006. The redirect message may include an associated control code A and/or signed parameters. A request can be sent to RP 1008 at 1030 'user/BA 1 006. The request may be a request for a service at RP 1 008. The request may include a signed statement from the local 0P 1002. Based on the signed announcement message from the local 0P 1 002, the RP 1008 can instruct the user to log in to the RP 1008. For example, RP 1008 can display the logged in page at 1032. In an exemplary embodiment, a non-mobile SC may be used and/or distributed to a web-based OP or another third party, such as a bank. Similar implementations described herein may be applied when a non-mobile SC is used and/or distributed. For example, a non-mobile SC can be implemented similar to the implementation of the mobile split terminal implementation described herein. For example, the establishment of a local link may be via an external smart card reader and/or an NFC (Near Field Communication) terminal attached to the computer. The interface supports HTTP messages that can be sent to 〇p/scWS implemented on the SC. In an exemplary embodiment, the OP application can execute on a Global System (GP) compatible SC, e.g., uiCC in a GSM and/or UMTS network, and can accommodate different stakeholder modes. Some SCs may be GPs 1013091673-0 10013373#single number A〇m page 39/total 1 page 201225697 =, but the GPSC implementations described herein may be mapped to implementation choices for other embodiments, such as Java cards The actual GPSC can host one or more secure domains (sd), whereby each (four) can represent a stakeholder and/or can store a secret or personalize the application for that stakeholder. It seems that the main SD can be a release of the card issue 3. It can organize the contents of the I have different privilege according to the hierarchy. The issuer can have authorization management (10) = and can perform spontaneous control on the card, as well as the ability to perform two = 1 or delete _. Other SD can be given if they reside in 2 different levels. If the SD is at the same level, the privilege = Manage (10) privilege, which allows the SD to manage the card content in its sub-layer ("hy). All the actions performed by the appetiser 2 are authorized by the issuer, and the stick can be carefully supplied to the issuer SDUSD) and can be checked by the ISD. The Gp Cai Le (four) that can reside in the towel makes the Cosmos Path (TP) concept of the Saki communication. The TP phase is a privilege assigned to the sin and allows them to exchange commands via the GP Open milk. Otherwise the application is split on Gp %. The =11 diagram shows the Secure_(SD) layer clipping implementation. The full domain level includes Issuer Security Domain (ISD) 11G2, Supplemental Security Domain (10), 11G4, SSD, and Applications (Apps) 11〇8, 1110, 1112, and 1114. The ISD 1102 can have AM privileges and can control other entities in the SD hierarchy. The ISD (10) can control the application (1) taste 1114 ’ while the ISD 1102 can grant the μ privilege to the SSD 1104#〇SSD 11〇6. For example, 'SSD 11〇4 can control applications 11〇8 and 111〇. 10013373#Single Number A0101 Figure 12 shows another example of the Secure Domain (SD) hierarchy. SD layer Page 40 of 1 Page 1013091673-0 201225697 Times with scepter-based domain management. The IDS 1102 can verify the tokens from SSj) 1104 and/or SSD 1106. This token-based management enables the SSD 1106 to load its own application 1202 using the ISD 1102 verified token. Scepter verification may be performed using a token and/or key based verification implementation described herein or a similar implementation. Depending on how SCWS is implemented on the SC, different options can be applied to enable different stakeholder modes. Figure 13 shows an exemplary embodiment of a domain level as a global platform (GP) application using a web page word server (e.g., smart card web server (SCWS) 1310). As shown in Fig. 13, SCWS 131 can be implemented as an application in the owned SD, such as iso 1302 owned by the SC issuer. The ISD 1302 may have Authorization Management (AM) privileges and may spontaneously control the hierarchy shown in Figure 13. An application provider (e.g., a third party OP) SD (APSD) 1304 may be a UI for the application 1308 and has a delegation management ((10)) privilege to manage the OP application 1308. The scws management agent SD (SSD) 1 306 can be used for SCWS 131 and has DM privileges to manage SCWS 1310. The SCWS 1310 can be implemented as a GP application for the GP 1312. The MNO mode, the second party OP mode, and/or the non-MNO mode can be used to support the application of 〇p. The logic can reside in different SDs, such as APSD 1304. Application 1308 may be owned and/or managed by APSD 1304, which may be an entity different from SSD 1306 having SCWS application 1310 and a domain. Application 1308 and SCWS 1310 can communicate using trust path capabilities The second party and card issuer must agree to perform the business relationship for the implementation. For example, third parties and card issuers must grant SD and apply appropriate privileges.

The SCWS management can be performed by the card issuer via the SSD 1306, the SSD 1013091673-0 10013373# single number A01〇l page 41/100 pages 201225697 1306 can support OTA management capabilities, such as RAM over HTTP. If APSD 1 304 also supports the SCP80 protocol, the application and content may be 〇τA managed by a third party using a DM token. Figure 14 shows an exemplary implementation that SCWS can implement in a card's runtime environment (RTE). If the SCWS is implemented in the card's runtime environment (RTE), for example by the SC manufacturer, there is no way for third party applications to communicate with the SCWS, as access to the SCWS cannot be made public through the GP architecture. Therefore, the stakeholder model of the third party 0P is not supported. However, MN0 and non-mobile modes are supported. As shown in Figure 14, there is no 0TA communication between application 1306 and SCWS 1402' but the GP API and/or GP OPEN may not specify communication with the underlying RTE elements, such as RTE 1404 and/or SCWS 1402. If the APSD 1304 supports the SCP80 protocol, the application and content may be an OT managed by a third party using a μ scepter. 15A and 15B illustrate an exemplary implementation of a contract flow for the provisioning phase. The provisioning phase can be used, for example, for the SSO protocol. The provision shown in Figures 15A and 15B can be performed using GBA to derive a shared secret session secret (e.g., κ Γ ρ) between security modules 1 504 and 0P/NAF 1510. The security module 1 504 can include a smart card, USIM, UICC, Java card, smart card web server (SCWS) enabled smart card or other trusted entity on the WTRU. According to an exemplary embodiment, the security module 15〇4 may include a local device and/or a local web server, such as the scws described herein. As shown in Fig. 15A, at 1514, ME/BA 1 508 can be logged to RP 1512 with the 0P identification word. The RP 1512 can perform discovery at 1516 and establish an association with the network 〇P/NAF K10 at 1518. At 152 〇, rp 1512 can redirect ME/BA 1 508 to the network 〇p/NAF 151〇βΜΕ/Μ 15〇8 10013373^^'^^ Α0101 Page 42 of 10 Page 1013091673-0 201225697 Available in The 1522 performs a detailed lookup and decision process with the security module 1504. At 1524, ME/BA 1 508 can establish a TLS tunnel with OP/NAF 1510. The 1524 ’ OP/NAF 1510 may be the network entity that was identified in the agreement at this time. At 1526, the ME/BA 1 508 can send a request for an authentication page (eg, an HTTP GET request) to the network OP/NAF 1510. The OP/NAF 1510 can send an authentication request to the ME/BA 1508 at 1 528. At 1 530, the ME/BA 1 508 can send a request to the ME/GBA module 1 506 for the application specific GAA key. The ME/GBA module 1 506 can send an IMSI request to the security module 1504 at 1 532. At 1 534, the security module 1 504 can check for a valid temporary key Ks. The check may be performed, for example, at 1 532 after the IMSI request. At 1536, the security module 1504 determines if a valid temporary secret record Ks exists. If a valid temporary key Ks exists, no booting is performed and the message flow jumps to step 1580 (in Figure 15B) to derive the session key (e.g., Krp) from the temporary key Ks. If the valid temporary key Ks does not exist, then the boot is performed as described herein to generate a valid temporary key. Ο According to one embodiment, the booting can be performed as shown in steps 1538 through 1 579 of Figures 15A and 15B. The booting can be performed to authenticate (e. g., user authentication) and derive a temporary key (e.g.,

Ks_(exl7int)_NAF) is used to perform local authentication. Although one embodiment of the bootstrap protocol is illustrated at steps 1538 through 1579 of the 15A and 15B diagrams, other guidance and/or authentication protocols may be performed for authentication and/or generation, according to embodiments known to those skilled in the art. Temporary secrets. 10_Production Number As shown in Figure 15B, using the boot procedure performed by steps 1538 through 1579 of Figures 15A and 15B, the security module I504 can derive the temporary key A0101 at 1578. Page 43 / Total 1〇0 Page 1013091673 -0 201225697 (eg ' Ks_(ext/int)_NAF). The derivation uses a key derivation function that depends on Ks and/or other known parameters used in the contract. The security module 1 504 can send an external copy of the temporary key (e.g., Ks-extJAF) to the ME/GBA module 1 506 at 1579. An RP-specific session key (e.g., Krp) can be derived at 1580' security module 1504 for authentication of 1^1512. An internal copy of a particular session key (eg, 1^?) and a temporary secret record (eg, Ks_int_NAF) may be stored in security module 1504 at 1581. The validity period of the temporary key (e.g., Ks_ext_NAF) and the boot transaction identifier (B-TID) associated with the temporary secret record (e.g., Ks_ext_NAF) may be sent from the ME/GBA module 1506 to the ME/BA 1 508 at 1582. At 1583, a request containing a NAF_ID (e.g., an HTTP request) can be sent from ME/BA 1508 to ME/GBA 1506. At 1584, ME/GBA module 1 506 can send a command to security module 1504 to calculate a digest using an internal temporary key (e.g., Ks_int_NAF) as a password. Communication from the ME/GBA may also include a fully qualified domain name (FQDM). The security module 1504 can verify the FQDM at 1585 and calculate the digest at 1586. At 1587, the security module 1 504 can send a "after a summary with a temporary key as a password (e.g., Ks_int_NAF). The 1588 * ME/GBA module 1 506 can send a digest and a B-TID to the ME/BA 1508. The ME/BA 1508 can send a request containing a B-TID (eg, an HTTP request) to the network OP/NAF 1510 at 1 589. If the OP/NAF 1510 has a valid temporary key (for example, Ks_int_NAF), then the OP/NAF The valid temporary key can be used by 1510. The valid temporary key may match the corresponding key stored in the security module at the wireless device' and may be used to apply the same or similar HHH337# single number deletion 1 page 44 / total 1 page 1013091673-0 The same or similar key derivation functions for the 201225697 parameter set are exported. Otherwise, the 0P/NAF 1510 can obtain a valid temporary key from the BSF/HSS 1502 as shown in steps 1590 through 1592 of Figure 15B. For example, the network OP/NAF 1510 may send a request for a key and user security setting (USS) to the BSF/HSS 1502 at 1590. The request may also include a NAF_ID and a B-TID. At 1591, the BSF/HSS 1502 can derive a temporary key (for example, Ks_(ext/int)_NAF) and obtain GBA USS (GUSS). At 1592, the BSF/HSS 1502 can send a temporary secret record (e.g., Ks_(ext/int)_NAF), GUSS, and a key validity period for the temporary key to the network OP/NAF 1510. At 1 593, the network OP/NAF 1510 can validate the password attribute using a valid temporary key (e.g., Ks_int_NAF). The network OP/NAF 1510 may derive an Rp specific session key (eg, Krp) from the temporary secret record (eg, Ks_int_NAF) at 1594. The claim message can be signed at 1596 with a key established by the association. At 1 595, the network OP/NAF 1510 can send a redirect message to the ME/BA 1 508 to redirect the ME/BA 1508 to the RP 1512. The redirect message can include an authentication statement. The ME/BA 1508 can send an authentication statement to the RP 1512 at 1597, and the RP 1512 can confirm that the authentication statement is valid at 1598. 16A and 16B illustrate an exemplary embodiment of an authentication phase agreement flow. For example, the authentication phase can integrate the SSO protocol (eg, mobile local OpenlD) with the GBA. As shown in Figure 16A, the ME/BA 1608 can send a login request to the RP 1612 at 1614. The login request may include an identification word, such as a 0P identification word. At 1616, the RP 1612 can perform OP discovery. At 1618, the network OP/NAF 1610 can derive a token from the session key (eg, Krp) and the associated control code. 1013091673-0 10013373#single number A01〇l page 45/total page 201225697 name key ( For example 'Kasc). The network Op/NAF 1610 and RP 1612 can establish a shared secret signature key (e.g., Kasc) at 1 620. The ME/BA 1608 can be redirected to the local OP on the security module 1604 at 1 622 'RP 1612. The redirect message can include an associated control code. The security module 1604 and ME/BA 1 608 can perform detailed lookup and decision procedures at 1 624. At 1626, the security module 1604 can be logged from the session (eg,

The signature key (eg, Kasc ) is derived from Krp and the associated control code. The security module 1604 can sign the identity claim message at 1628 with a signing key (e.g., Kasc) and send the signed claim to the ME/BA 1608 at 1630. As shown in FIG. 16A, the signed announcement message can be sent to the ME/BA 1608 via the με/GBA module 1 606. At 1632, the signed claim message can be sent from the ME/BA 1 608 to the RP 1612, and at 1634, the RP 161 2 can use the signing key (e.g., Kasc) to verify the identity claim. After the RP 1612 verifies the identity claim, the user can access the service, for example via ME/BA 1 608. Figure 16B illustrates another exemplary embodiment of an authentication phase agreement flow. The contract flow shown in Fig. 16B is similar to the contract flow shown in Fig. 16A, but the contract flow shown in Fig. 16B shows a secure channel between the RP and the device. The protocol flow shown in Figure 16B can be used, for example, to perform an authentication phase for integrating Mobile Local OpenlD with GBA and provisional provisioning, which can be used for subsequent communications to support RP and device The establishment of a secure channel. As shown in FIG. 16B, at 1622a, the RP 1612 may include a temporary label '(eg, Nonerrp) in the redirect message of the ME/BA 1608. The secure channel mapping Kut can be derived from session keys (eg, Krp), associated control codes, and temporary flags (eg, Nonerrp). At 1628a, 10013373#single number A0101 page 46 of 100 1013091673-0 201225697 The security module 1604 can sign an identity claim message with the signing key and the secure channel key Kut. At 1 634a, the RP 1612 can verify the identity claim message with the signature secret record and the secure channel key Kut. The use of the secure channel key Kut supports the establishment and use of a secure channel between the RP and the security module and/or the device associated with the security module. In GBA, the Ks GAA master session key can be derived from the GBA module (ie, a software in 诎). Ks can be a concatenation of CK and IK returned by the AUTHENTICATE command sent to (10)^. In the case of GBA-ME, where UICC does not support GBA specific features,

The GBA module can reside on the device itself and derive a NAF-specific temporary key (eg, Ks_MF) from NAF_Ir^〇Ks (and RAND 'IMPI) ° Temporary key (eg, Ks_NAF) can then be used on request The identification of NAF is given to the application (for example, a browser). Although the security of the secret is guaranteed to remain within the Gba module, the security of the temporary key (eg, Ks_NAF) is the responsibility of the application. In GBA_ME (Standard GBA), the temporary key can be stored in the device and thus potentially known by the device owner. For security-sensitive operations, the variable GBA_U can store the GBA temporary key in the UICC. In GBA_U*, the temporary key Ks can be kept in the smart card, and two different methods can be used to derive the two keys. A temporary key (eg, Ks_ext_NAF) can then be given to the application. In order to indicate the use of GBA_im, the GUSS may contain information from the XRES of the LRES that must be bit-flipped. In GBA_Ut, the security module can be run in the 'GBA Export' module. The GBA module can run the UMTS AUTHENTICATE command, which causes the temporary 10013373^^^^ A〇101 page 47/100 pages 1013091673-0 201225697 The internal generation of the Ks and the temporary storage! USiM can return RES (and inverted LSB) to the GBA module. For actual authentication, the GBA module can send a NAF-ID to the USIM and thus receive a temporary key (e.g., Ks_ext_NAF) that can be used by the application. The temporary secret (e.g., 'Ks_ext_NAF) can be used by the application and has the same security features as the temporary key (e.g., Ks_NAF) in the GBA_ME. Further secret keys may be derived from a temporary key (e.g., Ks_NAF when GBA_ME is implemented) or another temporary key (e.g., Ks_int_NAF when GBA_u is implemented). Figure 17 shows an exemplary embodiment of a protocol flow for using DNS lookup as a means of bypassing the boot function. This can be performed, for example, during the provisioning phase of the ss〇 agreement, such as the OpenID/GBA protocol shown in Figures 15A and 15B. The entities shown in FIG. 17 include HSS 1 708, security modules (eg, UICC) 1704, ME 1706, OP/NAF 1718, and RP 1720. The security module 1 704 can be associated with a wireless device, such as WTR1], and includes a USIM 1710 and a local 〇p 1712. ME 1 706 may include BA 1714 and TCP/IP client 1716. OP/NAF 1718 and HSS 1708 may be part of a network, such as MN0 Network 1 702. As shown in FIG. 17, RP 1720 can send a redirect message to BA 1714 at 1722 and a BA 1714 to local 0P 1712. The redirect message can include an authentication request. At 1724, the BA 1714 may request (e.g., an HTTPS GET request) a local 0P fully qualified domain name (FQDN) from the TCP/IP client 1716. The TCP/IP client 171 6 performs a lookup at 1 726 to determine the local OP IP from the OP FQDN, and (optionally) at 10013373^^^ A〇101 page 48/100 pages 1091091673-0 201225697 1728 with Local 〇P 1712 establishes an HTTPS tunnel. At 1 730, the TCP/IP client 1716 requests (e.g., 'via an HTTPS GET message) the local OP identification word. The local OP 1712 determines at 1732 whether a session secret (e.g., Krp) exists, and if the session key exists, the local OP 1712 continues identity authentication as described herein at 1734. If the session secret record does not exist then the local 0P 1712 sends a redirect message to the bus 1714 at 1736 and the BA 1714 to the 0P/NAF 1718. The redirect message can include an authentication request. At 1738, the BA 1714 can request the 0P/NAF 1718 address from the TCP/1P client 171 6 . In an exemplary embodiment, the OP/NAF 1718 address may be a fixed ip in the SCWS, or a special 埠 0P FQDN of the OP/NAF 1718 with / resolved by the TCP/IP client 1716. At 1740, the OP/NAF 1718 can establish a TLS tunnel as described herein and/or perform authentication at the network. As shown in Figure 17, the protocol flow can use local DNS lookups as a means of bypassing the GBA module. RP 1 720 can redirect BA 1714 to the service using a URL of 0P/NAF 1718 (eg, ' http: //opsf. org). According to one example, 3GPP TR 33.924 may describe a network-based function that integrates the 〇peniD provider (OP) and 3GPP Network Application Function (NAF) functions' and may also provide exemplary OFDM functionality. The local DNS lookup maps the URL of the 0P/NAF 1718 to a known IP address of the local 0P 1712 (e.g., '127.0.0.1). Thus, 'BA 1714 is not redirected to 0P/NAF 1718, but is instead spoofed via local DNS lookup and directly into local 〇p 1712, as shown in Figure 17 from 1722 to 1 730. The BA 1714 can access the local 0P 1712 on the security module that is looked up by the local DNS. Then local 〇p can check to determine if a valid session key (1013091673-0 10013373#single number A〇1〇l page 49/100 pages 201225697 for example, Krp) exists. If so, the process can proceed to the authentication phase, such as the identification phase shown in Figures 16A and 16B. If there is no valid session key (eg, Krp), then local 〇p can redirect μ 1714 to the real IP address of 0P/NAF 1718. The BA 1714 can then continue to authenticate using the network side 0P/NAF 1718. The cryptographic association between session secret (e.g., Krp), signature secret (e.g., Kasc), and/or application specific GBA temporary secret (e.g., Ks_int_NAF) may be implemented via at least two implementations. According to an embodiment, if an appropriate key derivation function (KDF) is used, a session key (eg, Krp) may be derived from a temporary key (eg, Ks_int_JAF), ie, Krp=KDF(Ks-int_NAF) 'where The export can be done, for example, by a security module or USIM. According to another embodiment, a hash can be used to derive a session key (eg, Krp) from the secret Kop reserved by the local 0P and the AKA parameter RES calculated by the USIM, ie Krp=HMAC(Kop*, RES), This can be done by local 〇p alone. This embodiment can have slightly different semantics by indirectly linking to the temporary key 1 (_in t__NAF). Moreover, this implementation imposes additional requirements on the deployment to ensure semantics: local 0P is truly located and secure. The module or USIM is in the same ICC; however, the security module or USIM portion may remain unchanged as described herein and in the GBA module. According to the __ typical implementation, the security module or USIM can perform direct flow. An example of this is described in 3GPP TR 33.924 regarding identity management and 3GPP secure interconnection. Session secrets (eg, Krp) can be established based on 0P/NAF and local 0P known credentials/confidences' because of the The session key (eg, Krp) of 1013091673-0 can then be used to derive a secret key, such as a signature key (eg, Kasc) 1()() 13373#single number A0101 page 50 / total 1 page 201225697, To sign a claim message. The generation of a session key (eg, Krp) credential can be bound to a previous authentication process, such as GBA or AKA, to implement a secret session key in local OP and/or OP/NAF (eg, Krp) ) Established as part of the local 0P, the KDF residing on the security module or smart card can directly access and/or read the key material from the previous authentication. In an exemplary embodiment, in the case of GBA, local 0P can read a temporary secret record from the security module or USIM (eg, Ks_int_NAF) and perform key derivation using its own logic with a temporary key (eg, Ks_int_NAF), which acts as a session secret

D ^ Record (for example, Krp) the input parameters of KDF. In another embodiment, the local OP may request the security module or USIM (eg, via a designated interface or call) to derive the session key using a security key also known as OP/NAF or USIM internal KDF (eg, Krp) ). Local 0P can get the result of KDF and use / store session secret (for example, Krp). In both cases, 'OP/NAF can derive a temporary key (eg, 0 Ks_int_NAF) from the BSF (eg, via the Zn interface, such as the Zn interface shown in TS 33.220) and apply the same KDF to it. Get the session secret (for example, Krp ). 1013091673-0 Since the local 0P resides in the security module or %, it can be supplied by mn〇 (eg 'using the OTA mechanism' or when installed on the SC when personalized). In either case, the local 〇p application itself can be configured to be confidential (for example, stored as a Java Card object). The secret is then known to the local OP and MN0 (and thus to the OP/NAF operated by the MN〇 is known, the secret may be referred to herein as a κ〇ρ "convenient secret (eg, Krp) derivation) Can be separated from the security module (for example, USIM/UICC) capabilities, and can only be used from the network 10_7# single number A 〇 101 page 51 / total coffee page 201225697 (for example, GBA or AKA operation) output For example, RES from USIM. RES may contain implicit information about the USIM secret used for authentication. Local 0P may apply KDF to RES and Kop* to generate a session key (eg, Krp). According to one embodiment, even RES It is public, and entities other than 0P/NAF (and, for example, MN0) can export the same session secret (for example, Krp) ° 0P/NAF can compare RES and XRES, if they match, then from the same seed The session key (eg, Krp) is derived from the material to produce the same session secret (eg, Krp). The above embodiment can be used when the local OpenlD/GBA tries to use the local OpenID in a 'multi-factor' manner. Means trying to combine the SS0 agreement (for example, O penID) and any other implementation of authentication, signature, crypto vault or any confidential function on the UICC or elsewhere in the UE. It is desirable to protect the RP and, for example, Figure 15-16 for 0P/NAF Subsequent communication between devices (UEs). In this regard, separate and independent mutual authentication procedures can be used between the two entities. Several methods of implementing channel security are described herein. However, some implementations may not implement 0P. /NAF independence. In an exemplary embodiment, a modification of the authentication phase of the detailed protocol flow shown in Fig. 16B may be performed. At 1 622a of Fig. 16B, the temporary flag may be transmitted from the RP to the UE. As an additional input to the key derivation function, at 1626b, Kut can be derived from the session secret record (eg, Krp), the associated control code established between 0P/NAF and RP, and NonceRP. This provides the desired secure channel. This will change the initial OpenID contract because it will implement changes to the RP (for example, session control code for temporary flags, etc.). In terms of security, there is a minimum benefit 1337#单号应01第5 2 pages / total 100 pages 1013091673-0 201225697; because NonceRP may not be protected, it can (in principle) be read by 0P/NAF, and then 0P/NAF can generate the same declaration message. Isolation of 0P/NAF. In another exemplary embodiment, the UE and the RP may exchange temporary flags (n〇ncel from ϋΕ and nonce2 from RP) in the initial phase of the agreement (before discovery). For example, 'this can be performed at 1614 and/or 1616 in Figure 16B. This would be considered critical. 'Because 0P/NAF is not part of the initial communication, it is assumed that the temporary flag exchange is not visible. This can provide a prerequisite for isolation from the entity. Once O OpenID is complete, both ends can share a signature key (e.g., Kasc), for example, the Diffie-Hellman key agreement procedure can be used to establish a secret key that can be used to protect the channel. That is, the UE may send the following message to Rp: ax, Enc Kasc {SHA-X(ax, nonce2)} (where X is the random number selected by the UE, and Enc Kasc {SHA-X(ax, nonce2)} Indicates the cryptographic signature of A (signed by the signature key Kasc), where A is {ax, nonce2}); and the RP can send the following message to the UE: ay, Enc Kasc {SHA-X(ay,noncel)},( Where y is the temporary flag selected by the RP, and Enc Kasc {SHA-X(ay, noncel)} represents the cryptographic signature of B (signed by the signature key Kasc), where B is {ay, noncel}); Depends on discrete logarithms. The calculation can occur in the multiplicative group Zp* (derived from the intercept Zp), where P is a large prime and the value "a" is the generator of the large prime order subgroup (Zp*). Both a and p are well known, and therefore axy m〇d p can be calculated from both sides, thereby protecting the channel. The UE can know X, RP "5!* to know y. For example, knowing ay's UE has 1 delete 373# single number A0101 page 53 / 100 pages 1013091673-0 201225697 There is enough information to calculate axy mod p°RP can perform similar calculations using ay. Since signatures A and B can be verified by R P and U E respectively, the process involves mutual authentication, and assuming that OpenID/NAF does not involve initial communication, intermediate human attacks can be avoided. It is also possible to obtain a similar result by using only one temporary flag (for example, nonce 1 ) in the above two signatures. The Shared Signature Key (Kasc) can be used to provide signatures that support the authenticated version of the Diffie-Hellman Agreement. This a priori key sharing allows for the establishment of a secure channel without the use of Diffie Hermann. In another exemplary embodiment, as a modification to the above agreement, a secure channel may be initially established using a TLS tunnel. If a certificate authority (CA) is used, the RP public key can be sent to the UE via the certificate. The UE may generate a nonce and send it (encrypted using the RP public key) a temporary flag to the RP. The temporary flag can be used on both sides to generate a common symmetric key. 0P/NAF can be outside the loop because it is assumed that the user initiates communication. It is now possible to establish a secure transport layer channel in which one-way RP discrimination has taken place. Once OpenlD is complete, both sides can use the temporary flag and signature key (for example, Kasc) to generate the Kut. In addition, it can generate the desired secure channel and establish independence from 0/NAF. 0P/NAF seems to theoretically hijack the session (if it (not the UE) sends a temporary flag to the RP in the initial phase), but not in this article. 0P/NAF does not know the communication before it is discovered, and even if it is known, it is not a gangster. The embodiments described below outline the integrated variants of OpenlD (and local 0P) and AKA. Figure 18 shows a protocol flow for authentication and key agreement (AKA). 10013373^^'^^ A0101 Page 54 of 100 1013091673-0 201225697 An exemplary embodiment. The embodiments described herein can be implemented using AKA and CK/ΐκ. For example, the AKA key that can be authenticated using the CK/IK established on the network after successful AKA operation in the wireless device and/or security module can be provided to the local 〇p 1 802, for example in a security mode. Group 1804 is on 'or on mobile device (ME) 1806 of user equipment 1808. The session key can be derived from CK/IK by using a key derivation function (for example,

Krp) 1810 to provide the AKA key to the local OP 1 802 eCK/IK can be entered into the key derivation function, similar to the temporary key Ktmp ° described here which causes the network (eg, OPSF) and the device (eg , this % OP) has the same session key (for example, Krp) 1810 for the RP. After the session key is established, it can be used as described herein. Although AKA is described herein, other protocols can be used, such as IMS-based authentication or other authentication and key agreement protocols. In an exemplary embodiment, the number of AVs used for user authentication may be reduced. The AV can use the access to the HSS, and the query to the HSS will be reduced. In an exemplary embodiment, instead of using a new AV for each user login, the AKA mechanism is combined with a password (or a hash of a password, for example), which can be established between the user and the OP. The OP can be implemented as a web service' which has an interface for obtaining the HSS of the AV, and an HTTP interface for communicating with the UE/Browser. The user password can be securely shared with the OP. About User Passwords Two different streams are described here: the registration flow and the authentication flow. The registration flow can be used to authenticate and/or share a password, which occurs, for example, during the first login to the RP. The authentication stream can be used for subsequent authentication. For example, when a password is established, a authentication stream can occur. If the device (WTRU) reboots 'the AKA key becomes invalid' and is replaced by the network authentication procedure. 10013373#单号A〇1〇l Page 55 of 100 1013091673-0 201225697 Here is an example of a registration flow. Sexual implementation. In the registration stream, the user may want to log in at the RP. The user is redirected to the local 0P. Local 〇P can take AV from HSS (for example, based on IMSI). The local OP can challenge the UE for authentication (which can be performed via the HTTP digest AKA because OpenID uses the HTTP protocol and communication occurs between the browser and the local P). The browser can extract the AV from the request and proceed according to the HTTP digest AKA process. The local 0P can verify the response and can ask the user to choose a password before issuing the signed claim redirect message. Mutual authentication based on AKA AV can be implemented at this stage so that the local 0P can know the user. Communication can be secure based on CK, IK keys. The user can set the password with local 0P, where the password or its hash (eg, as in HTTP digest authentication) can be sent to the local 0P. 0P can store passwords (or hashes) and AV for future use. 0P can issue a signed statement message redirected to 0P. The UE can be redirected to the RP, the RP can verify the claim, and the user logs in to the RP. 1013091673-0 An exemplary embodiment of an authentication flow is described herein. In the authentication stream, the user may want to log in at the RP. Users can be redirected to the local 〇P. Local 0P may not be able to get a new AV from the HSS, but the stored AV can be used based on the IMSI. The local OP can challenge the UE for authentication, such as using a modified HTTP Summary AKA procedure. The local 0P indicates that the user password exists and the browser must be able to understand the flag (f 1 ag ). The browser can extract the AV from the request and proceed according to the HTTP summary AKA process. When the browser receives res from the security module or USIM, the browser can request a password from the user (as in HTTP digest authentication) and then use the appropriate encryption implementation (for example, by calculating rsp = f( rES | f (password))) Combine RES with a password, where f is a hash function (for example, SHA)) 10013373#single number A01〇l page 56/100 pages 201225697, and Ί ' indicates cascading. As a result, rsp can be used as a password in the screening response to the local liver. The local OP can perform the same calculation (e.g., if the hash of the password is known, the local OP can calculate xrsp = f(XRES丨 hash password))' and verify that the response rsp from the browse H matches xrsp. The local OP can issue a signed statement message redirected to Rp, can be redirected to the RP, the statement can be verified, and the user can log in to the Rp. If no additional encryption is used, the HTTP digest AKA performed in the registration and authentication stream can be performed in the HTTPS channel to protect the authentication information (e.g., 'authentication credentials' such as user secrets). The temporary flag may be part of the challenge message when the liver issues an authentication challenge to the wireless device in the registration or authentication flow. In such an implementation, the authentication response may compute a hash f(RES丨f(password)|nonce) and/or send it to 〇p, where the presence of the temporary flag may provide a freshness quality 计算 to the calculation. The hash provided in the response message can use the key to provide additional authenticity measurements by signature. If the OC has authentication information (e.g., user password) instead of its hash, the hash response can be f (RES 丨 password! nonce), where there is no internal hash of the password. In an exemplary embodiment, the hash chain can be used to derive n different one-time ciphers from the initial RES generated during the first authentication. The browser can extract..." and perform an AKA algorithm with the USIM. The browser can generate a seed value s and can calculate a hash key according to the seed value by subsequently applying a hash function, where the first of the hash chains Values V1 = hi(s), hi(s) = h(h(h(...h(s)) [i times]. The browser can use ικ on hn(s) to request signatures and RES It is sent to the local 0P along with the hn(S) and the signature. If RES=XRES, the local 0P can store the hash chain commitment hn(s). *Single number 10013373» Reward 1 Page 57 / Total (10) Page 1013 〇91673-〇201225697 In further authentication, the local OP may challenge the browser 'in the HTTP digest request' to provide the next (ie, the value before the index used in the last authentication) hash value (ie, at In the first authentication after registration and hash chain commitment, the browser can calculate hn_1(s) and send it to local 0P). Local 0P can now calculate h ( hn-l(s) ) = hn (S ) 'and compare it to the received hash key promise ◊ due to the one-way nature of the hash function' so it is difficult to guess hn-1(s) from hn (s), if possible. The seed value s of the chain can also be provided by a user password or PIN code, which can be requested each time the user authenticates. Similar to the 〇pen ID/GBA bound to the local Open ID at 16-1 7 In the embodiment described in the figure, the local entity can be used to sign the claim message 'without requiring AV to be used each time. The AV can be directly transmitted in the OpenID associated control code (ie, the network side 〇P-agg/〇PSF can be AV is obtained in the HSS, and RAND and AUTN can be integrated into the associated control code, which can be transmitted to the local 0P through the browser. The local 〇P (or browser) can extract the field, and Local 0P can perform AKA with USIM and sign the declaration with the result IK. If IK is not available for local 0P, or local 0P does not use USIM to sign the declaration, then the key can be derived from IK (like GBA) to use it To sign the statement, the hash chain method can be used to increase the number of possible authentications each time the AKA runs. In an exemplary embodiment, the local 0P cannot sign the claim message by itself, but can provide a web interface and application logic. For example, local 0P A claim message can be constructed, but without a signature. The local OP can then use the security module (eg, USIM/UICC) function to generate and/or calculate a signature. The signature can then be included in the Rp via the user browser. 10013373#Single number A01CU Page 58 of 100 Last page 1013091673-0 201225697 The final message. The local op can build an intermediate layer between the browser and the security model (eg, USIM/UICC) for the Open ID protocol when providing local claims for actual user authentication and saving network traffic. Figure 19A is a schematic diagram of an exemplary communication system 1 900 that implements one or more disclosed embodiments. Communication system 1 900 can be a multiple access system that provides content to multiple wireless users, such as voice, data, video, messaging, broadcast, and the like. Communication system 1 900 can enable multiple wireless users to access the content through the sharing of system resources, including wireless bandwidth. For example, communication system 1 900 can use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (0FDMA). ), single carrier FDMA (SC-FDMA), etc. As shown in FIG. 19A, communication system 1900 includes wireless transmit/receive units (WTRU) 1 902a, 1 902b, 1 902c, 1 902d, radio access network (RAN) 1904, core network 1 906, public switched telephone Network (PSTN) 1908, Internet 191G and other networks 1912, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Any of the WTRUs 1 902a, 1 902b, 1 902c, 1902d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 1902a, 1 902b, 1 902c, 1902d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, mobile phones, personal digits Assistants (PDAs), smart phones, notebooks, netbooks, personal computers, wireless sensors, consumer electronics, and more. Communication system 1 900 can also include base station 1914a and base station 1914b. Base Station 1〇〇1337#单编号A0101 Page 59/100 Page 1013091673-0 201225697 1914a, 191 4b Any of the types of devices configured to provide a wireless interface to at least one of the WTRUs 1902a, 1902b, 1902c, 1902d To facilitate access to one or more communication networks, such as core network 1906, Internet 1910, and/or network 1912. By way of example, base stations 1914a, 1914b may be base transceiver stations (BTS), node b, eNodeB, home node B, home eNodeB, site controller, access point (AP), wireless router, and the like. While base stations 1914a, 1914b are depicted as separate elements, it should be understood that base stations 1914a, i914b may include any number of interconnected base stations and/or network elements. Base station 1914a may be part of RAN 1904, which may also include other base stations and/or network elements (not shown), such as base station controllers (BSCs), radio network controllers, relay nodes, and the like. Base station 1914a and/or base station 1914b can be configured to transmit and/or receive wireless signals within a particular geographic area, which can be referred to as a community (not shown). The community can be further divided into Du District magnetic regions. For example, the community associated with base station l914a can be divided into three magnetic regions. Thus, in one embodiment, base station 1914a may include three transceivers, i.e., one transceiver for each magnetic zone of the community. In another embodiment, base station 1914a may use multiple input multiple output (MIM0) technology, and thus multiple transceivers for each magnetic zone of the community may be used. Base stations 1914a, 1914b may communicate with one or more of WTRUs 1902a, 1902b, 1902c, 1902d via null intermediaries 1916, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, Infrared (I r ), ultraviolet (uv), visible light, etc.). The null intermediaries 1916 can be established using any suitable radio access technology (RAT). 1013091673-0 10013373# Single bat number A01〇l Page 60 of 100 201225697 More specifically, as described above, communication system 1 900 can be a multiple access system and can use one or more channel access schemes For example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 1914a and WTRUs 1902a, 1902b, 190c in RAN 1904 may implement radio technologies, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish null intermediaries using Wideband CDMA (WCDMA). 1916. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved Fat (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDpA) and/or High Speed Uplink Packet Access ( HSUPA). In another embodiment, the base station 1914a*the WTRUs 19〇2a, 1902b, 1 902c may implement a radio technology, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE An empty mediation plane 1916 is established for the LTE-A technology. In another embodiment, base station 1914a and WTRUs 1 902a, 1902b, 1 902c may implement radio technologies, such as IEEE 802.16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2, CDMA2000 1X, CDMA2. 〇〇〇EV_D〇, Provisional Standard 2〇〇〇 (IS 2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS_856), Global System for Mobile Communications (GSM) 'Enhanced Data Rate for GSM Evolution (EDGE) ), GSM EDGE (GERAN) and more. The base station 1914b in Figure 19A may be a wireless router, a home node, or an access point, for example, and any suitable RAT may be used to facilitate wireless connectivity in a local area, such as a commercial premises, a seven-vehicle vehicle , campus, etc. In one embodiment, the base station 1914b and the WTRU plane 3373# single number deletion 1 1013091673-0 l9〇2c, i9〇2d may implement a radio technology, such as IEEE page 61/1 page 201225697 802.11' to establish a wireless area. Network (WLAN). In another embodiment, base station 1914b and WTRUs 1902c, 1 902d may implement a radio technology (e.g., IEEE 802.15) to implement a wireless personal area network (WPAN). In yet another embodiment, the base station l9Ub*WTRUs 1902c, 1 902d may use a cell based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico community or a femto community. As shown in Figure 19A, base station 1914b can have a direct connection to Internet 1910. Therefore, the base station 1914b does not have to access the Internet 191 via the core network 196. The RAN 1904 can be in communication with a core network 1906, which can be configured to provide voice, data, applications, and/or the Internet to one or more of the WTRUs 1 902a, 1 902b, 1 902c, 1 902d Any type of network for Voice over Voice (VoIP) services. For example, core network 1 906 can provide call control, billing services, mobile location based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high level security functions such as user authentication. Although not shown in FIG. 19A, it should be understood that RAN 1904 and/or core network 1906 can communicate directly or indirectly with other RANs that use the same RAT as RAN 1 904 or different RATs. For example, in addition to being connected to the RAN 1904 (the RAN 1 904 may be using E-UTRA wireless technology), the core network 1 906 may also be in communication with another RAN (not shown) that uses GSM wireless technology. Core network 1 906 may also serve as a gateway for WTRUs 1 902a, 1 902b, 1902c, 1902d to access PSTN 1908, Internet 1910, and/or other network 1912. The PSTN 1 908 may include a circuit switched telephone network that provides Plain Old Telephone Service (POTS). Internet 1910 can be 10013373^^'^ A〇101 Page 62 of 100 pages 1091091673-0 201225697 including global interconnected computer network systems and devices using public communication protocols, such as the TCP/IP Internet Protocol family Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (ip). Network 1912 may include a wired or wireless communication network that is owned and/or operated by other service providers. For example, network 1912 can include another core network connected to one or more RANs that can use the same RAT as RAN 1904 or a different RAT. Some or all of WTRUs 1 902a, 1902b, 1902c, 1 902d in communication system 1 900 may include multi-mode capabilities, ie, WTRU 1 90 2a, 1 90 2b, 1 902c, 1 902d may be included on different wireless links Multiple transceivers that communicate with different wireless networks. For example, the WTRU 1902c shown in FIG. 19A can be configured to communicate with base station 1914a (which can use cell-based wireless technology) and with base station 1914b, which can use IEEE 802 wireless technology. Figure 19B is a system diagram of an exemplary WTRU 1902. As shown in FIG. 19B, the WTRU 1902 can include a processor 1918, a transceiver 1 920, a transmit/receive element 1922, a speaker/microphone 1924, a numeric keypad 1926, a display/touchpad 1928, a non-removable memory 1 930, and a removable Memory 1932, power supply 1934, Global Positioning System (GPS) chipset 1 936, and other peripherals 1938. It should be understood that the WTRU 1902 can include any sub-combination of the aforementioned elements while remaining consistent with the embodiments. The processor 1918 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors, controllers, and micro-controls associated with the DSP core. 10, noodles No. A〇101 Page 63/100 pages 10109091673-0 201225697 Integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (1C ), state machine, and so on. The processor 1918 can perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 1 902 to operate in a wireless environment. Processor 1918 can be coupled to transceiver 1920, which can be coupled to transmit/receive element 1 922. While Figure 19B shows processor 1918 and transceiver 1 920 as separate components, it should be understood that processor 1918 and transceiver 1 920 can be integrated together in an electronic package or wafer. Transmit/receive element 1922 can be configured to transmit a signal to ' or receive a signal from a base plane (e.g., base station 1914a) on null plane 191 6 . For example, in one embodiment, the transmit/receive element 1922 can be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 1 922 may be a transmitter/detector configured to transmit and/or receive signals such as IR, UV or visible light. In yet another embodiment, the transmit/receive element 1922 can be configured to transmit and receive both RF and optical signals. It should be understood that the transmit/receive element 1 922 can be configured to transmit and/or receive any combination of wireless signals. Moreover, although the transmit/receive element 1 922 is shown as a separate element in Figure 19B, the WTRU 1 902 may include a number of transmit/receive elements 1922. More specifically, WTRU 1 902 may use a tricky technique. Thus, in one embodiment, the WTRU 1902 can include two or more transmit/receive elements 19 2 2 (e.g., multiple antennas) that transmit and receive wireless signals over the null plane 1916. The 1013091673-0 transceiver 1920 can be configured to modulate signals to be transmitted by the transmit/receive element 1922 and to demodulate signals received by the transmit/receive element 1 922. The WTRU 1902 may have multi-mode performance as described on 1 〇〇 1337 #单编号崖01 201225697. Thus, transceiver 1 920 can include multiple transceivers that enable WTRU 1902 to communicate via multiple RATs, such as UTRA, E-UTRA, and IEEE 802. 1 processor WTRU 1902 can mate To, and receive student input data from speaker/microphone 1924, numeric keypad 1926, and/or display/touchpad 1928 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor i9i8 can also output user data to the speaker/microphone 1924, the keyboard 1926, and/or the display/touchpad 19 tray. In addition, the processor 1918 can access the information and store the data to any type of appropriate memory, such as the non-removable memory 1930 and/or the removable memory 1932. The non-removable memory 1930 can include random access memory. (RAM), read-only memory (ROM), hard drive, or any other type of storage device. The removable memory 1 932 may include a user identity module (SIM) card, a memory stick, and a secure digital (SD) memory card. In other embodiments, the processor Q 1918 can access the information from, and store data on the WTRU 1902 (e.g., on a feeder or home computer (not shown)). The processor 1918 can receive energy from the power source 1934 and can be configured to allocate and/or control power to other components in the WTRU 1 902. Power source 1934 can be any suitable insult that powers WTRU 19〇2. For example, the power source 1 934 may include one or more dry cells (eg, cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (ημη), lithium ion (Li~10n), etc., solar cells, fuel Battery, etc. #〇面#单号A0101 Page 65/100 pages 1091091673-0 201225697 The processor 1918 can also be coupled to a gps chipset 1 936, which can be configured to provide information about the WTRU 19〇2 Location information of the current location (e.g., 'longitude and latitude') WTRU 1 902 may receive location information from the base station (e.g., base stations 1914a, 1914b) plus or in place of GPS chipset 1936 information on the null plane 191 6 and/or Or determining the location based on signal timing received from two or more neighboring base stations. It should be understood that the WTRU 1902 may obtain location information by any suitable location determination method while maintaining consistency of implementation. The processor 1918 is further coupled to other peripheral devices 1 938, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, peripheral device 1 938 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photo or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, a hands-free headset, blue Bud® modules, FM radio units, digital music players, media players, video game player units, internet browsers, and more. Figure 19C is a system diagram of RAN 19 04 and core network 1 906, in accordance with an embodiment. As described above, the RAN 1904 can communicate with the WTRUs 1 902a, 1 902b, 1 902c over the null plane 1916 using E-UTRA radio technology. The RAN 1904 can also communicate with the core network 1 906. The RAN 1904 may include 1 940a, 1 940b, 1 940c, but it should be understood that the RAN 1904 may include any number of 6 nodes 3 while remaining consistent with the embodiments. The eNodeBs 1 940a, 1 940b, 1940c may each include one or more transceivers for communicating with the WTRUs 1 902a, 1902b, 1 902c over the null plane 191 6 . In one embodiment 10013373# single number A0101, eNodeB 1940a, 1 940b, 1 940c may be implemented ΜΙΜΟ page 66 / 100 pages 1013091673-0 201225697 technology. Thus, the eNodeB 1940a, e.g., can transmit wireless signals to, and receive wireless signals from, the WTRU 1902a using multiple antennas. Each eNodeB 1940a, 1940b, 1940c may be associated with a special community (not shown) and configured to handle radio resource management decisions, handover decisions 'users' scheduling in the uplink and/or downlink, etc. . As shown in Fig. 19C, the 'eNodebs 1940a, 1940b, 1940c can communicate with each other on the X2 interface. The core network 1906 shown in Figure 19C may include a mobility management gateway (〇 MME) 1942' service gateway 1944, and a packet data network (PDN) gateway 1 946. While each of the foregoing elements are described as being part of the core network 19〇6, it should be understood that any of these elements may be owned and/or operated by entities other than the core network operator. The MME 1942 can be connected to each of the eNodes B 1940a, 1940b, 1940c' in the RAN 1904 via the S1 interface and acts as a control node. For example, MME 1 942 may be responsible for authenticating WTRUs i9〇2a, 19〇2b, 19〇2c, bearer start/destart, selecting a particular during initial attachment of WTRUs 1 902a, 1 902b, 1 902c Service gateway, and so on. The MME 1942 may also provide control plane functionality for switching between the RAN 19〇4 and other rans (not shown) that use other radio technologies (e.g., GSM or WCDMA). The service gateway 1944 can be connected to each of 6 nodes b 1940a, 1940b, 1940c of ran 19〇4 via the S1 interface. The service gateway 1944 can typically route and forward user profile packets to/from the WTRU l9〇2a '19〇2b, 1902<^the service gateway 1944 can also perform other functions, such as anchoring the user plane during handover between 6-node Bs In the downlink data available, 1013091673-0 10013373, the production order number A〇1〇l page 67/100 pages 201225697 triggers paging, management and storage of WTRUs 1 902a, 1902b, at WTRU 1 902a, 1 902b, 1 902c, 1 902c context, and so on. Service gateway 1944 may also be coupled to PDN gateway 1946, which may provide WTRUs 1 902a, 1 902b, 1 902c with access to a packet switched network (e.g., Internet 1910) to facilitate WTRUs 1902a, 1 902b, Communication between the 1902c and the IP enabled device. The core network 1906 facilitates communication with other networks. For example, core network 1906 can provide WTRUs 1902a, 1902b, 1 902c with access to a circuit-switched network (e.g., PSTN 1 908), thereby facilitating communication between WTRUs 1902a, 1 902b, 1 902c and conventional landline communication devices. Communication. For example, core network 1 906 can include or be in communication with an IP gateway (eg, an ip Multimedia Subsystem (IMS) server) that acts between core network 1906 and PSTN 1908. interface. In addition, core network 1 906 can provide WTRUs 1 902a, 1 902b, 1 902c with access to network 1912, which can include other wired or wireless networks that are owned and/or operated by other service providers. Even though the features and elements are described above in a particular combination, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in combination with other features and elements. Moreover, the methods described herein can be implemented in a computer program, software, or firmware that can be embodied in a computer readable medium that can be executed by a general purpose computer or processor. Examples of computer readable media include electronic signals (sent on a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, 'read only memory (_), random access memory (RAM), scratchpad, cache memory, semiconductor memory device, magnetic medium, such as internal hard Disc and removable disk, magneto-optical media and optical media 10013373^ early number Αί)1()1 page 68 / total 1 page 1013091673-0 201225697 , such as CD-ROM discs, and digital universal discs (DVD) ). The processor associated with the software is used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer. BRIEF DESCRIPTION OF THE DRAWINGS [0005] A more detailed understanding can be obtained from the following description of examples given in connection with the accompanying drawings, in which: FIG. 1 shows an exemplary embodiment of a protocol flow for OpenlD protocol operation. ;

Figure 2 shows an exemplary embodiment of a traffic flow for OpenID/GBA; Figure 3 shows an exemplary embodiment of a protocol flow for authenticating a user and/or a wireless device using local authentication; Another exemplary embodiment showing the use of local authentication to authenticate a subscriber stream and/or a protocol flow of a wireless device is shown; FIGS. 5A and 5B illustrate another use of local authentication to authenticate a subscriber stream of a user and/or wireless device. Exemplary embodiment;

6A and 6B illustrate another exemplary embodiment of a protocol flow for authenticating a user and/or a wireless device using local authentication; FIG. 7 illustrates an exemplary embodiment of an operational flow for the authentication phase; 8 illustrates an exemplary embodiment of an operational flow for a provisioning phase; FIG. 9 illustrates another exemplary embodiment of an operational flow for an authentication phase; An exemplary embodiment of a protocol flow for splitting a terminal situation; Figure 11 shows an example of a secure domain (SD) hierarchy (hierachy) 10013373#single reduction A〇101 page 69/100 pages 1013091673-0 201225697 Embodiment 12; FIG. 12 illustrates another exemplary embodiment of a secure domain (SD) hierarchy; and FIG. 13 illustrates security using a smart card web server (SCWS) as a global platform (GP) application An exemplary embodiment of a domain level; Figure 14 illustrates an exemplary embodiment of implementing SCWS in a card's runtime environment (RTE); Figures 15A and 15B illustrate the use of an SS0 protocol. Exemplary implementation of the agreement flow Method 16A shows an exemplary implementation of a protocol flow that integrates the authentication phase of the SSO protocol with the Generic Bootstrap Architecture (GBA); Figure 16B shows a generic boot that integrates the SS0 protocol with the device to pin the RP channel. An exemplary embodiment of a protocol flow for the authentication phase of a program structure (GBA); Figure 17 shows an exemplary embodiment of a protocol flow for lookup using a Domain Name Server (DNS); Figure 18 shows An exemplary embodiment for authenticating a protocol flow with an Key Agreement (AKA); Figure 19A illustrates an exemplary communication system that implements one or more disclosed embodiments; Figure 19B illustrates execution of one or An exemplary wireless transmit/receive unit of the plurality of disclosed embodiments; and a 19Cth diagram illustrates an exemplary system radio access network that implements one or more disclosed embodiments. [Main component symbol description]

[0006] 808 shared secret key K 10013373^^'^^ A〇101 page 70 / total 100 pages 1013091673-0 201225697 816 , Ktmp , Ks_NAF , CK / IK , Ks , Ks_ext_NAF ,

Ks_int_NAF temporary secret record 906, Krp secret session key 908 associated control code 1102, ISD issuer secure domain 1104, SSD supplementary secure domain 1404, RTE card runtime environment 1 504, USIM/UICC security module 1806, ME Mobile device 1 900 communication system 1 902a, 1 902b, 1 902c, 1 902d wireless transmitting/receiving unit 1 904, RAN radio access network 1 908, PSTN public switched telephone network 1914a, 1914b base station 1916 empty interfacing plane 1 922 transmitting /receiving component

1 942, MME mobility management gateway RP relying party B-TID boot transaction identification word K session secret record A associated control code S, Kasc signature secret DNS domain name server 0? 8? 0? 61111) server function BA Browser Agent AM Authorization Management 1013091673-0 1QQ13373#: Single Number A0101 Page 71 / Total 100 Page 201225697 DM Entrusted Management SCWS Smart Card Web Server GP Global Platform SD Security Domain RAM Random Access Memory GAA Universal Identification Structure AKA Secret protocol BSF boot program function FQDN fully qualified domain name

Kut secure channel redundancy RNC radio network controller KDF function G P S global positioning system PDN packet data network X2, S1 interface HHH337# single number deletion 1 page 72 / total 100 pages 1013091673-0

Claims (1)

201225697 VII. Patent Application Range: 1. A method for providing a session key associated with a service provider for local authentication at a wireless device, the method comprising: receiving a temporary key, wherein the temporary Deriving a key from a network authentication between the wireless device and a network entity; generating the session key associated with the service provider based on the temporary key, wherein the session key is The network entity is shared, and wherein the session key is configured for a local authentication performed at the wireless device; and storing the session key 用于 2 for the local authentication at the wireless device The method of claim 1, wherein the network authentication comprises an authentication and a key agreement. 3. The method of claim 2, wherein the authentication and key agreement protocol uses a shared secret between the wireless device and the network entity to derive the temporary key. The method of claim 1, wherein the network authentication comprises a boot program. 5. The method of claim 1, wherein the session key is generated using an internal key derivation function. 6. The method of claim 1, wherein the wireless device comprises a security module, and the method further comprises generating or storing at least one of the session keys using the security module. 7. The method of claim 1, wherein the network entity comprises an OpenID Server Function (0PSF). The method of claim 1, wherein the service provider is an OpenID Relying Party (RP). The method of claim 1, wherein the service provider is an OpenID Relying Party (RP). 9. The method of claim 1, the method further comprising: receiving an authentication key associated with the network authentication from the network entity: and deriving the from the authentication key Temporary key. 10. A method for performing local authentication on a wireless device, the method comprising: receiving an associated control code from a service provider, wherein the associated control code indicates that the service provider has performed a network with a network An association of entities; receiving authentication information associated with a user of the wireless device; authenticating the authentication information locally at the wireless device; based on the associated control code and a session associated with the service provider Generating a signature key, wherein the session key is derived from a network authentication between the network entity and the wireless device, and wherein the session key is configured to perform the wireless device a local authentication; and signing an identity claim using the signature key to indicate that the wireless device has verified the authentication information locally. The method of claim 10, wherein the session key is shared by the network entity for confirmation of the identity claim. The method of claim 10, wherein the session key is configured for multiple local authentications at the wireless device. 13. The method of claim 10, wherein the associated control code is received in an authentication request from the service provider. 14. The method of claim 10, wherein the network entity comprises a 0?61110 server function (0?8?). The method of claim 10, wherein the identity statement is configured to use the signature key at the location of the method of claim 10, the method of claim 10, the method of claim 10, the method of claim The network entity is confirmed. The method of claim 10, wherein the wireless device comprises a security module, and wherein the session key is stored in the security module. The method of claim 16, wherein the security key is used to generate the signature key. 18. The method of claim 10, wherein the wireless device comprises a local web server, and wherein the authentication information is received via the local web server. 19. The method of claim 18, the method further comprising transmitting a request for the authentication information via the local web server. The method of claim 18, wherein the security module comprises the local web server. The method of claim 10, wherein the associated control code is received via a local DNS lookup performed by an application on the wireless device. The method of claim 10, wherein the session key is derived from an authentication key associated with the network entity. The method of claim 10, wherein the service provider is an OpenID Relying Party (RP). 10013373#单号 A〇101 Page 75 of 100 1013091673-0