Protected Recovery Phrases: Plan and Progress

internet-identity
17

Team,

Let’s start with an alignment:

  • The problem is that an attacker can add or remove any and all devices from a compromised anchor
  • @dostro, @Litzi, and myself from the Internet Identity Labs team and @lastmjs from the Demergent Labs team collaborated on solutions and decided to propose we start with a fix for the most phishable attack vector, the recovery phrase
  • The reason we chose to start specifically with the recovery phrase is because we believe this is the most harmful attack surface, given that it’s the most phishable, and that incremental iteration will generally help make faster and more informed decisions for future improvements

The worst case scenario for a compromised anchor is that the final recovery method, typically the recovery phrase, is removed by an attacker, leaving no opportunity for the anchor owner to recover.

Therefore we propose 3 branches for your review, each implementing a different approach to support a method of protecting the recovery phrase from removal by anyone that doesn’t know it:

  1. GitHub PR to Add new KeyType
  2. GitHub PR for an Optional ProtectionType in DeviceData type
  3. (Our recommendation) GitHub PR for Optional list of Tags in DeviceData type

The flow for each is generally the same:

  • In the remove method, read information about the device being removed
  • If the device is a protected recovery phrase, make sure the recovery phrase the user submitted matches
  • Trap if no match and return without removing the recovery phrase

One important note: Fixing this attack vector still leaves one open that an attacker could add a protected recovery phrase from a different compromised device, even if the anchor already has a protected recovery phrase. We could restrict only 1 protected recovery phrase per anchor in this fix if you all think we should.

1. Add new KeyType

The KeyType enum currently has the following 4 options:

  1. Unknown
  2. Platform
  3. CrossPlatform
  4. SeedPhrase

We propose in this option to add a 5th option for SeedPhraseProtected to differentiate between protected and unprotected recovery phrases.

Strengths

  • A clean implementation with minimal complexity
  • Minimal memory management overhead

Weaknesses

  • This does add another KeyType that needs management down the line, should KeyType undergo a migration (though we’re not aware of any such plans)

Opportunities

  • None besides the immediate feature implementation

Threats

  • None that we’ve identified

2. Optional ProtectionType in DeviceData type

@paulyoung suggested adding a new enum that we implemented as an optional variable to the DeviceData type that could store information about this key being a protected recovery phrase.

Strengths

  • Simple rollback

Weaknesses

  • The DeviceData type will include an additional optional field, which increases state by more than necessary given that only a fraction of devices will need it

Opportunities

  • Possibility to add additional ProtectionTypes in the future

Threats

  • None that we’ve identified

3. (Our recommendation) Optional list of Tags in DeviceData type

Iterating on the 2nd option, the field we add to DeviceData could be a list of Tags as metadata for the device. Not only could it be used to protect the recovery phrase, but it could be used to protect any device, set different administrative permissions per device, and generally add substantial flexibility

Strengths

  • Simple rollback
  • Generalized, reusable solution to make devices more flexible

Weaknesses

  • Such a generalized solution might influence future feature implementations to leverage this rather than a potentially more appropriate, scaleable, harder-to-implement solution

Opportunities

  • As @frederikrothenberger reminded us about @timo’s previous suggestion, this is one way to set different administrative permissions per device so that only devices with the Admin Tag, for example, are able to add/remove devices, Superadmin to add/remove recovery phrases, TxApprover for devices capable of approving transactions, etc, etc

Threats

  • Currently, we’re scoping the reading of the Protected Tag only on removal of a seed phrase because attackers might be able to add their own protected devices, and until there’s a UI for administrative control, we should be more cautious with this feature.

The threat for option 3 requires a more thoughtful approach to the UI in the medium term so that users can configure which devices can add other high-permission devices, but unless Dfinity has medium-term plans to extend device functionality in these ways we believe this enables a highly flexible design space for future feature implementations at low cost.

6 Likes