1 / 46

Single Sign-On using Trusted Platforms

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 。

keiki
Download Presentation

Single Sign-On using Trusted Platforms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 概要 • ネットワークユーザは、登録される全てのサービスによって1つの認証セットを覚えなきゃならない→メンドクサイ＆アンセキュア • これを解決するのがSSO。 • TCPAにより標準化されている技術によってSSOを実現するのがこの論文。

  3. SSO • Single Sign-OnはASP（Authentication Service Provider)に一度だけ認証され、そこからSPに接続、認証される技術。 • SPはASPによって与えられたauthentication assertionsによって指定されたユーザに保護された資源へのアクセス権を許可する。

  4. TCPA概要 • Trusted Computing Platform Alliance ～PCセキュリティ標準確立を目指すコンソーシアム～ • データの保護 • 信頼されるプラットフォームの検証 • ソフトウェア・ハードウェア問わず • プラットフォームとかユーザ認証の証明モデル • TCPAが定義するプラットフォーム→TP • これをつかってSSOをやる 注：現在TCPAは無くなりTCGに。

  5. Review of TCPA security services

  6. TCPA security services • TP has TPM, small crypto co-processor Fritz chip • Shielded locations • どんな攻撃に対しても耐えうる • TPM capabilitiesのみによりアクセス可能 • TPM Identities, Integrity Metrics, Key Certification

  7. 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は保障されなきゃいけない

  8. Certification of IDK by PRV-CA 6. TPM_ActivateTPMIdentity Activate the new IDK ⇔encrypted session key TP （PUBEK, PRVEK） 1. TPM_MakeIdentityNew IDK(pub, prv) 5. Identity Credentialとsession keyを送る PUBEKを使ってひねる 4. Generate Identity Credential ⇔IDK pub 3. Verify it (Trusted root public key) 2. Send IDK pub, PUBEKand some Credential PRV-CA

  9. After having successfully activated an IDK • TPM内のみでデータを署名するのに使える • IDK-signedデータを対応するIdentity Credentialと一緒に第3者に送信することができる • 第3者はPRV-CAが発行したroot public keyを利用してIdentity Credentialを検証できる

  10. AACP • Asymmetric Authorization Change Protocol • すべてのIDKにauthorization情報が含まれる • IDKを発行できるのはある特定のオーナだけだが、オーナが変わることがある • IDKのauthorization情報を変更するためのプロトコル

  11. Integrity Metrics • 設定やソフトウェアの状態を判定、保存、報告することができる • TP上で実行しようとするソフトウェアに関してHashし、その値をTPM’sPlatform Configuration Registers(PCRs)に格納する • はじめはPCR=0, TPが呼び出される度にPCRが更新される • BIOS、OS,applications

  12. Actions of Integrity Metrics • 実行されようとしているソフトウェアをHash • 現在のPCRの値とHashの結果をくっつけて、もう一度Hash • その値をPCRに格納 • History information • 判別されてイベント、software name and version • 影響されたPCR • Validation Certificate • 実行されようとしているソフトウェアのHash値と対応？？

  13. Integrity Challenge/Response TPのソフトウェアの状態を調べる 第3者 Integrity Challenge - nonce TP • Integrity Response • 現在のPCR値 • TPMのIDKを利用したPCR値とnonceの署名 • IDKのIdentity Credential • History information

  14. Integrity Responseの信頼性検証 • Trusted root public keyを利用してIndenity Credentialを検証 • PRC値とnonceをIndemnity Credential内のpublic keyを利用して検証 • History informationを査定し、与えられたPCR値を検証する このようにしてソフトウェアの状態を知れる

  15. Key Certification • TPM’s Protected Storage • いろんなタイプのデータを暗号法的に守れる • Non-migratable Signature Key (SK) • 例えば、TPM_CreateWrapKeyコマンドによってRSA keyが生成されたとき、Private keyのほうが格納される

  16. Key Certification 第3者 Verify Identity Credential → PRV-CA’s trusted root public key Public key certificate of the SK → Identity Credential TPM_CertifyKey ↓ SKPUBに対する Public key certificate TP Protected Storage - Non migratable SK Identity Credential+ Public key certificate

  17. Using Trusted Platforms for SSO

  18. AS' integrity • ユーザ認証はユーザのTPに委譲され、TP内のASによって実行される • ASはソフトウェアだけかもしれないし、ハードとの組み合わせかもしれない • Username/password • Smart Card • Integrityによって、どのmethodが使われているかを判別できる

  19. AS' integrity • TPM Identitiesに対応するIdentity Credentialがユニークである • X.509 public key certificate • Unique serial numberがPRV-CAによって割り当てられる • Identity Credentialは匿名性がある • ユーザの個人情報を含んでいない • TPM Identities = SSO Indentity

  20. System Entities登場人物たち

  21. 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を判断する

  22. 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を防ぐ • 詳しくは後で。

  23. 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 testing lab, TCPA specification

  24. The SSO protocol User 2. SPID is right? AS SP • Authentication reqSPID, Integrity Challenge

  25. The SSO protocol User 2. SPID is right? authenticationstatus 3. Authenticates AS SP • Authentication reqSPID, Integrity Challenge

  26. The SSO protocol User 4. Which SSO Identity? 2. SPID is right? AS SP SSO Identities • Authentication reqSPID, Integrity Challenge

  27. The SSO protocol User 2. SPID is right? 4. Which SSO Identity? Initial Register AS SSO Identities SP • Authentication reqSPID, Integrity Challenge

  28. The SSO protocol User AS SP • 5. Authentication Response • Integrity Response • Public key cert • Auth assertion

  29. The SSO protocol User 6. Evaluate IR 7. Verify SK’s public key cert 8. Verify the signature of assertion AS SP • 5. Authentication Response • Integrity Response • Public key cert • Auth assertion

  30. Data structure relations PRV-CA Root key Signs IDK(SSO Id) Signs Non-migratable SK IDK(SSO Id) Is guaranteed by Signs Authentication Assertionincludes SPID User’s TP Software State (BIOS, OS, AS, etc.)

  31. 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

  32. 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

  33. Treat Analysis

  34. SP collusion • SPが共謀すると、SSO Identitiesに対応したユーザのプライバシが危うくなる • SPごとに違うSSO Identitiesを利用する • 初期登録の際、すべてのSPごとにそのSP専用のSSO Identitiesを利用すると理想的 • SPを選ぶときやSPのPrivacy Policyを理解する際に、用心できるだけ • SPはユーザの個人情報を管理しているだろうから、SP collusionを完全に防げるわけではない

  35. SP/Privacy CA collusion • SPがPRV-CAで不正すると、ユーザのプライバシが危うくなる • PRV-CAはIdentity Credentialsと簡単に関連付けることができるため • IDK毎に異なるPRV-CAを利用する • プライバシー保護とSSO利用の利便性のトレードオフ • すべてのPRV-CAが、すべてのユーザもしくはSPによって信頼されているわけではない

  36. 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

  37. Reflection Attack (cont.) • ユーザがSPIDを検査している限りこの攻撃を防げる • 好ましいSPを示していることを確認できる • Authentication assertionはSPIDを含んでいるASによって電子的に署名されいているので、SPIDを簡単に変えることはできない • 同時にこのassertionによって、このSPがほかのSPでないことを保障される

  38. Eavesdropping • ユーザのTPとSP間での交換されるメッセージを盗聴することができる • どのSPとユーザが通信しているかを知ることができる • まあ、しょうがないか • Encrypting trafficでも防げない • 別にこれに限った問題じゃない

  39. Advantages and Disadvantages

  40. Advantages • Local SSO scheme • 第三者がユーザのふりをできない • SSO identitiesの秘密鍵が手元のTPMで守られているし、それが外にでることがないから • SSO identitiesは匿名性がある • 個人を示すような情報を含んでいないから • identityの役割をわけることができる • 個人情報が漏洩する心配もない

  41. Advantages(cont.) • オンラインの第三者を必要としない • 使われている証明書の様々なタイプの状態を確認するためにCertificate Revocation Listsがに定期的に問い合わせることがあるかも • SSO protocolはユーザの干渉なく、いつでも繰り返すことができる • あるSPがユーザの認証状況やTPのソフトウェアの状態が依然としてacceptableかどうかを確認する場合など • TP/SP session間にSSOプロトコルを再び実行することは、ユーザビリィティを変えることなくセキュリティの達成度をあげることができる

  42. Advantages(cont..) • ユーザのTPの中にASが存在し、信頼性のあるTPMによってそのintegrityが保障されている • ほかのSSOスキームとの相違点 • ユーザインターフェースをspoofすることが難しい • なりすましASP攻撃を防げる • TCPAアーキテクチャには変更がない • 新しいLiberty profileに適応できる

  43. Disadvantages • 複雑 • SSO IdentitiesとPRV-CAを対応付けることで、ユーザのプライバシが危うくなる • すべてのTPM IdentityはそのTPに制限されている • SSO Identityはそれが作られたTPのみで有効である • ユーザモビリティは、TP自身がそれを提供している場合か、異なるSP間でSSO Identity federation serviceが提供されいていう場合のみ可能

  44. Related Work • Liberty Alliance • 異なるドメイン間でのweb-based SSOのopen specification • Authentication assertionsはSAMLスキーマで • Boris Balacheff, at el, Trasted Computing Platforms: TCPA • 同一ドメインでのTPを利用h下sign-onを提案、本論文はこれの拡張

  45. Related Work(cont.) • Liqun Chen. Private communication • SPに対応したパスワードなどを格納し、自動的に必要なパスワードを提供するアプリケーション • SPに対する透過性やCross-platform user mobilityを実現できる • TPをこのアプローチに応用したら、もっといい • パスワードはTPMの保護されたストレージに保存され、信頼できる状態になったのみパスワードがリリースされる

  46. Conclusion • TCPAを利用した異なるSP間でのSSOがどのように動作するかを示した • TPM Identities, Integrity Metrics and Key Certificationを利用して実現 • ユーザ認証はローカルTPで任せられている • SPは、ユーザTPの認証とAuthentication assertionを信頼する前のソフトウェアの状態を確認する必要がある • SSO Identitiesの匿名性を利用してユーザのプライバシを保護 • ローカルASPでユーザを認証するために使われる方法とは違う • しかし、PRV-CAでのTCPAの独立性や複雑性はそのまま

More Related