privacy and identity authentication © copyright 2004, credentica inc. all rights reserved. dr....

Privacy and Identity Authentication

© Copyright 2004, Credentica Inc. All Rights Reserved.

Dr. Stefan BrandsCredentica & McGill School of Computer Science

June 8, 2004

Presented to: EA Open House 2004, Ontario

2© Copyright 2004, Credentica Inc. All Rights Reserved

Content

• Part I• Introduction

• Part II• Case study: Liberty Alliance

• Part III• Digital Credentials


Part I

Introduction


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, …)


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!


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 (?)


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


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


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


Part II

Case study: Liberty Alliance


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)


Federation introduction (animation)

User

Identity Provider

SP

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, …)


Account linking (animation)

User

SP

SP

SP IdentityProvider

1) Login as usual

2) Linking “consent”

3) User-handle generationUsernamePassword(Cookie)

Account linking?

Yes

User-handle

(“contextual” ID …)

UserId = User-handle

Username = User-handle

4) User-handle storing


Single sign-on (animation)

User

SP

SP

SP IdentityProvider

1) (Strong) identification

2) Single sign-onIdentificati

on3) Service access

Authentication

assertion

Authentication

request & SP id

UserId = User-handle

Username = User-handle


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)


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


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


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


Part III

Digital Credentials


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


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


Cross-organizational SSO with Credentials

User

Digital Credential

issuerProgram

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


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 3rd party• Credential Authorities can be prevented from learning

the attributes that they certify• Smartcard cannot leak sensitive data to outside world



• 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



• 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



• 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

privacy and identity authentication © copyright 2004, credentica inc. all rights reserved. dr....

Documents