Challenges and Architectural Approaches for Authenticating Mobile Users

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

authentication of mobile users what is the problem? what are solutions? example: user wants to access media library for which has membership media library stream media to wall in lounge use PDA as remote control 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

verification vs. selection two related but distinct problems verify properties identity membership trustworthiness uncompromised platform demographics customer segments mechanism: authentication answer: yes/no SAM @ ICSE 2008 predict Qo. S properties success/failure latency integrity confidentiality. . . mechanism: trust management recommender systems answer: quantitative assessment authenticating mobile users © Sousa 3

outline classes of the verification problem remote personalized service User Access to Services Group Access to Services group/public services Link Peers architectural patterns challenges SAM @ ICSE 2008 authenticating mobile users © Sousa 4

UAS User Access to Services server URL user credentials personal/local device + connectivity verify identity - telnet PC anywhere e-banking e-payments. . . remote personalized service SAM @ ICSE 2008 authenticating mobile users © Sousa 5

GAS Group Access to Services proof of membership/trustworthiness demographics/interests info k-anonymity verify membership trustworthiness (personal +) local devices: - membership services (library. . . ) - e-voting - services in smart spaces - e-commerce -. . . group/public services uncompromised platform demographics SAM @ ICSE 2008 authenticating mobile users © Sousa 6

LP Link Peers personal devices: - social exchange/chatting - file sharing - media streaming - remote control -. . . verify demographics/interests membership/identity co-ownership SAM @ ICSE 2008 authenticating mobile users © Sousa 7

credentials play key role many types with pros and cons 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 who you are fingerprints, face, voice, gait recognition very easy to provide false positives/negatives hard to change/keep private SAM @ ICSE 2008 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 UAS: prove identity GAS: prove right to access LP: prove co-ownership authenticating mobile users © Sousa 8

outline classes of the verification problem User Access to Services Group Access to Services Link Peers architectural patterns challenges SAM @ ICSE 2008 authenticating mobile users © Sousa 9

traditional authentication addresses UAS server URL user credentials WS issuers <tix, uid> server uid→ACL uid, URL <tix, uid> tickets issuer uid→pwd tickets protocol access protocol <x> encrypted text Needham-Schroeder protocol SAM @ ICSE 2008 authenticating mobile users © Sousa 10

traditional authentication conceived to protect servers server URL user credentials server WS issuers reveals credentials & intention to communicate with specific server before issuer is authenticated may have to uid→ACL tickets issuer uid→pwd trust shared WS implicitly trusts server SAM @ ICSE 2008 authenticating mobile users © Sousa 11

LP is increasingly popular for mobile devices applications media sharing/streaming remote control dev peers dev dev short range radio: Bluetooth. . . line of sight: infra-red co-location: shake SAM @ ICSE 2008 authenticating mobile users © Sousa peers local connector wide-area connector ownership 12

LP is used in P 2 P systems to 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) selection (trust management) is arguably just as relevant as authentication in P 2 P systems authentication of users implied by ownership (what you carry) SAM @ ICSE 2008 authenticating mobile users © Sousa dev peers local connector wide-area connector ownership 13

LP combined with UAS/GAS for wide-area/paid connectivity peers (service consumers/providers) and carriers may each have their own security policies dev peers multilateral security (telecom) for billing, prior to LP users authenticate with carriers UAS for personalized billing dev peers GAS for using certified e-currency (UAS with broker entity) SAM @ ICSE 2008 authenticating mobile users © Sousa 14

GAS in shared spaces: users remain k-anonymous PDA in membership-based spaces, users’ PDA: issuers profiles starts secure UAS to certificates issuer obtains anonymous one-time certificates reveals membership to ambient (k-anonymity) ambient services 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 SAM @ ICSE 2008 authenticating mobile users © Sousa gid→ACL certificates issuer certificates protocol ambient access identification protocol 15

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 issuers profiles ambient services gid→ACL PDA may release one-time pseudonyms PDA remembers habits/prefs of user and releases the ones associated to each type of space/requested service ambient access SAM @ ICSE 2008 authenticating mobile users © Sousa 16

UAS in shared spaces appealing and risky PDA users will access personalized services issuers profiles may not have the skill or the will to 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 ACL based on user’s location PDA compromised at high-risk location may manifest at location deemed low-risk (and open access) SAM @ ICSE 2008 authenticating mobile users © Sousa ambient services gid→ACL server uid→ACL certificates issuer certificates protocol ambient access identification protocol 17

UAS in shared spaces PDA may get in the way PDA give users a false sense of security in high-risk spaces issuers profiles limiting: users may want to engage local capabilities for accessing remote services ambient services overhead: gid→ACL remember to carry PDA and charge battery may not be justified in trusted spaces medical staff moving within a hospital corporate campuses… SAM @ ICSE 2008 authenticating mobile users © Sousa server uid→ACL certificates issuer certificates protocol ambient access protocol identification protocol 18

UAS in shared spaces possible without PDA as in traditional authentication malicious space may capture credentials server URL user 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 enough it may unintentionally facilitate all of the above SAM @ ICSE 2008 authenticating mobile users © Sousa server uid→ACL ambient services uid→ACL issuers certificates issuer certificates protocol access protocol 19

UAS in shared spaces broaden perspective on protection server URL user credentials ambient services (as) before ACL protects server’s resources against malicious users now, also protect user’s assets/privacy against malicious spaces/others uid→ACL issuers server X→ACL certificates issuer certificates protocol access protocol SAM @ ICSE 2008 authenticating mobile users © Sousa 20

UAS in shared spaces tradeoff access and protection ambient services uid→ACL issuers server X→ACL ambient services uid→ACL issuers certificates issuer protection: some spaces have trusted admin some don’t access: users may be ok with accessing a subset of personalized services at different spaces authentication and granting access becomes a multilateral problem logging and accountability complements upfront access control SAM @ ICSE 2008 authenticating mobile users © Sousa 21

authentication gets complex even in simple scenarios example: user wants to access media library for which has membership media library challenge: framework stream media to wall in lounge use PDA as remote control GAS local LP remote LP help users manage the release of credentials and be aware of access/protection tradeoffs works in degraded modes when parts are missing role of infrastructure/trusted third parties? role of personal devices? SAM @ ICSE 2008 authenticating mobile users © Sousa 22

discussion classes of the verification problem remote personalized service User Access to Services Group Access to Services group/public services Link Peers architectural patterns challenges SAM @ ICSE 2008 authenticating mobile users © Sousa 23

UAS in shared spaces multilateral authentication & trust PDA server URL user credentials issuers profiles dev peers ambient services uid→ACL issuers gid→ACL dev peers server X→ACL certificates issuer 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 SAM @ ICSE 2008 authenticating mobile users © Sousa 24