Décrire un exemple d'obscurcissement indiscernable ou de chiffrement fonctionnel

Question

Comme décrit dans Perfecting the Art of Sensible Nonsense , une percée majeure dans la recherche en cryptographie a été publiée à l'été 2013:

Obscurcissement indiscernable candidat et cryptage fonctionnel pour tous les circuits

En principe, il semble permettre ce que la plupart des informaticiens avaient supposé impossible: brouiller le code informatique afin que les secrets qu'il contient soient préservés même par des attaquants qui peuvent exécuter le code entièrement sous leur propre contrôle. Ce type d'obscurcissement est extrêmement puissant et peut être utilisé, par exemple, pour créer de nouvelles formes de chiffrement à clé publique. Il est lié aux percées dans cryptage fonctionnel et cryptage déniable .

Il est décrit de cette façon dans l'article:

L'obfuscateur fonctionne en transformant un programme informatique en ce que Sahai appelle un "puzzle multilinéaire". Chaque morceau du programme est obscurci en mélangeant des éléments aléatoires qui sont soigneusement choisis de sorte que si vous exécutez le programme tronqué de la manière prévue, le caractère aléatoire s'annule et les morceaux s'emboîtent pour calculer la sortie correcte. Mais si vous essayez de faire autre chose avec le programme, le caractère aléatoire rend chaque pièce du puzzle sans signification.

Mais il est également décrit comme " ... loin d'être prêt pour des applications commerciales. La technique transforme des programmes courts et simples en albatros géants et peu maniables. "

Une des raisons de la lourdeur est la nécessité d'utiliser le chiffrement entièrement homomorphe (FHE), qui lui-même reste lourd comme décrit dans questions connexes ici .

Notez que cela a été discuté sur d'autres échanges de pile:

Crypto est probablement un forum plus approprié pour une discussion générale, mais de nombreuses discussions sur les aspects pratiques possibles (ou leur absence) peuvent être mieux faites ici.

Compte tenu de l'état actuel de la technique, il semble que les applications pratiques n'existent pas. Mais cette déclaration est difficile à accepter sans exemple. Voici donc une question qui devrait être pertinente ici: quelqu'un peut-il fournir un exemple concret du type de tâche utile pour laquelle l'obscurcissement par indiscernabilité ou le chiffrement fonctionnel pourrait un jour être utilisé, et décrire à quel point il est lourd à ce stade (taille, performances , etc)?

Tom Leek · Accepted Answer

Le article décrit réellement les constructions deux, la seconde utilisant la première comme outil de construction. La première construction fournit obscurcissement indiscernable tandis que la seconde est cryptage fonctionnel.

L'obscurcissement de l'indiscernabilité est une propriété plutôt ésotérique, qui est pas ce que les non-universitaires pensent quand ils entendent "obfuscation" ; la terminologie est impropre. Cette propriété signifie que si vous pouvez encoder un "traitement" comme un circuit (grosso modo un morceau de code qui peut être déroulé, sans boucle infinie), de telle sorte qu'il existe plusieurs possibles circuits distincts qui donnent les mêmes résultats, alors l'obscurcissement impossible à distinguer permet la publication d'un "circuit obscurci" de telle sorte que n'importe qui peut courir le circuit et obtenir le résultat, mais un étranger ne peut pas savoir lequel des circuits possibles a été utilisé comme une base en interne.

Ce que bon IO peut faire, en soi, n'est pas clair. Les auteurs, dans la section 1.7 de leur article, présentent encore un exemple, qui est plutôt tiré par les cheveux:

Les développeurs de logiciels voudront souvent publier une version de démonstration ou à usage restreint de leur logiciel qui limite les fonctionnalités disponibles dans une version complète. Dans certains cas, un développeur de logiciels commerciaux le fera pour démontrer son produit; dans d'autres cas, le développeur voudra créer plusieurs niveaux d'un produit avec des prix différents. Dans d'autres domaines, le logiciel peut être remis à un partenaire qui n'est que partiellement fiable et le développeur souhaite uniquement libérer les fonctionnalités nécessaires à la tâche.

Idéalement, un développeur pourrait créer une version de logiciel déclassée simplement en commençant par la version complète, puis en désactivant certaines fonctionnalités au niveau de l'interface - nécessitant un effort supplémentaire minimal. Cependant, si c'est tout ce qui est fait, il pourrait être facile pour un attaquant de contourner ces contrôles et d'accéder à la version complète ou au code derrière. L'autre alternative consiste pour une équipe de développement de logiciels à retirer soigneusement toutes les fonctionnalités inutilisées du cœur du logiciel. La suppression de fonctionnalités peut devenir une tâche très longue qui pourrait elle-même conduire à l'introduction de bogues logiciels. De plus, dans de nombreuses applications, il peut être difficile de savoir ce qui peut ou ne peut pas rester pour une version à usage restreint.

