Notarized Federated Identity Management for Web Services

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

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)

4
SSO and FIM
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

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

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

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

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

10
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
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

12
Implementation of NotarizedFIM Protocol

• Two public parameters P1, P2
• The user and SeP compute a session_ID N
• XOR each partys 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

13
Implementation of the notarized FIM protocol
(Contd)

• 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

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
15
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
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
17
Outline of the talk

• Introduction to federated ID
• Provider model in SAML
• Notarized federated identity management model and
  protocol
• Identity theft and countermeasure

18
An authentication protocol robust against
identity theft

• Identity theft causes
• Private information insecurely stored and entered
• On credit card companys computers, in DMVs
  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

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

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

22
Acknowledgements

• David Croston at IAM Technology, Inc

23
(No Transcript)
24
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