Method and apparatus for trusted federated identity

Reliable joint identity method and device

This application requires a US provisional patent application named "Identity Management on a Communications Device" filed on May 28, 2010, with the application number 61/396,602 and filed on February 9, 2010. The United States Provisional Patent Application No. 61/302,890 entitled "Method and Apparatus for Implementing Local and Mobile OpenID Provider (Method and Apparatus for Implementing Local and Mobile OpenID Provider)" enjoys priority, among which these applications The content of is hereby incorporated as a reference.

Internet users usually have multiple usernames and passwords that can be used for user authentication in order to access multiple websites. For example, Internet users can have a username/password combination for accessing social networking sites such as Facebook, and another username/password combination for accessing email sites such as Gmail . Although having multiple username/password combinations may be necessary for user authentication, Internet users may find it cumbersome to memorize each username/password combination. For example, Internet users may forget their username/password combination on a certain website and cannot access the website.

In order to make user authentication of Internet users less troublesome, single sign-on (SSO) solutions such as OpenID have been proposed. However, there are some shortcomings when implementing SSO as a web service. For example, the user may not have a secure channel to the web-based SSO provider. In addition, the user's control over the SSO provider may be very limited.

In addition, the verification in SSO may generate communication via the air interface, which may cause a burden on the network entity (that is, the OpenID (Open ID) provider (OP or NAF)) and the network itself due to the increase in business volume. In addition, mobile network operators (MNOs) may have to bear this additional business volume and processing costs.

In this application, we describe implementations that allow local and decentralized single sign-on (SSO) providers to be implemented in trusted environments such as smart cards, wireless smart phones, H(e)NB Or other types of equipment. The single sign-on provider can be an OpenID provider, a Liberty Alliance provider, an open authentication (OAUTH) provider, and so on. This application provides a collection of many different solutions and their implementation options. Although the concepts described may be in the context of the OpenID protocol, these ideas can be extended to other single sign-on (SSO) agreements and/or federated identification agreements.

In an example embodiment, the user environment can be used to enable open management security protocols so that the relying party (RP) can authenticate the user. The user environment may include: a user interface that uses a single sign-on security protocol to communicate with the RP to request access to the services provided by the RP on behalf of the user, where the RP may be outside the user environment, And it can communicate with the trusted provider of the single sign-on certificate to initiate user verification; and a processor, such as a trusted computing environment, which verifies the user for the trusted provider within the user environment, the processor It is configured to perform at least some functions of the trusted provider of the single sign-on certificate locally in order to restrict communication outside the user's environment during the verification process.

In another example embodiment, a method may be used to protect the user environment and/or the local assertion provider (LAP) in order to authenticate the user for the relying party in an open management security protocol such as OpenID. The method may include: receiving a redirect from the RP via the user interface indicating that the RP wishes to authenticate the user. The RP can communicate with a single sign-on (SSO) certificate such as an OpenID provider (OP). The trusted provider communicates; receives the user certificate from the user through the user interface; uses the received user certificate to verify the user for the RP, so that the trusted provider of the SSO certificate such as OP can be executed locally At least some functions of the RP, thereby restricting communication outside the user environment during the authentication process; and sending the authentication response to the RP via the user interface.

This overview is provided to introduce many concepts in a simplified form, and these concepts will be further described in the following detailed description. The purpose of this summary is not to identify the key features or basic features of the claimed subject matter, nor to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to those implementations that solve any or all of the disadvantages pointed out in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS A more detailed understanding can be obtained from the following description given with the aid of examples in conjunction with the accompanying drawings, in which: Figure 1A shows an example communication system that can implement one or more of the disclosed embodiments.

Figure 1B shows an example wireless transmission/reception unit that can implement one or more of the disclosed embodiments.

Figure 1C shows an example system radio access network in which one or more of the disclosed embodiments can be implemented.

Figure 2 shows the SAML protocol process used to exchange authentication and data between the identity provider and the service provider.

Figure 3 shows the OpenID protocol process that allows users to log in to different relying party sites using a single IP.

Figure 4 shows an example implementation of an agreement process for providing an SSO agreement with integrated OP on a trusted computing environment.

Figure 5 shows an example implementation of an agreement process that provides an SSO agreement with integrated OP on a trusted computing environment.

Figure 6 shows the OpenID protocol flow for association-based communication.

Figure 7 shows the OpenID protocol process for stateless signature verification.

Figure 8 shows an example implementation of integrating BONDI with OpenID based on associations.

Figure 9 shows an example implementation that integrates BONDI and stateless signature verification.

Figure 10 shows an example implementation of enabling split OP.

Figure 11 shows another example implementation of enabling separate OP.

Figure 12 shows the BSF function used in the GBA architecture.

Figure 13 shows an overview of the GBA architecture.

Figure 14 shows the GBA reference module derived from 3GPP TS 33.220.

Figure 15 shows the GBA reference module for the accessed network NAF derived from 3GPP TS 33.220.

Figure 16 shows the architecture scheme for Liberty/GBA.

Figure 17 shows an example implementation for GBA for MMO-supported flag assertion.

Figure 18 shows another example implementation of enabling separate OP.

Figure 19 shows an example implementation of enabling separate terminal/local OpenId.

Figure 20 shows the standard OpenID protocol.

Figure 21 shows the business process of OpenID/GBA from 3GPP TR 33.924 v9.1.0.

Figure 22 shows an example implementation of an agreement process for reducing airborne traffic.

Figure 23 shows an example implementation of internal routing for OP on SCWS.

Figure 24 shows an example implementation of the protocol process that allows the RP to use the stateless mode to perform OpenID authentication.

Figure 25 shows an example implementation of the protocol process that allows RP to use association-based mode to perform OpenID user authentication.

Figure 26 shows an example implementation of the protocol process for the improved stateless mode.

Figure 27 shows an example implementation for an improved association-based model agreement process.

Figure 28 shows the keyed-in hash message authentication code (HMAC) derived from NIST-FIPS PUB 198-1.

Figure 29 shows the business process of OpenID/GBA.

Figure 30 shows another example implementation of an agreement flow based on the associated communication mode.

Figure 31 shows another example implementation of an agreement flow based on the associated communication mode.

Figure 32 shows another example implementation of an agreement flow based on the associated communication mode.

Figure 33 shows another example implementation of the agreement process for stateless mode .

Figure 34 shows an example implementation of the protocol flow for detached terminals.

Figure 35 shows the trust relationship in OpenID.

Figure 36 shows an example implementation of the trust relationship with the local OP.

Figure 37 shows an example implementation of the trust relationship with the MNO.

Figure 38 shows an example implementation of SD layering with issuer SD.

Figure 39 shows an example implementation of SD layering with DM.

Figure 41 shows an example implementation of SCWS as a GP application.

Figure 42 shows an example implementation of SCWS implemented in the runtime environment of the card.

In this application, we describe local and decentralized single sign-on implemented in trusted computing environments, such as user equipment (UE), smart cards, smart phones, H(e)NB or other types of devices ( SSO) Supply-side ideas and concepts. The single sign-on provider may be an OpenID provider, a Liberty Alliance provider, an open authentication (OAUTH) provider, and so on. This application provides many different solutions and their implementation options. Although these concepts may be described in the context of the OpenID protocol, these ideas can be extended to other single sign-on (SSO) agreements and/or federated identification agreements.

The local mobile SSO protocol such as the local mobile OpenID is a concept that allows a locally located module or entity to perform the identity verification/assertion function as part of the SSO or identity management protocol such as the OpenID protocol. Locally located modules can be smart cards, SIMs, UICCs, Java cards, smart card web server (SCWS) enabled smart cards, smart phones and other wireless devices.

Local mobile SSO is used to collectively refer to those that can change part or all of the single sign-on (SSO) and related identity management functions that are usually performed by web-based SSO servers to local-based entities and /Or the term of the method executed by the module, wherein the entity and/or module is a part or all of the communication device itself, or such entity/module is physically and/or logically located in the communication device and/or its Near the user (that is, located locally). For example, the entity/module can be embedded in the device; attached to the device; or connected to the device through a local interface, wire, or short-range wireless device.

Local OpenID can also be used as a term to indicate a subset of the local mobile SSO method, thus, the SSO or identity management method is based on the OpenID protocol. For example, the local OpenID can be used to indicate the functions of the OpenID identification supplier (abbreviated as OP or OpenID IdP) that can be performed by a local entity/module.

The local IdP is a term used to indicate an entity or module that performs the function of the OpenID server. The prefix OPloc can be used to represent the local IdP. One of the main functions of the local IdP may be to facilitate the authentication of the user and/or device through one or more assertions about the user and/or device identification. This assertion can be sent from the local IdP to the browser agent (BA) running on the device, and then the browser agent can forward the assertion to an external relying party (RP). If one or more functions provided by the local IdP are restricted to provide such identification assertions, the local IdP can be referred to as a local assertion provider (LAP).

The local IdP can process, create, manage, or send assertion messages to one or more external recipients. These assertion messages can assert the verification status of one or more identities related to the user and/or the device. For example, in the OpenID protocol, a third-party entity called a relying party (RP) can be one of the recipients of the assertion message. The local IdP can also use signatures, encryption keys, passwords, etc. to sign the assertion message.

The native OpenID method can use one or more cryptographic keys, such as the root session key. The root session key can be represented by Krp, and can be the session key to be used between the RP and the OP. Krp can also serve as the root session key between the RP and the OP that can obtain other keys. The native OpenID method can also use an assertion key, which can be represented by Kasc. Kasc may be a signature key used to sign one or more assertion messages for user verification. Kasc can be derived from Krp.

The local OpenId method can also use a service called OpenID Server Function (OPSF), which can be used to generate, share, and distribute secrets that can be used by the local IdP and/or relying parties (RP). The external RP can treat the OPSF and the local IdP as a single entity. OPSF can also verify the signature issued by the local OpenID, and RP can get in touch with it directly, for example, through the public Internet. By modifying the local DNS resolution cache on the device to map the OPSF address to the local IdP, the browser on the device can be redirected to the local IdP.

The local OpenID method can also use a service represented by OP-agg, which can be used to facilitate the discovery of the local IdP on behalf of the RP.

1 Communication System Figure 1A is a diagram of an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides voice, data, video, messaging, broadcast and other content for multiple wireless users. The communication system 100 enables multiple wireless users to access these contents by sharing system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA) ), single carrier FDMA (SC-FDMA) and so on.

As shown in Figure 1A, the communication system 100 may include wireless transmission/reception units (WTRU) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, and a public switched telephone network (PSTN) 108. Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRU 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals, and may include user equipment (UE), mobile stations, mobile nodes, fixed or mobile user units, pagers, mobile phones, Personal digital assistants (PDAs), smart phones, laptops, notebook computers, personal computers, wireless sensors, consumer electronic devices, etc.

The communication system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of equipment configured to facilitate access to one or more communication networks by forming a wireless interface with at least one of the WTRUs 102a, 102b, 102c, 102d, For example, the network may be the core network 106, the Internet 110, and/or the network 112. For example, the base stations 114a and 114b may be base transceiver stations (BTS), node-B, eNodeB, home nodeB, home eNodeB, site controller, access point (AP), wireless router, etc. Wait. Although each base station 114a, 114b is described as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 104, where the RAN may also include other base stations and/or network elements (not shown), such as base station controller (BSC), radio network controller (RNC), relay Nodes and so on. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a specific geographic area called a cell (not shown). The cell can be further divided into cell magnetic regions. For example, the cell associated with the base station 114a can be divided into three magnetic regions. Therefore, in an embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a magnetic area of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, so that multiple transceivers may be used for each magnetic region in the cell.

The base stations 114a, 114b can communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 116, which can be any suitable wireless communication link (such as radio frequency (RF), microwave, infrared). (IR), ultraviolet (UV), visible light, etc.). The air interface 216 can be established using any suitable radio access technology (RAT).

More specifically, as described above, the communication system 100 may be a multi-access system, and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and so on. For example, the base station 114a and WTRU 102a, 102b, 102c in the RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use wideband CDMA (WCDMA) to Establish an air interface 116. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include high-speed downlink packet access (HSDPA) and/or high-speed uplink packet access (HSUPA).

In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or Advanced LTE (LTE-A) to establish the air interface 116.

In other embodiments, the base station 114a and the WTRU 102a, 102b, 102c can implement IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, and interim standard 2000 (IS-2000). ), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN) and other radio access Technology.

The base station 114b in Figure 1A can be a wireless router, home node B, home eNode B, or access point, and can use any appropriate RAT to facilitate wireless in local areas such as business premises, residences, vehicles, and campuses. connect. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may establish picocells or femtocells by using a cell-based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in FIG. 1A, the base station 114b can be directly connected to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 through the core network 106.

The RAN 104 may communicate with a core network 106, which may be configured to provide voice, data, applications, and/or Internet protocols to one or more of the WTRUs 102a, 102b, 102c, and 102d Voice (VoIP) service of any type of network. For example, the core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connection, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in Figure 1A, it should be understood that the RAN 104 and/or the core network 106 can directly or indirectly communicate with other RANs that use the same RAT or a different RAT as the RAN 104. For example, in addition to connecting to the RAN 104 that can use E-UTRA radio technology, the core network 106 can also communicate with another RAN (not shown) that uses GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, and 102d to access the PSTN 108, the Internet 110, and/or other networks 112. PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global interconnected computer network equipment system using public communication protocols, which may be the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP) and the Internet Protocol in the TCP/IP Internet Protocol Family (IP). The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another core network connected to one or more RANs, where the one or more RANs may use the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. In other words, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers that communicate with different wireless networks on different wireless links . For example, the WTRU 102c shown in Figure 1A may be configured to communicate with a base station 114a using cell-based radio technology, and may communicate with a base station 114b using IEEE 802 radio technology.

Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmission/reception element 122, a speaker/microphone 124, a digital keyboard 126, a display/touch pad 128, a non-removable memory 130, and a removable memory Body 132, power supply 134, global positioning system (GPS) chipset 136 and other peripheral devices 138. It should be understood that, while maintaining compliance with the implementation, the WTRU 102 may include any sub-combination of the foregoing elements.

The processor 118 may be a general-purpose processor, a special-purpose processor, a traditional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with the DSP core, a controller, a microcontroller , Dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state device, etc. The processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, and the transceiver 120 may be coupled to the transmission/reception element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmission/reception element 122 may be configured to transmit signals to or from a base station (for example, the base station 114a) via the air interface 116. For example, in one embodiment, the transmission/reception element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, for example, the transmission/reception element 122 may be a transmitter/detector configured to transmit and/or receive IR, UV, or visible light signals. In yet another embodiment, the transmission/reception element 122 may be configured to transmit and receive RF and optical signals. It should be understood that the transmission/reception element 122 may be configured to transmit and/or receive any combination of wireless signals.

In addition, although the transmission/reception element 122 is described as a single element in Figure 1B, the WTRU 102 may include any number of transmission/reception elements 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, in one embodiment, the WTRU 102 may include two or more transmission/reception elements 122 (eg, multiple antennas) that transmit and receive radio signals via the air interface 116.

