1 / 24

Notarized Federated Identity Management for Web Services

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

alda
Télécharger la présentation

Notarized Federated Identity Management for Web Services

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. Notarized Federated Identity Management for Web Services Michael T. Goodrich Roberto Tamassia Danfeng Yao University of California, Irvine Brown University Work supported in part by the National Science Foundation and by IAM Technology, Inc.

  2. 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 Notarized Federated Identity Management

  3. Motivation • Digital identity management (DIM) • To protect sensitive personal information in on-line transactions • Users tend to choose weak passwords • 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 • Cookie-based SSO approach (used by Microsoft Passport) • Does not support cross-domain single sign-on • Approach using cryptographic-enabled assertions • Secure Assertion Markup Language (SAML) Notarized Federated Identity Management

  4. SSO and FIM Notarized Federated Identity Management

  5. 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 • Service Provider (SeP) • SeP is the system that relies on the information supplied to it by the identity provider • Relying party • Used in Liberty Alliance Federated Identity Management for single sign-on Notarized Federated Identity Management

  6. Identity Federation • Websites of different admin domains need to trust each other's access control verdicts • Circle of trust • Issues • 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? • These questions have not been extensively studied • Existing SSO solutions assume pre-established trust relationship among providers • IdP and SeP communicate to each other during SSO process Notarized Federated Identity Management

  7. Notarized Federated Identity Management • 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 Notarized Federated Identity Management

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

  9. Security Requirements • Security • 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 • Accountability • Identity providers should be held accountable for the assertions that they generate; and for any unauthorized information disclosure about the user Notarized Federated Identity Management

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

  11. 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 hold the identity provider accountable for unauthorized disclosure? • Our solution uses lightweight crypto primitives • hash function • XOR • symmetric encryption • digital signature Notarized Federated Identity Management

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

  13. 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, P1) • Queries the notary server for assertions of h • Notary server notarizes an assertion • Retrieves the blinded assertion S’ • Signature approach: Signs S’ with its private key • STMS approach: computes the proof for S’ • The user unblinds and verifies an assertion • The user verifies the notary information • Computes the blinding factor K = Hash(N, P2) • Decrypts S’ with K and obtains S • Detect unauthorized information disclosure • The service provider unblinds and verifies the assertion Notarized Federated Identity Management

  14. Privacy and Accountability User IdP SeP S_ID, assertion Access Notary Server Blinded assertion Accesses Request for attributes IdP User Stored by Signs Notary Server Signs Assertions to notary Stored by IdP Notarized Federated Identity Management

  15. Query Response Notary server realization: STMS • The Secure Transaction Management System [Goodrich, Tamassia et al.] implements an authenticated dictionary Basis (signed) Updates t Responder A User t DS Source Answer Proof Basis (signed) Responder B DS DS Notarized Federated Identity Management

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

  17. Outline of the talk • Introduction to federated ID • Provider model in SAML • Notarized federated identity management model and protocol • Identity theft and countermeasure Notarized Federated Identity Management

  18. An authentication protocol robust against identity theft • Identity theft causes • Private information insecurely stored and entered • 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 • Prevent dumpster diving • Safe disclosure • Prevent shoulder surfing • With minimal changes to current financial and administrative infrastructure • Existing approaches • Centralized processing • Heavy-weight Zero-knowledge proofs • Our approach • To design a lightweight authentication protocol using identity-based encryption Notarized Federated Identity Management

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

  20. 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] Notarized Federated Identity Management

  21. 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 Notarized Federated Identity Management

  22. Acknowledgements • David Croston at IAM Technology, Inc Notarized Federated Identity Management

  23. Notarized Federated Identity Management

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

More Related