Private keys and public keys
Blockchains identify users using PKI (Public Key Infrastructure). PKI generates a private key and a public key as a pair and uses them for encryption and digital signatures. The defining property is this: anything encrypted with the private key can only be decrypted with the matching public key, and anything encrypted with the public key can only be decrypted with the matching private key. The public key is exposed to anyone, so when something is encrypted (signed) with a private key, anyone can decrypt it (verify the signature) with the public key and confirm who signed and executed a given transaction (TX). It is on the strength of that property that PKI has become the standard way blockchains identify users.
When you sign a transaction with your private key, the blockchain verifies it using the paired public key and grants the authority to change the balance of the wallet address derived from that public key. In other words, whoever holds the private key controls the assets at the corresponding wallet address.
Another characteristic of PKI is that a public key can be generated from a private key, but a private key can never be generated or inferred from a public key. That is why publishing the public key reveals nothing about the private key, and why secure encrypted communication and signature verification are possible at all.
The fact that a private key cannot be regenerated or restored in any way after its initial creation is a huge security advantage — and an equally huge drawback. Going through life without ever losing anything simply isn't realistic. That makes a backup and recovery system for lost private keys enormously important.
The most famous application of PKI, which predates blockchain, is the joint certificate (formerly the accredited certificate) used in Korea. A joint certificate contains a public key, and users are advised to keep the matching private key on a separate secure storage device such as a USB drive or an external hard disk. PKI itself is secure, but protecting the private key store has meant mandatory installation of security software — virtual keyboards, antivirus, tamper detection — which is why nearly everyone has at some point suffered through installing a pile of programs just to use a certificate. Storing a private key so that it can be restored later is, as you can see, no simple matter.
It is especially incoherent to introduce a separate trusted authority for private key management on a blockchain, whose ultimate goal is to eliminate trusted third parties in the first place. Individuals need to be able to manage their own private keys somehow, and those keys need to be available at all times. Blockchains generally leave private key management entirely to the individual and recommend writing the private key or a *mnemonic on paper or a USB drive, or using an HSM (Hardware Security Module, dedicated hardware for storing encryption keys securely). But paper and HSMs can be lost too, so it is hard to call any of these approaches always available. The best option would be to store the private key safely in the cloud — except the cloud is permanently exposed to hacking, so the risk doesn't go away either.
* Mnemonic
A string of 12 words that expresses an otherwise unmemorable private key in a form a human can recognize, used to recover a wallet if the private key is lost. Because the private key can be regenerated from those 12 words, a mnemonic must be protected to exactly the same standard as the private key itself.
Secret Sharing
So what if we use the cloud, but split the private key into several pieces and store them in several places? Imagine taking a physical key, breaking it into fragments, and depositing each fragment in a different bank vault. Even if a thief cracks a few of those vaults, they can't reassemble the whole key — so storage gets safer. And the owner, who can retrieve every fragment from every vault, can restore the key as long as the banks stay open. The weakness is obvious: if a bank shuts down, the key is gone forever. So we need a way to restore the key even when some of the banks close.
That idea is exactly where secret sharing begins. Secret sharing lets you split secret information (a private key) into multiple pieces and restore that secret once you have gathered more than a threshold number of them. This works because you are not simply chopping the key up — you are generating multiple shared clues from which the shape of the key can be reconstructed. Clues like 'the key is 3 cm long' or 'the key has four notches' are created in quantity, and knowing some number of them is enough to rebuild the key.
Fortunately, the secret that needs to be distributed is digital information, so a computer can perform all kinds of operations on it and the generation of these clues can be generalized into an equation. First, build an arbitrary degree-t (threshold) equation that contains the secret (S), then generate n values (Sn) and store each in a different repository. Because it is a degree-t equation, obtaining t of those values (Sn) from the repositories is enough to solve it and compute the secret (S).
To put it more plainly: you split the secret (S) into n pieces (that is, create n clues), store them across n repositories, and recovering any t of them restores the secret (S). Splitting the data across many repositories immediately raises the difficulty of hacking it. And because the n pieces are not physical fragments of the secret (S) but values (clues) that make the degree-t computation possible, inferring the secret (S) from fewer than t pieces is impossible. Which means that even if some cloud repositories are hacked or go down, the secret (S) can still be restored as long as t repositories are operating normally. High security and high availability are guaranteed at the same time.
* Reference
PARAMETA Vault
PARAMETA offers Vault, a private key backup system built on secret sharing. Vault consists of the Vault Manager, which handles user authentication, recovery key management, and repository registration and management; the repositories that hold the pieces of the secret; and a smart contract that shares Vault Manager and repository information. An SDK (Software Development Kit) ships alongside so clients can put all of this to use easily. Each repository is operated by a different party and can adopt its own authentication method — so the more repositories there are and the more varied the authentication methods, the stronger the security.
The secret sharing that generates the clues for a Vault secret is provided through the SDK. It splits a secret into n clues and, in reverse, restores the secret from t clues — and neither the secret nor its clues are ever transmitted to an external server all at once. The Vault client (e.g. a blockchain wallet) delivers each generated clue to its respective repository, where it is stored after user authentication.
Vault recommends encrypting the n clues before storing them in the repositories. The moment those clues travel to the repository servers they could leak over the network, and there is always the possibility that the repositories collude. The encryption key used here is itself secret information that needs its own backup, so it too has to be managed. Vault stores the encryption key in the Vault Manager, but also applies secret sharing to that key and distributes it across the repositories in case the Vault Manager fails.
Vault is based on an n-t threshold secret sharing algorithm: it splits the private key into n pieces for storage and restores it once t of them are recovered. Availability is high, because the private key can be restored even if several repositories fail, as long as at least t are still running. Security is strong, because stealing the private key requires hacking at least t repositories to collect enough clues. On top of that, because the clues sitting in the repositories are stored in encrypted form, restoring the private key is practically impossible even if every repository colludes.
One might object that the Vault Manager, which manages the encryption key, is a centralized component. But the Vault Manager only handles the encryption key, never the secret itself, so it cannot restore a private key on its own. And since the encryption key is likewise distributed across the repositories, a Vault Manager failure can be handled too.
[Reference] Visit the blog section of the official PARAMETA website ▼
Web3 Enabler, PARAMETA