PPTX, PDF30 views

Secure your app user data with end-to-end encryption

The document discusses end-to-end encryption for apps and databases. It describes generating encryption keys for users, encrypting data in the app using those keys so that only intended users can decrypt it, and storing the encrypted data in a database. The document also mentions generating backup keys from a username and password to prevent key loss.

Technology◦

Secure your app user data with end-to-end encryption

1.
David Szabo –VP of Developer Platform
4.
App REST Frontend Backend Database 1.Login (OAuth) 2. Database query AuthorizeAuthorizeAuthorize if (!user.hasAccess(resource)) throw “Access denied”;
5.
Until somebody comesin a way that you don’t expect
6.
Process 1 memory Process 2 memory Process3 memoryUser mode Process 1 memory Process 2 memory Process 3 memoryKernel mode if (!user.hasAccess(resource)) throw “Access denied”;
7.
? ? ?
8.
Your end-to-end encryptedapp Only end-users can decrypt data. Your cloud doesn’t have the keys. ? ? ?? ? ? MIICSQIBADCC AkIGCSqGSIb3 DQEHA6CCAjMw ggIvAgECMYIC ADCB/QIBAqAK BAhQZz8w9dMf
9.
https + at-rest end-to-endencryption
10.
https at-reste2ee Steve Maria Mark Eiffel Crys webapi frontend database Crys
11.
Steve Mark CrysSteve Maria Mark Eiffel Crys Crys Thread123 Thread123 Thread123
15.
let’s see itin action
16.
Step 1: createkeys for your users key = virgil.generateKey() virgil.createCard(“Bob@yourapp.io”, key) Bob@yourapp.io Gru@yourapp.io Steve@yourapp.io
17.
Step 2: encryptstuff in the app. Store encrypted data in your db. encrSelfie = virgil.encrypt(selfie, [“Bob@yourapp.io”, me]) db.collection(“photos”).doc(“Selfie17”).set({encrSelfie}) Bob@yourapp.io Gru@yourapp.io Steve@yourapp.io
18.
Step 3: makesure that user keys aren’t lost // key = virgil.generateKey() key = virgil.generateBrainKey(username, password) Bob@yourapp.io Gru@yourapp.io Steve@yourapp.io

Editor's Notes

#4 Today, I’m here to announce that End-to-End Encryption is not a fad anymore: it’s here to say. It’s official. And I tell you why…
#10 We like trusting people, trusting companies But the forced trust in IT today is this interesting dynamic where the developer/service provider has to ask trust from their customers, because there isn’t any other way. And the developer/service provider isn’t able to fulfill the trust, because of the nature of today’s standard internet security: HTTPS and at-rest encryption, hasn’t changed in the last 20 years. So, it’s not about trust, but it’s about the inability to keep that promise. We’re building a world where trust doesn’t have to be asked by developers. Where developers can choose not to see their customers’ data. And when they can’t see the data, their hackers can’t see it either! That’s End-to-End Encryption: the cheapest way to be data breach-proof. The cheapest way to be HIPAA compliant. The Gordius knot of data security.
#11 In the beginning, there was nothing. Then God invented chat But chat alone was boring, so he invented the frontend server to talk to the chat app over the internet, and the database to store all chats between users And then https was invented to keep one’s chats private! But the messages terminated on the frontends, letting curious individuals peeking into their brothers’ and sisters’ messages. It was a pain and God decided to address that later. So, when data arrived to the database, the database stored it and the database file was encrypted, which God named “at-rest” encryption. But it was a fail again, as a single key encrypted the entire database and in order for that to operate, the key had to be stored somewhere where the database server could read it up. So, God concluded that it’s a joke, like when somebody stores the door key under the pot by the door!  The God took a rest and thought through all the mess he created… Data breaches all over: on frontend servers, in databases. So, the next morning when God woke up, he decided to redo this whole thing. He decided to create a key for every user. He used to encrypt the sent chat message with this key. He then kept the key on the device and transmitted the encrypted message through servers that had no idea what they transmit, they just dumbly did. Well, I’m just a messenger – they thought… and they were right! In the last day, God decided to create the sky and send all the public keys up there, so that brothers and sisters can download each others’ public keys and encrypt stuff for each other! This way, making the system perfectly end-to-end encrypted, secrets kept and sealed.
#12 Then God looked at the happy people chatting and learned that brothers and sisters like to do chats in groups and so, he introduced a dedicated key to encrypt each chat thread and encrypted this thread key with the brothers and sisters’ keys, like previously he did the chat messages. Then God realized that sometimes, people do silly things and they’ll be fired from chat threads.
#13 There’s a whole new breed of apps that are based on this new phenomena. Powering democracy, privacy Open source With contributors from all around the world
#14 Lots of chat apps, but other apps as well, such as HPI’s HealthCloud for example. GesundheitsCloud uses E2EE to protect the health records of Germany citizens shared across healthcare apps.
#15 SORAA puts intelligent sensors and CPUs into their lightbulbs to hear you, see you, learn you. They use our open source SDK to e2ee all data that this curious little bulb captures from you. They also use our SDK to protect the device’s firmware from being tampered with.

Secure your app user data with end-to-end encryption

More Related Content

What's hot

Similar to Secure your app user data with end-to-end encryption

Recently uploaded

Secure your app user data with end-to-end encryption

Editor's Notes