Key Roll-over: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Full Title or Meme==
==Full Title or Meme==
Whenever user secrets, like prive keys of a cryptographic key pair need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticaling user access to their proporerty.
Whenever user secrets, like the private keys of a cryptographic key pair, need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticatiing user access to their property.


==Context==
==Context==
Line 24: Line 24:


Any others???
Any others???
===Call for full solutions===
These two efforts are just the beginning of DIF’s work in the area of secret retention and recovery. Any interested party is encouraged to contribute their ideas, code, and insights to this vital work. For more information about participating in this new initiative, and the DIF I&D WG in general, view its Meeting Page, read the group’s Charter, and join DIF!


==References==
==References==
* The wiki page [[
* The wiki page [[Cryptographic Secret Recovery]] deals the one use case for [[Key Roll-over]]


[[Category:Authentication]]
[[Category:Authentication]]
[[Category:Recovery]]
[[Category:Recovery]]

Latest revision as of 01:58, 4 June 2020

Full Title or Meme

Whenever user secrets, like the private keys of a cryptographic key pair, need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticatiing user access to their property.

Context

Any viable Identity Management architecture must address secrets or private key management used in user authentication.

  • In a centralized Identity Management architecture the identifier is created by the IdP and so that IdP can handel recovery entirely within their own organization. Some do it well.
  • In a decentralized Identity Management architecture individuals, organizations, and things create and manage their own cryptographic keys without reliance on a central authority or intermediary other than a pointer to the method used for resolving identifiers into public keys that can be used for authentication purposes.
  • In a distributed Identity Management architecture the identifiers do not come with any built in resolution to any kind of resolver and so have full responsibility for any recovery of loss of access to identifiers.

Note that several existing systems that have addressed this problem include:

  1. Microsoft Bit Locker disk drive encryption
  2. Android Key Vault in version 9 and later.
  3. Key fobs used since 1980's and extending to USB U2F and Web Authentication devices.
  4. Slack provisioning user with a page of Two-factor authentication backup codes.

Problems

  • When a user is in control of creating their own identifiers then they have the power to wield private keys that control DIDs, they can also lose everything connected to those DIDs if they can’t retain and secure them.
  • By definition, in a decentralized identity system, there is no centralized service to provide an “I forgot my password” button.

That is the starting condition. It is certainly possible to build safeguards and recovery mechanisms into a decentralized identity system.

Solutions

  • Recovery mechanisms can be as simple as creating a backup of a wallet that holds cryptographic keys or writing down a seed number on a piece of paper.
  • Many key recovery techniques that are popular in the cryptocurrency community can also be applied to decentralized identity. Some of the better-known approaches are mnemonic seed phrases or Shamir’s Secret Sharing algorithm.
  • In general solutions will take something the user knows and use that to recover control of the identifier, for example by doing a Key Roll-over or reload into a user device.

Any others???

References