The transceiver 120 may be configured to modulate the signal to be transmitted by the transmission/reception element 122 and demodulate the signal received by the transmission/reception element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Therefore, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs such as UTRA and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to the speaker/microphone 124, the digital keyboard 126, and/or the display/touch panel 128 (such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and Receive user input data. The processor 118 can also output user data to the speaker/microphone 124, the digital keyboard 126, and/or the display/touchpad 128. In addition, the processor 118 can access information from any suitable memory such as the non-removable memory 130 and/or the removable memory 132, and store the information in these memories. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. The detachable memory 132 may include a user identification module (SIM) card, a memory card, a secure digital (SD) memory card, and so on. In other embodiments, the processor 118 may access information from and store data in memory that is not actually located in the WTRU 102, where, for example, the memory may be located on a server or a home computer (Not shown).

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control the power for other components in the WTRU 102. The power source 134 may be any suitable device that powers the WTRU 102. For example, the power supply 134 may include one or more dry battery packs (such as nickel cadmium (Ni-Cd), nickel zinc (Ni-Zn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, Fuel cell and so on.

The processor 118 may also be coupled with a GPS chipset 136, which may be configured to provide location information (eg, longitude and latitude) related to the current location of the WTRU 102. As a supplement or alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (such as base stations 114a, 114b) via the air interface 116, and/or based on receiving information from two or more nearby base stations Signal timing to determine its location. It should be understood that, while maintaining compliance with the implementation, the WTRU 102 may use any appropriate positioning method to obtain location information.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functions, and/or wired or wireless connections. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and videos), universal serial bus (USB) ports, vibration devices, TV transceivers, hands-free headsets, Bluetooth ®Modules, frequency modulation (FM) radio units, digital music players, TV game instrument modules, Internet browsers, etc.

Figure 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As described above, the RAN 104 may use E-UTRA radio technology and communicate with the WTRUs 102a, 102b, 102c via the air interface 116. And the RAN 104 can also communicate with the core network 106.

The RAN 104 may include eNode-Bs 140a, 140b, 140c, but it should be understood that the RAN 104 may include any number of eNode-Bs while maintaining compliance with the embodiment. Each eNode-B 140a, 140b, 140c may include one or more transceivers to communicate with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-B 140a, 140b, 140c may implement MIMO technology. Thus, for example, the eNode-B 140a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a.

Each eNode-B 140a, 140b, 140c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, users in uplink and/or downlink Scheduling and so on. As shown in Figure 1C, eNode-Bs 140a, 140b, and 140c can communicate with each other via the X2 interface.

The core network 106 shown in FIG. 1C may include a mobile management gateway (MME) 142, a service gateway 144, and a packet data network (PDN) gateway 146. Although each of the aforementioned components is described as being part of the core network 106, it should be understood that any of these components may be owned and/or operated by entities other than the core network operator.

The MME 142 can be connected to each of the eNodeBs 140a, 140b, and 140c in the RAN 104 via the S1 interface, and can act as a control node. For example, the MME 142 may be responsible for authenticating users of WTRUs 102a, 102b, 102c, activating/deactivating bearers, selecting a specific service gateway during the initial attachment process of WTRUs 102a, 102b, 102c, and so on. The MME 142 may also provide control plane functions to switch between the RAN 104 and other RANs (not shown) that use other radio technologies such as GSM or WCDMA.

The service gateway 144 can be connected to each of the eNode-Bs 140a, 140b, and 140c in the RAN 104 via the S1 interface. The service gateway 144 can generally route to the WTRUs 102a, 102b, and 102c and forward user data packets from the WTRUs 102a, 102b, and 102c. The service gateway 144 can also perform other functions, such as anchoring the user plane during the handover between eNode-B, triggering paging when downlink data is available for WTRU 102a, 102b, 102c, management and storage The context of the WTRU 102a, 102b, 102c, etc.

The service gateway 144 can also be connected to a PDN gateway 146, which can provide WTRUs 102a, 102b, 102c with access to a packet-switched network such as the Internet, so as to facilitate WTRUs 102a, 102b, 102c and Communication between IP-enabled devices.

The core network 106 can facilitate communication with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, the core network 106 may include or communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), where the IP gateway serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

2.3 Identity management and available security When users start accessing information on mobile devices, they face the dilemma of handling too many user certificates for one web service one after another. Users are faced with the cumbersome task of memorizing these certificates and entering login and password information every time they access the web service. Although the device may remember these certificates, the device may be lost or stolen, and it may end up in the hands of someone who shouldn't own it.

What is provided can be a solid authentication solution that combines local user authentication with transparent network authentication. For example, a variety of passwords or token items and/or biometric authentication technologies can be used in combination with a greeting-style seamless network authentication scheme, where the scheme is in cooperation with a web service portal. These schemes can be called single sign-on (SSO) or federated identity.

The mobile platform can include UE, which can support a variety of dedicated processor architectures and operating systems. This creates a fragmented market for software/firmware developers and forces operators to negotiate with OEMs to introduce and support common technologies such as access control and authentication. The following section discusses the implementation of the SSO agreement on the mobile platform.

In an example embodiment, the open management security protocol can be enabled by using the user environment to enable the relying party (RP) to authenticate the user. The open management security protocol may be a single sign-on protocol (SSO), such as the OpenID protocol, the Liberty Alliance protocol, the open authentication (OAUTH) protocol, the security assertion markup language, the identity assurance framework, and so on. The relying party can be a party that wishes to verify or verify the user's certificate.

The user environment may include a user interface and/or a processor, such as a trusted computing environment.

The user interface can provide an interface between the UE and the user. For example, the user interface can be a web browser, web page, application, and so on. The user interface can also receive user certificates. The user certificate can be a combination of user name, password, PIN code, key, token, biometric identification, and so on.

The user interface can provide an interface and/or use an SSO protocol such as OpenID to communicate with the RP to request access to the services provided by the RP on behalf of the user. For example, a user can use a user interface proxy such as a web browser to access the RP, and can use OpenID to choose to log in. The user interface may also receive an instruction from the RP indicating that the RP wishes to authenticate the user. For example, the user interface may receive a redirect message from the RP, where the message instructs the user interface to use a trusted computing environment to authenticate the user.

The user interface can also initiate user authentication by communicating with trusted providers of SSO certificates. For example, the RP can redirect the user interface to a trusted computing environment that can be associated with a trusted provider. The trusted provider may be a user certificate provider. For example, it is possible for a trusted provider to know the user and be able to verify the user through a certificate provided by the user.

The processor can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with DSP cores, controllers, microcontrollers , Dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state machine, etc. In addition, in an example embodiment, the processor may be a trusted computing environment, such as a UMTS integrated circuit card (UICC), a user identification module (SIM), a machine-to-machine (M2M) device, and a smart card , Java Card, Global Platform Smart Card, Security Integrated Chip Card (ICC) and so on. The trusted computing environment can be implemented using a smart card web server (SCWS).

The trusted computing environment can authenticate users for trusted suppliers within the user environment. In order to verify the user, the trusted computing environment may locally perform at least some functions of the trusted provider of the single sign-on certificate, so as to restrict communication outside the user environment during the verification process. For example, the user can perform verification locally in the trusted computing environment through a PIN code, a biometric identification, a token, etc., or a combination thereof (ie, a PIN code and a biometric identification). The trusted computing environment can generate a verification response. The trusted computing environment may use a redirect message to redirect the user interface agent to the RP, where the redirect message may include an assertion that the user is verified. The user interface can then be redirected to the RP, and the user can log in after the RP has verified the assertion from the trusted computing environment.

In an example embodiment, the trusted computing environment may calculate a signature, such as a base64 (basic 64-bit) encoded HMAC signature, and may provide the signature to the RP via the user interface. For example, by performing this process, the RP can be allowed to verify the certificate of the trusted computing environment. The trusted environment can calculate the signature based on the shared secret between the trusted computing environment and the trusted provider that may be associated with the MNO or OP. The shared secret may be established between the trusted computing environment and the trusted provider through the user interface. This signature can be used to sign the parameter list received from the RP.

Relying parties (RP) can be services, websites, databases, applications, and so on. In an example embodiment, the RP may be outside the user environment. For example, the RP may be a website hosted on a server outside the user environment, where the user environment may be, for example, a mobile phone or other UE used by the user to access the website. The RP may have to establish a connection, such as using the public Internet communication provided by the mobile network operator (MNO) for the web service entity to establish the connection. For example, this processing can be performed when the relying party (RP) cannot directly communicate with the trusted computing environment. The MNO may have a remote management interface that forms an interface with the trusted computing environment, and additional communication channels such as SMS, which may allow the MNO to communicate with the UE and/or the trusted computing environment. The MNO can act as a negotiation bridge between the RP and the OP on the trusted computing environment.

In another example embodiment, the RP may be in a user environment. For example, the RP may be located inside the UE, which may include a user interface and a trusted computing environment.

In an example embodiment, the RP may be configured to transmit a verification request in order to allow the RP to verify the trusted computing environment's certificate. The user interface can receive authentication requests from RP. The verification request may include association control. The user interface can provide this associated control to the trusted computing environment. The trusted computing environment can generate a signature based on a shared secret, and can generate a verification response including the signature and associated control. The user interface or the trusted computing environment can provide the verification response generated by the trusted environment to the RP.

In an example embodiment, the user environment may be inside a user equipment (UE). For example, the user interface and the trusted computing environment may be contained within a single UE. In another example embodiment, the user environment may be deployed in a separate terminal configuration, where the user interface and the trusted computing environment may reside in separate UEs. For example, the user interface can be on the user's mobile phone, and the trusted computing environment can be on the user's bank card or UICC. For another example, the user interface may be on the user's personal computer, and the trusted computing environment may be on the user's mobile phone.

In an example embodiment, by providing a method for protecting the user's environment and/or local assertion provider (LAP), the user can be authenticated for the relying party (RP) in the open management security protocol. In an example embodiment, the LAP may be inside the processor, such as inside a trusted computing environment. An instruction from the RP can be received via the user interface, where the instruction indicates that the RP wishes to authenticate the user. The RP can be outside the user environment and can communicate with trusted providers of single sign-on (SSO) certificates. The user certificate can be received from the user through the user interface. The user can be verified with the received user certificate. For example, a processor such as a trusted computing environment can use the received user certificate to verify the user for the RP, so as to execute at least some functions of the trusted provider of the SSO certificate locally, thereby restricting the use during the verification process. Communication outside the users environment. Authentication can be done by using a smart card web server (SCWS).

The verification response can be sent to the RP via the user interface. For example, the verification response can be sent when the user has been verified.

The indication received from the RP may be a redirect message. The redirect message may instruct the user interface to use the trusted computing environment to authenticate the user. For example, the redirect message can instruct the browser to authenticate the user locally instead of being authenticated by a trusted provider.

The signature can be, for example, a base64-encoded HMAC signature, which can be calculated and provided to the RP via the user interface. For example, by performing this process, it is possible to allow the RP to verify the certificate of the trusted computing environment. The trusted computing environment can verify the certificate based on a shared secret between the trusted computing environment and a trusted provider such as an OpenID provider that may be associated with the MNO. The shared secret may be established between the trusted computing environment and the trusted provider through the user interface.

In an example embodiment, the verification request may be received from the RP, which may allow the RP to verify the trusted computing environment's certificate. For example, the user interface can receive authentication requests from RP. The verification request may include association control. The user interface can provide associated control to the trusted computing environment. It is possible to generate a signature based on a shared secret. In addition, a verification response including the signature and associated control can also be generated. Then, the verification response can be provided to the RP.

2.3.2 Single sign-on implementation using OpenID and SCWS OpenID can provide an easy role for operators to provide trust in the OpenID provider (OP) to the relying party (RP) with minimal effort and risk. OpenID can cooperate with previously existing authentication methods, so that operators can use their own AAA and AKA certificates provided in advance in UICC or other authentication methods to support the authentication process for OP, including but not limited to PKI, Pre-shared key, SIP-digest certificate, TLS, etc.

The combination of OpenID and smart cards provides a way to an interesting value proposition. The Smart Card Web Server (SCWS) provides a brand-new IP-based service that can provide users with a much richer and very secure Web experience. The basic function of a web server is to use the HTTP protocol to deliver web pages. This is the same for SCWS residing on a smart card or UICC. SCWS can be the first step to integrate UICC as a network node in the mobile phone providers IP network.

In an example embodiment, the UICC can be used as the operator's local trust center and agent. For example, by performing this process, the verification business volume can be kept locally, and the burden on the operator's network can be avoided. The OP can enable multiple methods for binding the OpenID certificate to the UICC and/or device and/or user identification and/or user by scaling the verification strength. For example, OpenID can interact with a UICC-based UE to verify AKA certificates, GBA, or other forms of verification mechanisms, where the verification mechanism may be a certificate-based verification mechanism. In the embodiment disclosed here, the UE can provide checks and balances for the OP agent on the device to trust and reputation of the operator, so as to provide higher security with the help of the standard OpenID protocol.

2.3.3 OP on the smart card In the following section 4, several implementations are described. These implementations describe the integration of the OP on the smart card. For example, one of the embodiments describes the OpenID on the smart card hosting the smart card web server (SCWS). Another embodiment describes the improvement of OpenID on SCWS.

The benefits from the implementation described here can include: · User mobility when using OpenID · Improved user control of certificates (enhanced security protection), because this important information is now on the card Instead of being in the cloud, the need to use GBA is reduced, thereby significantly reducing the burden of network resources. The verification business volume is limited to the public Internet between network entities, without the need for air transmission- For the improved protocol of OpenID on SCWS, this is very obvious. 3 Standardization prospects have many formal and de facto (industry) standardization organizations that are engaged in identification management (IdM); however, most of these organizations Focus on the use of IdM in the desktop environment. The implementations disclosed here provide IdM through local and/or distributed SSO providers. These providers can be implemented in trusted environments such as smart cards, or on platforms that can include trusted computing environments. Implementation, such as smart phones, H(e)NB or other types of equipment. Single sign-on suppliers can be provided by standardization organizations, such as Liberty Alliance suppliers, SAML suppliers, Kantara Initiative (initiating) suppliers, OpenID suppliers, and so on.

3.2 Freedom Alliance The Freedom Alliance was initiated as an industry forum led by companies such as BT, AOL, Oracle, Intel, NTT, CA, Fidelity Investment, NTT, and Sun Microsystems. The alliance has released the Liberty Alliance Frameworks (Free Federation Framework) series of specifications for ID Federation (ID-FF) and Identity Web Services (ID-WSF).

ID-FF Specification 1.0 is a specification that allows consumers and users of Internet-based services and e-commerce applications to authenticate and log in to the network or domain once from any device, and then access The service of multiple websites thus avoids the need for users to re-authenticate and control privacy issues. The Liberty Alliance also released two versions of the logo joint specification and provided its joint specification to OASIS (http://www.oasis.org), which formed the basis of Security Assertion Markup Language (SAML) 2.0. In addition, the Liberty Alliance also released the Liberty Alliance Web Service Framework (ID-WSF), which addresses web services based on logos. This specification is an open framework for deploying and managing a variety of identity-based web services in a secure and privacy-respecting joint social network. For example, these web services can be geolocation, contact book, calendar, mobile messaging, and so on.

The embodiments disclosed herein disclose innovations that can be used to provide support for the security and other aspects of the Liberty Alliance standard in the context of the UE. For example, one embodiment discloses a mobile device that has a secure environment as a removable module or as an integrated module, such as a UICC, a smart card, or an integrated trusted environment (TrE), where the secure environment can be a standalone Or co-host some of the disclosed functions, such as the trusted ticket server or TTverifier (TT verifier) function on the UE. Compared with the functions currently available for conventional UEs that only support existing Liberty Alliance customer agreements, these disclosed functions can be added individually or collectively to more security and trust evidence.

3.3 OASIS and SAML Structured Information Standards Promotion Organization (OASIS) is a global open association for the development, integration and adoption of e-commerce and web service standards. In the context of IdM, OASIS has developed the Security Assertion Markup Language (SAML), and its current version is 2.0.

SAML is an XML-based standard that is used to exchange authentication and authorization data between security domains, that is, between the identity provider (the creator of the identity assertion) and the service provider (the user of the assertion). SAML attempts to solve the single sign-on (Web SSO) problem of web browsers in order to extend the traditional SSO solution based on the network to the open environment of the Web. SAML attempts to use open standardized protocols based on XML (and XHTML) to overcome the proliferation of non-interoperable proprietary technologies. SAML differs from other IdM technologies such as OpenID in that it relies on user agents to provide requests and assertions.

Figure 2 shows the SAML protocol used to exchange authentication and data between the identity provider and the service provider.

The embodiments disclosed herein disclose innovations that can be used to provide support for the security and other aspects of SAML in a UE context. For example, one of the embodiments discloses a mobile device that has a secure environment as a removable module or as an integrated module, such as a UICC, a smart card, or an integrated trusted environment (TrE), where the secure environment can be a standalone Or co-host some of the disclosed functions, such as the trusted ticket server or TTverifier function on the UE. Compared with the functions currently available for conventional UEs that only support existing SAML client agreements, these disclosed functions can add more security and trust evidence individually or together.

3.4 Kantara Initiative The Kantara Initiative is the successor organization of the Freedom Alliance and is led by some of the original supporters of the Freedom Alliance, such as BT, NTT, T-Mobile, AOL and Fidelity Investment. Kantara is not a standard definition organization (SDO), because Kantara publishes recommendations and focuses on two main technical topics: identity assurance and interoperability.

Kantara first stipulated the Identity Assurance Framework (IAP) v2.0 that extended the IAP v1.0 specification work made by the Liberty Alliance. The IAP specification initially detailed a lot of identification assurance levels, which will help to identify trusted identification-enabled companies, social networks, and Web 2.0 based on public standardized rules and the security risk assessment associated with each identification assurance level. Applications are linked together. Likewise, the framework enables flexible and granular trust guarantees for identification requirements and evaluations. The required assurance levels are based on the four assurance levels outlined in NIST Special Publication 800-63, version 1.0.1, and their confidence levels range from low to high.

The embodiments disclosed herein disclose innovations that can be used to provide support for the security and other aspects of IAP in the context of the UE. For example, one of the embodiments discloses a mobile device that has a secure environment as a removable module or an integrated module, such as a UICC, a smart card, or an integrated trusted environment (TrE), where the secure environment can be either alone or Co-host some of the disclosed functions, such as the trusted ticket server or TTverifier function on the UE. Compared with the functions currently available for conventional UEs that only support the existing Kantara IAP client agreement, the disclosed functions can be added individually or collectively to more security and trust evidence.

3.5 OpenID OpenID is an open standard for authenticating users. This standard can be used for access control to allow users to use the same digital ID to log in to these services when different services trust the authentication organization. OpenID replaces the conventional user registration process, thereby allowing users to log in once and access the resources of multiple software systems. The term OpenID can also refer to the ID used in the standard.

OpenID is developed and maintained by the OpenID Foundation, which is an American non-profit organization. The OpenID Foundation (OIDF) is made up of individuals and companies dedicated to enabling, promoting, and protecting OpenID technology.

As the term for ID used in the OpenID protocol, OpenID is a form of unique URL and is verified by the user's OpenID provider (that is, the entity hosting its OpenID URL). The OpenID protocol does not rely on a central authority to verify user identification, nor does it rely on a specific verification method itself. Since neither the OpenID protocol nor the website that requires identification can enforce specific types of authentication, multiple authentication processes can be used, such as using smart cards, biometrics, or conventional passwords.

The embodiments disclosed herein disclose innovations that can be used to provide support for the security and other aspects of OpenID in a UE context. For example, one of the embodiments discloses a mobile device that has a secure environment as a removable module or as an integrated module, such as a UICC, a smart card, or an integrated trusted environment (TrE). The OpenID used here is used as an example agreement, where newly disclosed functions such as Trusted Ticket Server (TTS), TTverifier, and TCTicket (TC Ticket) can be hosted by the secure environment in the UE, and can be individually or Together, it makes the UE more secure and reliable. In addition, when the UE executes the user identification client function in accordance with the OpenID protocol, by using these disclosed methods, this enhanced security and reliability can be verified externally. .

3.6 3GPP SA3 and its work on OpenID 3GPP SA3 is a 3GPP security standardization working group. In 3GPP SA3, a comprehensive approach is adopted in the extensive security of 2G, 3G and next-generation mobile phones, terminals and systems. . Currently, in the IdM space, there is a technical report (TR 33.924) on the integration of OpenID and the general bootstrapping architecture. In addition, there is another technical report (TR 33.980) on the interoperability between the Liberty Alliance and GBA.

The embodiments disclosed herein disclose innovations that can be used to provide support for the security and other aspects of OpenID and/or the integration of OpenID with GBA or other authentication mechanisms in the context of the UE. For example, one of the embodiments discloses a mobile device that has a secure environment as a removable module or as an integrated module, such as UICC, smart card, or integrated trusted environment (TrE), where the secure environment can be Separately or jointly host some of the disclosed functions, such as the functions of a trusted ticket server or TTverifier on the UE. Compared with the functions currently available for conventional UEs that only support the existing agreements stipulated by 3GPP and implement OpenID or Liberty Alliance interoperability on 3G networks, the disclosed functions can be added individually or jointly to more security and trust evidence.

4 Technical Overview This section provides a technical overview of the implementation of the Identity Management (IdM) solution. For example, these implementations can be used to place OpenID provider (OP) server functions in mobile native platforms, especially smart cards.

In Section 4.1, we provide an introduction to OpenID.

Section 4.2 discusses the implementation of OpenID on the smart card and its architecture, implementation options, variants, and 3GPP GBA integration (generic bootstrapping architecture).

Section 4.3 discusses an implementation that envisages an OpenID provider (OP) to implement platform options. In addition, Section 4.3 also discusses the implementation of JavaCardTM-compliant smart cards and the implementation of OP on the Smart Card Web Server (SCWS).

Section 4.4 discusses the implementation of handling local user authentication. Local user authentication is a topic involving OpenID and other SSO technologies. In addition, Section 4.4 also discusses the implementation of using biometrics.

Section 4.5 discusses the implementation of the "trust" and "trust relationship" methods that can be developed in the context of OpenID. For example, several implementations that disclose the role of the MNO are described here, and in addition, the trust relationship that the MNO may have with other entities/actors in the OpenID agreement is discussed in detail. In an example embodiment, the MNO is exactly the same as the primary identity provider (IdP), and the OP on the smart card is a proxy for the MNO (acting as an IDP). In the second exemplary embodiment, the MNO does not own or manage the OP on the smart card, and the MNO is not an IdP, but a third-party IdP owns and manages the OP on the smart card.

Section 4.6 discusses the implementation that allows OP to be implemented on platforms other than smart cards. For example, some implementations disclose the feasibility of implementation on JavaCardTM and embedded secure components. In addition, some implementations describe how the concept of platform trust (as in trusted computing) can be integrated with the concept of action OP, so as to provide a higher level of trust and security for action OP.

4.1 Introduction to OpenID OpenID allows users to use a single OP to log in to different relying party sites. OP is the central storage location for user identification and serves as a single verification point for the user. Since the user is authenticated against his OP, the OP can issue an assertion to a relying party (RP), which in turn allows the user to access the service. For convenience, OP is also allowed to store personal information that can be compared with user profiles. Then, after the registration process, this information can be exchanged between the OP and the RP to provide the RP with more detailed information about the user.

Figure 3 shows the OpenID protocol process that allows users to use a single OP to log in to different relying party sites. As shown in Figure 3, the user attempts to perform OpenID login, and this will cause the RP to start the process of discovering the OpenID URI. An optional security association that establishes a shared secret can be created between RP and OP. When the process is found to be completed, the RP will redirect the user to the OP that is trying to authenticate the user. OP provides the user with a login web page, in which, once the appropriate certificate is entered, the user is authenticated. Once the authentication is successful, the user is redirected to the RP, and the login for the web service is displayed to the user there.

4.2 OpenID on the smart card In the OpenID protocol, OP can be a repository for user certificates and other user personal information. Therefore, since the theft of the user certificate used to authenticate the OP can allow an attacker to access all OpenID-enabled sites in the name of the user, in the OpenID protocol, the OP becomes the target of most attacks. In a more moderate attack scenario, for example, the attacker will use the browser of the logged-in user after the user has verified his OP, such as performing covert operations on behalf of the user. In this type of attack scenario, The attacker did not obtain the user certificate, so these certificates cannot be used to log in to any site. However, the OpenID protocol design allows an attacker to log in to all RP sites that the user logged in in the previous browser session. The attacker does not have to access the user's machine, such as through malware or MITM. This attack can be executed by any site (the site does not have to be an RP site) by using the XSRF attack to use the hidden framework in the site. If an attacker can inject malware or act as a MITM, the entire login process may be captured and then replayed in a separate browser session when needed. In addition, if the user decides (on the OP) to allow subsequent logins without having to provide his certificate to the OP again (for example, if the OP stores a permanent cookie in the users browser) and the site uses the OpenID protocol " "Request immediate verification" option, then the user may be logged in by the attacker without notice. Therefore, OP security is a major issue for the OpenID implementation.

OpenID itself allows users to install their own OP on websites such as blogs they own. However, the user is unlikely to own the host. Therefore, users believe that their host provider is operating correctly and protecting their private data in an appropriate manner. Although a customized OP with a user-specific design can hinder phishing attacks, since the attacks are no longer carried out in a simple and automatic manner, all those who use the OPs implementation and the users browser and OPs interface Weakness attacks (MITM, malware, etc.) are still possible.

In an example embodiment, the functionality of an SSO provider such as OP may be brought to UE controlled and/or owned by the user. For example, by performing this process, it is possible to provide a centralized environment to manage user identification, while providing the benefits of seamless and easy authentication provided by the OpenID protocol. If users can have their own OP on the security device they control, then certain attacks will be more difficult to carry out in a conventional way. The device for storing and executing OP for the user may be a trusted computing environment carried by the user in his mobile device, such as a smart card. Most smart cards (such as UICC, Java Card, etc.) can perform enhanced functions and can interact with users.

By running OP on the smart card that belongs to the user, it allows the user to maintain more control over their private data. For some solutions, for example, when the RP charges fees for its services, it will be useful if the trustworthiness information of the OP based on the smart card is transmitted from the MNO to the RP. This may include reverse channels that allow the RP to charge users through the MNO. The user can use the local channel to authenticate to the OP, for example via a PIN code. The OP can be installed remotely by the MNO, and the necessary certificates for the OP can be brought to the smart card via the GBA protocol.

Figure 4 shows an example implementation of an agreement process for SSO agreement to provide an integrated OP on a trusted computing environment. For example, by using this protocol process, OpenID can be provided with an integrated OP on a smart card.

As shown in Figure 4, at 201, the user can use a user interface proxy such as a web browser to access the RP, and can choose to log in using OpenID. At 202, the RP may redirect the user interface agent to a local OP that may be included in a trusted computing environment such as a smart card, UICC, Java card, etc. At 203, the user can verify to the OP on the trusted computing environment through a PIN code, biometric identification, etc. locally. At 204, the OP within the trusted computing environment may generate a verification response. At 205, the OP may redirect the user interface proxy to the RP, and may include an assertion that the user has verified. At 206, the user interface agent can be redirected to the RP, and after the RP verifies the assertion from the OP, the user can log in.

The RP may have to use, for example, public Internet communication to establish a connection with the web service entity provided by the MNO (if the OP is provided by the MNO). For example, this processing may be performed when the RP cannot directly communicate with the OP on the trusted computing environment. The MNO may have a remote management interface that forms an interface with the trusted computing environment and an additional communication channel, such as SMS, which allows the MNO to communicate with the device and/or the trusted computing environment. The MNO can act as a negotiation bridge between the RP and the OP on the trusted computing environment.

Figure 5 shows an example implementation of the protocol process for providing OpenID with an integrated OP on a smart card.

As shown in Figure 5, at 207, the user can access the RP and choose to log in using OpenID. At 208, the service can redirect the user (user browser) to its local OP. For example, the user can use the PIN code locally and use the smart card interface and/or biometric identification to authenticate to the OP. At 210, the OP can generate a verification response. At 211, the OP may redirect the browser to the RP and may include an assertion that the user has been verified. At 212, the browser can be redirected to the RP, and after the RP verifies the assertion from the OP, the user can log in.

The RP may have to use, for example, public Internet communication to establish a connection with the web service entity provided by the MNO (if the OP is provided by the MNO). For example, this processing may be performed when the RP cannot directly communicate with the OP on the smart card. The MNO may have a remote management interface that forms an interface to the smart card and an additional communication channel, such as SMS, which allows the MNO to communicate with the device and/or the smart card. The MNO can act as a negotiation bridge between the RP and the OP on the smart card.

4.2.1 Architecture and Preferences 4.2.1.1 RP OP Communication Requirements In an example embodiment, in order for the RP to obtain an assertion from the OP running on a trusted computing environment such as a smart card, the RP must communicate with the OP. The RP can send the user identification to the OP, and then the OP can notify the RP of the verification result after verification.

The OpenID protocol uses two different types of communication in the protocol process. Indirect communication is performed by HTTP redirection or HTML format submission. In the sense that the communication passes through the user's browser, the communication is indirect. Indirect communication is used to verify the request (from the RP to the OP via the browser) and to verify the response (from the OP to the RP via the browser). Direct communication is performed directly between the RP and the OP, and it is used to directly associate with the OP and verify the assertion.

Since the process of establishing an association (thereby establishing a shared secret) between RP and OP is not mandatory, there are two protocol procedures for OpenID verification.

The implementation described here can be implemented using any protocol process used for OpenID authentication.

4.2.1.1.1 Background of association-based communication Figure 6 shows the OpenID protocol process for association-based communication.

As shown in Figure 6, in the OpenID protocol, the association between OP and RP does not depend on the pre-shared secret between OP and RP. It is the initial step performed by the RP after the user provides its OpenID identifier to the RP and wants to log in to the RP with OpenID. At 215, the RP connects to the OP (via HTTPS) and establishes a (short-term one-by-one authentication session) shared secret k with the OP by performing a Diffie-Hellmann key exchange. Then, at 230, the RP later uses the shared secret to verify the signature of the assertion message that originally originated from the OP but was received by the RP from the user's browser via indirect communication (browser redirection).

At 220, if an association is established between RP and OP (and thus a common secret k is established), then the association control is passed in the verification request and response (via indirect communication). At 225, the verification response from the OP contains the signature of the association control and the assertion using the shared secret k. The RP can then use k to automatically verify the signature. Through the use of association control, it is possible to allow OP and RP to track multiple simultaneous sessions.

4.2.1.1.2 Background of stateless signature verification Figure 7 shows the OpenID protocol process for stateless signature verification.

As shown in Figure 7, if no association is established between the RP and the OP, then at 240, the RP must verify the signature in the verification response received at 235 in the direct message to the OP. At 245, if the assertion is valid and is indeed issued by the OP, then the OP must issue to the RP a statement containing the "is_valid" field set to "yes".

Although the authentication request and response are redirected by HTTP and passed through the user's browser, and therefore there is no need to have any direct communication channel between the RP and the OP in any scheme, there must be a way for the RP to verify and receive The signature on the assertion reached. If the initial agreement must remain compliant, then the RP must be able to contact the OP at least once after receiving the assertion for signature verification. Then there will no longer be a need to establish an association.

4.2.1.2 Implementation of the discovery of OP on the local device for verification When the OpenID protocol is used, the RP does not necessarily need to discover the OP when performing indirect communication.

In an example embodiment, the browser used to access the RP will be redirected to the local OP on the smart card. Since the channel between the browser and the RP is used, the RP does not even need to know the address of the OP. However, this redirection may require pointing the browser to an address. This address can be given as the local IP address of the device (similar to 127.0.0.1 indicating the local host), and the browser will recognize this address and then participate in local authentication.

In another embodiment, a special identifier converted by the browser for the purpose of redirecting to the local OP and continuing user authentication can be used. For example, such an identifier can take the form of sc://openid/identifier, and this will inform the browser to participate in a verification session about the identifier with the OP on the smart card. The verification request can be transformed using a correct communication format so as to be used in a trusted computing environment such as a smart card. Then, in accordance with the UICC capabilities, authentication can be performed between the user and the UICC through an appropriate interface. For example, verification can be performed using a PIN code, biometric verification, and so on. The verification may indicate that the user has approved the verification in other ways. For example, if an attacker or an unauthorized user uses a smart card for authentication without knowing the user, then by executing this process, it is possible to prevent an attack that may occur in this case.

By coupling the authentication with the user interaction, the user can know the ongoing transaction. According to the capabilities of the smart card, it may be better to display the actual transaction details, that is, which site acts as the RP, the return URL on the RP, and which identifier will be used. If the OP on the smart card supports multiple OpenID identifiers, the OP can even present the user with an optional identifier that can be used in conjunction with the RP. After performing a local verification against the OP (for example, using a PIN code), the browser is redirected to the RP, which contains a positive assertion from the OP.

In an example embodiment, the assertion may be verified by the RP, thereby requiring a direct communication between the RP and the OP, where the direct communication is via association or via the direct signature verification described in the previous section. The method used for assertion verification is implementation specific and is further described in section 4.2.2.1 below.

4.2.1.3 Implementation of identification for MNO assertion In an example implementation, a local OP on a trusted computing environment such as a smart card is used for local user authentication. The MNO may be an entity that provides necessary assertions to the RP after receiving the trigger message from the local OP on the smart card, thereby declaring that the user has been successfully authenticated. This implementation is further described in Section 4.2.2.1.2 Separating OP Scheme.

4.2.2 Implementation options and implementation variants This section discusses implementation options and variants of the implementation that can be combined with the more general concepts disclosed herein.

4.2.2.1 Implementation of RP-OP communication for assertion verification 4.2.2.1.1 Implementation for integration of BONDI In an example implementation, the direct communication channel between RP and OP can at least be used to verify assertion signatures . For example, the direct channel can be provided by tunneling traffic between the OP and the RP via the user's browser. This concept may require the browser to perform additional redirects within the current session.

In another embodiment, the browser can act as a single point of contact for the RP in order to implement a second process that can be used to establish a communication channel between the RP and the OP. Since the specified communication protocol between RP and OP is HTTP or HTTPS, the browser can transmit all traffic.

In order to facilitate the communication between the browser and the trusted computing environment such as the smart card, the OMTP BONDI API can be used. The BONDI API can allow the browser to use JavaScript to communicate with the smart card, and then communicate with the OP. By using BONDI, redirection can even be reduced. The RP contains the appropriate JavaScript call in the webpage it sends to the browser. The JavaScript call invokes the BONDI API and can allow access to the smart card. Then, the call result can be wrapped in the same JavaScript in the response message sent to the RP (for example, in the HTTP POST message). According to the time when the RP uses the BONDI call, the RP can establish the association when the RP uses the verification request to redirect the smart card call in the page, or it can also use the page displayed after the RP receives the OP assertion, thereby allowing the RP Ability to perform direct verification without being associated.

Figure 8 shows an example implementation of integrating BONDI with OpenID based on the association. As shown in Figure 8, at 245, an association is established between OP and RP by using BONDI. BONDI may allow the browser to communicate with a trusted computing environment such as a smart card and/or an OP that may be inside the trusted computing environment. At 250, a verification request from the RP is received on the OP. At 255, the verification response is communicated back to the RP.

Figure 9 shows an example implementation that integrates BONDI with stateless (not associated) signature verification. As shown in Figure 9, at 260, OP and RP communicate via BONDI and the browser. At 265, the RP transmits a verification request to the OP. At 270, the OP sends a verification response to the RP.

4.2.2.1.2 Implementation of Split OP In an example implementation, the RP can verify the received assertion by using the split OP. In separating the OP, the function of the OP can be separated between the MNO and the local OP. Although the local OP can be responsible for implementing user authentication, the MNO can verify the signature from the smart card OP by communicating with the RP. This processing can be performed in conjunction with the association established between the RP and the MNO, or through stateless signature verification.

Figure 10 shows an example implementation of enabling separate OP. As shown in Figure 10, at 275, an association can be established between the RP and the MNO. The RP can establish a shared secret with the MNO, and then the OP can use the shared secret in the signature process of the assertion message. If the RP has multiple simultaneous connections with different users, the assertion message may contain association control so that the RP can identify the correct shared secret. This shared secret may allow the RP to verify the assertion signature without having to communicate with the OP. This association may be performed before performing the first redirection of the UE browser from the RP.

At 280, the OP may transmit a verification request to the RP. At 285, the RP may send a verification response to the OP. At 290, the OP may establish an associated control and signature key with the MNO. The association control and signature key can be established using GBA.

If no association is established between the RP and the MNO, then the RP may still need to be able to verify the received signature by contacting the entity on the MNO. The entity may need to issue a statement about the validity of the signature. In an example embodiment, one option is to check whether the OP actually belongs to the OP issued by the MNO. This check may require the OP to include a unique identifier in the verification assertion message sent to the RP, and then the RP will forward the message to the MNO. OP address (IMEI/IMSI) can even be used as the identifier. If the OP is registered with the MNO as a valid OP, the MNO will return a message with the "is_valid" field set to "Yes" to the RP, so that the RP can accept the assertion message (assertion verification). The split OP scheme allows the MNO to maintain its control of OpenID processing in a way that offloads all verification burdens to the local OP on the smart card, while the MNO can still reply by using the "is_valid" set to "No", thereby Choose to revoke the logo. Signature verification can be performed as the last step in the agreement before the user logs in to the RP.

Figure 11 shows an example of a stateless (unlinked) implementation with separate OP enabled. At 295, an assertion verification can be performed between the MNO and the RP. At 300, the RP may transmit a verification request to the OP. At 305, the OP may send a verification response to the RP. At 310, an associated control and signature key can be established between the OP and the MNO. The association control and signature key can be established using GBA.

In another example embodiment, in order to enable the MNO to communicate with the OP on the smart card, it is also studied whether a standard OTA management process using encrypted SMS as a bearer can be used. The commands contained in the SMS can be decrypted by the SIM card, and can be run in the manner defined in 3GPP TS 11.11.

In another example embodiment, the Bearer Independent Protocol (BIP) may be used in combination with the Card Application Toolkit Transmission Protocol (CAT_TP). BIP allows to open data channels from mobile phones to OTA servers and (U)SIM cards, thereby generating end-to-end data channels. The size of an SMS is 140 bytes. In contrast, the data packet used for BIP contains 1472 bytes. BIP can use the UE's GPRS connection to implement a faster connection. BIP is standardized in 3GPP TS 31.111, and CAT TP is standardized in ETSI TS 102 124.

4.2.2.2 Implementation of using 3GPP GBA for OP on smart card In an example implementation, GBA can be used to introduce the UICC/H(e)NB-based OP described in this application. For example, GBA agreements can be used and established by many MNOs.

4.2.2.2.1 Introduction to GBA The 3GPP GBA protocol specification (3GPP TS 33.220) is a way to implement the user by using the users valid identity on the home location register (HLR) or home user server (HSS) Proven technology. The GBA architecture is performed by allowing the network element to query the SIM card in the UE and verify the similarity of the answer to the answer predicted by the HLR/HSS. GBA stands for a common key verification method.

The Bootstrap Server Function (BSF) is an MNO network entity, which acts as an intermediary between two endpoints and enables the two endpoints to establish a shared secret (its lifespan may be limited).

The following diagram is included as a reference and gives an overview of the GBA architecture and its components.

Figure 12 shows the BSF function used in the GBA architecture.

Figure 13 shows an overview of the GBA architecture.

Figure 14 shows the GBA reference module from 3GPP TS 33.220.

Figure 15 shows the GBA reference module of the accessed network from 3GPP TS 33.220.

4.2.2.2.2 Existing technology integrating GBA and SSO By using GBA, 3GPP authentication and key agreement processing can be used to generate application-specific certificates in the SSO context. An example of this application is given in 3GPP TR 33.980, which describes the interworking scheme between GBA and the Liberty Alliance SSO protocol. Another example is given in 3GPP TR 33.924, which describes the interworking scheme between GBA and OpenID protocols. The 3GPP TR uses the GBA key to perform user authentication between the NAF/OP at the same location as the identity provider and the UICC of the UE/user. In the remainder of this section, for example, we will focus on the interoperability between GBA and OpenID.

The UE uses the BSF of the MNO HSS on the Ub interface to create these application layer certificates. Then, these certificates are shared with OP/NAF via the Zn interface. Afterwards, the UE client can use these certificates to communicate directly with the service provider.

Figure 16 shows the architecture scheme for Liberty/GBA shown in "A Web Services Shopping Mall for Mobile Users" written by my MacDonald et al. As shown in Figure 16, GBA can be integrated with the Liberty Alliance protocol to provide shopping malls that implement Liberty IdP. Through this free IdP, shopping malls can provide users with identifiers that can be used in shopping services. The IdP uses the GBA protocol as the verification mechanism.

Figure 16 shows the following steps: 315 Once registered, the user agent of (UE) executes GBA U with (BSF) on Ub.

320 Provide Ub parameters for the user agent applet inside UICC.

325 The UICC component of the user agent calculates Ks and provides a service layer certificate (Ks(int/ext) NAF) for the UE. The Ks is always kept in the UICC.

330 The user agent contacts (NAF/IdP) to obtain the "Shopping Mall" logo.

335 Pass the service certificate suitable for the user agent to (NAF/IdP) via Zn.

340 Provide the authentication token for the "shopping mall" from (NAF/IdP) to the user agent).

345. The (UE) uses the service certificate to communicate with the (SP) and request services.

350. (SP) Confirm the validity of the (UE) service certificate.

4.2.2.2.3 Implementation using GBA and OpenID In an example implementation, by using GBA, a shared secret can be established between UICC and NAF. NAF can be in the same location as other services (such as IdP) and does not have to be outside the MNO network. NAF can request connection from BSF (inside the MNO network). For example, the connection between the UICC inside the UE and the NAF can be through HTTP or SOAP over HTTPS. In other embodiments discussed further below, for a UICC-based OP that can be used for communication between the OP and the MNO, the OP can use the GBA protocol.

4.2.2.2.3.1 The MNO as the (direct) trusted supplier of the OP In an example embodiment, in the sense that the MNO can be used to establish trust between the RP and the OP, the MNO can be directly included in the RP-OP communication middle.

The following embodiments can be combined with the embodiments previously described in Section 4.5.2.2.1.

Implementation for direct connection between RP and MNO Figure 17 shows an example implementation of using GBA for MMO support logo declaration.

As shown in Figure 17, at 370, the RP can connect to the MNO's network entity in order to establish an association. The MNO entity can act as a UICC-based OP assertion support; this entity can be called OPsup. OPsup can have an integrated NAF function, and can act as an entity inside (but reachable) or outside (but can be operated or authenticated by the MNO) network of the MNO. At 365, the OP on OPsup and UICC can perform the necessary bootstrapping process in order to use GAA/GBA to establish a shared secret. At 355, the user's browser can be redirected from the RP to the local OP. At 360, communication can take place between the browser and the OP.

The user can verify with the local (UICC) OP. After performing local verification at 360 (for example, using a PIN), at 365, the OP can send a message containing the session identifier to OPsup (or the additional temporary usage (nonce) passed by the RP in the initial redirection), where the The session identifier is signed with the RP-specific key Ks_NAF_RP obtained from Ks_NAF. Alternatively, the session-specific key may be used for signing. At 370, if a secure connection has been established between OPsup and the RP, since the established channel has provided the authenticity of the source and provided integrity protection for the message, OPsup can forward the message to the RP. However, OPsup can use a public key to sign messages to provide integrity protection and authenticity regardless of the communication channel. The RP may be equipped with a RP private key Ks_NAF_RP obtained from Ks_NAF to verify the OP signature. Alternatively, the key may be a session private key. Then, Ks_NAF_RP can be passed to the RP via OPsup. In another embodiment, KS_NAF can be directly used to create and verify signatures.

Implementation of indirect communication via OP In an example implementation, by using indirect communication, the temporary usage can be transferred from the RP to the OP, and then the OP will forward it to the MNO. The MNO signs the temporary usage, where the temporary usage can be included in the assertion that is transmitted back from the OP to the RP after the local verification succeeds. Since the MNO has signed the temporary usage, it can provide the RP with a guarantee that the OP is running on the UICC issued by the MNO.

Implementation for the combined method In an example implementation, a shared secret established between the RP and the MNO via direct communication (eg, HTTPS connection) may be used. Then, at the end of the verification, the RP may expect the OP to include the secret in the assertion message.

In another example embodiment, GBA can be used. Since the GBA protocol does not allow any shared secrets (such as RP secrets) to be established between NAF and UICC, indirect means (such as OPsup entities in the same place) can be used here. RP sends the session identifier to OPsup, OPsup can use GBA to establish a shared secret with UICC. Then, OPsup uses the same secret as the secret established by the UICC (therefore combined with the OP on the UICC) to sign the session identifier, and can send the signed session identifier back to the RP. The RP can keep this signed session identifier as a reference. The RP includes the session identifier in the redirect message, thereby allowing the OP to use the GBA secret to sign it. The OP can then include the signed session identifier in the assertion message sent to the RP. After that, the RP can compare the signed message from the OP with that from OPsup. If the two match, the RP proves that the OP belongs to the user of OPsup's MNO. This embodiment may represent a closed-loop process, where signature matching strengthens the message protection process and establishes OpenID verification.

4.2.2.2.3.2 The implementation of using GBA when the OP function is separated between the MNO and the OP (separate OP) on the smart card Figure 18 shows an example implementation that allows the separation of the OP. As shown in Figure 18, at 375, an association can be established between the RP and the MNO. The RP can establish a shared secret with the MNO, and then the IP can use the shared secret in the signature process of the assertion message. If the RP has multiple simultaneous connections with different users, the assertion message may also need to include association control so that the RP can identify the correct shared secret. This shared secret may allow the RP to verify the statement signature without having to communicate with the OP. This association can be done before redirecting the UE browser from the RP for the first time.

At 380, the OP may transmit a verification request to the RP. At 385, the RP sends a verification response to the OP. At 390, the OP may establish an associated control and signing key with the MNO. The associated control and signature key can be established using GBA.

In an example embodiment, the function of the OP may be divided between the MNO and the local OP. If the association between the RP and the MNO is used, then the RP can establish a shared secret with the MNO, and then the OP can use this shared secret in the signature process of the assertion message. If the RP has multiple simultaneous connections with different users, the assertion message may also need to include association control so that the RP can identify the correct shared secret. The shared secret may allow the RP to verify the statement signature without having to communicate with the OP. If it is assumed that GBA is performed, the shared key between MNO and RP can be passed to OP protected by Ks_NAF. Thus, the OP can sign the assertion message using the shared key established with the aid of the association.

The RP can establish an association with the MNO, and then the MNO executes a GBA process that generates a shared secret between the MNO and the OP. MNO can implement NAF function on servers reachable by RP. The NAF can establish a shared secret with the OP on the UICC, and the RP receives the shared secret from the NAF. Association control (known to NAF and RP) can also be sent from the MNO point of contact (NAF) to the OP. The OP can then use the GBA shared secret containing the association control to sign the assertion sent to the RP. Since the RP has already received the same common key from the NAF by means of the associated link, the RP can verify the OP signature. By using association control, OP and RP can be allowed to handle multiple (simultaneous) sessions.

4.2.2.2.3.3 Example of using GBA in mobile OpenID in a separate terminal In an example embodiment, GBA can be used in a separate terminal configuration where a browser and OP/UICC combination resides on a separate device. It can be assumed that the configuration used is a separate terminal type, but the OP is an entity local to the user, and as mentioned earlier, the user performs authentication with the OP locally.

Figure 19 shows an example implementation of enabling separate terminal/local OpenId. As shown in Figure 19, for example, the process of ensuring the security of the channel between two devices can be completed using a Bluetooth secure link, or it can be used to establish a shared key Ks_local_device described in TS 33.259 (Ks_local_device) process and so on to complete. The key can be calculated inside the UICC and can be passed to the browser via a secure tunnel. The establishment of shared secrets can be supported by GBA. The shared key can be obtained from the key Ks_(ext/int)_NAF generated by GBA.

In an example embodiment, when 33.259 is used, HTTPS with certificate-based mutual authentication can be used to establish a secure tunnel for connecting NAF and a remote device. For example, the browser can be PC-based, and the tunnel works in an Internet/TCP connection environment. The security of the tunnel can be reinforced with the help of a trust mechanism. According to the requirements in the Mobile Phone Specification (MPWG), it can be assumed here that the remote device containing the browser is TCG compatible. Through the TPM evidence in the device, the HTTPS tunnel can be established to be bound to the trust status of the browser device. Therefore, the integrity check embedded in this protocol will bind the Ks_local_device to the platform.

In another example embodiment, as part of the process, the remote device storing the user's browser may request the UICC host device to send the NAF_ID list to it. MiTM can easily generate this request and receive the requested ID. For the processing of the protection tunnel, the combination of its certificate and mutual authentication with the assumed proper trust characteristics will ensure that MiTM attacks will not occur within the separate terminal configuration, or if such an attack occurs, the attack can also be detected of. Once this setting is completed, the Ks_local_service key can be safely sent to the remote device via the tunnel; then, the remote device (browser) can send a key generation request message (integrity protected), In order to initiate the calculation of Ks_local_service on the UICC host device.

The identification assertion protocol used to separate terminal type configuration is described here. It can be assumed here that GBA has been implemented, and the process of establishing a shared key Ks_local_service between the remote platform (browser-PC) and the device containing UICC/OP (UE) has been implemented. As shown in Figure 19, the channels identified at 405 (connecting UE and NAF/OPsup) and 400 (connecting UE and PC) can be secure. In another example embodiment, the MNO can be used to provide support for the identification assertion of the UICC-based OP application here.

In another example embodiment: · The user uses the OpenID login format to provide his OP identifier (URL) to the RP (at 395) · The user is redirected by the RP to his OP-the redirect message includes temporary usage Or session identifier · RP establishes a security association with the MNO (for example, HTTPS connection-at 410) · RP also sends a session identifier to OPsup-the message is protected by the aforementioned security association (at 410) · The user uses the browser to input PIN (or password) for verification. Pass the information from the PC to UICC/OP via 400 in a message, where the message also includes the session identifier obtained from the RP-as mentioned above, the message is protected by Ks_local_device ·OPsup uses the GBA key Ks_(ext/int)_NAF to sign the session identifier and sends it back to the RP, which keeps the signature as a reference (410)·Now, OP also uses the GBA key Ks_( ext/int)_NAF to sign the session identifier sent to it from the browser, and include the signature in the assertion message subsequently sent to the RP (395) · RP compares the two signatures, one of which is from Opsup (410), the other signature comes from OP (395); if the two match, RP concludes that the OP belongs to the user of OPsup's MNO.

4.3 Implementation of an effective protocol for the OP on the smart card web server This section aims to show the advantages provided by the OP on the SCWS, especially the advantages of the implementation that is effectively improved and further described in this application. For example, the proposed implementation may be an implementation that implements the OpenID protocol. One of the advantages of these implementations is to verify that the traffic is local, and in addition to the air interface network or network service required by the existing HTTP message flow, the The business volume will not burden other air interface networks or network services. The discovery and correlation business volume does not go through the air interface network, and is carried out on the public Internet of the fixed line between the operator OP and RP.

4.3.1 Standard OpenID Figure 20 shows the standard OpenID protocol. For this protocol, local traffic does not exist, and the traffic offloaded from the air network is only the discovery process and the process of establishing an association between the RP and the OP. Since OP is a web service, all communication between the user/browser/device and OP will be carried out via the air interface. For example, the signals 420, 435, 440, 445, 450, 455, 460, and 465 appear through the air communication process performed as data traffic (eg HTTP, IP-based communication) and via the MNO/air network. This represents a burden on the MNO network. In addition, the signals 425 and 430 are traffic that appears on the fixed-line Internet, and can use the existing infrastructure.

4.3.2 OpenID/GBA Figure 21 shows the business process of OpenID/GBA from 3GPP TR 33.924 v9.1.0. Regarding the definition of the protocol, no matter what the associated steps are between the RP and the MNO, all communication is carried out over the air network. However, due to the need for verification 472 and 474, which will increase the burden on the air data network and the back-end services required for GBA verification, namely the BSF and NAF subsystems. Therefore, compared with the web-based OP, The business volume in OpenID/GBA will even increase. Therefore, here we will see an increase in air network traffic and an increase in the burden on network entities.

4.3.3 Implementation for improving the agreement Figure 22 shows an example implementation of the agreement process for reducing air traffic. For example, the valid protocol can be used for OpenID on SCWS. In this embodiment, it is assumed that there is a long-term shared key between the OP and the MNO associated with the SCWS.

As shown in Figure 22, the air transport traffic can be offloaded to local equipment, thereby reducing the air interface network traffic. For example, by performing this processing, the verification traffic can be allowed to be local, so that the verification traffic minimizes the burden of the air interface network or the network service. In addition, discovery and/or associated traffic does not necessarily occur via air interface networks, and can occur on fixed-line public Internet.

At 480, the user can interface with a user interface such as a browser, and can access the RP, and use OpenID to request login. At 485, RP and OP (MNO) can perform discovery to discover the OP server based on the OpenID identification. At 490, the RP may transmit an association request to the OP. OP can generate a random unique association control A, and can calculate the key S. The OP can send an association response to the RP. The association response may include association control A and key S. The RP can store the key S and the associated control A.

At 495, the RP may transmit a redirect to the browser. The redirection can redirect the browser to the OP, and the associated control A can be included in the request parameters. OP can be linked to SCWS. The browser can receive the redirection and can map to SCWS by performing a modified local DNS lookup. At 500, the browser may transmit a local verification request to the OP. At 505, verification can be done locally. For example, at 510, the OP can verify the certificate based on the long-term shared key K and the associated control A. In addition, the OP can also calculate the key S, and can use the key S to calculate the signature. The signature can be used to sign the assertion message, and/or to sign parameters such as return_to URL, identification, and/or mode.

At 515, the OP can transmit a redirect to the browser that can redirect the browser to the RP. The redirection may include the associated control A and the parameters with the signature. At 520, the browser may send a request to the RP, which may include a signed assertion message from the OP. The RP can use the key S to verify the signature on the assertion message. Then, at 525, the RP may allow the browser to display the login page and may provide service access to the browser.

4.4 The implementation method for implementing OP on the smart card web server has available and standardized methods for user equipment (UE) to communicate with the SIM card. For example, the 3GPP TS 11.14 specification defines the methods that can be used by the SIM application. The SIM Application Toolbox (SAT) interface does not define how to use commands in a unified way on different SIM card types from different SIM manufacturers. In an example embodiment, by using the SIM application toolkit, the SIM card can obtain temporary control of the UE (take action in advance). Compared with the situation where the UE sends a request to the SIM card and the SIM card responds, the UE can obtain the SAT command from the SIM. The SIM card issues the SAT command to the UE; regardless of whether the command is executed successfully, the UE will respond accordingly and send a response back to the SIM.

4.4.1 The OP Smart Card Web Server (SCWS) on the smart card web server is a web server running on the USIM card, and its behavior is similar to that of a traditional web server. It can be seen as an advancement of the SIM toolbox, and in the current application scheme for displaying the phone book, it can be seen as an additional MNO service via the HTML interface using the native UE browser and so on. SCWS uses a standard HTTP protocol to deliver its content to the browser, but unlike traditional web servers, SCWS can use two different bearers: BIP (on top of the T=0 smart card protocol) or USB interface The complete TCP/IP stack (implemented on the card).

The UE is responsible for routing the traffic from and to the SCWS USIM, thereby acting as a gateway to connect the (U)SIM to the MNO and the Internet. If BIP is used, the router in the ME will redirect some HTTP requests from the UE browser to the local SCWS. The HTTP request on the defined TCP port will be sent to SCWS on the (U)SIM, and the HTML page in the response is generated by SCWS. HTTP requests that do not use the TCP port dedicated to BIP are directed to a server on the Internet. If the USB protocol is used in combination with a complete TCP/IP stack on the (U)SIM, the UE has the same IP gateway function as other computers that connect the intranet to the Internet. The ME gateway also depends on the IP protocol version used, namely IPv4 or IPv6. Compared with BIP, the complete TCP/IP stack also provides the possibility to route requests from (U)SIM to the Internet.

Figure 23 shows an example implementation of internal routing for OP on SCWS. As shown in Figure 23, SCWS can be used as the basis of OP, and the routing capabilities of the UE can be modified to react on designated external ports and forward communications to the OP on SCWS. For example, by performing this process, it is possible to create direct communication without having a tunnel through a browser. These traffic may still pass through the same device, but may be redirected in different ways.

The routing function (RF) in the UE can enable multiple communication paths. When the user accesses the RP site using a browser for the first time, the RF can redirect the request to the RP via the available outbound TCP/IP interface (such as 3G network connectivity). Now, since a public session is established on this connection, the RP knows the IP address of the browser. The RP can use the same address as in the user/browser session to get in touch with the OP. The RP can use another (predefined) port on the device, which is different from the port in the HTTP session with the browser. RF sees this port as the port that should be routed to the OP on the SCWS. The RF can directly redirect the message to the OP, and the OP can allow the RP to establish an association with the OP. The RP may also issue a redirect to the browser in order to perform OpenID verification. The browser can be redirected to the OP on SCWS. RF can treat the call from the browser as a call that can be routed to the local SCWS. The OP can perform local user authentication (this processing can be done via a secure UI, or SCWS can be provided as part of the UICC capability to control the device, which usually requires the user to provide a PIN code).

After verification, the OP can use a positive assertion to redirect the browser to the RP. Since RP and OP may have established an association, RP can independently verify the assertion. If the association cannot be created, then OpenID's direct verification scheme can also be implemented. In this case, the RP can contact the UE at the predetermined port after receiving the positive assertion, the RF will route the request to the OP, and the OP can respond to the verification request.

In an example embodiment, access to the OP may be restricted on the local device. For example, only local browsers can be allowed to obtain assertions about the identity. Doing so prevents attackers from retrieving identification assertions from external devices. RF can also couple the routing of inbound traffic to OP with previous browser requests. For example, for a single RP communicating with a browser, routing may be active for a limited time.

MNO can also use RF to perform management tasks on SCWS and OP respectively.

4.4.1.1.1 General requirements The following are the general requirements stated in the OpenID specification: (R-1) In OpenID, RP can decide to work in a stateless or association-based communication mode. Since assumptions cannot be made on the RP, both of these options need to be supported by the OP implementation.

(R-2) In the stateless mode, no shared secret is established between the OP and the RP. After the RP receives the assertion message from the OP via the browser, the RP will directly contact the OP. Then, the RP will establish a direct HTTP(S) connection with the OP to request the OP to verify the signature on the assertion message.

The OpenID specification allows two different types of (symmetric) signature schemes: HMAC-SHA1-160-bit key length and HMAC-SHA256-256-bit key length. If the RP uses the association, then the symmetric key can be exchanged between the OP and the RP during the association establishment process. The secret exchange is protected in the following way: use Diffie-Hellman key exchange protection, and then use DH-key-value to encrypt the shared secret, or if Diffie-Hellman is not used, the connection must be protected by transport layer security measures. Eavesdropped by an eavesdropper. All the signatures issued by the OP on the assertion message are symmetric signatures using one of the mentioned algorithms. Smart card terms such as Global Platform use the term password or the more common "Data Authentication Mode (DAP)" to describe this cryptographic signature scheme.

(R-3) In association-based OpenID, RP and OP establish a shared secret identified by association control. The RP includes this association control in the initial redirect message, which redirects the browser to the OP. The OP can then use association control to discover the RP's shared secret, and then use that secret to sign the assertion message. Once this message is received, the RP can automatically verify the received signature.

(R-4) The communication options described in (R-1), (R-2), (R-3) all require at least one direct connection from the RP to the entity E1 that can be reached via the public Internet, where For normal OpenID, E1 is the OP server.

(R-5) The entity E1 from (R-4) must be able to establish a shared secret between the OP server and the RP in an association-based mode. In the stateless mode, the secret must be known by the OP in order to sign the message. In addition, the secret must also be known by the reachable entity E1, and then the RP will verify the OP signature by contacting it.

(R-6) The signature in OpenID is generally based on HMAC-SHA1. The OP and the verifier must be able to use the appropriate algorithm to sign the data and verify the signature.

(R-7) The MNO must provide a network entity E2, which provides OP discovery processing by means of HTML or XRDS discovery in accordance with the OpenID standard. The entity E2 must run on the DNS address that is part of the OpenID identifier, for example, if the identifier is http://openid.mno.com/id, then the MNO must run on http://openid.mno.com The web service E2, that is, the MNO must have the domain and server in order to run as a discovery service. The discovery service is carried out by means of the public Internet and can be featherweight. The entity E2 can co-exist with the entity E1 from (R-4) in a common physical entity that provides these two functions. In addition, E2 can be separated from E1, in which case the discovery process provides an entry point for the roaming device option using OpenID.

(R-8) The (DNS) address of E2 from (R-7) should not be changed in order to provide users with consistent identification.

(R-9) OP must be reachable by the user's browser via at least HTTP.

(R-10) The same connection as in (R-9) can use HTTPS instead of HTTP.

Optional (R-11): OP must be able to generate and display HTML pages used as verification pages. Since actual verification is not specified, this process is optional. If the verification page is not used, the OP should at least inform the user that its OpenID identifier has been used, so as not to conceal the use of the logo. However, not displaying the verification page may be beneficial to provide users with a more consistent SSO experience. For example, users only verify the OP on SCWS once a day, and then all subsequent verification processing will be performed automatically.

Optional (R-12): If a verification page is used and the verification page receives data from the user, such as user name and password, then the OP must be able to accept the data, process and verify the data, and Perform the corresponding operation.

Optional (R-13): If a verification page is used, the verification page can use the information received by the RP to display additional information to the user in an easy-to-understand manner, for example, by displaying the RP name and putting it in the text Identifiers that are used, used as a graphic image, or used in a combination of the two methods at the same time.

Optional (R-14): If a verification page is used, the verification page can include a (visual) secret used as an indicator that indicates to the user that the user is communicating with a legitimate OP.

4.4.1.1.2 Implementation of using SCWS in OpenID The previous section discussed the general requirements set by the OpenID standard. In this section, we will describe the implementation for implementing local OP using SCWS within the OpenID requirements described above.

In an example embodiment, the SCWS may not be directly reachable from the public Internet, that is, the RP cannot directly contact the OP on the SCWS. If the requirements (R-1), (R-2), (R-3) are given, then indirect pointing can be used. For example, an MNO can provide a web service that can be reached via the public Internet, and the service can share secrets with OPs associated with SCWS (see the section on separating OPs in this article). In addition, the web service can also share the secret with the RP, so that the secret can be shared between the RP and the OP associated with the SCWS. In another embodiment, the RF can route the request to the OP on the SCWS.

The communication from MNO to SCWS can be carried out via HTTP(S) and via remote management interface, for example via SCWS remote update and associated applet. The communication can also come from mobile browser and via local HTTP(S) ) To proceed. The local connection interface can be used for OpenID communication. In addition, the local connection can also serve as a general HTTP(S) interface for communication with SCWS and OP.

