How to carry out transactions with values ​​in systems built on blockchain technology without disclosing their content?

In recent years, blockchain technology has been actively developing in the world, which is a distributed architecture consisting of many equal "nodes". "Nodes", in turn, exchange information in the form of transactions containing information about both the movement of values ​​and the execution of smart contracts. At the same time, the technology itself ensures the grouping of these transactions into blocks, the development of consensus in order to include blocks in the existing sequences, the selection of the only correct block chain (blockchain) and ensuring the distribution of the correct block chain between all "nodes".



Blockchain technology makes it possible to ensure that each "node" has the correct blockchain, which can also be called distributed ledger technology.



In fact, a blockchain or block chain is a continuously updated register that stores in open form all information about transactions (movement of values ​​and operations with them) and allows you to trace the full history of the origin and transfer of values ​​between participants. Together with the presence in each "node" of the correct chain of blocks, this allows the system participants to ensure that the information contained in such a distributed ledger is invariable and transparent.



It should be borne in mind that not every participant using the functionality of the distributed ledger technology wants to advertise the composition, quality and quantity of their values, the operations carried out with them, or participants in such operations. To solve the problem of ensuring the confidentiality of this information in various systems based on distributed ledger technology, it is possible to consider the use of technology using the Zero-Knowledge Protocol.



And what about the banking sector? From the point of view of JSC “Rosselkhozbank”, the technology of distributed ledgers with the implementation of the Zero Disclosure Protocol can be useful in organizing electronic interaction between banks.



image



This solution has the following set of advantages:



  • storing information about valuables and transactions with them without disclosing the content of such information (confidentiality);
  • high speed of operations;
  • relative simplicity in the implementation of system scalability based on distributed ledger technology, depending on the needs of the participants;
  • high resiliency in the storage of information.


We propose to dwell in more detail on the solution involving the use of the Zero Disclosure Protocol, since, in our opinion, it is this key element that determines the potential of using distributed ledger technology in the banking sector.



Features of using the Zero-knowledge protocol



Zero-knowledge protocol is a strong authentication protocol. It uses a pair of public and private keys, and it is used to authenticate users without disclosing any secret information. Such protocols are applicable to ensure information security in many areas of modern information technology. In addition, there are options for using protocols with zero knowledge of secrets to build an electronic signature mechanism or to increase its cryptographic strength against attacks by malefactors.



Zero-knowledge protocols belong to public key protocols. The protocol is built around the repetition of rounds involving certain actions. In the course of its work, the round is performed in 3 steps. The first 2 steps use random values ​​as input. The party that is checked is called the "Prover" , and the party that is checked is called the "Verifier" .



Round steps:



  1. The Prover generates a one-time private key, as well as a one-time public key, which is then sent to the Prover;
  2. The verifier receives a one-time public key from the Prover and then generates a random bit, which then sends to the Prover;
  3. The prover receives a bit of information and performs calculations on it.


The Prover sends the resulting result to the Verifier for verification.



In all rounds of testing, the probability of a correct answer is 50%, that is, in each round the Prover can have knowledge of the truth with a probability of 50%.



To achieve the required accuracy, the number of such rounds should be increased, thereby reaching the necessary probability at which the Prover will be considered authorized.



The main problems when using zero-knowledge protocols are:



  1. Required public key length;
  2. Confidence that the secret has not been shared in any other way.


Let's consider the theoretical component of several protocols with zero knowledge of secrets and draw up a comparative table of their characteristics.



ZkSNARKs protocol



zkSNARKs stands for Zero Knowledge Non-Interactive Argument of Knowledge.



This is a form of cryptography that allows a person to prove that they own a particular set of data without necessarily revealing it. This system includes only two sides: conductors and verifiers. The conductor proves that a certain element, information or word exists and is correct without revealing what that element or information is. This is the meaning of zero knowledge . The process involved in proving and validating information is fast and can be validated in a fraction of a second even for programs with large amounts of data.



For the protocol to work, it must satisfy the basic requirements of zero knowledge of the secret.



For example, a smart contract has been created. The user will be able to receive payment if he takes certain actions. What if the user does not want to disclose the details because they are confidential and secret to competitors?



For this, the zkSNARKs zero knowledge protocol is used , which proves that the steps were performed according to the terms of the smart contract, without disclosing what these actions were. He can just show part of the process without showing the whole process and prove that the user is honest.



zkSNARKs consists of three algorithms: G , P and V .



Generator (C - program, λ - input, which should not be disclosed (confidential)):



(pk, vk) = G (λ, C)



Prover (x is a public input, w is a secret statement that needs to be proved, but not told):



π = P (pk, x, w) - proof prf



Verifier:



V (vk, x, π) == (∃ w stC (x, w)) - true or false



G is a key generator that accepts input λ (which should not be expanded under any circumstances) and program C. Then two public keys are generated: a validation key pk (for a proofer) and a proof key vk ( for the verifier). These keys are available to any interested party.



PIs the one who will use 3 elements as input. A validating key pk, a random input x that is publicly available, and a statement that needs to be proven, but not told what it really is. Let's call this operator "w". Algorithm P generates a proof prf such that: prf = P (pk, x, w) .



