HK1173284A - Method and apparatus for trusted authentication and logon - Google Patents

Description

Method and apparatus for trusted authentication and login

Technical Field

The present application relates to authentication and access.

Background

Identity management and user authentication and access are crucial issues for network (Web) usage, mobile services, wireless communication and other services. Many authentication and access protocols exist. For example, open id (openid) is an open, decentralized framework, and is a method for user authentication and access control. A single digital identity allows a user to log in once and gain access to multiple services. Digital identities are typically in the form of unique Universal Resource Locators (URLs), which are typically provided by identity providers (host). When a user desires to access a service provider with a digital identity, the identity provider authenticates the user. The OpenID framework allows different authentication methods to authenticate a user. To claim an identity at an identity provider, several methods can be used; the most common is the use of a login form (form) in which the user provides a password. However, without the use of a trusted system, the relying party would not be able to obtain sufficient evidence to establish a trust relationship with the communication partner that submitted the authentication credentials. User credentials (e.g., in the form of a username/password combination) are not bound to the platform and can therefore be stolen. An attacker can use the stolen credentials to access the service on behalf of the legitimate user. By binding the authentication credentials for the OpenID protocol to the platform and the trusted state of the platform, the confidentiality and the security of the OpenID protocol can be improved.

In a ticket (ticket) based authentication and authorization protocol, a software token (i.e., ticket) is used to prove the identity of a single entity/user. Based on these tokens, access to a particular system is restricted to the entity/user that generated the appropriate token. Furthermore, the data included in the token may be used to implement authentication control that enables a token-based access control scheme, in addition to implementing authentication only.

Another authentication and authorization protocol uses an Attestation Identity Key (AIK) as a credential in an identification ticket system, where the AIK is generated by a Trusted Platform Module (TPM) in a trusted computing environment. The AIK is used to sign trust measurements and to validate (certify)) keys generated by the TPM. Current implementations of such trusted ticket-based systems require the use of a central database to maintain a shared key database or Public Key Infrastructure (PKI) for ticket encryption, and all service providers need to be modified to evaluate and accept received tickets.

Disclosure of Invention

Methods and apparatus for trusted authentication and login are disclosed. Trusted Platform Module (TPM) -based login methods are proposed for authentication and access. A user registers an identity with an identity provider that is tightly bound to the user's particular platform (e.g., TPM). For example, if the user decides to use this identity to log into the service provider, the identity provider challenges (challenge) the user to provide the correct credentials. In this approach, the credentials used to merge the cryptographic credential chain consist of a TPM-generated ticket. This allows the user to log in without requiring a password at the identity provider. A local password at the user's particular platform may always be used to protect the identity from local attacks.

The login is combined with integrity verification of the specific platform. Using a TPM signed assertion to a Platform Configuration Register (PCR) of the TPM, where the PCR securely stores the system configuration, the identity provider may compare the reported system state to a previously generated reference value and only allow legitimate users to log in using a trustworthy platform and assert identity. This combined authentication and attestation allows fine-grained (fine-grained) access control by binding the authentication data not only to a specific platform, but also to a predefined system state that is considered trustworthy. This can allow new use cases for authentication and access methods that require enhanced system privacy and security and that will not allow any modifications that result in an untrusted system.

Drawings

A more detailed understanding can be obtained from the following description taken in conjunction with the accompanying drawings and by way of example, in which:

FIG. 1 illustrates an example high-level architecture for an authentication and access system;

FIG. 2 illustrates an example high level signal flow diagram for an authentication and access method;

fig. 3(a) and 3(b) show example signal flow diagrams for authentication and access methods;

fig. 4 is an embodiment of a Long Term Evolution (LTE) wireless communication system/access network; and

fig. 5 is an example block diagram of a wireless transmit/receive unit and a base station of an LTE wireless communication system.

Detailed Description

The term "wireless transmit/receive unit (WTRU)" as referred to below includes, but is not limited to, a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a computer, or any other type of user equipment capable of operating in a wireless environment. The term "base station" as referred to below includes, but is not limited to, a node B, an evolved node B, a site controller, an Access Point (AP), or any type of interfacing device capable of operating in a wireless environment.

The disclosure herein uses the OpenID protocol as an example authentication and access system and is applicable to other authentication and access systems. The basic entities and their high level flows are first described, followed by a detailed discussion of the method.