ETSI SCP defines smart card access via TCP/IP (9), and the access can be not limited to local access. For example, restricted access to SCWS from external entities may not be a technical issue; on the contrary, according to the current standard specification for SCWS, it may be a limitation of the routing function inside the device. Direct HTTP access to SCWS can be implemented in future versions of SCWS. Such access may not be administrative access. For example, for OpenID operations, RP can access web pages served by SCWS (dynamic applets that implement OP server logic).

4.4.1.2 Implementations used to handle additional and derived requirements for the implementation of OP-associated-SCWS. When OP is implemented on UICC and OP is associated with SCWS, the following implementations may generate additional requirements: (RSCWS-1 ) In an example embodiment, the MNO must implement an OP Server Function (OPSF) that can generate, share, and distribute secrets for the OpenID protocol with the local OP associated with the SCWS (and optionally with the RP).

The supporting OP function may need to act as a trusted party for negotiation between the RP and the local OP entity on the UE for the shared secret used in the signature on the OpenID. This support function can provide an HTTP(S) interface to enable the RP to initiate an association process (if association is used) or to confirm the signature from the local OP when the RP requests it. Therefore, it can be reached via the public Internet, and the function must also be able to communicate with the local OP in order to exchange secrets. This communication for the local OP may have to be performed at least once on each RP that the user wishes to access. In an example embodiment, the local OP is managed and maintained by the MNO. The MNO can update the shared secret by communicating with the local OP/SCWS, and the OMA SCWS standard can meet the needs. In another example embodiment, the remote OpenID identification service of the non-MNO manages and communicates with the local OP on the smart card. In addition, global platform standards may also be used.

