1. Notarized Federated Identity Management for Web Services Michael T. Goodrich Roberto Tamassia Danfeng Yao Brown University University of California, Irvine Work supported in part by the National Science Foundation and by IAM Technology, Inc.

2. DBSec 2006Notarized Federated Identity Management2 Outline  Introduction to federated identity management (FIM)  Notarized federated identity management model and protocol  STMS and its application in notarized FIM  Identity theft and proposed countermeasure

3. DBSec 2006Notarized Federated Identity Management3 Motivation  Digital identity management (DIM) To protect sensitive personal information in on-line transactions To protect sensitive personal information in on-line transactions  Users tend to choose weak passwords As the number of passwords to remember increases As the number of passwords to remember increases  Single sign-on (SSO) and federated identity management A user logs in only once to a site, then is automatically authenticated A user logs in only once to a site, then is automatically authenticated  Cookie-based SSO approach (used by Microsoft Passport) Does not support cross-domain single sign-on Does not support cross-domain single sign-on  Approach using cryptographic-enabled assertions Secure Assertion Markup Language (SAML) Secure Assertion Markup Language (SAML)

4. DBSec 2006Notarized Federated Identity Management4 SSO and FIM

5. DBSec 2006Notarized Federated Identity Management5 Provider model in SAML  Specially designed for general cross-domain single sign-on  Identity Provider (IdP) IdP is the system that asserts information about a subject IdP is the system that asserts information about a subject  Service Provider (SeP) SeP is the system that relies on the information supplied to it by the identity provider SeP is the system that relies on the information supplied to it by the identity provider Relying party Relying party  Used in Liberty Alliance Federated Identity Management for single sign-on

6. DBSec 2006Notarized Federated Identity Management6 Identity Federation  Websites of different admin domains need to trust each other's access control verdicts Circle of trust Circle of trust  Issues How to securely maintain the identity federation when members may leave or join the circle of trust? How to securely maintain the identity federation when members may leave or join the circle of trust? How to provide separation of IdP and SeP for the privacy protection of the user? How to provide separation of IdP and SeP for the privacy protection of the user?  These questions have not been extensively studied Existing SSO solutions assume pre-established trust relationship among providers Existing SSO solutions assume pre-established trust relationship among providers IdP and SeP communicate to each other during SSO process IdP and SeP communicate to each other during SSO process

7. DBSec 2006Notarized Federated Identity Management7  We introduce a trusted third-party, called notary server  The notary information of an assertion provides its trustworthiness  Distributed implementation of the notarized federated identity management framework using STMS  We also present a robust authentication protocol that is resilient against identity theft attacks, using identity-based encryption

8. DBSec 2006Notarized Federated Identity Management8 Notarization  Notary server Third party trusted by identity providers and service providers Third party trusted by identity providers and service providers Notarizes assertions submitted by identity providers Notarizes assertions submitted by identity providers Answers queries on notarized assertions asked by the service providers Answers queries on notarized assertions asked by the service providers Prevents direct communication between the identity provider and the service provider Prevents direct communication between the identity provider and the service provider  Notarized assertion Generated by identity provider Generated by identity provider Authenticated by notary server Authenticated by notary server Trusted by service provider Trusted by service provider

9. DBSec 2006Notarized Federated Identity Management9 Security Requirements  Security A polynomial-time adversary cannot forge a valid notarized assertion A polynomial-time adversary cannot forge a valid notarized assertion  Secrecy Notarized assertion should not leak sensitive information of a user to unauthorized parties, including the notary server Notarized assertion should not leak sensitive information of a user to unauthorized parties, including the notary server  Accountability Identity providers should be held accountable for the assertions that they generate; and for any unauthorized information disclosure about the user Identity providers should be held accountable for the assertions that they generate; and for any unauthorized information disclosure about the user

10. DBSec 2006Notarized Federated Identity Management10 Overview of Notarized FIM SeP User IdP NotaryServer 1. Service request 2. S_ID, attr. names 8. Notarized blinded assertion 3. Authenticates 4. Signed S_ID, attr. names attr. names 5. Signed blinded assertion with assertion with hashed_ID hashed_ID 6. Query for hashed_ID 7. Notarized blinded assertion 9. Unblind and verify S_ID: session ID Hashed_ID: hashed S_ID Attr. Name: name of attribute required by SeP

11. DBSec 2006Notarized Federated Identity Management11 Protocol Design Challenges  How to protect the identity of the user from the service provider?  How to blind the content of an assertion from the notary server? How to unblind by the service provider? How to unblind by the service provider?  How to hold the identity provider accountable for unauthorized disclosure?  Our solution uses lightweight crypto primitives hash function hash function XOR XOR symmetric encryption symmetric encryption digital signature digital signature

12. DBSec 2006Notarized Federated Identity Management12 Implementation of Notarized FIM Protocol  Two public parameters P 1, P 2  The user and SeP compute a session_ID N XOR each party’s random string XOR each party’s random string  The user requests IdP to generate assertions Signed request to IdP for accountability Signed request to IdP for accountability  IdP blinds an assertion Computes the hashed_ID h = Hash(N, P 1 ) Computes the hashed_ID h = Hash(N, P 1 ) Generates an assertion S using h for index Generates an assertion S using h for index Computes the blinding factor K = Hash(N, P 2 ) Computes the blinding factor K = Hash(N, P 2 ) Encrypts S with K using a symmetric encryption scheme Encrypts S with K using a symmetric encryption scheme Blinded assertion is called S’ Blinded assertion is called S’  IdP submits an assertion to the notary server Sign S’ with its private key Sign S’ with its private key Notary server stores S’, and stores the signature for accountability Notary server stores S’, and stores the signature for accountability