Fig. 1 is an example authentication and access system 100, the system 100 including, but not limited to: a client/user platform 110, an identity provider 120, a privacy authentication authority (privacy certification authority pca)130, and a service provider 140. The client/user platform 110, the identity provider 120, and the service provider 140 communicate with each other through any combination of wireless and wired communication systems. The client/user platform 110 also communicates with the PCA 130, the PCA 130 communicating with a storage medium 160, the storage medium 160 storing, for example, a validation (verification).

The client/user platform 110 may be a WTRU, a base station, a computing platform, or any device that may require authentication. The client/user platform 110 includes, but is not limited to: a Trusted Platform Module (TPM)115, the TPM 115 providing remote attestation and data sealing and binding capabilities for the client/user platform 110. TPM 115 is a microcontroller that stores keys, passwords, digital certificates, and the TPM 115 is able to generate cryptographic keys. The TPM may be attached to a motherboard or integrated into the chipset of the system and may be used in any computing device that requires these functions. TPM 115 ensures that information stored therein becomes more secure against software attacks, physical tampering, and eavesdropping from the outside. If the measurement values taken for the components during the boot sequence are not equal to the reference measurements as expected, access to the data and secrets in the TMP 115 or client/user platform 110 may be denied. Thereby, important applications and capabilities, such as secure e-mail, secure network access, and local protection of data, become more secure. Although a trusted platform module is discussed herein, other alternative trust centers may be used, such as a mobile trusted module.

TPM 115 uses an Endorsement Key (EK) that is a 2048 bit RSA public and private key pair that is randomly created on-chip and cannot be changed during manufacturing. The private key never leaves the chip, while the public key is used for attestation and for encryption of sensitive data sent to the chip. The public portion of the EK is typically known by the PCA 130 via the EK certificate for attestation purposes. In general, whenever TPM 115 needs to authenticate itself to a verifier (e.g., an identity provider), it generates a second RSA key pair called an Attestation Identity Key (AIK), sends the AIK public key to PCA 130, and authenticates this public key against the corresponding EK. If PCA 130 finds this EK in its list, it issues a certificate on the TPM 115 AIK. TPM 115 may then provide this certificate to identity provider 120 and authenticate itself.

As stated herein, an AIK (in which at least an identity is included) represents at least a portion of a ticket described herein. However, the use of AIK as a ticket is limited by TPM 115. Thus, an indirect means known as a verify key operation is used in which a signing key is generated by TPM 115 and verified by signing the signing key with an AIK. This key is called the Certified Signing Key (CSK). The CSK and AIK along with the PCA that proves the AIK is valid form part of the ticket described herein.

The client/user platform 110 also includes a ticket server 150 that generates credentials or tickets for service access. The ticket server 150 authenticates the user. The ticket server 150 uses a trusted computing method of platform attestation to validate (valid) the client/user platform 110 and itself to the identity provider 120. The ticket server 150 does not exist in the currently untrusted OpenID architecture, where the corresponding role is played only by the local credential storage. Since more security critical information and operations are centralized in the ticket server 150, the ticket server 150 must be trusted to properly process the AIK certificates and CSKs and not disseminate them to other platforms; protecting the ticket and certificate; securing any security critical operations on all certificates authorized by the user; providing a security option to be integrated directly in and to be accessed through a public web browser; and aggregating, processing, and transmitting platform validation data. This is disclosed in detail herein.

The user needs to select PCA 130 to validate the AIK created in TPM 115. The PCA 130 may retain all identity-related information and contractual measures need to be taken to ensure that this identity-related information is not disclosed. After the AIK is validated at PCA 130, the user may select the identity provider 120 to provide (host) the claimed identity. The claimed identity is represented by a Universal Resource Identifier (URI) selected by the user. In order to register such a claimed identity, the user must provide valid AIK credentials to the identity provider 120. This is disclosed in detail herein.

The identity provider 120 may have only a minimal amount of identity-related information. The user may decide which information provided (host) at the PCA 130 may and will be disclosed to the identity provider 120. Contractual measures need to be taken to ensure coordination between the parties, otherwise, a rogue PCA can prove the identities of the different users. Since the PCA 130 will not reveal the user's true identity to the identity provider 120, the identity provider 120 will not be able to link different requests to a single identity.

PCA 130 is just one example of a device that can resolve an asserted identity into a true identity. This can be easily achieved by keeping a secure database that maps (unique) EK certificates to AIKs. The EK certificate used during AIK attestation allows unambiguous identification of TPM 115 and, therefore, client/user platform 110 (assuming only one user has access to platform 110 that resolves the user).

The service provider 140 need only log the identity provider into the website. For example, on the home page, the service provider 140 may have an OpenID sign-in flag. The identity provider 120 used by the user/client needs to be in the list of known and accepted identity providers of the service provider 140.