Generally, a new (symmetric) secret can be established for each RP between OP and RP. Since it is difficult to restrict users' access to RPs using OpenID to log in, it is difficult to provide these shared secrets in advance for all RPs that users wish to access in the future. If a secret is generated for each RP in the UICC (for example, derived from the seed value), then the secret can be shared with the RP. For this, please refer to the agreement process in the later chapter, where we will Options for discussion.

(RSCWS-2) In another example embodiment, network entities from (RSCWS-1) and operated by MNOs can use different channels and communication methods to establish secrets in OPs associated with SCWS and distribute them To RP. The communication from MNO to RP is restricted to HTTP-based communication by the OpenID protocol. The communication from the MNO to the OP associated with the SCWS can use secure SMS-PP, or, for example, the communication can be guided by GBA, and/or can use a secure communication protocol, such as HTTP(S) SCWS remote management interface.

(RSCWS-3) In another example embodiment, the local OP associated with the SCWS must have access to the secret shared between the MNO entity from (RSCWS-1) and the smart card. These secrets are not network-specific keys, but only used in the OpenID protocol; if necessary, they can be called and re-established with the help of OTA measures. These secrets are symmetric keys used by the OP to sign the HTTP parameters sent from the RP.

If the OP owns the local OP, the MNO may not have to distribute these secrets, because the OP can establish a key with its local OP (confirmed by the GP and/or GMA). The MNO may need to remotely manage the secrets of the SCWS, but he may use this approach to establish a key for the local OP.

(RSCWS-4) In another example implementation, the protection of secrets from (RSCWS-3) should make it impossible to read from other applications on the phone, and all the algorithms that act on these secrets are It runs in the security environment provided by the smart card, so that the secret will not be exposed outside the application space in the smart card environment.

If the local OP is a global platform application, the key can be stored in the security domain of the local OP, where the security domain of the local OP performs cryptographic operations for the local OP.

(RSCWS-5) In another example embodiment, the local OP associated with the SCWS can store secrets and associated controls for the OP to use in the future, so that if the RP is accessed again, the additional cost from the MNO to the OP can be reduced. OTA business volume.

(RSCWS-6) In another example embodiment, the local OP associated with SCWS can use additional security features that can only be displayed by legitimate local OPs in the authentication page displayed to the user, such as being stored securely in Smart Secret image in the card.

(RSCWS-7) In another example implementation, the OP associated with SCWS must implement application logic other than the application logic for processing HTTP requests and displaying HTML pages, especially for applications that sign parameters from RP logic.

(RSCWS-8) In another example implementation, if the implementation option of generating a secret from the OP associated with SCWS is used, the application logic from (RSCWS-7) must generate a symmetric secret and pass it securely to Entities in the MNO network.

(RSCWS-9) In another example embodiment, the application logic from (RSCWS-7) and (RSCWS-8) can be implemented in a Java applet or applet dynamically called by SCWS in order to execute the necessary Operate, and then return control to SCWS. The applet/servlet should run in a secure environment in UICC.

(RSCWS-10) In another example embodiment, SCWS can provide a dynamic web page for authentication, which displays information retrieved from the MNO based on a user profile, such as advertising banners, where the user profile can be accessed through It is generated by tracing the user OpenID used on the RP. MNO can provide RP'Internet space' for marketing/advertising purposes on SCWS. Doing so will bring additional value to the OP on SCWS.

(RSCWS-11) In another example implementation, if SCWS proves to be too restrictive in a specific scenario, then another option could be to implement application logic based on a JavaCard application that mimics the functionality of SCWS: the application accepts incoming HTTP requests, Provide users with a verification interface (such as a PIN), calculate the signature, generate an HTTP response, and respond to the browser. In this solution, it can be explored whether the BONDI framework contributes to the indirect communication part between the browser and the smart card application that replaces SCWS.

4.4.1.3 Naming rules The following naming rules for entities are applicable: · OP associated with SCWS: local OpenID identifies the supplier, which publishes signed assertion messages, and sends these messages to the users browser RP. The smart card and even the OP storing the SCWS are assumed to have a relationship with the MNO, and thus all entities associated with the MNO have a relationship.

·RP: Relying party, it can be any website that uses OpenID to provide users with login. RP is completely independent of all other entities. Therefore, no additional requirements can be imposed on RP, and the OpenID protocol process used for RP cannot be changed. The OP must support any communication mode (stateless or association-based) that the RP chooses to use. If the MNO decides that the user should not use certain RPs, then because the user can also use other identifiers, the MNO cannot deny access to these sites by denying OpenID access to these RPs. The MNO can only use additional devices to restrict access to the RP, where the additional devices generally prevent access to sites that consume bandwidth.

· OP-Agg: OP-Agg implements entity E2 from (R-7), which provides discovery services for RP.

OPSF: The OP Service Function (OPSF) implements a support OP function that can generate, share and distribute secrets with the OP associated with the SCWS and optionally with the RP from (RSCWS-1). From the perspective of RP, OPSF and OP associated with SCWS behave as if they are a single entity. OPSF can verify the signature issued by the OP associated with the SCWS, and it can be directly reached by the RP via the public Internet. By modifying the local DNS resolution cache on the device, the browser on the device can be redirected to the OP associated with the SCWS, so that the address of the OPSF is mapped to the local OP associated with the SCWS.

·Browser: displayed in the agreement flow chart to clarify the routing and messaging functions to and from the OP associated with SCWS. Otherwise, it is just a front end that displays and receives user authentication.

4.4.1.4 Implementation of OP on SCWS/UICC While trying to maintain a compatible standard OpenID authentication protocol, this section uses implementations derived from the general concepts described above. The following discusses two implementations of stateless and association-based mode agreements; the second implementation uses cryptographic assumptions, which includes sharing the key between the OP card function and the server function on the network side in order to strengthen authentication Process.

4.4.1.4.1 Agreement Process Description The following section describes an example implementation of the agreement process for implementing the OP associated with SCWS. In an example embodiment, as shown in (R-1) above, both of these schemes (stateless and association-based) can be covered. The following provides an agreement flow chart and description about the call flow of the embodiment. The general OpenID protocol is shown in Figure 3.

Multiple options are shown in Figures 24-27 and explained in the corresponding descriptions.

4.4.1.4.2 Protocol flow for RP using stateless mode Figure 24 shows an example implementation of the protocol flow that enables RP to use stateless mode to perform OpenID authentication. For example, RP can use a stateless mode to perform OpenID user authentication. As shown in Figure 24.

530: Users can access the RP website and enter their OpenID identifier. For example, http://op.org/identity.

535: The browser can send an HTTP message containing the OpenID identifier to the RP website.

540: RP can use OpenID based on HTTP/HTML'simple' discovery process, and contact OP-Agg via the public Internet, in order to retrieve the identification page for the OpenID identifier. For example, HTTP get (GET) http://op.org/identity.

545: OP-agg can receive the request and respond with an HTML page containing OPSF's Internet address, such as the following address: <link rel = "openid.server" href = http:// op.org/server.cgi>

OPSF can operate the RP like a standard OpenID identification provider web service, that is, when the RP requests it, the OPSF can verify the signature on the assertion message (issued by the local OP). OPSF can be reached via the public Internet, and can be assumed to have a DNS name that can be reached via http://op.org, such as op.org. Since it is impossible for the outside world to know the IP address of the smart card, this indirect OP-agg and OPSF are used for communication.

The address of OPSF can be different from the address of OP-agg.

a. Option 1: This item is not required, but an option is given. If this option is not used here, option 2 at 570 can be used in a subsequent phase of the agreement.

i. OP-agg notifies OPSF of the request from RP by sending RP identifier and OpenID user identifier to OPSF.

ii. OPSF can try to find the secret and OpenID identification of the RP in the local database.

iii. If no secret is found, the OPSF can generate a new secret and associated control, and send both to the OP associated with the SCWS, and the SCWS then stores them instead.

iv. If a secret is found, OPSF will use the secret to perform signature verification in the future. It can be assumed that if the OPSF finds a secret in the local database, then the OP associated with the SCWS has already received the secret and associated control during the previous protocol execution with the RP, so that the secret can be stored and reused.

The secret used by the OPSF to verify the signature and the secret used by the OP associated with the SCWS to generate the signature may be the same. The freshness of the signature can be ensured by the temporary usage of the RP inserted in the next step, and the temporary usage of the RP needs to be part of the signature. The OpenID specification maintains the default of the freshness of the signature secret itself. The OP is responsible for ensuring the strength of the secret password, maintaining its secrecy, and ensuring its freshness when needed. OPSF and OP associated with SCWS can last for a limited lifetime or be used to count the use of signature secrets for that purpose. More about the secret sharing options are described in section 4.4.1.4.3.1.

550: RP can receive the address of OPSF, and create temporary usage and session identifier, for example, temporary usage=123123, session=user. RP can compile the return_to (return_to) parameter, which tells the OP which URL the browser should be redirected to after user authentication. RP can issue HTTP redirects, thereby redirecting the browser to the OP server address, where the HTTP redirects can include the following parameters: openid .mode = checked_setup, openid .identity = http://op .org/ identity ,openid .return_to = http://rp .org/return .cgi?session=User&nonce=123123555: The browser can receive the redirect and open the connection to the URL specified by the RP in the redirect message.

560: Combined with a modified local DNS lookup table that can map OPSF URLs to SCWS local IP addresses, for example, by using a host file with the entry http://op.org == 127.0.0.1, you can Redirect the browser to the local OP associated with SCWS and issue an HTTP request containing the parameters from 550.

The modified local DNS lookup table can be used on the device, and it will make the device think that the URL http://op.org is at the local IP address of SCWS. Therefore, the browser can open the connection with SCWS/local OP instead of connecting to OPSF (which can be reached via the public Internet at URL http://op.org).

565: By performing the following processing, you can ensure that the verification business volume is kept locally. These steps are not required or prescribed by the OpenID protocol specification: a. OP can be associated with SCWS and display the local verification page b. The user can enter it Verify certificates, such as username and password c. OPs can be associated with SCWS to verify these certificates 570: If option 1 at 545 is used, then the OP associated with SCWS may have an OP associated with SCWS The secret and association control shared with the OPSF, wherein the secret and association control are newly received from the OPSF or retrieved from the local memory of the secret and association control.

a. Option 2, if option 1 is not used in 545: i. OP associated with SCWS can generate new secrets and associated control ii. The OP associated with SCWS can send this secret and associated control to OPSF via SCWS iii. OPSF can receive the secret and store it securely for later access. For example, the goal here can be to share the secret between OPSF and the local OP. Therefore, if the local OP generates a secret, it can be After generating the secret, pass it to OPSF.

The local OP with the toolbox enabled can use CAT to actively communicate with the mobile phone, thereby bypassing SCWS. The message can be formatted in accordance with a standard OTA (for example, OTA for sending OPSF via SMS-PP bearer). However, this processing may require OPSF to communicate with the card via the MNO's OTA system. As an alternative, the BIP gateway can capture the payload of the toolbox message, and the phone can send it to OPSF using TCP/IP. But this still requires the message to go through the MNO's OTA server. If the card does not have an IP address and does not support TCP/IP, then BIP can be used.

575: The OP associated with SCWS calculates the signature of the following parameters: return_to, identification, and mode.

580: The OP associated with the SCWS sends an HTTP redirect message to the browser, which contains the parameters received from the RP in step 550, in addition to the following items: a series of signed parameters in the openid.signed parameter Parameters, the associated control in the openid.assoc_handle parameter, and the signature (base64 encoding) in the openid.sig parameter.

This message is used to redirect the browser to the return_to URL on the RP.

585: The browser redirects the user to the return_to URL on the RP.

590: RP receives the signed assertion message, and participates in the verification process carried out with OPSF through direct communication via the public Internet and based on HTTP(S).

595: RP issues an HTTP POST message, which contains the parameters received in 580 from the OP associated with SCWS.

600: OPSF uses the shared key to verify the signature on the received data.

605: If the signature verification is successful, OPSF returns is_valid: true.

610: For RP, users are now identified as http://op.org/identity.

615: The browser displays the HTML page of the RP.

620: Log the user on the RP as http://op.org/identity.

4.4.1.4.3 Additional implementations for the stateless mode 4.4.1.4.3.1 The stateless mode of the shared secret OpenID is characterized by the process in which the RP receives a signed statement from the OP, but because the RP does not know the signature Is secret, so the signature cannot be verified by itself. In the stateless mode, the RP contacts the OP again to verify the signature. Since from the perspective of the RP, the OP issuing the signature (associated with SCWS) and the OP checking the signature (OPSF) are considered the same entity, so they must be able to share secrets. There are several options for this.

4.4.1.4.3.1.1 Option 1: OPSF to manage secrets This section outlines some implementations that use Option 1 at 454 described above with reference to Figure 24. Once the discovery process is performed, OP-agg can send a notification to OPSF. OPSF can then create secrets and associated controls, and send both to the OP associated with SCWS. If OPSF is part of the MNO, then SCWS remote management processing can be used. If OPSF is not part of the MNO, the global platform approach allows OPSF to send keys to the local OP on the card, assuming that the mobile phone provides support. In option 1, the central secret/association control database and management can be implemented on OPSF, which stores the OpenID identifier, RP to association control and the mapping of secrets in the database. Once the OPSF is notified, the OPSF can perform identification and RP lookup. If no secret is found, the OPSF can generate a new secret and associated control, and send it to the OP on the SCWS. This exemplary embodiment assumes that the OP on the SCWS can store the secret of the RP and the associated control, and the secret used by the OP on the SCWS for signing is the same as the secret used by the OPSF for signature verification. Then, the process will be executed once on each RP.

