twitter in disaster mode: security architecture
DESCRIPTION
Presented aTRANSCRIPT
Christian RohnerPer Gunningberg
Uppsala Universitet, Sweden
Twitter in Disaster Mode:Security Architecture
Theus HossmannDominik Schatzmann
Franck LegendrePaolo Carta
ETH Zurich, Switzerland
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)
• 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)
• 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