Ouvrir un Dossier Medical Partagé avec son interne, persévérer 6 minutes malgré lenteur et plantages pour finalement avoir accès à ces hiéroglyphes, et ne pas pouvoir y ajouter de données. 14 ans de développement et 500M€ pour ça, bravo @ameli_actu ! Au secours @Drmartyufml ! pic.twitter.com/cOyWLh4eBO
— Renaud MILLER (@renaudmiller) June 11, 2018
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
- Mot de passe
- Certificat intermédiaire, signé par le CER racine de l’app sur le serveur
- Deux paires de clefs : authentification (signature), donnée (chiffrement)
- Clefs publiques / hash des clefs privées envoyées sur le serveur
- 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
- Le service qui souhaite s’authentifier se présente au serveur
- Le serveur teste sa signature dans un challenge
- Le serveur produit un token unique pour le lien Client / Service
- 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
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 :
- conçoit un mot de passe symétrique en DH avec le client
- envoie un payload signé qui contient le jeton TOTP et le certificat intermédiaire
- Le client :
- vérifie le payload et le déchiffre
- vérifie le jeton TOTP
- 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
Questions?
Thank You!
https://talks.m4dz.net/zka/fr/ 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