Lecture 7: Privacy and Security in Mobile Computing

lowlyoutstandingMobile - Wireless

Nov 24, 2013 (3 years and 6 months ago)

68 views

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