Single Sign-On using Trusted Platforms

Andreas Pashalidis and Chris J. Mitchell

Technical Report

Royal Holloway University of London

MAUI 輪講 2003/07/03 By keita & mitsuya

概要

• ネットワークユーザは、登録される全てのサービスによって 1 つの認証セットを覚えなきゃならない→メンドクサイ＆アンセキュア

• これを解決するのが SSO 。• TCPA により標準化されている技術によっ

てSSO を実現するのがこの論文。

SSO

• Single Sign-On は ASP （ Authentication Service Provider) に一度だけ認証され、そこから SP に接続、認証される技術。

• SP は ASP によって与えられた authentication assertions によって指定されたユーザに保護された資源へのアクセス権を許可する。

TCPA 概要

• Trusted Computing Platform Alliance　～ PC セキュリティ標準確立を目指すコンソーシアム～

– データの保護– 信頼されるプラットフォームの検証

• ソフトウェア・ハードウェア問わず– プラットフォームとかユーザ認証の証明モデル

• TCPA が定義するプラットフォーム→ TP• これをつかって SSO をやる

注：現在 TCPA は無くなり TCG に。

Review of TCPA security services

TCPA security services

• TP has TPM, small crypto co-processor Fritz chip

• Shielded locations– どんな攻撃に対しても耐えうる– TPM capabilities のみによりアクセス可能

• TPM Identities, Integrity Metrics, Key Certification

TPM Identities

• Unique RSA key pair を持つ• PRVEK (private one)

– TPM に送られてくる certain data structure の復号化のみに使われる

• PUBEK (public one)– TPM から取り出し可能

• TPM の PUBEK を TP の外に出すことは、第 3 者にそのプラットホームをユニークに特定できる

• TPM Identities は IDK をもつ。 RSA のペア• PRV-CA によって IDK は保障されなきゃいけない

Certification of IDK by PRV-CA

TP

PRV-CA

（ PUBEK, PRVEK）

(Trusted root public key)

1. TPM_MakeIdentityNew IDK(pub, prv)

2. Send IDK pub, PUBEKand some Credential

3. Verify it

4. Generate Identity Credential ⇔IDK pub

5. Identity Credential とsession key を送るPUBEK を使ってひねる

6. TPM_ActivateTPMIdentityActivate the new IDK ⇔encrypted session key

After having successfully activated an IDK

• TPM 内のみでデータを署名するのに使える

• IDK-signed データを対応する Identity Credential と一緒に第 3 者に送信することができる

• 第 3 者は PRV-CA が発行した root public key を利用して Identity Credential を検証できる

AACP

• Asymmetric Authorization Change Protocol

• すべての IDK に authorization 情報が含まれる– IDK を発行できるのはある特定のオーナだ

けだが、オーナが変わることがある• IDK の authorization 情報を変更するた

めのプロトコル

Integrity Metrics

• 設定やソフトウェアの状態を判定、保存、報告することができる

• TP 上で実行しようとするソフトウェアに関して Hash し、その値を TPM’s 　 Platform Configuration Registers(PCRs) に格納する– はじめは PCR=0, TP が呼び出される度に PCR

が更新される– BIOS 、 OS, 　 applications

Actions of Integrity Metrics

• 実行されようとしているソフトウェアを Hash• 現在の PCR の値と Hash の結果をくっつけて、

もう一度 Hash• その値を PCR に格納• History information

– 判別されてイベント、 software name and version– 影響された PCR– Validation Certificate

• 実行されようとしているソフトウェアの Hash 値と対応？？

Integrity Challenge/Response

TP

第 3 者Integrity Challenge- nonce

TP のソフトウェアの状態を調べる

Integrity Response-現在の PCR 値-TPM の IDK を利用した PCR 値と nonce の署名-IDK の Identity Credential-History information

Integrity Response の信頼性検証

• Trusted root public key を利用して Indenity Credential を検証

• PRC 値と nonce を Indemnity Credential 内の public key を利用して検証

• History information を査定し、与えられたPCR 値を検証する

このようにしてソフトウェアの状態を知れる

Key Certification

• TPM’s Protected Storage– いろんなタイプのデータを暗号法的に守れ

る– Non-migratable Signature Key (SK)

• 例えば、 TPM_CreateWrapKey コマンドによって RSA key が生成されたとき、Private key のほうが格納される

