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!