P2P System for Anonymous Instant Messaging

1
Introduction

• P2P System for Anonymous Instant Messaging
• Rather big project
• Will only cover big picture
• Please, interrupt and ask questions

2
Structure

• Background
• Related Work
• Design
• Implementation
• Demo and more questions

3
The Problem

• Instant Messaging is big
• Personal communication should be private
• Not happening on the internet
• There is a number of anonymizing technologies out
  there
• They all target specific protocols
• None are made to work on IM

4
Project Goals

• A P2P system for IM communication
• Provides sender and receiver anonymity
• Decentralised
• Robust and attack-resistant design
• Based on open standards

5
Anonymizing Technologies

• Anonymous publishing and retrieval
• Freenet, Publius, Free Haven
• Anonymous mail
• Remailers, MIX networks, Mixminion
• Anonymous web (HTTP)
• Crowds, Proxies, Commercial Offerings
• Anonymous TCP
• Onion Router, Tor

6
Pseudonyms

• Need a way to identify users
• Make each user generate a public/private key pair
• User publishes public key out-of-band
• The public key (its hash) is the users ID on the
  network
• Effectively random, but can be used to verify
  identity

7
IM Requirements

• Need to design infrastructure allowing
  client-to-client communication
• A client needs to maintain connection with many
  other clients
• Sends mostly short messages rapidly
• Onion routing meeting points suit well

8
Large scale design

• A network of nodes, each fairly dumb and relaying
  traffic for clients.
• Clients have reliable lists of nodes IPs and
  public keys
• Clients run application that uses this network
  for message exchange
• Clients need not be part of the network

9
Cryptographic Primitives
10
Onion Routing

• Low-latency system for anonymizing bi-directional
  TCP streams
• Proposed 1997, based on old MIX Network design
• Clients first build virtual circuits and then
  send data through them

11
Onion Routing Setup

• Circuit Setup Stage

k1
k2
X
Y
m
m
A
B
DPriy(m)
DPrix(m)
m
EPubxk1 Y EPuby(k2 B m)
12
Onion Routing Forward

• Once circuit is set up, messages can be sent in
  both directions
• Forward

k1
k2
X
Y
m
m
k1, k2
Dk1(m)
A
Dk2(m)
B
m
m
Ek1Ek2(m)
13
Onion Routing Backwards

• Incoming outgoing paths are remembered, so
  messages can go back
• Backwards

k1
k2
X
Y
m
m
k1, k2
Ek2(m)
Ek1(m)
A
B
m
m
Dk2Dk1(m)
14
In-Depth

• In our design, more complicated
• Use Diffie-Hellman key exchange for perfect
  forward secrecy
• Very vulnerable to DoS attacks
• Use Hashcash to make them unfeasible
• Public key crypto used throughout to verify peers
  identities

15
Leaky Circuits

• Can send data to and from any node in the circuit

k1
k3
k2
X
Z
Y
m
m
A
Ek1m
Ek2m
B
m
m
Ek1Ek2(m)
16
Circuit Topology

• Traditionally circuits were long chains
• Each link introduces a delay
• Long chains are slow and provide an avenue for
  attacks
• Use tree topology instead
• Need to carefully chose encryption mode in this
  case
• Data can leave through any node

17
Circuit Trees

• Traditionally
• Our design

A
B
A
B
18
Meeting Points

• Such design is good for client-server pattern
• To do client-client, need to introduce meeting
  points (rendezvous points)
• Meeting points are bound on a network node
• Identified by the node and point ID
• Point ID is a public key

19
Meeting Points 2

• Alice picks network node n and key pair kPub and
  kPri
• Tells Bob shes available at bind point
• (n, H (kpub))
• Connects to n and binds to k
• Signs bind request with kPri to prove she is
  worthy
• Bob connects to n and sends data, which gets
  forwarded to Alice
• Alice responds

20
In action

n
k
m
A
B
m
m
Econn, H(kpub), data
Ebind, kpub, Ekpri(n, H(kpub)
21
Dummy Traffic

• Each message passes through all nodes
• Only one node sees the plaintext
• Take it a bit further
• Each message passes through all nodes and all
  connected circuits

C
kc
kb
A
B
22
The result

• Have a system for P2P anonymous communication
• Node directory is missing
• Very hard problem. Future work.
• Resolving clients meeting points
• Can be done with a DHT.
• Running an IM protocol on top of this is
  comparatively easy

23
IM Design

• Client maintains a list of its buddies (their
  IDs)
• Always binds to her own meeting point
• Attempts to contact all buddies through their
  meeting points
• Exchanges messages and presence through the
  points
• Maintains for when they go down

24
Instant Messaging

• Use XMPP (Jabber) an Internet Standard
• Streaming XML protocol. Nice to work with.
• Can simply send chunks of XML to buddies.
• Dont want to do any GUI coding.
• Make the client application speak XMPP, and use
  Jabber messenger to as a GUI

Client PC
Jabber GUI
C
XMPP Protocol
Onion Route
25
Implementation

• Implemented all this from scratch, in Java
• Fairly clean and structured great for future
  work
• Used JCE with BouncyCastle algorithm
  implementations (free from US export
  restrictions)
• Built with RSA, Diffie-Hellman, AES and SHA-256.
  SSL for underlying TCP links.

26
Future Work

• Clients need lists of nodes
• Very hard, must be trusted without trust
• Lookup for clients meeting point data
• Should be fairly easy to do with a DHT
• More formal research of properties and attack
  resistance
• Code robustness

27
Demo

• Blah. Picture.