1. Privacy and Identity Authentication © Copyright 2004, Credentica Inc. All Rights Reserved. Dr. Stefan Brands Credentica & McGill School of Computer Science June 8, 2004 Presented to: EA Open House 2004, Ontario

2. 2 © Copyright 2004, Credentica Inc. All Rights Reserved Content Part I Introduction Part II Case study: Liberty Alliance Part III Digital Credentials

3. 3 © Copyright 2004, Credentica Inc. All Rights Reserved Part I Introduction

4. 4 © Copyright 2004, Credentica Inc. All Rights Reserved Digital identity management (1) Network identity (also: digital identity) Collection of information relating to an individual Created and managed as single unit in a network Stored in electronic form Situation today: Individuals have fragmented network identities in “silos” Aggregating network identities is increasingly easy But: which network identities pertain to same individual? – If linkage is wrong, aggregate has less value (data pollution) Causes of pollution Unintentional (different name spellings, …) Intentional (avoidance, theft, lending, copying, forgery, insider help, …)

5. 5 © Copyright 2004, Credentica Inc. All Rights Reserved A simple approach to linking identities “Strong identity” approach: Capture (authenticated) identifier when collecting data – Employee ID, static IP address, SSN, credit card number, passport ID, electronic ID (biometric, X.509 certificate, …) Aggregate on basis of this cross-domain identifier Implications radically differ depending on setting! – OK for intra-organizational (“enterprise”) identity management Possibly: Extended Enterprise (e.g., supply chain management) – NOT OK for cross-organizational identity management: E-health, E-government, Critical Information Infrastructures, … Consequences of electronic identifiers are much more severe than showing your SSN everywhere Everything is electronically recorded, not only by your transaction partner but also by central parties, in real time!

6. 6 © Copyright 2004, Credentica Inc. All Rights Reserved Where does the simple approach work? Single-domain intra-organizational Employees have low/no privacy expectations/rights No conflicts with privacy legislation Trust dynamics very simple No scalability issues Can use traditional security tools (“silo protection”) – Door guards, intrusion detection, firewalls, anti-virus, … Multi-domain intra-organizational (branches, …) Trust dynamics minimally complicated Minimal conflicts with privacy legislation Low privacy expectations Possibly some scalability issues Traditional security tools still work Extended enterprise (?)

7. 7 © Copyright 2004, Credentica Inc. All Rights Reserved Where does it break down? “Balanced” business-to-business (B2B) Collaborative enterprise applications Government-to-business (G2B) Government-to-government (G2G) Back-office sharing of personal data Government-to-citizen (G2C) Implications for stability of democracy Business-to-consumer (B2C) Consumer-to-consumer applications Online gaming, instant messaging, … Peer-to-peer transactions

8. 8 © Copyright 2004, Credentica Inc. All Rights Reserved Why the simple approach fails in general Serious security & scalability problems See case study (exemplary application) Fear for loss of “information autonomy” Different manifestations for: – Individuals: identity theft, discrimination, errors, access denial, … – Companies: competitive intelligence, liability issues, goodwill issues – Critical Information Infrastructures: monitoring by criminals/terrorists Possible violations of data protection legislation Privacy: “The right of individuals, groups, and organizations to determine for themselves when, how, and to what extent information about them is communicated to others” Personal information: “information about a data subject whose identity can reasonably be ascertained from the information” – Network identity = personal information!! (unless “untraceable”)

9. 9 © Copyright 2004, Credentica Inc. All Rights Reserved 1.Collection Limitation 2.Data Quality 3.Purpose Specification 4.Use Limitation 6.Openness 7.Individual Participation 8.Accountability 5. Security safeguards (incl. confidentiality) OECD FIPs: Fair Information Principles (FIPs) Security safeguards deal with outsiders, but in cross-domain identity management the main privacy threats come from insiders The straightforward use of “secure” electronic identifiers in cross-domain identity management addresses FIP 5, but is in conflict with FIPs 1 & 4

10. 10 © Copyright 2004, Credentica Inc. All Rights Reserved Part II Case study: Liberty Alliance