Referring now to fig. 2, there is shown an exemplary high level signal flow 200 for the system 100 disclosed in fig. 1. As discussed herein, a client/user or user platform 210, a service provider 215, and an identity provider 220 (shown as an example OpenID provider) are configured for communication with each other.

The client/user platform 210 uses its web browser 225 to access the service provider web page (identified as index. jsp 235) via an access web message 227. For example, if the client/user 210 wants to log in using his OpenID URI, an index at the service provider 215 jsp page 235 requests this URI via OpenID login form message 229, and thus obtains the address of the OpenID provider 220 that provides (host) the asserted identity via OpenID identity message 231.

The service provider 215 then attempts to form an association with the OpenID provider 220. According to the OpenID protocol, the service provider 215 is associated with the OpenID provider 220 via an association message 241. If the authentication is successful, the association includes a request via an association message 243 to a redirect message 247 sent by the OpenID provider 220 to the client/user platform 210, a claimed identity, and a secure exchange returning a URL. This is performed by the user redirection at the service provider 215, jsp 240, and the provider at the OpenID provider 220, jsp 245. After association, the client/user platform 210 is redirected to the provider of the OpenID provider 220 via a redirect message 249 to the OpenID provider.

The OpenID provider 220 then converts from the provider jsp web page 245 to the provider authorization jsp web page 255 to authenticate the client/user platform 210. The user initiates the request by clicking on a link on the provider authorization jsp web page 255. This starts a new background thread TT verifier 258, which TT verifier 258 challenges the ticket server 250 via challenge message 252. Provider authorization jsp web page 255 redirects client/user platform 210 back to provider jsp web page 245, which provider jsp web page 245 waits for TT verifier 258 to complete and evaluate the challenge result provided in challenge reply message 254. As described herein, the ticket server 250 generates an appropriate reply including the ticket using TPM functionality and generally interacts with the TPM 250, PCA275, and storage media 280 (e.g., retention validation).

Assuming the authentication is successful, the provider jsp web page 245 sends a redirect message 262 to the client/user platform 210. Redirect message 262 redirects the client/user platform 210 to a user return url. Jsp page 265 checks for redirections from the associated OpenID provider 220 and grants access to the client/user platform 210 via service message 267.

Referring now to fig. 3(a) and 3(b), there is shown a signal flow diagram 300 between a ticket server 305 and a ticket challenger 310. The signal flow between the ticket server 305 and the PCA315, the attestation storage media 320 and the TPM325 is also shown.

The ticket server 305 runs as a service application on the client. It listens on a predefined port and waits for a challenge. After receiving the challenge message 327 (which challenge message 327 contains the identity the user wants to use in, for example, OpenID, and a service request issued at the service provider), the user is asked to explicitly allow the challenge using a response message 329. The user has the option of rejecting the challenge. If rejected, the OpenID authentication will fail.

If the challenge is accepted, the user is prompted to enter a password for the AIK corresponding to the given identity, and is prompted to authenticate TPM325 usage by entering a Storage Root Key (SRK) password at ticket server 305. The SRK is then included in a TPM command that enables access to TPM-protected keys. The ticket server 305 then attempts to retrieve the previously obtained AIK certificate for this identity from the certificate storage medium 320, collectively shown as 335, which 335 is required for system state information retrieval 345 and TC ticket generation 350 as discussed herein. The certificate can be from a previous AIK attestation with a PCA (e.g., PCA 315) and can therefore be retrieved from a local certificate store (e.g., attestation storage media 320) on the system, or if the certificate is not available in local memory (or the certificate for the AIK in local memory has expired or becomes invalid for any reason), a new certificate for the identity represented by the AIK can be requested from the PCA 315. In particular, if a certificate cannot be found in the certificate storage media 320, the user may select the PCA315 to connect to go through the AIK attestation process and obtain a certificate for the AIK. Thus, the user must provide the correct owner password for the TPM 325. This prevents creation of rogue identities by people other than the owner of the TPM 325. As shown below, the user input is forwarded by the ticket server 305 to the TPM325 where the password is evaluated at the TPM 325.

In response to accepting the challenge, the ticket challenger 310 creates a random nonce (nonce) 337. The ticket server 305 receives the random nonce 337 from the ticket challenger 310 via a nonce message 339. The AIK signed quote Q describing the PCR values of the system configuration (including the random number) is obtained from the TPM325, making a statement regarding the system state, shown collectively as 345.

