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? 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 library for which has membership stream media to wall in lounge use PDA as remote control media library

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

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

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

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

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

ICSE 2008 authenticating mobile users © Sousa8 credentials play key role many types with pros and cons UAS: prove identity GAS: prove right to access LP: prove co-ownership 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 /keep private 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

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

ICSE 2008 authenticating mobile users © Sousa10 traditional authentication addresses UAS WS server uid → ACLissuers tickets issuer uid → pwd Needham-Schroeder protocol tickets protocol access protocol encrypted text uid, URL server URL user credentials

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

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

ICSE 2008 authenticating mobile users © Sousa13 LP is used in P2P systems to establish a secure link local connector wide-area connector ownership 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 relevant as authentication in P2P systems

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

ICSE 2008 authenticating mobile users © Sousa15 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 GAS in shared spaces: users remain k-anonymous ambient services gid → ACL certificates issuer PDA issuers profiles certificates protocol ambient access identification protocol

ICSE 2008 authenticating mobile users © Sousa16 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 and releases the ones associated to each type of space/requested service GAS in shared spaces: users remain k-anonymous ambient services gid → ACL PDA issuers profiles ambient access

ICSE 2008 authenticating mobile users © Sousa17 UAS in shared spaces appealing and risky users will access personalized services 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) ambient services gid → ACL PDA issuers profiles server uid → ACL certificates issuer certificates protocol ambient access identification protocol

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

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

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

ICSE 2008 authenticating mobile users © Sousa21 UAS in shared spaces tradeoff access and protection 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 ambient services uid → ACL issuers server X → ACL certificates issuer ambient services uid → ACL issuers ambient services uid → ACL issuers ambient services uid → ACL issuers

ICSE 2008 authenticating mobile users © Sousa22 authentication gets complex even in simple scenarios challenge: framework 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? example: user wants to access media library for which has membership stream media to wall in lounge use PDA as remote control media library GAS local LP remote LP

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

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