Key Certification

TP

第 3 者

Protected Storage- Non migratable SK

Identity Credential+ Public key certificate

TPM_CertifyKey↓

SKPUB に対するPublic key certificate

VerifyIdentity Credential → PRV-CA’s trusted root public keyPublic key certificate of the SK → Identity Credential

Using Trusted Platforms for SSO

AS' integrity

• ユーザ認証はユーザの TP に委譲され、TP 内の AS によって実行される

• AS はソフトウェアだけかもしれないし、ハードとの組み合わせかもしれない– Username/password– Smart Card

• Integrity によって、どの method が使われているかを判別できる

AS' integrity

• TPM Identities に対応する Identity Credential がユニークである– X.509 public key certificate– Unique serial number が PRV-CA によって割

り当てられる• Identity Credential は匿名性がある

– ユーザの個人情報を含んでいない• TPM Identities = SSO Indentity

System Entities登場人物たち

User and User TP

• User’s TP は network access device と SP に対する ASPの役割を担う

• TPM Identities は SSO Identities として振舞う• TPM ユーザごとに異なる SSO Identities を作成可能• SP は TP 内の AS と通信をする• AS は、ユーザを認証し、 SSO を手助けするために

SP に authentication assertion を提供する• Daemon or part of the OS login mechanism• Integrity Challenge/Reponses session を利用して AS の i

ntegrity を判断する

Service Providers

• SP はユーザ認証を要求、 TP 内の AS から assertion を入手する

• Integrity Challenge/Response による AS の integrity の検証– SSO Identity に対応した Identity Credential が AS が

SP に伝える– Integrity assurance と Under identification の両立

• SPID, URI– Reflection attacks を防ぐ

• 詳しくは後で。

Trust Relationships

• End user は IDK の SSO Identities に対応する PRV-CA を信じる必要がある

• SP は、– IDK の SSO Identities に対応する PRV-CA

– ユーザ TP 上で実行されている AS

• PRV-CA を信用する＝ TCPA のすべての登場人物を信用する– TPM manufacturer, TP manufacturer, Conformance tes

ting lab, TCPA specification

The SSO protocol

SP

AS

User

1. Authentication reqSPID, Integrity Challenge

2. SPID is right?

The SSO protocol

SP

AS

User

1. Authentication reqSPID, Integrity Challenge

2. SPID is right?authentication

status

3. Authenticates

The SSO protocol

SP

AS

User

1. Authentication reqSPID, Integrity Challenge

2. SPID is right?

SSO Identities

4. Which SSO Identity?

The SSO protocol

SP

AS

User

1. Authentication reqSPID, Integrity Challenge

2. SPID is right?

SSO Identities

4. Which SSO Identity? Initial Register

The SSO protocol

SP

AS

User

5. Authentication Response• Integrity Response• Public key cert• Auth assertion

The SSO protocol

SP

AS

User

5. Authentication Response• Integrity Response• Public key cert• Auth assertion

6. Evaluate IR7. Verify SK’s public key cert8. Verify the signature of assertion

Data structure relations

PRV-CA Root key

IDK(SSO Id)

IDK(SSO Id)Non-migratable SK

Authentication Assertionincludes SPID

User’s TP Software State(BIOS, OS, AS, etc.)

Signs

Signs

Signs Is guaranteed by

The SSO protocl

• AS achieves SSO– User authentication status– SSO Identity/SP associations

• SP から保護された資源に対する要求があって、対応する SSO Identity association が存在したら、 SSO できる

• Single logout– Remembering every open SP session

SSO Identity Federation

• TPM Identities を TP の外に出すことを認めない• TP 自身が Mobility を提供しているときは、この

SSO scheme は user mobility を提供できる• 異なる SSO Identities を SP ごとに使うべき• Federated SSO Identities

– ひとつの SP に対して異なる TP で作られた複数の SSO Identities を登録する

– Out of scope

Treat Analysis

SP collusion

• SP が共謀すると、 SSO Identities に対応したユーザのプライバシが危うくなる

• SP ごとに違う SSO Identities を利用する– 初期登録の際、すべての SP ごとにその SP専用の

SSO Identities を利用すると理想的

• SP を選ぶときや SP の Privacy Policy を理解する際に、用心できるだけ– SP はユーザの個人情報を管理しているだろうか

