Privacy Preserving Identity Attribute Verification in Windows CardSpace
Upcoming SlideShare
Loading in...5

Privacy Preserving Identity Attribute Verification in Windows CardSpace






Total Views
Slideshare-icon Views on SlideShare
Embed Views



1 Embed 185 185



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Privacy Preserving Identity Attribute Verification in Windows CardSpace Privacy Preserving Identity Attribute Verification in Windows CardSpace Presentation Transcript

    • Privacy Preserving Identity Attribute Verification in Windows CardSpace Kevin Steuer Jr Ruchith Fernando Elisa Bertino October 8, 2010
    • Windows CardSpace
    • Identity Manager Identity Selector Relying Party
    • Identity Manager ● Information card issuer ● Security Token Service
    • Identity Selector
    • Source :
    • Information Card
    • XML Descriptor Issued by an identity manager Managed & Self Issued
    • Relying Parties/Service Providers ● Specifies the required claims ● Expects an XML token containing the values
    • Problems ?
    • Identity Manager is trusted in securely storing user's identity attribute values Identity Manager holds the attribute values in plain
    • Proposed Approach
    • Semi-Trusted Identity Manager
    • Relying Party → User : Do you have a Social Security Number?
    • Just proving that the user does is sufficient!
    • No need to give away the SSN to the Relying Party!
    • Let the Identity Manager store only a COMMITMENT of the SSN We use the Pedersen commitment
    • Pedersen Commitment c=gxhr ●G : Finite cyclic group of large prime order p so that the Computational Diffie-Hellman (CDH) problem is hard in G ● A generator g ∊ G ● x, r ∊ {0, 1, ... , p-1} = Fp
    • The user obtains a signed identity attribute value from an identity provider Sets up the commitment with the identity manager
    • How is it used with at a Service Provider?
    • Zero Knowledge Proof Of Knowledge
    • Schnorr protocol 1. U randomly chooses y, s ∊ F*p , and sends V the element d = gyhs ∊ G 2. V picks a random value e ∊ F*p , and sends e as a challenge to U. 3. U sends u = y + ex, v = s + er, both in Fp, to V. u v e 4. V accepts the proof if and only if g h = d c in G.
    • VeryIDX Managed Card
    • <ic:SupportedClaimType Uri="http://veryidx...strongclaims/ssn"> <ic:DisplayTag>Strong Claim SSN</ic:DisplayTag> <ic:Description>Strong Claim ...</ic:Description> </ic:SupportedClaimType> <vi:SupportedStrongClaimValues xmlns:vi="http://veryi..."> <vi:StrongClaimValue Uri="http://veryidx...strongclaims/ssn"> <vi:Commitment>743872676989=</vi:Commitment> <vi:R>329839797987493827983=</vi:R> </vi:StrongClaimValue> </vi:SupportedStrongClaimValues>
    • User is prompted to enter the value of the strong claim to carryout the proof
    • But ....
    • What about the 2nd and 3rd attempts?
    • Linkability Consistent attribute values to the relying parties
    • The identity selector will prove the same commitment value to the relying party!
    • Make sure we don't present the same commitment twice to the relying party!
    • Original Commitment : c1 = gxhr Commitment in the token to RP : ci = gc1hri
    • Request Security Token Response <wst:RequestSecurityTokenResponse> ... <vi:SupportedStrongClaimValues> <vi:ClaimValue Uri="http://veryidx...strongclaims/xyz"> <vi:Commitment>77666876989=</vi:Commitment> <vi:R>329839797987493827983=</vi:R> </vi:ClaimValue> </vi:SupportedStrongClaimValues> </wst:RequestSecurityTokenResponse> Used by the identity selector to retrieve the new commitment and random values
    • Identity Manager : WSO2 Identity Server (IS) Identity Selector : Higgins Relying Party : WSO2 IS Java RP ZKPK implementation : VeryIDX
    • Thank You !