listen to this article:
Cryptographic Validated and Easy to Use Multi-Party Approval Structures
The setting of multiparty computation (MPC) is one where a number of distinct, yet connected, computing devices (or parties) wish to carry out a joint computation of some function while preserving certain security properties in the face of adversarial behavior. The basic idea of MPC is to enable a set of parties to carry out a computation without any trusted party. We call such a process an “MPC protocol”.
To illustrate how this works, let’s discuss an example (Figure 1). John, Sarah, and Jill want to know what their collective average salary is, yet none of them want to tell the others their salary for fear of having the lowest salary. Using MPC, each participant would input their salary without revealing what their salary was to the other participants, and the MPC protocol would tell the group what the average salary is. Each student would only know their own salary and the result of the computation –the average salary between the three individuals.
Figure 1: MPC example scenario
- Secure Multiparty Computation – Toy Example Scenario: A group of cryptographers wishes to compute their average salaries without revealing their individual salaries
Basic Security Requirements for an MPC Protocol – Privacy and Correctness.
The concept of MPC considers an adversarial setting, where some of the parties (or an external entity) try to “attack” the protocol. The aim of such an attack may be to learn private information (e.g., the salary of some of the participants) or to cause the result of the computation to be incorrect (e.g., that the average salary is some specific value so that they can offer someone in the group a job and have them think that their offer is good). As such, two of the most basic security requirements for an MPC protocol are privacy and accuracy.
- The privacy requirement states that nothing should be learned beyond what is absolutely necessary; parties are aware of often designated output and nothing else.
- The accuracy requirement states that each party should receive its correct output and can rely on it. Therefore, the adversary must not be able to cause the result of the computation to be different from the function that the parties had set out to compute.
Secure multiparty computation can be used to solve a wide variety of problems, enabling the utilization of data without compromising privacy.
MPC vs. Shamir Secret Sharing
, this cryptographic protocol might get you confused with another cryptographic protocol called Shamir’s Secret Sharing Scheme (SSS). Although SSS and MPC are both ways to cryptographically distribute the shares of a key, they are different in how each system distributes the shares. When using SSS, the key must be created in its full format, which results in a single point of failure. Only after it is created in its unencrypted form will the key be distributed. Whenever an event requires an authorization or signature, the SSS key-shares will be reassembled into the full unencrypted key, posing a hazard to the organization. With MPC, the private key is never assembled as an unencrypted key and will never reside as a whole in a single location at any point in its lifecycle (not even when key shares are being used to authorize the event).
Multiparty Approval Structure that is Platform Agnostic
Apart from its distributed design and the constantly changing share value, MPC has the advantage of flexible implementation. Every business is different, and segregation of duties is a cornerstone of physical and virtual security. MPC allows businesses to distribute the duties associated with authorization approval across multiple parties within a variety of organizations. MPC shares can be held by any party, either in a virtual or physical hardware security module (HSM). HSMs are physical computing devices that safeguard and manage keys and perform encryption and decryption functions for digital signatures. These devices traditionally come in the form of an external device that can be plugged into a computer or network server.
MPC protocols also allow for almost anyone to assume a party within the ecosystem. Parties can be people within the organization or a software bot that approves or declines a transaction based on an automated algorithm or artificial intelligence. A party could also be an external, trusted third party. Furthermore, the approval process can be done in one phase or in multiple and sequenced phases, requiring certain parties’ approval before others. Sufficient data security practices call for the segregation of duties between the approval initiator and the approver. This process can seem cumbersome, but for certain fewer complex steps such as a KYC or AML check, the approval process can be automated. This automation assists in smoothing the approval process and improving efficiency.
Therefore, it is easy to establish a secure, multi-party, cryptographically validated, and compliance-ready approval process with MPC. For example, a policy of multiple approving parties could consist of three groups, a total of nine possible signers, and a policy of five of nine signers for each transaction. The signers could either be humans or artificial intelligence and/or external or internal signers.
Finally, it’s important for any business to make sure that shares can be recovered in a disaster or significant loss. In the event that one party is corrupted, having access to a backup share is critical to an organization. Backup shares can be stored in offline servers, or with trusted third parties, and be accessed whenever necessary. Recovery would require a strong policy, designed to prevent the key recovery process from becoming a point of weakness. It is recommended that recovery keys are stored in an encrypted offsite backup storage facility. This way, the recovery will be insulated from both cyber and physical attacks. MPC share backup is an essential feature of any good MPC protocol.
Example Use Cases Where Multiple Parties Are Required
RSM (link) has written an elaborated article, diving into the possible applications of MPC. Amongst these use cases, you can find:
Secured Authentication – describing how an MPC multifactor structure designed to provide the National Institute of Standards and Technology would describe as “hard” cryptographic authentication, which offers impersonation resistance verification. MPC is extremely secure and fully adheres to the SYH requirement.
Phone as a Key Chain – where using an MPC protocol allows parties to store a share of the private key on their phone without the fear of an account being compromised if the phone were to be stolen. Storing an MPC key share on a phone is secure even in the event of the phone being stolen or hacked the information cannot be used in isolation to access the information.
vHSM – Another significant use case for MPC technology focuses on replacing our reliance on hardware security modules. In current enterprise applications for public or private key management, most companies utilize a physical Hardware Security Module (HSM). These HSMs are physical computing devices that safeguard and manage digital keys, perform encryption and decryption functions for digital signatures, and provide strong authentication and other cryptographic functionalities.
Going passwordless – MPC technology solves these issues by providing a robust, user-friendly experience without compromising security. MPC technology never requires the password to be created or used in its full form and instead creates two separate, random shares.
Signing a Transaction – MPC protocol can allow a party to sign a transaction without having to reassemble the private key. To do so, each party uses their encrypted key-shares to sign the signature, which contributes key material to compute and decrypt the full signature.
Bringing it all together
MPC is the next advancement in secure key management and transaction authentication and approval processes. MPC protocols eliminate single points of failure, offer improved enterprise-grade, mathematically guaranteed security, and drastically enhances scalability.