4.4.1.4.3.1.2 Option 2: Generate a new secret by the OP on SCWS This section outlines some implementations that use Option 2 described above with reference to Figure 24. Once the parameters from the RP are received, the OP associated with the SCWS can generate new associated controls and secrets. The OP associated with the SCWS can use the secret to sign the parameters, and then send this secret and associated control to the OPSF. If the OP on the SCWS can also store the secret, then the OPSF can decide to store the secret and associated control for later use. Then, the process can be performed only once for each RP. This process assumes that a permanent secret already exists, which can allow the local OP to encrypt the new secret so that it can only be decrypted by the OPSF. This encryption process allows the local OP to send new secrets to the OPSF without requiring transport layer security.

4.4.1.4.3.1.3 Option 3: Secret derived from a public seed In an example embodiment, if the OP and OPSF associated with SCWS share a common seed, the public seed can be pre-established and independent of combining different RPs If one or more secrets are used, then another variant can be used. Assume that OP and OPSF on SCWS share a common seed value S. By applying the encryption function to S and information P received in the communication process of uniquely identifying the current OpenID process, the two can have the same secret. For example, the shared secret can be calculated by applying a hash function to the concatenation of S and P, for example, by calculating the shared secret as k=SHA1(S|P). By examining the information P received by the OP and OPSF associated with the SCWS, different candidates can be considered, such as the RP IP address and OpenID identifier, the entire parameter set received from the RP, a parameter subset, and any combination of the above and many more.

As in the key derivation function that is pre-generated and can use secret and association control when needed, the secret derived in this way can also be pre-generated in accordance with the public mode.

4.4.1.4.3.1.4 Further options Further options are also applicable, these options can produce similar states, for example, OP and OPSF share the same secret state.

4.4.1.4.3.2 Verification options Since there is no actual user verification in the OpenID specification, different options are applicable.

4.4.1.4.3.2.1 Implementation for integrating concepts from trusted OpenID In an example implementation, for example, by using TPM, the device can generate measurements on software. These measurements can then be transferred to the OP associated with the SCWS during the authentication session. The local OP may have reference values for comparison with the measurements, and the verification will only succeed if the reported measurements correspond to these known good reference values.

4.4.1.4.3.2.2 Using verification certificates to unlock OpenID secrets In an example embodiment, the user and OPSF may share public secrets, such as PIN codes. The PIN code can be used to calculate the secret each time the user enters the certificate, which is similar to the implementation described in 4.4.1.4.3.1.3. This PIN can be shared through out-of-band registration processing.

4.4.1.4.3.2.3 Bind user authentication to device and network authentication If the smart card (and SCWS) supports biometric user authentication, then OpenID authentication can be bound to the biometric identifier provided by the user. Since the OP is located locally (on the smart card), it can directly access the biometric reference data and will not leak biometric data to the MNO or other Internet entities.

In an example embodiment, the communication device may be connected to the network. The device can hold a certificate, which can be safely stored on the device or a smart card such as UICC, and the certificate is used to enable the device to verify the network. In order to provide secure access to devices and network services that can only be accessed by the user, the device may include a biometric scanner to provide a complete three-factor authentication mechanism, where the mechanisms combine Biometrics, certain things the user knows (such as pins or passwords), and certain things the user has (such as the security token generator fob).

By combining with the previously described implementation for device verification, user verification can also be introduced in the verification process. After the user authenticates the user to the device using a combination of these verification mechanisms, the device can check whether the user verification is correct, that is, the device first verifies the user, and then, if the result proves to be correct, it will The user authentication information that has been checked (for example, the user certificate used in the user authentication process in the original form, hashed form or other compressed form) is combined into its own internal device certificate, and then combined The binding certificate information is sent to the network.

Once the combined certificate is received, the network can assess whether the device is being used by a legitimate user, and whether the device itself is legitimate.

If the device itself cannot check the authenticity of the user, it can first send the combined certificate information to the network, without allowing the user to perform any other processing, and only evaluate the combined certificate on the network and convey information about the users approval Only after the verified information allows users to access its other functions. The device can then allow the user to access its other functions.

This method can provide the most stringent security, but based on the security policy implemented, the number of elements used in verification may be reduced.

The verification mechanism can be introduced into the verification schemes of these implementation modes including: 1. The user provides all three forms of authentication information to the device, so that the user is authenticated against the device. Once the verification is successful, it provides access to the functions of the device and the data held on the device. Then, the device uses normal methods to authenticate to the network in order to provide users with network-based services available on the device.

2. The user provides all three forms of authentication information to the device. This will use some or all of the information to authenticate the user to the device. Once the authentication is successful, some or all of the authentication information will be combined with the certificate information kept on the device. Send to the network for additional verification with the network. Once the authentication between the device and the network is successful, the user is allowed to access device functions, data maintained on the device, and network-based services.

3. A variant of (2) above is to send biometric information to the network or the only information element that is safely exported, such as the fuzzy hash of biometric information, for network-level user authentication without the need to use The biometric information of the user is used for local verification of the device.

4. Another variation of (2) or (3) is to allow the user to have restricted access to the device functions and data until the network authenticates the user (and the device) and the device obtains the relevant information sent by the network. Instructions for the assessment. In this mode, the user will be allowed to access or use certain pre-designated "safe and guaranteed" functions, and those only after completing the network verification of the user and device certificates and sending the appropriate authorization back to the device Features that are only allowed to be accessed.

Variations of the above-mentioned mechanism in which the user authentication function is dispersed between the device and the network or distributed in one entity are also feasible. In addition, by binding user authentication and device authentication, strong authentication on the user and/or device can be provided.

Although multiple types of biometrics can be introduced, example embodiments can use biometric scans such as fingerprint scanners or retinal scanners. By introducing biometric scanning as a natural extension of the user interface, it is possible to adopt a method that provides dynamic and transparent user authentication based on trigger events when users perform functions or access specific services local to the device or through communication networks. Way to introduce biometric scanning into the safety function. For example, a fingerprint scanner can be introduced into a soft key to trigger a soft key operation, such as "send" when the finger is tapped, so as to make a call while authenticating the user. Alternatively, by combining the user's physical contact with the device on the display surface, the device body, or the touch button, an unobtrusive verification process can be used to continuously verify the user to the device.

4.4.1.4.4 RP agreement flow using association-based mode Figure 25 shows an example implementation of the agreement process that allows RP to use association-based mode to perform OpenID user authentication. The association can be performed after the user contacts the RP for the first time and uses its OpenID identifier in combination with the RP. If an association is established, the association can be reused, which will further reduce the communication work. However, the OP may not require the working mode of the RP, and it is possible that the RP decides one of the two communication modes.

The association establishes a permanent secret between the RP and the OP, and the RP can use the secret to sign the assertion message. In addition, the RP can also use the secret to verify the OP signature. The OP can decide the validity period of the shared secret. RP and OP use association control as the identifier of the secret. The RP includes the association control in the first request message to the OP, and then the OP can use the corresponding secret according to the association control. If the OP determines that the association has expired, the OP will notify the RP in a response message. In principle, this allows the OP to reject any association request. As long as the RP can also support the stateless mode, this process can be used to force the RP to return to the stateless communication mode. For example, if the OP cannot support the signature mode (HMAC-SHA1 or HMAC-SHA256) requested by the RP, then the OP can reject the association request.

Contrary to the stateless communication mode in which a user establishes a new secret between the RP and the OP every time the user logs in to the RP, each identification and the RP will be associated once. If an association has been established between OP and RP, then RP and OP can reuse the association.

Once the OPSF address is known, that is, after the discovery phase, the RP can establish an association, and before continuing to execute the protocol, that is, before including the association control in the redirect message, the RP must complete the association.

As shown in Figure 25: 625: The user can access the RP site in order to use OpenID to log in; he can enter his OpenID identifier, for example http://op.org/identit630: the browser can send to the RP website Send an HTTP message containing the OpenID identifier.

635: RP can use HTTP/HTML-based OpenID'simple' discovery processing, and get in touch with OP-agg via the public Internet to retrieve the OpenID identifier on the identification page, such as HTTP to get http://op. org/identity640: OP-agg can receive requests, and it can respond by using an HTML page containing the OPSF address, for example, the following address: <link rel="openid.server" href=http:/ /op.org/server.cgi>

OPSF address can be different from OP-agg address 645: RP can use HTTP with the following parameters for OPSF POST (transfer) call: openid.mode (openid. mode) = associate (association), openid.assoc_type (openid. association_type) = HMAC-SHA1, openid.session_type (openid. session_type) = blank (empty) ,openid.dh_*='Diffie-HellmanParameters' 650: OPSF can generate shared secret and association control for RP 655: OPSF can use association control and secret (if Diffie-Hellman is used , The secret is encrypted) HTTPPOST contained in the key=value format file to respond to the RP. This association can be established once for each RP and OpenID identification. Since Diffie-Hellman may be attacked by MITM attacks, the OpenID best security practice recommends using HTTPS authentication 660: RP can create session temporary usage and session identifiers, such as nonce=123123, session=User (user) 665: RP can store secrets and association control received from OPSF 670: RP can include association control in a redirect message 675: RP can send an HTTP REDIRECT message containing the following parameters to the browser: openid.mode=checked_setup (verified) _Establish), openid.identity=http://op.org/identity, openid.return_to=http://rp.org/return.cgi?session=User&nonce=123123,openid.assoc_handle (openid. Association_Control) ='association_handle'680: The browser can receive the redirect message and open the connection with the URL specified in the RP in the redirect message. 685: By means of the modified DNS lookup table that maps the OPSF URL to the SCWS local IP address , For example, by using the item http://op.org==127.0.0. The host file of 1 can redirect the browser to the local OP associated with SCWS, and post an HTTP request containing parameters from 675. The modified local DNS lookup table can be used on the device to make the device think The URL http://op.org is at the local IP address of SCWS. Therefore, the browser can open the connection to SCWS/local OP instead of connecting to OPSF (the OPSF can be reached via the public Internet at URL http://op.org) 690: The following items are not caused by The OpenID protocol specification stipulates: a. The OP associated with SCWS can display the local authentication page b. The user can enter his authentication certificate, such as user name and password c. The OP associated with SCWS can verify the certificate 695: related to SCWS The associated OP may need to use the secret shared between the OPSF and the RP to sign the return message, and several options can be applied: a. Option 1: i. The secret may already exist, for example by OPSF in advance Shared and pre-equipped b. Option 2: i. OPSF can send associated control and secrets to the OP associated with SCWS, for example via a secure SMS, or guided by GBA, and/or use a secure communication protocol For example, SCWS HTTPS remote management interface ii. OP associated with SCWS can store secrets and association control c. Option 3: i. OP associated with SCWS can request secrets from OPSF by using the association control received from RP . The agreement for this message can be run with the help of SMS, in addition, other options are also feasible, and its feasibility needs further study ii. OPSF can perform secret lookup based on association control iii. OPSF can send secret and association control to SCWS related Associated OP, such as sent via secure SMS-PP, or guided by GBA, and/or using secure communication protocol, such as SCWS HTTPS remote management interface 700: OP associated with SCWS can use secret to calculate return_to URL, Identification and signature on pattern parameters 705: The OP associated with SCWS can include the signature as an additional parameter in the HTTP redirection 710: The OP associated with SCWS can send an HTTP redirect message to the browser, the HTTP redirect message Contains the following parameters: openid.mode=id_res,

4.4.2 Implementation methods for OP improvement on SCWS 4.4.2.1 General methods for improvement In the example implementation in section 4.4.1, the local OP that can be associated with SCWS and OPSF may need to be at least for each RP Establish a shared secret for assertion signature and verification. However, other methods can also be applied, in which the protocol is further improved by using additional cryptographic means, which allows only one (long-term) shared secret to be established between OPSF and the local OP, and then a cryptographic function is used to derive the signature for the signature Secret. In addition, the integration of the secret exchange process between the OPSF and the local OP can be performed inside the agreement message.

4.4.2.2 Background technical information on improvements The following sections provide more technical background for possible implementations and implementation methods.

SCWS can use IP-based methods or traditional UICC methods to securely communicate with mobile phones and indirectly secure communications with external parties; UICC application owners can download these applications to UICC and manage them remotely.

In terms of resource usage on UICC, it can be noted that UICC that can support global platforms, SCWS and subsequent IP stacks is likely to support large-capacity memory and USB. This kind of UICC can have a sufficiently powerful processor, and O/S will take on resource management.

In 575 (stateless mode) in Figure 24 and 695 (associated mode) in Figure 25, the OP associated with SCWS can store and use secrets. For example, by performing this process, the signature key can be kept in a protected memory that will never be discarded, and the key can only be used by the cryptographic algorithm of the card itself. The key can be a key that can be safely shared with another (trusted) party (similar to an MNO) and is guaranteed not to leave the smart card. For the application-specific signing key in the downloaded applet, we need to consider four questions: (1) How does the key enter the UICC and the applet, (2) how to keep the key secure, (3) ) Who can use the key, and (4) How can the key be updated.

In an example implementation (the answer to question (1)), the key dedicated to the OP on the UICC can be loaded as part of the executable load file of the applet, and can reside in the designated application of the applet In the key file. The application download does not need to use SCWS to manage the update process. However, SCWS can call smart card applications (meaning any application, not just SCWS web pages). This means that the local OP may be a small application running in the global platform framework. For this kind of complex small application (it is not just the SCWS HTML page), it is more advantageous to use the global platform small application loading process.

In another example implementation (the answer to question (2)), the secrets belonging to any loaded application are protected by the O/S of UICC. We can rely on O/S to implement this process. The memory where the program loaded by UICC is running is protected by O/S.

In another example embodiment (answer to question (3)), for example, the local OP can use a (dedicated) signature key to sign (or decrypt/encrypt) some data. Any external entity that can communicate with the local OP on the UICC via SCWS can provide data for the applet to perform signature or decryption, but such communication for SCWS may have to be performed as a redirect via the terminal browser. For shared keys, key owners such as OP can distribute such keys to TTPs such as MNOs so that they can use these keys in their interaction with UICC.

If the key file is used to store the key in the OP associated with SCWS, then a standardized applet update process can be used to update the key file. If the SCWS management update process is used, then the process can be completed by the owner of the SCWS update process (assuming it is an MNO). In addition, it is also feasible to use key generation on the card as an alternative.

SCWS provides BIP/CAT communication and TCP/IP/HTPP via USB. In the latter case, TLS (based on PSK or PKI) can be used between the device and SCWS.

In another example embodiment, the OP server application can be loaded onto the UICC as a JavaCard applet, and then used in the manner specified in the version 2.2 global platform card specification released in March 2006 To manage. The applet may be located in the security domain (SD) of the card issuer (CI) or the application provider (AP) SD, even if the two domains are actually owned by the same party (ie, MNO/CI). Alternatively, the OP application can be a firmware or a local application.

OMA can provide security processing for the content and settings of SCWS, where the content and settings are updated by a remote server application using HTTPS for SCWS and mutual authentication. For example, this process is executed for use by the MNO as the card issuer, and is therefore designed around the traditional OTA for transmission. This feature is not used to download those applications associated with SCWS, but to update such applications (only for MNO use).

SCWS can use traditional toolbox and OTA technology (its SMS-PP is ubiquitous by default). Therefore, if the UICC does not have its own IP address, then SCWS describes the use of CAT/BIP for UICC/ME connections, so as to browse web pages on SCWS from clients, and transfer and manage web pages on SCWS from a management entity. Similarly, SCWS can also support serial SMS-PP for messages from remote administrators. However, if the UICC has its own address, SCWS can also support direct TCP/IP connections on the UICC high-speed (ie USB) interface to browse web pages from clients, and direct TLS connections over direct TCP/IP connections To transfer and manage web pages on SCWS from the management entity.

4.4.2.3 Introduction to Improved OP on SCWS The following embodiments describe an improved variant of the concept of OP on SCWS. OP on SCWS can be an improvement to OpenID/GBA. For example, these embodiments can provide the following advantages: OP on SCWS can make the authentication process local to the device, and thereby significantly reduce communication costs, thereby improving OpenID/GBA.

Further improvements on the OP on SCWS can be carried out between the OP and the network entity by passing a verification secret within the standard OpenID message field. Doing so can further reduce the communication overhead, and can ease the relationship between the OP on the SCWS and the network entity (OPSF), so that OpenID can be migrated between networks.

In addition, the following implementations can allow OP on SCWS to generate the following major advantages for network operators, such as: · No authentication traffic on the mobile network · Authentication traffic on the public Internet · All application data traffic is active 4.4.2.4 Improvements made by local OPs on the Internet In an example embodiment, local authentication may be performed on OPs associated with SCWS, thereby significantly reducing business volume. For example, by executing this process, the verification traffic can be localized, thereby reducing the burden on the network itself. In an example embodiment, a shared secret can be established for each RP accessed by the user between the network OPSF entity and the OP associated with the SCWS. Several mechanisms for establishing this secret are described here. For example, in an example embodiment, if RPs use associations, they can store a secret for signature verification and can reuse the secret the next time the user accesses it. In another example embodiment, if the RP uses the stateless mode, the RP cannot keep the secret. OP can create a secret and can safely share the secret with OPSF. The OP associated with SCWS can store the secret, and can reuse the secret when the user accesses the same RP next time. OPSF can also store the same secret, so OPSF can use it directly in stateless mode. Yu signature verification.

In another example embodiment, to some extent, a secret shared once between OSPF and the OP associated with SCWS can be reused. For example, if a total of 5 secrets can be saved for the OP on the smart card, these secrets can be reused every time the user accesses the RP. For example, compared with OpenID/GBA specified in 3GPP TR 33.924, by executing this process, network traffic can be greatly reduced. For example, the daily business volume can be reduced by half. If several days are considered, the reduction will be even greater because the secrets can be reused.

The mentioned secret may be different from the secret used in OpenID/GBA. The secret shared between OPSF and the OP associated with SCWS is the OpenID secret used to sign the assertion message. As in the standard OpenID protocol process, these secrets can be shared with the RP and can be established as long-lived secrets. For example, the secrets last longer than a single login session, so basically This kind of reuse is allowed.

4.4.2.5 Further improvements In an exemplary implementation of the protocol process for implementing the OP on the SCWS, the OPSF network entity run by the MNO can participate in additional communication with the OP associated with the SCWS on the device. Since both entities must be equipped with the same symmetric key so that each RP can sign the assertion message or verify it separately, this communication is necessary.

By further improving these implementations, the additional communication between the device and the network can be greatly reduced, and the information necessary to establish a secret can be directly encapsulated into the protocol field of the OpenID message. These messages are sent via the public Internet as HTTP messages, and they may cause an additional burden on the MNO's air network infrastructure. For example, by performing this process, it can be ensured that the verification traffic is local, that is, between the browser and the UICC/SCWS in the device, thereby preventing the unused network from being used. Since the communication is offloaded from the (over-the-air) network to the internal communication within the device, this processing can reduce the general business volume.

By ensuring that there is no need to perform additional signaling traffic for authentication between the MNO and the UICC/device, another improvement to these implementations can be given. For example, there may be no GBA process (run) for each verification, or no SMS/MMS or control messages will be sent via the air interface between the network and the device. All necessary information can be directly transmitted within the HTTP message, where the HTTP message can be partly through the air network and through the Internet (device to RP), and partly through the fixed line public Internet (RP to MNO) Be transmitted. However, the business volume can be 1) triggered by users who wish to log in using OpenID, 2) charging users through existing data planes, and 3) less than web-based OpenID and less than in OpenID/GBA.

4.4.2.4 Technical details about protocol improvements 4.4.2.4.1 Naming rules The same naming rules as described above will be repeated here for reference: · OP associated with SCWS: local OpenID identifies the supplier, and its release carries Sign assertion messages and send these messages to the RP through the user's browser. It is assumed that the smart card and even the OP storing the SCWS have a relationship with the MNO, and therefore have a relationship with all entities associated with the MNO.

·RP: Relying party, it can be any website that uses OpenID to provide users with login. RP is completely independent of all other entities. Therefore, no additional requirements can be imposed on RP, and the OpenID protocol process of RP cannot be changed. The OP must support any communication mode (stateless or association-based) that the RP chooses to use. If the MNO decides that the user should not use certain RPs, then because the user can also use other identifiers, the MNO cannot deny access to these sites by denying OpenID access to these RPs. The MNO can only use additional devices to restrict access to the RP, where the additional devices generally prevent access to sites that consume bandwidth.

· OP-Agg: OP-Agg implements a network entity that provides discovery services for RP in accordance with the OpenID protocol.

OPSF: The OP service function (OPSF) implements the OP function that can generate, share and distribute secrets with the OP associated with the SCWS and optionally with the RP from (RSCWS-1). From the perspective of RP, OPSF and OP associated with SCWS behave as if they are a single entity. OPSF can verify the signature issued by the OP associated with the SCWS, and it can be directly reached by the RP via the public Internet. By modifying the local DNS resolution cache on the device, the browser on the device can be redirected to the OP associated with the SCWS, so that the address of the OPSF is mapped to the local OP associated with the SCWS.

The requirements and necessary functions of the OPSF of this entity are precisely described in the previous document "OP on SCWS specification draft" as above.

·Browser: displayed in the agreement flow chart to clarify the routing and messaging functions to and from the OP associated with SCWS. Otherwise, it is just a front end that displays and receives user authentication.

4.4.2.4.2 Possible assumptions regarding the implementation mode The OP and OPSF functions associated with the SCWS can establish a long-term secret K, which is protected by the security features of the smart card and can only be accessed by the OP associated with the SCWS. For example, the secret can be established by a single GBA process, another key derivation function that allows the key to be derived from the AKA key, or any other generated between the MNO and the OP associated with the SCWS A shared secret method is established, where the shared secret can be protected by the security features of UICC. In addition, the process of establishing a secret can be performed using any method known in the art.

Smart cards can also provide cryptographic functions (algorithms and calculations) to calculate new secrets from K. The specific attributes of this function can be obtained from the description of the security requirements. The same or similar functions can also be known to OPSF, which allows OPSF to derive the key from K.

Both entities can generate random values long enough for cryptographic operations.

4.4.2.4.3 Agreement Process Description The following section describes an example implementation of the agreement process used to implement the OP associated with SCWS.

4.4.2.4.3.1 Example implementation of the protocol flow of the RP using the stateless mode If the RP uses the stateless mode to perform OpenID user authentication, the implementation described in Figure 26 can be applied.

4.4.2.4.3.1.1 Description of stateless mode Figure 26 shows an example implementation of the improved stateless mode agreement process.

745: The user can access the RP website, and in order to log in with OpenID, he enters his OpenID identifier, such as http://op.org/identity750: the browser can send an HTTP message containing the OpenID identifier to the RP website .

755: RP can use HTTP/HTML-based OpenID'simple' discovery processing, and get in touch with OP-agg via the public Internet to retrieve the OpenID identifier on the identification page, such as HTTP to get http://op. org/identity.

760: OP-agg can receive requests and respond with HTML pages containing OPSF Internet addresses. For example, OP-agg can respond by including the following address: <link rel="openid.server" href=http://op.org/server.cgi>