11. 11 © Copyright 2004, Credentica Inc. All Rights Reserved Liberty Alliance Industry consortium, formed September 2001 Over 160 technology and consumer-facing organizations – American Express, Novell, Vodafone, Sun Microsystems, Ericsson, Nokia, GM, HP, America Online, Sony, VeriSign, … Started as counter-movement to Microsoft’s Passport Goal: open standard for “federating” identities “Federated identity allows users to link elements of their identity between accounts without centrally storing all of their personal information.” Basic approach: One “Identity Provider” (IdP) satisfies the authentication (identity linking!) needs of all the Service Providers (SPs) in its “circle of trust” Authorization decisions stay with the SPs themselves IdP uses traditional single-domain authentication methods – Password-only, Kerberos, PKI, biometrics, … Many circles of trust can exist (and can overlap arbitrarily)

12. 12 © Copyright 2004, Credentica Inc. All Rights Reserved Federation introduction (animation) User Identity Provider SP 1) (Strong) identification Identification 2) Federation invitation 3) Introduction cookie SP Invitation Yes Cookie Design assumption: SPs and IdP already know the Users Legacy account setup & legacy program identifiers (SIN, passport, user-name, …)

13. 13 © Copyright 2004, Credentica Inc. All Rights Reserved Account linking (animation) User SP Identity Provider 1) Login as usual 2) Linking “consent” 3) User-handle generation Username Password (Cookie) Account linking? Yes User-handle (“contextual” ID …) UserId = User-handle Username = User-handle 4) User-handle storing

14. 14 © Copyright 2004, Credentica Inc. All Rights Reserved Single sign-on (animation) User SP Identity Provider 1) (Strong) identification 2) Single sign-on Identification 3) Service access Authentication assertion Authentication request & SP id UserId = User-handle Username = User-handle

15. 15 © Copyright 2004, Credentica Inc. All Rights Reserved Security problems IdP abuse (rogue insiders, controlling parties) Impersonate any targeted User across entire circle of trust – Even parallel to User’s own activities without User ever knowing it (Falsely) deny access to targeted Users across entire circle – This IdP power may also be problematic for SPs IdP is target for Denial Of Service attacks Shut down access across entire circle of trust Unsuitable for SP-sided security No access-rights lending (& cloning) prevention – Users can “lend/copy” rights (user/password, cookies, etc.) Tamper-resistant User tokens do not work here – Storage limitations, time consuming, DPA analysis, … – Ineffective: security still depends only on getting to cookie! “Low” security (cookie & password, browser)

16. 16 © Copyright 2004, Credentica Inc. All Rights Reserved Privacy problems “Security safeguards” not achieved Very hard to give Users ability to review and correct their own information (it is “federated”) IdP can trace all User–SP interactions in real time (real-time error-free cross-profiling power!) IdP knows which SP-handles belong to each User Not desirable for Users and SPs alike – For much the same reason as those who hope to become IdPs did not like Microsoft Passport v1 – Loss of “information autonomy” (goes beyond privacy) IdP is like a Mastercard “on steroids” Here, all communications are fully electronic Unlike with credit cards, we deal with personal information (“network identities”), not just with payments amounts

17. 17 © Copyright 2004, Credentica Inc. All Rights Reserved Roadmap problems IdP assertions cannot replace “legal” signatures SPs cannot share “attribute” data unless through their IdP (again, loss of information autonomy) Even if User would want automated sharing to happen What if IdP or SP do NOT already know a User? “Introductions” between SPs create cross-profiling power Each circle of trust is still a silo! Linking circles of trust is done by (cross-)linking their IdPs! – Much like PKI hierarchies of CAs Essentially means a new “super-IdP” has to be formed Security and privacy problems go up: – They now pertain to all Users & SPs in the joined-up circles of trust – The damage can now flow across circles of trust

18. 18 © Copyright 2004, Credentica Inc. All Rights Reserved The crux of these problems Old-school authentication primitives were designed for intra-organizational requirements: Security against unauthorized outsiders No privacy provisions other than wire-tapping prevention But cross-domain access brings NEW requirements Complicated trust dynamics Vulnerabilities due to (real-time) reliance on central parties – Denial of service, hackers, insiders Security against dishonest insiders – Not necessarily in your own organization, but in someone else’s! Perimeter security techniques of little use – All security must be tied to the information itself ! Privacy: Control over who can learn what information – Related to broader concerns over loss of information autonomy

