Lecture 7: Privacy and Security in Mobile Computing

Lecture
7
: Privacy and Security in




Mobile Computing




Cristian

Borcea

Department of Computer Science

NJIT


Location Privacy


Location Authentication


Trusted Ad Hoc Networks

2

Client

Server

LBS Database

(Location Based Service)

Request:

Retrieve all bus lines from
location to address

=

=

Privacy Violated

3


Problem:







Research:



Continuous location exposure

a serious threat to privacy


Preserve privacy without
sacrificing


the quality of
continuous

location
based
applications

4

“A

message

from

a

client

to

a

database

is

called

location

anonymous

if

the

client’s

identity

cannot

be

distinguished

from

other

users

based

on

the

client’s

location

information
.
”


Database

K
-
anonymity
:

“A

message

is

called

location

k
-
anonymous

if

the

client

cannot

be

identified

by

the

database,

based

on

the

client’s

location,

from

other

k
-
1

clients
.
”


5

Client sends plain request
to the server

Server sends
“anonymized”
message

Database executes
request according to the
received anonymous data

Database replies to server
with compiled data

Server forwards data to
client

Server transforms the
message by “anonymizing”
the location data in the
message

6

Spatial Cloaking
–

Setting a range of space to be
a single box, where all clients located within the
range are said to be in the “same location”.

x

y

Temporal Cloaking
–

Setting a time interval,
where all the clients in a specific location sending
a message in that time interval are said to have
sent the message in the “same time”.

t

7

x

y

t

Spatial
-
Temporal Cloaking
–

Setting a range of space and a
time interval, where all the
messages sent by client inside
the range in that time interval.
This spatial and temporal area
is called a “cloaking box”.

8


Privacy is not the user’s main goal


Secondary to completing main task


Controlling privacy settings


Makes systems more complex


Hinders ease
-
of
-
use


Usable privacy settings


Provide transparent solutions


Put the user in control


Inform
the user about what is going on

9


Privacy fundamentalists


Uncompromising about their privacy


37% of the US population


Privacy unconcerned


Indifferent to privacy concerns


11% of the US population


Privacy pragmatists


Concerned about privacy, but willing to trade personal data for
benefit


52% of the US population


Not absolute


Changes over time (25% privacy fundamentalists in 2000)


Cultural differences

10

11


Yes, if they benefit from that


Study with 500+ people in Manhattan over 3
weeks


84% willing to share location to compute place crowding


77% willing to share their location data with others in
public or semi
-
public places


57% would like to know information about other people


Location Privacy


Location Authentication


Trusted Ad Hoc Networks

12


Provided by wireless
carriers


Provided by third
parties

13

LBS

Let’s hack the
phone and submit
false location


Commonly, third party LBSs receive location from mobile
devices


Determined by GPS, wireless triangulation (Intel’s
Placelab
), etc


Users prefer localization systems on mobiles: control location data


But can this location be trusted?

14

L

Location: L (Manhattan)


Why?


Get free location
-
based coupons

in

youza


Get
mayorship

deals in
foursquare


Track your friends in
loopt

15


Traditional solutions use infrastructure
support


E.g., measure signal strength of mobile from
fixed trusted beacons with known locations


Wireless carriers may refuse to
authenticate locations for third party
services


Due to business and legal reasons


Our

solution: LINK provides location
authentication independent of wireless
carriers


Trusted mobile devices act as trusted beacons
that certify if a user is in their proximity


Mobiles communicate through short range
wireless (Bluetooth)

15


Targets users who exhibit regular malicious
behavior


Users register with LINK and verify each other’s
location


Claimer
: submits location to LBS and asks neighbors for
verification


Verifier
: submits location verification for claimer


Users have public/private keys for crypto
operations

16


Location Certification Authority (LCA)


Centralized entity in Internet: receives location claims
and verifications


Makes location authentication decisions based on current
verifications, trust scores, and historical data

▪
Maintains user trust scores and updates them function of user
behavior

▪
Historical data contains claims, verifications, and trust score
evolutions


Informs LBS once a decision is made

17

18

INTERNET

C

V
1

V
3

V
2

V
4

LBS

LCA

broadcast
certification
request


certification
reply

certification
reply

claim
decision


Certification request signed by claimer


Includes
SeqNo

to identify specific claim


Certification replies signed by verifiers


Include cert. request to allow LCA to match with claims


Update C’s

trust score

How are trust


scores updated?


LCA updates claimer trust score function of claim
result
(additive increase, multiplicative decrease)


Accepted when have verifiers:
additive increase


Accepted when lack verifiers
: additive decrease

▪
Claimer has good trust score and no suspicious history


Rejected:
multiplicative decrease


Ignored:
no update



Verifiers sometimes required to authenticate their
location (i.e., act as claimers)


Cost: communication overhead and protocol complexity

19


LCA selects only verifiers with “good” trust scores


Improves authentication accuracy


If all verifiers contradict C:
claim rejected

