a location privacy protection framework with mobility using host identity protocol
DESCRIPTION
Keiji Maekawa Graduate School of Informatics, Kyoto University Yasuo Okabe Academic Center for Computing and Media Studies, Kyoto University. A Location Privacy Protection Framework with Mobility Using Host Identity Protocol. Introduction. Mobility and location privacy - PowerPoint PPT PresentationTRANSCRIPT
A Location Privacy Protection Framework with
MobilityUsing Host Identity Protocol
Keiji MaekawaGraduate School of Informatics, Kyoto University
Yasuo OkabeAcademic Center for Computing and Media Studies, Kyoto
University
Introduction
Mobility and location privacy Capability of preventing others from
learning one’s location Your location might be leaked out to
others…▪ Correspondents▪ Eavesdroppers
Alice is now connecting from
that college’s network .
Alice(Mobile Node) Bob
(Correspondent Node)
Eve
This person in my network is probably Alice!
Alice(Mobile Node)
Introduction
Desired conditions Anonymity against eavesdroppers▪ They cannot identify the sender and the receiver of
packets. Both end-points can authenticate each other,
but they don’t know about exact location.This is surely from Alice, though I don’t know where she is.
Bob
EveWho the hell is
this???
Introduction Case study: Mobile IP
Home Address is the identifier. Care-of Address is the locator.
Correspondent Node
Mobile Node
Home Agent
Mobile Node
Mobile Node
MN’s Home Network
Never knows MN’s locationAlways knows MN’s
location
Introduction Case study: Mobile IP (Route
Optimization) CN, HA, and eavesdroppers on the path
can trace the MN’s location simply looking at IP headers.
Correspondent Node
Mobile Node
Home Agent
Mobile Node
Mobile Node
MN’s Home Network
Introduction
It is difficult to design a protocol so that ANY node doesn’t know the MN’s location. Including trusted nodes such as Home
Agent It’s trade-off between privacy and
performance. In some case, privacy may be more
important than performance.
Overview
Related Works HIP and BLIND
Problem Statement What is to be solved
Our Proposal Protocol Design
Conclusion
Host Identity Protocol (HIP) ID/locator separation
Host Identity is a public key pair Host Identity Tag (HIT) is the identifier▪ 128-bit hash of Host identity
Base Exchange 2 round trip key exchange Exchange public keys for authentication Establish SAs (IPsec ESP)
Mobility in HIP (1)
Rendezvous Mechanism HIT & IP address stored in a Rendezvous
Server (RVS)▪ MN’s IP address is kept up to date
The first (I1) packet is forwarded▪ Then, end-points start to communicate directly
RVS
A B
Registration / Location UpdateTo: HIT of B
IP of RVS
Mobility in HIP (2)
MN sends UPDATE messages to CN and RVS on roaming. Sessions in upper layers are kept
A B AUPDATE
RVS
UPDATE
BLIND Framework [Ylitalo and Nikander ’06]
Complete identity protection Only end-points can recognize the IDs in
packets. Eavesdroppers can’t identify them.
A BHIT(A) HIT(B)
HIT(A) HIT(B)
???
BLIND Framework
src/dst IDs are Blinded HIT with nonce N BHIT= hash(N || HIT) Nonce is randomly generated in each
session Extended Base Exchange
A variation of Diffie-HellmanA BHIT(A)
HIT(B)HIT(A) HIT(B)
BHIT(A)BHIT(B)
Extended Base Exchange
Initiator Responder
I1: BHIT[I] → BHIT[R] , Nonce
BHIT[I] = hash(Nonce || HIT[I])BHIT[R] = hash(Nonce || HIT[R])
Determines HIT[R] by trying all own
HITs.
R1: BHIT[R] → BHIT[I] , DH[R]Generates the Key by DH
Encrypt HI[I] with the Key
I2: BHIT[I] → BHIT[R] , DH[I] , { HI[I] }
R2: BHIT[R] → BHIT[I] , { HI[R] }
Generates the Key by DH
Decrypt HI[I] with the Key
Encrypt HI[R] with the Key
BLIND with Forwarding Agent Location privacy for the BLIND Forwarding Agent (FA)
SPINAT FA conceals MN’s location from CN FA doesn’t know both IDs.
A BFA
HIP communication
Not know A’s ID
Not know A’s address
Our Proposal
Goal To achieve both Mobility and Location
Privacy Approach
The protocol is based on BLIND▪ Good identity protection
Introduce mobility into BLIND
Our Proposal
To realize mobility with BLIND Rendezvous mechanism dealing with
blinded HIT Movement transparency support
Blind Rendezvous
Problems are: RVS cannot resolve blinded HIT. Raw HITs should be concealed.
Blind Rendezvous
HIP-in-HIP tunneling Establish SAs with RVS with BLIND, then
securely send a packet with raw HITs as a HIP option.
The raw HIT info is deletedat RVS on forwarding.
AB
F
RVS
Blinded Channel
BHIT[B]+HIT[B]
BHIT[B]
Movement Transparency
Mobility support by Forwarding Agents Use a temporary HIT for FA registration
Intra-FA handover MN sends update message only to FA.▪ MN is identified by the temporary HIT
This roaming is traced by FA and nodes in MN-FA.
ABF
A
Mobility Support by FA (2) Inter-FA handover
The MN registers to another FA with a new temporary HIT after roaming.
All identifiers are changed at once. There’s possibly packet loss.▪ Expects retransmission in upper layers
A
F2 AHIT(A)IP(A) THIT(A)’ IP(A)’
SPI’
B
IP(A)’
THIT(A)’
F1 THIT(A) IP(A) SPI
RVS
updateupdate
Analysis
Single Points of Failure There may be some extensions for
robustness. Forwarding Agents▪ Multiplexing
Rendezvous Server▪ DHT-based
Analysis
Collusion If CN and FA collude, MN’s ID and
location can be combined. When some incident happens,
police can inspect MN’s location.
Implementation and Evaluation Implementation and evaluation is
ongoing.
Conclusion We proposed the Mobile BLIND
Framework Achievement▪ Anonymity for eavesdroppers▪ Conceal location from correspondents▪ Movement Transparency
Extensions to BLIND▪ Blind Rendezvous Mechanism▪ Mobility support by extended Forwarding
Agents
Thank you!