19. 19 © Copyright 2004, Credentica Inc. All Rights Reserved Part III Digital Credentials

20. 20 © Copyright 2004, Credentica Inc. All Rights Reserved Digital Credentials Based on 20 years of academic research Much more powerful than X.509-style PKI: Privacy “slider” (independent from security “slider”) – All parties in the certified-data path have fine-grained control over attribute disclosure: RA → CA → User → Verifier → Validator Sophisticated selective disclosure techniques – Unlinkable certificate issuing and showing Identified, pseudonymous, anonymous, and anything “in between” Unique security features – Limited-show certificates – Privacy-friendly cross-platform blacklisting – Embedded lending disincentives – Efficient smartcard implementation (incl. multi-application) Non-intrusive managed security services

21. 21 © Copyright 2004, Credentica Inc. All Rights Reserved Digital Credentials in action (animation) User can “blind” (randomize) the certificate’s public key… … and also the signature of the CA … … but cannot modify the attributes the CA certifies for him. User can disclose only the minimal attribute property the Verifier needs to know … … but needs to know all the attributes in the certificate to make his own signature with the certificate’s secret key

22. 22 © Copyright 2004, Credentica Inc. All Rights Reserved Cross-organizational SSO with Credentials User Digital Credential issuer Program 2 2) Use Digital Credentials 1) Get Digital Credentials 1 Program Untraceable Unlinkable Plus: privacy-preserving (!) techniques for cross-domain data sharing, cross-platform blacklisting, and fraud tracing

23. 23 © Copyright 2004, Credentica Inc. All Rights Reserved Properties of Digital Credentials (1) Fully adaptable levels of privacy: Anonymous, pseudonymous, role-based access, and anything “in- between” Principle of least authority; selective/minimal disclosure Reverse authentication: data does not meet conditions Recertification and updating: present Digital Credential without revealing current attribute values Dossier-resistance: leave no or partial non-repudiable transaction evidence to verifier Credential verifier can selectively hide data before passing on digital evidence 3 rd party Credential Authorities can be prevented from learning the attributes that they certify Smartcard cannot leak sensitive data to outside world

24. 24 © Copyright 2004, Credentica Inc. All Rights Reserved Properties of Digital Credentials (2) Security protections: No pooling of privileges (multiple Digital Credentials can be shown to contain same identifier without disclosing it) Lending protection: Embed client-confidential data into Digital Credential (legitimate owner need never disclose it) Discarding protection: Lump negative data in base Digital Credential (e.g., drunk driving mark into driver’s license) Limited-show credentials: Embedded identifier (or value) exposed if and only if Credential shown too many times Audit capability: – Digital audit trails & receipts facilitate dispute resolution – Non-identified audit trail cannot be disavowed by originator – Self-signed fraud confessions for lending and reuse

25. 25 © Copyright 2004, Credentica Inc. All Rights Reserved Properties of Digital Credentials (3) Smartcard Implementations: Manage billions of Credentials using 8-bit smart-card chip (off- load storage and computational burden to user device) Application provider can arbitrarily minimize level of trust placed in smartcard (through application software) Secure multi-application smartcards: – Different application providers can share same secret key – Digital Credentials have uncorrelated secret keys (unknown even to card supplier) and can be revoked separately – Different applications using same smartcard are fire-walled through user software (not card software!) – Leakage of a card’s key does not allow fraud beyond the security functionality the card was supposed to add

26. 26 © Copyright 2004, Credentica Inc. All Rights Reserved Properties of Digital Credentials (4) Managed services: Credential Authorities certify sensitive information without being able to learn the data Revocation Authorities can validate certificates without being able to identify the clients of organizations Role of tamper-resistant smartcard can be outsourced Peer-to-peer support: Individuals can store and manage their own credentials Unauthorized users cannot modify, discard, lend, pool, or prevent the updating of information they hold Distribute all back-end database entries to data subjects Multi-purpose and multi-application certificates