Multiparty Computation threshold signing in Practice: Bringing Security to our Customers

Author: T. Koens

This article covers ING’s latest development on Multiparty Computation. Find the code for our MPC solution here, and the whitepaper here.

While distributed ledger technology (DLT) provides powerful solutions to achieve decentralized operations, securely running a DLT platform remains a challenge. One important problem in such platforms is the secure management of the keys that are used in the DLT operations. Fortunately, by using a cryptographic technique called secure multiparty computation (MPC), it is possible to overcome the key management problem in DLT platforms. An area of MPC, called threshold cryptography, facilitates the distribution of a secret key to multiple parties, which eliminates the risks of a single point of failure (when one person’s mistake can effect an entire transaction).

In this article, we explain MPC and threshold cryptography and describe how they can be used in digital signatures. Furthermore, we discuss how threshold signatures can be implemented and what additional security mechanisms can be applied to achieve proactive security.

Increasing security

Now that Distributed Ledger Technology (DLT) platforms are adopted by corporations on a global scale, the need for managing secret keys is becoming an important security aspect. Such secret keys allow for the identification and authentication of participants on a platform. For example, if you log in to your online ING account, you may use a PIN-code or password to prove that it is actually you. However, as you may have experienced yourself, managing your PIN-code or password is not always an easy feat. You may forget your password, your password can be stolen, or you simply mix up your password which temporarily locks you out of a service. Of course, you can start writing down your password on a sticky note, but that goes against good security practices as others may easily obtain it.

Let’s have a more detailed look at how passwords that you may use online work, by using a digital signature scheme as a working example. In cryptography, a digital signature scheme allows identification and authentication of a participant on a platform. Such a scheme contains three algorithms:

1. The key generation algorithm, creating a public and private key pair.

2. The sign algorithm, where a private key is used to sign a message, creating a digital signature.

3. The verify algorithm, where a public key is used to verify that a digital signature is correct.

The public key is known to all participants on the platform, and only each participant knows their unique private key; you can consider this as your password. A private key is required for signing data to prove that a participant is the creator of that data, as all other participants can verify the signature against the corresponding public key. Furthermore, anyone can encrypt a message with your public key and only you can decrypt that message with your private key. This allows for sending a message over an insecure channel without anyone, except you and the sender, being able to read that message. An example of using a private key is adding your signature to an email that you send.

Managing that private key, therefore, becomes very important; if you lose your private key you now no longer have access to your data. If you are the sole owner of a private key, you can make as many transactions as you wish (assuming no additional security measures are in place), so keeping the private key secure and to yourself is important.

A single person managing a private key, however, may introduce a single point of failure risk.

An example is Alice sending a transaction to Bob. Alice could initiate a million euro transaction, signs the transaction with her private key, and send the transaction to Bob. However, in this scenario Alice could send that transaction to her friend, Carol, by mistake instead. If we want to reduce the single point of failure risk of Alice sending a transaction to Carol (instead of Bob), we could ask Don to also sign the transaction, together with Alice.

So how can we achieve two (or more) parties signing a single transaction? This is where Multiparty Computation threshold signing (MPCts) may provide a solution.

Multiparty Computation threshold signing

Indeed, a very promising solution to address private key management is that of Multiparty Computation threshold signing. In short, in MPCts the key generation algorithm and verify algorithm are replaced by an interactive protocol between multiple participants. A quorum of these participants must use their part of the private key to, for example, ensure the transaction receives a valid signature. This reduces the single-point-of-failure risk discussed in the previous paragraph. Also, losing your part of the private key becomes less of an immediate problem, as a majority of parties is needed for signing a transaction, meaning that if you lose your private key the other participants can still ensure that a transaction is signed. But wait a minute. Who creates and distributes that single private key? Isn’t that a new single point of failure? Fortunately, multiple parties must be involved in creating and distributing the key which also reduces the single point of failure risk.

Practical applications of MPC go beyond managing a private key. MPC also allows for confidential computation of data. As a practical example, imagine a retailer and a credit card company combining their data-sets to detect fraud by analyzing both sets. The interesting part is that MPC allows for combining the data-sets where both parties will learn the results of the analyses, but do not need to provide access to each other for the content of their own data-set.