ら、 SP collusion を完全に防げるわけではない

SP/Privacy CA collusion

• SP が PRV-CA で不正すると、ユーザのプライバシが危うくなる– PRV-CA は Identity Credentials と簡単に関連付ける

ことができるため

• IDK毎に異なる PRV-CA を利用する• プライバシー保護と SSO 利用の利便性のトレードオフ– すべての PRV-CA が、すべてのユーザもしくは S

P によって信頼されているわけではない

Reflection Attack

• 攻撃者は、 victim user に対する SSO処理の一部として SP から受信した Integrity Challenge やAuthentication request message を転送することができる– SP のふりをする (spoofing the SPID)

• Integrity Challenge や Authentication request messages の起源を検証する– SSL/TLS channel with server-side certificates in conjunct

ion with the security extensions for DNS– Suitable challenge/response protocol involving message s

ignaling

Reflection Attack (cont.)

• ユーザが SPID を検査している限りこの攻撃を防げる– 好ましい SP を示していることを確認できる

• Authentication assertion は SPID を含んでいる AS によって電子的に署名されいているので、 SPID を簡単に変えることはできない– 同時にこの assertion によって、この SP がほか

の SP でないことを保障される

Eavesdropping

• ユーザの TP と SP間での交換されるメッセージを盗聴することができる– どの SP とユーザが通信しているかを知る

ことができる• まあ、しょうがないか

– Encrypting traffic でも防げない– 別にこれに限った問題じゃない

Advantages and Disadvantages

Advantages

• Local SSO scheme– 第三者がユーザのふりをできない– SSO identities の秘密鍵が手元の TPM で守られて

いるし、それが外にでることがないから

• SSO identities は匿名性がある– 個人を示すような情報を含んでいないから– identity の役割をわけることができる– 個人情報が漏洩する心配もない

Advantages(cont.)

• オンラインの第三者を必要としない– 使われている証明書の様々なタイプの状態を確認する

ために Certificate Revocation Lists がに定期的に問い合わせることがあるかも

• SSO protocol はユーザの干渉なく、いつでも繰り返すことができる– ある SP がユーザの認証状況や TP のソフトウェアの

状態が依然として acceptable かどうかを確認する場合など

– TP/SP session間に SSO プロトコルを再び実行することは、ユーザビリィティを変えることなくセキュリティの達成度をあげることができる

Advantages(cont..)

• ユーザの TP の中に AS が存在し、信頼性のある TPM によってその integrity が保障されている– ほかの SSO スキームとの相違点– ユーザインターフェースを spoof することが難し

い– なりすまし ASP 攻撃を防げる

• TCPA アーキテクチャには変更がない• 新しい Liberty profile に適応できる

Disadvantages

• 複雑• SSO Identities と PRV-CA を対応付けることで、

ユーザのプライバシが危うくなる• すべての TPM Identity はその TP に制限されて

いる– SSO Identity はそれが作られた TP のみで有効であ

る– ユーザモビリティは、 TP 自身がそれを提供してい

る場合か、異なる SP間で SSO Identity federation service が提供されいていう場合のみ可能

Related Work

• Liberty Alliance– 異なるドメイン間での web-based SSO の open

specification– Authentication assertions は SAML スキーマで

• Boris Balacheff, at el, Trasted Computing Platforms: TCPA– 同一ドメインでの TP を利用 h下 sign-on を提案、本論文はこれの拡張

Related Work(cont.)

• Liqun Chen. Private communication– SP に対応したパスワードなどを格納し、自動的

に必要なパスワードを提供するアプリケーション– SP に対する透過性や Cross-platform user mobility

を実現できる

• TP をこのアプローチに応用したら、もっといい– パスワードは TPM の保護されたストレージに保

存され、信頼できる状態になったのみパスワードがリリースされる

Conclusion

• TCPA を利用した異なる SP間での SSO がどのように動作するかを示した

• TPM Identities, Integrity Metrics and Key Certification を利用して実現– ユーザ認証はローカル TP で任せられている– SP は、ユーザ TP の認証と Authentication assertion を信頼す

る前のソフトウェアの状態を確認する必要がある• SSO Identities の匿名性を利用してユーザのプライバ

シを保護– ローカル ASP でユーザを認証するために使われる方法とは違う

– しかし、 PRV-CA での TCPA の独立性や複雑性はそのまま