MAUI輪講 2003/07/03 By keita & mitsuya Single Sign-On using Trusted Platforms Andreas Pashalidis and Chris J. Mitchell Technical Report Royal Holloway University of London
概要 • ネットワークユーザは、登録される全てのサー ビスによって 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 （PUBEK, PRVEK） 1. TPM_Make. Identity New IDK(pub, prv) 6. TPM_Activate. TPMIdentity Activate the new IDK ⇔encrypted session key 5. Identity Credentialと session keyを送る PUBEKを使ってひねる 4. Generate Identity Credential ⇔IDK pub 3. Verify it (Trusted root public key) 2. Send IDK pub, PUBEK and some Credential PRV-CA
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のソフトウェアの状態を調べる Integrity Challenge - nonce TP 第 3者 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_Create. Wrap. Keyコマンドによ ってRSA keyが生成されたとき、Private key のほうが格納される
Key Certification 第 3者 Verify Identity Credential → PRV-CA’s trusted root public key Public key certificate of the SK → Identity Credential TP TPM_Certify. Key ↓ SKPUBに対する Public key certificate Protected Storage - Non migratable SK Identity Credential + Public key certificate
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の integrityを判断する
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に対応するPRVCAを信じる必要がある • SPは、 – IDKのSSO Identitiesに対応するPRV-CA – ユーザTP上で実行されているAS • PRV-CAを信用する＝TCPAのすべての登場人 物を信用する – TPM manufacturer, TP manufacturer, Conformance testing lab, TCPA specification
The SSO protocol User 2. SPID is right? AS SP 1. Authentication req SPID, Integrity Challenge
The SSO protocol User 2. SPID is right? authentication status 3. Authenticates AS SP 1. Authentication req SPID, Integrity Challenge
The SSO protocol 4. Which SSO Identity? SSO Identities User 2. SPID is right? AS SP 1. Authentication req SPID, Integrity Challenge
The SSO protocol User 2. SPID is right? 4. Which SSO Identity? Initial Register SSO Identities AS SP 1. Authentication req SPID, Integrity Challenge
The SSO protocol User AS SP 5. Authentication Response • Integrity Response • Public key cert • Auth assertion
The SSO protocol User 6. Evaluate IR 7. Verify SK’s public key cert 8. Verify the signature of assertion SP AS 5. Authentication Response • Integrity Response • Public key cert • Auth assertion
Data structure relations PRV-CA Root key Signs IDK(SSO Id) Signs Non-migratable SK Signs Authentication Assertion includes SPID IDK(SSO Id) Is guaranteed by User’s TP Software State (BIOS, AS, etc. )
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が、すべてのユーザもしくはSPによ って信頼されているわけではない
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 conjunction with the security extensions for DNS – Suitable challenge/response protocol involving message signaling
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の独立性や複雑性はそのまま
Скачать презентацию MAUI輪講 2003 07 03 By keita mitsuya Single Sign-On
67abf6c5ca4d52d5404a94a97605aadd.ppt