Une solution immédiate consiste pour un développeur à restreindre l'utilisation au niveau de l'interface, puis à publier une version obscurcie du programme. Pour cette application, l’obscurcissement par indiscernabilité suffit, car par définition, une version restreinte dans l’interface ne peut pas être distinguée d’un programme obscurci avec un comportement équivalent dont les propriétés sont supprimées au début.

Le cas d'utilisation est au mieux douteux. Cependant, IO a une fonctionnalité (théorique) plus utile, que les auteurs exposent par la suite: elle leur permet de construire le cryptage fonctionnel.

Le chiffrement fonctionnel consiste à fournir un circuit calculable (obscurci avec IO) qui reçoit en entrée des versions chiffrées d'une certaine valeur x et renvoie F (x) pour une fonction [~ # ~] f [~ # ~], sans rien révéler d'autre sur x . Les auteurs montrent comment ils peuvent le faire pour any function [~ # ~] f [~ # ~] qui peut être encodé comme un circuit, et le le circuit obscurci résultant est de "taille polynomiale" par rapport au circuit original non obscurci mettant en œuvre [~ # ~] f [~ # ~].

Or, cette expression de "taille polynomiale" nous dit que nous sommes dans le monde abstrait des mathématiques, et non dans le monde pratique. Elle concerne le comportement asymptotique lorsque la taille du circuit croît vers l'infini. Elle ne dit pas grand-chose sur le coût de la construction dans une situation pratique et limitée; seulement que si Dieu joue avec des ordinateurs de la taille d'un univers, alors il trouvera la construction "assez efficace" à condition qu'il crée d'abord un univers suffisamment grand pour accueillir la majeure partie des ordinateurs impliqués - sans a priori mesure de la taille de cet univers pour que le résultat théorique s'applique. Empiriquement, nous constatons que la plupart des algorithmes banals que nous manipulons et qui offrent une complexité polynomiale sont "quelque peu rapides", mais c'est principalement parce que ces algorithmes sont des choses très simples; il n'y a aucune preuve ni même suggestion que la construction décrite dans l'article serait aussi "banale".

Le chiffrement fonctionnel, s'il peut fonctionner avec un processeur raisonnable et des budgets RAM, peut être utile pour la sécurité dans un certain nombre de situations. Par exemple, imaginez un jeu FPS = joueurs adverses sur des ordinateurs en réseau. Pour un rendu 3D efficace, la machine locale de chaque joueur doit connaître la carte du terrain et l'emplacement actuel de tous les objets, y compris les autres joueurs, afin qu'elle puisse décider si, du point de vue du local joueur, tout autre joueur est visible (et doit être dessiné sur l'écran) ou caché (par exemple, sournoisement posé derrière un mur, prêt à lancer une grenade à main) - mais les tricheurs trouveraient très pratique de connaître ces emplacements en temps réel . Chaque joueur est supposé avoir le contrôle complet de sa machine (il a un accès physique). Avec le chiffrement des fonctions, la machine du joueur peut calculer le rendu (c'est le [~ # ~] f [~ # ~] fonction) en fonction des emplacements envoyés par le serveur, sans obtenir les emplacements eux-mêmes.

Malheureusement , pour les applications pratiques, nous sommes loin d'avoir une solution viable. Ce qui doit être compris, c'est que dans toutes ces constructions, chaque circuit gate doit correspondre à une instance du schéma de cryptage entièrement homomorphique de Gentry, et à chaque cycle d'horloge pour le circuit obscurci, toutes les portes doivent être traitées , qu'ils soient "actifs" ou non dans le circuit (c'est en grande partie la raison pour laquelle l'obfuscation fonctionne théoriquement: elle ne révèle pas de portes actives, en les rendant toujours toutes actives). Cet article donne des résultats de performance: sur un PC assez gros, nous sommes prêts pour minutes de calcul. C'est pour chaque porte dans le circuit obscurci, et pour chaque cycle d'horloge.

Compte tenu de la configuration du cryptage fonctionnel, il y a des millions voire des milliards de portes dans le circuit envisagé: le "circuit obscurci" doit inclure le décryptage asymétrique et la validation des preuves à connaissance nulle. Alors maintenant, nous parlons d'utiliser tous les ordinateurs fonctionnant actuellement sur Terre, de collaborer tous sur le calcul, et ils pourraient faire des progrès non négligeables vers l'exécution d'une instance de chiffrement fonctionnel dans quelques siècles.

Ce ne sont que des estimations que je fais à partir de ce que j'ai vu dans les articles, mais elles devraient vous donner l'ordre de grandeur. À savoir, que la métaphore de l'albatros est très loin de la réalité; vous devriez plutôt imaginer une armée complète de vaisseaux spatiaux voués à la domination galactique. S'il vole, malgré la lourdeur bureaucratique, il aura une énorme inertie et coûtera assez cher.

Mavin · Answer

Ajouter simplement une explication plus simple de ~~Cryptage fonctionnel~~ Cryptage entièrement homomorphe avant de passer au cryptage fonctionnel et à l'obscurcissement de l'indiscernabilité car il est plus facile de l'expliquer de cette façon. Tiré principalement de http://crypto.stanford.edu/craig/easy-fhe.pdf Ce qui précède est un article de Craig Gentry (l'un des pionniers dans ce domaine), et il donne une très facile à suivre l'exemple d'Alice avec quelques mathématiques.