20

C

V
1

V
3

V
2

LCA

Location claim: L

Certification reply: M

Certification reply: M

Certification reply: M


Spatio
-
temporal correlation


Could C have reached L from its previous location?


No:
claim rejected


If C’s trust score
&

trust score trend are “good”:
accept claim


C’s trust score decreased (additive)

21

C

V
1

V
3

V
2

LCA

Location
claim

I
have no neighbors


If C’s trust score

is “good” and
trust score trend is bad: reject claim


Else

ignore claim

Trust score trend measures regular malicious
behavior

-

Counts how often the trust score of a user
has been decreased over time

-

“few times” = legitimate user

-

“often” = malicious user


Individual attacks are thwarted if “good” verifiers are in
majority


Hard to collude because at least one of the verifiers would
need to follow claimer everywhere


Need to capture certification request and pass it to all colluders

22

C

V
1

V
3

V
2

LCA

Location claim: L

Certification reply: L

Certification reply: L

Certification reply: M


Attempts to slander claimer

If
|∑
T
v

-

∑

T
v
| > Threshold

Decision based on set of verifiers with greater trust sum

Else /* too close to call */

If
C’s trust score trend is “bad”:
reject claim

Else
Check trust score trends and locations of
blue


verifiers


If

blue verifiers are deemed malicious:
accept claim


Else

ignore claim

23

C

V
1

V
5

V
2

V
3

V
4

•

Red
verifiers agree with C

•

Blue
verifiers disagree with C

24

C

V
1

V
3

V
2

LCA

Location claim: L

Help me authenticate L

Colluders

Internet

Certification reply: L


Solution: maintain and analyze history of verifications


Weighted trust score for verifiers

▪
The more often one verifies, the less it contributes in verification

▪
Tv

/ log
2
w
;
Tv
:

V’s trust score; w: no. of times V verified for C


Over time, identify colluding users


Users
have many verifiers and only few of them
verify often (e.g.,
family)


If
significant no. of verifiers perform verifications
often, they may be
colluders


Maintain matrix of who verified for whom


M[v][c] counts how many times v has verified for c


Algorithm adapts dynamically to no. of claims and
no. of verifiers

25


LINK designed to balance privacy and usability


Users submit location only when requesting authentication
or verifying others


Users can define rate limits or place limits for
verifications


Verification messages could be encrypted to protect
against other mobile users in proximity


LCA enforces tit
-
for
-
tat mechanism (similar to
BitTorrent
)


User must participate in a few verifications before she
may issue claim

26


Malicious claimers attempt to “game” the system


Submit both “good” and “bad” requests


Claim to have no neighbors when submitting “bad” requests


First 10 minutes submit only “good” requests to improve trust score


Attacks detected quickly based on trust score trend
analysis

27

0
0.2
0.4
0.6
0.8
10min
70min
130min
190min
250min
False Negative Rate

Time Interval

1bad/4good
1bad/1good

Up to 6% of the total number of users collude with each
other to verify false claims


Use different permutations: 50% of colluders participate in any
verification


Colluding users detected quickly and punished by analyzing
their verification histories

28

0
0.2
0.4
0.6
0.8
1
1.2
10min
60min
110min
160min
210min
260min
False Negative Rate

Time Interval

12
10
8

Number
of claims
phone
can do until battery
exhausted
=
2,701


Number of verifications
phone
can do
until battery exhausted
=
20,458


Feasible from an energy consumption point of view

29


Bluetooth discovery takes the most
time and consumes the most energy


Linear increase function of number
of verifiers due to Bluetooth
connection establishment


Feasible for walking speeds from a
latency point of view


Implemented on Android phones


Location Privacy


Location Authentication


Trusted Ad Hoc Networks

30

31

Internet

Firewall

Good guys

Bad guy

Bad guy

Wireless ad
-
hoc network

Good guys

Protected network


Existing solutions for ad hoc networks are reactive


Is it possible to have a proactive method?

32


Stop attacks at
originators


Application
centric network
policy


Nodes
trusted to enforce the policy create
protected network


Unauthorized
traffic from trusted node is stopped at the
originator


Untrusted
nodes cannot establish a link with trusted
network

Enforcer


App A

Policy A

Trusted nodes

Enforcer


App A

Policy A

Application A

Untrusted node

Application

data

Unauthorized

traffic

33

Satem

Link

Driver

Connection
Manager

user

space

kernel

space

Trust establishment protocols

TPM

Wireless

Adaptor

hardware

Enforcer

Application

Satem

Link

Driver

Connection
Manager

TPM

Wireless

Adaptor

Enforcer

Application

Node 1

Node 2


Satem

guarantees trusted policy
enforcement


Changes
affecting the policy enforcement are forbidden or
cause
node to be
disconnected


TPM guarantees genuine kernel monitor (i.e.,
Satem
)


Enforcer
enforces the network
policy


Connection
manager handles trust establishment


34


How

