Twitter in Disaster Mode: Security Architecture

transcript

Christian RohnerPer Gunningberg

Uppsala Universitet, Sweden

Twitter in Disaster Mode:Security Architecture

Theus HossmannDominik Schatzmann

Franck LegendrePaolo Carta

ETH Zurich, Switzerland

2hossmann@tik.ee.ethz.ch

Source: XKCD (http://xkcd.com/723/)

Source: Twitter Blog (http://blog.twitter.com/2011/06/global-pulse.html)

Network Outage in Japan

Operator # inoperative BS

NTT DoCoMo 6720

KDDI 3800

Softbank 3786

Your Smart Phone, the Emergency Kit

• Temporary GSM network• Wireless mesh network• Satellite communication

• Opportunistic Communication• DTN2• Haggle• PodNet

Deployment, configuration, etc.• Requires experts• > 1-2 days

✗• No expert skills required• Instantly ready✓

Goal: Enable disaster victims to tweet instantaneouslyGoal: Enable disaster victims to tweet instantaneously

Twimight

• Simple yet flexible• Wide spread (200M users)

• Wide spread • Developer friendly• Wide spread • Developer friendly

• Disaster Mode (user enabled with a simple settings check-box)

✓ Opportunistic Communication

✓Security

• Disaster Mode (user enabled with a simple settings check-box)

✓ Opportunistic Communication

✓Security

• Open source (Google Code)

Opportunistic Spreading of Tweets

• Bluetooth communication• Periodic Scanning (2min ± 20sec)

• Power saving heuristic• Reduced scanning interval at battery levels < 50%• No more scanning at levels below 30%

• Epidemic spreading (flooding)• Small data volumes• FIFO buffer

• Publish tweets once connectivity is restored

What about security?

• Problem: From centralized to distributed operation• Authenticity & Integrity• Confidentiality

• Goal: Achieve Twitter-equivalent security in disaster operation• Sign Tweets and Messages• Encrypt privat messages

• Our solution: The “Twimight Disaster Server”• PKI, adapted for temporarily disconnected networks

Key Idea: Prepare everything before it breaks!Key Idea: Prepare everything before it breaks!! !

The Twimight Disaster Server

Step 1: Server-side User Identification

• Client obtains OAuth tokens from Twitter• Client sends tokens (over HTTPS) to TDS• Server receives Twitter user ID using tokens

1. Oauth 2. Send tokens

3. Get user ID

Step 2: Inter-client User Identification

• Client generates Key Pair (RSA, 2048Bit)• Client sends Public Key to TDS• Server sends certificate (signed with TDS key) to client• Client signs Tweets using its Private Key• Client attaches certificates to Tweets for verification

1. Create keys

2. Send PK3. Send certificate

4. Signed Tweets

Stolen/Lost device

• Revoke key on TDS• TDS manages a revocation list (certificate’s serial number)• TDS distributes incremental list to devices

• Scalability??• Key Idea: Shored-lived certificates (days-weeks)• Transmit and store only non-outdated records

Additional benefits: Direct Messages

• Private unicast messages (Direct Messages)• Adapted to disaster opertation: Encrypt Direct

Messages• TDS maintains list of followers• TDS sends followers’ keys• Client encrypts message with Public Key

(and signs with Private Key)

Summary

• Public release (Android Market)• Bug fixes• Awareness

• Scalability! Geo-location to the rescue..• Geographically limited flooding• Smart tweet delivery

• Contact Graph based routing for Direct Messages• Interest matching for tweets

• Geographically limited key revocation

• New Twitter features (photos, lists, etc.)

What’s next?

Thank You For Installing & Using Twimight

http://code.google.com/p/twimight

Twitter in Disaster Mode: Security Architecture

Technology