MPC offers many benefits. First, it is provably secure and calculations made are correct. Second, MPC provides both privacy and usability. Third, using MPC could mean that the data is compliant to legislation, for example the General Data Protection Regulation (GDPR), as the data itself does not move cross-border. And finally, a third party (often called a dealer) that collects, manages, and combines the data is no longer needed, as data remains within a company’s environment. Indeed, removing such third parties could significantly lower the risk of data leaks, and decreases operational cost.

Practical applications of MPC(ts)

Both MPC and MPCts have many practical and useful applications. We discuss four of these applications below.

* Offering a custodian service to customers.

One interesting initiative on MPCts within ING is called Pyctor. The aim of this initiative is to provide a digital asset safekeeping service to customers. As part of this service, multiple large corporations could manage an online account of a customer together. This significantly improves the level of security. If one corporation has a security breach, the malicious actor cannot do much as multiple different signatures are required for a transaction to be valid.

* HSM replacement.

MPCts is an alternative for Hardware Security Modules (HSMs), as it performs the same function as an HSM, for example, the creation of digital signatures. HSMs are physical computing devices that manage private keys. However, as we described there may be some downsides of HSMs, such as vendor lock-in, large costs, and single point of failure. With MPCts the vendor lock-in can be avoided by, for example, using open source MPCts code. Also, the single point of failure can be avoided as MPCts are designed to be used by multiple players who all have a part of the private key.

* Automated Certificate Authority.

If an MPCts infrastructure has been set up, other parties (this could also be another department within an organization) can benefit from this infrastructure. For example, having set up an MPCts infrastructure allows the creation of an automated Certificate Authority (aCA) using MPCts. A Certificate Authority is an entity that issues digital certificates which certifies ownership of a public key to a real world name (in the certificate). An aCA aims to automate as many steps as possible between the issuing of certificates and its users. Although MPCts are not required to create an aCA, they do improve security as a CA is a single point of failure and MPCts distribute the risk of a breach over multiple participants. More importantly, there is no need to setup a completely new infrastructure for the aCA, as the MPCts infrastructure largely supports this, saving resources in time and money.

* Performing calculations with private data.

Imagine there are three parties, one party providing confidential input, one party performing calculations, and one party querying the results. Now, it may seem that at least one party (the party performing the calculations) gets to know the confidential input. However, with MPC the input, calculations, and results can be constructed without leaking any confidential information.

As an example, statistical data analyses of patients could be performed to increase the quality of care for patients.

MPC ensures that only the results of such analyses are shown to the parties that are allowed to see it. The patient data itself is not shown to other parties.

Some challenges of MPC

Before you start implementing MPC protocols, there are some challenges that should be taken into consideration.

* First, like any cryptographic primitive, the protocol should be correctly designed. Providing (mathematical) proof that an MPC protocol works as designed is a first step in addressing this challenge.

* Second, even if such a protocol is designed correctly, it must be correctly implemented (technically). Remember that, in our introduction, we discussed managing passwords. Although a correctly designed password management system may provide sufficient security, writing that password down on a sticky-note poses a significant risk as it bypasses the controls of such a system.

* Third, from a functional perspective, the protocol must address the (security) requirements set. For example, what is the number of malicious participants the MPC protocol allows for? and does this match the requirement for the maximum number of allowed participants?

* Fourth, MPC is a complex technology and should be audited. This requires that the auditors must be able to grasp the complex details of MPC.

* Finally, for several decades MPC was but of theoretical interest. However, research of MPC and the increase in computing power has led MPC to become of practical use, as we saw from the examples above. However, with very large data-sets MPC currently performs slowly, which could be a drawback for some use cases. However, given both the academic and corporate attention on MPC we expect that MPC will certainly evolve and that the challenges will be addressed.

To conclude, the practical examples show that MPC offers many possibilities to improve existing business processes, increase the level of security, and may even offer new services to customers. This is why ING continues to explore and implement MPC and MPCts. An in-depth description of our project can be found here. Its open source code can be found here to which you can contribute, too.

For any questions or remarks, please contact blockchain@ing.com.

Acknowledgements

Thanks to Hervé Francois, Oleg Burundukov, Victor Ermolaev, and Gamze Tillem for their feedback on the content of this article.