Convener: Hans Harmannij
Abstract: Polymorphic pseudonyms can be used to solve several privacy problems, related to linking users across parties, including the identity provider, tracking Service Provider usage by the IDP, and tracking by a hub or proxy. At the same time it allows collaboration between specific SPs, and it allows switching IDPs by the user, while remaining known to SPs.
Tags: Pseudonymity, Unlinkability, Unobservability
Master thesis
Introduction: what are polymorphic pseudonyms?
Problems we face:
Features:
Homomorphic encryption: we can create a polymorphic pseudonyms(PP) and do adaptions to the data even though its encrypted.
A polymorphic pseudonym is general for the user.
PP and EP can be randomised which so they are unlinkable to earlier sessions with different copies of the same pseudonym. If you decrypt an EP, you get a random looking string which is different for diff service providers (but is the same for the service provider each time the user logs in there)
Demonstration: logging in to a service provider via shibboleth.
EP is different in different session, final pseudonym is the same at the same service provider.
Variations:
Homomorphic encryption
System wide public key k (k...random value)
Conv. changed the public key with which it is encrypted by...? // changed general encryption
k, k', k'' are rand. Numbers.
PP = EG(uid, yk, k)
->
EG(uid, yk | SPid, k')
=
EG(uid, k', ysp)
->
EG(uid | SPid, ysp, k'')
=EP
aud1: how much information does the pseudonym facility get?
convener: not really any. ID provider contacts ps. fac. and it only sends a randomised PP; the pseudonym facility can't see anything about the user.
aud2: 'full mesh': encrypt P, then transferred to SP. why is that encryption necessary? Maybe to protect the value?
convener: to make sure the P is only really visible to the SP
aud3: where does this apply? Who would be interested in this?
convener: still looking if there are any better solutions. Also looking for ways to get rid of the database.
aud4: scenario: in primary education: you got a relation between a publisher and a publishing house. Need to send your data to both entities.
contract between publishing house and ...?, but they don't need to know each other
-Paper on this (NL)-
aud5: If a single user is enrolled by SP1 or 2, the collaboration space concerned doesn’t know it is the same person?
Diff SP work together - get same data.
aud6: if you have one of the P of the SP, you decrypt it --> get a random string back.
? - Encrypted parts are random.
aud7: Are there any obstacles in implementing this (?) from an organisational viewpoint?
Key management authority and Pseudonym facility needed, as extra parties. PF can be the same as the hub, then can’t be a SP. Organisational problem exists. Not a lot of technical problems.
convener: Possible to create polymorphic attributes that are suitable for all SP. but first need to be specialised for diff. parties.
__________________________________________________________
Links etc. will be shared via e-mail
Source code: https://github.com/polymorphic-pseudonyms
Paper by Eric Verheul about polymorphic pseudonyms in Dutch education, containing all technical details: http://www.cs.ru.nl/E.Verheul/papers/PP2/PEKScheme.pdf