The verifier algorithm V returns a boolean variable. A boolean variable has only two options: it can be TRUE or FALSE . So, the verifier takes key, input X and proof prf as inputs, such as: V (vk, x, prf) . And then it determines if it's true or false.



It should be noted that the parameter λused in the generator sometimes makes it difficult to use zkSNARKs in real-world applications. The reason for this is that anyone who knows this parameter can generate fake evidence. Therefore, the value of λ must be kept confidential .



Thus, starting the generator must be a safe process, protected from anyone knowing or stealing the λ parameter .



ZkSTARKs protocol



There is no external trusted installation phase in zkSTARKs and the randomness used is public information. The public use of randomness is extremely important for the public to trust zero-knowledge systems, otherwise a powerful entity could exert its influence to gain settings and generate false evidence. Since there is no third-party trust configuration phase, and public verifiable randomness is used instead, zkSTARKs systems create verifiable trust.



zkSTARKs do not rely on public / private key pairs (such as ECDSA), but rely on collision-resistant hashing for interactive solutions, and a random oracle model (which is typically used in place of generic cryptographic hash functions, where strong assumptions about randomness are required to infer the oracle) for non-interactive proofs ( zknSTARKs , n = non-interactive) therefore zkSTARKs can be resistant to attacks from quantum computers.



The zkSTARKs protocol is scalable, transparent, versatile, and can be quantum robust. This builds trust in the technology as it is verifiable. There are many areas that can be improved with technologies like zkSTARKswhere trust is required and there are great incentives to cheat, for example:



  • voting systems;
  • performing computation and checking its results, such as past transactions in distributed ledgers;
  • secure verification of information, for example, to verify identity or credentials.


There are four categories related to scalability (results from zkSTARKs ).



  1. The complexity of the arithmetic circuit (in the zkSNARK and zkSTARK systems, the code for creating zk programs is written in such a way that they can be divided into circuits and then calculated - in fact, the complexity of the circuit is higher than its computational efficiency.
  2. ( zkSNARK , zkSTARKs, ).
  3. (zkSTARKs zkSNARK 10 , ).
  4. ( zkSTARKs zkSNARK, , zkSTARKs zkSNARK, ).


The zkSTARKs protocol was planned to be used in Ethereum in verifiable computing and potentially secure / anonymous transactions, as well as in Dapps where privacy is important, such as the Brave web browser, which uses the Basic Attention token.



There is a new company called StarkWare Industries that aims to solve some of the problems with the ZK-STARK (one of which is proof size) and also commercialize technology that can be used in many industries, including distributed ledger implementations.



Bulletproofs technology



ING's Distributed Ledger Development Division is experimenting with Bulletproofs, a privacy-focused technology based on modern cryptographic algorithms.



Bulletproofs is based on work by Jonathan Bootle and others in 2016 on improving the use of discrete logarithms, which underlie zero knowledge proofs. and represents a more effective form of this very proof.



Importantly, Bulletproofs has built-in support for public keys and Pedersen obligations(a cryptographic primitive that allows you to fix any selected value, keeping it hidden from others, with the ability to later reveal the fixed value). This enables us to implement range proofs on general zero knowledge principles without performing heavy machine calculations of elliptic curves.



Evidence Bulletproofs represented in a much more general way than the range proof and can be used for arbitrary statements zero knowledge. The technology is comparable in efficiency to zkSNARKs or zkSTARKs , but has built-in support for elliptic curve public keys and Pedersen obligations(therefore, as a rule, there is no need to perform elliptic curve calculations inside the tested program). Also, unlike zkSNARKs , Bulletproofs have a full 128-bit level of cryptographic strength in accordance with standard assumptions without using a "trusted installation". And, unlike zkSTARKs , they are fast enough to prove and validate sane-scale problems on conventional computing hardware.



Compared to ZKP technology , which requires more computing power, Bulletproofs technology is about 10 times faster, as it allows transactions without the exchange of payment data.



Key points for this technology (protocol):



  • Bulletproofs are based on the general principles of zero knowledge proof (as in zkSNARKs);
  • the technology can be used to extend multilateral protocols such as multisignature or zero-knowledge conditional payments;
  • Bulletproofs provides a much more efficient version of proof for a range of confidential transactions (when using batch verification, verification speed is increased by more than 23 times);
  • such range proofs can be combined within a transaction, and its size will grow logarithmically;
  • with proper aggregation like Provisions , batch verification provides over 120x the speed of previous proofs.


Comparative table of protocol characteristics



Let's compile a comparative table with the characteristics of the considered protocols with zero secret knowledge



image



conclusions



  1. zk-SNARKs and zk-STARKs have many areas of application, including for the implementation of simple electronic signatures, as well as the creation of electronic document management systems, assuming information confidentiality.
  2. In general, zero knowledge protocols are very promising and becoming more practical for use in distributed ledger technology systems. At the moment, each implementation stands out in its own way, however, they all require resources, and there is a need for effective solutions with zero knowledge range.
  3. , , , , ( , , ).


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).




All Articles