to verify that a remote service is trustworthy?


Trustworthy (in this context) = have not been replaced or modified
to perform malicious actions


Same question can be asked for local programs


Threat model: OS/applications on remote platform may be
compromised


By local operator


Through network
-
enabled attacks


Solution: use
secure coprocessor
to build trusted systems


Trusted Platform Module (TPM):
a special
-
purpose chip built into a
variety of platforms to enable strong user authentication and
machine attestation


Defined by Trusted Computing Group


Tamper
-
resistant


Architecture


Computing logic
–

sign,
hash


Registers


Functions


Secure
key storage


Attestation


TPM based trusted boot


PCR
0

= SHA1(SHA1(SHA1(0|BIOS)|LILO)|OSK
)

35

Verifier
What code are
you running
?
Here’s the digest
of my code
`
Remote platform
36


Compute a hash value of a loaded program before execution
starts


This operation is called “measure the code”


The hash value can later be used by remote party to verify
the code integrity


E.g., verify it against a hash value of the code signed by the
developer of the code


TPM
-
based platform guarantees that hash value cannot be
modified


37

Satem

Network

Network

Compromise code on the disk

Disable enforcer or Satem

38

Wireless

Link Layer

Link Driver

Connection

Manager

UP

CP

Network

Services

Network

Layer

Link Driver

Connection

Manager

Authentication Only

Any traffic

UP: Uncontrolled Port

CP: Controlled Port

Dual
-
Port access control (802.1x)

39


Two
-
way
verification of commitments



Commitment
: certificate
that attests code integrity (using code
hashes)


Secure link association through encryption



All
nodes in
trusted
network share
link key

Link

Driver

Connection Manager

UP

CP

Application

Link Driver

Connection

Manager

Satem

Connection Request

Request Commitment

Commitment

Commitment,
Policy, key

Enforcer

Remote Node

Local Node

Policy

Attest


key


Problems with previous solution:


Nodes can verify their trustworthiness only at data link
layer (using 802.1x)


A node can be member in only one trusted ad hoc network
at a time


Policies associated with network layer

40


In the general framework:


Nodes can verify their trustworthiness at any layer


A node can be part of multiple trusted ad hoc networks
simultaneously


Policies can be associated with any application or protocol


N
odes
1,
4

&
6 form a trusted two
-
tier file sharing network enforcing
both
the file
sharing and routing
policies


Nodes
6,
8

&
9 form a trusted two
-
tier game network enforcing both
the game and routing
policies


Node 6 is member in two networks simultaneously


Node 7 is used for routing by nodes 1, 4 & 6


Node 5 doesn’t have trusted agent
-
> can’t join any trusted network


Node 2 doesn’t enforce routing policy
-
> can’t be used by applications
that require trusted routing


41


T
ier
manager is an application that
allows nodes to create
,
join, and merge into a
tier


A

node
may join
multiple tiers, and thereby, run multiple
enforcers


T
ier
manager and
enforcer(s)
must
be trusted


C
ode
base of the
tier manager defined in system commitment


C
ode
base
of each enforcer defined
in
service commitment


Satem

enforces these commitments


42


Hardware: laptops with built
-
in TPM


Satem
:
p
atched
Linux kernel

▪
do_execve
,
do_mmap
,
sys_init_module
,
sys_open
,
etc


Enforcers:


Linux
netfilter


Modified application source code


C
onnection manager (link layer architecture):


Modified
xsupplicant
,

an
open source 802.1x
client


Modified
hostapd
,

an
open source 802.1x
server

43


Location Privacy

1.
http://www.winlab.rutgers.edu/~
gruteser/papers/gruteser_anonym
ous_lbs.pdf

2.
http://www.winlab.rutgers.edu/~
gruteser/papers/ccs308
-
baik.pdf

3.
http://
synrg.ee.duke.edu/papers/cachecloak.pdf

4.
http
://people.cs.kuleuven.be/~
bettina.berendt/teaching/Privacy11/
Geerts_hciLocationPrivacy.pptx

5.
http://gandalf.njit.edu/~sgrandhi/documents/C7.pdf


44


Location Authentication:

6.
http://cs.njit.edu/~
borcea/papers/mobiquitous10.pdf


Trusted Ad Hoc Networks

7.
http://cs.njit.edu/~
borcea/papers/ieee
-
mass07.pdf

8.
http
://
www.trustedcomputinggroup.org/resources/trusted_platfor
m_module_tpm_summary

9.
http://cs.njit.edu/~
borcea/papers/srds06.pdf

10.
http://cs.njit.edu/~
borcea/papers/ieee
-
tdsc09.pdf

45


This was my last lecture; the slides of all lectures should
be posted on the
N
II site soon:


http://www.nii.ac.jp/en/calendar/2011/0913
/



Contact information, papers, etc.:


http://www.cs.njit.edu/~borcea/



I’ll be at NII until 30 November. If you would like to talk:


S
top by my office (1415)


Email me