Cryptage entièrement homomorphe

Exclure les mathématiques ~~Cryptage fonctionnel~~ Le chiffrement entièrement homomorphe est quelque chose comme ceci:

Disons qu'il existe des données non chiffrées - UD. Il existe un cryptage des données non cryptées appelé données cryptées - ED. Nous effectuons des analyses/manipulations (appelons l'analyse une fonction F) sur UD pour obtenir une sortie non chiffrée - UO.

La question posée/répondue par le chiffrement fonctionnel est - Peut-on exécuter la fonction d'analyse/manipulation F, sur les données chiffrées ED, et obtenir une sortie chiffrée correspondante - EO, TEL QUE si l'on déchiffre EO, on peut obtenir la sortie non chiffrée définie ci-dessus - UO?

Un diagramme simple (le processus 1 devrait donner la même sortie que le processus 2):

UD de données non cryptées -> passé par une fonction d'analyse F -> donne une UO de sortie non cryptée.
a) UD de données non cryptées -> algorithme de cryptage -> ED de données cryptées [Ce processus est dans un environnement de confiance]

b) Transférez ED n'importe où. -> Effectuer la fonction d'analyse F sur ED -> Obtenir EO (sortie cryptée). [Peut être effectué n'importe où, y compris dans un environnement non fiable, par exemple le cloud]

c) Obtenez EO. -> algorithme de décryptage -> Obtenir UO (sortie non cryptée) [Sur un environnement de confiance]

Un schéma de travail au niveau des bits doit juste prendre en charge ADD, SUBTRACT et MULTIPLY comme expliqué dans le document ci-dessus. Et si cela fonctionne au niveau du bit, il peut généralement être étendu à tous les calculs.

En tant qu'extension, compte tenu de la récursivité générale, on pourrait même chiffrer la fonction d'analyse F, de sorte que même l'analyse effectuée n'est pas connue des environnements non fiables.

Répondez au commentaire ci-dessous, car je n'ai pas assez de réputation pour commenter!

Votre question m'a frappé en écrivant la réponse ci-dessus. Peut-être que l'exemple ci-dessus est un peu trop simple et le concept un peu abstrait.

D'une manière générale, il existe une correspondance biunivoque entre le texte brut et le texte chiffré pour garantir le déchiffrement.

Disons donc que l'on voulait rechercher les données pour le texte "bleu". En continuant avec l'exemple ci-dessus, disons que le texte "bleu" est chiffré en "xChd". Ainsi, la recherche de fonctionnement sur les données chiffrées recherchera "xChd" au lieu de "bleu". En termes algorithmiques, les fonctions sont les mêmes, c'est-à-dire "rechercher du texte". Les instances individuelles de la fonction rechercheront une phrase différente, selon le contexte. Mais encore une fois, je dis que c'est trop d'une vue de haut niveau.

Au niveau du bit, on n'a que ADD (communément appelé OR), SUBTRACT (NOT et OR) et MULTIPLY (AND) - c'est comme décrit dans l'article. Sinon, au niveau des bits, nous n'avons que 3 opérations fondamentales - ET, OR et NON.

Le chiffrement typique dans le monde d'aujourd'hui implique la génération d'un flux de bits unique mais aléatoire qui est XOR avec le texte brut pour donner du texte chiffré. Dans le déchiffrement, le texte chiffré est XOR avec le chiffrement pour donner du texte brut.

