ESP Egocentric Social Platform

Transcription

1 ESP Egocentric Social Platform T. J. Purtell, Ian Vo, Monica S. Lam With: Kanak Biscuitwala, Willem Bult, Dan Boneh, Ben Dodson, Steve Fan, and Frank Wang,

2 Global Social Platforms Ideal for Meeting strangers Stalking people Discovering long lost hook-ups Marketing Hosting lots of personal pictures for free Laboring in the virtual world to avoid real work EULA for most networks Provider owns everything you post.

3 Egocentric Social Platforms Ideal for Sharing freely I am not going to be at my home which is at Ridge Way for 2 weeks Maintaining boundaries Mixing Work + Friends = Work Rules Quantified Self Apps Social Finance and Health Apps Limited global internet connectivity Arab spring, natural disaster, 3 rd world

4 Mobile First Always on Often connected Always with you

5 Direct Connection DENIED! Friend is offline can t send a message. Friend is on 3G NAT doesn t work. Friend is at work firewall blocked it. The cloud and phones must BUFFER.

6 Separation of Concerns Break the system into parts Allow consumer choice for those parts Better competition, better evolution Choice must not be HARD

7 The Split Identity Use existing providers; already have accounts Short-term data Notification/message routing Temporary Blobs Long-term data Backup services

8 An OS Service Connecting people to run apps is the next evolution of smart device platforms. ESP is the backend for Musubi Social ACLs embedded with encrypted data OS (Musubi for now) handles smart messaging

9 Social Primitives - Identity 1. Establish an Identity 2. Connect with Friends 3. Short Push Messaging 4. Large Pull Messaging

10 Everything Encrypted Friends need to exchange public keys Original Musubi generated an RSA key pair on install No way to message someone unless they are already a user No way to reuse existing phone address book

11 IBC to the Rescue What if the address, Facebook ID, etc is the public key? Public key would exist before a user installs. Private key allows users to prove their identity P2P

12 Identity-Based Cryptography Shamir invented using the address as the public key for signatures in Encryption of a message to a person using their address as the public key went unsolved... Boneh and Franklin accomplished this in 2001 using elliptic curve pairings (Weil).

13 IBC: Server derives the private key The public keys are all well-known and there are public parameters for the IBC server. Any client can check a signature or encrypt a message to someone without talking to the server. To sign or decrypt a message you need the private key.

14 IBC: Identity Based Cryptography public parameters Verify Decrypt

15 IBC: Revocation Implicit time based revocation in IBC. Private key is tied to a specific time frame Stolen private key = only lose control of data sent during that time frame Lost private key = just request it again

16 Identities and Friends Solved with IBC + Mobile phone address book Can communicate P2P with trust Ideal : OAuth provider offers IBC key service Today: Stanford hosts a generic IBC for Gmail+FB+

17 Improved Revocation IBC automatically expires keys Every message includes implicit revocation Check authorization token at start for revocation through existing mechanisms

18 Social Primitives - Data 1. Establish an Identity 2. Connect with Friends 3. Short Push Messaging 4. Large Pull Messaging

19 Protecting Data Messages encrypted with AES Social ACL attached hashed identities IBC encrypted secrets Encryption enforces ACL Servers can apply it at a higher level ACL serves as routing information

20 Message Routing IP : Identity Each device has a message queue Identity is a fan out to multiple devices Frequently used groups can be fan outs Messages buffered to stable storage

21 Adapted AMQP Queue A stream of messages buffered persistently until consumed Exchange A destination for a message that rebroadcasts it to other exchanges or queues

22 Large Pull Messaging Small messages ideal for push HD quality is still needed Push a thumbnail with a pointer to a large blob of data Other devices download the full copy lazily

23 ESP Architecture All data are encrypted outside the mobile device

24 First Time Flow

25 Activate an Existing Identity

26 Contact a Friend for the 1 st Time

27 Responding to the 1 st Message

28 Evaluation

29 IBC and Mobile Device Performance An IBC operation takes a second! Use cached AES key between a pair of individuals Embedded in social ACL Protected by IBC Update the pair key when either identity expires On average 15 days

30 Message Format

31 Social Behavior Models IBC Expiration: 1 month Facebook Twitter Contextual # senders 229 friends 100 followings 20 friends # recipients 229 friends 10,000 followers 20 friends # posts / day ,000 # msgs received / sender / day ,000 msg length 50 KBytes 4 KBytes 4KBytes

32 Sending Costs r: # receivers s: # senders t: Expiration period (1 month) m s : Messages sent Operation CPU Time (m s ) Frequency Compute channel key 78 2 s / t Sign encrypted channel key s / t Load cached channel key 0.58 m s * r SHA256 of message headers r m s SHA256 of message body l m s AES encrypt secret block 0.78 m s * r AES encrypt message body 0.42 l m s * r

33 Receiving Costs r: # receivers m r : Messages received t: Expiration period (1 month) Operation CPU Time (m r ) Frequency Check user signature s / t Decrypt channel key s / t Load cached channel key 0.59 m r AES decrypt secret block 0.85 m r AES decrypt message body 0.43 l m r SHA256 of message headers r m r SHA256 of message body l m r

34 Cost for Network Types Simulated Network Min Latency Size Overhead (in bytes) % CPU Send % CPU Receive Facebook 360 ms 59, % 0.7% Contextual 74 ms 5, % 5.6% Twitter 14 s 2,589, % 5.4%

35 Future ESP messaging deployed in Musubi for Android Work on big blobs and real-time sessions is ongoing What apps need full ESP access vs. Musubi firewalled social access? Standards

36 Conclusion Attack the open SNS problem with crypto Make the services required dead simple Smarts on the devices They can handle it ESP is the basis for a compelling platform