Transcript SP collusion

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_MakeIdentity
New IDK(pub, prv)
6. TPM_ActivateTPMIdentity
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_CreateWrapKeyコマンドに
よって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_CertifyKey
↓
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?
User
2. SPID
is right?
SSO Identities
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
AS
SP
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, OS, 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の独立性や複雑性はそのまま