OPSF can operate the RP like a standard OpenID identification provider web service. For example, OPSF can verify the signature on the assertion message (issued by the local OP) at the request of the RP. According to requirements, the OPSF must be reachable via the public Internet, so it is assumed that the OPSF has a DNS name, such as op.org, which can be reached via http://op.org. Since the outside world does not know the IP address of the smart card, this indirection of OP-agg and OPSF can be used for communication.

The address of OPSF can be different from the address of OP-agg.

765: RP can receive the address of OPSF and create temporary usage and session identifiers, for example, nonce = 123123, session = User. The RP can compile the return_to parameter, which tells the OP which URL the browser should be redirected to after user authentication. RP can redirect the browser to the OP server address by issuing an HTTP redirect containing the following parameters: openid.mode=checkid_setup,openid.identity=http://op.org/identity,openid.return_to=http: //rp.org/return.cgi?session=User&nonce=123123770: The browser can receive the redirection, and can open the connection to the URL specified by the RP in the redirection message. 775: The OPSF The URL is mapped to the DNS lookup table of the SCWS local IP address. For example, by using the host file with the entry http://op.org==127.0.0.1, the browser can be redirected to the local OP associated with the SCWS, and Post an HTTP request containing the parameters at 765.

A modified local DNS lookup table can be used on the device to make the device think that the URL http://op.org is at the local IP address of SCWS. The browser can open the connection with the SCWS/local OP instead of connecting to the OPSF (the OPSF can be reached via the public Internet at the URL http://op.org).

780: By performing the following processing, you can ensure that the verification business volume remains local. These steps are not required or prescribed by the OpenID protocol specification: a. The OP associated with SCWS can display the local verification page b. The user can enter his verification certificate For example, user name and password c. The OP associated with SCWS can verify the certificate 785: The OP associated with SCWS can create a unique random association control A. By using the function f, S=f(A, K) can be used to calculate the signature secret of the assertion message, where the f should be one-way, so that knowledge of A will not reveal any knowledge of K. In an example embodiment, even if S and A are shown, that is, S and A are given, f will not show any knowledge about K. In terms of calculation, K=g(S,K) is calculated for the function g. Is not feasible.

Since A can be presented to the RP as a part of the parameters in the redirect message, it can be assumed that the RP will not gain knowledge of S in the stateless mode of the OpenID agreement process. The association control A can be included in the redirect message. In addition, it can be assumed that the signed message m signed with S will not show any information about K to the signature verifier (due to the use of symmetric key signatures, the signature verifier always needs to have S to verify the signature, by Therefore, we do not require that the signature does not show S).

Here, it can be specified that the associated control is a string of 255 characters or less, and it can only include ASCII characters (printable non-blank characters) in the closed interval 33-126.

The secret used by the OPSF to verify the signature and the secret used by the OP associated with the SCWS to generate the signature may be the same. The freshness of the signature can be ensured by the temporary usage of the RP inserted in the next step, and the temporary usage of the RP must be part of the signature. The OpenID specification maintains the default of the freshness of the signature secret itself. The OP is responsible for ensuring the strength of the secret password, maintaining its secrecy, and ensuring its freshness when needed. OPSF and OP associated with SCWS can last for a limited lifetime or be used to count the use of signature secrets for that purpose.

The local OP with the toolbox enabled can use CAT to actively communicate with the mobile phone while bypassing SCWS. The message can be formatted in accordance with a standard OTA (for example, OTA for sending to OPSF via SMS-PP bearer). However, this processing may require OPSF to communicate with the card via the MNO's OTA system. In another example embodiment, the BIP gateway can capture the toolbox message payload, and the phone can send it to OPSF using TCP/IP. This may require messages to be sent via the MNO's OTA server. SCWS claims that BIP can only be used if the card does not have an IP address and does not support TCP/IP. Therefore, it is desirable to send via SCWS by using TCP/IP.

d. Further options can be applied, which may generate a shared secret between OP and OPSF associated with SCWS. The feasibility of this method needs to be studied in the next step.

790: The OP associated with SCWS can calculate the signature on the following parameters: return_to, identity, and mode.

795: The OP associated with the SCWS can send an HTTP redirect message to the browser, the message including the parameters received from the RP at 765. In addition, the following items can be included: · a series of signed parameters in the openid.signed parameter · association control in the openid.assoc_handle parameter · signature in the openid.sig parameter (base64 encoded).

This message can be used to redirect the browser to the return_to URL at the RP.

800: The browser can redirect the user to the return_to URL at the RP.

805: RP can receive the signed assertion message, and join the verification process with OPSF in the direct communication based on HTTP(S) via the public Internet.

810: The RP can publish an HTTPPOST message that contains the parameters received at 795 from the OP associated with the SCWS. The HTTP POST message may include the associated control A generated by the OP associated with the SCWS.

815: OPSF can extract A from the parameter list, and can use the same function f with the same input as the OP associated with SCWS, that is, OPSF calculates f(A,K)=S, and uses S as a shared secret To verify the signature on the data received from the OP associated with the SCWS.

820: If the signature verification is successful, OPSF can return is_valid: true.

825: For RP, users can now be identified as http://op.org/identity.

830: The browser can display the HTML page of the RP.

835: The user can log in to the RP as http://op.org/identity. 4.4.2.4.3.2 The protocol flow of the RP using the association-based mode Figure 27 shows the improved association-based mode An example implementation of the agreement process. For example, this process can be executed when the RP uses an association-based model to perform OpenID user authentication. The association can occur after the user first contacts the RP and uses his OpenID identifier in combination with the RP. If an association is established, the association can be reused to further reduce the communication effort. However, the OP may not be able to request the working mode of the RP, and it may be that the RP decides one of the two communication modes.

The association can establish a permanent secret between the RP and the OP, and the RP can use the secret to sign the assertion message. In addition, the RP can also use the secret to verify the OP signature. The OP can decide the validity period of the shared secret. RP and OP can use the association control as the identifier of the secret. The RP includes the association control in the first request message to the OP, and then the OP can use the corresponding secret according to the association control. If the OP determines that the association has expired, the OP can notify the RP in a response message. Doing so allows the OP to reject any association request. As long as the RP can support the stateless mode, this process can be used to force the RP to fall back to the stateless communication mode. For example, if the OP does not support the signature mode (HMAC-SHA1 or HMAC-SHA256) requested by the RP, then the OP can reject the association request.

Contrary to the stateless communication mode in which a user can establish a new secret between the RP and the OP every time the user logs in to the RP, each identification and the RP will be associated once. For example, not all items shown in Figure 27 can be executed when the user logs in. If an association has been established between OP and RP, then the association can be reused by RP and OP.

Once the OPSF address is known, that is, after the discovery phase, the RP can establish an association, and before continuing to execute the protocol, that is, before including the association control in the redirect message, the RP can complete the association.

As shown in Figure 27: 840: The user can access the RP website, and in order to log in using OpenID, he can enter his OpenID identifier, such as http://op.org/identity.

845: The browser can send an HTTP message containing the OpenID identifier to the RP website.

850: RP can use HTTP/HTML-based OpenID'simple' discovery processing, and can contact OP-agg via the public Internet to retrieve the OpenID identifier on the identification page, such as HTTP to get http://op .org/identity.

855: OP-agg can receive the request and respond with an HTML page containing the OPSF address. For example, OP-agg can respond by including the following: <linkrel="openid.server" href= http://op.org/server.cgi>

The address of OPSF can be different from the address of OP-agg.

860: RP can use HTTP POST calls with the following parameters for OPSF: openid.mode=associate,openid.assoc_type=HMAC-SHA1,openid.session_type=blank,openid.dh_*='Diffie-HellmanParameters' 865: OPSF can Generate a unique random association control A for the RP. In addition, OPSF can use the function f and calculate S=f(A, K). Then, S can be used as an association (mid-term) shared secret between RP and OPSF. The RP can later use S to verify the signature on the assertion message from the OP associated with the SCWS. In an example embodiment, since A and S can be shared with RP at 870, even if A and S are known, it can be assumed that f is a unidirectional function, so that S and A cannot be given. Calculate K under the circumstances. The function f itself may not need to be kept secret.

870: OPSF can use HTTPPOST to respond to RP. This HTTPPOST will associate control A and secret S (if Diffie-Hellman is used, the secret is encrypted) and include it in the key=value format file. Each RP and OpenID identification can establish this association once.

880: RP can create session temporary usage and session identifiers, such as nonce = 123123, session = User885: RP can store secret S and associated control A received from OPSF.

890: The RP may include the association control A in the redirect message.

895: The RP can send an HTTP redirect message to the browser. The HTTP redirect message can include the following parameters: openid.mode=checkid_setup,openid.identity=http://op.org/identity,openid.return_to=http://rp.org/return.cgi?session=User&nonce= 123123,openid.assoc_handle=A900: The browser can receive the redirection message, and can open the connection with the URL specified in the redirection message by the RP, by means of a modified DNS that maps the OPSF URL to the SCWS local IP address Lookup table, for example, by using the host file with entry http://op.org==127.0.0.1, the browser can be redirected to the local OP associated with SCWS, and can publish HTTP containing parameters from 885 ask.

A modified local DNS lookup table can be used on the device, and this will make the device think that the URL http://op.org is located at the local IP address of SCWS.

905: The browser can open the connection with SCWS/local OP instead of connecting to OPSF (the OPSF can be reached via the public Internet at URL http://op.org).

910: By executing the following processing, it can be ensured that the verification traffic remains local. These steps are not required or prescribed by the OpenID protocol specification: a. The OP associated with SCWS displays the local verification page b. The user enters his verification certificate, for example User name and password c. OP verification certificate 915 associated with SCWS: The OP associated with SCWS may need to use a secret S that can be shared between OPSF and RP to sign the return message. The parameter A can be extracted from the received HTTP request, and the function f can be applied here, so that S=f(A,K).

920: The OP associated with the SCWS can use the secret S to calculate the return_to URL, the identifier, and the signature on the mode parameter. We may need the function f to not show any information about K to the verifier of the signature on m when it gives a signed message m signed with S.

925: The OP associated with the SCWS can include the signature as an additional parameter in the HTTP redirect.

930: The OP associated with SCWS can send an HTTP redirect message to the browser. The message can include the following parameters: openid.mode=id_res,openid.return_to=http://rp.org/return.cgi?session=User&nonce =123123,openid.identity=http://op.org/identity,openid.signed=mode,identity,return_to,openid.assoc_handle=A,openid.sig='base64 encoded signature calculated using S'935: browser can Redirect the user to the return_to URL at the RP without further user involvement.

940: The RP can receive a signed assertion message.

945: RP can use the determined shared secret S to verify the signature.

950: For RP, users can now be identified as http://op.org/identity.

955: The browser can display the HTML page of RP.

960: Users can log in on the RP as http://op.org/identity.

Additional implementations based on the association mode The following disclosed additional implementations related to the implementation of the stateless agreement described in Section 4.4.1.4.3.

4.4.2.5 Comparison between OP on the improved SWCS and existing OpenID/GBA In OpenID/GBA, users use GBA protocol for authentication, which means that every OpenID login attempt at any RP will trigger the use of via The OP/NAF GBA process of the air interface causes a burden on the network entity (OP/NAF) and the network itself due to the growth of business volume. Suppose that given a customer base of 10,000 users, each user logs in to 10 different RPs every day. According to OpenID/GBA, this will result in a total of 100,000 GBA verification processes performed every day; if each GBA process (inquiry + response) only consumes 1-5kB, there will be a total of 1-4.8GB of additional verification business volume per day.

4.4.2.6 Security Discussion The next section provides the background of cryptographic tools that can be used in the example implementation of the OP agreement on SCWS for stateless and association-based modes. Features such as hash algorithms that can be used are discussed here.

4.4.2.6.1 The generalization function f can be used to establish a shared secret S between the local OP and OPSF. The OPSF and the local OP can have a common shared long-term secret K, which can be used as an input of f, and the K will never be leaked to the other party in the agreement. However, in the association-based mode, since the RP may verify the signature on the assertion message, it is possible to leak the secret S to the RP. Since the shared secret may have security implications, it is necessary to discuss the options that the RP has when it knows S.

This process also applies to the standard OpenID protocol. Assuming that the RP is malicious, the knowledge of S cannot allow the RP to log in to the user on another RP. This is because the other RP will establish another shared secret S'with the OP, which will result in the use of S The signature is deemed invalid. Therefore, revealing the secret to the RP is not necessarily a security issue. However, showing S to the browser (or user) may become a security issue. In this case, the attacker can use the victim's OpenID identifier to activate the OpenID protocol. If the attacker can retrieve the shared secret S shared between the RP and the OP, the attacker can use S to sign the assertion message without performing actual verification on the OP. Therefore, the attacker can log in using the victim's identifier instead of verifying on the victim's OP. It can be seen from this situation that the shared secret S between RP and OP cannot be revealed to the browser, but it is possible to expose S to RP.

If a malicious user works with the RP, the RP may send S to the browser, and the user may log in to the RP without authentication on the RP. However, since the user can only log in to a single RP, and it is assumed that the RP is already under its control (or at least cooperating with the user), this situation may not necessarily be considered an attack. As a result, even if the OpenID authentication protocol process is not executed at all, the user can still log in.

4.4.2.6.2 Security features of the example protocol In some example implementations, it is possible that A and the message signed by S may be leaked to the browser in the redirect message. If A and the message signed by S are learned, then It may be impossible to calculate S. In addition, it is impossible to calculate K even if the same input is given.

Given A and S (the most information that may be leaked to a single third party other than OP and OPSF), if what is needed is that K cannot be calculated by calculation (that is, assuming that there is no function f -1 to make f-1(A,S)=K, which can be calculated in a time polynomial with the length of the input), then without RP, the long-term shared secret K between OPSF and the OP associated with SCWS can be obtained.

Therefore, given a random input A and a shared secret K, it is necessary to generate a new secret S from f so that S=f(A, K). Given A (and a message signed with S), S cannot be calculated at this time. If the input K is correct and exists, then it may be required that f can produce the correct result.

It is possible to calculate f in polynomial time, and the calculation is preferably performed in the protected area of the smart card.

S can be a valid input of the signature function used in OpenID. OpenID knows in advance to use HMAC-SHA1 or HMAC-SHA256 as the signature algorithm. Since OPSF and OP associated with SCWS may reach agreement in advance on the specific signature algorithm and key length, the output length of the function f can be fixed. In an example embodiment, OPSF and OP may use two common secrets K and K, whereby K may be used to derive S for the SHA1-based signature, and Kto derive S for the SHA256 signature.

4.4.2.6.3 Implementation of security The implementation described in this section is a cryptographic operation that can meet the requirements pointed out in the previous section. In an example embodiment, the secret may be directly contained in the OpenID message, which may reduce the amount of business required for verification. User authentication can be performed locally (not involving the MNO network), and the shared secret between the OPSF (MNO network) and the OP (in the device) associated with the SCWS can be safely transmitted within the OpenID protocol message, without There is a need for further external communication between the MNO network and the device.

4.4.2.6.3.1 HMACHMAC is a keyed-in hash message authentication code (MAC) that verifies the source and integrity of the message without using any additional mechanisms. HMAC has two parameters with different functions, namely message input and a secret key known only to the message initiator and one or more intended recipients.

The message sender uses the HMAC function to generate a value (MAC) formed by compressing the key and message input. The MAC is usually sent to the message receiver along with the message. The receiver uses the same key and HMAC function used by the sender to calculate the MAC on the received message, and compares the calculation result with the received MAC. If these two values match, the message has been received correctly, and the receiver is sure that the sender is a member of the community of users sharing the key.

Given the HMAC attributes, by using HMAC for the function f, all relevant requirements as described above can be met.

List of relevant parameters used for HMAC: ·BThe block size of the hash function input, such as 160 bits for SHA1 ·HHash function (such as SHA1) ·IpadInternal filler, repeated B times The byte x'36'·K-the key shared between OP and OPSF·K0-the key used to obtain the B-byte key after preprocessing K·L-the hash function Output block size, such as 160 bits used for SHA1 · Opad-external padding, bytes repeated B times x'5c' · t-number of MAC bytes · text (text)-used for slave Calculate the plaintext of HMAC in the length of n bits, where 0<=n<2^B-8B, in our example will be A·||concatenation·XORexclusive OR·K should be equal to or greater than L/2, that is, for our example, if SHA1 is used, then K should be greater than 80 bits, or if SHA256 is used, it should be greater than 128 bits.

·MAC(text)=HMAC(K,text)=H((K0 XOR opad)||H((K0 XOR ipad)||text)) In order to prevent attacks, it may be necessary to execute two hash functions through nesting To calculate MAC. Combining most hash functions, it is possible to add additional information to the message without knowing the key K, and to obtain another valid MAC. If other alternatives are used, then by using MAC=H(messagekey) to add the key, an attacker who finds a conflict in the (non-keying) hash function can be allowed to get the conflict in the MAC. It is better to use MAC=H(key||message||key), but even if two different keys are used, different security files will show weaknesses.

Figure 28 shows the keyed hash message authentication code (HMAC) from NIST-FIPS PUB 198-1.

Since the external hash function obscures the intermediate results of the internal hash, the current HMAC version of the agreement does not expose these weaknesses. For the security of the algorithm, the padding values (ipad and opad) are not important, but they are defined as having a large Hamming distance from each other, so the internal and external keys will have a smaller amount in common Bits, that is, by using these fillers, two different keys can be "derived" from K0 for use in the hash function.

In an example embodiment, text=A as a random input may be generated by OP or OPSF, respectively. A can be included in the redirect message, and by using K, the two can use the above mechanism to recalculate the HMAC, and the HMAC result can be used as a shared signature secret S for the OpenID assertion message.

4.4.2.6.3.2 The security proof of the OP protocol on the improved SCWS needs to be shown as follows: 1. In the protocol, the attacker can retrieve A and S (for example, as an RP in association mode), so it is necessary to show that he cannot retrieve K.

2. The search performed by the browser/user is even less than that of RP, that is, only A is searched, and S must not be calculated from the knowledge of A.

3. The browser/user must also not be able to calculate K from A.

When simulating an attacker who understands S and A, the attacker does not use the information given on S, the proof of 3. can be derived from 1.

Therefore, what must be displayed is: I. If S and A are given, then there should be no function f*, so that when S=f(A,K), K=f*(A,S)II. If only A is given, then there must be no function g that can satisfy S=g(A) when S=f(A,K).

The proof of the above two theorems can be found in the description of HMAC (or NMAC) provided by Bellare et al., in (11), they essentially show that if the basic compression hash is assumed The function is pseudo-random, and the hash function is weak to collision resistance, then HMAC is a pseudo-random function. In (12), according to the only assumption that the compression function is PRF, these assumptions can be alleviated by showing that HMAC is PRF.

4.4.2.6.3.3 RSA In an exemplary embodiment, by using a private key that must be shared between OPSF and OP associated with SCWS to encrypt a randomly created unique association control, an RSA encryption scheme can be used to obtain a shared key K In deriving the OpenID signature secret S. Assume that N=pq represents the modulus used in the RSA scheme, where p and q are prime numbers. Furthermore, the key pair is represented by e, d (private, public), and is shared as a long-term secret K. Then, the association control A signs with the private part e in order to obtain the signature secret S, that is, S=Ae mod N. Given the security assumptions for RSA, if the public key d is known, A can be calculated from S, but e cannot be calculated given A and S. If only A is given, then S cannot be calculated without knowing e.

4.4.2.6.4 Security implementation variants 4.4.2.6.4.1 Changes to long-term secret K In an example implementation described in section 4.4.2, although long-term secret K is used, for example, during a certain period of time After that, by using a key exchange method between OSPF and the OP associated with SCWS, the secret K can be changed. Any known key exchange method can be used.

The change of K can be performed on OPSF, and the OP associated with SCWS cannot prevent a successful OpenID protocol process.

In an example embodiment, if the OPSF and OP agree on the new long-term secret K'in the stateless mode, the OP can calculate the signature key S'by using the function f in combination with the new key, namely S'=f(A,K'). Then, S'can be used to sign the assertion message, and OPSF can use the new long-term shared secret K'to recalculate S'to verify the signature on the assertion message.