The ticket server 305 then creates a TC ticket, shown collectively as 350. The TC ticket creation 350 involves the creation of a new key (RSA key pair) by the TPM that can be used to sign the request and identity. This new key is validated with the AIK using a validate key operation as described herein. That is, the TPM uses the attestation key function for this newly created key pair to generate attestation statements and bindings, where a binding refers to a chain of trust established from the PCA to the AIK and AIK certificates. When the newly created key is successfully validated, it is referred to as the validated signing key (CSK). There may be multiple CSKs and multiple AIKs in the TPM (or protected by the TPM in a secure memory protected by the TPM).

Information required to authenticate (verify) the TC ticket 350 is included in the ticket 350 so that the recipient (represented by the ticket challenger 310 in fig. 3(a) and 3 (b)) can easily authenticate the TC ticket 350. Along with the plain text measurement log (log) ML and the reference Q, a response including the TC ticket 350 is sent back to the ticket challenger 310 via the TCT, Q, ML message 352. The CH response and ACK message (generally denoted 351) are protocol signaling messages used to inform the recipient (i.e., ticket challenger 310) that the next message will contain TC ticket 350, a reference, and ML. It should be noted that at this juncture in the process, FIGS. 3(a) and 3(b) represent the internal operation of the TT verifier thread 258 in FIG. 2. Since the OpenID provider can handle multiple requests simultaneously, it must ensure that each requesting client gets a new, fresh (fresh) and unique challenge to prevent replay attacks.

After responding to the TC ticket 350 via message 355, the ticket challenger 310 now has the following data: a reference to the AIK signature from the TPM325, the reference including a random number 337 as anti-replay protection; a plain text measurement file; a TC ticket 350, the TC ticket 350 including a signed identity string, a signed request string, a public key portion of the CSK, an AIK signature over the public key portion of the CSK, and an AIK certificate issued by the PCA 315. To authenticate the client, the ticket challenger 310 checks the following information, shown collectively as 360: validation of the AIK certificate (timestamp); verifying the PCA signature on the AIK certificate; verify the AIK signature over the CSK public key hash (hash) in the TC ticket 350; verify the signature on the service request and the identity in the TC ticket 350; confirming an item (entry) in the measurement list; and verifying that the actual (referenced) Platform Configuration Register (PCR) values correspond to the measurement list ML.

If any fails in this verification process, the client will not be authenticated. A specific credential chain is established by the ticket server 305 and PCA315, i.e., AIK certificate-certified CSK-signed request. An authentication status message 365 is sent to the user. This is also illustrated, for example, by redirect message 262 in fig. 2. In this example, message 262 may redirect the user's browser to the service provider return url, or authenticate the user at the service provider. If any of the above verifications fail (certificate validation or system integrity failure), the redirect sends the user to an "authentication failure" page at the OpenID provider. Alternatively, in case of authentication failure, it is possible to create a customized result page at the OpenID provider, which shows the reason for the failure. This can include showing the user which modules or software have failed integrity checks and can be affected (legacy) to a system that suggests to the user that the next step will bring the user's system back to a trustworthy state.

Given the disclosure herein, the role of a PCA (e.g., PCA 275) is different than it plays in current ticket systems that use trusted computing. For example, PCA275 may only need to be invoked once for each partial identity that a particular service provider 215 will use. In the initial registration, the client/user platform 210 associates its platform identity with a partial identity of a pseudonym. PCA275 provides a certificate for this pseudonym identity and stores the association of the pseudonym with the platform identity. This data is privately sensitive and therefore needs to be protected. In another example, the positioning of the PCA275 allows additional options compared to current ticket systems. The trust model and method disclosed herein allows placement of the PCA275 at a place other than the identity provider 220 and at the user's choosing.

In the disclosed methods and architectures, a user may select an arbitrary external PCA whose AIK credentials are accepted by an identity provider or use PCA functionality provided directly or indirectly by the identity provider. In this latter example, the PCA or PCA function may be placed at the identity provider to reduce complexity and provide a seamless alternative to registering with the identity provider via a Web (Web) form.

Due to its particular security architecture, the proposed disclosure reduces the specific threat against identity management systems using trusted computing, which rely on encryption of identity-related information. In trusted OpenID, for example, the AIK certificate is known and visible to the client; therefore, the AIK certificate cannot contain hidden information that threatens privacy.

