How to achieve effective supervision through distributed key technology?

Author: Kao Cheng real

This article is the periodic work report of the "Key Steward" research group.

I. Asymmetric cryptography is the cornerstone of building blockchain applications

Asymmetric cryptography has always played a key role in information systems, and has become the basis for building many core functions of information systems.

In the blockchain system, asymmetric cryptography is used not only for user identification and verification of operation rights, but also for digital asset address generation, asset ownership identification, and digital asset circulation. As shown in Figure 1, specifically, digital signatures based on asymmetric cryptography can construct public and private key pairs to identify users; can generate encrypted asset addresses based on public keys, and verify asset ownership with public and private key pairs; private key pairs can Operation signature, using the public key to verify the user's operation authority; you can also use the receiver's public key to encrypt the transmission data, and the receiver can use the private key to decrypt and read the data.

• Detailed DCEP future use scenarios-low-cost cross-border payments
• Research | How Blockchain Solves Financing Problems
• Half a year of research and development can't beat BM's mouth? Isn't Voice worth looking forward to?

Figure 1 Application of asymmetric cryptography in a blockchain system

The "people", "finance", "rights" and "data" in the blockchain rely on asymmetric cryptography to identify, and the corresponding functions and permissions also need to rely on asymmetric cryptography to ensure and achieve, so it can be said that Asymmetric cryptography is the cornerstone of building blockchain applications and promoting their development.

Second, traditional asymmetric cryptography technology cannot effectively support distributed and decentralized systems

Distributed and decentralized trust are important characteristics of the blockchain system. These characteristics ensure that the blockchain system can reduce the threshold of trust and achieve higher system efficiency in the environment of multiple parties. However, the design and implementation of asymmetric cryptography itself is centralized, and it cannot effectively support distributed and decentralized systems.

At present, the asymmetric cryptographic algorithms used in blockchain systems use centralized algorithms for the calculation of private keys to public keys. The generation of public and private key pairs needs to be based on the complete private key, that is, between the private key and the public key. The relationship is 1 to 1, and the N to 1 relationship cannot be effectively realized. Therefore, asymmetric cryptography cannot effectively support the business collaboration of the same transaction under the participation of multiple parties, and it cannot implement native distributed management of "people", "finance", "rights" and "data" in the blockchain.

At present, distributed management of asset ownership, effective locking and custody of assets are basically implemented based on multi-signature and smart contract programming in the application layer at Level 2. Approval of operation permissions also need to be implemented through contracts. But these two methods are not supported by all blockchains, or have limited support capabilities. For example, BTC does not support smart contracts, and it only supports a maximum of 5 multi-signatures and a threshold of 3/5 on multi-signature; while ETH does not support multi-signature, it is necessary to write smart contracts to achieve similar functions. On the other hand, from the perspective of security, in addition to the implementation of the functions completed at the upper layer, in addition to considering the completeness of its own business logic, it is also necessary to consider attacks from the bottom of the system. .

Third, distributed key technology can achieve native support for distributed systems

If we transform the centralized asymmetric cryptographic algorithm into a distributed asymmetric cryptographic algorithm, which is referred to as the distributed key technology in this article, as shown in Figure 2, the existing private key generated by a user is transformed into a multi-key Each node independently generates its own private key shards, transforms the existing centralized computing process into a distributed computing process, and transforms the correspondence between a private key and a public key into a set of private key sets and a public key Key correspondence, then the original public key generation, signature, verification, and data encryption processes based on a single private key can be transformed to complete public key generation, signature, verification, and data decryption based on a set of private keys Process, asset custody, approval, etc. were originally located at Level 2, the business completed by the smart contract can be achieved by calling the underlying distributed key components located at Level 1, and the function of such distributed key components is atomic , Has the same password security strength.

Figure 2 Comparison of existing digital signature and distributed key signature processes