In another example embodiment, if a new secret long-term secret Kis established in the association-based mode, the RP can still keep the old secret S used for the association. If the association is still valid and the RP has not joined the association step with OPSF, then the RP may directly use the old association control A, and may expect an assertion message from the OP signed with the stored secret S. However, the OpenID specification allows OP to include the parameter openid.invalidate_handle in the assertion message. If this parameter is used and set to the old association control A, then the RP will be forced to return to the OP in order to perform signature verification as in the stateless scheme. Doing so can allow the OP associated with SCWS to include this parameter set to A for the new long-term shared secret K', and the new signature secret S'=f(A' using the newly created association control A' ,K'). Doing so may invalidate the control code on the RP, and the RP can contact the OPSF for signature verification. Due to the key exchange, the OPSF may already have K', so that S'=f(A', K') can be calculated, and the signature on the assertion message can be verified. However, if the RP joins a new session associated with the OPSF, the OPSF may also invalidate the control A, and the new key K'can be used with the RP to establish a new pairing A', S'.

4.4.2.6.4.2 Hash chain guarantee for K In an example embodiment, OPSF and the OP associated with SCWS may wish to change the long-term secret K periodically. Based on the secret K, these two entities can perform hash chain guarantees by continuously applying the (password-protected) hash function h to K, which will produce a chain: K0=h(K), K1= h(K0)=h(h(K)),..., Kn=h(Kn-1)=hn(K). If the initial secret K can be established safely, then OP and OPSF can calculate the chain independently. Then, the first shared secret used may be Kn. If the hash function used to construct the hash chain has a one-way property, the value will not allow the attacker to directly calculate the subsequent shared secret Kn-1. The attacker has to reverse the hash function in order to derive the next secret. These secrets are used by the OPSF and the local OP in the reverse order of the hash chain. In order to further improve security, the processing of proceeding to the next value in the hash chain, that is, the processing of OPSF and local OP discarding the current value and calculating the next value can follow several strategies. For example, the processing can be monthly, Execute in the form of days, sessions, etc.

4.4.2.6.5 Reuse AKA AV and secrets, and build a hash chain from AKA certificates In an example embodiment, OPSF may be in the same position as the network function on the MNO, where the network function may allow OPSF retrieval AKA verification vector (AV) from HLR (home location register) and AuC (verification center) of MNO. OPSF can retrieve AVs, and can select one of the AVs to challenge the OP associated with SCWS. By using this AV, the OPSF and the OP associated with the SCWS can establish a shared secret CK, and then the shared secret CK can be used as the long-term shared secret K of OpenID. In another example embodiment, instead of establishing a long-term secret, the OP and OPSF can establish a guarantee of a hash chain, the value of which is used as a shared secret between the OPSF and the OP associated with the SCWS. This processing can be a secure way to establish long-term shared secrets.

4.4.2.7 Highlight the benefits of the improvements This section aims to show the benefits that OP on SCWS can provide, especially the benefits provided in this improved variant.

4.4.2.7.1 Standard OpenID Figure 29 shows the standard OpenID protocol process. By using an existing web-based OpenID OP server (such as myopenid.com), standard OpenID protocol procedures can be used to access RP from mobile devices.

As shown in Figure 29, local traffic does not exist, and the only traffic offloaded from the air network is the discovery process and the association establishment process between RP and OP. Since the OP is a web service, all communications between the user/browser/device and the OP are all through the air interface.

The over-the-air communication is carried out at 965 and 975, where the communication is performed on the MNO/over-the-air network, and is usually used as a data traffic representing the load on the MNO network (for example, communication based on HTTP, IP).

At 970, traffic will appear on the fixed-line Internet, and the existing infrastructure can be used.

4.4.2.7.2 OpenID/GBA Figure 30 shows the business process of OpenID/GBA. This figure is taken from Figure 4-4 1.1 on page 13 of 3GPP TR 33.924 v9.1.0.

As shown in Figure 30, no matter what kind of association steps are carried out between the RP and the MNO, all communications are carried out over the air network. For example, the signals at 980 and 985 are transmitted by air transmission communication, which is carried out on the MNO/air network as data traffic and represents the load on the MNO network. Compared with the web-based OP, due to the need for additional steps for verification, the business volume in OpenID/GBA is even greater, and this will give the air data network and the back-end services required for GBA verification, namely BSF and The NAF subsystem creates a burden. Therefore, the air network traffic will increase, and the load on the network entity will increase.

4.4.2.7.3 Simplified association-based communication Figure 31 shows another example implementation of the agreement process based on the association-based communication mode. As shown in Figure 30, the air transport traffic can be offloaded to local equipment, thereby reducing the air interface network traffic. For example, by performing this process, the verification traffic can be allowed to be local, so that the verification traffic minimizes the burden on the air interface network or network service. In addition, the discovery and/or correlation business volume may not occur via the air interface network, and may be performed on a fixed-line public Internet.

At 990, the user can interface with a user interface such as a browser, and can access the RP, and can also use OpenID to request login. At 995, the RP and OP (MNO) can perform the process of discovering the OP server based on the OpenID identification. At 1000, the RP can transmit an association request to the OP. OP can generate a random unique association control A, and can calculate the key S. The OP may send an association response to the RP. The association response may include association control A and key S. The RP can store the key S and the associated control A.

At 1005, the RP can transmit a redirect to the browser. The redirection may redirect the browser to the OP, and may include the associated control A in the request parameter. OP can be associated with SCWS. The browser can receive redirects and can map to SCWS by performing a modified local DNS lookup. At 1010, the browser may transmit a local verification request to the OP. At 1015, verification can be done locally. For example, at 1020, the OP can verify the certificate based on the long-term shared secret key K and the associated control A. In addition, the OP can also calculate the key S, and can use the key S to calculate the signature. The signature can be used to sign the assertion message, and/or to sign parameters such as the return URL, identification, and/or mode.

At 1025, the OP may send a redirect to the browser instructing the browser to access the RP. The redirection may include the associated control A and the parameters with the signature. At 1030, the browser may transmit a request to the RP, which may include a signed assertion message from the OP. The RP can use the key S to verify the signature on the assertion message. Then, at 1035, the RP can allow the browser to display the login page and can provide the browser with access to the service.

In an example embodiment, it is assumed that there is a long-term shared key between the OP and the MNO associated with the SCWS.

As shown in Figure 31, 1010, 1015, 1020, and 1025 represent local communications that will not create a load on the MNO/air network. In addition, since these communications can be carried out inside the device, these communications can be carried out when there is no traffic in other (fixed line or non-MNO) networks.

990, 1005, 1030, and 1035 represent over-the-air communications, which can be used as data traffic (such as HTTP and IP-based communications) on the MNO/over-air network, and can represent the load on the MNO network.

995 and 1000 represent the business volume that can occur on fixed lines such as the fixed line Internet and can use the existing infrastructure. This communication does not increase the load on the MNO/air interface network.

Figure 32 shows another example implementation based on the protocol flow of the associated communication mode. As shown in Figure 32, the air transport traffic can be offloaded to local equipment, thereby reducing the air interface network traffic. For example, by performing this processing, the verification traffic can be allowed to be local, so that the verification traffic minimizes the burden of the air interface network or network services. In addition, the discovery and/or correlation business volume can be carried out via the air interface network, and can be carried out on a fixed-line public Internet.

At 1040, the user can interface with a user interface such as a browser, and can access the RP, and can also use OpenID to request login. At 1045, the browser may transmit an HTTP message to the RP, which may include the OpenID identification URL. At 1050, the RP and OP (MNO) can perform discovery of the OP server based on the OpenID identification. For example, the RP can send HTTP(S) to the OP to obtain the identification page message, and the OP can use the OpenID IDP server address to respond.

At 1055, the RP may transmit an association request to the OP. For example, the RP can send an HTTP(S) POST to the OP. OP can generate random unique association control A, and can calculate secret S. The OP can send an association response to the RP. For example, OP can send HTTP(S) POST to RP. The association response may include association control A and secret S. RP can store secret S and associated control A. The RP can create temporary usage and session identifiers.

At 1060, the RP can transmit a redirect to the browser. For example, the RP can send an HTTP redirect to the browser. The redirection can redirect the browser to the OP, and the association control A can be included in the request parameter. OP can be associated with SCWS. The browser can receive redirects and can map to SCWS by performing a modified local DNS lookup. At 1065, the browser may transmit a local verification request to the OP. For example, the browser may transmit to the OP the HTTP obtain http://op.org/server including the parameters included in the redirection.

At 1070, verification can be done locally. The browser can present the user with a verification page requesting the user to verify the certificate. The user can enter an authentication certificate that includes a user name and password. At 1075, the OP can verify the certificate based on the long-term shared secret key K and the associated control A. In addition, the OP can also calculate the secret S, and can use the secret S to calculate the signature. The signature can be used to sign the assertion message, and/or to sign parameters such as the return URL, identification, and/or mode.

At 1080, the OP can send a redirect to the browser instructing the browser to access the RP. For example, the OP can send an HTTP redirect to the RP. The HTTP redirection may include associated control A and parameters with signatures. At 1085, the browser may transmit a request to the RP, which may include a signed assertion message from the OP and the parameters provided by the OP. For example, the browser can send HTTP to RP to get http://rp.org/return. The RP can use the secret S to verify the signature on the assertion message. Then, at 1090, the RP can allow the browser to display the login page and can provide the browser with access to the service. For example, the RP can instruct the browser to display an HTML page. At 1095, the browser informs the user to log in on the RP.

In an example embodiment, it is assumed that there is a long-term shared key between the OP and the MNO associated with the SCWS.

As shown in Figure 32, 1040, 1065, 1070, 1080, and 1095 represent local communications that will not generate load on the MNO/air network. In addition, since these communications can be carried out inside the device, these communications can be carried out without traffic on other (fixed line or non-MNO) networks.

1045, 1005, 1085, and 1090 represent over-the-air communications, which can be used as data traffic (such as HTTP and IP-based communications) on the MNO/over-the-air network, and can represent the load on the MNO network.

1050 and 1055 represent the business volume that can occur on fixed lines such as the fixed line Internet and can use the existing infrastructure. This communication does not increase the load on the MNO/air interface network.

Figure 33 shows another example implementation of the protocol flow based on the associated communication mode. As shown in Figure 33, the air transport traffic can be offloaded to local equipment, thereby reducing the air interface network traffic. For example, by performing this process, the verification traffic can be allowed to be local, so that the verification traffic minimizes the burden of the air interface network or network services. In addition, the discovery and/or correlation business volume can be carried out via the air interface network, and can be carried out on a fixed-line public Internet.

At 1100, the user can interface with a user interface such as a browser, and can access the RP, and can also use OpenID to request login. At 1105, the browser may transmit to the RP an HTTP message that may contain an OpenID identification URL. At 1110, RP and OP (MNO) can perform discovery of OP server based on OpenID identification. For example, the RP can send HTTP(S) to the OP to obtain the identification page message, and the OP can use the OpenID IDP server address to respond.

At 1115, the RP may transmit an association request to the OP. For example, the RP can send an HTTP(S) POST to the OP. OP can generate random unique association control A, and can calculate secret S. The OP can send an association response to the RP. For example, OP can send HTTP(S) POST to RP. The association response may include association control A and secret S. RP can store secret S and associated control A. The RP can create temporary usage and session identifiers.

At 1120, the RP can transmit a redirect to the browser. For example, the RP can send an HTTP redirect to the browser. The redirection can redirect the browser to the OP, and the association control A can be included in the request parameter. OP can be associated with SCWS. The browser can receive redirects and can map to SCWS by performing a modified local DNS lookup. At 1125, the browser can transmit a local verification request to the OP. For example, the browser may transmit to the OP the HTTP acquisition http://op.org/server that may include the parameters included in the redirection.

At 1130, verification can be done locally. The browser can present the user with a verification page requesting the user to verify the certificate. The user can enter an authentication certificate that includes a user name and password. At 1135, the OP can verify the certificate based on the long-term shared secret key K and the associated control A. In addition, the OP can also calculate the secret S, and can use the secret S to calculate the signature. The signature can be used to sign the assertion message, and/or to sign parameters such as the return URL, identification, and/or mode.

At 1140, the OP may send a redirect to the browser instructing the browser to access the RP. For example, the OP can send an HTTP redirect to the RP. The HTTP redirection may include associated control A and parameters with signatures. At 1145, the browser may transmit a request to the RP, which may include a signed assertion message from the OP and the parameters provided by the OP. For example, the browser can send HTTP to RP to get http://rp.org/return. The RP can use the secret S to verify the signature on the assertion message. Then, at 1150, the RP can allow the browser to display the login page and can provide the browser with access to the service. For example, the RP can instruct the browser to display an HTML page. At 1155, the browser informs the user to log in on the RP.

In an example embodiment, it is assumed that there is a long-term shared key between the OP and the MNO associated with the SCWS.

As shown in Figure 33, 1100, 1125, 1130, 1140, and 1155 represent local communications that will not cause a burden on the MNO/air network. In addition, because these communications can be carried out inside the device, these communications can be carried out without traffic in other (fixed line or non-MNO) networks.

1105, 1120, 1145, and 1150 represent over-the-air communications, which can be used as data traffic (such as HTTP, IP-based communications) on the MNO/over-air network, and can represent the load on the MNO network.

1110 and 1115 represent the business volume that can occur on fixed lines such as the fixed line Internet and can use the existing infrastructure. This communication does not increase the load on the MNO/air interface network.

Figure 34 shows another example implementation of the agreement process for stateless mode.

1160: The user can access the RP website. In order to log in using OpenID, he enters his OpenID identifier, such as http://op.org/identity.

1165: The browser can send an HTTP message containing the OpenID identifier to the RP website.

1170: RP can use HTTP/HTML-based OpenID'simple' discovery processing, and get in touch with OP-agg via the public Internet, so as to retrieve the OpenID identifier on the identification page, such as HTTP to get http://op. org/identity.

1175: OP-agg can receive requests and respond with HTML pages containing OPSF Internet addresses. For example, OP-agg can respond by including the following address: <link rel="openid.server" href=http://op.org/server.cgi>.

OPSF can operate the RP like a standard OpenID identification provider web service. For example, OPSF can verify the signature on the assertion message (issued by the local OP) at the request of the RP. According to requirements, OPSF must be reachable via the public Internet, so it is assumed that it has a DNS name, such as op.org, which can be reached via http://op.org. Since the outside world does not know the IP address of the smart card, the indirectness of OPOP-agg and OPSF can be used for communication.

The address of OPSF can be different from the address of OP-agg.

1180: RP can receive the OPSF address and create temporary usage and session identifiers, for example nouce = 123123, session = User. RP can compile the return_to parameter that tells OP to which URL the browser should be redirected after user authentication. The RP can issue an HTTP redirect to redirect the browser to the OP server address, where the redirect includes the following parameters: openid.mode=checkid_setup,openid.identity=http://op.org/identity, openid.return_to=http://rp.org/return.cgi?session=User&nonce=1231231185: The browser can receive the redirection, and can open the connection to the URL specified in the RP in the redirection message. 1190: By means of Modify the DNS lookup table that maps the OPSF URL to the SCWS local IP address, for example, by using the host file with the entry http://op.org==127.0.0.1, the browser can be redirected to the SCWS related Connect with the local OP and issue an HTTP request containing the parameters at 765.

A modified local DNS lookup table can be used on the device to make the device think that the URL http://op.org is located at the local IP address of SCWS. The browser can open the connection with the SCWS/local OP instead of connecting to the OPSF (the OPSF can be reached via the public Internet at the URL http://op.org).

1195: By performing the following processing, you can ensure that the verification business volume is kept locally. These steps are not required or prescribed by the OpenID protocol specification: a. The OP associated with SCWS can display the local verification page b. The user can enter his verification Credentials, such as user name and password c. The OP associated with SCWS can verify the certificate 1200: the OP associated with SCWS can create a unique random association control A. By using the function f, S=f(A, K) can be used to calculate the signature secret of the assertion message, where the f should be one-way, so that the knowledge of A will not reveal any knowledge of K. In an exemplary embodiment, even if S and A are shown, that is, S and A are given, f does not show any knowledge about K. In addition, for the function g, in terms of calculation, K=g (S, K) The processing of calculation is not feasible.

Since A may be presented to the RP as part of the parameters in the redirect message, it can be assumed that the RP will not gain knowledge of S in the stateless mode of the OpenID agreement process. The association control A can be included in the redirect message. In addition, it can be assumed that a signed message m signed with S will not show any information about K to the signature verifier (because it uses a symmetric key signature, the signature verifier always needs to have S to verify the signature. Therefore, we do not require that the signature does not show S).

In an example embodiment, the association control may be specified as a string of 255 characters or less, and may only include ASCII characters in the closed interval 33-126 (printable non-blank characters Yuan).

The secret used by the OPSF to verify the signature and the secret used by the OP associated with the SCWS to generate the signature may be the same. The freshness of the signature can be ensured by the temporary usage of the RP inserted in the next step, and the temporary usage of the RP must be part of the signature. The OpenID specification maintains a tacit understanding of the freshness of the signature secret itself. The OP is responsible for ensuring the strength of the secret password, maintaining its secrecy, and ensuring its freshness when needed. OPSF and OP associated with SCWS can last for a limited life or use count of signature secrets for this purpose.

The local OP with the toolbox enabled can bypass SCWS and use CAT to actively communicate with the mobile phone. The message can be formatted in accordance with a standard OTA (for example, OTA for sending OPSF via SMS-PP bearer). However, this processing may require OPSF to communicate with the card via the MNO's OTA system. In another embodiment, the BIP gateway can capture the payload of the toolbox message, and the phone can send it to OPSF using TCP/IP. This may require the message to be sent via the MNO's OTA server. In addition, SCWS claims to only use BIP if the card does not have an IP address and does not support TCP/IP. Therefore, what is expected is to use TCP/IP and use SCWS to send.

d. Other options are also applicable. These options may generate a shared secret between OP and OPSF associated with SCWS. The feasibility of this type of method needs to be studied in the next step.

1205: The OP associated with the SCWS can calculate the signature on the following parameters: return_to, identification, and mode.

1210: The OP associated with the SCWS can send an HTTP redirect message to the browser, where the message contains the parameters received from the RP at 1180. In addition, the following items can be included: · a series of signed parameters in the openid.signed parameter · association control in the openid.assoc_handle parameter · signature (base64 encoding) in the openid.sig parameter.

At 1212, the message can be used to redirect the browser to the return_to URL at the RP.

1215: The browser can redirect the user to the return_to URL on the RP.

1220: RP can receive a signed assertion message, and join the verification process with OPSF in direct communication via the public Internet and based on HTTP(S).

1225: The RP can publish an HTTP POST message that contains the parameters received at 795 from the OP associated with the SCWS. The HTTP POST message may include the associated control A generated by the OP associated with the SCWS.

1230: OPSF can extract A from the parameter list, and can use the same function f with the same input as the OP associated with SCWS, that is, OPSF calculates f(A,K)=S, and uses S as a shared secret to verify slaves The signature on the data received by the OP associated with the SCWS.

1235: If the signature verification is successful, OPSF can return is_valid: true.

1240: For RP, users can now be identified as http://op.org/identity.

1245: The browser can display the HTML page of the RP.

1250: Users can log in as http://op.org/identity on the RP.

As shown in Figure 34, 1160, 1190, 1212, 1215, and 1250 represent local communications that will not generate load on the MNO/air network. In addition, since these communications can be carried out inside the device, these communications can be carried out without any traffic generated by other (fixed line or non-MNO) networks.

1165, 1180, 1220, and 1245 represent over-the-air communications, which can be used as data traffic (such as HTTP and IP-based communications) on the MNO/over-air network, and can represent the load on the MNO network.

1170, 1175, 1225, and 1235 represent the business volume that may appear on fixed lines such as the fixed line Internet and can use the existing infrastructure. This communication does not increase the load on the MNO/air interface network.

4.5 Schemes and Applications This section discusses additional implementations of the methods and agreements described in the previous chapters. For example, this section expands the above summary by explicitly listing some different solutions, thereby expanding the scope of usage examples and solutions.

The term "smart card" (SC) can be used to describe any type of integrated circuit card (IC) that can provide safe operating facilities. For a specific use in mobile devices that can use SC to maintain network authentication certificates (such as GSM/UMTS), the use can be called UICC. The Smart Card Web Server (SCWS) application defined by the Open Mobile Alliance (OMA) is not limited to use in UICC, and can be conceived to be used on any other smart card. Therefore, the implementation described here can be easily extended to a general SC, for example, the implementation of user authentication is implemented by using OpenID in combination with the OP entity residing inside the secure element.

In addition, any other security environment that can provide a similar interface and protected operation for security-critical methods can be the implementation target of the above-mentioned embodiment.

4.5.1 Stakeholder Model 4.5.1.1 MNO Model In an example embodiment, the MNO can act as a comprehensive identity provider. MNO can host OP-gg and OPSF discovery and association point entities as web services, and can also provide OP application and user identification to UICC.

4.5.1.2 Third-party OP and MNO In an example implementation, it is assumed that the user already has an existing OpenID identifier registered with the third-party OP, such as myopenid.com. This OP may be referred to as a third-party OP (3OP).

The MNO can no longer act as the user's service provider, but can transmit data and allow 3OP to install the OP application on the UICC and associate it with the SCWS application. 3OP may have to establish a business relationship with MNO. The MNO can also license 3OP remote management rights for OP applications. The MNO can charge 3OP for the service and generate revenue. Further details are described below on the use of cards compatible with the Global Platform (GP).

4.5.1.3 Non-MNO, non-action An example implementation can be used in a non-action plan. For example, OpenID identifies that the supplier can use a general SC such as an SC issued by a bank to install the OP application. For example, by performing this process, a bank card hosting an NFC bill application and an OpenID verification OP application can be used. It can be assumed that the type of device that will communicate with the SC is not previously known. However, if the current SC specification is given, a TCP/IP connection via USB can be established with the SC, where, for example, the connection is established via a local link, SC reader, NFC communication interface, etc. . The SC can be equipped with SCWS that can be reached by external terminals.

4.5.2 Separated terminal solution This section describes the implementation, in which the device containing the SC hosting the SCWS and OP applications may not be the same device as the device that wants to access the RP website. In these embodiments, the SC can be used as an external authentication token. These separate terminal implementations can be combined with the different stakeholder models described here.

4.5.2.1 Separated terminal with UICC in the mobile terminal Figure 34 shows an example implementation of the protocol flow for the separated terminal.

In an example embodiment, the user may have a mobile device equipped with UICC with SCWS and OP installed on it. The user can use a device different from the mobile device to access the desired web page on the RP, where the device is called a browsing agent (BA). When the BA accesses the RP and submits the OpenID identifier for login, the RP can redirect the BA to the OP, which is the URL of the OP. The HTTP redirect message from RP to BA may include the necessary information required by the OP application to calculate the signature on the assertion message. The content of the message can be delivered to the mobile device and the OP on the SC. The OP can display a verification page to the user on the mobile device, and the user will authorize and verify the login. The OP can sign the assertion message. Then, the signed assertion message can be sent back to the RP, and this processing is usually done by the RA. Then, the RP can verify the signature, and the user/BA will log on to the RP.

In another example implementation that includes communication between the BA and the mobile device, for example, a local link can be established between the two entities by means of Bluetooth or WLAN, and the device can be registered as hosting the OP equipment. Then, the browser can send a redirection to the mobile device via the local link, and the mobile device can forward the redirection to the OP/SCWS. The OP can then request its certificate from the user. The user can use any method (such as password, PIN, biometric) implemented for user authentication on his mobile device to authenticate to the OP. The OP can sign the assertion message and forward it to the BA via the local link. Then, BA can use this message to verify with RP. In this scheme, BA acts as the MITM between the RP and the mobile device. Since the user may know that he initiated the OpenID session, he can detect an unauthorized request on his mobile device.

As shown in Figure 35, at 1255, BA can access RP and can request to log in using OpenID. At 1260, the RP can receive the login request, and can initiate the process of discovering the OP server with the OP (MNO) based on the OpenID identification. In 1265, the RP can send an association request to the OP (MNO), and the OP (MNO) can send an association response. The association response may include association control A and key S. At 1270, the RP may redirect the browser to the OP associated with SCWS. The RP request may include A in the request message. BA and the user can establish a local link.

At 1275, the BA may transmit a local verification request to the OP associated with the SCWS. At 1280, a local authentication process can be established between the OP associated with the SCWS and the user/mobile device.

At 1285, the OP associated with the SCWS can redirect the BA to the RP. The orientation may include associated control, and may include signed parameters. At 1290, BA can transmit a request to RP. The request may include a signed assertion message from the OP associated with the SCWS. At 1295, the RP can allow the BA to display the login page.

4.5.2.2 Separate terminal with smart card in external card reader/NFC In an example implementation regarding non-mobile SC deployment, the SC can be issued by a web-based OP or another third party (eg, a bank). Steps similar to those described in the mobile separation terminal example can be applied here. Then, the local link can be established by means of an external smart card reader or by means of an NFC (Near Field Communication) terminal attached to the computer. The interface can support HTTP messages, and the HTTP messages can be sent to OP/SCWS implemented on the SC.

4.6 Trust Relationship in OpenID 4.6.1 Existing Trust Relationship in OpenID Figure 35 shows the trust relationship in OpenID.

4.4.6.1.1 Step 1 of the OpenID protocol is shown in Figure 36. At 1300, the user accesses the RP website that allows him to access the service after logging in. If he decides to log in with OpenID, then he will be redirected to his OP. The user must trust the RP that has performed the redirection properly and will not encounter phishing attacks. In addition, the user also trusts the RP for him to receive the service after logging in, and (for privacy reasons) believes that the RP will not exhibit user interaction with the RP to third parties.

The OpenID\ identifier provided by the user enters the RP domain and serves as a means for finding the correct OP for the RP and an identifier for the interaction between the RP and the user. The RP only learns the identifier, and by parsing it, the RP knows the address of the OP.

According to the OpenID specification, discovery is a process in which the relying party uses identifiers to find ("discover") necessary information for initiating a request. OpenID authentication has three ways to perform discovery.

If the recognition word is XRI, [XRI_Resolution (parse)_2.0] (Wachob, G., Reed, D., ChasenL, Tan, W. and S. Churchill (Churchill), "Extensible Resource Identifier (XRI) Resolution V2.0-Committee Draft 02 (XRI) Resolution V2.0-Committee Draft 02"), then it will generate a XRDS files.

It should be noted that the relying party can use a CRI proxy parser, such as the parser provided by XDI.org at http://www.xri.net. Doing so will eliminate the need for the RP to perform XRI resolution locally.

If it is a URL, you should first try the Yadis protocol (Miller, J., "Yadis Specification 1.0") [Yadis]. If it succeeds, the result is also an XRDS file. If the Yadis protocol fails and no valid XRDS file is retrieved, or the service element (OpenID service element) is not found in the XRDS file, the URL is retrieved, and HTML-based discovery processing (HTML-based discovery) should be tried.

It is worth mentioning that the discovery step may provide an entry point for the attacker. For example, an attacker can use a DNS spoofing attack to try to directly attack the RP in order to subvert the discovery step by redirecting the RP to a counterfeit OP controlled by the attacker instead of the real OP. Although the host is another host, the RP still considers it to be the user's real OP because the function variable has the same name. In contrast to what seems to be outside the scope of the OpenID specification, this shortcoming exists in the design of the OpenID protocol and protection. This threat has been captured in the trusted OpenID file, and hints about some possible mitigation methods are discussed in it.

4.6.1.2 Step 2 of the OpenID protocol is shown in Figure 36. In 1305, once the RP finds a user OP, the RP will establish an association with the OP, thereby allowing it to communicate securely through the shared key protection information. The ID will leave the RP domain and enter the OP domain. Although the OP will determine that he actually hosts the user ID with the specified identifier, the OP will also know which site the user is currently trying to access. If the establishment of a shared secret is insecure (the standard only defines Diffie-Hellman that can be attacked by MITM), then the OP cannot ensure that the RP associated with it is the same as the RP that the user sees in his browser.

Users believe that OP will not use the collected information (such as the sites the user has visited and the frequency of access) to build user profiles. In addition, the user believes that OP will not accept association requests from sites that the user has not visited (for example, an attacker's hidden login attempts to unknown sites).

RP believes that OP will actually authenticate users and provide RP with reliable user identification information. In the payment scheme that can use RP to collect RP service fees, RP also believes that OP will provide the necessary means to charge. For example, if the MNO acts as the OP in OpenID/GBA, then the RP will recognize the OP as being run by an MNO that allows the user to charge the user's phone bill. Then, RP believes that MNO-OP will implement the fee.

Since arbitrary OPs can be constructed and set up (for example, those who do not authenticate users and may be abused by spammers, thereby providing them with a simple mechanism to create OPs that spamming general accounts to forums, blogs, etc.), Therefore, the RP may wish to restrict access to the restricted OP set. The OpenID protocol does not specify this OP white/blacklist method, but it can be implemented on the RP to defend against malignant OPs.

4.4.6.1.3 Step 3 of the OpenID protocol is shown in Figure 36. At 1310, the user is redirected to the OP page and performs authentication. The certificate will leave the user domain and enter the OP domain. Therefore, the interface between the user and the OP must be protected from eavesdropping. In a typical scenario, by using HTTPS over HTTP, very little protection can be provided. However, considering that the user will not check the entire certificate chain, this process does not protect against forged OPs with valid certificates.

The user believes that the OP will not abuse the certificate, that is, the user will not think that the OP is malicious. A malicious OP can easily access all services on behalf of its registered users. Because OP's damage will cause the user's certificate to be immediately exposed to all web services, and will also cause damage to the user's identity, large OPs with a large user base have become the main targets of attackers.

As a result of the verification phase, the user's browser is redirected to the RP by the assertion from the OP, where the OP is the OP that the user authenticated in order to use his identifier.

Damage to user IDs is particularly worrying, because OpenID IDs are usually used not only as a means to simplify access to different web services, but also as a way to access multiple sites. Means to build prestige. Therefore, once the identifier is abused, it is difficult to restore the well-received logo.

4.6.1.4 Step 4 of the OpenID protocol is shown in Figure 36. At 1315, the user is redirected to the RP by using the assertion from the OP. RP obtains enough information to trust the user (and OP) who has performed authentication and believes that the user knows the secret associated with the identifier. RP will not obtain any information or guarantees about the authentication method used between the user and the OP.

4.6.2 Implementation of the trust relationship in the mobile local OP 4.6.2.1 Overview Figure 37 shows an example implementation of the trust relationship with the local OP. In an example embodiment, if the OP becomes the local entity of the user, then the OP and the user domain can be considered as a single domain identified by a dashed line 1340.

At 1330, the user can perform authentication, which can reduce the network load of the authentication process. Users can share their private data with local entities that provide them with more control. If you want to build an association, then the RP may need to contact the local OP directly. This connection is not necessary for the operation of the OpenID protocol. The communication between the RP and the OP can also be performed by means of indirect communication, that is, by means of redirection using the user's browser.

However, the degree of trust the RP has in the local OP depends on the amount of reliable information that can be derived from the assertions from the OP. Usually, RP will accept every OP, but in applications that require security, RP can restrict access to a group of OPs or OPs with specified attributes. Then, the OP must provide the RP with information about these attributes. Such information can be transmitted via indirect communication and from the local OP via a direct channel (such as an associated channel) or via an attachment in a redirect message. In another example embodiment, such an assertion about OP attributes (for example issued by a trusted MNO) may originate from TTP.

At 1325, the RP can continue processing as described in 1305 (that is, the last paragraph in section 4.4.6.1.1). At 1335, the UE can continue processing as described in 1315 (ie the last paragraph in section 4.4.6.1.3). At 1320, the UE may continue to perform processing as described in 1300 (ie, the first paragraph in section 4.6.1). But in this solution, as described in the first paragraph of this section, users can use multiple methods to perform local authentication without interacting on the Internet.

4.6.2.2 Trust relationship with MNO Figure 38 shows an example implementation of the trust relationship with the local OP. As shown in Figure 38, since the MNO runs on a smart card, it can have direct contact with the OP. RP can have an indirect connection with MNO, but they do not need to establish such a relationship in the OpenID agreement of compatible standards. RP may need to establish contact with OP. For several reasons, such as with the help of the MNO's bill processing, the enhanced trust level of the logo, etc., the RP may wish to obtain additional information about the user's logo. This degree of trust can be based on the degree of trust the RP has in the MNO.

The trust level can be transferred from the MNO to the RP via the OP. In an example embodiment, it is assumed that the RP has a certain level of trust in the MNO (for example, through the reputation of the MNO, similar to out-of-band processing of registration, service, and contractual agreements). In addition, it can be assumed that the RP can communicate with the entity of the MNO when needed, and the communication can be protected by appropriate means (for example, IPSEC, HTTPS). In addition, it can be assumed that the smart card and the MNO (the server) may have the means to communicate in different ways according to needs.

The MNO can be included in the discovery process, which allows the RP to establish a direct communication channel (association) with the OP by providing the RP with the current address of the OP. This process may expose the service accessed by the user to the MNO, thereby allowing it to generate the user's tracking profile. If indirect processing via the user's browser is used, the discovery processing may not be necessary.

If the MNO is included in the OpenID protocol, then the MNO can have several functions.

4.6.2.2.1 The MNO acting as the (direct) trustworthiness supplier of the OP means that the MNO can be directly included in the trust-building process between the OP and the RP. This direct inclusion can immediately ensure to the RP that the OP asserted flag is registered on the MNO. If the MNO acts as the OPs direct trust provider, then several methods can be used between the OP, the RP and the appropriate service or MNOs existing service combination.

a) Example implementation for direct connection between RP and MNO In one example, the MNO may provide a central service that can be reached by the RP. RP cannot be directly associated with OP, but is associated via MNO. The user's browser can be redirected to the local OP. After verification, the OP can send a message to the MNO stating that the verification was successful. The message can be signed with a key issued by the MNO to the smart card. The MNO can verify the signature, add its own signature, and then forward the message to the RP. The RP can receive two messages: an assertion from the OP that indicates that the user has been verified, and a message from the MNO that indicates that the valid OP has performed verification. These messages can be combined in a single message from the MNO so that the message contains an assertion that the verification was performed successfully.

b) Example implementation of indirect communication through the OP In an example implementation, the MNO may not wish to provide such external services to the RP; the communication may be transmitted indirectly through the OP. The degree of trust can be obtained directly from the statement from the MNO, and the communication between the RP and the MNO can be performed via the OP. RP can use additional fields containing temporary usage to redirect the browser to the browser. The OP can then extract the field from the request and forward it to the MNO. The MNO can sign it, and then the signed response can be included in the assertion response from the OP to the RP. Since the MNO may sign the temporary usage received from the known OP, this process also has the additional benefit of hiding the accessed service from the MNO. If the user's real identity is revealed to the RP, the temporary usage can be used as a session identifier, and then the session identifier will identify the user.

