FileSpace An alternative to CardSpace that supports MultipleToken Authorisation and Portability Between Devices

1. FileSpaceAn alternative to CardSpace that supports MultipleToken Authorisation and Portability Between Devices David Chadwick University of Kent NIST IDTrust 2009

2. Contents • Problem statement and solution idea • User experiences of using InfoCards and FileSpace • At service provision time • At Card/File issuing time • Technical properties of FileSpace • Detailed Comparison of FileSpace and InfoCards • Conclusion NIST IDTrust 2009

3. Problem Statement • A user typically has multiple cards • today each plastic card issuer only puts one attribute on a card, Visa member, AAA frequent flyer, IEEE member etc. so why expect that in InfoCards all this information will be on one card. It wont. • But she can only use one of these cards in any given InfoCard/CardSpace transaction • Insufficient for many purposes • buy a book at a discount using Visa card and student card • access patient data using Doctor card and hospital employee card • Users need to be able to select/present multiple cards • Cards may not be easily transported to all devices • e.g. use on a mobile phone • initial version of CardSpace did not have an export capability NIST IDTrust 2009

4. Solution Idea • Instead of cards, use files • Files are an existing well known concept to all computer users • Users are already familiar them, know how to drag and drop, copy, delete them etc. • So if every credential (plastic card) becomes a file, then user can copy them easily between devices, send multiple files to service providers etc. NIST IDTrust 2009

5. Example user’s directory with FileSpace files NIST IDTrust 2009

6. Click Comparison of User Experiences- at Service Provision Time LOGIN InfoCard FileSpace NIST IDTrust 2009

7. User Selects FileSpace LOGIN InfoCard FileSpace NIST IDTrust 2009

8. User Selects Files To Upload LOGIN InfoCard FileSpace NIST IDTrust 2009

9. User is asked to Confirm he isFather Christmas LOGIN InfoCard FileSpace NIST IDTrust 2009

10. User’s Private Key could be in a hardware token IBM’s ZTIC USB device Mobile Phone NIST IDTrust 2009

11. User is provided with service NIST IDTrust 2009

12. Click Comparison of User Experiences- at Service Provision Time LOGIN InfoCard FileSpace NIST IDTrust 2009

13. User is asked to choose a single InfoCard NIST IDTrust 2009

14. User is asked to provide password for card provider NIST IDTrust 2009

15. User is provided with service NIST IDTrust 2009

16. User must Login to his account (over SSL) User Experience at Enrolmente.g. to get an electronic MasterCard NIST IDTrust 2009

17. Then Ask For Electronic Card/File to be Created • User may need to select which attribute(s) to be included or IDP may choose them • In FileSpace, there is an additional step of sending your Certificate (e.g. Father Christmas) and proving ownership NIST IDTrust 2009

18. Then Select Where to Download File To NIST IDTrust 2009

19. In CardSpace User then has to Import file into Card Selector NIST IDTrust 2009

20. Creating a New Identity • In CardSpace we have self issued cards, whereby a user enters his own attributes into his cards • In FileSpace we have new identity cards, either self issued (e.g. Father Christmas) or issued by a CA such as Versign (e.g. my Bill Gates cert) (so not much difference there then !) NIST IDTrust 2009

21. Basic Principles of FileSpace • Clearly Separate Authentication from Authorisation by having separate tokens • Have multiple Authz Tokens linked to one Authn Token • Each Authz Token provides an attribute assertion from a trusted authoritative source • Have one Authn Token per Pseudonym • this is purely a handle on which to hang the Authz tokens. The pseudonym can be anything • user can have as many pseudonyms as he wishes NIST IDTrust 2009

22. Token Lifetimes • All FileSpace tokens are long lived and can be used repeatedly • User has to authenticate to service provider that he is the holder of all of them at time of use • In CardSpace all tokens are short lived and issued on demand • this requires authn to the card issuer each time a service is required • Each FileSpace Authz Token can be independently revoked by the issuer (AA) • so if user looses his private key he can ask AAs to revoke his authz credentials (no need to revoke authn credential) NIST IDTrust 2009

23. Authn Tokens • Public key certificate containing any subject DN the issuer chooses to put there, subject to it being globally unique (which is mandatory in X.509 anyway!!) • Can be user generated (self issued) • unique DN can be generated by having public key id RDN + user provided CN RDN • Can be CA generated • unique DN can be CA name plus user provided CN RDN • It does not matter since it is not used for authorisation, only for authentication • Contains a pointer to where relying party can find private key in order to validate that the current user is the holder of the private key – solves the Discovery problem • could be mobile phone number, or “user’s browser” NIST IDTrust 2009

24. Authz Tokens • Are standard claims/assertions/certificates that say this subject has this attribute, signed by issuer • However, subject id and attribute are encrypted (indirectly) to key public key of subject • Can be lost or stolen but are worthless to finder/thief because he cant decrypt them • Only valid once subject proves to RP that he has the decryption key • In practise we encrypt to a symmetric key and encrypt symmetric key to public key of subject then subject can decrypt symmetric key and encrypt it to public key of RP allowing RP to read the contents NIST IDTrust 2009

25. Service Provision • User selects set of Authz Tokens and the matching Authn Token to send to service provider (through file upload function) • SP reads location of private key from Authn token and sends a message containing tokens and asking for decryption keys • User is asked to confirm SP can have these tokens, then enters PIN to private key and device creates decryption keys for the SP and returns them NIST IDTrust 2009

26. Protocol Exchange • SP-> private key location: {{authzCredi} i=1 to n, nonce1, ts1, SPPKC}signSP • Private key location -> SP: {{sni, encKeyi} i=1 to n, nonce1, nonce2, ts2, SP}signUser • Where: • n is the number of authorisation credentials to be decrypted • SPPKC is public key certificate of Service Provider • nonce is a random number and ts is a short time in the future (say 2 seconds) • sni is serial number of ith authorisation credential • encKeyi is symmetric key used to encrypt the contents of authorisation credential i, encrypted to the public key of the recipient SP NIST IDTrust 2009

27. Detailed Comparison (1) NIST IDTrust 2009

28. Detailed Comparison (2) NIST IDTrust 2009

29. Detailed Comparison (3) NIST IDTrust 2009

30. Merging InfoCards and FileSpace David Chadwick NIST IDTrust 2009

31. Conclusion • FileSpace overcomes a major disadvantage of CardSpace/InfoCards, that of not being able to send multiple cards • FileSpace does not lose out on usability since users already know how to use files (and it could be integrated into Card Selectors) • It has a number of security advantages as well • better privacy protection at the IdP • don’t need to worry about securing the desktop (unless private keys are held there) NIST IDTrust 2009

32. Any Questions? NIST IDTrust 2009