In another example, the OpenID implementation presents an OpenID provider login table to the user. The user enters his/her credentials and the OpenID provides for issuing a cookie to the user. This cookie is then used for each subsequent OpenID-enabled service access. This may lead to some attacks on the OpenID protocol: (1) directly attacking the user credentials of the OpenID provider for logging in to the client (phishing with a fake OpenID provider page would expose a large number of user credentials, which allows identity theft) and; (2) attacks involving re-use, duplication, and theft of cookies from the client's computer after authentication, resulting in identity theft.

Both of these attacks are mitigated by the disclosure presented herein. All user passwords are local and only provided to a local trusted ticket server, and the problem of credential phishing is defeated. Furthermore, pseudonym identities are bound to the platform (e.g. TPM) so they cannot be copied into another device.

Further, cookies cannot be stored on the client platform. This may prevent the threat of local reuse. For example, consider a computer shared by multiple people. If person a logs into his OpenID account and forgets to logout, person B can simulate a using the stored cookie. Options the authentication methods disclosed by the present invention can be seamlessly integrated into a web browser. Whenever a user wants to access a service using the trusted method disclosed herein, the identity provider creates a new challenge for the ticket server. The user only sees a prompt from the trusted ticket server application that asks the client for a local AIK password, which is needed to answer the challenge. The ticket server does not store this AIK authentication secret. If another user B on the same platform wants to access the service, the ticket server is challenged again by the identity provider and B needs to provide A's local AIK password (B does not know it). The goal is to have a one-time cookie that is not permanently saved on the client's platform. Alternatively, binding user authentication to a device may be facilitated through biometric identification. In an integrated device, biometric identification can be implemented transparently, dynamically, and constantly, thereby always ensuring that the device is being used by a real user.

The disclosure herein may use encryption on issued cookies in a manner such that the target platform (the user platform as seen from the perspective of the identity provider) and the user may decrypt the encryption and use it as an authentication token. The identity provider encrypts the cookie using the secret key and sends it to the client-side ticket server, which is protected by the public CSK. Although CSK does not imply bulk encryption of any amount of data, it can be used to encrypt a secret key that is used to encrypt cookies. The secret key may be a symmetric or asymmetric key.

The cookie can be decrypted using the TPM if needed. This decryption requires the user to authenticate CSK usage with the (local) CSK secret. The ticket server ensures that cookies are stored encrypted and only decrypted when needed.

In another application, the disclosed authentication and access methods may be used in a combined authentication, access and authorization method. Major search engine companies have recently announced support for open authorization (OAuth) (i.e., an example API authorization method) to provide a seamless user experience when accessing network services. The user will access the network (Web) service using the access link provided by the service provider and at the same time, access is granted to the network application for the service provided (hosted) by the service provider, e.g. via OAuth. OpenID is used to authenticate users using centrally stored identities. OAuth is used to authorize network services to access user data such as calendars, documents, etc. The merging of the two protocols improves the user experience of single sign-on in a single step and allows new web services that require access to different user data, such as mashup applications (mash-up), dashboard, etc.

Instead of the user's TPM signing only the identity provider (e.g., OpenID challenge), the TPM will sign a merged challenge, such as an OpenID/OAuth challenge, as set forth by the identity provider's request through the web application. User identification and authorization and acceptance of data access is securely signed by the TPM. As disclosed herein, user security is improved by: (1) binding login and authorization to the hardware TPM, and (2) providing platform integrity verification by OpenID/OAuth providers to prevent malicious software running on the client from stealing sensitive data. Integrity verification also increases the security level of network applications. Only clients in the certified integrity verification state may be given access to the network service. This allows new network services to be established for security and privacy critical applications. E.g. OAuth, the fact that the authorized provider of token access is signed by the TPM can be uniquely identified, the described method provides non-repudiation. This facilitates a charging process that may be implemented by the service provider of the network application. The signature allows the web application provider to certify the web service requested and accessed by the user.

TPM-based user authentication allows contact between platform identity and identity providers. Identity providers need to maintain a database of registered identities for a given platform. When detecting an attempt to login from another platform using one of the registered identities, the identity provider: (1) authentication can/must be denied, or (2) the legitimate owner of the identity can be announced. Identity providers can easily distinguish legitimate users from attackers through a given platform credential.

In another example, a method may include an attestation mechanism. The identity provider may challenge the user to provide information about the system state of the user platform. If the system is in a trustworthy state, access will be granted. This will affect the security of (legacy) web applications, since only "trustworthy" systems can access the web services.

