COAST / Pierre-Antoine Rault

Audit de registres distribués pour renforcer la confiance

Contexte

  • client: une entreprise + ses employés utilisant la base de consentement F&S

Modèle de menace

  • F&S: honest but curious, résolu par E2EE
  • *Brèche/employé malveillant: malicious, résolu par audit
  • Autres clients: honest but curious, résolu par compartimentation

Désir d'une garantie au-delà des SLA/certifications

  • pour l'entreprise (vis-à-vis de F&S) : vérification du respect du protocole, de l'authenticité des clés, certificats, etc.
  • pour F&S : pas de certification mais un audit continu vérifiable par tout le monde

Audit des opérations

Pour garantir la transparence des opérations (en l'occurence : les certificats)

CONIKS applique ce modèle à la transparence des certificats

Réaction à postériori pour minimiser la latence/le blocage induit

Audit privé

Pour garantir l'auditabilité sans attiser la curiosité de tiers (autres clients, employés, etc.)

CONIKS par entreprise client, ou Trusternity/Hyperledger

Registres distribués

  • une structure de données répliquée
  • une algorithme connu pour y ajouter des données
  • une vérification des ajouts par les participants à la réplication
  • un ajout permanent pour chaque donnée : sa présence est vérifiée et inaltérable

vs

Publique

n’importe qui dans le monde peut lire et envoyer des transactions

 

sécurité reposant sur une cryptoéconomie incitant à participer à la vérification des transactions

Privé

si un tiers de confiance est possible : gouvernance simplifiée, granularité des droits, coûts réduits, rapidité, confidentialité.

 

sécurité reposant sur une approbation centralisée ou en consortium des transactions

Publique

Privé

Les deux offrent une garantie sur l’inaltérabilité du registre distribué, même lorsque certains participants sont maladroitement ou volontairement fautifs.

vs

Les deux synchronisent les données auprès de chaque participant, permettant un traitement local.

Smart contracts/chaincode

Les smart contracts sont écrits sous forme de code ajouté en tant que bloc.

Leur logique est publiquement auditable.

Quand un évènement concerné par le contrat a lieu, e.g. l'expiration d'un certificat ou l'ajout d'une nouvelle donnée au registre, son code est exécuté.

Les clients et acteurs sensibles (e.g. des régulateurs ou des responsables d'audit) ont une garantie de transparence non plus seulement des résultats d'opérations, mais de la logique qui les a créés.

Smart contracts/chaincode

Smart contracts/chaincode

Smart contracts

Autres exemples :

  • automatiser des transactions secondaires en réponse à une transaction initiale
    • NFT gérant la redistribution des droits lors des reventes
  • formaliser l'ajout de certaines données pour en automatiser l'audit de cohérence et confiance :
    • EthIKS
    • Trusternity

Audit privé des consentements

Opérer sur des données privées et déléguer l'audit à un consortium/tiers (TPA) via Hyperledger Fabric

 

Stockage sur le registre

de la preuve (signature de

l'organisation et de F&S)

 

Vérification indépendante

voire du client lui-même

Made with Slides.com