Avec cette publication, je prévois de lancer une série d'articles sur la façon dont les nouvelles technologies dans le domaine de la cybersécurité peuvent transformer l'ensemble de l'industrie informatique. Habituellement, la lutte contre les menaces se voit attribuer une fonction auxiliaire, et peu de gens pensent que dans un proche avenir, les technologies de protection peuvent changer considérablement notre vie, la rendant non seulement plus sûre, mais fondamentalement différente. Dans mes prévisions, je vais essayer de me concentrer sur la période de 5 à 30 ans. Si vous prenez plus de 30 ans, vous pouvez alors entrer complètement dans l'abstraction, et si elle est inférieure à 5, la prévision sera trop évidente. Dans la première partie, nous parlerons d'un nouveau marché du travail intellectuel, qui est pratiquement absent pour le moment, c'est le marché des algorithmes.
Chaque programmeur qui a traité des problèmes d'optimisation complexes, développé de nouvelles fonctions cryptographiques ou reçu de nouveaux résultats significatifs dans le développement ML / AI, la pensée a surgi: est-il possible de vendre des algorithmes pour lesquels une telle quantité de travail intellectuel a été dépensé, et quelque chose faire de l'argent sur eux? En règle générale, la réponse à cette question est non. Parfois, vous pouvez le vendre, mais seulement une fois et seulement à certains services spéciaux avec l'obligation de ne pas l'utiliser ailleurs. Lorsque j'étais aux études supérieures au Département d'analyse des systèmes, les étudiants diplômés locaux ont écrit de nombreux travaux intéressants et significatifs sur l'optimisation multicritères, dans lesquels ils ont réussi à améliorer les algorithmes individuels et à obtenir un résultat qui était plusieurs pour cent plus précis que celui existant. Cependant, le développement ultérieur de ces développements n'a jamais été suivi.à l'exception de la vente de R&D elle-même en tant que service.
Puis-je vendre des algorithmes?
Analysons la complexité d'une telle opération à l'aide d'un exemple distinct. Disons qu'un développeur a créé une nouvelle fonction de hachage qui résiste aux collisions. Un résultat aussi utile l'a amené à penser qu'il serait bien de vendre l'accès à la fonction de hachage. Il existe deux façons de mettre cela en œuvre:
1. Dans le cloud: pour héberger quelque part dans le cloud et fournir un service HASHaaS. Aujourd'hui, cette décision est tout aussi simple et dénuée de sens. Même si nous imaginons que la vitesse et la qualité du canal de communication sont suffisantes pour assurer le SLA requis des appels de fonction, nous aurons la difficulté d'envoyer les données elles-mêmes au cloud. Les informations que nous voulons hacher sont susceptibles d'avoir une certaine valeur pour nous. Par exemple, on peut trouver la fonction de hachage d'un document pour une certification supplémentaire avec une signature numérique électronique, ou utiliser le hachage des mots de passe des utilisateurs afin de ne pas les stocker dans la base de données. Il semble absurde d'envoyer des mots de passe en texte clair à un serveur étranger afin d'obtenir un hachage plus tard. Si vous les chiffrez pour la transmission, le serveur distant devra toujours les déchiffrer pour calculer les hachages. Donc,il recevra tous les mots de passe, tous les documents et toutes les autres données que nous voulons hacher. L'utilisation du modèle cloud s'avère non viable, sauf dans de rares cas où les informations envoyées à un serveur distant n'ont absolument aucune valeur pour nous. Mais de telles situations seront plutôt l'exception à la règle.
2. On-premise... La deuxième méthode consiste à transférer directement l'algorithme du côté du client, où il l'exécutera lui-même. Il y a plusieurs complications ici. Si nous transmettons un programme dans un langage interprété (ouvert), tel que Python, alors le client peut en faire ce qu'il veut. Il sera impossible de contrôler la copie et la modification ultérieures du code. Si nous le transmettons sous une forme compilée, alors, d'une part, ce n'est pas toujours pratique pour le client, et d'autre part, suivre la logique de l'algorithme et la multiplier ne sera pas difficile. Même si nous confondons le code à l'avance et supprimons toutes les informations de débogage, nous pouvons démonter et tracer la logique de l'algorithme, car, très probablement, la quantité de code à analyser ne sera pas trop grande. Ainsi, les deux trajectoires conduisent le programmeur à l'échec. La pensée degénérer de la propriété intellectuelle sous la forme d'algorithmes spécialisés et en tirer des revenus passifs toute ma vie - reste un rêve ... Ou pas?
La révolution de ces dernières années
Certains domaines théoriques de la cryptographie au cours des dix dernières années sont passés de constructions théoriques irréalisables à des solutions appliquées. L'un de ces domaines est le cryptage homomorphe.
L'homomorphisme du chiffrement est que les modifications apportées au texte chiffré sont similaires aux modifications apportées au texte d'origine. Disons que Enc () est une fonction de chiffrement et Dec () est un déchiffrement; alors l'homomorphisme d'addition peut être exprimé par x + y = Dec ( Enc ( x ) + Enc ( y )). De même - par multiplication: x ∙ y= Dec ( Enc ( x ) ∙ Enc ( y )). Si un chiffrement a un homomorphisme à la fois en addition et en multiplication, alors il est appelé cryptage entièrement homomorphique (FHE). Pourquoi est-ce suffisant? Parce que sur ces opérations, vous pouvez construire n'importe quel circuit logique. En particulier, NAND ( A , B ) = 1 + A ∙ B, et NAND, à son tour, est une porte universelle, c'est-à-dire qu'à travers elle, vous pouvez exprimer tout autre opérateur logique et écrire n'importe quel programme. Les premières idées sur les chiffres homomorphes sont apparues il y a longtemps - en 1976. Cependant, la première implémentation d'un tel chiffrement n'a été décrite qu'en 2009 ( Craig Gentry. Cryptage entièrement homomorphe utilisant des réseaux idéaux. Dans le 41ème Symposium ACM sur la théorie de l'informatique (STOC), 2009 ). Cette conception était si limitée dans son application pratique qu'elle nécessitait environ 30 minutes de calculs pour une opération élémentaire avec une force cryptographique suffisante de la longueur de la clé. Au cours des deux prochaines années, de nombreux circuits FHE différents sont apparus, plus adaptés à de telles mises en œuvre pratiques. Certains des plus connus sont BGV et CKKS (Z. Brakerski, C. Gentry et V. Vaikuntanathan. Cryptage entièrement homomorphe sans bootstrapping, ITCS 2012 et Cheon, Jung Hee; Kim, Andrey; Kim, Miran; Song, Yongsoo. Cryptage homomorphique pour l'arithmétique des nombres approximatifs. Progrès en cryptologie - ASIACRYPT 2017. Springer, Cham. pp. 409-437 ). Cela a été suivi par l'émergence de nombreuses implémentations et bibliothèques open source qui implémentent des chiffrements homomorphes. L'un des premiers a été IBM avec sa bibliothèque HElib (2013), puis HEAAN de l'Université nationale de Séoul (2016), PALISADE de DARPA (2017), SEAL étendu de Microsoft (2018) et de nombreuses autres implémentations, notamment accélérées par GPU, FPGA, etc.
L'exemple FHE montre comment en 10 ans le chemin a été passé d'idées théoriques abstraites à des solutions concrètes appliquées. La cryptographie homomorphe ouvre un certain nombre de nouvelles perspectives: par exemple, elle permet de travailler avec des données sans décryptage. Auparavant, pour extraire et traiter des informations d'une grande base de données cryptée, il était d'abord nécessaire de télécharger la base de données entière, de la décrypter, de la modifier aux bons endroits, puis de la crypter et de la renvoyer. Maintenant, cela peut être fait en une seule opération. Dans une base de données cryptée, nous trouvons immédiatement la cellule souhaitée et la modifions sans avoir recours au décryptage de la table entière.
Maintenant, revenant au schéma "in-cloud", nous pouvons implémenter une plate-forme de trading à distance ("marketplace") d'algorithmes, où il sera possible d'envoyer des données non ouvertes, mais cryptées. Cela rend la configuration de l'entreprise beaucoup plus réaliste. Désormais, tout accès au service n'oblige pas le client à divulguer quoi que ce soit. Nous pouvons envoyer des informations personnelles, des données volumineuses accumulées et toute autre information confidentielle cryptée et recevoir le résultat du traitement sous forme cryptée, la clé dont nous seuls disposons.
Une autre trajectoire consiste à vendre un accès sur site à l'algorithme. Ici, il convient de prêter attention à une autre découverte de la cryptographie ces dernières années. C'est ce que l'on appelle l'obscurcissement indiscernable. Pour la première fois, l'idée d'obscurcissement indiscernable a été exprimée en 2001 ( B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, SP Vadhan et K. Yang. Sur la (im) possibilité de masquer les programmes. CRYPTO, 2001, pages 1 à 18) en rapport avec la nécessité de repenser le problème d'obscurcissement formalisé, car les approches précédentes de celui-ci d'un point de vue mathématique n'étaient pas entièrement correctes et ne donnaient pas d'indicateurs mesurables de la qualité ou de la médiocrité du programme. En 2013, pratiquement la même équipe de chercheurs a proposé une solution au problème qu'ils s'étaient posé en 2001. Ils ont réussi à trouver un design qui pourrait être un candidat pour le rôle d'un tel obfuscateur ( Sanjam Garg; Craig Gentry; Shai Halevi; Mariana Raykova; Amit Sahai; Brent Waters. Candidate Indistinguishability Obfuscation and Functional Encryption for all Circuits. Focs 2013, 40-49 ). L'essence de l'obfuscation indiscernable peut être expliquée comme suit. Disons que nous avons un programme comme obf(), qui reçoit un certain code de programme en entrée, et le sort sous une forme obscurcie (confuse) en sortie. De plus, si nous avons deux programmes de fonctionnalité égale A et B , alors ayant reçu leurs variantes obfusquées obf ( A ) et obf ( B), nous, avec une précision de valeurs négligeables, ne serons pas en mesure de comprendre lequel des deux a été appliqué à l'entrée de l'obfuscateur (une approche similaire est utilisée pour formuler l'indiscernabilité des algorithmes de chiffrement). De cela découle plusieurs conclusions non évidentes, dont l'une est la capacité du programme à la sortie de l'obfuscateur à garder un "secret" en lui-même. Il peut s'agir, par exemple, d'une clé de chiffrement - elle est ensuite transmise avec le code exécutable et ne peut pas être récupérée.
Les bonus possibles liés à l'utilisation de l'obfuscation indiscernable ne se limitent pas à cela. Une autre conséquence importante de l'utilisation de code indiscernable est le manque de confiance dans le composant matériel. Tout traitement de données peut être effectué sur du matériel non fiable. En conséquence, des milliards dépensés pour le développement d'ordinateurs domestiques, ou la confrontation entre Huawei et les États-Unis, perdent leur sens s'ils sont argumentés par les exigences de confiance dans le matériel. Mais c'est déjà le sujet d'un autre article.
Dans le cas de la vente d'algorithmes, il devient possible de transférer leur code obscurci au client. Dans le même temps, même si nous mettons dans le code une certaine individualisation pour un certain utilisateur, le client ne pourra pas "extraire" cette partie personnalisée du code. En conséquence, nous rendons non seulement impossible l'analyse des principes de l'algorithme, mais nous obtenons également un moyen de fournir aux programmes une certaine étiquette indissociable de leur part, qui laissera toujours une marque numérique une fois distribués sur Internet. Cependant, il convient de noter que la mise en œuvre actuelle de l'obfuscation indiscernable est si lourde qu'il est trop tôt pour parler de son utilisation pratique. Très probablement (contrairement au cloud), nous verrons le schéma d'implémentation sur site au plus tôt dans 10 ans.
Prévisions et mises en garde
Ainsi, nous voyons qu'au cours des 5 prochaines années ou plus, le marché des algorithmes peut apparaître sous la forme de circuits cloud, et une exécution sur site plus tard est également possible. Bien sûr, cela ne se fera pas du jour au lendemain. Pour former de telles relations, il devrait encore apparaître:
- La plateforme (ou les plateformes) d'échange de données entre fournisseurs et consommateurs d'algorithmes. Ils doivent exécuter automatiquement toutes les fonctions FHE au niveau d'une certaine couche de transport. Ensuite, le service deviendra vraiment pratique et, surtout, compréhensible pour tous les acteurs du marché, car à présent peu de spécialistes en informatique savent ce qu'est FHE et comment l'utiliser.
- L'échange de Big Data est toujours entravé par la vitesse limitée des canaux de communication. Par conséquent, ici, il est nécessaire d'attendre le moment où la bande passante des canaux atteint organiquement les valeurs requises, ou de lancer des services supplémentaires pour le prétraitement des données côté client, qui peuvent faire partie des plates-formes et des cadres du paragraphe 1.
Le développement du marché des algorithmes peut avoir un impact significatif sur de nombreux secteurs de l'économie. Plusieurs domaines peuvent être identifiés qui seront certainement influencés par cette transformation.
Big Data.La configuration du marché moderne du Big Data ne comprend pas seulement les tableaux d'informations eux-mêmes, mais - plus encore - les centres d'analyse, qui sont capables d'extraire des connaissances et de construire des modèles basés sur ces informations. Chaque grand collecteur de données, tel qu'un opérateur de télécommunications, une banque ou un commerce de détail, dispose de son propre personnel d'analystes qui développent des modèles pour extraire les connaissances et vendre ces matériaux à d'autres consommateurs. Si un marché riche d'algorithmes et de modèles pour travailler avec des données est disponible gratuitement, ces unités perdront leur importance. Les accumulateurs de bigdonnées ne pourront plus ajouter de la valeur aux informations extraites des mégadonnées et seront contraints de vendre uniquement des matières «premières», dont le coût commencera également à se dévaluer avec le temps, commecomment les matières premières classiques (pétrole, gaz, aluminium, etc.) se déprécient maintenant.
Trois niveaux de développement. La dichotomie de développement classique de nos jours est «backend versus frontend». Ce dernier écrit l'interface utilisateur, le premier écrit toute la logique côté serveur de l'application. Une nouvelle couche peut être formée ici, qui peut être désignée comme "algoend". Il contiendra les algorithmes clés, les plus importants et les plus complexes (NLP, ML / AI, Data Mining, Blockchain, etc.). En d'autres termes, algoend est le contenu essentiel de tout développement, et frontend et backend sont son individualisation pour un projet spécifique. Algoend exigera un maximum de qualifications et se lancera dans le domaine des services supplémentaires, formant un nouveau marché pour les services. À leur tour, le frontend et le backend sont un marché du travail dont le coût diminuera.
Marché C2B.Déjà à partir des deux premiers points, on peut tirer une conclusion sur la transformation en cours sur le marché du travail. Le développement de nouvelles technologies dans le domaine de la cybersécurité va relancer le secteur désormais pratiquement absent du C2B. En d'autres termes, nous passons des schémas juridiques de contrôle de la propriété intellectuelle (que seules les grandes entreprises peuvent combattre pour l'instant) à des schémas technologiques que tout le monde peut utiliser. Si la propriété intellectuelle produite est indissociable du service qui l'utilise, alors il n'y a pas besoin de frais juridiques et organisationnels pour maintenir le mode de son utilisation.
Marché des services juridiques. Il est généralement admis que la transition vers l'économie de l'information crée une forte demande d'avocats chargés des brevets et des litiges juridiques. Jusqu'à un certain moment, c'était vraiment le cas. Cependant, dans 10 ans ou plus, je prédirais la mort totale de ce marché des services (du moins dans le domaine informatique). Déjà maintenant, breveter et enregistrer des algorithmes ressemble à une procédure peu pratique et vraiment protectrice, tous les développeurs sont plus enclins à laisser les développements importants comme une sorte de savoir-faire qu'à divulguer et breveter les résultats. Un autre fait important est ajouté ici - le code à la sortie d'un obfuscateur indiscernable ne peut pas faire l'objet de droits d'auteur. Cela découle de la définition même de l'obfuscation indiscernable, car il est impossible de déterminer et de prouverquel type de conception de logiciel lui a été soumis à l'entrée. Je prédis qu'il n'y aura plus de litiges juridiques dans l'industrie informatique 10 ans plus tard, du moins sous la forme que nous voyons actuellement.
Les prédictions exprimées dans cet article, bien sûr, comme toutes les autres prédictions, peuvent ne pas se réaliser. Les découvertes et les développements en R&D sont le domaine le plus ingrat pour les prévisions. Nous ne pouvons pas dire, par exemple, que les conceptions complexes actuelles de l'obscurcissement indiscernable seront améliorées et deviendront pratiques dans 5 ans. Cela peut ne pas arriver. Il serait plus juste de supposer que les prévisions elles-mêmes et les conclusions de cet article sont susceptibles de se réaliser, mais les délais sur lesquels elles sont établies comportent une incertitude beaucoup plus grande.
L'article original a été publié ici