Introduction to DeepKey

tags: deepkey documentation

Because DeepKey will be so tightly integrated with so many hApps and the Holochain core, we want it to be as stable as possible. Therefore we want to keep its scope tight and clear. It needs to serve two main purposes:

1. Provide the PUBLIC infrastructure for managing keys
2. Enable users to unify agency across their devices

Managing Keys

In cryptographic systems, keys are the primary means of signaling authority and identity. In other words, you interpret something as provably coming from an agent if they signed it with their private (signing) key and they are the right person to read it if they can decrypt it with their private (encryption) key.

So cryptogaphically speaking, key=agent and posession of a private key is functional agency.

However, that is not how the world of humans works. People are not (yet) good at managing keys responsibly. Many billions of dollars in cryptocurrencies have been lost, because people have lost their keys, and they have no means of replacing them.

DeepKey solves that problem in the Holochain space. The basic functions it must perform are:

1. publish keys (CreateEntry)
2. replace keys (UpdateEntry)
3. revoke keys (DeleteEntry)

Use case 1 – lost keys:

Alice runs a number of hApps on her laptop. The laptop harddrive has become corrupted and she needs a deterministic way to to regenerate her keys so she doesn't lose access/control/ownership of her data, identity, currencies, etc.

Heirarchal Deterministic Keys

The above use case with Alice shows the need to have a consistent way of generating keys, so that we can regenerate them when lost.

For this we can use a master seed, and record (privately) the derivations used to generate keys.

Use case 2 – stolen keys:

Bob has some hApps he runs on his phone, including HoloFuel. His phone has been stolen, and he wants to prevent anyone from being able to act as him in his hApps or spend his HoloFuel.

Note: Technically, without DeepKey and just native Holochain, you could sign a new agent key to your source chain using your old one. While it does allow you ot replace a key, unfortunately, it doesn't solve either of the above use cases. Quite the opposite, it could allow the person who stole Bob's phone to replace the keys, locking Bob out.

Publishing Keys

Replacing or Revoking Keys

Unifying Agency Across Devices

The second purpose of DeepKey deals with the fact that humans have more than one device which each should, for securities sake, have different cryptographic keys. Thus there needs to be a way to unify human agency in the context of multiple cryptographic agency.

Use case 3 – self-trust across multiple devices:

Implementation Overview:

To deliver on the basics of Distributed Public Key Infrastructure (DPKI), we need a way to generate keys of various types (revocation, identity, encryption, signing) from seeds, and we need to be able to generate such seeds from primary seeds, so that a human agent can create related "device agents" provably under their control.

After studying a number of uses cases, including initial sign-up, key revocation, etc, the central insight we came to was the need to create a Hierarchical Deterministic Key generation system, based on a Primary Seed, from which additional seeds can be generated which then are in turn used to actually generate many key-pairs. This allows us, by-convention, to use the first seed generated by the Primary seed as the seed for revocation keys, and subsequent seeds as seeds for keys of separate Holochain devices that can be proven to be under the control of the holder of Primary Seed.

[WIP] Status:

Current Features:

• dpki_init
• create_new_agent
• is_initialized
• Need to follow derivation process
  • Generate Root Key
  • Generate Revocation Key
  • Generate Authorizor Key
  • Sign your Authorizor Key with you Revocation Key

What Does the DNA do Currently:

• Expects you to initialized
  • pass in the revocation pub key and a signed auth key with your revocation key.
  • This registers the KeyRootSet