Try   HackMD

DPKI - Distributed Public Keys

Key Management // Identity and Identity Recovery

First piece of three Holochain identity services.

  1. DPKI does key management for actually ensuring continuity of control of your keys and source chain.
  2. Personas lets you control your identity data and provide profile mappings to allow selective and revokable access to your data
  3. Validation/Assertions/Trust Graph enables collection of third party validation or assertions about identity and reputation.

User Seed and Key Generation

Registration of User Seed and Master Keys on the DPKI (occurs during Holochain Installation):

Types of Seeds:

  • Revocation Seed (RevSeed)
  • Generator Seed (GenSeed, Master ID Seed)

Levels of Keys:

  • Revocation Keys : Directly created from the RevSeed
UserDPKIHIP44User Local ChainDHTUserDPKIHIP44User Local ChainDHTStore Master Keys in the local chainRequest RegistrationgenEntropy()Request PasswordgenPassword()Provide PasswordgenRevSeedMnemonic(entropy) (24 words)genRevSeed(password, mnemonic)Returns RevSeed and RevSeedMnemonicmakeHash(RevSeedMnemonic)pick word from RevSeedHash via moduloProvides RevocationSeedMnemonic to UsergenIdMasterSeed(revocationSeed)Returns IdMasterSeeds(revocationSeed)Store IdMasterSeeds(revocationSeed)genIdKeys(app)Returns Public Keys for appPublish Public Key and to DHT (Header)

Registration of new dApp on the DPKI

Decision to be made:

  • Where and when is the registration called ?
    • During app installation
      • Will need to work with core
    • After app installation :
      • Passing parameters
dAppDPKIHIP44dAppDPKIHIP44if the dApp_Type is registered check if the APP_Account is registered too. if not create a new APP_Account. if the app is not registered create a new dApp_TypeRequest to register(APP.DNA.HASH,dApp.Agent.HASH)registration(APP.DNA.HASH,dApp.Agent.HASH)registerApp()

Types of Package(s):

  • HIP44: This is our cryptography tool package for generating RevSeeds and GenSeeds and their corresponding Priv/Pub. Key Pairs.

Gossip Identity Verification Process:

Primary Revocation Key (48 words) >> generate 1.) Master Revocation Key and 2.) Master Identity Seeds ("GenSeeds", of 12 words each)

Set a Revocation Method for each particular key.
Updating Key Revocation method.

  • For any change in the revocation

Instructions on how to choose ppl.

  • Email,
  • Call,
  • Skype, etc.

N(M) Process:

  • M friends are asked to sign the user's identity (their agent key)
  • At the time of the revocation, user contacts the M friends to request the revocation
  • At least N(M) friends then need to create revocation request to the user's DPKI
  • Once N(M) friend hashs/agent keys have been received (that match the M number who originally signed the agreement to be the M users and attest to the user's identity at the time of the N(M) request) then new keys generated and pointed assigned.

Indentification Process

Need :

​​​​To verify if the Agent is the same as the agen on the other app
  • verifyAgents()
  • valadateAgent()
AppDPKIAppDPKI

Other notes on Identity:

Revoking a Key

Lost Key

Compromised Key

Getting a new Key

Explained: Using a key in HoloChat

DPKI Components

  • Revocation/Acceptance of new keys
    • Select Default Method:
      • Rev Key / Rev Authority / M of N Sigs
DPKI_DNADPKI_UIAppDNAAppUIDPKI_DNADPKI_UIAppDNAAppUId

  • Override default method for a specific app

  • Bridging from/to a holochain app

    • Register a public DPKI key in ID string for an app
    • Proof of control of private key:
      • Run DPKI locally
      • get(PubKeyHash) via DPKI API bridge to get the full key
      • Encrypt(message, key)
      • Bridge Call to DPKI with result=echo(encryptedMessage)
      • check result =initial message before encryption
NewAppKeyMgtAppUserNewAppKeyMgtAppUser{"KeyMgtApp":"KeyMgtApp.App.DNA.Hash", "KeyRevocationAuth": KeyMgtApp.App.Key.Hash}Stored as AgentId in chain and dhtIn Genesis code of NewApp call bridge to getGenesisPublicKey(). Uses KeyMgtApp App.Key.HashDefault Revocation method stored in KeyMgtAppMessage is signed using private keyError: "Invalid KeyMgtApp Key. Cannot confirm control of correlated private key."ask for KeyMgtApp.App.Key.HashKeyMgtApp.App.Key.HashInitialiseGet Public KeyPublic KeyGet default Revocation Method (linked from pubkey hash)Replies with Signed message or false if no default methodIf false or if verifySignature(message,signature,pubkey) fails, throw error/return false in genesis

  • Unify identities across devices

  • Bind to HC identity services

  • "Proof" of key control across HC apps

  • Hold/reveal Assertions/Claims/Fields

  • Seed & HD keys

  • "Proof" of legacy identity services (email, FB, Twitter, github, google, phone, etc.)

  • OAuth provider for legacy web

Notes from the meeting (29/6)

We discussed the importance of user experience and how a well designed process can ensure the majority of users has good security and recovery protocols set up be default.

(node damaged or destroyed)
To do this we imagined using a key generation algorithm (BIP39?). This would allow a user to securely record and store a key phrase which can be used to regenerate their public/private key pairs. This would allow a user who lost their private key to recover it and resume using their apps.

(node stolen by bad agent)
It was discussed that this same key phrase could be used to generate revocation key pairs stored inside DPKI. This would allow a user posessing the key phrase to not only recover their app private keys but also revoke them to prevent a bad agent in possession of their device from permanently taking controll.

Finally we considered how to structure the communications between DPKI and a users apps. The main concern was that if a bad agent were to temporally take control of a users node they could use DPKI to discover all the apps which they are a part of. (Art explained why this is a bad scenario).

If the bridging calls go from DPKI to the peripheral dApps this makes it much easier to revoke all keys in the case of a compromise. It has the downside of revealing all apps that are bridged.

The alternative is that apps bridge TO DPKI. In this case a user must activate revokation from within all their apps, potentially 100s, but means their existance would not be revealed if DPKI was exposed.

Another option we partially explored is using multiple instances of DPKI (with different keys generated from the seed phrase) to bridge to different apps thus limiting the potential information a hacker could gain.

How to make the DPKI Experience More Friendly ?

( How to make Key managemnet compatable with humans ? How to make the user experience Smooth ? )

  • Install Holochain
  • Push an option to to convince the user to set up the revocation key and revocation method (Leave 1 i.e. self revocation method).
  • Give the options of MofN when they have friends (Level 2)
  • Use tools that are know to people Like (Creating Seeds) to make it seem relatable and easy to understand
  • Use the Revocation key Seed to get the Revocation method Seed So that it has better security and less seed for the user to hold

After the revocation (How can you change the Keys ?)

NOTE : We don't send the private key over the wire.

  • Can't pass the keys over the wire ?
  • Have the installer hcd get the new keys and Install the app

How to Sync Two same apps are the same person

  • ??
  • KeyGen should be a System level function (So you dont have to generate and then pass it over the wire)

Other random things I remember

  • Membranes based on level of security/recover implemented
  • M choose N would be a good way to incentivise users to get their peers to install Holochain
  • Revocation private keys could be generated and stored in existing hardware wallets that follow the BIP39 standard

Notes from the meeting (3/7)

Had more clarification on the proposed ADR for Identity and Key Management

Last changed by 
 
Philip Beadle
0
2555
Published on HackMD