The distributed key technology is fundamentally different from the scheme of generating private key fragments based on secret sharing technology. The secret sharing scheme is to first generate a complete private key, and then split the private key to form a number of private key fragments and save them to multiple parties. Since the complete private key has appeared, it is difficult to ensure that the complete private key has not been leaked, either technically or administratively. In the distributed key method, each participant directly generates their own private key fragments. There is no complete private key in the entire process, and there is no passing and sharing of the private key fragments generated by the participants. There is no problem of leaking the complete private key.

FIG. 3 is a schematic diagram of comparison between data encryption and decryption using an existing asymmetric cryptographic algorithm and encryption and decryption using a distributed key algorithm. In the existing method, Bob sends Alice a secret message, and Bob uses Alice's public key PK to encrypt the information. After Alice receives it, he uses his own private key SK to decrypt the information. In the case of a distributed key algorithm, Bob sends a secret message to the group Group. Bob uses the group's public key PK to encrypt the information. After the group receives the encrypted information, it needs to use the private information of different people in the group. The key, including Alice, Carl, and David's SK, decrypts the information together.

Figure 3 Comparison of existing asymmetric ciphers and distributed non-key encryption and decryption

Through the above-mentioned transformation of the asymmetric cryptographic algorithm in the existing centralized mode under the distributed background, it is possible to realize "person", "finance", "right" and "data" based on blockchain and other distributed applications. Native distributed support, which can achieve richer upper-layer distributed applications.

Figure 4 Distributed key technology can achieve remote management of different systems

Based on the distributed key technology and the cross-chain interoperability scheme, remote management of "people", "finance", "rights" and "data" from different blockchain systems or traditional information systems can also be realized As shown in Figure 4, a cross-chain scheme based on a distributed key algorithm is constructed.

Fourth, the distributed implementation of asymmetric cryptography is a substantial breakthrough in promoting blockchain technology and application governance

In existing blockchain systems and information systems, the private key is the user's passport in the system, and no one can influence its behavior even under abnormal conditions. In this case, we can only rely on KYC, rely on the analysis of the data to find anomalies, and rely on the after-the-fact disposal of the abnormal situation.

This situation is mainly due to the lack of appropriate and effective regulatory tools and means. On the basis of existing data collection and data analysis, we should give blockchain applications prior approval capabilities, cross-chain pin-type supervision capabilities for external blockchain applications, and asset control in certain specific situations Right to take over. These capabilities require breakthroughs in distributed implementation that rely on asymmetric cryptographic algorithms. As shown in Figure 5, distributed management of "people" is achieved through a distributed identity management protocol, distributed management of "accounts" is achieved through a distributed asset protocol, and distribution of "accounts" is achieved through a distributed permission management protocol Management through distributed data management protocols, and the cross-chain implementation scheme based on distributed keys to jointly build the regulatory capabilities required by the blockchain.

Figure 5 Blockchain supervision capability composition based on distributed key technology

Therefore, the distributed implementation of asymmetric cryptographic technology is a necessary technical foundation to promote the substantial combination of blockchain technology and application governance, and to promote the development and promotion of the blockchain industry.

Fifth, distributed keys can achieve a rich combination of business logic

1. Realize distributed management of user identity

Based on the distributed key algorithm, users can implement binding with this distributed generated private key set in multiple ways, thereby realizing easy-to-read and difficult to store private keys to decentralized distributed systems Then the user identity is managed in this distributed system. The security of this binding is also mathematically provable. Since each distributed private key cannot independently generate a valid signature, such escrow is secure.

There are several ways for users to implement a binding relationship with a distributed private key collection.

(1) The user generates an escrow account in the trusted distributed system

Users can generate an escrow account in the trusted distributed system. The escrow account is also implemented with an asymmetric key algorithm, which is equivalent to completing registration in the trusted system.

As shown in FIG. 6, after the account generation is completed, the user may request that the trusted distributed system generate a user identity in a third-party system. When the user identity is generated, the binding between the managed identity and the user's account in the trusted distributed system is completed, and the hosting of the user identity is also completed, so that the user can use the same account in the trusted distributed system. Manage user identities in multiple third-party systems.

Figure 6 Users generate escrow accounts in a trusted distributed system