In yet another example, instead of a service application on the user side listening for incoming authentication requests and forwarding the requests to the TPM, seamless browser integration may be used. This can be achieved by using browser extensions that implement the applicable functionality. The identity provider issues a challenge that is located inside the HTML code of the sign-in page. The browser extension can read this information and forward the necessary data to the TPM. And the TPM creates a signed ticket and returns the signed ticket to the browser extension. The extension may then issue a correct HTTPS response to the identity provider, the response including the signed ticket. In this case, the streams of fig. 3(a) and 3(b) would be handled by a seamlessly integrated browser extension instead of a stand-alone extension. This solution allows better portability and better user experience.

In general, a method for trusted authentication and access from a user platform includes logging in to a service provider using a predetermined identity, wherein the user platform is redirected by the service provider to an identity provider pointed to by the predetermined identity. The method also includes receiving an authentication challenge from the identity provider and, in the event that the authentication challenge is accepted by the user platform, transmitting a Trusted Platform Module (TPM) -based ticket in response to the authentication challenge. The method also includes accessing the service provider upon successful receipt of the ticket verification from the identity provider. The predetermined identity is represented by a universal resource identifier. The method also includes generating a ticket that validates the user platform and ticket. The authentication challenge includes at least the predetermined identity and a type of service request. The method also includes generating a signing key for verification of the predetermined identity and the service request signature.

The method also includes providing a password for an Attestation Identity Key (AIK) corresponding to the predetermined identity, and a storage root key password for authenticating TPM use. It also includes obtaining a certificate corresponding to an Attestation Identity Key (AIK). The method also includes generating the credential if a previously obtained credential is not available. The method also includes receiving a nonce in response to the positive challenge response, and generating an Attestation Identity Key (AIK) signed quote from the TPM, wherein the AIK signed quote includes the nonce. The ticket also includes a Certified Signing Key (CSK) signed predetermined identity, a CSK signed request, a CSK public key, and a Privacy Certification Authority (PCA) issued Attestation Identity Key (AIK) certificate.

The method also includes transmitting, in response to the authentication challenge, an Attestation Identity Key (AIK) signed quote and measurement log from a Platform Configuration Register (PCR) of the TPM, if the user platform accepts the authentication challenge. Successful ticket verification includes validating the time stamp of the AIK certificate, verifying the PCA signature on the AIK certificate, verifying the AIK signature on the CSK public key, verifying the predetermined identity of the CSK signature, verifying the request for the CSK signature, validating the measurement log, and validating the quote.

The method also includes receiving an encrypted cookie for subsequent service provider access, the cookie protected by the certified signing key. The authentication challenge includes an authorization challenge. The method also includes an attestation challenge.

An apparatus for supporting trusted authentication and access includes an interface module configured to access a service provider using a predetermined identity, wherein the apparatus is redirected by the service provider to an identity provider pointed to by the predetermined identity. The apparatus also includes a ticket server configured to respond to the authentication challenge by transmitting a Trusted Platform Module (TPM) -based ticket if the authentication challenge is accepted. The interface module is further configured to receive a successful ticket verification from the identity provider and access a service on the service provider. The ticket server is further configured to generate a ticket including a Certified Signing Key (CSK) signed predetermined identity, a CSK signed request, a CSK public key, and a Privacy Certification Authority (PCA) issued Attestation Identity Key (AIK) certificate. The ticket server is further configured to obtain an Attestation Identity Key (AIK) signed quote from the TPM and a measurement log. The ticket server is further configured to receive a nonce and generate an Attestation Identity Key (AIK) signed quote from the TPM, wherein the AIK signed quote includes the nonce.

As disclosed herein, the user client/platform may be, for example, a WTRU or a base station used in a wireless communication system. In one example, it also applies to other wireless communication systems. Fig. 4 illustrates a Long Term Evolution (LTE) wireless communication system/access network 400 that includes an evolved universal terrestrial radio access network (E-UTRAN) 405. The E-UTRAN 405 includes a WTRU 410 and a number of evolved node Bs (eNBs) 420. The WTRU 410 communicates with the eNB 420. The enbs 420 interface with each other using an X2 interface. each of the enbs 420 interfaces with a Mobility Management Entity (MME)/serving gateway (S-GW)430 over an S1 interface. Although figure 4 shows a single WTRU 410 and three enbs 420, it should be apparent that any combination of wireless and wired devices may be included in the wireless communication system access network 400.

Fig. 5 is an exemplary block diagram of an LTE wireless communication system 500, the LTE wireless communication system 500 including a WTRU 410, an eNB 420, and an MME/S-GW 430. As shown in fig. 5, the WTRU 410, eNB 420, and MME/S-GW 430 are configured to perform a Blind Decoding (BD) complexity reduction method using association.

