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 userswhat is the problem? what are solutions?
requirementsmedia library: verify that the user has accesssmart space: verify that the user has accessdisplay: verify that PDA is intended remote controlmedia library: verify that display is intended output... establish secure channels
example: user wants toaccess media libraryfor which has membership
stream media to wall in loungeuse PDA as remote control
media library
SAM @ ICSE 2008 authenticating mobile users © Sousa3
verification vs. selectiontwo related but distinct problems
verify propertiesidentitymembershiptrustworthinessuncompromised platform
demographicscustomer segments
mechanism: authentication
answer: yes/no
predict QoS propertiessuccess/failurelatencyintegrityconfidentiality...
mechanism: trust management
recommender systems
answer: quantitative assessment
SAM @ ICSE 2008 authenticating mobile users © Sousa4
outline
classes of theverification problem
User Access to Services
Group Access to Services
Link Peers
architectural patternschallenges
remote personalized service
group/public services
SAM @ ICSE 2008 authenticating mobile users © Sousa5
UASUser Access to Services
- telnet- PC anywhere- e-banking- e-payments- ...
remote personalized service
personal/local device
+connectivity
personal/local device
+connectivity
server URLuser credentials
verifyidentity
SAM @ ICSE 2008 authenticating mobile users © Sousa6
GASGroup 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/trustworthinessdemographics/interests info
verifymembershiptrustworthinessuncompromised platform
demographics
k-anonymity
SAM @ ICSE 2008 authenticating mobile users © Sousa7
LPLink Peers
personal devices:- social
exchange/chatting- file sharing- media streaming- remote control- ...
personal devices:- social
exchange/chatting- file sharing- media streaming- remote control- ...
verifydemographics/interests
membership/identity
co-ownership
SAM @ ICSE 2008 authenticating mobile users © Sousa8
credentials play key rolemany types with pros and cons
UAS: prove identityGAS: prove right to accessLP: prove co-ownership
what you knowpasswords
easy to change/keep private
hard to keep track ofdisruptive to provide
zero-knowledge proofsdoesn’t reveal what you knowvery complex to provide
who you arefingerprints, face,voice, gait recognition
very easy to providefalse positives/negativeshard to change/keep private
what’s in your vicinitywhere you are:secure spaces
what you carry:smart cards, one-time pwd
may preserve anonymityfeasible to change/keep private
may be hard to keep track of
SAM @ ICSE 2008 authenticating mobile users © Sousa9
outline
classes of the verification problemUser Access to ServicesGroup Access to ServicesLink Peers
architectural patternschallenges
SAM @ ICSE 2008 authenticating mobile users © Sousa10
traditional authenticationaddresses UAS
WS server
uid→ACLissuers
tickets issuer
uid→pwd
Needham-Schroeder protocol
tickets protocol
access protocol
<x> encrypted text
uid, URL
<tix, uid>
<tix, uid>
server URLuser credentials
SAM @ ICSE 2008 authenticating mobile users © Sousa11
reveals credentials& intention to communicate with specific serverbefore issuer is authenticated
may have to trust shared WS
implicitly trusts server
traditional authenticationconceived to protect servers
WS server
uid→ACLissuers
tickets issuer
uid→pwd
server URLuser credentials
SAM @ ICSE 2008 authenticating mobile users © Sousa12
LP is increasingly popular for mobile devices
short range radio: Bluetooth...line of sight: infra-redco-location: shake
local connector
wide-area connector
ownership
dev
dev
applicationsmedia sharing/streamingremote control
devpeers
devpeers
SAM @ ICSE 2008 authenticating mobile users © Sousa13
LP is used in P2P systemsto 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 othersno need for central authoritypeers need to know each other beforehand (off band)
authentication of users implied by ownership (what you carry)
devpeers
devpeers
selection (trust management)is arguably just as relevant
as authentication in P2P systems
SAM @ ICSE 2008 authenticating mobile users © Sousa14
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)
devpeers
devpeers
SAM @ ICSE 2008 authenticating mobile users © Sousa15
in membership-based spaces, users’ PDA:starts secure UAS to certificates issuerobtains anonymous one-time certificatesreveals membership to ambient (k-anonymity)
ambient cannot track identity or usage patternsmay request identity of malicious users to cert. issuer
certificates issuer may track identity and usagehence backlash against MS Passport
zero-knowledge proofsdo not require third party (cert. issuer)limited use due to complexity
GAS in shared spaces:users remain k-anonymous
ambientservices
gid→ACL
certificatesissuer
PDA
issuersprofiles
certificates protocol
ambient access
identification protocol
SAM @ 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 userscan’t transfer knowledge across similar spaces
PDA may release one-time pseudonymsPDA remembers habits/prefs of user andreleases the ones associated to each typeof space/requested service
GAS in shared spaces:users remain k-anonymous
ambientservices
gid→ACL
PDA
issuersprofiles
ambient access
SAM @ ICSE 2008 authenticating mobile users © Sousa17
UAS in shared spacesappealing and risky
users will access personalized servicesmay not have the skill or the willto protect PDA from cyber attacks at malicious/unsecure spacescompromised 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)
ambientservices
gid→ACL
PDA
issuersprofiles
server
uid→ACLcertificates
issuer
certificates protocol
ambient access
identification protocol
SAM @ ICSE 2008 authenticating mobile users © Sousa18
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 spacesmedical staff moving within a hospitalcorporate campuses…
ambientservices
gid→ACL
PDA
issuersprofiles
server
uid→ACLcertificates
issuer
certificates protocolambient access
identification protocolaccess protocol
SAM @ ICSE 2008 authenticating mobile users © Sousa19
UAS in shared spacespossible without PDA
as in traditional authenticationmalicious space may capture credentials
replay and piggyback attacksspace may obtain undue access to personal services
new risks associated with ubiquitous accessspace may reveal user presence and activitythreats to privacy and personal security
if space is not secure enoughit may unintentionally facilitateall of the above
ambientservices
uid→ACLissuers
server
uid→ACLcertificates
issuer
certificates protocol
server URLuser credentials
access protocol
SAM @ ICSE 2008 authenticating mobile users © Sousa20
UAS in shared spacesbroaden perspective on protection
(as) beforeACL protects server’s resourcesagainst malicious users
now, alsoprotect user’s assets/privacyagainst malicious spaces/others
ambientservices
uid→ACLissuers
server
X→ACLcertificates
issuer
certificates protocol
server URLuser credentials
access protocol
SAM @ ICSE 2008 authenticating mobile users © Sousa21
UAS in shared spacestradeoff access and protection
protection: some spaces have trusted admin some don’taccess: users may be ok with accessinga subset of personalized services at different spaces
authentication and granting access becomes a multilateral problemlogging and accountability complements upfront access control
ambientservices
uid→ACLissuers
server
X→ACLcertificates
issuer
ambientservices
uid→ACLissuers
ambientservices
uid→ACLissuers
ambientservices
uid→ACLissuers
SAM @ ICSE 2008 authenticating mobile users © Sousa22
authentication gets complexeven in simple scenarios
challenge: frameworkhelp users manage the release of credentialsand be aware of access/protection tradeoffsworks in degraded modes when parts are missing
role of infrastructure/trusted third parties?role of personal devices?
example: user wants toaccess media libraryfor which has membership
stream media to wall in loungeuse PDA as remote control
media library GAS
local LPremote LP
SAM @ ICSE 2008 authenticating mobile users © Sousa23
discussion
classes of theverification problem
User Access to Services
Group Access to Services
Link Peers
architectural patternschallenges
remote personalized service
group/public services
SAM @ ICSE 2008 authenticating mobile users © Sousa24
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 otherspersonalized server may grant less to user at risky ambienta user may trust a space for certain things, but not others
logging and accountability complements upfront access control
ambientservices
uid→ACLissuers
server
X→ACLcertificates
issuer
server URLuser credentials
ambientservices
gid→ACL
PDA
issuersprofiles
serverX→ACL
certificatesissuer
devpeers
devpeers
Top Related