Donc, ce que l'auteur (Craig) et/ou d'autres tentent de réaliser au niveau du bit est:

[ET, OU, NON ou toute combinaison de ces opérations fondamentales] sur des entrées non chiffrées donnent des sorties non chiffrées.
Est-il possible de développer un schéma de chiffrement TEL QUE [ET, OU, NON ou toute combinaison de ces opérations fondamentales] sur des entrées chiffrées donnent des sorties chiffrées qui peuvent être déchiffrées pour donner une sortie identique à la sortie non chiffrée ( s).

Dans la littérature, le cryptage entièrement homomorphe est décrit comme suit avec une fonction dite d'évaluation.

Supposons ce qui suit:

une. f est une fonction réduite à un circuit booléen C (c'est-à-dire composée uniquement de portes et de diverses entrées et sorties)

b. Paire de clés - pk est la clé publique, sk est la clé secrète

c. UI et UO sont respectivement des entrées et sorties non chiffrées

ré. EI et EO sont respectivement des entrées et des sorties chiffrées.

Ensuite, FHE (Fully Homomorphic Encryption) est décrit comme

Evaluer (pk, C, EI) nous donne EO tel que Decrypt (sk, EO) est identique au circuit C en cours sur UI.

Donc, pour répondre à votre question dans FHE, la fonction f ou le circuit C sont les mêmes, car la logique ou l'algo doit être le même. La fonction Évaluer nécessite la clé publique pour pouvoir traduire toutes les entrées/intermédiaires non chiffrés du circuit C en forme chiffrée (par exemple, si l'on voulait rechercher "bleu", la fonction f peut avoir "bleu" incorporé quelque part dans le code, mais les données chiffrées devraient être recherchées pour "xChd". Encore une fois, il s'agit d'un exemple de très haut niveau et ne correspond pas entièrement au niveau de bits, car au niveau de bits, la fonction d'évaluation doit être indépendante du circuit C. De plus, au niveau des bits, les fonctions sont définies comme ayant une seule sortie - les portes de base ET, OR et NON sont toutes une seule sortie. Les fonctions normales à multiples entrées et multiples sorties que nous parler dans les algorithmes et les programmes de langage de haut niveau sont tous construits à partir de portes de base. Ici, l'analogie de haut niveau échoue, et la clé publique est requise par la fonction Évaluer. vous envoyer des données chiffrées avec ma clé privée et da fonction et ma clé publique, FHE peut être résumé comme - Vous pouvez calculer la fonction sur mes données cryptées en utilisant ma clé publique et m'envoyer la sortie cryptée ).

Cryptage fonctionnel

Passer au chiffrement fonctionnel. FE (Functional Encryption) n'est pas défini très simplement ou clairement. En fait, il existe tout un document de recherche dédié à la formalisation d'une définition de FE - http://eprint.iacr.org/2010/543.pdf

FE ressemble à un peu de magie - un peu comme quand quelqu'un est initié au cryptage à clé publique/clé privée.

Dans FE, il existe à nouveau une clé secrète principale - msk, également appelée clé principale. Il existe une touche de fonction - fk, souvent appelée skf, clé de fonction secrète, jeton secret, clé secrète (à ne pas confondre avec la clé secrète principale). La paire msk/fk est comme une paire clé privée/publique.

Permet d'appeler une entrée non chiffrée en tant que "x". Soit toute fonction F (ou circuit de portes). Soit un cryptage de x en utilisant le msk connu sous le nom E(x) [x crypté]. Ensuite, si nous avons la clé de fonction - fk, nous pouvons calculer F(x) en utilisant uniquement E (x). Notez que la sortie F(x) n'est pas chiffrée.

Pour l'énoncer mathématiquement F(x) = Decrpyt (fk, E(x)) où E(x) est Encrypt (x, msk) pour une paire de clés msk, fk

Bien que cela puisse sembler très contre-intuitif, le problème est que la taille ou la longueur de E(x) est une fonction de la taille de la fonction F et généralement pas de mise à l'échelle linéaire. Intuitivement, on peut considérez-le comme l'algorithme ou la logique de la fonction F est mappé sur l'algorithme de décryptage. Notez également que la sortie de Decrypt (fk, E(x)) n'est pas cryptée. Par conséquent, nous avons chiffrement de l'algorithme atteint! Je peux donner à n'importe quel tiers une entrée chiffrée et une clé de fonction, et le tiers peut obtenir le résultat de l'exécution de la fonction sur des données non chiffrées. Par exemple, un filtre anti-spam peut décider si un courrier est du spam ou non , sans déchiffrer l'e-mail et sans savoir quel est mon algorithme pour décider du spam.

Dans l'exemple FHE ci-dessus, une attaque par dictionnaire peut être lancée facilement car il existe une correspondance biunivoque entre les données non cryptées et les données cryptées (il existe des schémas de cryptage qui ne génèrent pas toujours la même sortie pour la même entrée - en fait presque tous les schémas de cryptage largement utilisés ssl, ssh, etc. ne génèrent pas toujours la même sortie pour la même entrée, mais nous n'entrerons pas dans le détail ici), les mots peuvent généralement être classés par ordre d'occurrence et devinés facilement. Mais avec FE rien ne peut être deviné! Les données et l'algorithme sont sécurisés!

