A Location Privacy Protection Framework with Mobility Using Host Identity Protocol

1. 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 MobilityUsing Host Identity Protocol

2. 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) This person in my network is probably Alice! Eve

3. 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. Alice (Mobile Node) Bob Who the hell is this??? Eve

4. Introduction • Case study: Mobile IP • Home Address is the identifier. • Care-of Address is the locator. Never knows MN’s location Always knows MN’s location Mobile Node Home Agent Correspondent Node MN’s Home Network Mobile Node Mobile Node

5. 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. Mobile Node Home Agent Correspondent Node MN’s Home Network Mobile Node Mobile Node

6. 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.

7. Overview • Related Works • HIP and BLIND • Problem Statement • What is to be solved • Our Proposal • Protocol Design • Conclusion

8. 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)

9. 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 Registration / Location Update To: HIT of B IP of RVS A B

10. Mobility in HIP (2) • MN sends UPDATE messages to CN and RVS on roaming. • Sessions in upper layers are kept UPDATE A B A UPDATE RVS

11. BLIND Framework [Ylitalo and Nikander ’06] • Complete identity protection • Only end-points can recognize the IDs in packets. • Eavesdroppers can’t identify them. A B HIT(A) HIT(B) HIT(A) HIT(B) ???

12. 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-Hellman A B HIT(A) HIT(B) HIT(A) HIT(B) BHIT(A) BHIT(B)

13. Extended Base Exchange BHIT[I] = hash(Nonce || HIT[I]) BHIT[R] = hash(Nonce || HIT[R]) Initiator Responder Determines HIT[R] by trying all own HITs. I1: BHIT[I] → BHIT[R] , Nonce Generates the Key by DH Encrypt HI[I] with the Key R1: BHIT[R] → BHIT[I] , DH[R] Generates the Key by DH Decrypt HI[I] with the Key Encrypt HI[R] with the Key I2: BHIT[I] → BHIT[R] , DH[I] , { HI[I] } R2: BHIT[R] → BHIT[I] , { HI[R] }

14. 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. Not know A’s ID Not know A’s address A FA B HIP communication

15. Our Proposal • Goal • To achieve both Mobility and Location Privacy • Approach • The protocol is based on BLIND • Good identity protection • Introduce mobility into BLIND

16. Our Proposal • To realize mobility with BLIND • Rendezvous mechanism dealing with blinded HIT • Movement transparency support

17. Blind Rendezvous • Problems are: • RVS cannot resolve blinded HIT. • Raw HITs should be concealed.

18. 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. BHIT[B]+HIT[B] RVS F BHIT[B] A B Blinded Channel

19. 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. A F B A

20. 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 THIT(A) IP(A) SPI F1 RVS A B update update F2 AHIT(A) IP(A) THIT(A)’ THIT(A)’ IP(A)’ SPI’ IP(A)’

21. Analysis • Single Points of Failure • There may be some extensions for robustness. • Forwarding Agents • Multiplexing • Rendezvous Server • DHT-based

22. 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.

23. Implementation and Evaluation • Implementation and evaluation is ongoing.

24. 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

25. Thank you!