In this scenario, the user's identity is fully hosted in a trusted distributed system. The user holds an account that proves that he / she corresponds in the system, thereby owning the identity of all managed users bound under the account. Such a binding relationship depends on the corresponding records of the trusted distributed system.

Its advantage is that the distributed private key set corresponding to the escrow identity completely exists in the distributed system, and users do not need to care about its security. At the same time, in the use process, as long as the user initiates an operation request, the distributed system completes subsequent operations after accepting the request, and does not require the user's full participation.

(2) The user holds one or several private keys in the distributed private key set

Another implementation is that one or more private keys in the distributed private key set are held by the user. In this way, the user is both the principal and the trustee of identity hosting. The binding relationship between a user and a hosted identity is guaranteed by a cryptographic algorithm, which is a mathematically provable binding relationship.

You can set the parameters of the algorithm to implement the distributed private key function. For example, in the signing process, if the participation of the distributed private key held by the user is required, a richer logical function can be formed as shown in FIG. 7.

Figure 7 The user holds one or several private keys in the distributed private key set

The advantage of this solution is that it provides higher security for identity hosting. But in the use of signatures, users need to participate in the whole process.

2. Achieve privacy and regulation

Certain behaviors of users in application systems need to implement privacy protection. User identity hosting can provide a reliable privacy identity for users in the real world. Through the distributed key system, a decentralized distributed user identity hosting platform can be established. The distributed algorithms and decentralized features ensure that no entity third party can obtain the real world corresponding to the identity of the trusted user. Real user information.

At the same time, in the current real world, the government has clear regulatory requirements for some industries and some specific applications, such as finance, import and export, and customs. Supervision lies in being able to understand the macro data, make timely adjustments or, in special circumstances, have effective means of review to locate the source of the problem. This puts forward the requirement of layered management between privacy and supervision, that is, in daily use, users' behavior in the system should be protected by privacy, while being able to provide supervisory and auditing capabilities in a small range .

In an application system with a supervisory function, as shown in Figure 8, before generating an identity hosting system account, users can access the corresponding KYC system and complete the required identity authentication in accordance with the requirements of local laws and regulations. These KYC data will not appear in the identity hosting system or application system, so as to ensure its privacy behavior in the application system. At the same time, these data are encrypted and stored in KYC and authorized to access to specific parts, so as to meet the needs of supervision and audit. .

Figure 8 Implementing supervision functions using distributed key technology

3. Achieve distributed management of user permissions

Distributed key algorithms can further combine cryptographic technologies such as threshold signatures to build richer logical relationships between distributed private keys.

The basic logical relationships include:

(1) Equivalent "AND" relationship between distributed private keys

Without setting a threshold, the power of each private key in a distributed private key set is equal. The complete participation of all distributed private keys is required to complete the corresponding operation, so the logical relationship between the ANDs of the distributed private keys is shown as follows:

(2) "AND-OR" relationship between distributed private keys constructed by thresholds

When the thresholds t / n and t≤n are set, each private key in a distributed private key set is equivalent. However, more than t distributed private keys are required to complete the corresponding operation, so the relationship between the distributed private keys and or is shown. As follows:

(3) Specify the "and or" relationship of a distributed private key

In the case of a threshold, it is specified that one of the distributed private keys must participate when the signature operation is completed, and there is a relationship between the specified distributed private key and other participating distributed private keys.

When using a distributed private key to build a permission relationship, this set of distributed private keys does not correspond to a user, but each distributed private key in the distributed private key corresponds to multiple participants in the actual business application. The above-mentioned logical relationship is used to construct the relative permission relationship between participants in business applications.

(4) "AND" relationship of peer-to-peer distributed private keys

The number of private keys in the distributed private key set and the number of application participants are 1: 1. As shown in Figures 9 and 10, each application participant holds a distributed private key in the set, so these participants Establish a peer-to-peer decision relationship between them. This logic at the business level means that all operations require the unanimous consent of all participants to complete.

Figure 9 The relationship between the peer-to-peer distributed private key AND forms a "YES" conclusion  

Figure 10 The relationship between the peer-to-peer distributed private key "AND" forms a "NO" conclusion  

 

(5) "AND" relationship between distributed private keys constructed by thresholds

