Mécanismes de sécurité pour les systèmes collaboratifs sans autorité centrale
Cas d'usage
- Droits différenciés (groupes)
- Droits multiples (consultation, édition)
- Droits dynamiques (groupes créés/administrés après initialization)
Collaboration autour d'un document
Mise en application des droits par le chiffrement
- Chiffrement de bout en bout
- Groupes cryptographiques dynamiques
- Résistance au partitionnement du réseau (membre hors-ligne)
CONSIDÉRATIONS d'éTablissement de clé cryptographique
Encryption key type
Key negociation
State changes
Deterministic key ratchet
protocols in which users can start encrypting messages to the group immediately after creating the group or receiving a group creation message, without having to wait for round-trips with other users. Such protocols necessarily use prekeys.
is there a singlekey shared by all group members, a shared key between each pair of users, etc. ?
adding users, removing users, and key refreshing. Changing keys is necessary when adding or removing users because removed users should no longer be able to decrypt messages, and added users should not be able to decrypt messages from before they were added. Key refreshing is the mechanism used to achieve post-compromise security.
forward secrecy at low cost: deterministically derive new encryption keys for each message, using a chain of key derivation function applications. After sending or receiving a message, a user can delete the corresponding key, which is only used once.
Propriétés d'Authentification des auteurs
State change malicious
user tolerance
users cannot forge message identities even temporarily. A protocol can lack this property but still authenticate authors if users validate a message’s author through a transcript consistency check after receiving the message.
Malicious user tolerance
same as above, but for the initial key negociation
Unforgeable
Message unlinkability
preserving
the protocol doesn't produce cryptographic proof that two messages were sent by the same user. A protocol partially fulfils thisproperty if some but not all messages may be cryptographically linked.
Authenticated authors
the protocol allows users to verify message authors
Propriétés dE COHÉRENCE des communications
Malicious user tolerant
Partition tolerant
Signature-free
Malicious users cannot cause any two honest users to.believe that their message sets are consistent when they are not.
Malicious delivery service
tolerant
A malicious delivery service cannot cause any two honest users to believe that their message sets are consistent when they are not.A protocol partially fulfils this property if the delivery service consists of multiple servers and transcript consistency holds so long as at least one server is honest.
Asynchronous
The protocol doesn't mandate signatures for every message, so that other forms of author authentication may be used
Intent preservation
At rest, all system must converge to the same value, with the editions of each user.
Resistant to network partitions
Consistent causal broadcast
With CRDT, this is sufficient for users to see a causaly consistent view of their collaborative work
TAXONOMIE de la collaboration
On se repose sur une catégorisation existante des usages observés pour l'écriture collaborative¹ :
- Auteur unique : une personne guide l'écriture, les autres discutent des idées
Écriture séquentielle : chaque personne écrit sa partie, le texte est mis bout à bout- Écriture par organisation horizontale : chacun "possède" une partie et un seul compile le tout
- Écriture par division stratifiée : chacun joue un rôle au sein du projet, sans forcément écrire
- Écriture réactive : tous écrivent, ajustent, corrigent et commentent et peuvent publier
¹Lowry, Paul Benjamin; Curtis, Aaron; Lowry, Michelle René, « "Building a Taxonomy and Nomenclature of Collaborative Writing to Improve Interdisciplinary Research and Practice" », The Journal of Business Communication (1973). N˚41, 2004
Propriétés dE cONTROLE de COLLABORATION
Partition tolerant
Asynchronous
Rights separation
Collaborators can work on subsets of the document
Subsets of the document can be assigned to different authors in read and/or write mode
Anonymous edits
Unauthenticated users can collaborate on subsets of the document
Roles
Assignments can be grouped into roles assignable by virtue of scoped/proxied administration rights
Scénario 2 : droits MULTIPLES
3 utilisateurs autour d'un document.
Ayant acté une hiérarchie (un administrateur A1), 2 utilisateurs jouissent de droits différents l'un de l'autre : U1/U2.
Variantes en édition :
Variantes en consultation :
S2.1 : U1 capable d'éditer le document, U2 de commenter.
S2.2 : U1 capable d'éditer une partie du document, U2 d'éditer une autre partie.
S2.3 : U1 capable d'éditer le document, U2 de commenter sans que U1 ne puisse voir les commentaires.
S2.4 : U1 capable d'éditer une partie du document, U2 d'éditer une autre partie, sans que chacun de puisse voir la partie de l'autre.
Scénario 3 : MEMBRES HORS-LIGNE
3 utilisateurs autour d'un document. 1 utilisateur externe.
Ayant acté une hiérarchie (un administrateur A1), 2 utilisateurs jouissent de droits différents l'un de l'autre : U1/U2. 1 utilisateur sans droits : E1.
Variantes en édition :
Variantes en consultation :
U1 capable d'éditer le document, délègue ce droit à U2 puis se déconnecte.
U2 de commenter sans que U1 ne puisse voir, délègue ce droit à U1 puis se déconnecte.
On ajoute dès lors aux scénarios qui suivent des variantes hors-ligne.
Scénario 4 : MEMBRES Extérieurs
2 utilisateurs autour d'un document. 1 utilisateur externe.
Ayant acté une hiérarchie (un administrateur A1), 1 utilisateur jouit de droits non-administratifs : U1. 1 utilisateur peut être ajouté : E1.
A1 ajoute E1 au groupe en présence de U1.
A1 ajoute E1 au groupe sans la présence de U1.
A1 ajoute E1 au groupe sans la présence de E1.
A1 ajoute E1 au groupe sans la présence de U1 ni E1.
A1 ajoute E1 au groupe sans la présence de U1, puis se déconnecte.
A1 ajoute E1 au groupe sans la présence de E1, puis se déconnecte.
A1 ajoute E1 au groupe sans la présence de U1 ni E1, puis se déconnecte.
Objectifs
Confidentialité vis-à-vis du réseau et du serveur
Cohérence malgré des participants malveillants
Anonymat lors de partages publics
Granularité dans l'étendue des droits d'un groupe
Non-objectifs
Tolérance au problème des généraux byzantins Majorité de participants honnêtes et EN LIGNE
Blockchain/Crypto-monnaies COMPLEXE ET PUBLIQUE , sinon nécessitant une infrastructure
Chiffrement homomorphique/opérations sur des données chiffrées PREUVES INCOMPLÈTES EN CRDT
Absence de serveur DNS, signaling IMPOSSIBLES
Gestion de multiples appareils d'un même utilisateur
Confidentialité 1-n
Les derniers protocoles d'établissement de clés de groupes permettent le broadcast contrairement à Signal :
- STR (fixe, synchrone)
- TGDH (synchrone)
- Asynchronous Ratcheting Tree
- TreeKEM
- IETF MLS
figure modifiée de Group Messaging for Secure Asynchronous Collaboration, Matthew A. Weidner
WhatsApp, Signal, etc.
ART, TreeKEM, etc.
COHÉRENCE
figure modifiée de Adapting secure group messaging for encrypted CRDTs, Martin Kleppman, 2019
Les applications web modernes traitent toute entrée utilisateur comme soupçonnable
En pair-à-pair, faire confiance à toute entrée, même d'un membre du groupe, revient à une régression de la confiance
Hash chaining
Garantie de la cohérence causale en vue d'usage de CRDT, via e.g. Causal TreeKEM¹
¹Group Messaging for Secure Asynchronous Collaboration, Matthew A. Weidner
COHÉRENCE/Anonymat
figure modifiée de Adapting secure group messaging for encrypted CRDTs, Martin Kleppman, 2019
Solution: confiance du dernier hash par signature de groupe/anonymisation¹
¹Snapdoc: Authenticated snapshots with history privacy in peer-to-peer collaborative settings, PETS 2019
L'ajout d'un nouveau collaborateur requiert l'historique complet pour vérifier la chaîne
granularité des droits
confidentialité via le chiffrement de groupe
≠
droits différenciés via des signatures de groupes
Groupe de confidentialité
Groupe de signature : admins
chargé des opérations d'autorisation : ajout/suppression de membres, publication de modifications du document
¹via Identity-Based Proxy Re-Encryption, e.g. Identity-based conditional proxy re-encryption with fine grain policy, Chunpeng et al., 2017
délégation d'une ou plusieurs opérations d'édition¹
chargé des opérations d'autorisation : ajout/suppression de membres, publication de modifications du document
Groupe de confidentialité
Groupe de signature : admins
granularité des droits, délégation
granularité des droits, délégation
délégation de l'édition d'un champ déclaré comme protégé par les administrateurs : "titre"
Groupe de confidentialité
Groupe de signature : admins
L'utilisateur bleu transmet ses modifications avec le tag "titre", vérifié cryptographiquement par son délégataire¹
La modification est acceptée par un membre du groupe administrateur, qui le signe et le renvoit comme autoritatif au sein du groupe de confidentialité
¹un membre du groupe admin en ligne, pas forcément celui ayant délégué, grace au concept d'id-based proxy signature
An ID-based proxy signature schemes without bilinear pairings, He Debiao, 2011
Notes
De
Lecture
capabilities-Based Access control
Variante : Object Capabilities, représentant les capacités comme des objects d'un language de programmation. Disambiguation.
ressources : github.com/dckc/awesome-ocap (various object capabilities info), racket-lang.org/goblins/captp.html (lists implementations)
Se reposant sur les capacités : les smart contracts ou certains systèmes de fichier distribués.
A capability is single thing that both designates a resource and authorizes some kind of access to it.
Patterns : modulation (révocation, délégation), atténuation (opérations autorisées, zone d'effet), abstraction (POLA)
Exemples d'utilisations modernes : E (langage) and CapTP its Capability Transport Protocol, OCAPub/Spritely/Gobelins, Cap’n Proto, JWT.
capabilities-Based Access control
Questions soulevées :
- qui est le Policy Decision Point ? Le Capability Generator ?
- en l'absence de base centrale des révocations, comment récupérer les révocations lors de l'ajout d'un nouveau membre ? sans donner tout l'historique des révocations (et donc des délégations) précédentes ?
ressources : github.com/dckc/awesome-ocap (various object capabilities info), racket-lang.org/goblins/captp.html (lists implementations)