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
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