The number of private key shards in the distributed private key set and the number of participants in the business are 1: 1. Each participant holds one of the private key shards. However, due to the existence of thresholds, a few decision-making relationships that obey the majority are established. Participants' opinions beyond the threshold, as shown in Figures 11 and 12, will not affect the final decision results.

Figure 11 When the number of private key shards and the number of business participants are 1: 1, a “YES or” relationship with a threshold is formed and a “YES” conclusion is formed  

Figure 12 When the number of private key shards and the number of business participants is 1: 1, a "NO" conclusion is formed when there is a threshold "AND" relationship.  

The number of private keys in the distributed private key set and the number of application participants 1: n (n≥1), then different participants hold different numbers of distributed private keys, as shown in Figure 13, holding distributed private keys The number of keys corresponds to the different weights of different participants in the expression of opinions. For example, an application scenario where different shareholders have different voting rights in a shareholder meeting.

Figure 13 "AND or" relationship between the number of private keys and the number of application participants in the distributed private key set 1: n (n≥1)

 

(6) Specify the "and or" relationship of a distributed private key

In this case, the final result must be supported by the participant holding the distributed private key, which is equivalent to the participant holding the distributed private key having a vote of veto on the decision, as shown in Figure 14.

Figure 14 Specify an AND relationship of a distributed private key

Six, effective supervision based on distributed key technology

1. Operational real-time approval

Evaluating the system's operating status through historical record data, checking whether the business application complies with the specifications, discovering whether there are any abnormal operations and prompting related risks, is a post-hoc monitoring and post-correction method. For core and key business applications, business supervisors need to be empowered with prior approval.

The traditional method is to implement the approval operation of a business request with different permissions through the service flow, but it has the following disadvantages:

(1) The approval method of business circulation depends on the accuracy of the code's implementation of business logic, and there is a possibility of logic loopholes;

(2) The approval method of business circulation cannot form a valid voucher for the decision-making process. The approval process and the instructions submitted in the final system do not constitute a strict correlation, and cannot form a logical relationship that can be traced and cannot be tampered with.

Distributed key technology can implement distributed signatures with the participation of supervisors, giving supervisors real-time approval capabilities for user operations. As shown in Figure 15.

Figure 15 Distributed business process with supervisor participation in distributed key technology

The specific process is as follows:

(1) The executor (one or more parties) and the supervisor (one or more parties) independently control their own private key fragments;

(2) For operations submitted by the executor, if the supervisor needs approval, the supervisor will complete a valid signature on the operation instruction in a distributed manner, and the signature can be verified by a third party using the traditional public key method;

(3) The signing process is interactive. When the supervisor receives the operation instruction submitted by the executor and during the signing process, he can terminate the signature of the transaction and refuse to form a valid transaction instruction.

Distributed signature based on distributed key technology is a mathematically provable process. A distributed signature is a valid digital certificate that traces the approval decision process and cannot be tampered with.

At the same time, both the regulated object and the on-chain assets may participate in the business applications of third-party blockchain systems. As a result, distributed key technology can be used to implement distributed control of user identities, account addresses, and operating instructions in other blockchain systems for supervised objects and on-chain assets. The pin-type supervision of the chain system provides real-time approval capabilities for users, assets, and operations in third-party systems.

Figure 16 Supervision of cross-chain systems by distributed asymmetric cryptography  

2. Exception Handling

For abnormal situations discovered after the audit, such as the illegal operation of some supervised objects and the takeover of related account assets, it is necessary to give supervisors an abnormal handling capability that does not require the supervised object to participate .

Figure 17 Exception Handling by Distributed Key Technology

By adopting the threshold threshold setting through distributed key technology, supervisors can be given private key fragments that reach the threshold setting, thereby achieving emergency processing capabilities for specific assets under special circumstances . As shown in Figure 17, in this process, the supervisor can use the private key shards that reach the threshold when needed to complete the transfer of assets in a specific supervisory account, thereby locking related assets and avoiding continued violation operations. .

We will continue to update Blocking; if you have any questions or suggestions, please contact us!