As a…
MESSAGING APP USER
I want to…
SHARE NUDES WITH MY BUD
So that…
MY SERVICE HOSTER CAN ACCESS MY PICS TOO
Fact
it’s easier to build
a complex backend stack
rather than a secured client
Sharing the Data
Our Stacks Are Huge
- Storage (DB, Object Storage, FS…)
- Messaging (ZMQ, Redis…)
- Containers (k8s, LXC…)
- Microservices
- PWA front-end
Data Is Sensitive
Question is
Who Owns Your Nudes?
Taking the Power Back
- Picking Data
Do not exposes your
whole data to everyone
Taking the Power Back
- Picking Data
- Giving Access Permissions
Only identified users and apps
are allowed to access data
Taking the Power Back
- Picking Data
- Giving Access Permissions
- Setting Expiration
Allow access for a limited
amount of time
ZKA is a development pattern which provides a way to give access to users data for third-party apps, with the guarantee that untrusted services can’t access those plain data without any permission.
ZKA: Core Concepts
Lexicon
- Data
- piece of information produced by the user
- Client
- user’s application
- Service
- third-party app that need to access the data
- Key-pair
- Cryptographic asymmetric keys (RSA / EC)
- Certificate
- Client/Service Virtual ID Card
- Server
- Distributes the data/identities
Patterns
- Zero Knowledge Proof Authentication
- End to End Encryption
- Encrypted data only
- Non-naive approach
The Encryption Layer
Setup
- Password
- Intermediate Certificate, signed with the app CER available on the server
- Two pairs : authentication (signature), data (encryption)
- Public Keys and Private Keys Hashes
are uploaded to the server - Private Keys are stored in the Client
with the Intermediate Certificate
Registering a Service
- One Intermediate Certificate per Service
- Two Keys-pairs per Service
- The signature keys-pair is used for auth
Zero Knowledge Proof Auth
The Mystery Cave
Zero Knowledge Proof
┌─────────────┐ ┌────────────┐ ┌────────────┐
│ Service │ │ Server │ │ Client │
└──────┬──────┘ └──────┬─────┘ └─────┬──────┘
│ Request new Client Token │ │
├───────────────────────────────►│ │
│ │ │
│ Return Client Token │ Register Token │
│◄───────────────────────────────┼─────────────────────────────►│
┌──────────┤ │ ├───────────┐
Sign Client Token │ │ │ │
└─────────►│ │ │ │
│ Send Signed Token │ │ │
├────────────────────────────────┼─────────────────────────────►│ │
│ │ ├───────────┤
│ │ │ Check Token and Sign
│ │ │◄──────────┘
│ │ Valid: Authorize Service │
│◄───────────────────────────────┼──────────────────────────────┤
│ │ │
│ │ Invalid: Reject Access │
│ │◄─────────────────────────────┤
Security Concerns
- No password exchanges
- Keys can be revoked using the Intermediate Certificates
End to End Encryption
Encrypt
- Client side only
- Using the recipient Service Public Key
- With a unique symmetric Key wrapping
Decrypt
- Service side
- With the Service Private Key
Security Concerns
- Each symmetric key is unique per
Blob/Service/Client - The symmetric key is
a datetime token
Non-naive approach
Document Tree Structure
Security Concerns
- Never share all the doc
- Smallest amount of Data possible
- Forbidden resources stay safe
So,
Who Protects Your Nudes?
- Hardware Manufacturers?
- Operating Systems Editors?
- Apps Developers?
- You?
We need reviews
Open source, public reviews, public authorities, independent reports…
ZKA
- Privacy-oriented pattern
- Increase client complexity
- Decrease backend complexity
- PWA compatible
- Need reviews as well
Thank You!
https://talks.m4dz.net/zka/en/short/ Available under licence CC BY-SA 4.0
Illustrations
m4dz, CC BY-SA 4.0
Interleaf images
Courtesy of Unsplash and Pexels contributors
Icons
- Layout icons are from Entypo+
- Content icons are from FontAwesome
Fonts
- Cover Title: Sinzano
- Titles: Argentoratum
- Body: Mohave
- Code: Fira Code
Tools
Powered by Reveal.js
Source code available at
https://git.madslab.net/talks