In addition to the components that may be found in a typical WTRU, the WTRU 410 includes a processor 516 with an optional connection memory 522, at least one transceiver 514, an optional battery 520, and an antenna 518. The processor 516 is configured to perform the methods disclosed herein. The transceiver 514 is in communication with the processor 516 and an antenna 518 to facilitate the transmission and reception of wireless communications. In the case where a battery 520 is used for the WTRU 410, the battery 520 powers the transceiver 514 and the processor 516.

In addition to the components that may be found in a typical eNB, the eNB 420 includes a processor 517 with an optional connection memory 515, a transceiver 519, and an antenna 521. The processor 517 is configured to perform the methods disclosed herein. The transceiver 519 is in communication with the processor 517 and the antenna 521 to facilitate the transmission and reception of wireless communications. The eNB 420 is connected to a mobility management entity/serving gateway (MME/S-GW)430, the MME/S-GW 430 including a processor 533 with an optional connection memory 534.

Examples

1. A method for trusted authentication and access from a user platform, the method comprising logging in to a service provider using a predetermined identity, wherein the user platform is redirected by the service provider to an identity provider pointed to by the predetermined identity.

2. According to the method shown in embodiment 1, the method further comprises receiving an authentication challenge from the identity provider.

3. A method as in any preceding embodiment, comprising transmitting a Trusted Platform Module (TPM) -based ticket in response to the authentication challenge if the user platform accepts the authentication challenge.

4. A method as in any preceding embodiment, comprising accessing the service provider upon receiving a successful ticket verification from the identity provider.

5. The method according to any of the preceding embodiments, wherein the predetermined identity is represented by a universal resource identifier.

6. A method as claimed in any preceding embodiment, comprising generating a ticket, the ticket validating the user platform and ticket.

7. The method of any preceding embodiment, wherein the authentication challenge comprises at least the predetermined identity and a type of service request.

8. A method as claimed in any preceding embodiment, comprising generating a signing key for verification of the subscription identity and the service request signature.

9. A method as in any preceding embodiment, comprising providing a password for an Attestation Identity Key (AIK) corresponding to the predetermined identity, and a storage root key password for authenticating TPM use.

10. A method as claimed in any preceding embodiment, comprising obtaining a certificate corresponding to an Attestation Identity Key (AIK).

11. A method as claimed in any preceding embodiment, the method comprising generating a certificate if a previously obtained certificate is not available.

12. A method as in any preceding embodiment, comprising receiving a nonce in response to a positive challenge response.

13. The method of any of the preceding embodiments, comprising generating an Attestation Identity Key (AIK) signed quote from the TPM, wherein the AIK signed quote comprises the nonce.

14. The method of any of the preceding embodiments, wherein the ticket further comprises a Certified Signing Key (CSK) signed predetermined identity, a CSK signed request, a CSK public key, and a Privacy Certification Authority (PCA) issued Attestation Identity Key (AIK) certificate.

15. The method of any of the preceding embodiments, comprising transmitting an Attestation Identity Key (AIK) signed quote and measurement log from a Platform Configuration Register (PCR) of the TPM in response to the authentication challenge if the user platform accepts the authentication challenge.

16. The method of any of the preceding embodiments, wherein the successful ticket verification comprises validating a timestamp of the AIK certificate, verifying a PCA signature on the AIK certificate, verifying an AIK signature on the CSK public key, verifying a predetermined identity of the CSK signature, verification of a request for the CSK signature, validation of the measurement log, and verification of the quote.

17. A method as claimed in any preceding embodiment, comprising receiving an encrypted cookie for subsequent service provider access, the cookie being protected by a certified signing key.

18. The method of any of the preceding embodiments, wherein the authentication challenge comprises an authorization challenge.

19. The method of any of the preceding embodiments, comprising an attestation challenge.

20. An apparatus for supporting trusted authentication and access, the platform comprising an interface module configured to access a service provider using a predetermined identity, wherein the apparatus is redirected by the service provider to an identity provider pointed to by the predetermined identity.

21. The apparatus of embodiment 20, comprising a ticket server configured to respond to an authentication challenge by transmitting a Trusted Platform Module (TPM) -based ticket if the authentication challenge is accepted.

22. The apparatus as in any one of embodiments 20-21 comprising the interface module configured to receive a successful ticket verification from the identity provider and access a service on the service provider.

