As both a regulated digital asset custodian and managed self-custody wallet provider, the technical questions CoKeeps are most often asked include:
In this article, we are going to explore how CoKeeps generates cryptographic private keys, but in order to do so, we must first discuss two of the most popular strategies cited by the majority of our competitors. In an on-going battle of acronyms, the task of explaining the differences between HSM and MPC key generation methods seems to have become a tradition for digital asset custodians to publicly disclose their position between the two.
Hardware security modules (HSM) are physical computing devices dedicated to the purpose of utilising cryptographic credentials. They are manufactured to perform specific tasks that cannot be repurposed for other things and can range in scale from generic computer-chip enclaves such as Intel’s SGX through to more robust portable cryptocurrency hardware wallets similar to Ledger. We believe that when used for transient data such as active user authentication, HSM can provide an extremely secure process flows, in which lost or corrupt cryptographic credentials can be easily replaced with new ones as and when required.
However, when HSM is used to store the assets themselves, their physical form also becomes their most relevant vulnerability – a distinct point of failure that can only be backed-up through further exposure of seed phrases or recovery keys. Although the full extent of concern can be reduced by splitting the backup using something such as Shamir’s secrets, the end result when the shards are combined remains the actual assets.
In contrast, using secure multi-party computation (MPC) to generate cryptographic credentials involves multiple systems from different independent environments to be accessed simultaneously in order to generate or use the cryptographic credentials in real-time, rather than needing to store sensitive information in a single location. In this example, Shamir’s secrets can be put to better use as recovery keys for account access, instead of providing direct ownership of the assets themselves.
The technical goals of MPC protocols are to ensure that no information about the private data held by the individual entities can be inferred from the messages that are sent to each other during the execution of the protocol and that any subset of adversarial, corrupt or colluding entities willing to share information or deviate from the instructions during the protocol execution should not be able to force honest entities to output an incorrect result.
Unfortunately, MPC protocols designed specifically for digital assets are a relatively new cryptographic field, similar to and often even involving the use of Zero Knowledge proofs, which is also an experimental subject that has not had as much time tested in production as traditional cryptographic primitives such as elliptic curves and message signing. The majority of MPC protocols used by digital asset custodians rely upon a trusted setup that involves the cryptographic private key needing to be initially split and then recombined later for signing, both of which are moments that if taking place on a server results in the opportunity for the private keys to be copied or taken out of the system without anyone knowing. When service providers hide the complexities of what is taking place behind their own servers, it’s very difficult to be certain that everything is as it should be – especially if they are over reliant upon the security of the MPC protocol or use it in conjunction with virtual accounting.
CoKeeps implements a Zero Trust architecture that expects every entity at every layer to be adversarial in nature – with authentication required at every stage of every action. It’s a slow and methodical process that relies upon as much trusted technology as possible. Since we provide what we market as both hot and cold wallets, as well as offering optional custodial services, we have a number of different ways in which private keys are generated, which is based upon the use case they are designed to aid.
We utilise WebGL device fingerprint broadcasting over DNS to authenticate devices, which removes the need for us to store and authenticate user credentials from our own database. Since we have yet to formalise our proprietary MPC usage into a published protocol, we continue to refer to it as an MPC methodology, which is more inline with our general Zero Trust architecture and capable of withstanding all but all adversarial participants.