La technologie Blockchain garantit que chaque nœud dispose de la bonne blockchain, qui peut également être appelée technologie de grand livre distribué.
En fait, une blockchain ou blockchain est un registre mis à jour en permanence qui stocke sous forme ouverte toutes les informations sur les transactions (mouvement des valeurs et opérations avec elles) et vous permet de retracer l'historique complet de l'origine et le transfert des valeurs entre les participants. Associé à la présence dans chaque "nœud" de la chaîne correcte de blocs, cela permet d'assurer l'invariabilité et la transparence des informations contenues dans un tel registre distribué pour les participants du système.
Il faut garder à l'esprit que tous les participants utilisant la fonctionnalité de la technologie du grand livre distribué ne souhaitent pas annoncer la composition, la qualité et la quantité de leurs valeurs, les opérations effectuées avec eux ou les participants à de telles opérations. Pour résoudre le problème d'assurer la confidentialité de ces informations dans divers systèmes basés sur la technologie du grand livre distribué, il est possible d'envisager l'utilisation de la technologie utilisant le protocole Zero-Knowledge.
Et qu'en est-il du secteur bancaire? Du point de vue de JSC «Rosselkhozbank», la technologie des registres distribués avec la mise en œuvre du protocole de divulgation zéro peut être utile pour organiser l'interaction électronique entre les banques.
Cette solution présente les avantages suivants:
- stocker des informations sur les objets de valeur et les transactions avec eux sans divulguer le contenu de ces informations (confidentialité);
- vitesse élevée des opérations;
- simplicité relative dans la mise en œuvre de l'évolutivité du système basé sur la technologie du grand livre distribué, en fonction des besoins des participants;
- haute tolérance aux pannes lors du stockage des informations.
Nous proposons de nous attarder plus en détail sur la solution impliquant l'utilisation du Zero Disclosure Protocol, puisque, à notre avis, c'est cet élément clé qui détermine le potentiel d'utilisation de la technologie du grand livre distribué dans le secteur bancaire.
Caractéristiques de l'utilisation du protocole Zero-Knowledge
Le protocole Zero-Knowledge est un protocole d'authentification fort. Il utilise une paire de clés publiques et privées, et il est utilisé pour authentifier les utilisateurs sans divulguer aucune information secrète. Ces protocoles sont applicables pour garantir la sécurité de l'information dans de nombreux domaines de la technologie de l'information moderne. En outre, il existe des options pour utiliser des protocoles sans connaissance d'un secret pour construire un mécanisme de signature électronique ou pour augmenter sa force cryptographique contre les attaques de malfaiteurs.
Les protocoles sans connaissance font partie des protocoles à clé publique. Le protocole est construit autour de la répétition de tours impliquant certaines actions. Au cours de son travail, le tour est effectué en 3 étapes. Les 2 premières étapes utilisent des valeurs aléatoires comme entrée. La partie qui est vérifiée est appelée le "Prover" , et la partie qui est vérifiée est appelée le "Verifier" .
Étapes rondes:
- Le Prover génère une clé privée à usage unique, ainsi qu'une clé publique à usage unique, qui est ensuite envoyée au Prover;
- Le vérificateur reçoit une clé publique à usage unique du Prover et génère ensuite un bit aléatoire, qui envoie ensuite au Prover;
- Le prouveur reçoit un peu d'informations et effectue des calculs dessus.
Le prouveur envoie le résultat obtenu au vérificateur pour vérification.
Dans tous les cycles de vérification, la probabilité d'une réponse correcte est de 50%, c'est-à-dire qu'à chaque cycle, le prouveur peut avoir connaissance de la vérité avec une probabilité de 50%.
Pour atteindre la précision requise, le nombre de ces tours doit être augmenté, atteignant ainsi la probabilité nécessaire à laquelle le Prover sera considéré comme autorisé.
Les principaux problèmes lors de l'utilisation de protocoles sans connaissance sont:
- Longueur de clé publique requise;
- Confiance que le secret n'a pas été partagé d'une autre manière.
Considérons la composante théorique de plusieurs protocoles sans connaissance des secrets et dressons un tableau comparatif de leurs caractéristiques.
Protocole ZkSNARKs
zkSNARKs signifie Zero Knowledge Non-Interactive Argument of Knowledge.
Il s'agit d'une forme de cryptographie qui permet à une personne de prouver qu'elle possède un ensemble particulier de données sans nécessairement le révéler. Ce système ne comprend que deux côtés: les conducteurs et les vérificateurs. Le conducteur prouve qu'un certain élément, information ou mot existe et est correct sans révéler ce qu'est cet élément ou cette information. C'est le sens de zéro connaissance . Le processus de vérification et de validation des informations est rapide et peut être validé en une fraction de seconde, même pour les programmes contenant de grandes quantités de données.
Pour que le protocole fonctionne, il doit satisfaire aux exigences de base de zéro connaissance du secret.
Par exemple, un contrat intelligent a été créé. L'utilisateur pourra recevoir un paiement s'il entreprend certaines actions. Que faire si l'utilisateur ne souhaite pas divulguer les détails parce qu'ils sont confidentiels et secrets pour les concurrents?
Pour cela, le protocole de connaissance zéro zkSNARKs est utilisé , ce qui prouve que les étapes ont été réalisées selon les termes du contrat intelligent, sans révéler quelles étaient ces actions. Il peut simplement montrer une partie du processus sans montrer l'ensemble du processus et prouver que l'utilisateur est honnête.
zkSNARKs se compose de trois algorithmes: G , P et V .
Générateur (C - programme, λ - entrée, qui ne doit pas être divulgué (confidentiel)):
(pk, vk) = G (λ, C)
Prover (x est une entrée publique, w est une déclaration secrète qui doit être prouvée, mais pas dite):
π = P (pk, x, w) - proof prf
Verifier:
V (vk, x, π) == (∃ w stC (x, w)) - vrai ou faux
G est un générateur de clé qui accepte l'entrée λ (qui ne doit en aucun cas être étendue) et le programme C. Ensuite, deux clés publiques sont générées: une clé de validation pk (pour un vérificateur) et une clé de preuve vk ( pour le vérificateur). Ces clés sont à la disposition de toute personne intéressée.
PEst-ce celui qui utilisera 3 éléments comme entrée. Une clé de validation pk, une entrée aléatoire x qui est disponible publiquement, et une déclaration qui doit être prouvée, mais sans dire ce que c'est vraiment. Appelons cet opérateur "w". L'algorithme P génère une preuve prf telle que: prf = P (pk, x, w) .
L'algorithme du vérificateur V renvoie une variable booléenne. Une variable booléenne n'a que deux options: elle peut être TRUE ou FALSE . Ainsi, le vérificateur prend la clé, l'entrée X et la preuve prf comme entrées, telles que: V (vk, x, prf) . Et puis il détermine si c'est vrai ou faux.
Il est à noter que le paramètre λutilisé dans le générateur, il est parfois difficile d'utiliser les zkSNARK dans des applications réelles. La raison en est que quiconque connaît ce paramètre peut générer de fausses preuves. Par conséquent, la valeur de λ doit rester confidentielle .
Ainsi, le démarrage du générateur doit être un processus sûr, protégé de quiconque connaît ou vole le paramètre λ .
Protocole ZkSTARKs
Il n'y a pas de phase d'installation externe de confiance dans zkSTARKs et le caractère aléatoire utilisé est une information publique. L'utilisation publique de l'aléatoire est extrêmement importante pour que le public fasse confiance aux systèmes sans connaissance, sinon une entité puissante pourrait exercer son influence pour obtenir des paramètres et générer de fausses preuves. Puisqu'il n'y a pas de phase de configuration de confiance tierce et qu'un caractère aléatoire vérifiable public est utilisé à la place, les systèmes zkSTARKs créent une confiance vérifiable.
Les zkSTARK ne reposent pas sur des paires de clés publiques et privées (telles que ECDSA), mais reposent sur un hachage résistant aux collisions pour les solutions interactives, et un modèle oracle aléatoire (qui est généralement utilisé à la place des fonctions de hachage cryptographiques génériques, où des hypothèses fortes sur le caractère aléatoire sont nécessaires pour déduire l'oracle) pour les preuves non interactives ( zknSTARKs , n = non interactif) les zkSTARK peuvent donc être résistants aux attaques des ordinateurs quantiques.
Le protocole zkSTARKs est évolutif, transparent, polyvalent et peut être quantique robuste. Cela renforce la confiance dans la technologie car elle est vérifiable. De nombreux domaines peuvent être améliorés avec des technologies comme zkSTARKsoù la confiance est requise et où il y a de grandes incitations à tricher, par exemple:
- systèmes de vote;
- effectuer des calculs et vérifier ses résultats, tels que les transactions passées dans les grands livres distribués;
- vérification sécurisée des informations, par exemple, pour vérifier l'identité ou les informations d'identification.
Il existe quatre catégories liées à l'évolutivité (résultats de zkSTARK ).
- La complexité du circuit arithmétique (dans les systèmes zkSNARK et zkSTARK, le code de création de programmes zk est écrit de telle manière qu'ils peuvent être divisés en circuits puis calculés - en fait, la complexité du circuit est supérieure à son efficacité de calcul.
- ( zkSNARK , zkSTARKs, ).
- (zkSTARKs zkSNARK 10 , ).
- ( zkSTARKs zkSNARK, , zkSTARKs zkSNARK, ).
Le protocole zkSTARKs était prévu pour être utilisé dans Ethereum dans le calcul vérifiable et les transactions potentiellement sécurisées / anonymes, ainsi que dans les Dapps où la confidentialité est importante, comme le navigateur Web Brave utilisant le jeton Basic Attention.
Il existe une nouvelle société appelée StarkWare Industries qui vise à résoudre certains des problèmes liés au ZK-STARK (dont l'un est la taille de l'épreuve) et à commercialiser également une technologie pouvant être utilisée dans de nombreuses industries, y compris les implémentations de registres distribués.
Technologie pare-balles
La division de développement de registres distribués d'ING expérimente les Bulletproofs, une technologie axée sur la confidentialité basée sur des algorithmes cryptographiques modernes.
Bulletproofs est basé sur les travaux de Jonathan Bootle et d'autres en 2016 sur l'amélioration de l'utilisation des logarithmes discrets, qui sous-tendent les preuves de connaissance zéro. et représente une forme plus efficace de cette preuve même.
Surtout, Bulletproofs a un support intégré pour les clés publiques et les obligations Pedersen(une primitive cryptographique qui vous permet de fixer n'importe quelle valeur sélectionnée, en la gardant cachée des autres, avec la possibilité de révéler plus tard la valeur fixe). Cela nous permet de mettre en œuvre des épreuves de portée sur des principes généraux de connaissance zéro sans effectuer de calculs machine lourds de courbes elliptiques.
Preuve Bulletproofs représentée de manière beaucoup plus générale que la preuve de portée et peut être utilisée pour des déclarations arbitraires zéro connaissance. La technologie est comparable en efficacité à zkSNARKs ou zkSTARKs , mais a un support intégré pour les clés publiques de courbe elliptique et les obligations Pedersen(par conséquent, en règle générale, il n'est pas nécessaire d'effectuer des calculs de courbe elliptique dans le programme testé). De plus, contrairement aux zkSNARKs , les Bulletproof ont un niveau complet de 128 bits de force cryptographique selon les hypothèses standard sans utiliser de «configuration fiable». Et, contrairement aux zkSTARK , ils sont suffisamment rapides pour pouvoir prouver et valider des problèmes à une échelle raisonnable sur du matériel informatique conventionnel.
Par rapport à la technologie ZKP , qui nécessite plus de puissance de calcul, la technologie Bulletproofs est environ 10 fois plus rapide, car elle permet des transactions sans échange de données de paiement.
Points clés de cette technologie (protocole):
- Les épreuves à balles sont basées sur les principes généraux de la preuve de connaissance zéro (comme dans zkSNARKs);
- la technologie peut être utilisée pour étendre les protocoles multilatéraux tels que les paiements conditionnels multisignatures ou sans connaissance;
- Bulletproofs fournit une version beaucoup plus efficace de la preuve d'une gamme de transactions confidentielles (lors de l'utilisation de la vérification par lots, la vitesse de vérification est plus de 23 fois plus rapide);
- ces preuves de plage peuvent être combinées dans une transaction, et sa taille augmentera de façon logarithmique;
- avec une agrégation appropriée comme les dispositions , la vérification par lots fournit plus de 120 fois la vitesse des épreuves précédentes.
Tableau comparatif des caractéristiques du protocole
Compilons un tableau comparatif avec les caractéristiques des protocoles considérés avec zéro connaissance secrète
conclusions
- Les zk-SNARK et zk-STARK ont de nombreux domaines d'application, y compris pour la mise en œuvre de signatures électroniques simples, ainsi que pour la création de systèmes de gestion électronique de documents, en assumant la confidentialité des informations.
- Dans l'ensemble, les protocoles de connaissance zéro sont très prometteurs et deviennent plus pratiques pour une utilisation dans les systèmes de technologie de grand livre distribué. Pour le moment, chaque implémentation se distingue à sa manière, cependant, elles nécessitent toutes des ressources, et il y a un besoin de solutions efficaces avec une gamme de connaissances nulle.
- , , , , ( , , ).
1. 34.13-2018 (). . // docs.cntd.ru URL: docs.cntd.ru/document/1200161709 ( : 31.05.2020);
2. Recommendation for Key Management Part 1: General // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf ( : 11.05.2020);
3. / 12207-2010 // docs.cntd.ru/ URL: docs.cntd.ru/document/gost-r-iso-mek-12207-2010 ( : 11.05.2020);
4. Recommendation for Cryptographic Key Generation // nvlpubs.nist.gov/ URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r1.pdf ( : 11.05.2020);
5. Recommendation for Key Management Part 2 – Best Practices for Key Management Organizations // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf ( : 11.05.2020);
6. Security Requirements for Cryptographic Modules // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf ( : 11.05.2020);
7. Payment Card Industry (PCI) Data Security Standard // pcisecuritystandards.org URL: www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1589494129851 ( : 11.05.2020);
8. // intuit.ru URL: www.intuit.ru/studies/courses/553/409/info ( : 11.05.2020).
9. // cryptowiki.net/ URL: cryptowiki.net/index.php?title=____ ( : 11.05.2020);
10. Kerberos_(protocol) // en.wikipedia.org URL: en.wikipedia.org/wiki/Kerberos_(protocol) ( : 11.05.2020)
11. RFC5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile;
12. Recommendation for Key Management Part 3: Application-Specific Key Management Guidance // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf ( : 11.05.2020);
13. Blockchain reference architecture // ibm.com URL: www.ibm.com/cloud/architecture/files/blockchain-architecture-diagram.pdf ( : 24.05.2020).
14. Key management // cloud.ibm.com URL: cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-security ( : 24.05.2020);
15. , . . / . . . — : // . — 2016. — № 1 (105). — . 141-143. — URL: moluch.ru/archive/105/24663 ( : 31.05.2020).
16. CKMS – // www.cryptomathic.com URL: www.cryptomathic.com/hubfs/Documents/Product_Sheets/Cryptomathic_CKMS_-_Product_Sheet.pdf ( : 31.05.2020);
17. HSM // www.croc.ru URL: www.croc.ru/promo/insafety/design/hardware-security-module ( : 31.05.2020);
18. HSM // cbr.ru URL: cbr.ru/Content/Document/File/104755/FT_35.pdf ( : 30.05.2020);
19. AWS Key Management Service // aws.amazon.com URL: aws.amazon.com/ru/kms ( : 30.05.2020);
20. . . // zakonbase.ru URL: zakonbase.ru/content/part/1250444 ( : 31.05.2020);
21. Diffie Hellman Protocol // mathworld.wolfram.com URL: mathworld.wolfram.com/Diffie-HellmanProtocol.html ( : 31.05.2020);
22. STS Protocol // archive.dimacs.rutgers.edu URL: archive.dimacs.rutgers.edu/Workshops/Security/program2/boyd/node13.html ( : 31.05.2020);
23. The Needham-Schroeder Protocol // www.cs.utexas.edu URL: www.cs.utexas.edu/~byoung/cs361/lecture60.pdf ( : 31.05.2020);
24. Otway Rees protocol // www.lsv.fr URL: www.lsv.fr/Software/spore/otwayRees.pdf ( : 31.05.2020);
25. Payment Card Industry (PCI) PTS HSM Security Requirements // www.pcisecuritystandards.org URL: www.pcisecuritystandards.org/documents/PTS_HSM_Technical_FAQs_v3_May_2018.pdf ( : 31.05.2020);
26. zk-SNARK? // z.cash/ru URL: z.cash/ru/technology/zksnarks ( : 31.05.2020);
27. zk-SNARKs zk-STARKs? // academy.binance.com/ru URL: academy.binance.com/ru/blockchain/zk-snarks-and-zk-starks-explained ( : 31.05.2020);
28. Bulletproofs: Short Proofs for Confidential Transactions and More // web.stanford.edu URL: web.stanford.edu/~buenz/pubs/bulletproofs.pdf ( : 31.05.2020);
29. // beincrypto.ru URL: beincrypto.ru/learn/chto-takoe-tehnologiya-raspredelennogo-reestra ( : 31.05.2020);
30. 12 - // dou.ua URL: dou.ua/lenta/articles/12-konsensus-protocols ( : 31.05.2020);
31. ISO/IEC 11770-1-2017. 1 // www.egfntd.kz URL: www.egfntd.kz/rus/tv/391980.html?sw_gr=-1&sw_str=&sw_sec=24 ( : 31.05.2020);
32. Consensus algorithm // whatis.techtarget.com URL: clck.ru/Nvade ( : 31.05.2020);
33. Introduction to Zero Knowledge Proof: The protocol of next generation Blockchain // medium.com URL: medium.com/@kotsbtechcdac/introduction-to-zero-knowledge-proof-the-protocol-of-next-generation-blockchain-305b2fc7f8e5 ( : 31.05.2020).
2. Recommendation for Key Management Part 1: General // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf ( : 11.05.2020);
3. / 12207-2010 // docs.cntd.ru/ URL: docs.cntd.ru/document/gost-r-iso-mek-12207-2010 ( : 11.05.2020);
4. Recommendation for Cryptographic Key Generation // nvlpubs.nist.gov/ URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r1.pdf ( : 11.05.2020);
5. Recommendation for Key Management Part 2 – Best Practices for Key Management Organizations // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf ( : 11.05.2020);
6. Security Requirements for Cryptographic Modules // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf ( : 11.05.2020);
7. Payment Card Industry (PCI) Data Security Standard // pcisecuritystandards.org URL: www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1589494129851 ( : 11.05.2020);
8. // intuit.ru URL: www.intuit.ru/studies/courses/553/409/info ( : 11.05.2020).
9. // cryptowiki.net/ URL: cryptowiki.net/index.php?title=____ ( : 11.05.2020);
10. Kerberos_(protocol) // en.wikipedia.org URL: en.wikipedia.org/wiki/Kerberos_(protocol) ( : 11.05.2020)
11. RFC5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile;
12. Recommendation for Key Management Part 3: Application-Specific Key Management Guidance // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf ( : 11.05.2020);
13. Blockchain reference architecture // ibm.com URL: www.ibm.com/cloud/architecture/files/blockchain-architecture-diagram.pdf ( : 24.05.2020).
14. Key management // cloud.ibm.com URL: cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-security ( : 24.05.2020);
15. , . . / . . . — : // . — 2016. — № 1 (105). — . 141-143. — URL: moluch.ru/archive/105/24663 ( : 31.05.2020).
16. CKMS – // www.cryptomathic.com URL: www.cryptomathic.com/hubfs/Documents/Product_Sheets/Cryptomathic_CKMS_-_Product_Sheet.pdf ( : 31.05.2020);
17. HSM // www.croc.ru URL: www.croc.ru/promo/insafety/design/hardware-security-module ( : 31.05.2020);
18. HSM // cbr.ru URL: cbr.ru/Content/Document/File/104755/FT_35.pdf ( : 30.05.2020);
19. AWS Key Management Service // aws.amazon.com URL: aws.amazon.com/ru/kms ( : 30.05.2020);
20. . . // zakonbase.ru URL: zakonbase.ru/content/part/1250444 ( : 31.05.2020);
21. Diffie Hellman Protocol // mathworld.wolfram.com URL: mathworld.wolfram.com/Diffie-HellmanProtocol.html ( : 31.05.2020);
22. STS Protocol // archive.dimacs.rutgers.edu URL: archive.dimacs.rutgers.edu/Workshops/Security/program2/boyd/node13.html ( : 31.05.2020);
23. The Needham-Schroeder Protocol // www.cs.utexas.edu URL: www.cs.utexas.edu/~byoung/cs361/lecture60.pdf ( : 31.05.2020);
24. Otway Rees protocol // www.lsv.fr URL: www.lsv.fr/Software/spore/otwayRees.pdf ( : 31.05.2020);
25. Payment Card Industry (PCI) PTS HSM Security Requirements // www.pcisecuritystandards.org URL: www.pcisecuritystandards.org/documents/PTS_HSM_Technical_FAQs_v3_May_2018.pdf ( : 31.05.2020);
26. zk-SNARK? // z.cash/ru URL: z.cash/ru/technology/zksnarks ( : 31.05.2020);
27. zk-SNARKs zk-STARKs? // academy.binance.com/ru URL: academy.binance.com/ru/blockchain/zk-snarks-and-zk-starks-explained ( : 31.05.2020);
28. Bulletproofs: Short Proofs for Confidential Transactions and More // web.stanford.edu URL: web.stanford.edu/~buenz/pubs/bulletproofs.pdf ( : 31.05.2020);
29. // beincrypto.ru URL: beincrypto.ru/learn/chto-takoe-tehnologiya-raspredelennogo-reestra ( : 31.05.2020);
30. 12 - // dou.ua URL: dou.ua/lenta/articles/12-konsensus-protocols ( : 31.05.2020);
31. ISO/IEC 11770-1-2017. 1 // www.egfntd.kz URL: www.egfntd.kz/rus/tv/391980.html?sw_gr=-1&sw_str=&sw_sec=24 ( : 31.05.2020);
32. Consensus algorithm // whatis.techtarget.com URL: clck.ru/Nvade ( : 31.05.2020);
33. Introduction to Zero Knowledge Proof: The protocol of next generation Blockchain // medium.com URL: medium.com/@kotsbtechcdac/introduction-to-zero-knowledge-proof-the-protocol-of-next-generation-blockchain-305b2fc7f8e5 ( : 31.05.2020).