The following examples build from usages of the legacy CSR system to a more comprehensive example that demonstrates the differences possible with CKM.

Legacy CSR Architectural Use Cases

The following use case focus on legacy approaches that are rooted in CSR: keys are usually generated and then stored by traditional means, though additional security could offered by CKM (see below).

#1. Digital Union. Connell has NFTs on Bitmark, Tezos, and Ethereum that he wishes to unite. He brings together their keys in a single Gordian Envelope, which he stores with UCLA and SF-MOMA as key managers. He can now feel confident that he won’t lose them even if he loses access to his own copy of the envelope. [encryption.]

#2. Liability Insurance. Ned’s Nifty NFT Co. holds custody of its customers’ NFTs, which means that a single security breach could cause immense loss. Ned reduces his liability by moving all of his customers over to CSR. Though he still holds one Gordian Envelope for them, it’s not enough to cause loss, since another Gordian Envelope would be required, with his 2 of 3 VSS setup. [2-of-3 sharding.]

Note that though this use case imagines a simple 2-of-3 setup, it is more likely that sophisticated quorums will be used, with a mix of hardware, social, and networked shared keys, to meet the needs of the user.

#3. Monkey Business. Bruce has a very expensive Bored Ape NFT. He secures it with a master key spun off of a seed he keeps in a Gordian Envelope. He keeps other NFTs on other keys generated by that seed, which prevents them from being correlated, which might otherwise make his entire collection, and even his cryptocurrencies, a target. [multiple key generation.]

#4. Identity Insurance. Vince has used his SCID as the source of trust for an NFT art business. When Ned’s Nifty NFT Co. has a security breach, Vince realizes that either of his other Gordian Envelopes now represents a SPOC for his system, so resets his use of the CKM system with new keys. In the process, he also needs to rotate his SCID. [key rotation, SCID.]

Also see CSR Use Cases for legacy CSR Use Cases that slowly shade into CKM usage.

Full Architecture Example: CSR & CSM Hybrid Use Cases

The following offers a more precise example of the extent of a legacy CSR system, where keys are generated outside of the system and then secured by CKM. A hybrid system like this would come into use if a user did not want to move his current NFTs (or other digital assets), but wanted to improve their resilience with CKM.

  • Bob owns an Ethereum key that holds considerable value, including several NFTs of historic significance.
  • Bob also holds a Tezos key with additional NFTs.
  • Bob places those keys as well as related metadata as the payload of a Gordian Envelope.
  • Bob uses CKM to collaboratively generate a new key with the aid of Feral File and the MOMA.
  • The private key of the key pair is used to lock the Gordian Envelope holding Bob’s keys and data.
  • The public key of the key pair is signed by the private key to generate a SCID.
  • The key is sharded into three parts using VSS, any two of which can reconstruct the envelope’s permit key.
    • For a more modern system, the individual systems would maintain their secrets to regenerate the key whenever was necessary using SMPC.
  • Three Gordian Envelopes are created, each containing the payload data as well as one of the three VSS shares. They are held by Bob, by Feral File, and by MOMA.
  • Any two Gordian Envelopes can be brought together to restore the permit key and thus unlock the payload containing the Ethereum key, the Tezos key, and the metadata. This is done whenever Bob wishes to manipulate his digital assets.
  • If one Gordian Envelope is lost or stolen, there is no immediate threat to Bob’s holdings, dramatically reducing liability for Feral File and MOMA as key holders. However, Bob should obviously rotate his data into a new Gordian Envelope with a newly generated key if that occurs, destroying all old shares afterward.
  • Bob uses his SCID to make verifiable claims that he is the owner of the artwork.

Full Architecture Example: Full CKM System Use Case

The following offers a different precise example that is entirely rooted in CKM.

  • Bob prepares an address for storing his NFTs by activating a Collaborative Key Generation system.
  • Bob chooses three SMPC Systems to generate his keys: his home system, Feral File, and Nifty NFT. The latter two have an in-kind agreement. Since Bob is working with Feral File, that means he gets the Nifty NFT Secret Server for free and knows that Feral File considers them reliable.
  • The three servers use their individual secrets to generate a Feral File key. Bob moves his Feral File NFTs there.
  • Bob later decides to move an NFT across Feral File’s Ethereum Bridge. The three servers again use their individual secrets and this time generate an Ethereum key. Bob then moves one Feral File NFT across the Bridge to that new address.
  • Notably, none of the servers has the full secret underlying the keys. In fact, since all that’s happened to date is the transferring of NFTs to addresses, nothing but a public key has even been generated: the private key has never been held by any individual server on the internet, creating powerful proof against compromise.
  • As he grows increasingly confident with the system, Bob generates other keys, for Tezos, for Signal, for the signing of Apple Apps, for SSH, and for other purposes.
  • Bob also stores data in Gordian Envelopes, with the keys again generated by the Collaborative Key Generation system. Bob keeps the only copies of these, but considers going to a value-add NFT service such as Vicki’s Vault to ensure the encrypted data is backed up too. Maybe in the future, depending on what he needs to store.
  • When Bob upgrades his computer, he manages to lose the secret held by his home machine because it was specially protected and so needed to be migrated by hand. (He forgot to do so.) No problem, his keys can be generated by any two of the three servers.
  • With just two key-generating secrets left, Bob is now vulnerable to SPOFs. He thus has his new home computer work with the Feral File and Nifty NFT servers to generate a series of new keys. He then migrates his various assets and services to the new keys he’s created.