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 QoS 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
uid→ACL
tickets issuer
uid→pwd
may have to 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
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 P2P 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 P2P systems
authentication of users implied by
ownership (what you carry)
SAM @ ICSE 2008
authenticating mobile users © Sousa
dev
dev
peers
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
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
ambient
services
ambient
services
uid→ACL
issuers
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
issuers
profiles
dev peers
server URL
user credentials
ambient
services
ambient
services
uid→ACL
issuers
gid→ACL
dev peers
server
X→ACL
certificates
issuer
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