Zero Knowledge Architecture

La (Web)App sécurisée est-elle possible ?

@m4d_z
alwaysdata
Le dossier médical, c'est trop bien !
Finalement, c’était juste un gros rhume

Partager :
quoi, comment, avec qui ?

La donnée est sensible

Cloud Everywhere

Qui stocke quelles informations ?

Par où passe l’information ?

On ne devrait pas penser à se protéger mais on n’a pas le choix

Reprendre le contrôle

  • Quelles informations sont partagées ?
  • Qui peut y accéder ?
  • Pendant combien de temps ?

ZKA est un design d’application qui permet de fournir des accès à la donnée personnelle pour les applications tierces, en garantissant que ces services n’auront jamais accès à des contenus en clair, sans permission.

Concevoir une
architecture « sans connaissance »

Donnée
information produite par l’utilisateur•trice
Client
app avec lequel interagit l’utilisateur•trice
Service
entité externe qui cherche à utiliser la donnée
Paire de clefs
clefs de chiffrement asymétriques (RSA / EC)
Certificat
carte d’identité virtuelle du Client / Service
Serveur
garantit les identités et passe les données

Concepts

  • Authentification à preuve nulle
  • Chiffrement bout en bout
  • Données chiffrées exclusivement
  • Approche non-naïve

Comment ça fonctionne ?

Zero Knowledge

  1. Mot de passe
  2. Certificat intermédiaire, signé par le CER racine de l’app sur le serveur
  3. Deux paires de clefs : authentification (signature), donnée (chiffrement)
  4. Clefs publiques / hash des clefs privées envoyées sur le serveur
  5. Clefs privées stockées dans le client, avec certificat intermédiaire

Authentification à
preuve nulle

La Caverne d’Ali Baba



Ceci est une caverne (vraiment)

Gestion des clefs

  • un certificat intermédiaire par Service
  • deux paires de clefs par Service
  • la paire de signature est utilisée dans un challenge d’auth

Preuve à connaissance nulle

  1. Le service qui souhaite s’authentifier se présente au serveur
  2. Le serveur teste sa signature dans un challenge
  3. Le serveur produit un token unique pour le lien Client / Service
  4. Le client s’appuie sur le token pour valider le service qui se présente

Sécurité

  • aucun échange de mot de passe
  • les clefs sont révocables via les certificats intermédiaires

Chiffrement (E2EE)

Chiffrement

  • côté client uniquement
  • avec la clef publique du service
  • avec de l’encapsulation de clef symétrique

Déchiffrement

  • dans le service
  • avec la clef privée du service

Sécurité

  • chaque clef synchrone est unique par
    blob / service / client
  • la clef synchrone est un datetime token

Approche non-naïve

Document : arborescence de données

Sécurité

  • pas de partage intégral du document
  • chaque blob est chiffré unitairement / par service / clef unique
  • la granularité est la plus fine possible
  • stockage cloud, chiffré, sans clef disponible
  • pas d’accès aux ressources interdites

Frameworks, outils, implémentation

C'est compliqué

Frameworks

Standard File !

Mobile / Desktop

  • Code compilé
  • Stockage de clefs dans le système de fichiers
  • Environnement contrôlé
  • Intrusion prévenues

Navigateur

CORS

  • protège des requêtes vers des domaines non-reconnus
  • prévient des injections depuis des ressources extérieures
  • interdit l’écriture sauvage dans le document

CSP

  • autorise explicitement les ressources
  • prévient l’injection XSS / data
  • protège l’intégrité de l’app

SRI

  • vérifie la signature des assets
  • protège du MITM
  • garantit l’intégrité des ressources exécutées

Referrer-Policy

  • évite la fuite des URI privées
  • isole les URLs de l’app
  • protège du tracking malicieux

Stockage des clefs

  • basé sur WebCrypto
  • avec File-API
  • export des clefs chiffrées / CER intermédiaires

Protéger la couche crypto ?

WebAssembly

Prévient la lecture à la volée du code exécuté et rend l’extraction de données complexe

7 questions sur l’impact de ZKA

(la 3e va vous surprendre)

1/ Migrer une base de code existante

2/ Appliquer ZKA au Big Data

3/ Perte des clefs

4/ Gestion des metadonnées sur le serveur

5/ Compromission du serveur

6/ Export des clefs

7/ Badge de récupération

À l’initialisation

  • Le badge contient :
    • un certificat sans mot de passe
    • deux paires de clefs
    • un jeton TOTP
  • La paire de chiffrement est installée dans le client lors du rattachement
  • Les données sont doublement chiffrées avec la clef public du dispositif
  • Le jeton TOTP est synchronisé sur l’app cliente

Au déchiffrrement

  • Le badge :
    1. conçoit un mot de passe symétrique en DH avec le client
    2. envoie un payload signé qui contient le jeton TOTP et le certificat intermédiaire
  • Le client :
    1. vérifie le payload et le déchiffre
    2. vérifie le jeton TOTP
    3. déchiffre les contenus avec le certificat intermédiaire

ZKA en application

Objectif : Minimiser les risques

  • fuite de données → Chiffrement
  • escalades de privilèges → Chiffrement
  • usurpation d’ID → ZKP (Chiffrement)
  • limitation de la zone d’attaque

Contextes

  • Journaux / Traces d’usages
  • Documents complexes
  • Systèmes de fichiers
  • Stockages distants

À qui choisissons-nous de faire confiance ?

  • Aux constructeurs ?
  • Aux implémenteurs ?
  • Aux éditeurs ?
  • Aux utilisateurs ?

Nous avons besoin d’auditabilité

Open source, audits publics, structures publiques, rapports autonomes…

ZKA

  • complexe et coûteux
  • compatible Web
  • solution technique
  • trou de confiance
m4dz's avatar
m4dz

Paranoïd Web Dino · Tech Evangelist

alwaysdata logo
https://www.alwaysdata.com

Questions?

Thank You!

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