Challenges and Architectural Approaches for Authenticating Mobile Users

1. Challenges and Architectural Approaches forAuthenticating Mobile Users João Pedro Sousa George Mason University Fairfax, VA Workshop on Software Architectures and Mobility

2. authentication of mobile userswhat is the problem? what are solutions? requirements media library: verify that the user has access smart space: verify that the user has access display: verify that PDA is intended remote control media library: verify that display is intended output ... establish secure channels • example: user wants to • access media libraryfor which has membership • stream media to wall in lounge • use PDA as remote control media library

3. verification vs. selectiontwo related but distinct problems verify properties • identity • membership • trustworthinessuncompromised platform • demographicscustomer segments mechanism: authentication answer: yes/no • predict QoS properties • success/failure • latency • integrity • confidentiality... • mechanism: trust managementrecommender systems • answer: quantitative assessment

4. remote personalized service group/public services outline • classes of theverification problem • User Access to Services • Group Access to Services • Link Peers • architectural patterns • challenges

5. UASUser Access to Services • server URL • user credentials personal/local device + connectivity • telnet • PC anywhere • e-banking • e-payments • ... • verify • identity remote personalized service

6. GASGroup Access to Services • proof of membership/trustworthiness • demographics/interests info • (personal +) local devices: • membership services (library...) • e-voting • services in smart spaces • e-commerce • ... k-anonymity • verify • membership • trustworthinessuncompromised platform • demographics group/public services

7. LPLink Peers • personal devices: • social exchange/chatting • file sharing • media streaming • remote control • ... • verify • demographics/interests • membership/identity • co-ownership

8. credentials play key rolemany types with pros and cons • UAS: prove identity • GAS: prove right to access • LP: prove co-ownership • what’s in your vicinity • where you are:secure spaces • what you carry:smart cards, one-time pwd • may preserve anonymity • feasible to change/keep private • may be hard to keep track of • what you know • passwords • easy to change/keep private • hard to keep track of • disruptive to provide • zero-knowledge proofs • doesn’t reveal what you know • very complex to provide • who you are • fingerprints, face,voice, gait recognition • very easy to provide • false positives/negatives • hard to change/keepprivate

9. outline classes of the verification problem User Access to Services Group Access to Services Link Peers architectural patterns challenges

10. traditional authenticationaddresses UAS • server URL • user credentials WS server issuers uid→ACL <tix, uid> uid, URL tickets issuer uid→pwd <tix, uid> Needham-Schroeder protocol tickets protocol access protocol <x> encrypted text

11. traditional authenticationconceived to protect servers • server URL • user credentials WS server issuers uid→ACL tickets issuer • reveals credentials& intention to communicate with specific serverbefore issuer is authenticated • may have to trust shared WS • implicitly trusts server uid→pwd

12. short range radio: Bluetooth... line of sight: infra-red co-location: shake dev peers dev dev dev peers LPis increasingly popular for mobile devices • applications • media sharing/streaming • remote control local connector wide-area connector ownership

13. LP is used in P2P systemsto establish a secure link • local area networks(with free connectivity) • peers may establish secure link while hiding identity from others • no need for central authority • peers need to know each other beforehand (off band) • authentication of users implied by ownership (what you carry) dev peers dev peers selection (trust management) is arguably just as relevantas authentication in P2P systems local connector wide-area connector ownership

14. LP combined with UAS/GAS for wide-area/paid connectivity • peers (service consumers/providers) and carriers may eachhave their own security policies • multilateral security (telecom) • for billing, prior to LPusers authenticate with carriers • UAS for personalized billing • GAS for using certified e-currency(UAS with broker entity) dev peers dev peers

15. GAS in shared spaces:users remain k-anonymous • in membership-based spaces, users’ PDA: • starts secure UAS to certificates issuer • obtains anonymous one-time certificates • reveals membership to ambient (k-anonymity) • ambient cannot track identity or usage patterns • may request identity of malicious users to cert. issuer • certificates issuer may track identity and usage • hence backlash against MS Passport • zero-knowledge proofs • do not require third party (cert. issuer) • limited use due to complexity PDA issuers profiles ambient services gid→ACL certificates issuer certificates protocol ambient access identification protocol

16. GAS in shared spaces:users remain k-anonymous • in public/commercial spaces,ambient seeks to obtain demographics/interests for targeting info & services • PDA may release a diff pseudonym at each location(requires autonomous location awareness) • ambient remembers habits/prefs of regular users • can’t transfer knowledge across similar spaces • PDA may release one-time pseudonyms • PDA remembers habits/prefs of user andreleases the ones associated to each typeof space/requested service PDA issuers profiles ambient services gid→ACL ambient access

17. UAS in shared spacesappealing and risky • users will access personalized services • may not have the skill or the willto protect PDA from cyber attacks at malicious/unsecure spaces • compromised PDAs can act as stepping stones to attack personalized services (stored URLs & pwds) • servers may adjust ACLbased on user’s location • PDA compromised at high-risk locationmay manifestat location deemed low-risk(and open access) PDA issuers profiles ambient services gid→ACL server certificates issuer uid→ACL certificates protocol ambient access identification protocol

18. UAS in shared spacesPDA may get in the way • give users a false sense of securityin high-risk spaces • limiting:users may want to engage localcapabilities for accessing remote services • overhead:remember to carry PDAand charge battery • may not be justified in trusted spaces • medical staff moving within a hospital • corporate campuses… PDA issuers profiles ambient services gid→ACL server certificates issuer uid→ACL certificates protocol ambient access access protocol identification protocol

19. UAS in shared spacespossible without PDA • as in traditional authenticationmalicious space may capture credentials • replay and piggyback attacks • space may obtain undue access to personal services • new risks associated with ubiquitous access • space may reveal user presence and activity • threats to privacy and personal security • if space is not secure enoughit may unintentionally facilitateall of the above • server URL • user credentials ambient services uid→ACLissuers server certificates issuer uid→ACL certificates protocol access protocol

20. UAS in shared spacesbroaden perspective on protection (as) before ACL protects server’s resourcesagainst malicious users now, also protect user’s assets/privacyagainst malicious spaces/others • server URL • user credentials ambient services uid→ACLissuers server certificates issuer X→ACL certificates protocol access protocol

21. UAS in shared spacestradeoff access and protection protection: some spaces have trusted admin some don’t access: users may be ok with accessinga subset of personalized services at different spaces authentication and granting access becomes a multilateral problem logging and accountability complements upfront access control ambient services ambient services ambient services ambient services uid→ACLissuers uid→ACLissuers uid→ACLissuers uid→ACLissuers server certificates issuer X→ACL

22. authentication gets complexeven in simple scenarios challenge: framework • help users manage the release of credentialsand be aware of access/protection tradeoffs • works in degraded modes when parts are missing • role of infrastructure/trusted third parties? • role of personal devices? • example: user wants to • access media libraryfor which has membership • stream media to wall in lounge • use PDA as remote control media library GAS local LP remote LP

23. remote personalized service group/public services discussion • classes of theverification problem • User Access to Services • Group Access to Services • Link Peers • architectural patterns • challenges

24. server URL • user credentials ambient services uid→ACLissuers server certificates issuer X→ACL UAS in shared spacesmultilateral authentication & trust • ambient services facilitate UAS • each party needs to authenticate and grant access to others • each party may establish access control policies for others • personalized server may grant less to user at risky ambient • a user may trust a space for certain things, but not others • logging and accountability complements upfront access control PDA issuers profiles dev peers ambient services gid→ACL server certificates issuer X→ACL dev peers