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
Just Do It
Frameworks
PoC & Protocols
Back-end: Standard File
Mobile / Desktop
- Signed binaries → Tampering mitigation
- Keys on Filesystem → OS level isolation
- Controlled environment → Identified targets
- OS Anti-malware → Security delegation
What about
Progressive Web Apps?
CORS
Sandbox Network Communication
- Prevent requests from unknowns
- Prevent unauthorized access
CSP
Protect Application Integrity
- Deny unwanted document’s writes
- Declare allowed resources
- Prevent XSS injection / Data leak
SRI
Migitate Tampering
- Verify assets checksum
- Prevent MITM attack
Referrer-Policy
Protect from malicious tracking
- Sandbox app URLs
- Prevent internal URIs leaks
Keys Storage
libsodium: keys management- File API: keys storage
- Exports: encrypted content
How to protect the
Encryption Layer?
WebAssembly
- Mitigate MITM attack
(on-the-fly data access) - Tracks data extraction/sniffing
(I/O analysis)
Minimize the Mayhem
Limit the attack bias
- Data leak → Encrypted
- Priviledge escalation → Encrypted
- ID theft → ZKP (Encryption)
Thanks @vixentael for the recap
7 Questions about ZKA
1
Migrating
from an existing codebase
2
Applying ZKA
to the Big Data
3
Loss of Keys
4
Storing Metadata
on the Server
5
Server
Security Failure
6
Exporting Keys
7
Recovery
Recovery
Initialization
Client
- Derivate Recovery Password from master
- Generate Recovery Certificate
- Generate Recovery Keys-pair
- Initialize TOTP Token
- Share Private Recovery Key w/ Shamir’s Secret
Recovery Server
- Create Account (PK ID) w/ TOTP
- Encrypt/Upload Recovery Material
Recovery
Restore
Payload Server
- Get Recovery PK ID and Shamir’s Secret Part
Recovery Server
- Identify w/ PK ID and TOTP
- Get Payload
- Delete the Material
(new) Client
- Rebuild PK & Unlock w/ Recovery Password
- Extract the Payload
- Restore the Content
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
Questions?
Thank You!
https://talks.m4dz.net/zka/en/ 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