Builder Vault is software-based and 100% self-hosted, giving institutions complete control over where and how their key management and protection infrastructure is hosted. 

‍

Builder Vault is also available through AWS Marketplace, providing the option to license directly through AWS and automatically deploy in AWS Nitro with remote attestation and secret injection for the convenience of private clouds and advanced security.

‍

Securing enterprise secrets since 2014, Builder Vault uses a specialized subfield of cryptography known as secure Multi-Party Computation (MPC) to provide lifecycle key management with software that can be securely hosted on premises, in public or private clouds, mobile devices and more.

‍

Builder Vault provides multi-party controlled threshold signature services using ECDSA, EdDSA, AES, Schnoor and other common algorithms. As with all Builder Vault applications, MPC technology is used to generate, store, and use private keys to conduct threshold signing services across multiple, distributed MPC nodes.

‍

System users can configure the system to use a fixed or variable number of MPC key shares (m) to conduct signing services. This can be useful to enforce multiparty signing approvals where two out of three, three out of five, or some other m of n parties need to participate to collaboratively create a signature.

Since all key shares collectively represent a single key, the threshold signature appears to the application or end user to be a standard single signature, generated by a standard single key. Therefore no special coding is required by the application to enforce multi-party approvals and signing.

‍

Builder Vault Threshold Signature service can be used to sign transactions (such as digital asset transactions), code, and virtually any other digital content with public key authentication. Today, Builder Vault threshold signature services secure more than $1B in daily transactions and is considered by major institutions to be a best-in-class threshold signature solution.

‍

Builder Vault can be used to create a Threshold Security Module (TSM) which is functionally similar to a virtual Hardware Security Module (HSM), only the virtual machine and the associated secrets and operations are distributed across multiple MPC nodes.

Similar to a HSM, Builder Vault TSMs can be used to generate, store, and use keys internally by the system to decrypt critical documents or verifiably sign digital content while conforming to industry standard protocols. TSM can also export keys for use in external systems. 

‍

Unlike virtual or physical HSMs, which introduce single point of failure vulnerabilities by storing complete keys on a single physical or virtual machine, Builder Vault TSM stores shares of a single key on different physical or virtual machines. Depending on the threshold (t) security model, a malicious party would need to compromise at least t+1 parties before they could defeat the TSM security scheme to gain access to enough key materials to recreate a complete key or to use the distributed shares to fraudulently execute a cryptographic operation. 

‍

The ability to host MPC nodes and associated key shares on different physical or virtual machines and cloud containers, with different administrative access dramatically increases the security of Builder Vault protected keys over conventional software-based key management and protection solutions,

‍

Builder Vault is an entirely software based key management system that you host in secure public cloud enclaves, on-prem containers, and/or mobile devices for unrivaled flexibility and control.

‍

PKCS #11 is a cryptographic token interface standard which specifies an API that enables applications to address cryptographic devices, such as Builder Vault, as tokens and can perform cryptographic functions as implemented by these tokens. Certain applications require highly secure Public Key Cryptography Services but also require more flexible and agile deployments than are available with conventional PKCS #11 solutions.

‍

In conventional implementations of PKCS #11, an object (like a key) consists of a long list of attributes where the key itself is one of many attributes. Some attributes may contain information such as permissions for how the key can be used. As with the key itself, the permissions can be altered if fraudulently accessed, creating a vulnerability for misuse even while the key itself remains secure.

‍

Builder Vault’s PKCS #11 plug-in provides secure Public Key Cryptography Services via a standard interface while eliminating common single point of failure vulnerabilities that can result in key theft or misuse. While traditional PKCS #11 solutions store a complete key on one device along with a single copy of the attributes, Builder Vault generates, stores, and uses three different shares of a key along with a copy of the attributes on three MPC nodes. When a cryptographic operation is called up, each node uses its locally stored key share and copy of the associated attributes to verify permissions before executing the operation. 

‍

In order to defeat the Builder Vault PKCS #11 system a malicious party would have to hack into three different MPC nodes, undetected, in order to steal a complete key or modify the attributes stored with each key. Hosting MPC nodes in different secure computing environments, each with a different administrator, materially increases the security of the public keys and attributes while enabling an entirely software-based solution for greater flexibility, scale, and agility than exists with conventional alternatives.  

‍

Secure multi-party computation (MPC) is a specialized subfield of cryptography. MPC allows multiple parties to each hold a secret and collectively compute an output using those secrets, without the parties ever disclosing their secrets to one another or any other party.

‍

Builder Vault uses MPC to generate, store, and use private keys in the form of multiple distributed key shares, each held by a different party. When a key operation like digital signing or decryption is required, the distributed parties compute the operation output without ever creating or disclosing their key shares to any party.

‍

By generating, storing, and using private keys in this distributed manner a malicious party would have to compromise some minimum threshold number of parties (t+1) holding key shares in order to steal or maliciously use the key.

‍

Depending on the MPC threshold model, a malicious party would need to compromise all parties or some majority subset of parties. When these parties use different physical or virtual machines in secure environments, with different administrators the security of private keys can be comparable or superior to physical or virtual cloud hosted HSMs, without the cost, complexity, or scale limitations of those alternatives.