Cet article est   sous licence CC BY 4.0 DEED. disponible sur arxiv   Auteurs:  (1) Ehsan Toreini, Université du Surrey, Royaume-Uni ;  (2) Maryam Mehrnezhad, Université Royal Holloway de Londres ;  (3) Aad Van Moorsel, Université de Birmingham.  Tableau des liens   Résumé et introduction   Contexte et travaux connexes   Architecture FaaS   Analyse de la mise en œuvre et des performances   Conclusion   Remerciements et références  3 Architecture FaaS  Dans cette section, nous présentons l'architecture de notre système (Fig. 1) et décrivons ses fonctionnalités. L'architecture FaaS inclut des parties prenantes dans trois rôles : A) Système ML : un système qui possède les données et l'algorithme ML, B) Service d'auditeur d'équité : un service qui calcule les performances équitables du système ML, et C) Vérificateur universel : n'importe qui qui possède l’expertise technique et la motivation nécessaires pour vérifier le processus d’audit.  3.1 Modèle de menace  La conception et la mise en œuvre de la sécurité des parties mettant en œuvre les rôles de protocole respectifs (système ML, Fairness Auditor Service et Universal Verifier) (Fig. 1) sont indépendantes les unes des autres. Les communications qui se produisent entre les rôles n'impliquent aucune confiance entre les parties ; ainsi, toutes leurs réclamations doivent être accompagnées de preuves de validation (pour lesquelles nous utiliserons ZKP). Nous supposons que le système d'audit est vulnérable à différentes attaques et n'est pas digne de confiance. Ainsi, les données stockées sur le Fairness Auditor System doivent être cryptées, infalsifiables et vérifiables à toutes les étapes. De plus, nous supposons que le canal de communication entre le système ML et l’auditeur d’équité n’est pas protégé. Par conséquent, les données sensibles doivent être cryptées avant le début de la transmission. Toutefois, il y aura un accord sur les primitives cryptographiques au stade du préréglage de la séquence protocolaire.  Dans FaaS, nous supposons que le système ML est honnête dans l'envoi des cryptogrammes des étiquettes originales des échantillons de l'ensemble de données. On pourrait s’opposer à une telle hypothèse et discuter du fait que le système ML pourrait avoir l’intention de tromper le service d’audit, et par extension les vérificateurs, en modifiant les étiquettes réelles de l’ensemble de données. Par exemple, le système ML fournirait les cryptogrammes des étiquettes réelles et celles prévues aussi similaires que possible afin que l'auditeur conclue que les algorithmes sont équitables. Il s’agit d’un domaine intéressant pour des recherches plus approfondies. Par exemple, il peut être résolu en fournissant les cryptogrammes des étiquettes réelles au service d'audit de manière indépendante, par exemple le vérificateur peut posséder un ensemble de données qu'il fournit à un système ML. Le vérificateur décide ensuite séparément des valeurs souhaitées pour les étiquettes réelles et les transmet au service Auditeur. De cette manière, le système ML comprend beaucoup moins clairement comment manipuler les données qu’il envoie à l’auditeur, puisque certaines étiquettes proviennent d’ailleurs.  La sécurité interne des rôles va au-delà du FaaS. Le système ML lui-même doit envisager des mesures supplémentaires pour protéger ses données et ses algorithmes. Nous supposons que le système ML présente les données et les prédictions de manière honnête. Il s’agit d’une hypothèse raisonnable puisque les incitations à agir de manière éthique contrastent avec la malhonnêteté lors de la participation à un processus de contrôle d’équité. Ceci est discuté davantage dans la section Discussion.  Tableau 2 : Permutations possibles de la représentation 3 bits d'une entrée dans les données d'origine.  3.2 Aperçu du protocole  La principale séquence de protocole de sécurité se situe entre le système ML et le Fairness Auditing Service ou l'auditeur en abrégé. Notez que bien que nous suggérions trois rôles dans notre architecture, les communications se font principalement entre les deux rôles ci-dessus, et tout vérificateur universel peut se tourner vers le service d'audit (qui représente le comité d'équité), s'il souhaite contester les calculs.  Le système ML est responsable de la mise en œuvre et de l'exécution de l'algorithme ML. Il contient des données en entrée et effectue des prédictions (en fonction du cas d'utilisation et de l'objectif) qui constituent la sortie (Fig. 1). Le service d'auditeur d'équité reçoit des informations du système ML et évalue ses performances en matière d'équité en calculant une mesure d'équité. Ensuite, il renvoie le résultat de la métrique au système ML. Il publie également les calculs dans un comité d'équité pour vérification publique. Le conseil d'équité publique est un conseil d'équité accessible au public et en lecture seule (par exemple un site Web). L'auditeur a uniquement le droit de joindre des données (et des preuves suffisantes) au comité d'équité. De plus, l'auditeur vérifie l'authenticité, l'exactitude et l'intégrité des données avant de les publier.  3.3 Séquence du protocole  Ce protocole comporte trois étapes : configuration, génération de cryptogramme et calcul des métriques d'équité.  3.3.1 Phase I : configuration  Dans cette phase, le système ML et l'auditeur se mettent d'accord sur les paramètres initiaux. Nous supposons que le protocole fonctionne dans un groupe cyclique multiplicatif (c'est-à-dire un groupe de type algorithme de signature numérique (DSA) [18]), mais il peut également fonctionner dans des groupes cycliques additifs (c'est-à-dire des groupes de type algorithme de signature numérique à courbe elliptique (ECDSA) [18 ]). L'auditeur et le système ML se mettent d'accord publiquement sur (p, q, g) avant le début du protocole. Soient p et q deux grands nombres premiers où q|(p − 1). Dans un groupe cyclique multiplicatif (Z ∗ p ), Gq est un sous-groupe d'ordre premier q et g est son générateur. Par souci de simplicité, nous supposons que le problème de décision Diffie – Hellman (DDH) est hors de portée [31]. Ensuite, le système ML génère une clé de paire publique/privée à l'aide de DSA ou ECDSA et publie les clés publiques dans le tableau d'équité. La protection de la paire de clés privées dépend de l'architecture de sécurité du système ML et nous supposons que la clé privée est stockée en toute sécurité selon une pratique industrielle standard (par exemple en utilisant le module de mémoire sécurisé intégré).    après les accords initiaux, le système ML produit une table de cryptogramme avec n lignes correspondant au nombre d'échantillons dans leur ensemble de données de test. Nous appellerons cette table table de cryptogramme dans la suite de cet article. Dans le cas où le système ML ne souhaite pas révéler le nombre d'échantillons dans l'ensemble de test, l'auditeur et le système ML peuvent se mettre d'accord publiquement sur n. Dans ce cas, n doit être suffisamment grand pour que les vérificateurs universels soient satisfaits du résultat. Table de cryptogramme :  Chaque ligne du tableau des cryptogrammes résume trois paramètres : (1) le statut d'appartenance au groupe protégé, (2) son étiquette réelle et (3) l'étiquette prédite par le modèle ML. Chaque ligne contient le format crypté des trois paramètres ainsi que les preuves de son exactitude. Un tableau de cryptogramme en phase de configuration est présenté dans le tableau 3. Dans le cas le plus simple, chaque paramètre est binaire. Par conséquent, les paramètres combinés généreront huit permutations au total. Dans la phase de configuration, le tableau est généré pour contenir les huit permutations possibles et leurs preuves pour chaque échantillon de données. La structure totale des permutations est présentée dans le tableau 2. Chaque ligne satisfera quatre propriétés : (a) on peut facilement vérifier si un seul cryptogramme est la version cryptée de l'une des huit permutations possibles, (b) bien que vérifiable, ne serait-ce que un seul cryptogramme sélectionné, on ne peut pas déterminer quelles permutations le cryptogramme actuel représente, (c) pour chaque deux cryptogrammes sélectionnés dans une seule ligne, n'importe qui pourra les distinguer les uns des autres, et (d) étant donné un ensemble de cryptogrammes, sélectionner arbitrairement à partir de chaque ligne sous forme d'ensemble, on peut facilement vérifier combien de cas pour chaque « permutation » se trouvent dans l'ensemble.  La génération des fonctions de la table de cryptogramme est basée sur la séquence suivante :  Étape (1) : Pour chacun des n échantillons, le système génère une clé publique aléatoire g xi où xi est la clé privée et xi ∈ [1, q − 1].  Étape (3) : Le numéro de colonne correspondant qui est égal à la valeur décimale du codage binaire est sélectionné dans la table de cryptogramme pour compléter la table d'audit d'équité (comme indiqué dans le tableau 2).  Enfin, le tableau d'audit d'équité généré est signé numériquement par le système ML, puis envoyé via le service d'audit d'équité.  3.3.3 Phase III : Évaluation de l'équité  Tout d'abord, le service d'audit d'équité reçoit le tableau d'audit d'équité, vérifie la signature numérique et les ZKP et publie le contenu dans le comité d'équité.  À ce stade, nous développons chacune de ces composantes de l’équation pour les comparer entre elles.  Ce processus est lourd en termes de calcul, en particulier lorsque le nombre d'échantillons de données dans le tableau d'audit d'équité est important. Dans ce cas, l'auditeur d'équité peut déléguer la déclaration du numéro de permutation au système ML. L'auditeur reçoit toujours le tableau de vérification de l'équité et les ZKP correspondants. Il peut stocker le tableau d'audit d'équité dans le tableau d'équité, calculer l'équité et vérifier l'exactitude des nombres de permutation déclarés. Le vérificateur universel peut suivre les mêmes étapes pour vérifier les calculs des mesures d'équité via le tableau d'audit d'équité qui est accessible au public via le comité d'équité.  À la fin de cette étape, l'auditeur utilise les chiffres acquis pour calculer la mesure d'équité et publier les informations. Le nombre de chaque permutation indique les performances globales de l'algorithme ML pour chacun des groupes avec attribut protégé. Le tableau 4 montre les permutations et leur lien avec la mesure d'équité du système ML. Le tableau des cryptogrammes et les résultats seront publiés sur le fairness board (Fig. 1)

EScholar Technologies

EScholar

Cet audio est produit dans la langue originale de l'histoire !

Architecture FaaS et équité vérifiable pour les systèmes ML

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps