User-centric Handling of Identity Agent Compromise

1. User-centric Handling of Identity Agent Compromise ESORICS 2009, Saint Malo, France, 2009 Daisuke Mashima Dr. Mustaque Ahamad Swagath Kannan College of Computing Georgia Institute of Technology Atlanta, GA, USA

2. Consequence of online identity theft • Impersonation • Breach of sensitive information • Financial loss • and more… Increasing Risk of Identity Theft • Variety of online identity credentials • Passwords, certificates, SSN, credit card number, etc. • Loss and theft are possible

3. User-centric Identity Management • Recent trend in identity management systems • Advantage • User can choose appropriate credentials flexibly • Disadvantage • Users are expected to be more responsible for their online identity usage • Users need to have more robust control over and awareness of identity credential usage.

4. Outline • Limitations in existing implementations • Our approach • Prototype implementation in GUIDE-ME • Evaluation • Conclusion / Future Work

5. [1] Negotiation [2] Authorization Token + Ownership Proof [4] Identity Credential [3] Authorization Token GUIDE-ME • Georgia tech User-centric IDEntity Management Environment • Local and remote Identity Agents (IdAs) Relying Party User / Local IdA Remote IdA

6. Limitation of Current Systems • Loss, theft, or compromise of user devices / authentication credentials is possible. • No effective mechanism to support user’s awareness of credential usage. • Revocation of compromised devices takes time.

7. Assumptions • Relying parties (RPs) require a requesting agent to demonstrate the knowledge of user’s private key for ownership verification. • Ownership proof and identity credential work together to prove identity. (Joint Authority) • Proof Key in CardSpace, U-Prove, GUIDE-ME, … • RPs follow specified protocol. • Robust verification minimizes their future risks.

8. Our Approach • Online monitoring agent • Enhance user’s awareness • Accessible to users • Threshold Signatures • Eliminate single point of attack/failure • Achieve immediate revocation of compromised identity agents • Enable users to control the monitoring feature … Private Key Key Shares

9. Monitoring Agent - Run on TTP chosen by a user - Log identity credential usage - Send usage report periodically - (Detect & block suspicious usage) Storage Token High-level Idea in Simplified Setting • Local IdA stores user’s identity credential. • Storage token and online monitoring agent are newly added. • 2-3 threshold signature scheme is employed. User Local IdA

10. Negotiation Scenario with Storage Token Monitoring Agent User / Local IdA Relying Party

11. Report usage log periodically Negotiation Scenario without Storage Token Monitoring Agent User / Local IdA Relying Party

12. Email (SMS) [2] Authorization Token + [4] Identity Credential [3] Authorization Token Storage Token (USB Drive) PrototypeImplementation Monitoring Agent (Java Servlet) User + Local IdA (Java app) Relying Party (Java Web server) [1] Negotiation (Text file) Remote IdA (Java Web Server)

13. Response Time • Remote IdA, RP, and monitoring agent • Run on separate machines in our campus NW • Local IdA (User Device) • Connected via a cable TV Internet service • Shorter than “4-second threshold” by Akamai Table1: Comparison of Response Time [seconds]

14. User-Centricity • Properties of user-centricity presented by Bhargav-Spantzel et al. • Revocability • By updating key shares, compromised agents are disabled immediately. • Audit / Notification • Online monitoring agent under user’s control can log and report identity credential usage. • Usability • Monitoring agent mitigates the impact on usability.

15. Summary of Security Analysis • None of local IdA, remote IdA, monitoring agent, and storage token is a single point of attack. • Monitoring agent is still effective even when both local and remote IdAs are compromised. • Eavesdropping of messages to monitoring agent does not leak sensitive information. • Storage Token does not require fancy security features.

16. Security, Privacy and Usability Trade-offs Security Never (rarely) use Storage Token Proactive Update Do not carry or care about Storage Token Use Storage Token whenever necessary Privacy Usability

17. Recovery and Availability • Recovery can be done by creating a new instance by re-generating key shares • No CA or IdP needs to be involved • Missing storage token • Monitoring agent works in place of it • Disabled Monitoring agent • Users can use services by using storage token • Disabled local IdA • Key shares available from a remote IdA, monitoring agent, storage token are enough.

18. Conclusion • Proposed a mechanism to enhance user’s control and awareness in user-centric identity management systems • User-centric identity-usage monitoring • Fast revocation of compromised identity agents • Flexible use of hardware storage token to balance usability, security, and privacy • Presented an actual proof of concept • Response time measurements • Security and user-centricity analysis

19. Future Work • Enhancement of monitoring agent’s functionality • Real-time anomaly detection mechanism • Integration into other architecture • Windows CardSpace etc. • User studies to evaluate usability

20. Thank you very much. Questions?ご拝聴ありがとうございました。mashima@cc.gatech.edu http://www.cc.gatech.edu/~mashima Merci.