c) Example implementation for the combination method In an example implementation, the communication types can be combined: when the user wants to log in to the RP using OpenID, the RP will contact the MNO, and in the association phase of the OpenID protocol The MNO establishes a shared secret. The RP can then expect the OP to include the secret in the assertion message when the verification is completed. For the MNO, it can choose to use the newly generated signature key to provide a signed statement for the RP, where the signature key is generated in the MNO network smart card using the GBA protocol. With the help of the GBA agreement, the MNO can establish a secret with the smart card, and the two entities can sign the same statement. The OP can then include this signed statement in the assertion message sent to the RP. The RP can compare the signed statement from the MNO with the statement in the assertion message. The signed statement (or ticket) from the MNO can be generated as needed, or can be generated when the device first authenticates with the MNO and then saves it locally. When the device subsequently attempts to connect to the RP, the previously stored signed statement can be delivered to the RP.

The OpenID protocol can allow the RP to decide whether to establish an association with the OP (thereby establishing a shared secret) or use a stateless protocol process. OP can support all these two working modes. If association is used, a shared secret can be established for each RP and each OP. This means that the pre-shared statement between the MNO and the OP on the user's device must contain this latest secret between the RP and the MNO. The signing key can be pre-shared between the device-OP and the MNO (for example, with GBA), and then both the MNO and OP will use the signing key to sign the secret/temporary usage on a session-by-session basis, where the temporary Usage can be determined between RP and MNO and forwarded by MNO to OP.

4.6.2.2.2 The MNO acting as the (indirect) trustworthiness supplier of the OP In an example embodiment, the MNO may also act as the indirect trustworthiness supplier of the OP. Similarly, the MNO need not be involved in the communication process during the OpenID verification. In another example embodiment, the MNO can issue a certificate and key material to the smart card, and then the certificate and key material can be used to sign the field in the assertion message from OP to RP. After that, the RP can verify to ensure that the OP originates from the signature and certificate of a trusted MNO. The certificate verification can be performed without further involvement of the MNO, for example, performed by the TTP.

4.6.2.2.3 The MNO acting as the trustworthiness and software supplier of the OP In an exemplary embodiment, the MNO can remotely download and manage the OP package software on the smart card. For some solutions, such as Smart Card Web Server (SCWS), the management can be done between SCWS and MNO by means of HTTPS management sessions. The MNO can directly include the secret (such as a certificate, such as a certified key) used to transfer trust in the statement issued by the OP. Then, the RP can derive the degree of trust from the authenticated secret. The MNO can even include a set of secrets in the OP software for use in combination with different user identifiers. RP can derive the degree of trust from the OP software certificate issued by the MNO.

In an example embodiment, the GBA may allow the MNO to establish a shared secret with the OP on the device. Since the secret may not be known to the RP, it is possible that the RP has established a secure communication channel with the MNO. Therefore, the MNO can forward this secret (derived by GBA) to the RP in the associated channel so that the RP can independently verify the OP Assertion statement, where the statement is signed with a key derived from GBA.

In another embodiment, after the GBA secret is established between the MNO and the OP, the MNO can request a temporary usage and RP ID from the RP, and then use the temporary usage and RP ID to obtain the GBA secret between it and the OP Establish further secrets only for this particular RP and this particular session. For example, by performing this process, it is possible to avoid reusing the GBA-derived secret for association with the RP, and avoid exposing the GBA-derived secret to the RP. Then, the MNO can forward this RP and the session-specific secret to the RP. As in the first option, the RP can then verify the OP signature on the assertion based on the session-specific key.

4.7 Implementation on the global platform smart card GP SC can host multiple so-called security domains (SD), where the security domain enables each SD to represent a stakeholder, and can store and install keys for the stakeholder And personalized applications. The main SD may be an issuer SD belonging to the card issuer. SD can be organized in a hierarchical structure, and SD can have different permissions to manage content within its hierarchy. The issuer SD can have authorized management (AM) permissions, which means it has autonomous control of the card, and can install and delete SD in its hierarchy. Other SDs are only given to AM when they reside on a separate level on the card. If the SD is at the same level, then the SD can get a delegated management (DM) permission, where the DM permission allows the SD to manage the content of the card in its sub-level. All operations performed by the SD can be authorized by the publisher with a token, where the token is presented to the publisher SD by the DM SD and checked by the publisher SD.

Applications of GP SC residing in different SDs can use the concept of trusted path (TP) to communicate. TP may be a permission that must be assigned to applications, which allows these applications to exchange commands with the help of GP's open API. Otherwise, the application is separated on the GP SC.

Figure 39 shows an example implementation of the SD hierarchy with the issuer SD.

Figure 40 shows an example implementation of the SD hierarchy with DM.

4.7.2 Implementation options of the implementation mode Depending on how SCWS can be implemented on the SC, different stakeholder models can be enabled.

4.7.2.1 Implementation of SCWS as a GP application Figure 41 shows an example implementation of SCWS as a GP application. In an example embodiment, SCWS can be implemented as a GP application in a specific SD owned by the SC publisher, and can support MNO models, third-party OP models, and non-MNO models. We assume that OP's application logic can reside in different SDs as different applications, and thus can be owned and managed by entities different from those that own SCWS applications and domains. Both of these applications can use trusted path capabilities to communicate. The third party and the card issuer must agree on the business contacts used to implement the program, such as licensing the correct permissions to SD and applications.

The application provider (third-party OP) SD can be equipped with DM permissions and can manage OP applications. SCWS management can be performed by the card issuer by means of the SCWS management agent SD, where the SD usually supports OTA management capabilities, such as RAM by means of HTTM. If APSD also supports the SCP80 protocol, then the application and content can be OTA managed by a third party using DM tokens.

4.7.2.2 Example 2: SCWS implemented in the card's runtime environment (RTE) Figure 42 shows an example implementation of SCWS implemented in the card's runtime environment. In an example embodiment, since access to the SCWS will not be exposed through the GP framework, the SCWS can be implemented by the SC manufacturer in the RTE of the card, and third-party applications cannot communicate with the SCWS. Therefore, the stakeholder model of a third-party OP cannot be supported. However, MNO model and non-action model are supported.

4.8 OP implementation on platforms other than SCWS 4.8.1 Use Java Card as a platform. Java Runtime Environment can be installed on Java Card, which allows interoperability of SIM card applications across different SIM cards (and manufacturers) .

In an example embodiment, the Java Card platform may be used to allow the MNO to create and deploy an OTA applet to the Java Card.

4.4.8 Implementation using embedded secure components As described above, the embedded local OP application in a device that belongs to the user or is controlled by the user to a certain degree can be implemented in the smart card. With the increasing expansion of embedded security solutions in mobile devices, there may be multiple different operating environments that provide different security attributes. The OP design on the smart card can be extended to other (embedded) secure components, which can allow secure code execution and secure storage of certificates. In addition, the operating environment may need to provide communication channels to the external environment, especially for OP-user authentication interaction, OP-browser communication (based on HTTP(s)), and OP-RP association and assertion messages (also based on HTTP (s)) channel.

In an example embodiment, what is used may be an existing security environment (such as a trusted zone, etc.) that can be used in the mobile phone to provide a trusted operating environment (TEE) for OP software on the device.

Since the smart card can be regarded as under the control of the MNO, the smart card can represent the key resource of the MNO. In the process of implementing the OP on the embedded operating environment, especially in the implementation in which the MNO and the local OP establish a shared secret, the MNO may need a device to verify the security attributes of the operating environment. The device may include, but is not limited to: · the ability to perform integrity measurements of the operating environment · reporting the communication of integrity measurements · the (integrity) verification of the equipment operating environment is required to transfer it to a trusted operating environment ( TEE)·Used for downloading/provisioning protocol/processing from the MNO network to the OP in the embedded TEE·TEEs communication capabilities; the OP must be able to communicate with the RP and the user (and the MNO). In some example implementations (On the smart card or inside the TEE), the MNO can obtain additional information about the user's behavior (such as RP accessed by the user, login frequency, user behavior, etc.). In programs that require privacy, such as in a corporate environment, the company hopes to hide user behavior from the MNO, and it is more beneficial that it does not contain the MNO to a large extent.

In another example embodiment, if an embedded security feature is used to perform a local OP implementation, the MNO cannot be included in the OpenID process. Doing so can allow users to autonomously create, manage and maintain OP devices inside the TEE of their equipment. In this solution, the OP cannot share secrets with the MNO, because it can be assumed that the MNO may lack trust in the OP implementation. However, there may be a local trust relationship between the user and his device. The user can trust that the OP implementation will not disclose any private personal information to a third party. Since the MNO cannot issue an assertion about the implementation of the OP, the increase in privacy may be at the cost of a decrease in OP trust from the RP.

4.8.3 Concept integration from trusted OpenID innovation In an example implementation, OP can be implemented on a smart card. Assessment of equipment integrity can be included and introduce requirements for equipment measurement and reporting integrity. For equipment that can support the integrity verification/reporting of the MNO, the MNO can first check the integrity of the equipment and the safety/runtime environment of the OP. The MNO can then trigger the (remote) software installer for the OP software. In addition, the MNO can equip OP applications with device reference values. The OP can then check the measurement reported during the OpenID verification process against these reference values, and if it passes the integrity check successfully, the verification can be allowed.

Although the features and elements in a specific combination are described above, those of ordinary skill in the art will understand that each feature can be used alone or in any combination with other features and elements. In addition, the method described here can be implemented in a computer program, software, or firmware introduced into a computer readable medium and run by the computer or processor. Examples of computer-readable media include electrical signals (transmitted via wired or wireless connections) and computer-readable media. Examples of computer-readable media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor memory devices, internal hard drives, and removable disks Such as magnetic media, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVD). The processor associated with the software can be used to implement the radio frequency transceiver used in the WTRU, UE, terminal, base station, RNC, or any host computer.

<p>100 Communication Systems</p><p>102, 102a, 102b, 102c, 102d Wireless transmit/receive unit (WTRU)</p><p>104 Radio Access Network (RAN)</p><p>106 Core network</p><p>108 Public Switched Telephone Network (PSTN)</p><p>110 Internet</p><p>112 Other networks</p><p>114a, 114b base station</p><p>116 Air interface</p><p>118 processor</p><p>120 transceiver</p><p>122 Transmitting/receiving parts</p><p>124 Speaker/microphone</p><p>126 Digital keyboard</p><p>128 Display/Touchpad</p><p>130 Non-removable memory</p><p>132 Removable memory</p><p>134 power supply</p><p>136 Global Positioning System (GPS) Chipset</p><p>138 Peripherals</p><p>140a, 140b, 140c eNode-B </p><p>142 Mobility Management Gateway (MME)</p><p>144 Service gateway</p><p>146 Packet Data Network (PDN) Gateway</p><p>Management of AM authorization</p><p>assoc_handle association_control code</p><p>BSF bootstrap server function</p><p>DM entrusted management</p><p>HSS Home User Server</p><p>HTTP, HTTPS communication protocol</p><p>GET</p><p>GP Global Platform</p><p>LAP local assertion provider</p><p>MNO mobile network provider</p><p>NAF network address function</p><p>OP supplier</p><p>OpenID Open ID</p><p>OPSF server function</p><p>POST pass</p><p>RAM random access memory</p><p>return_to return_to</p><p>RP Relying Party</p><p>RTE runtime environment</p><p>S1, Ub, X2, Zn interface</p><p>SCWS Smart Card Network Server</p><p>SIM user identification module</p><p>SSO single sign-on</p><p>UE user device</p><p>UICC Universal Integrated Circuit Card</p><p>web network</p>

A more detailed understanding can be obtained from the following description given with the aid of examples in conjunction with the accompanying drawings, in which:

Figure 1A shows an exemplary communication system in which one or more of the disclosed embodiments can be implemented.

Figure 1B shows an exemplary wireless transmitting/receiving unit that can implement one or more of the disclosed embodiments.

Figure 1C shows an exemplary system radio access network in which one or more of the disclosed embodiments can be implemented.

Figure 2 shows the SAML protocol flow for the exchange of authentication and data between the identification provider and the service provider.

Figure 3 shows the OpenID protocol process that allows users to use a single IP to log in to different relying party sites.

Figure 4 shows an exemplary implementation of an agreement process for providing SSO agreements with an integrated OP on a trusted computing environment.

Figure 5 shows an exemplary implementation of an agreement process for providing SSO agreements with an integrated OP on a trusted computing environment.

Figure 6 shows the OpenID protocol flow for association-based communication.

Figure 7 shows the OpenID protocol flow for stateless signature verification.

Figure 8 shows an exemplary implementation of integrating BONDI and association-based OpenID.

Figure 9 shows an exemplary implementation that integrates BONDI and stateless signature verification.

Figure 10 shows an exemplary implementation of enabling split OP.

Figure 11 shows another exemplary implementation of enabling split OP.

Figure 12 shows the BSF function used in the GBA architecture.

Figure 13 shows an overview of the GBA architecture.

Figure 14 shows the GBA reference module derived from 3GPP TS 33.220.

Figure 15 shows the NAF reference module for the accessed network derived from 3GPP TS 33.220.

Figure 16 shows the architecture scheme for Liberty/GBA.

Figure 17 shows an exemplary embodiment for GBA for MMO-supported recognition assertions.

Figure 18 shows another exemplary implementation of enabling split OP.

Figure 19 shows an exemplary implementation of enabling split terminal/local OpenId.

Figure 20 shows the standard OpenID protocol.

Figure 21 shows the OpenID/GBA business process from 3GPP TR 33.924 v9.1.0.

Figure 22 shows an exemplary embodiment of an agreement process for reducing air traffic.

Figure 23 shows an exemplary implementation of internal routing for OP on SCWS.

Figure 24 shows an exemplary implementation of the protocol flow that allows the RP to use the stateless mode to perform OpenID authentication.

Figure 25 shows an exemplary implementation of the protocol process that allows the RP to use the association-based mode to perform OpenID user authentication.

Figure 26 shows an exemplary implementation of the protocol process for the improved stateless mode.

Figure 27 shows an exemplary implementation for an improved association-based model agreement process.

Figure 28 shows the keyed hash message authentication code (HMAC) derived from NIST-FIPS PUB 198-1.

Figure 29 shows the business process of OpenID/GBA.

Figure 30 shows another exemplary embodiment of an agreement flow for an association-based communication mode.

Figure 31 shows another exemplary embodiment of an agreement flow for an association-based communication mode.

Figure 32 shows another exemplary embodiment of an agreement flow based on an association communication mode.

Figure 33 shows another exemplary embodiment of the protocol flow for the stateless mode.

Figure 34 shows an exemplary embodiment of the protocol flow for splitting the terminal.

Figure 35 shows the trust relationship in OpenID.

Figure 36 shows an exemplary embodiment of the trust relationship with the local OP.

Figure 37 shows an exemplary embodiment of the trust relationship with the MNO.

Figure 38 shows an exemplary embodiment of the SD layer with the issuer SD.

Figure 39 shows an exemplary embodiment of SD layering with DM.

Figure 41 shows an exemplary implementation of SCWS as a GP application.

Figure 42 shows an exemplary implementation of SCWS implemented in the runtime environment of the card.