JP2017139026A - Method and apparatus for reliable authentication and logon - Google Patents
Method and apparatus for reliable authentication and logon Download PDFInfo
- Publication number
- JP2017139026A JP2017139026A JP2017094260A JP2017094260A JP2017139026A JP 2017139026 A JP2017139026 A JP 2017139026A JP 2017094260 A JP2017094260 A JP 2017094260A JP 2017094260 A JP2017094260 A JP 2017094260A JP 2017139026 A JP2017139026 A JP 2017139026A
- Authority
- JP
- Japan
- Prior art keywords
- aik
- ticket
- signed
- tpm
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
Description
本願は、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）およびアクセスに関する。 The present application relates to authentication and access.
識別子管理、ならびにユーザー認証およびアクセスは、ウェブ利用、移動体サービス、無線通信、および他のサービスのための重大な問題である。多くの認証およびアクセス・プロトコルがある。例えばＯｐｅｎＩＤは、ユーザー認証およびアクセス管理のための、開かれた、分散型の枠組みおよび方法である。ただ一つのディジタル識別子により、ユーザーが、一度ログオンし、そして複数のサービスへのアクセスを得ることが可能である。ディジタル識別子は一般には、アイデンティティ・プロバイダーによって通常提供される一意なユニバーサルリソースロケータ（ＵＲＬ：Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の形式である。アイデンティティ・プロバイダーは、ユーザーがディジタル識別子によりサービス・プロバイダーにアクセスしようと欲したとき、ユーザーを認証する。ＯｐｅｎＩＤの枠組みは、ユーザーを認証するための種々の認証方法を可能にさせる。アイデンティティ・プロバイダーにて識別子を主張する（ｃｌａｉｍ）ために、いくつかの方法を使用することが可能である。最も一般的なのは、ユーザーがパスワードを提供するログオン形式の使用である。しかしながら、信頼できるシステムの使用なくしては、認証信用情報を発出する通信相手と信頼関係を確立するための充分な根拠を依存する側が獲得することはないであろう。ユーザー信用情報（例えば、ユーザー名／パスワードの組み合わせの形式の）は、プラットフォームに結合している訳ではないため、盗用されているかもしれない。攻撃者は、正規のユーザーの名を借りてサービスにアクセスするために盗用された信用情報を使用するかもしれない。ＯｐｅｎＩＤプロトコルのための認証信用情報をプラットフォームおよびその信頼に値する状態に結合することによって、ＯｐｅｎＩＤプロトコルのセキュリティおよび安全性を高めることができる。 Identifier management and user authentication and access are critical issues for web usage, mobile services, wireless communications, and other services. There are many authentication and access protocols. For example, OpenID is an open, distributed framework and method for user authentication and access management. With a single digital identifier, a user can log on once and gain access to multiple services. Digital identifiers are typically in the form of a unique universal resource locator (URL) that is typically provided by an identity provider. The identity provider authenticates the user when the user wants to access the service provider with a digital identifier. The OpenID framework allows various authentication methods to authenticate users. Several methods can be used to claim an identifier at an identity provider. The most common is the use of a logon format where the user provides a password. However, without the use of a trusted system, the relying party will not gain sufficient evidence to establish a trust relationship with the communication partner issuing the authentication credential. User credentials (e.g., in the form of a username / password combination) may not have been tied to the platform and may have been stolen. An attacker may use stolen credentials to gain access to services in the name of legitimate users. By combining authentication credentials for the OpenID protocol with the platform and its trustworthy state, the security and security of the OpenID protocol can be increased.
チケット準拠の認証および認可プロトコルにおいては、単一のエンティティ／ユーザーの識別子を立証するためにソフトウェア・トークン（すなわちチケット）が使用される。これらのトークンに準拠することで、ある特定のシステムへのアクセスは、適切なトークンを生成するエンティティ／ユーザーに制限される。さらに加えて、単なる認証以外にトークン準拠のアクセス管理方式を可能にする認可制御を実施するために、トークン中に一体化されたデータを使用することができる。 In ticket-based authentication and authorization protocols, software tokens (ie, tickets) are used to verify a single entity / user identifier. By complying with these tokens, access to a particular system is restricted to the entity / user generating the appropriate token. In addition, the data integrated in the token can be used to implement authorization control that allows a token-compliant access management scheme other than just authentication.
別の認証および認可プロトコルでは、チケット・システムにおいて信用情報を識別する際に、信頼できるコンピューティング環境におけるＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：トラステッド・プラットフォーム・モジュール）により生成されたＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）を使用する。ＡＩＫは、信頼性測定に署名し、そしてＴＰＭによって生成された鍵を証明するために使用される。このような信頼できるチケット準拠のシステムの現在の実施方法は、チケットの暗号化のために、集中データベースを使用し、共有された鍵データベースまたはＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ：公開鍵暗号基盤）を維持することを必要とし、そしてすべてのサービス・プロバイダーを、受信したチケットを審査しそして受容するように変更する必要がある。 In another authentication and authorization protocol, an AIK (Attestation Identity Key) generated by a Trusted Platform Module (TPM) in a trusted computing environment when identifying credentials in the ticket system. Key). The AIK is used to sign the trust measure and prove the key generated by the TPM. Current implementations of such trusted ticket-compliant systems use a centralized database for ticket encryption and maintain a shared key database or PKI (Public Key Infrastructure). And all service providers need to be changed to review and accept received tickets.
信頼できる認証およびログオンのための方法および装置が開示される。ＴＰＭ準拠のログオン方法が認証およびアクセスに対して提示される。ユーザーは、ユーザーの特定のプラットフォーム、例えばＴＰＭに緊密に結合したアイデンティティ・プロバイダーを用いて識別子を登録する。ユーザーが、例えばこの識別子を使用してサービス・プロバイダーにログインしようと決めたなら、アイデンティティ・プロバイダーは、ユーザーが正しい信用情報を提供することをチャレンジ（ｃｈａｌｌｅｎｇｅ）する。この方法においては、信用情報は、暗号信用情報チェーンを組み込んだ、ＴＰＭによって生成されたチケットから成る。これによりユーザーは、アイデンティティ・プロバイダーにてパスワードの必要性なしでログインが可能となる。ユーザーの特定のプラットフォームでのローカルなパスワードは、ローカルな攻撃から識別子を保護するために依然として使用することができる。 A method and apparatus for trusted authentication and logon is disclosed. A TPM compliant logon method is presented for authentication and access. The user registers the identifier using an identity provider that is tightly coupled to the user's specific platform, eg, TPM. If the user decides to log in to the service provider using this identifier, for example, the identity provider challenges the user to provide correct credit information. In this method, the trust information consists of a ticket generated by the TPM that incorporates a cryptographic trust information chain. This allows the user to log in without the need for a password at the identity provider. A user's local password on a particular platform can still be used to protect the identifier from local attacks.
ログオンは、特定のプラットフォームの完全性検証と組み合わされる。システム構成を安全に保存する、ＴＰＭのＰＣＲ（Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒ：プラットフォーム構成レジスタ）上のＴＰＭによって署名されたステートメントを使用して、アイデンティティ・プロバイダーは、報告されたシステム状態を以前に生成された参照値と比較することができ、これによりログインしそして識別子を請求するために信頼に値するプラットフォームを正規のユーザーのみが使用することを可能とする。この組み合わされた認証および証明（ａｔｔｅｓｔａｔｉｏｎ）は、特定のプラットフォームのみではなく、信頼に値すると考えられる事前に定義されたシステム状態にも認証データを結合することによってきめ細かいアクセス管理を可能とする。これにより、システムの拡張されたセキュリティおよび安全性を必要とし、そして信頼に値しないシステムの原因となる何れの修正をも許容しないであろう、認証およびアクセス方法のための新しい用途を可能にする。 Logon is combined with specific platform integrity verification. Using a statement signed by the TPM on the TPM's Platform Configuration Register (PCR) that securely stores the system configuration, the identity provider can use the previously generated reference to the reported system state. The value can be compared, thereby allowing only legitimate users to use a trusted platform for logging in and claiming identifiers. This combined authentication and attestation allows fine-grained access management by combining authentication data not only with a specific platform, but also with predefined system states that are considered trustworthy. This allows for new applications for authentication and access methods that require extended security and safety of the system and would not allow any modifications that would cause untrustworthy systems. .
添付図面に関連して例として与えられた以下の説明から、より詳細な理解を得ることができる。 A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
後述される、用語「ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）」は、限定的ではなく、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザー機器）、移動体端末、固定型または移動体の加入者ユニット、ページャー、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ：携帯情報端末）、コンピューター、または無線環境において動作する能力のある他の如何なる種別のデバイスをも含む。後述される、用語「基地局（ｂａｓｅ ｓｔａｔｉｏｎ）」は、限定的ではなく、ノードＢ（Ｎｏｄｅ−Ｂ）、発展型ノードＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）、サイトコントローラー、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ：アクセス・ポイント）、または無線環境において動作する能力のある他の如何なる種別のインターフェイス・デバイスをも含む。 The term “WTRU (Wireless Transmit / Receive Unit)”, which will be described later, is not limiting and is not limited to UE (User Equipment), mobile terminal, fixed or mobile subscriber unit, pager. , Mobile phones, PDAs (Personal Digital Assistants), computers, or any other type of device capable of operating in a wireless environment. The term “base station”, which will be described later, is not limited, but includes Node B (Node-B), Evolved Node B (Evolved Node-B), Site Controller, AP (Access Point) ), Or any other type of interface device capable of operating in a wireless environment.
本明細書における開示は、認証およびアクセス・システムの一例としてＯｐｅｎＩＤプロトコルを使用し、そして他の認証およびアクセス・システムにも適用可能である。基本的エンティティおよびそれらの高位のフローが最初に説明され、方法の詳細な論議があとに続く。 The disclosure herein uses the OpenID protocol as an example of an authentication and access system and is applicable to other authentication and access systems. The basic entities and their high-level flows are described first, followed by a detailed discussion of the method.
図１は、限定的ではなく、クライアント／ユーザー・プラットフォーム１１０、アイデンティティ・プロバイダー１２０、ＰＣＡ（Ｐｒｉｖａｃｙ Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ：プライバシー認証局）１３０、およびサービス・プロバイダー１４０を含む認証およびアクセス・システム１００の一例である。クライアント／ユーザー・プラットフォーム１１０、アイデンティティ・プロバイダー１２０、およびサービス・プロバイダー１４０は、何れかの組み合わせの無線および有線の通信システムを通して互いに通信状態にある。クライアント／ユーザー・プラットフォーム１１０はさらに、ＰＣＡ１３０と通信状態にあり、ＰＣＡ１３０は例えば証明を保存する格納媒体１６０と通信状態にある。
FIG. 1 is an example of an authentication and
クライアント／ユーザー・プラットフォーム１１０は、ＷＴＲＵ、基地局、コンピューティング・プラットフォーム、または認証を必要とする場合がある何れのデバイスでもあることができる。クライアント／ユーザー・プラットフォーム１１０は、限定的ではなく、クライアント／ユーザー・プラットフォーム１１０のためのデータに対する、遠隔証明機能ならびにシール機能および結合機能を提供するＴＰＭ１１５を含む。ＴＰＭ１１５は、鍵、パスワード、ディジタル証明書を保存するマイクロコントローラーであり、そして暗号化鍵を生成させることが可能である。これはマザーボードに取り付けられるか、またはシステムのチップセットに集積され、そしてこれらの機能を必要とする何れのコンピューティング・デバイスにおいても使用することができる。ＴＰＭ１１５は、外部のソフトウェア攻撃および物理的改ざん、ならびに盗聴から、そこに保存された情報をより安全にすることを確実にする。ブート・シーケンスの間に構成要素に関して採られた測定値が参照測定値に対して予期された通りでないなら、ＴＰＭ１１５またはクライアント／ユーザー・プラットフォーム１１０の中のデータおよび秘密へのアクセスを拒絶することができる。その結果、安全な電子メール、安全なウェブ・アクセス、およびデータのローカルな保護などの重要なアプリケーションおよび能力をより以上に安全にする。本明細書においては信頼できるプラットフォーム・モジュールが議論されるが、例えば移動体の信頼できるモジュールなどの、他の代替の信用センターを使用することができる。
The client /
ＴＰＭ１１５は２０４８ビットのＲＳＡ公開および秘密鍵の組であるＥＫ（Ｅｎｄｏｒｓｅｍｅｎｔ Ｋｅｙ：エンドースメント鍵）を使用し、これは製造時にチップ上にランダムに生成されそして変更することはできない。秘密鍵はチップから決して分離せず、一方公開鍵はチップに送られた機密データの証明のためおよび暗号化のために使用される。ＥＫの公開の部分は一般に、証明の目的のためのＥＫ証明書によってＰＣＡ１３０によって既知である。一般にＴＰＭ１１５が、例えばアイデンティティ・プロバイダーなどの検証機構に対して自身を認証する必要があるときは常に、それは、ＡＩＫと呼ばれる第２のＲＳＡ鍵の組を生成させ、ＡＩＫ公開鍵をＰＣＡ１３０に送り、そして対応するＥＫに対してこの公開鍵を認証する。ＰＣＡ１３０はその一覧表中にこのＥＫを見出したなら、ＰＣＡ１３０はＴＰＭ１１５のＡＩＫに関する証明書を発行する。そしてＴＰＭ１１５は、アイデンティティ・プロバイダー１２０にこの証明書を提供し、そして自身を認証することができる。
The TPM 115 uses 2048 (Endorment Key), which is a 2048 bit RSA public and private key pair, which is randomly generated on the chip at the time of manufacture and cannot be changed. The private key is never separated from the chip, while the public key is used for proof and encryption of sensitive data sent to the chip. The public part of the EK is generally known by the PCA 130 by means of an EK certificate for certification purposes. In general, whenever the TPM 115 needs to authenticate itself to a verification mechanism, such as an identity provider, it generates a second RSA key set called AIK and sends the AIK public key to the PCA 130, Then, this public key is authenticated to the corresponding EK. If the PCA 130 finds this EK in the list, the PCA 130 issues a certificate regarding the AIK of the TPM 115. The TPM 115 can then provide this certificate to the
本明細書において述べられるように、ＡＩＫ（少なくともＡＩＫ中に一体化された識別子）は少なくとも本明細書において説明されるチケットの一部を表す。ＡＩＫのチケットとしての利用はしかしながら、ＴＰＭ１１５によって制限される。したがって、ＣｅｒｔｉｆｙＫｅｙ動作と呼ばれる間接的解決方法を使用して、署名鍵が、ＴＰＭ１１５によって生成され、そしてＡＩＫを用いてそれに署名することによって証明される。この鍵は、ＣＳＫ（Ｃｅｒｔｉｆｉｅｄ Ｓｉｇｎｉｎｇ Ｋｅｙ：証明された署名鍵）と呼ばれる。ＣＳＫおよびＡＩＫは、ＡＩＫの正当性を保証するＰＣＡと共に、本明細書において説明されるチケットの一部を構成する。
As described herein, AIK (at least an identifier integrated into AIK) represents at least a portion of the ticket described herein. However, the use of AIK as a ticket is limited by the
クライアント／ユーザー・プラットフォーム１１０はまた、サービス・アクセスに対する信用情報またはチケットを生成させるＴｉｃｋｅｔＳｅｒｖｅｒ１５０を含む。ＴｉｃｋｅｔＳｅｒｖｅｒ１５０はユーザーを認証する。ＴｉｃｋｅｔＳｅｒｖｅｒ１５０は、プラットフォーム証明の信頼できるコンピューティングを使用して、クライアント／ユーザー・プラットフォーム１１０およびそれ自身を、アイデンティティ・プロバイダー１２０に向かって正当化する。ＴｉｃｋｅｔＳｅｒｖｅｒ１５０は現在の非信頼済みＯｐｅｎＩＤ構造においては存在せず、単純にローカルな信用情報格納装置としての役割を果す。より多くのセキュリティ重要情報および動作がＴｉｃｋｅｔＳｅｒｖｅｒ１５０に集中化されているため、ＡＩＫ証明書およびＣＳＫを適切に取り扱いそしてそれらを他のプラットフォームに拡散させることがないこと、チケットおよび信用情報を保護すること、ユーザー承認によりすべての信用情報に関するセキュリティに緊要な何れの動作をも保護すること、一般的ウェブ・ブラウザーに直接的に統合されそしてそれらによってアクセスされるべき安全なオプションを提供すること、およびプラットフォーム正当化データを収集し、処理し、送付すること、が信頼できねばならない。本明細書においてはこれがさらに詳細に開示される。
The client /
ユーザーは、ＴＰＭ１１５において生成されたＡＩＫを証明するためにＰＣＡ１３０を選択せねばならない。ＰＣＡ１３０は、すべての識別子関連情報を保持することができ、そしてこの識別子関連情報の非公開性を確実にするために契約上の方策が講じられねばならない。ＰＣＡ１３０にてＡＩＫを証明した後に、ユーザーはアイデンティティ・プロバイダー１２０を選択し、主張された識別子を提供させることができる。請求された識別子は、ユーザーによって選択されたＵＲＩによって表される。そのような請求された識別子を登録するために、ユーザーは正当なＡＩＫ証明書をアイデンティティ・プロバイダー１２０に提供せねばならない。これは本明細書においてさらに詳細に開示される。
The user must select
アイデンティティ・プロバイダー１２０には、最少量の識別子関連情報のみしか提示されない場合がある。ユーザーは、ＰＣＡ１３０にて提供された何れの情報をアイデンティティ・プロバイダー１２０に露出することができ、露出することになるかを決定することができる。関係者の間の協調を確実にするために契約上の方策が講じられねばならず、そうでなければ不正なＰＣＡが相違するユーザーのものである識別子を証明してしまうかも知れない。ＰＣＡ１３０はアイデンティティ・プロバイダー１２０にユーザーの実際の識別子を露出することにはならないため、アイデンティティ・プロバイダー１２０は種々の要求を一つの識別子にリンクさせることはできないであろう。
Only a minimal amount of identifier-related information may be presented to the
ＰＣＡ１３０は、主張された識別子を実際の識別子に転換することが可能な唯一の事例（ｉｎｓｔａｎｃｅ）である。（一意な）ＥＫ証明書をＡＩＫに対応付ける安全にされたデータベースを保つことによって、容易にこれを為すことができる。ＡＩＫ証明の間に使用されるＥＫ証明書は、ＴＰＭ１１５すなわちクライアント／ユーザー・プラットフォーム１１０の疑う余地のない識別を可能とする（１人のユーザーのみが、これがそのユーザーに転換するプラットフォーム１１０への物理的アクセス権を有すると仮定して）。
サービス・プロバイダー１４０のみが、アイデンティティ・プロバイダーがサイトに対してログインすることを可能にさせる。サービス・プロバイダー１４０は例えば、最初のページ上にＯｐｅｎＩＤログイン・ロゴを有することができる。ユーザー／クライアントによって使用されるアイデンティティ・プロバイダー１２０は、サービス・プロバイダー１４０の既知のかつ受容されたアイデンティティ・プロバイダーの一覧表中になければならない。
Only the service provider 140 allows the identity provider to log into the site. The service provider 140 may have an OpenID login logo on the first page, for example. The
ここで図２を参照すると、図１において開示されたシステム１００に対する高位の信号フロー２００の一例が示される。本明細書において議論されるように、クライアント／ユーザーまたはユーザー・プラットフォーム２１０、サービス・プロバイダー２１５、およびアイデンティティ・プロバイダー２２０（ＯｐｅｎＩＤ Ｐｒｏｖｉｄｅｒの一例として示される）が互いの間の通信のために構成される。
Referring now to FIG. 2, an example of a high
クライアント／ユーザー・プラットフォーム２１０は、ウェブ・ブラウザー２２５を使用して、アクセス・ウェブページ・メッセージ２２７を介してサービス・プロバイダー・ウェブページ（ｉｎｄｅｘ．ｊｓｐ２３５と識別して）にアクセスする。クライアント／ユーザー２１０が彼の、例えばＯｐｅｎＩＤ ＵＲＩを使用してログインすることを欲したなら、サービス・プロバイダー２１５でのｉｎｄｅｘ．ｊｓｐページ２３５は、ＯｐｅｎＩＤログオン様式メッセージ２２９を介してそのＵＲＩを要求し、そしてその結果ＯｐｅｎＩＤ識別子メッセージ２３１を介して請求された識別子を提供するＯｐｅｎＩＤプロバイダー２２０のアドレスを検索する。
Client /
次にサービス・プロバイダー２１５は、ＯｐｅｎＩＤプロバイダー２２０とのアソシエーション（association）の形成を試みる。ＯｐｅｎＩＤプロトコルに従って、サービス・プロバイダー２１５は、アソシエーションメッセージ２４１を介してＯｐｅｎＩＤプロバイダー２２０とアソシエーションする。アソシエーションメッセージ２４１は、要求、主張された識別子、および認証に成功した場合に、クライアント／ユーザー・プラットフォーム２１０に対してそこにＯｐｅｎＩＤプロバイダー２２０がリダイレクト・メッセージ２４７を送ることになる、アソシエーションメッセージ２４３を介するリターンＵＲＬ、の安全な交換を含む。これは、サーバー・プロバイダー２１５にてｃｏｎｓｕｍｅｒ＿ｒｅｄｉｒｅｃｔ．ｊｓｐ２４０により、およびＯｐｅｎＩＤプロバイダー２２０にてｐｒｏｖｉｄｅｒ．ｊｓｐ２４５によって実行される。アソシエーションの後に、クライアント／ユーザー・プラットフォーム２１０は、ＯｐｅｎＩＤプロバイダーへのリダイレクト・メッセージ２４９を介してＯｐｅｎＩＤプロバイダー２２０のｐｒｏｖｉｄｅｒ．ｊｓｐウェブページ２４５にリダイレクトされる。
The
次にＯｐｅｎＩＤプロバイダー２２０は、ｐｒｏｖｉｄｅｒ．ｊｓｐウェブページ２４５からｐｒｏｖｉｄｅｒ＿ａｕｔｈｏｒｉｚａｔｉｏｎ．ｊｓｐウェブページ２５５に切り替わり、クライアント／ユーザー・プラットフォーム２１０を認証する。ユーザーは、ｐｒｏｖｉｄｅｒ＿ａｕｔｈｏｒｉｚａｔｉｏｎ．ｊｓｐウェブページ２５５上のリンクをクリックすることによって、要求を起動する。これは新しい背景のスレッドＴＴｖｅｒｉｆｉｅｒ２５８を始動し、チャレンジメッセージ２５２を介してＴｉｃｋｅｔＳｅｒｖｅｒ２５０にチャレンジする。ｐｒｏｖｉｄｅｒ＿ａｕｔｈｏｒｉｚａｔｉｏｎ．ｊｓｐウェブページ２５５は、クライアント／ユーザー・プラットフォーム２１０をｐｒｏｖｉｄｅｒ．ｊｓｐウェブページ２４５にリダイレクトして戻し、そこでＴＴｖｅｒｉｆｉｅｒ２５８を待って、チャレンジ応答メッセージ２５４において提供されたチャレンジの結果を完成させそして審査する。本明細書において説明されるように、ＴｉｃｋｅｔＳｅｒｖｅｒ２５０は、ＴＰＭの機能性を使用して、チケットを含む適切な応答を生成させ、そして一般に、ＴＰＭ２５０、ＰＣＡ２７５、および例えば証明を保持する格納媒体２８０と対話する。
Next, the
認証に成功したと仮定すると、ｐｒｏｖｉｄｅｒ．ｊｓｐウェブページ２４５は、リダイレクション・メッセージ２６２をクライアント／ユーザー・プラットフォーム２１０に送る。リダイレクション・メッセージ２６２は、サービス・メッセージ２６４へのリダイレクトを介して、サービス・プロバイダー２１５にてｃｏｎｓｕｍｅｒ＿ｒｅｔｕｒｎｕｒｌ．ｊｓｐページ２６５にクライアント／ユーザー・プラットフォーム２１０をリダイレクトする。ｃｏｎｓｕｍｅｒ＿ｒｅｔｕｒｎｕｒｌ．ｊｓｐページ２６５は、リダイレクトが関連ＯｐｅｎＩＤプロバイダー２２０から来ていることをチェックし、そしてサービス・メッセージ２６７を介してクライアント／ユーザー・プラットフォーム２１０にアクセスを与える。
Assuming that authentication was successful, provider. The
ここで図３（ａ）および図３（ｂ）を参照すると、ＴｉｃｋｅｔＳｅｒｖｅｒ３０５およびＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０の間の信号フローチャート３００が示される。ＴｉｃｋｅｔＳｅｒｖｅｒ３０５、ならびにＰＣＡ３１５、証明格納媒体３２０、およびＴＰＭ３２５の間の信号フローもまた示される。
Referring now to FIG. 3 (a) and FIG. 3 (b), a
ＴｉｃｋｅｔＳｅｒｖｅｒ３０５は、クライアント側にてサービス・アプリケーションとして動作する。それは、予め定義されたポート上にてリッスンし、チャレンジを待ち受ける。チャレンジメッセージ３２７（ユーザーが例えばＯｐｅｎＩＤ中にて使用することを欲した識別子、およびサービス・プロバイダーにて発行されたサービス要求を含む）を受信次第、ユーザーは、確認応答（ａｃｋｎｏｗｌｅｄｇｅ）メッセージ３２９を使用してチャレンジを明示的に許可することを要求される。ユーザーには、チャレンジを否定するオプションがある。否定されると、ＯｐｅｎＩＤ認証は失敗することになる。
The
チャレンジが受け入れられたなら、ユーザーは、所与の識別子に対応するＡＩＫに対してパスワードを入力し、かつＴｉｃｋｅｔＳｅｒｖｅｒ３０５にてＳＲＫ（Ｓｔｏｒａｇｅ Ｒｏｏｔ Ｋｅｙ：ストレージ・ルート鍵）パスワードを入力することによってＴＰＭ３２５利用を認証するように指示（ｐｒｏｍｐｔ）される。そしてＳＲＫは、ＴＰＭの安全にされた鍵にアクセスすることが可能なＴＰＭコマンド中に含められる。そしてＴｉｃｋｅｔＳｅｒｖｅｒ３０５は、証明書格納媒体３２０から、この識別子に対して以前取得されたＡＩＫ証明書を検索しようとする。これは集合的に３３５として示され、本明細書において議論するように、システム状態情報検索３４５およびＴＣＴｉｃｋｅｔ生成３５０のために必要である。証明書は、ＰＣＡ３１５などのＰＣＡを用いて以前のＡＩＫ証明から来る場合があり、その結果、証明格納媒体３２０などのシステム上のローカルな証明書格納装置から検索することが可能であり、あるいは証明書がローカルな格納装置において利用可能でない（またはローカルな格納装置におけるＡＩＫに対する証明書が期限切れかもしくは何れかの理由により無効になっている）なら、ＡＩＫによって表された識別子に対する新しい証明書をＰＣＡ３１５から要求することが可能である。具体的に言うと、証明書格納媒体３２０において証明書を見出すことができないなら、ユーザーはＰＣＡ３１５を選択し、ＡＩＫ証明処理を経て、そしてＡＩＫに対する証明書を獲得するために接続することができる。したがってユーザーは、ＴＰＭ３２５の正しい所有者パスワードを提供せねばならない。これが、ＴＰＭ３２５の所有者以外の人々による不正な識別子の生成を防止する。以下に示されるように、ユーザー入力はＴｉｃｋｅｔＳｅｒｖｅｒ３０５からＴＰＭ３２５に転送され、そこでパスワードが審査される。
If the challenge is accepted, the user enters the password for the AIK corresponding to the given identifier and uses the
チャレンジを受け入れたことに応答して、Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０はランダムなノンス３３７を生成する。ＴｉｃｋｅｔＳｅｒｖｅｒ３０５は、ノンス・メッセージ３３９を介してＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０からランダムなノンス３３７を受信する。ノンスを含む、システム構成について記述するＰＣＲ値のＡＩＫによって署名された引用（ｑｕｏｔｅ）Ｑが、ＴＰＭ３２５から検索され、集合的に３４５として示されるシステムの状態に関するステートメントが作成される。
In response to accepting the challenge,
ＴｉｃｋｅｔＳｅｒｖｅｒ３０５は次に、集合的に３５０として示されるようにＴＣＴｉｃｋｅｔを生成する。ＴＣＴｉｃｋｅｔ生成３５０は、要求および識別子に署名するために使用することができるＴＰＭによる新しい鍵（ＲＳＡ鍵の組）の生成にかかわる。本明細書において説明されるように、この新しい鍵は、ＣｅｒｔｉｆｙＫｅｙ動作を使用して、ＡＩＫを用いて証明される。すなわち、ＴＰＭはこの新たに生成された鍵の組に対する機能ＣｅｒｔｉｆｙＫｅｙを使用し、証明ステートメントおよび結合を生成させる。ここで結合とは、ＰＣＡからの、ＡＩＫへのおよびＡＩＫ証明書への信用のチェーンを結合することを意味する。新たに生成された鍵が成功裏に証明された場合に、それはＣＳＫと呼ばれる。ＴＰＭ中には複数のＣＳＫおよび複数のＡＩＫがある（またはＴＰＭによって保護された安全な格納装置においてＴＰＭにより安全にされている）場合がある。
The
ＴＣＴｉｃｋｅｔ３５０を検証するために必要とされる情報はＴＣＴｉｃｋｅｔ３５０に含まれ、受信した側（図３（ａ）および図３（ｂ）においてはＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０により表される）がＴＣＴｉｃｋｅｔ３５０を容易に検証することができる。平文（ｐｌａｉｎ―ｔｅｘｔ）ＭＬ（Ｍｅａｓｕｒｅｍｅｎｔ Ｌｏｇ：測定ログ）および引用Ｑと共に、ＴＣＴｉｃｋｅｔ３５０を含む応答がＴＣＴ，Ｑ，ＭＬメッセージ３５２を介してＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０に送り返される。ＣＨ＿ＲＥＳＰＯＮＳＥおよびＡＣＫメッセージ（集合的に３５１）は、次のメッセージがＴＣＴｉｃｋｅｔ３５０、引用、およびＭＬを含むことになるということを、受信側、すなわちＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０に通知するための、プロトコル信号方式メッセージである。この処理時点にては、図３（ａ）および図３（ｂ）が図２におけるＴＴＶｅｒｉｆｉｅｒ Ｔｈｒｅａｄ２５８の内部動作を表すことに注意するべきである。ＯｐｅｎＩＤプロバイダーは同時に複数の要求を扱うことができるため、リプレイアタック （ｒｅｐｌａｙ ａｔｔａｃｋ）を防止するために、要求するクライアントの何れもが、新しく、新鮮、かつ一意なチャレンジを持つことが確実でなければならない。
Information required to verify the
メッセージ３５５を介してＴＣＴｉｃｋｅｔ３５０を確認すると、ここでＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０は、以下のデータを有する。すなわち：アンチリプレイプロテクション（ａｎｔｉ−ｒｅｐｌａｙ ｐｒｏｔｅｃｔｉｏｎ）としてのノンス３３７を含む、ＴＰＭ３２５からのＡＩＫによって署名された引用、平文測定ファイル、署名された識別子文字列、署名された要求文字列、ＣＳＫの公開鍵部分、ＣＳＫの公開鍵部分上のＡＩＫ署名、およびＰＣＡ３１５によって発行されたＡＩＫ証明書を含むＴＣＴｉｃｋｅｔ３５０、である。クライアントを認証するために、Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅｒ３１０は、集合的に３６０として示された以下の情報をチェックする。すなわち：ＡＩＫ証明書の正当化（タイムスタンプ）、ＡＩＫ証明書上のＰＣＡ署名の検証、ＴＣＴｉｃｋｅｔ３５０中のＣＳＫ公開鍵ハッシュ上のＡＩＫ署名の検証、ＴＣＴｉｃｋｅｔ３５０中のサービス要求および識別子上の署名の検証、測定一覧表中のエントリーの正当化、および実際の（引用された）ＰＣＲの値がＭＬ（Ｍｅａｓｕｒｅｍｅｎｔ Ｌｉｓｔ：測定リスト）に対応することの検証、である。
When the
この検証処理における何かの項目が不良となると、そのクライアントは認証されないことになる。ＴｉｃｋｅｔＳｅｒｖｅｒ３０５およびＰＣＡ３１５によって、特定の信用情報チェーン、すなわちＡＩＫ証明書−証明済みＣＳＫ−署名済み要求が構築される。検証状態メッセージ３６５がユーザーに送られる。これはまた、例えば図２中のリダイレクション・メッセージ２６２により示される。この場合においては、メッセージ２６２が、サービス・プロバイダーのｒｅｔｕｒｎ＿ｕｒｌにユーザーのブラウザーをリダイレクトすることができるか、またはサービス・プロバイダーにてユーザーが認証される。上の検証の何れかが不良（証明書不良またはシステム完全性不良）となると、リダイレクトはＯｐｅｎＩＤプロバイダーの「認証失敗（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｆａｉｌｅｄ）」ページにユーザーを送ることになる。代替手段として、認証失敗の場合においてはＯｐｅｎＩＤプロバイダーにて失敗の原因を示す、カスタム設計された結果ページを生成することが可能である場合がある。これは、何れのモジュールまたはソフトウェアが完全性チェックに失敗したかをユーザーに示すことを含むことができ、そしてこれを利用して、彼のシステムを信頼に値する状態に戻すための次のステップをユーザーに提案するシステムにできるかも知れない。
If any item in this verification process becomes defective, the client is not authenticated. The
本明細書における開示から見て、例えばＰＣＡ２７５などのＰＣＡの役割は、信頼できるコンピューティングを採用する現今のチケット・システムにおいて果たされるものとは異なる。例えばＰＣＡ２７５は、特定のサービス・プロバイダー２１５によって使用される何れの部分的識別子に対しても一回だけ呼び出される必要があるようにすることができる。新規登録においては、クライアント／ユーザー・プラットフォーム２１０が、自身のプラットフォーム識別子を仮名の（ｐｓｅｕｄｏｎｙｍｏｕｓ）部分的識別子に関連付ける。ＰＣＡ２７５は、この仮名の識別子に対して証明書を提供し、そしてプラットフォーム識別子への仮名の関連付けを保存する。このデータは、個人的機密情報であり、そして従って保護されねばならない。別の例においては、ＰＣＡ２７５の位置付けが、現今のチケット・システムと比較した上での追加的オプションを可能とする。本明細書において開示される信用モデルおよび方法は、アイデンティティ・プロバイダー２２０およびユーザー選択以外の場所でのＰＣＡ２７５の設置を可能とする。
In view of the disclosure herein, the role of a PCA, such as PCA275, for example, differs from that played in modern ticket systems that employ reliable computing. For example, the
開示された方法および構造においてはユーザーは、アイデンティティ・プロバイダーによってＡＩＫ証明書が受容された任意の外部ＰＣＡを選択するか、またはアイデンティティ・プロバイダーによって直接的にもしくは間接的に提供されたＰＣＡ機能性を使用するかすることができる。この後者の例においては、ＰＣＡまたはＰＣＡ機能性がアイデンティティ・プロバイダー中に設置され、複雑性を減少させ、そしてウェブ様式を介してアイデンティティ・プロバイダーを用いての登録の継ぎ目のない置き換えを提供することができる。 In the disclosed method and structure, the user selects any external PCA for which the AIK certificate has been accepted by the identity provider, or the PCA functionality provided directly or indirectly by the identity provider. Can be used or not. In this latter example, PCA or PCA functionality is installed in the identity provider to reduce complexity and provide a seamless replacement of registration with the identity provider via a web style Can do.
その特定のセキュリティ構造により本開示は、識別子関連情報の暗号化に依存する信頼できるコンピューティングを採用する識別子管理システムに対する特定の脅威を軽減する。例えばＴｒｕｓｔｅｄ ＯｐｅｎＩＤにおいては、ＡＩＫ証明書は、クライアントにとって既知でありそして視認可能であり、したがってＡＩＫ証明書は、プライバシーを脅かす隠された情報を含むことはできない。 With its particular security structure, this disclosure mitigates certain threats to identifier management systems that employ reliable computing that relies on encryption of identifier-related information. For example, in Trusted OpenID, the AIK certificate is known and visible to the client, so the AIK certificate cannot contain hidden information that threatens privacy.
別の例においては、ＯｐｅｎＩＤ実施方法はＯｐｅｎＩＤプロバイダー・ログイン様式をユーザーに提示する。ユーザーがその人の信用情報を入力し、そしてＯｐｅｎＩＤプロバイダーがクライアントにクッキーを発行する。次にこのクッキーはあらゆるその後のＯｐｅｎＩＤによって可能にされたサービス・アクセスに使用される。これはＯｐｅｎＩＤプロトコルに対するいくつかの攻撃の原因となる場合がある：すなわち、（１）クライアントのＯｐｅｎＩＤプロバイダーへログインするために使用されるユーザー信用情報への直接攻撃（偽のＯｐｅｎＩＤプロバイダー・ページによるフィッシング（ｐｈｉｓｈｉｎｇ）は多量のユーザー信用情報を露出させ、なりすまし犯罪を可能にすることになる）、および、（２）認証後のクライアントのコンピューターからのクッキーの再使用、コピー、および盗用にかかわる、なりすまし犯罪の原因となる攻撃、である。 In another example, the OpenID enforcement method presents an OpenID provider login style to the user. The user enters his / her credit information and the OpenID provider issues a cookie to the client. This cookie is then used for service access enabled by any subsequent OpenID. This can lead to several attacks on the OpenID protocol: (1) Direct attack on user credentials used to log in to the client's OpenID provider (phishing with fake OpenID provider page) (Phishing) exposes a large amount of user credit information and enables impersonation crimes), and (2) impersonation involving the reuse, copying, and theft of cookies from client computers after authentication. It is an attack that causes crime.
両方の攻撃は、本明細書において提示される開示によって軽減される。すべてのユーザー・パスワードは、ローカルであり、ローカルな信頼できるＴｉｃｋｅｔＳｅｒｖｅｒのみに提供され、信用情報フィッシングの問題は排除される。その上仮名の識別子をプラットフォーム、例えばＴＰＭに結合し、その結果別のデバイスにそれらをコピーできないようにする。 Both attacks are mitigated by the disclosure presented herein. All user passwords are local and are provided only to the local trusted TicketServer, eliminating the problem of credential phishing. In addition, the pseudonym identifiers are bound to a platform, eg, TPM, so that they cannot be copied to another device.
その上クッキーはクライアントのプラットフォームに保存されることはない。これにより、ローカルな再使用の脅威を回避する。例えば複数の人々によって共有されたコンピューターを考慮されたい。人Ａが、彼のＯｐｅｎＩＤアカウントにログインし、そして署名して退出することを忘れると、人Ｂは、保存されたクッキーを使用し、Ａになりすますかもしれない。オプションとして、ここで開示された認証方法をＷｅｂ Ｂｒｏｗｓｅｒと継ぎ目なく統合することができる。ユーザーが、本明細書において開示される信頼できる方法を使用してサービスにアクセスすることを欲したときは常に、アイデンティティ・プロバイダーはＴｉｃｋｅｔＳｅｒｖｅｒに対して新しいチャレンジを生成する。信頼できるＴｉｃｋｅｔＳｅｒｖｅｒアプリケーションからの、チャレンジに答えるために必要なローカルのＡＩＫパスワードをクライアントに求める指示を、ユーザーは見るだけである。ＴｉｃｋｅｔＳｅｒｖｅｒはこのＡＩＫ認証秘密を保存することはない。同じプラットフォームの別のユーザーＢがサービスにアクセスすることを欲したなら、ＴｉｃｋｅｔＳｅｒｖｅｒは再びアイデンティティ・プロバイダーによってチャレンジされ、そしてＢはＡのローカルのＡＩＫパスワード（Ｂはこれを知らない）を提供せねばならない。狙いは、クライアントのプラットフォームに永久に保存されることのない一時的クッキーを持つことである。あるいは、デバイスへのユーザー認証の結合を生体認証を通して容易にすることができる。統合されたデバイスにおいては、透過的に、動的に、そしてしばしば、デバイスが常に真正の（ｂｏｎａ−ｆｉｄａ）ユーザーによって使用されていることを確実にするように、生体認証が為される。 In addition, cookies are not stored on the client's platform. This avoids local reuse threats. For example, consider a computer shared by multiple people. If person A forgets to log in to his OpenID account and sign and exit, person B may use a stored cookie to impersonate A. As an option, the authentication method disclosed herein can be seamlessly integrated with a Web Browser. Whenever a user wants to access a service using the reliable method disclosed herein, the identity provider creates a new challenge to the TicketServer. The user only sees instructions from the trusted TicketServer application to ask the client for the local AIK password needed to answer the challenge. TicketServer does not store this AIK authentication secret. If another user B on the same platform wants to access the service, the TicketServer is challenged again by the identity provider, and B must provide A's local AIK password (B does not know this) . The aim is to have a temporary cookie that is not permanently stored on the client's platform. Alternatively, user authentication coupling to the device can be facilitated through biometric authentication. In integrated devices, biometric authentication is done transparently, dynamically, and often to ensure that the device is always being used by a bona-fida user.
本明細書における開示は、目標プラットフォーム（アイデンティティ・プロバイダーの視点から見るとユーザー・プラットフォーム）およびユーザーがそれを解読し、そして認証トークンとしてそれを使用することができるような方法にて、発行されたクッキー上の暗号化を使用することができる。アイデンティティ・プロバイダーは、秘密鍵を使用してクッキーを暗号化し、クライアント側のＴｉｃｋｅｔＳｅｒｖｅｒに、公開のＣＳＫによって保護されて、それを送る。ＣＳＫは任意の量のデータの全体の暗号化を意味するものではないが、クッキーを暗号化するために使用される秘密鍵を暗号化するためにはそれを使用することができる。秘密鍵は、対称の、または非対称の鍵であることができる。 The disclosure herein was issued in such a way that the target platform (the user platform from the perspective of the identity provider) and the user can decrypt it and use it as an authentication token Encryption over cookies can be used. The identity provider encrypts the cookie using the private key and sends it to the client-side TicketServer, protected by a public CSK. CSK does not mean the entire encryption of any amount of data, but it can be used to encrypt the secret key used to encrypt the cookie. The secret key can be a symmetric or asymmetric key.
そして必要であるときに、ＴＰＭを使用してクッキーを解読することができる。解読は、ＣＳＫ利用に対してユーザーが（ローカルの）ＣＳＫ秘密を用いて認証することを必要とする。ＴｉｃｋｅｔＳｅｒｖｅｒは、クッキーが暗号化された状態で保存され、そして必要な場合にのみ、解読されることを確実にする。 And when necessary, the TPM can be used to decrypt the cookie. Decryption requires the user to authenticate with a (local) CSK secret for CSK usage. The TicketServer ensures that the cookie is stored in an encrypted state and can only be decrypted when needed.
さらなるアプリケーションにおいては、開示された認証およびアクセス方法は、結合された認証ならびにアクセスおよび認可方法に対して使用することができる。ある主要検索エンジン会社は、最近、ウェブ・サービスにアクセスするときに、継ぎ目のないユーザー体験を提供するために、ＡＰＩ認可方法の一例である、ＯＡｕｔｈに対する支援を発表した。ユーザーは、サービス・プロバイダーが提供するアクセス・リンクを使用して、ウェブ・サービスにアクセスし、そして同時に、例えばＯＡｕｔｈを介してそのサービス・プロバイダーが提供するサービスへのウェブ・アプリケーションのアクセスを許可することになる。ＯｐｅｎＩＤは、集中的に保存された識別子を用いてユーザーを認証するために使用される。ＯＡｕｔｈは、ウェブ・サービスがカレンダー、ｄｏｃｓ．などのユーザーのデータにアクセスすることを認可するために使用される。一つのステップにおける両方のプロトコルの組み合わせは、ユーザー経験に関する一元化署名を改善し、かつ異なった利用者データ、例えば、マッシュ・アップ（ｍａｓｈ−ｕｐ）、ダッシュボード（ｄａｓｈｂｏａｒｄ）などへのアクセスを必要とする、新しいウェブ・サービスを可能にする。 In further applications, the disclosed authentication and access methods can be used for combined authentication and access and authorization methods. A major search engine company recently announced support for OAuth, an example of an API authorization method, to provide a seamless user experience when accessing web services. The user uses the access link provided by the service provider to access the web service and at the same time allows the web application to access the service provided by the service provider, eg via OAuth It will be. OpenID is used to authenticate a user with a centrally stored identifier. OAuth is a web service that uses calendars, docs. Used to authorize access to user data such as. The combination of both protocols in one step improves the centralized signature on the user experience and requires access to different user data, such as mash-up, dashboard, etc. Enable new web services.
ユーザーのＴＰＭを、例えばＯｐｅｎＩＤチャレンジのみとしてアイデンティティ・プロバイダーに署名させる代わりに、ＴＰＭは、ウェブ・アプリケーションの要求を通してアイデンティティ・プロバイダーによって提示される、結合された、例えばＯｐｅｎｌＤ／ＯＡｕｔｈチャレンジに署名することになる。データへのアクセスの受容と並んで、ユーザー識別および認可がＴＰＭによって安全に署名される。本明細書において開示されるように、ユーザーのためのセキュリティは、（１）ログインおよび認可をハードウェアＴＰＭに結合すること、および（２）クライアント上にて動作する悪意のあるソフトウェアによる機密のデータの盗用を回避するために、ＯｐｅｎＩＤ／ＯＡｕｔｈプロバイダーによるプラットフォーム完全性検証を提供すること、によって改善される。完全性検証はまた、ウェブ・アプリケーションに対するセキュリティの水準を増大させる。完全性検証が証明された状態にあるクライアントのみに、ウェブ・サービスへのアクセス権を与えることができる。これにより、セキュリティおよび秘密が重要なアプリケーションに対して新しいウェブ・サービスの確立を可能にする。例えばＯＡｕｔｈの、認可プロバイダーのトークン・アクセスが、一意に特定可能なＴＰＭによって署名されるという事実から、説明された方法は否認防止を提供する。これは、ウェブ・アプリケーションのサービス・プロバイダーが実施することができる課金処理を容易にする。署名により、ユーザーがウェブ・サービスを要求しそしてアクセスしたということをウェブ・アプリケーション・プロバイダーが立証することを可能にする。 Instead of having the user's TPM sign the identity provider, eg, only as an OpenID challenge, the TPM will sign a combined, eg, OpenD / OAuth challenge, presented by the identity provider through a web application request. Become. Along with accepting access to data, user identification and authorization are securely signed by the TPM. As disclosed herein, security for users includes (1) coupling login and authorization to a hardware TPM, and (2) sensitive data by malicious software running on the client. By providing platform integrity verification by the OpenID / OAuth provider to avoid theft. Integrity verification also increases the level of security for web applications. Only clients in a state where integrity verification has been certified can be given access to the web service. This allows the establishment of new web services for applications where security and secrecy are important. The described method provides non-repudiation due to the fact that, for example, OAuth's authorization provider token access is signed by a uniquely identifiable TPM. This facilitates a billing process that can be performed by a web application service provider. The signature allows the web application provider to prove that the user has requested and accessed the web service.
ＴＰＭ準拠のユーザー認証は、プラットフォームの識別子およびアイデンティティ・プロバイダーの間のリンケージを可能にする。アイデンティティ・プロバイダーは、所与のプラットフォームに対して登録された識別子のデータベースを維持することが必要である。登録された識別子の内の１つを使用する別のプラットフォームからのログインの試みが検出されたときは常に、アイデンティティ・プロバイダーは：（１）認証を拒否することが可能である／拒否せねばならない、または（２）正規の所有者にその識別子を通知することができる。アイデンティティ・プロバイダーは、所与のプラットフォーム信用情報により攻撃者から正規のユーザーを容易に区別することが可能である。 TPM compliant user authentication allows linkage between platform identifiers and identity providers. An identity provider is required to maintain a database of registered identifiers for a given platform. Whenever a login attempt from another platform using one of the registered identifiers is detected, the identity provider will: (1) be able to / reject authentication Or (2) the authorized owner can be notified of the identifier. An identity provider can easily distinguish legitimate users from attackers with given platform credentials.
さらなる例においては、方法は証明（ａｔｔｅｓｔａｔｉｏｎ）メカニズムを含むことができる。アイデンティティ・プロバイダーは、ユーザー・プラットフォームのシステム状態についての情報を提供するようにユーザーにチャレンジすることができる。システムが信頼に値する状態にあるなら、アクセスは許可されることになる。これにより、「信頼に値する（ｔｒｕｓｔｗｏｒｔｈｙ）」システムだけがウェブ・サービスにアクセスすることができるように、ウェブ・アプリケーションのためのセキュリティをてこ入れする。 In a further example, the method can include an attestation mechanism. The identity provider can challenge the user to provide information about the system status of the user platform. If the system is in a trustworthy state, access will be granted. This leverages security for web applications so that only “trustworthy” systems can access web services.
さらなる例においては、ユーザー側にて、入来する識別子認証要求をリッスンし、そしてそれらをＴＰＭに転送するサービス・アプリケーションを有する代わりに、継ぎ目のないブラウザー統合を使用することができる。適切な機能性を実施するブラウザー拡張を使用することによって、これを達成することができる。アイデンティティ・プロバイダーは、サインイン（ｓｉｇｎ−ｉｎ）・ページのＨＴＭＬコード内にてチャレンジを発行する。ブラウザー拡張は、この情報を読み出し、そして必要なデータをＴＰＭに転送することができる。ＴＰＭは、今度は署名されたチケットを生成し、そしてそれをブラウザー拡張に返送する。次に拡張は署名されたチケットを含む正しいＨＴＴＰＳ応答をアイデンティティ・プロバイダーに発行することができる。この場合において、図３（ａ）および図３（ｂ）のフローは、別個の拡張ではなく継ぎ目のない統合ブラウザー拡張により扱われるであろう。この解決方法は、より優れた携帯性（ｐｏｒｔａｂｉｌｉｔｙ）およびより良いユーザー体験を可能にする。 In a further example, instead of having a service application on the user side that listens for incoming identifier authentication requests and forwards them to the TPM, seamless browser integration can be used. This can be achieved by using browser extensions that implement the appropriate functionality. The identity provider issues a challenge in the HTML code of the sign-in page. The browser extension can read this information and transfer the necessary data to the TPM. The TPM now generates a signed ticket and sends it back to the browser extension. The extension can then issue a correct HTTPS response containing the signed ticket to the identity provider. In this case, the flow of FIGS. 3 (a) and 3 (b) would be handled by a seamless integrated browser extension rather than a separate extension. This solution allows for better portability and a better user experience.
一般に、ユーザー・プラットフォームからの信頼できる認証およびアクセスのための方法は、予め定められた識別子を使用してサービス・プロバイダーにログオンすることを備え、ここで、ユーザー・プラットフォームはその予め定められた識別子によって指し示されたアイデンティティ・プロバイダーの方に、サービス・プロバイダーによってリダイレクトされる。方法はさらに、アイデンティティ・プロバイダーから認証チャレンジを受信すること、そしてその認証チャレンジに対応して、ユーザー・プラットフォームが認証チャレンジを受け入れたという条件にてＴＰＭに準拠したチケットを送信することを含む。方法はさらに、アイデンティティ・プロバイダーから成功したチケット検証を受信した際に、サービス・プロバイダーにアクセスすることを含む。予め定められた識別子は、ユニバーサルリソース識別子（ＵＲＩ：ｕｎｉｖｅｒｓａｌ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）によって表される。方法はさらに、ユーザー・プラットフォームおよびチケットを正当化するチケットを生成させることを含む。認証チャレンジは、少なくとも予め定められた識別子およびサービス種別要求を含む。方法はさらに、予め定められた識別子およびサービス要求に署名するための証明された署名鍵を生成させることを備える。 In general, a method for trusted authentication and access from a user platform comprises logging on to a service provider using a predetermined identifier, where the user platform is the predetermined identifier. Redirected by the service provider towards the identity provider pointed to by The method further includes receiving an authentication challenge from the identity provider and sending a TPM compliant ticket in response to the authentication challenge provided that the user platform has accepted the authentication challenge. The method further includes accessing the service provider upon receiving a successful ticket validation from the identity provider. The predetermined identifier is represented by a universal resource identifier (URI). The method further includes generating a ticket that justifies the user platform and the ticket. The authentication challenge includes at least a predetermined identifier and a service type request. The method further comprises generating a predetermined identifier and a certified signing key for signing the service request.
方法は、予め定められた識別子に対応するＡＩＫに対するパスワード、およびＴＰＭ利用を認証するための格納ルート鍵パスワードを提供することを備える。またそれは、ＡＩＫに対応する証明書を獲得することを含む。方法はさらに、以前に取得した証明書が入手不可という条件にて、証明書を生成させることを備える。方法はさらに、肯定的なチャレンジ確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）に対応してノンスを受信すること、およびＡＩＫによって署名された引用（ｑｕｏｔｅ）をＴＰＭから生成させることを備え、ここでＡＩＫによって署名された引用はノンスを含む。チケットはさらに、ＣＳＫによって署名された予め定められた識別子、ＣＳＫによって署名された要求、ＣＳＫ公開鍵、およびＰＣＡによって発行されたＡＩＫ証明書、を備える。 The method comprises providing a password for the AIK corresponding to the predetermined identifier and a stored root key password for authenticating TPM usage. It also includes obtaining a certificate corresponding to the AIK. The method further comprises generating a certificate on condition that a previously acquired certificate is not available. The method further comprises receiving a nonce in response to a positive challenge acknowledgment and generating a quote signed from the AIK from the TPM, wherein the quote signed by the AIK Includes nonce. The ticket further comprises a predetermined identifier signed by the CSK, a request signed by the CSK, a CSK public key, and an AIK certificate issued by the PCA.
方法はさらに認証チャレンジに対応して、ユーザー・プラットフォームが認証チャレンジを受け入れたという条件にて、ＴＰＭからのＰＣＲのＡＩＫによって署名された引用、および測定ログを送信することを備える。成功したチケット検証は、ＡＩＫ証明書のタイムスタンプの正当化、ＡＩＫ証明書上のＰＣＡ署名の検証、ＣＳＫ公開鍵上のＡＩＫ署名の検証、ＣＳＫによって署名された予め定められた識別子の検証、ＣＳＫによって署名された要求の検証、測定ログの正当化、および引用の検証、を含む。 The method further comprises sending a PCR AIK signed citation from the TPM and a measurement log in response to the authentication challenge, provided that the user platform has accepted the authentication challenge. Successful ticket verification consists of justifying the AIK certificate time stamp, verifying the PCA signature on the AIK certificate, verifying the AIK signature on the CSK public key, verifying the predetermined identifier signed by the CSK, CSK Verification of the request signed by, validation of the measurement log, and verification of the citation.
方法はさらに、その後のサービス・プロバイダー・アクセスに対して、証明された署名鍵によって保護された、暗号化されたクッキーを受信することを備える。認証チャレンジは認可チャレンジを含む。方法はさらに、証明（ａｔｔｅｓｔａｔｉｏｎ）チャレンジを備える。 The method further comprises receiving an encrypted cookie protected by a certified signing key for subsequent service provider access. The authentication challenge includes an authorization challenge. The method further comprises an attestation challenge.
信頼できる認証およびアクセスを支援するための装置は、予め定められた識別子を使用するサービス・プロバイダーにアクセスするように構成されたインターフェイス・モジュールを含み、ここで装置は、その予め定められた識別子によって指し示されたアイデンティティ・プロバイダーの方に、サービス・プロバイダーによって、リダイレクトされる。装置はまた、認証チャレンジが受け入れられたという条件にて、ＴＰＭに準拠したチケットを送信することによって認証チャレンジに応答するように構成されたチケット・サーバーを含む。インターフェイス・モジュールはまた、アイデンティティ・プロバイダーから成功したチケット検証を受信し、そしてサービス・プロバイダー上のサービスにアクセスするように構成される。チケット・サーバーはさらに、ＣＳＫによって署名された予め定められた識別子、ＣＳＫによって署名された要求、ＣＳＫ公開鍵、およびＰＣＡによって発行されたＡＩＫ証明書を含む、チケットを生成させるように構成される。チケット・サーバーはさらに、ＴＰＭからのＡＩＫによって署名された引用、および測定ログを獲得するように構成される。チケット・サーバーはさらに、ノンスを受信し、そしてＴＰＭからＡＩＫによって署名された引用を生成させるように構成され、ここでＡＩＫによって署名された引用がノンスを含む。 An apparatus for supporting trusted authentication and access includes an interface module configured to access a service provider that uses a predetermined identifier, wherein the apparatus is configured with the predetermined identifier. Redirected by the service provider towards the pointed identity provider. The apparatus also includes a ticket server configured to respond to the authentication challenge by sending a TPM-compliant ticket, provided that the authentication challenge is accepted. The interface module is also 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 that includes a predetermined identifier signed by the CSK, a request signed by the CSK, a CSK public key, and an AIK certificate issued by the PCA. The ticket server is further configured to obtain a quote signed by the AIK from the TPM and a measurement log. The ticket server is further configured to receive the nonce and generate a quote signed by the AIK from the TPM, where the quote signed by the AIK includes the nonce.
本明細書において開示されるように、ユーザー・クライアント／プラットフォームは、例えば無線通信システムにおいて使用することができるＷＴＲＵまたは基地局であることができる。一例であり、他の無線通信システムにもまた適用可能であるが、図４は、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）４０５を含むＬＴＥ無線通信システム／アクセス・ネットワーク４００を示す。Ｅ−ＵＴＲＡＮ４０５は、ＷＴＲＵ４１０および幾つかのｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ：発展形ノードＢ）４２０を含む。ＷＴＲＵ４１０は、ｅＮＢ４２０と通信状態にある。ｅＮＢ４２０はＸ２インターフェイスを使用して互いにインターフェイスする。それぞれのｅＮＢ４２０は、Ｓ１インターフェイスを通してＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ：モビリティ管理エンティティ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ ＧａｔｅＷａｙ：サービング・ゲートウェイ）４３０とインターフェイスする。図４においては１つのＷＴＲＵ４１０および３つのｅＮＢ４２０が示されるが、無線通信システム・アクセス・ネットワーク４００においては、無線のそして有線のデバイスの何れの組み合わせをも含むことができることは、明らかであるべきである。
As disclosed herein, a user client / platform can be a WTRU or a base station that can be used, for example, in a wireless communication system. FIG. 4 shows an LTE wireless communication system /
図５は、ＷＴＲＵ４１０、ｅＮＢ４２０、およびＭＭＥ／Ｓ−ＧＷ４３０を含む、ＬＴＥ無線通信システム５００の代表的ブロック図である。図５に示されるように、ＷＴＲＵ４１０、ｅＮＢ４２０、およびＭＭＥ／Ｓ−ＧＷ４３０は、リンケージを使用するＢＤ（Ｂｌｉｎｄ Ｄｅｃｏｄｉｎｇ：ブラインド・デコード）の複雑性削減の方法を実行するように構成される。
FIG. 5 is a representative block diagram of an LTE
典型的なＷＴＲＵにおいて見出すことができる構成要素に加えてＷＴＲＵ４１０は、随意的に接続されたメモリ５２２を有するプロセッサー５１６、少なくとも１つの送受信機５１４、随意的な蓄電池５２０、およびアンテナ５１８を含む。プロセッサー５１６は、本明細書において開示される方法を実行するように構成される。送受信機５１４は、プロセッサー５１６およびアンテナ５１８と通信状態にあり、無線通信の送信および受信を容易にする。蓄電池５２０がＷＴＲＵ４１０において使用される場合には、送受信機５１４およびプロセッサー５１６に電力を供給する。
In addition to the components that can be found in a typical WTRU, the
典型的なｅＮＢにおいて見出すことができる構成要素に加えてｅＮＢ４２０は、随意的に接続されたメモリ５１５を有するプロセッサー５１７、送受信機５１９、およびアンテナ５２１を含む。プロセッサー５１７は、本明細書において開示される方法を実行するように構成される。送受信機５１９は、プロセッサー５１７およびアンテナ５２１と通信状態にあり、無線通信の送信および受信を容易にする。ｅＮＢ４２０は、随意的に接続されたメモリ５３４を有するプロセッサー５３３を含む、ＭＭＥ／Ｓ−ＧＷ４３０に接続される。
In addition to the components that can be found in a typical eNB, the
実施形態
１．予め定められた識別子を使用してサービス・プロバイダーにログオンするステップであって、ユーザー・プラットフォームは、前記予め定められた識別子によって指し示されるアイデンティティ・プロバイダーに前記サービス・プロバイダーによってリダイレクトされることを備えることを特徴とする前記ユーザー・プラットフォームからの信頼できる認証およびアクセスのための方法。
２．前記アイデンティティ・プロバイダーから認証チャレンジを受信するステップを備えることを特徴とする実施形態１に記載の方法。
2. 2. The method of
３．前記認証チャレンジに応答して、前記ユーザー・プラットフォームが前記認証チャレンジを受け入れたという条件にて、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：トラステッド・プラットフォーム・モジュール）に準拠したチケットを送信するステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 3. In response to the authentication challenge, the method includes a step of transmitting a ticket that is compliant with a Trusted Platform Module (TPM) on the condition that the user platform has accepted the authentication challenge. A method according to any one of the preceding embodiments.
４．前記アイデンティティ・プロバイダーから成功したチケット検証を受信した際に、前記サービス・プロバイダーにアクセスするステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 4). The method of any one of the preceding embodiments, comprising accessing the service provider upon receipt of a successful ticket verification from the identity provider.
５．前記予め定められた識別子がユニバーサルリソース識別子（ＵＲＩ：Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）によって表されることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 5. The method according to any one of the previous embodiments, wherein the predetermined identifier is represented by a Universal Resource Identifier (URI).
６．前記ユーザー・プラットフォームおよびチケットを正当化する前記チケットを生成させるステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 6). A method according to any one of the preceding embodiments, comprising generating the ticket to justify the user platform and ticket.
７．前記認証チャレンジは、少なくとも前記予め定められた識別子およびサービス要求の種別を含むことを特徴とする先行する実施形態の内の何れか１つに記載の方法。 7). The method of any one of the preceding embodiments, wherein the authentication challenge includes at least the predetermined identifier and a type of service request.
８．前記予め定められた識別子および前記サービス要求に署名するために、証明された署名鍵を生成させるステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 8). A method according to any one of the previous embodiments, comprising the step of generating a certified signature key to sign the predetermined identifier and the service request.
９．前記予め定められた識別子に対応するＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）のためのパスワード、およびＴＰＭ利用を認証するための格納ルート鍵パスワードを提供するステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 9. A previous implementation comprising the steps of providing a password for an AIK (Attestation Identity Key) corresponding to the predetermined identifier and a stored root key password for authenticating TPM usage A method according to any one of the forms.
１０．ＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）に対応する証明書を獲得するステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 10. A method according to any one of the preceding embodiments, comprising the step of obtaining a certificate corresponding to an AIK (Attestation Identity Key).
１１．以前に取得した証明書が入手不可という条件にて、証明書を生成させるステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 11. The method of any one of the preceding embodiments, comprising the step of generating a certificate on condition that a previously acquired certificate is not available.
１２．肯定的なチャレンジ確認応答に応答してノンスを受信するステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 12 9. The method as in any one of the preceding embodiments, comprising receiving a nonce in response to a positive challenge acknowledgment.
１３．ＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）によって署名された引用を前記ＴＰＭから生成させるステップであって、前記ＡＩＫによって署名された引用が前記ノンスを含むことを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 13. A preceding embodiment, characterized in that a citation signed by an AIK (Attestation Identity Key) is generated from the TPM, the citation signed by the AIK comprising the nonce. The method according to any one of the above.
１４．前記チケットは、ＣＳＫ（Ｃｅｒｔｉｆｉｅｄ Ｓｉｇｎｉｎｇ Ｋｅｙ：証明された署名鍵）によって署名された予め定められた識別子、ＣＳＫによって署名された要求、ＣＳＫ公開鍵、およびＰＣＡ（Ｐｒｉｖａｃｙ Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ：プライバシー認証局）によって発行されたＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）証明書、をさらに備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 14 The ticket is issued by a predetermined identifier signed by a CSK (Certified Signing Key), a request signed by the CSK, a CSK public key, and a PCA (Privacy Certification Authority) A method according to any one of the previous embodiments, further comprising an AIK (Attempt Identity Key) certificate.
１５．前記認証チャレンジに応答して、前記ユーザー・プラットフォームが前記認証チャレンジを受け入れたという条件にて、前記ＴＰＭからのＰＣＲ（Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒ：プラットフォーム構成レジスタ）のＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）によって署名された引用、および測定ログを送信するステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 15. In response to the authentication challenge, on the condition that the user platform has accepted the authentication challenge, an AIK (Attestation Identity Key) of the PCR (Platform Configuration Register) from the TPM The method according to any one of the previous embodiments, comprising sending a signed citation and a measurement log.
１６．前記成功したチケット検証は、前記ＡＩＫ証明書のタイムスタンプの正当化、前記ＡＩＫ証明書上のＰＣＡ署名の検証、前記ＣＳＫ公開鍵上のＡＩＫ署名の検証、前記ＣＳＫによって署名された予め定められた識別子の検証、前記ＣＳＫによって署名された要求の検証、前記測定ログの正当化、および前記引用の検証、を含むことを特徴とする先行する実施形態の内の何れか１つに記載の方法。 16. The successful ticket verification includes a time stamp justification of the AIK certificate, a PCA signature verification on the AIK certificate, an AIK signature verification on the CSK public key, and a predetermined signed by the CSK. 8. A method according to any one of the preceding embodiments, comprising verification of an identifier, verification of a request signed by the CSK, validation of the measurement log, and verification of the citation.
１７．その後のサービス・プロバイダー・アクセスのために、証明された署名鍵よって保護された暗号化されたクッキーを受信するステップを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 17. Receiving an encrypted cookie protected by a certified signing key for subsequent service provider access, according to any one of the preceding embodiments, characterized in that Method.
１８．前記認証チャレンジは、認可チャレンジを含むことを特徴とする先行する実施形態の内の何れか１つに記載の方法。 18. The method of any one of the previous embodiments, wherein the authentication challenge comprises an authorization challenge.
１９．証明チャレンジを備えることを特徴とする先行する実施形態の内の何れか１つに記載の方法。 19. A method according to any one of the previous embodiments, comprising a proof challenge.
２０．信頼できる認証およびアクセスを支援するための装置であって、前記プラットフォームが、予め定められた識別子を使用してサービス・プロバイダーにアクセスするように構成されたインターフェイス・モジュールを備えることであって、前記装置が、前記予め定められた識別子によって指し示されるアイデンティティ・プロバイダーに前記サービス・プロバイダーによってリダイレクトされること、を特徴とする装置。 20. An apparatus for supporting trusted authentication and access, wherein the platform comprises an interface module configured to access a service provider using a predetermined identifier, A device wherein the device is redirected by the service provider to an identity provider pointed to by the predetermined identifier.
２１．認証チャレンジが受け入れられたという条件にて、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：トラステッド・プラットフォーム・モジュール）に準拠したチケットを送信することによって前記認証チャレンジに応答するように構成されたチケット・サーバーを備えることを特徴とする実施形態２０に記載の装置。 21. Providing a ticket server configured to respond to the authentication challenge by sending a ticket compliant with a TPM (Trusted Platform Module) on the condition that the authentication challenge is accepted; Embodiment 21. The apparatus of embodiment 20 characterized.
２２．前記インターフェイス・モジュールは、前記アイデンティティ・プロバイダーから成功したチケット検証を受信し、そして前記サービス・プロバイダーにおけるサービスにアクセスするように構成されることを備えることを特徴とする実施形態２０または２１の何れかに記載の装置。 22. 21. Any of embodiments 20 or 21 comprising the interface module being configured to receive a successful ticket validation from the identity provider and to access a service at the service provider. The device described in 1.
２３．前記チケット・サーバーは、ＣＳＫ（Ｃｅｒｔｉｆｉｅｄ Ｓｉｇｎｉｎｇ Ｋｅｙ：証明された署名鍵）によって署名された予め定められた識別子、ＣＳＫによって署名された要求、ＣＳＫ公開鍵、およびＰＣＡ（Ｐｒｉｖａｃｙ Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ：プライバシー認証局）によって発行されたＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）証明書を含むチケットを生成させるようにさらに構成されることを特徴とする実施形態２０乃至２２の内の何れかに記載の装置。 23. The ticket server includes a predetermined identifier signed by a CSK (Certified Signing Key), a request signed by the CSK, a CSK public key, and a PCA (Privacy Certification Authority). 23. The apparatus as in any one of embodiments 20-22, further configured to generate a ticket that includes an AIK (Attestation Identity Key) certificate issued by.
２４．前記チケット・サーバーは、前記ＴＰＭからのＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）によって署名された引用、および測定ログを獲得するようにさらに構成されることを特徴とする実施形態２０乃至２３の内の何れかに記載の装置。 24. Embodiments 20 to 23, wherein the ticket server is further configured to obtain a quote and a measurement log signed by an AIK (Attestation Identity Key) from the TPM. The apparatus in any one of.
２５．前記チケット・サーバーは、ノンスを受信し、そしてＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：証明アイデンティティ鍵）によって署名された引用を前記ＴＰＭから生成させるようにさらに構成されることであって、前記ＡＩＫによって署名された引用が前記ノンスを含むことを特徴とする実施形態２０−２４の内の何れかに記載の装置。 25. The ticket server is further configured to receive a nonce and generate a quote signed from the TPM signed by an AIK (Attestation Identity Key) signed by the AIK 25. Apparatus according to any of embodiments 20-24, wherein a citation includes the nonce.
特徴および要素が上で特定の組み合わせにて記述されているが、それぞれの特徴または要素は、他の特徴および要素なしで単独にて、または他の特徴および要素のあるなしに拘わらず様々な組み合わせにて使用することができる。本明細書において提供される方法またはフローチャートは、汎用目的のコンピューターまたはプロセッサーによる実行のための、コンピューターにて読み取り可能な記憶装置媒体に組み込まれたコンピューター・プログラム、ソフトウェア、またはファームウェアにて実施することができる。コンピューターにて読み取り可能な記憶装置媒体の例としては、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ：リード・オンリー・メモリ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ランダム・アクセス・メモリ）、レジスタキャッシュ・メモリ、半導体メモリ・デバイス、内蔵ハード・ディスクおよび着脱可能ディスクなどの磁気媒体、磁気−光学媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ：ディジタル多用途ディスク）などの光学媒体が含まれる。 Although features and elements are described above in specific combinations, each feature or element may be used alone or in various combinations with or without other features and elements. Can be used. The methods or flowcharts provided herein are implemented in a computer program, software, or firmware embedded in a computer readable storage medium for execution by a general purpose computer or processor. Can do. Examples of computer-readable storage media include ROM (Read Only Memory), RAM (Random Access Memory), register cache memory, semiconductor memory device, Magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and DVDs (Digital Versatile Disks).
適当なプロセッサーの例としては、汎用プロセッサー、専用プロセッサー、従来のプロセッサー、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ：ディジタル・シグナル・プロセッサー）、複数のマイクロプロセッサー、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサー、コントローラー、マイクロコントローラー、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：特定用途向け集積回路）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ：フィールド・プログラマブル・ゲートアレイ）回路、他の何れかの種別のＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：集積回路）、および／または状態マシンが含まれる。 Examples of suitable processors include general purpose processors, dedicated processors, conventional processors, DSPs (Digital Signal Processors), multiple microprocessors, one or more microprocessors associated with a DSP core, Controller, microcontroller, ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array) circuit, any other type of IC (Integrated Circuit) circuit , And / or state machines.
ユーザー・プラットフォームは、ＷＴＲＵを含む多くのプラットフォームの内の何れであることもできる。ＷＴＲＵ、ＵＥ、端末、基地局（ｂａｓｅ ｓｔａｔｉｏｎ）、ＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワークコントーラー）、または任意のホスト・コンピューターにおいて使用するための無線周波数送受信機を実施するために、ソフトウェアに関連付けられたプロセッサーを使用することができる。ＷＴＲＵは、ハードウェアおよび／またはソフトウェアにて実施され、カメラ、ビデオ・カメラ・モジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロホン、テレビ送受信機、ハンズフリー受話器、キーボード、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））モジュール、ＦＭ（Ｆｒｅｑｕｅｎｃｙ Ｍｏｄｕｌａｔｅｄ：周波数変調）無線ユニット、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶ディスプレイ）表示ユニット、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ−Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ：有機発光ダイオード）表示ユニット、ディジタル音楽プレーヤー、メディア・プレーヤー、テレビゲーム・プレーヤー・モジュール、インターネット・ブラウザー、および／または任意のＷＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線ローカル・エリア・ネットワーク）モジュールもしくはＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ：超広帯域）モジュールなどのモジュールと連動して使用することができる。 The user platform can be any of a number of platforms including WTRUs. Associated with software to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC (Radio Network Controller), or any host computer A processor can be used. The WTRU is implemented in hardware and / or software, and includes cameras, video camera modules, video phones, speakerphones, vibrating devices, speakers, microphones, TV transceivers, hands-free handsets, keyboards, Bluetooth (registered) Trademark)) module, FM (Frequency Modulated) radio unit, LCD (Liquid Crystal Display) display unit, OLED (Organic Light-Emitting Diode) display unit, digital music player, media player , Video game player module, internet browser, and / or optional It can be used in conjunction with a module such as a WLAN (Wireless Local Access Network) module or a UWB (Ultra Wide Band) module.
Claims (19)
前記アイデンティティ・プロバイダーから認証チャレンジを受信するステップと、
前記認証チャレンジに対応して、前記ユーザー・プラットフォームは前記認証チャレンジを受容したという条件にて、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：トラステッド・プラットフォーム・モジュール）に準拠したチケットを送信するステップと、
前記アイデンティティ・プロバイダーから成功したチケット検証を受信した際に、前記サービス・プロバイダーにアクセスするステップと
を備えることを特徴とする方法。 Logging on to a service provider using a predetermined identifier, wherein the user platform is redirected by the service provider to an identity provider pointed to by the predetermined identifier;
Receiving an authentication challenge from the identity provider;
In response to the authentication challenge, the user platform sends a ticket compliant with a Trusted Platform Module (TPM) on the condition that the user challenge has been accepted.
Accessing the service provider upon receiving a successful ticket validation from the identity provider.
ＡＩＫ（Ａｔｔｅｓｔａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｋｅｙ：構成証明アイデンティティ鍵）によって署名された引用を前記ＴＰＭから生成させるステップであって、前記ＡＩＫによって署名された引用は、前記ノンスを含むことと
をさらに備えることを特徴とする請求項１に記載の方法。 Receiving a nonce in response to a positive challenge confirmation;
Generating a citation signed by an AIK (Attestation Identity Key) from the TPM, the citation signed by the AIK further comprising including the nonce The method of claim 1.
プラットフォームは、
予め定められた識別子を使用してサービス・プロバイダーにアクセスするように構成されたインターフェイス・モジュールであって、前記装置は、前記予め定められた識別子によって指し示されるアイデンティティ・プロバイダーに前記サービス・プロバイダーによってリダイレクトされることと、
認証チャレンジが受容されたという条件にて、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：トラステッド・プラットフォーム・モジュール）に準拠したチケットを送信することによって前記認証チャレンジに応答するように構成されたチケット・サーバーと、
前記アイデンティティ・プロバイダーから成功したチケット検証を受信し、および前記サービス・プロバイダーにおけるサービスにアクセスするように構成される前記インターフェイス・モジュールとを備えることを特徴とする装置。 A device for supporting reliable authentication and access,
The platform is
An interface module configured to access a service provider using a predetermined identifier, wherein the device is sent by the service provider to an identity provider pointed to by the predetermined identifier Being redirected,
A ticket server configured to respond to the authentication challenge by sending a ticket compliant with TPM (Trusted Platform Module), provided that the authentication challenge is accepted;
And an interface module configured to receive a successful ticket verification from the identity provider and to access a service at the service provider.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2017094260A JP2017139026A (en) | 2017-05-10 | 2017-05-10 | Method and apparatus for reliable authentication and logon |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2017094260A JP2017139026A (en) | 2017-05-10 | 2017-05-10 | Method and apparatus for reliable authentication and logon |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015011333A Division JP2015111440A (en) | 2015-01-23 | 2015-01-23 | Method and apparatus for trusted authentication and log-on |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2017139026A true JP2017139026A (en) | 2017-08-10 |
Family
ID=59564999
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2017094260A Pending JP2017139026A (en) | 2017-05-10 | 2017-05-10 | Method and apparatus for reliable authentication and logon |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2017139026A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111147233A (en) * | 2019-11-26 | 2020-05-12 | 北京八分量信息科技有限公司 | Reliable implementation method and node for ABE attribute encryption |
| CN114158047A (en) * | 2021-12-30 | 2022-03-08 | 支付宝(杭州)信息技术有限公司 | Method and device for realizing one-key login service |
| CN114158047B (en) * | 2021-12-30 | 2024-06-11 | 支付宝(杭州)信息技术有限公司 | Method and device for realizing one-key login service |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007533182A (en) * | 2004-04-08 | 2007-11-15 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Method and system for linking a certificate to a signed file |
| WO2008026086A2 (en) * | 2006-08-31 | 2008-03-06 | International Business Machines Corporation | Attestation of computing platforms |
-
2017
- 2017-05-10 JP JP2017094260A patent/JP2017139026A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007533182A (en) * | 2004-04-08 | 2007-11-15 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Method and system for linking a certificate to a signed file |
| WO2008026086A2 (en) * | 2006-08-31 | 2008-03-06 | International Business Machines Corporation | Attestation of computing platforms |
Non-Patent Citations (2)
| Title |
|---|
| KLENK, A. ET AL.: "Preventing Identity Theft with Electronic Identity Cards and the Trusted Platform Module", PROCEEDINGS OF THE SECOND EUROPEAN WORKSHOP ON SYSTEM SECURITY, JPN7016000882, 31 March 2009 (2009-03-31), pages 44 - 51, XP058231147, DOI: doi:10.1145/1519144.1519151 * |
| MACHULAK, M. AND VAN MOORSEL, A.: "Use Case for User-Centric Access Control for the Web", NEWCASTLE UNIVERSITY TECHNICAL REPORT SERIES, vol. No.CS-TR-1165, JPN6019007421, 1 August 2009 (2009-08-01) * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111147233A (en) * | 2019-11-26 | 2020-05-12 | 北京八分量信息科技有限公司 | Reliable implementation method and node for ABE attribute encryption |
| CN114158047A (en) * | 2021-12-30 | 2022-03-08 | 支付宝(杭州)信息技术有限公司 | Method and device for realizing one-key login service |
| CN114158047B (en) * | 2021-12-30 | 2024-06-11 | 支付宝(杭州)信息技术有限公司 | Method and device for realizing one-key login service |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5688087B2 (en) | Method and apparatus for reliable authentication and logon | |
| US9490984B2 (en) | Method and apparatus for trusted authentication and logon | |
| US8881257B2 (en) | Method and apparatus for trusted federated identity management and data access authorization | |
| US10638321B2 (en) | Wireless network connection method and apparatus, and storage medium | |
| US9055107B2 (en) | Authentication delegation based on re-verification of cryptographic evidence | |
| KR101730459B1 (en) | Identity management with local functionality | |
| US9191814B2 (en) | Communications device authentication | |
| WO2019085531A1 (en) | Method and device for network connection authentication | |
| CN104767740A (en) | User platform credible authentication and access method | |
| JP2015111440A (en) | Method and apparatus for trusted authentication and log-on | |
| JP2017139026A (en) | Method and apparatus for reliable authentication and logon | |
| Singh et al. | Survey and analysis of Modern Authentication system | |
| KR20130046781A (en) | System and method for access authentication for wireless network | |
| Witosurapot | A Design of OTP-based Authentication Scheme for the Visually Impaired via Mobile Devices | |
| KR20130062965A (en) | System and method for access authentication for wireless network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170609 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170609 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180529 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180626 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180926 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190312 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20191015 |