PlatON Privacy-Preserving Computation WhitePaper | Part 6 Distributed Key Management Services

Continued from the previous article. PlatON Privacy-Preserving Computation WhitePaper｜Part 5 Applications

This article will introduce the sixth part of the Privacy-preserving Computation White Paper, Distributed Key Management Services(KMS) and preliminary roadmap of PlatON Pravacy-preserving computation .

6 Distributed Key Management Services

Blockchain provides the underlying core technology of decentralized networks. In all these blockchain systems, decentralization essentially means that each individual could control his own asset by means of controlling the private key (or signing key) of digital signatures. A transaction (transfer of assets) is valid as long as the underlying signature passes the verification . However, controlling the private keys individually may incur many problems in practice.

Usability.

Private/signing key differs from password. In most of our daily applications, people get used to keeping in mind the passwords with specific meanings. However, private keys are random strings with 32 bytes length. It is barely possible to remember all these meaningless strings when participants initiate transactions. Several methods are proposed to manage private keys, but all of them have some drawbacks.

Mnemonic words. Mnemonic words are generated from standard algorithm, which takes a private key as input. These words have specific meaning and could be converted back to a private key. Although it is easy to remember one single word, there are always more than 10 words to represent one private key. Therefore, Mnemonic words are commonly used as backups of private keys and stored in physical materials. For instance, write them down in a paper, and put it into a safe deposit box.
Keystore. In most decentralized wallets, passwords are used to protect private keys. Private keys are encrypted using symmetric ciphers (e.g., AES) by taking the password as a secret key. The resulting ciphertext forms the keystore file, which is stored locally in the device. Keystore file significantly simplifies the usage of private keys, in which the usage is essentially the same as centralized Apps. However, when users change devices, they have to import the keystore files. This will increase the complexity when changing devices.
Hardware Wallet. Users who have higher security requirements may prefer to use hardware wallet. The private keys are generated and used in a safe and trusted area in the hardware wallet. Private keys will never leave this area in the whole life cycle. The underlying security is essentially provided by the hardware, which controls the access of private keys. Thus, users have to carry a customized device or card to deal with their asset, and these devices are commonly suitable for laptops, not for mobile phones.

Security.

The one who has the private key could totally control the asset, the security of private keys directly affect the security of the asset. Most events such as exchange security incident and asset loss are caused by mishaps of private key management. Loss of mnemonic words, keystore files and hardware wallets happens frequently, and the lack of retrieval mechanism prevents users finding the private key back. Once users lose private keys, loss them forever.

Although many approaches are proposed to protect private keys, we should pay more attention to one crucial attack surface. That is, the private key appears in the memory in plain when using it to sign a transaction. Despite of a very short time slot, the attackers could easily steal the whole private key and then all the assets without sophisticated precautions.

Lack of Approval Procedure.

In the traditional financial management procedure, the approval of large fund transfers is very complicated, and each enterprise may have specific polices. For example, the transfers should be approved by the finance specialist, CFO and CEO sequentially, before they are initiated. However, these polices could not apply to blockchain directly. This is because the private-key owner could ignore all the polices, and initiate transfers as he wants.

One commonly used method to solve the above problem is multi-signature. Roughly speaking, this approach relies on smart contract (or script in Bitcoin). The smart contract states that “this transaction is valid as long as three collected signatures are valid”, and execution of the transfer will exactly follow the constraints as stated. Theoretically, smart contract could specify arbitrary polices for different purpose, but it still has some drawbacks.

Smart contracts will be run by every node in a repetition execution way. Thus the policies stated in smart contract are publicly known to all participants. This is not desirable for enterprise customers, since the policy may leak sensitive information from the company.
Another serious issue is that the policy is also public to hackers, who may have interests in attacking the company. Contract security has been one of the important problems plaguing the entire blockchain community.
For custody providers, they always need to maintain hundreds of blockchain assets and tokens. These heterogeneous blockchain may design different smart contract systems or even do not support smart contract. The cost of developing policy-related smart contract will be extremely high for these custody providers. The developers has to learn different programming languages, complete and sophisticated security test of these resulting contracts should be taken into account.

It is worth pointing out that the requirement for key management is much urgent for enterprise users. Individual users may prefer to use centralized wallets for high-frequency trading, and actually do not possess the private key.

In order to solve the above problems, we aim to utilize cryptographic protocol to provide distributed key management systems. More specifically, the underlying multi-party computation (MPC) protocol is threshold signatures. Utilization these tools and protocols are arising in the blockchian community, but still lack of commercial use and standard.

6.1 Threshold Signature

Threshold cryptography enables a set of parties to carry out cryptographic operations, without any single party holding the secret information. Threshold signature is a subfield of threshold cryptography, which focuses on distributed signing. In cryptography community, one may design new signature schemes that are suitable to convert into the threshold version. But this is not desirable in blockchian community, because specific and standard signature schemes, such as ECDSA/EdDSA/BLS, are already adopted. It is extremely difficult to replace them with new ones. Therefore, this direction aims to design efficient MPC protocols for existing signature schemes.

