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)

Mécanismes de sécurité pour les systèmes collaboratifs sans autorité centrale

By Pierre-Antoine Rault

Mécanismes de sécurité pour les systèmes collaboratifs sans autorité centrale

Présentation de pistes de recherche pour l'élaboration d'un mécanisme de sécurité pour les systèmes collaboratifs sans serveur central

  • 97