23. The apparatus of any of embodiments 20-22, wherein the ticket server is further configured to generate a ticket comprising a Certified Signing Key (CSK) signed predetermined identity, a CSK signed request, a CSK public key, and a Privacy Certification Authority (PCA) issued Attestation Identity Key (AIK) certificate.

24. The apparatus of any of embodiments 20-23, wherein the ticket server is further configured to obtain an Attestation Identity Key (AIK) signed quote and measurement log from the TPM.

25. The apparatus of any of embodiments 20-24, wherein the ticket server is further configured to receive a nonce and generate an Attestation Identity Key (AIK) -signed quote from the TPM, wherein the AIK-signed quote includes the nonce.

Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in combination with other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of the computer-readable storage medium include: read Only Memory (ROM), Random Access Memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs).

For example, suitable processors include: a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), and/or a state machine.

The user platform may be any number of platforms including a WTRU. A processor in association with software may be used to implement a radio frequency transceiver for use in a Wireless Transmit Receive Unit (WTRU), User Equipment (UE), terminal, base station, Radio Network Controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, bluetoothA module, a Frequency Modulation (FM) radio unit, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

Claims (19)

1. A method for trusted authentication and access from a user platform, the method comprising:

logging in a service provider using a predetermined identity, wherein the user platform is redirected by the service provider to an identity provider pointed to by the predetermined identity;

receiving an authentication challenge from the identity provider;

transmitting a Trusted Platform Module (TPM) -based ticket in response to the authentication challenge on a condition that the user platform accepts the authentication challenge; and

accessing the service provider upon receiving a successful ticket verification from the identity provider.

2. The method of claim 1, wherein the predetermined identity is represented by a universal resource identifier.

3. The method of claim 1, further comprising generating a ticket that validates the user platform and ticket.

4. The method of claim 1, wherein the authentication challenge includes at least the predetermined identity and a type of service request.

5. The method of claim 4, further comprising generating a certified signing key for signing the predetermined identity and the service request.

6. The method of claim 1, further comprising providing a password for an Attestation Identity Key (AIK) corresponding to the predetermined identity, and a storage root key password for authenticating TPM use.

7. The method of claim 1, further comprising obtaining a certificate corresponding to an Attestation Identity Key (AIK).

8. The method of claim 7, further comprising generating a certificate if a previously obtained certificate is unavailable.

9. The method of claim 1, further comprising:

receiving a nonce in response to a positive challenge response; and

generating an Attestation Identity Key (AIK) signed quote from the TPM, wherein the AIK signed quote includes the nonce.

10. The method of claim 1, wherein the ticket further comprises a Certified Signing Key (CSK) signed predetermined identity, a CSK signed request, a CSK public key, and a Privacy Certification Authority (PCA) issued Attestation Identity Key (AIK) certificate.

11. The method of claim 10, further comprising transmitting an Attestation Identity Key (AIK) signed quote and measurement log from a Platform Configuration Register (PCR) of the TPM in response to the authentication challenge if the user platform accepts the authentication challenge.

12. The method of claim 11, wherein the successful ticket verification comprises validating a timestamp of the AIK certificate, verifying a PCA signature on the AIK certificate, verifying an AIK signature on the CSK public key, verifying a predetermined identity of the CSK signature, verifying a request for the CSK signature, validating the measurement log, and verifying the reference.

13. The method of claim 1, further comprising receiving an encrypted cookie for subsequent service provider access, the cookie protected by a certified signing key.

14. The method of claim 1, wherein the authentication challenge comprises an authorization challenge.

15. The method of claim 1, further comprising an attestation challenge.

16. An apparatus for supporting trusted authentication and access, the platform comprising:

an interface module configured to access a service provider using a predetermined identity, wherein the apparatus is redirected by the service provider to an identity provider pointed to by the predetermined identity;

a ticket server configured to respond to an authentication challenge by transmitting a Trusted Platform Module (TPM) -based ticket if the authentication challenge is accepted; and

the interface module is configured to receive a successful ticket verification from the identity provider and access a service on the service provider.

17. The apparatus of claim 16, wherein the ticket server is further configured to generate a ticket including a Certified Signing Key (CSK) signed predetermined identity, a CSK signed request, a CSK public key, and a Privacy Certification Authority (PCA) issued Attestation Identity Key (AIK) certificate.

18. The apparatus of claim 17, wherein the ticket server is further configured to obtain an Attestation Identity Key (AIK) signed quote and measurement log from the TPM.

19. The apparatus of claim 16, wherein the ticket server is further configured to receive a nonce and generate an Attestation Identity Key (AIK) signed quote from the TPM, wherein the AIK signed quote includes the nonce.