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,
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.
Egocentric Social Platforms Ideal for Sharing freely I am not going to be at my home which is at 14233 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
Mobile First Always on Often connected Always with you
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.
Separation of Concerns Break the system into parts Allow consumer choice for those parts Better competition, better evolution Choice must not be HARD
The Split Identity Use existing providers; already have accounts Short-term data Notification/message routing Temporary Blobs Long-term data Backup services
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
Social Primitives - Identity 1. Establish an Identity 2. Connect with Friends 3. Short Push Messaging 4. Large Pull Messaging
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
IBC to the Rescue What if the email 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
Identity-Based Cryptography Shamir invented using the email address as the public key for signatures in 1984. Encryption of a message to a person using their email address as the public key went unsolved... Boneh and Franklin accomplished this in 2001 using elliptic curve pairings (Weil).
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.
IBC: Identity Based Cryptography public parameters Verify Decrypt
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
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+
Improved Revocation IBC automatically expires keys Every message includes implicit revocation Check authorization token at start for revocation through existing mechanisms
Social Primitives - Data 1. Establish an Identity 2. Connect with Friends 3. Short Push Messaging 4. Large Pull Messaging
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
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
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
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
ESP Architecture All data are encrypted outside the mobile device
First Time Flow
Activate an Existing Identity
Contact a Friend for the 1 st Time
Responding to the 1 st Message
Evaluation
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
Message Format
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 100 100 10,000 # msgs received / sender / day 100 100 10,000 msg length 50 KBytes 4 KBytes 4KBytes
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 340 2 s / t Load cached channel key 0.58 m s * r SHA256 of message headers 0.0067 r m s SHA256 of message body 0.026 l m s AES encrypt secret block 0.78 m s * r AES encrypt message body 0.42 l m s * r
Receiving Costs r: # receivers m r : Messages received t: Expiration period (1 month) Operation CPU Time (m r ) Frequency Check user signature 590 2 s / t Decrypt channel key 522 2 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 0.0067 r m r SHA256 of message body 0.026 l m r
Cost for Network Types Simulated Network Min Latency Size Overhead (in bytes) % CPU Send % CPU Receive Facebook 360 ms 59,266 0.05% 0.7% Contextual 74 ms 5,423 0.4% 5.6% Twitter 14 s 2,589,186 1.9% 5.4%
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
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 http://mobisocial.stanford.edu/musubi