Le principal avantage de FE est que l'on peut générer différentes touches de fonction pour différentes fonctions. Et nous pouvons donner à différentes personnes l'accès à différentes fonctions en distribuant les touches de fonction de manière appropriée. Tout le monde n'a pas besoin de tout savoir [Bien sûr, s'ils s'entendent, alors c'est un problème]. Une sous-classe de FE est ABE (Attribute Based Encryption). ABE a d'abord été officialisé puis généralisé à FE. Dans ABE, différentes personnes ont différents niveaux d'accès à l'information. Les informations cryptées sont accessibles au public. Cependant, les informations que chaque personne peut décrypter dépendent de la clé qu'elle détient. Ainsi, lors d'un lancement complet de produit, on peut émettre des clés telles que l'ingénierie ne peut voir que les dessins, les ventes ne peuvent voir que les rendus artistiques du produit final et la description des fonctionnalités qu'il offre et la direction peut tout voir. Voir cet exemple artificiel ici - http://www.cs.uiuc.edu/class/fa07/cs498mmp/presentations/john.pdf Le plus grand avantage d'ABE est qu'il facilite la distribution et la gestion des clés par rapport à l'infrastructure à clé publique actuelle.

Une très belle introduction légèrement mathématique à la fois FHE et FE est ici http://outsourcedbits.org/2013/10/06/how-to-search-on-encrypted-data-part-1/ et ici http://outsourcedbits.org/2012/06/26/applying-fully-homomorphic-encryption-part-1/

La relation entre FE et FHE est explorée ici https://www.usukita.org/sites/default/files/func_enc.pdf

Cependant, le problème avec FE était qu'il n'était implémentable que pour quelques fonctions. Il n'a pu être implémenté pour aucune fonction générale ou arbitraire. C'est là que l'obscurcissement de l'indistinguabilité (IO) entre en jeu. L'auteur ci-dessus est incorrect au sujet de la définition de IO.

Obscurcissement impossible à distinguer

Selon l'article original ( http://www.wisdom.weizmann.ac.il/~oded/PS/obf4.pdf ) Soit deux implémentations de la même fonctionnalité F (circuit booléen) c'est-à-dire F1 et F2. Étant donné les brouillages de F1 et F2, IO est atteint s'il est impossible (il y a une probabilité de réussite négligeable) de distinguer quel est le brouillage de F1 et qui est le brouillage de F2 (quel brouillage) est le résultat de l'obscurcissement F1 et laquelle obfuscation est le résultat de l'obscurcissement F2).

Comme mentionné ci-dessus IO la seule utilisation de IO jusqu'à présent est qu'il est utilisé comme tremplin pour atteindre la FE générale complète pour n'importe quelle fonction. La FE complète était atteint d'abord ici - https://eprint.iacr.org/2013/451.pdf Il n'y a rien de tel que "use IO pour obscurcir un programme ".

Pensées finales

Jusqu'à présent, tous ces développements ne semblent pas faire beaucoup en termes d'utilisations pratiques et même dans une certaine mesure conceptuellement, en particulier en termes de protection du code et des algorithmes (par opposition aux données qui sont actuellement assez bien protégées. La violation des données se produit principalement via le code utilisé pour le calculer). Laissant de côté les énormes ressources informatiques nécessaires à leur mise en œuvre, il existe encore diverses fuites de sécurité dans les protocoles ci-dessus qui rendront difficile de déjouer un puissant adversaire. Voir http://outsourcedbits.org/2013/10/30/how-to-search-on-encrypted-data-part-3/ et http://windowsontheory.org/2014/01/14/progress-and-challenges-in-code-obfuscation-part-ii / La pointe de la sécurité dans la protection du code est probablement quelque chose qui est décrit ici http: // outsourcedbits .org/2013/12/20/comment-rechercher-sur-les-données-cryptées-partie-4-béliers-inconscients /