In general, threshold signature comprises the following two main components.

Distributed Key Generation.

In a traditional key generation procedure, one chooses a uniformly random private key x, and generates a public key locally. In a distributed key generation procedure, n participants choose uniformly random shares x1,…,xn locally, and run a MPC protocol to generate the public key without collecting all these shares together. The resulting private key is x = x1 + · · · + xn and does not appear in the procedure.

• Distributed Signing.

A signing algorithm takes as input the message and the private key, and outputs a digital signature. In a distributed version, each participant holds xi and runs a MPC protocol to compute the signing process without collecting x1,…,xn together. The resulting signature is essentially the same as the local version.

Plenty of threshold signature schemes have been proposed [30, 14, 9, 18, 31, 15, 10, 11, 36]. LatticeX Foundation encourages cryptography experts to implement these protocols and make them open-source.

6.2 Framework and Architecture

Framework. The aim of distributed key management services based on threshold signature is to provide a unified framework to guarantee security, usability and flexibility. The basic framework is illustrated as follows in Figure 3.

The core component is a distributed KMS server, which could be deployed in different environments. Although only two servers are depicted in Figure 3, one could easily extend them to multiple servers. The servers interact with each other to run threshold signature protocols, and provide standard APIs for developers to customize their business logic, including the policies.

Two levels of policies are considered in this framework. The private keys are shared between severs according to some policies which we called Level-1 policies. The server himself could reshare the previous shares into subshares according to other polices, which we call Level-2 policies. These subshares are always distributed to individual users, which is essentially generated by the (n, t)-Shamir Secret Sharing scheme.

The basic workflow is stated as follows.

When a group of participants requires creating a jointly managed account, the two servers call the distributed key generation procedure and obtain x1 and x2, respectively. Server 1 reshares x1 according to Level-2 policies (e.g., 3-out-of-3 policy), gets x11, x12, x13 and sends them to the individual users, respectively. Server 1 will delete all the shares at the end of this procedure.
A Large fund transfer could be initiated by the system or one participant in the group. If all the participants (or other conditions satisfy the Level-2 policy) approve the transfer, they will send the subshares to Server 1. Server 1 confirms the approval, collects the subshares, reconstructs the share x1 and runs the threshold signature protocol with Server 2 to complete the transfer.

This framework has many advantages covering security, usability and flexibility, which are described as follows.

Security.

Inheriting from threshold signature, the private key never appears in the life cycle. The shares (of Server 2) could be managed by traditional KMS (see Figure 4). For individual users, the subshare could be stored in mobile phone. It will not affect the security of the whole system even they lost the subshares. Additionally, traditional authentication method, such as two-factor authentication, could be applied to enhance the security. One could even refresh the subshares in a fixed period or manually.
Usability. One important advantage of this framework is that the end-side users do not need to approve the transfer on-line simultaneously. They simply send the subshares independently and the interactive protocol is actually handled among the servers.

Flexibility.

The users could set customized Level-1 or Level-2 policies according to their business logic. It is also very flexible in design retrieval mechanisms by combining policy levels. For instance, one could set Level-1 policy be (2, 2) and Level-2 policy be (3, 1), then the retrieval service is provided by Server 1. Or one could set a (3, 1) Level-1 policy, then the retrieval procedure is provided by all the three servers.

Architecture.

The core component of the framework is the DKMS server. The architecture of the server is depicted in Figure 4.

At the heart of the server are various threshold signature protocols that supporting commonly used digital signature schemes, including ECDSA, EdDSA, BLS and Schnorr. Note that the difficulty is to design efficient threshold signature protocols for ECDSA and EdDSA. Other MPC protocols to support hierarchical deterministic wallet and share refreshing are also very useful in practice.

In the early version, a middleware called Key Module is designed to connect MPC protocols and Tink [20], which is an industrial-grade framework developed by Google. In this version, the mature tink framework is used to help manage the shares. A long-term version will integrate these protocols into tink.

Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard to misuse. It reduces common cryptography pitfalls with user-centered design, careful implementation and code reviews, and extensive testing. At Google, Tink is one of the standard cryptography libraries, and has been deployed in hundreds of products and systems. Tink was born out of our extensive experience working with Google’s product teams, fixing weaknesses in implementations, and providing simple APIs that can be used safely without needing a cryptography background.

Tink also supports external key management service, such as Amazon KMS, Google Cloud KMS, Android Keystore, and iOS Keychain. For commercial usage, these standard and widely accepted KMS systems are preferred to manage shares.

7 Roadmap

The preliminary roadmap is given in Figure 5.

2021 Q2

Support basic ZK-SNARKs algorithms, including Plonk.
Support basic primitives, such as zk-friendly hashes et al.

2021 Q3

Support private payments, including confidential transaction, anonymous transaction and private transaction.
Publish open-source distributed key management services.

2021 Q4