The following document is an extract from Magic Crystal, which describes how to leverage social secret sharing with Dark Crystal using Magic Wormhole for identity-less transport without using any Public Key Infrastructure. The document also includes a protocol design for developers wanting to integrate this feature into their application. It was developed by Least Authority and Dark Crystal. The full text can be viewed here.
Motivation
Many applications have some important data, such as private keys or cloud access credentials, that need to be kept secure and safe: such data should not be accessible to third parties, but it should be accessible to the user when needed, as it is required to recover access to the service in question.
Dark Crystal provides a way to back up such data using social connections: the data is split into several pieces (called “Shards”) and distributed among trusted peers (called “Custodians”). This is achieved using a scheme essentially based on Shamir’s Secret Sharing.
Dark Crystal is transport agnostic, meaning that it can be used in combination with any transfer/communication mechanisms. In addition, using Dark Crystal requires a public-key infrastructure (PKI) of the users’ choice.
The transfer mechanism used in this document is Magic Wormhole, a tool for connecting two computers on the Internet via human-transcribed one-time codes (LeastAuthority released desktop and mobile applications (called Destiny) and a Web-based UI (called Winden) for Magic Wormhole).
Magic Wormhole relies on the assumption that the two humans in charge of the two computers can communicate with each other either in person, on the phone, or via some messaging service (that is, via some “reasonably secure” channel).
We describe a generic application that can backup and restore arbitrary secret data. That said, it should have certain characteristics for this to be most useful. The data should be:
- “one-time” (or rarely) produced;
- “relatively small” (see Discussion); and
- self-contained.
Some examples of this:
- the seed / private key of a cryptocurrency wallet;
- credentials and access information for a cloud service (e.g. backup);
- confidential/sensitive information; and
- information identifying members of human rights organizations (HROs) in authoritarian countries.
The main idea is that the user doing the backup has either lost access to their computer (e.g. it fell into the ocean), or the need to delete the data from their own hardware in cases when it could be seized by hostile parties (e.g. authoritarian governments, police raids, border crossing).
Now, given a new computer and a fresh instance of the application, they can contact some subset of the Custodians keeping Shards and thereby restore access. Note that, in the interests of simplicity, we choose not to encrypt the secret data, so a sufficiently large subset of Custodians can conspire to restore access. This feature can be useful for example in estate planning. It also means there’s no “passphrase” or similar for the user to remember; the only thing they need to do is to re-contact some number of the Custodians. Another use-case for such a feature is continuity for e.g. human-rights organizations with sensitive information that should be recoverable only when a certain number of members agree.
Why Dark Crystal?
Encrypting files and messages provides a high level of protection from data being compromised. However, many people forgo using encryption because they are worried that losing their encryption keys will result in them losing access to their data.
Dark Crystal aims to solve this problem by providing a set of protocols that enable users to split their data into Shards and then distribute these shards to a set of their trusted peers (Custodians). It is not possible to reconstruct the original secret from a single Shard, so the secret remains protected if a Shard is compromised. On the other hand, a subset of Shards is enough to recover the original secret, so the owner’s access to the secret is preserved even if a shard is lost.
See the Dark Crystal documentation for more details about the challenges of adopting encryption methods and potential use cases for secret sharing with Dark Crystal.
Why Magic Wormhole?
Dark Crystal does not specify a transport mechanism for distributing the shards between Custodians. This means that Custodians either need to sign up for a specific service (like Secure Scuttlebutt) for securely distributing the shards, or resort to less secure methods such as email or instant messaging. The latter channels also have the disadvantage that the data is stored on the service provider’s servers, increasing the risk of it being compromised.
Magic Wormhole provides secure data transfer directly between two computers, without storing the secret on third-party servers. Integrating Magic Wormhole and Dark Crystal provides a secure transport mechanism without the need for the Custodians to sign up for a secure transport service or use less secure channels. While Magic Wormhole still relies on an external communication channel (e.g. email, instant messaging or voice) to relay the wormhole code, both the likelihood and the negative consequences of this code being compromised are minimal compared to the secret itself being shared on one of these channels.
A further advantage of Magic Wormhole is that it is identity-less, meaning that the participants do not need to supply personal information or obtain access credentials to complete the transfer. Dark Crystal relies on the Owner and the Custodians using a PKI of their choice, which means that public/private keys are assigned to (partially) identified individuals.
Magic Wormhole relies on low-entropy, human-memorable codes to perform a PAKE (Password Authenticated Key Exchange). These are made secure because only one guess may be used per code; if that one guess is an attacker, then the legitimate users know that code is destroyed. A “brute force” attack thus involves convincing two humans to relay dozens or thousands of codes. This isn’t a full security argument; please see the Magic Wormhole documentation for more.
The basic premise of Dark Crystal is that the secret owner trusts their Custodians, presumably implying that they know at least some aspects of their identity, so being identifiable by the public/private keys might not be much of a disadvantage. That said, one advantage of using Magic Wormhole is that the parties do not need to disclose any identifiable information to any other parties.
Perhaps more importantly, doing away with the need for a PKI could remove adoption barriers for less tech-savvy users, as it simplifies the list of technical requirements for Custodians.
Protocol design
In this document, we imagine and describe a generic stand-alone application that could, in principle, be used to socially back up any secret. That said, our description should still be useful for application developers wanting to integrate this feature into their application.
Optionally, the Custodians can use a browser-based client with no installation or configuration beforehand, making it a realistic option for non-technical users. This overcomes many of the usability issues with peer-to-peer protocols.
The data to be backed up should be fairly “static”, as the backup operation consumes human time, network bandwidth and storage resources.
While any amount of data could be shared in this fashion, we imagine such data is a “reasonably small” amount by modern standards. (see Discussion).
Continue reading the rest of the text here.