13. DBSec 2006Notarized Federated Identity Management13 Implementation of the notarized FIM protocol (Cont’d)  The user queries for an assertion of a hashed_ID Computes the hashed_ID h = Hash(N, P 1 ) Computes the hashed_ID h = Hash(N, P 1 ) Queries the notary server for assertions of h Queries the notary server for assertions of h  Notary server notarizes an assertion Retrieves the blinded assertion S’ Retrieves the blinded assertion S’ Signature approach: Signs S’ with its private key Signature approach: Signs S’ with its private key STMS approach: computes the proof for S’ STMS approach: computes the proof for S’  The user unblinds and verifies an assertion The user verifies the notary information The user verifies the notary information Computes the blinding factor K = Hash(N, P 2 ) Computes the blinding factor K = Hash(N, P 2 ) Decrypts S’ with K and obtains S Decrypts S’ with K and obtains S Detect unauthorized information disclosure Detect unauthorized information disclosure  The service provider unblinds and verifies the assertion

14. DBSec 2006Notarized Federated Identity Management14 Privacy and Accountability S_ID,assertion Blindedassertion UserIdPSeP NotaryServer Access Accesses IdP User Stored by Signs Request for attributes Assertions to notary Signs Stored by NotaryServer IdP

15. DBSec 2006Notarized Federated Identity Management15 Notary server realization: STMS  The Secure Transaction Management System [Goodrich, Tamassia et al.] implements an authenticated dictionary Source Responder A Responder B DS DS DS t Basis (signed) Updates UserQuery Response AnswerProof t

16. DBSec 2006Notarized Federated Identity Management16 STMS in Notarized FIM NotarySource SeP User IdP 1. Service request 2. S_ID, attr. names 8. Notarized blinded assertion 3. Authenticates 4. Signed S_ID, attr. names attr. names 5. Signed blinded assertion with assertion with hashed_ID hashed_ID 6. Query for hashed_ID 7. Notarized blinded assertion 9. Unblind and verify Signed STMS basis, updates per time quantum NotaryResponder

17. DBSec 2006Notarized Federated Identity Management17 Outline of the talk  Introduction to federated ID  Provider model in SAML  Notarized federated identity management model and protocol  Identity theft and countermeasure

18. DBSec 2006Notarized Federated Identity Management18 An authentication protocol robust against identity theft  Identity theft causes Private information insecurely stored and entered Private information insecurely stored and entered On credit card company’s computers, in DMV’s cabinets, in your bank, in your trash can …On credit card company’s computers, in DMV’s cabinets, in your bank, in your trash can …  How to proactively control the release of your private information? Secure storage Secure storage Prevent dumpster divingPrevent dumpster diving Safe disclosure Safe disclosure Prevent shoulder surfingPrevent shoulder surfing With minimal changes to current financial and administrative infrastructure With minimal changes to current financial and administrative infrastructure  Existing approaches Centralized processing Centralized processing Heavy-weight Zero-knowledge proofs Heavy-weight Zero-knowledge proofs  Our approach To design a lightweight authentication protocol using identity-based encryption To design a lightweight authentication protocol using identity-based encryption

19. DBSec 2006Notarized Federated Identity Management19 An authentication protocol with identity-based encryption User Identity Provider 3. Submits identity- based public key for authentication 6. Is the identity-based public key revoked? revoked? 1.Registersidentity-based public key 2. Issues corresponding private key Revocation Server Periodic updates of revokedidentity-based public keys 4. Challenge ciphertext 5. Result of decryption with private key IDAuthority

20. DBSec 2006Notarized Federated Identity Management20 Related work  Anonymous credentials [Camenisch Lysyanskaya 01] [Camenisch Herreweghen 02]  Federated ID management models [Camenisch et al 05] [Bhargav-Spantzel Squicciarini Bertino 05] [Pfitzmann Waidner 03]  Web service framework [Bonatti Samarati 02]  Identity theft detection [van Oorschot Stubblebine 05]  Identity-based encryption [Boneh Franklin 01]  SAML [OASIS], WS-Federation [IBM et al]

21. DBSec 2006Notarized Federated Identity Management21 Conclusions  Notarized federated identity management is a solution for establishing trust in web services  Notary server provides an anchor of trust  Notarized FIM protocol provides accountability, privacy, and secrecy for participants  IBE-based credentials and exchanges hold promises for identity theft solutions

22. DBSec 2006Notarized Federated Identity Management22 Acknowledgements  David Croston at IAM Technology, Inc

23. DBSec 2006Notarized Federated Identity Management23

24. DBSec 2006Notarized Federated Identity Management24 Generations of the model User IdP 1. Service request 2. S_ID, attr. names 8. Notarized blinded assertion 3. Authenticates 4. Signed S_ID, attr. names attr. names 5. Signed blinded assertion with assertion with hashed_ID hashed_ID 6. Query for hashed_ID 7. Notarized blinded assertion 9. Unblind and verify S_ID: One-time session ID Hashed_ID: hashed S_ID Attr. Name: name of attribute required by SeP Optional path NotaryServer NotaryServer SeP B SeP A