Key Migration and Revocation

[braydonf]

This NIP defines a protocol for clients and relays to gracefully recovery from a compromised private key.

At a minimum this includes the revocation of a private key. Clients give warning that the key is compromised. Relays and clients reject future events from a revoked key and may delete existing events.

Also defined is a protocol for a user to be able to remember an associated public key for another user. In the event that a private key of the other user is compromised, the user is able to identity who it was and how to go about recovering from the compromise. This includes an ability to remember the original name, NIP-05 identification, website, migration keys and other associated metadata. Client implementations can provide various strategies to help that recovery, starting as simple as displaying that the key has been compromised.

Read in Full

[braydonf]

For those familiar with similar proposals by @pablof7z, @fiatjaf, @nvk and @vitorpamplona on the topic, I've written a summary of the differences.

In comparison with: #829

• This proposal doesn't rely upon a bitcoin protocol opentimestamp service, though it can be used as an option. Keeping a network consensus wide agreed upon order of events isn't mandatory, instead the client keeps track of the order and validity. This is done through attestations that are either private or public, and verified through a social graph for others. Migration is not automatic, however revocation can be automatic.
• "Whitelisting a pubkey" is similar to "Recovery Key Setup" in this proposal, however it also includes the ability to have multiple keys and assign m of n signatures to create a migration event later. Also as mentioned, a NIP-3 timestamp isn't required.
• "Migrating to a pubkey" is similar to "Key Migration and Revocation" in this proposal. The event can also be used purely to revoke a key without a successor key. The most minimal implementations SHOULD implement revocation. The 60-day wait isn't necessary for migration, this is determined by the user of the client based on information presented, which could include a time component.

In comparison with: #637

• This proposal is similar in that it includes both a simple revocation of a key and a social means to migrate by means of multiple keys and signatures. However instead of a predetermined set of friends (of which relationships could change in the future), a social graph of mutual friends, can be used to verify a migration. Attestations of a migration or backup keys setup can be made by mutual friends that will help others in determining the truth.
• The recommended switch of a new pubkey is done through attestations in this proposal, this applies to both a recovery key setup as well as migration events.
• Similarly there are safeguards made to prevent accidental events.

In comparison with: #1056

• This proposal is similar in that it uses a social graph as defense against an attack from a compromised private key.
• It differs in that it also includes an ability to provide recovery keys that can help to facilite the social verification of the migration of a key, though these are not required on other means can be used.
• Also, the event for migration of a key is also a revocation of the key and can just be a revocation. Revocation is verified using the event signature, migration is verified using several options and the user of the client decides.
• Similarly, ideas such as using Generic Reposts to help propogate migration and revocation events are also used.

This proposal is, more or less, a merger of all three of the above proposals.

[fiatjaf]

One thing that isn't clear is how this protects against an attacker stealing your key, then publishing a new recovery key event with an older date, then proceeding to do the key rotation with his own recovery key and now he owns your identity.

[braydonf]

If an attacker steals a private key and publishes a new and fraudulent Recovery Keys Setup Event with an older date, it can be detected as fraudulent by everyone that has published their own dated and signed copy in a Recover Keys Attestation Event of the previously seen and honest Recovery Keys Setup Event. Attestations can be either private or public, public attestations can help those that have not made such attestations to be able to detect if it is fraudulent (in addition to the other methods).

[pablof7z]

If an attacker steals a private key and publishes a new and fraudulent Recovery Keys Setup Event with an older date, it can be detected as fraudulent by everyone that has published their own dated and signed copy in a Recover Keys Attestation Event of the previously seen and honest Recovery Keys Setup Event. Attestations can be either private or public, public attestations can help those that have not made such attestations to be able to detect if it is fraudulent (in addition to the other methods).

You mean my client has to cache forever all fiatjaf's key setup event to try to ascertain time order?

[braydonf]

@pablof7z The Recovery Keys Attestation Event is saved on relays, for both private (encrypted) and public.

[nvk]

This might become an issue, relays are not designed to offer data relation guarantees

[pablof7z]

@pablof7z The Recovery Keys Attestation Event is saved on relays, for both private (encrypted) and public.

Ok, yeah, I assumed so, but how can OTS be optional, if you're not requesting clients to keep track of all setup events; how do you order by date?

[braydonf]

@nvk Can you clarify what you mean by "data relation guarantees" and how that is relevant?

[braydonf]

@pablof7z OTS is optional because ordering by date of all Recovery Keys Setup Events for a pubkey isn't necessary for determining which one is valid.

Here is an example:

• Bob creates 3 keys to be used for a recovery, and broadcasts a Recovery Keys Setup Event (2 of 3 keys).
• Alice follows Bob and makes a private Recovery Keys Attestation for Bob's Recovery Keys Setup Event. Both Bob and Alice have now signed the Recovery Keys Setup Event.
• An attacker steals Bob's private key and broadcasts a fraudulent Recovery Keys Setup Event with a different set of recovery keys.
• Alice sees this new Recovery Keys Setup Event event and can know that it fraudulent because she already has attested to a different one.

[nvk]

Sorry, autocorrect. "Retention"

[braydonf]

@nvk Okay, that makes more sense. Data retention by relays depends on the relay and the terms of service. Redundancy of relays, paid relays and private/personal relays all help to backup ALL notes and events. Some relays will delete older events to free disk space; in that process, it should be emphasized that relays SHOULD NOT delete Recovery Key Attestation Events and Key Migration Attestations Events.

[nvk]

@nvk Okay, that makes more sense. Data retention by relays depends on the relay and the terms of service. Redundancy of relays, paid relays and private/personal relays all help to backup ALL notes and events. Some relays will delete older events to free disk space; in that process, it should be emphasized that relays SHOULD NOT delete Recovery Key Attestation Events and Key Migration Attestations Events.

The problem is user expectations and guarantees,

[braydonf]

If anyone is interested in helping to implement in clients and relays and flush out details in the specification, please reach out to me! Thanks!

[braydonf]

@nvk If it is a problem, it would be for the Nostr protocol and all events; if events can disappear from all relays then Nostr isn't a censorship-resistant network!

[nvk]

@nvk If it is a problem, it would be for the Nostr protocol and all events; if events can disappear from all relays then Nostr isn't a censorship-resistant network!

Doesn't feel right, happy to be proven wrong. Also aside from the previous proposal I'm not sure I have any better ideas.

[vitorpamplona]

if events can disappear from all relays then Nostr isn't a censorship-resistant network!

They can and they do every day. Not your relay, not your data.

Nostr is a censorship resistant protocol, not network. It allows users to use backup relay networks at their will, but if they put everything in a single relay and that relay goes out of business, all their data is gone.

[pablof7z]

if events can disappear from all relays then Nostr isn't a censorship-resistant network!

They can and they do every day. Not your relay, not your data.

Nostr is a censorship resistant protocol, not network. It allows users to use backup relay networks at their will, but if they put everything in a single relay and that relay goes out of business, all their data is gone.

Ok, hear me out..

Nostr... but on a blockchain

MIC-DROPPED

[melvincarvalho]

IMHO better to use single use seals for the on-chain commitments, rather than OTS. Peter Todd made both OTS and single-use seals, in that order. I dont think I would implement this when single-use seals offers imho a vastly superior path to data, with history, audit trail, and recoverable profiles. No issues with clients opting into this, but I think it may lead to a fractured landscape of solutions (which itself is not the end of the world).

[melvincarvalho]

@nvk If it is a problem, it would be for the Nostr protocol and all events; if events can disappear from all relays then Nostr isn't a censorship-resistant network!

It's not a censorship-resistant network. Spam is censored all the time. Relays are not data stores, they just transmit notes, and other stuff, from one user, to another. If you want to store events, it is much better not to use nostr for that, but rather, the cloud, which was designed for storage, and has super mature tooling.

[mikedilger]

First, if I am Alice, how do I know that I should attest to Bob's key recovery setup event? Do I call him on the phone? Is it just because I have never seen one before? Because maybe an Imposter sends a second one, but that is the first one I have seen and so I attest to the wrong one.

Second, in your scenario Alice becomes aware of an imposter recovery key setup event. But how does the rest of the network learn? Most people don't follow Alice, and even if they could they don't trust her.

Third, what if Bob creates one and thinks it didn't work, so he creates a second one. Isn't he now seen as an attacker on himself?

[mikedilger]

if events can disappear from all relays then Nostr isn't a censorship-resistant network!

They don't have to disappear from ALL relays, just the ones I happen to talk to.

Nostr is censorship resistant only in so much as it doesn't have a single point of failure.

[Semisol]

If it is a problem, it would be for the Nostr protocol and all events; if events can disappear from all relays then Nostr isn't a censorship-resistant network!

"Censorship resistance" means that any entity attempting to censor you can be easily worked around (by starting your own relay).

The protocol has no guarantees about content retention, censorship, or availability of relays. The only guarantee you get is ones you create yourself (for example by using a paid relay like nostr.land, or hosting your own relay that you can hold your own notes forever on).

[braydonf]

First, if I am Alice, how do I know that I should attest to Bob's key recovery setup event? Do I call him on the phone? Is it just because I have never seen one before? Because maybe an Imposter sends a second one, but that is the first one I have seen and so I attest to the wrong one.

Second, in your scenario Alice becomes aware of an imposter recovery key setup event. But how does the rest of the network learn? Most people don't follow Alice, and even if they could they don't trust her.

Third, what if Bob creates one and thinks it didn't work, so he creates a second one. Isn't he now seen as an attacker on himself?

@mikedilger Great questions.

1. This specification doesn't specify how Alice determines which key is truthful, it does provide several ways to help to determine which one is honest (NIP-05 DNS identifiers, NIP-03 opentimestamps and attestations in this NIP). Offline and side-channel verification should be considered too! Especially if it's not clear and there are multiple key setup or key migration and revocation events.

2. Attestations from Alice will only be known and relevant to people who follow Alice. It would be important for there to be many attestations from different identities to have greater reach in different social graphs. This is a benefit, an attacker could try to create many false identities and make fraudulent attestations to a false recovery key, however if nobody follows these false identities (aside from the attacker), it has zero relevance.

3. If Bob accidentally (or willfully) creates multiple honest key setup events or key migration and revocation events then it will be important for him to communicate and help clarify which one is the honest one. In this case the NIP-03 opentimestamp would be less relevant and the NIP-05 DNS identifier would be more relevant. Furthermore, the more attestations there are from shared contacts for one over the other should also help. If all else fails, then falling back to offline or side-channel verification can and should be used.

[vitorpamplona]

I might be too dumb for these things but I don't feel very comfortable implementing this.

The reason I thought #1056 would be good is exactly because it didn't touch any of the key attestation and verification procedures. It just passed ALL that responsibility to users directly: "Nostr cannot help you. Relays and clients do not have the information you need. You need to pick up a phone and find person X to ask what is the new key they are going to use. And you cannot use Nostr for that. It's all on you."

Here, because there is a "nostr" way of doing it, an attacker can use any of these events to confuse users into believing a key is migrating. Because there are so many kinds, relay checks, clients with varying levels of compliance, replaceable events and all of which can happen in the past, present and future, with expiration and event deletions, in separate relays that don't talk to each other or relay that are fully controlled by the attacker, etc... it creates more problems than what it might solve.

Even with this, in the end, it boils down to Web of Trust. This PR just codifies that into a sequence of Nostr events that apps can verify without the User having to call a friend. That's the delta improvement here.

Is the complexity worth that delta? Are we safer in this procedure or just with kind 1 posts saying that I am migrating?

And can we expect Clients to implement all of this without bugs and in a UX that match each other to avoid further confusion and a potential form of attack?

I don't know... It might be that this NIP is trying to do too much.

[braydonf]

I've started implementing the events for this NIP in go-nostr and can be found at:

https://github.com/braydonf/go-nostr/tree/key-migration-and-revocation/nipxx

This NIP has been updated to reflect changes based from that implementation. Several clarifications and changes have been made.

[braydonf]

"Nostr cannot help you."

@vitorpamplona I think it can help. If someone that I follow has their private key compromised, I can still trust my own events.

As far as implementation, it helps me to better understand the problem and to discover a solution that I may not have previously seen.

For example, here are some things that I'm thinking about after my first round of implementation and will be addressing in another set of updates:

1. Is it necessary to have the Key Migration Attestation Event for a Key Migration and Revocation Event? This could be done, as similar to #1056 by changing the follow list (kind 3) and mute list (kind 10000). While it isn't codified as an attestation, it is functionally similar. It might be more simple to have an event for it rather than it being necessary to pull follow and mute lists. However, the best solution should clear up with further implementation.

2. In the event that a private key is compromised, the NIP-05 in the profile, the name, the profile image and etc are all likely to change to something evil. It may become nearly impossible to even remember who the original profile was, I certainly don't have npubs memorized. Therefore, I think the Recovery Keys Attestation is not quite enough and it needs to expand to be not only an attestation of the Recovery Keys, but an attestation of the profile name, NIP-05, domain, and other contact points, such that I can remember who the profile was before the key was compromised.

[braydonf]

I've made several simplifications and updates to this NIP and it feels much closer to a solution!

Next, I'll work on implementing it more in go-nostr and updating the UX design wireframes.

[braydonf]

Okay, here are some of the UX wireframes for secure identities, as now included in this NIP.

Link to animation:
https://raw.githubusercontent.com/braydonf/nostr-key-migration-and-revocation/89a9437e958f44bf748f145b85e603d83cf7ef2f/graphics/ux-storyboard-animation.webp

[braydonf]

I've realized that the user metadata attestation portion of his drafted NIP can have a lot of other uses beyond the scope defined in this NIP and have separated it into another (see #1499). I will leave this NIP, as drafted, for the time being.

The remaining portions, the revocation piece can likely merge with @vitorpamplona #1056. It would rename it Key Revocation and not Key Migration (and mostly leave out the migration/transfer portion). The migration keys part can be another NIP of it's own that can define the scheme for pubkeys on a user's metadata and methods to verify them.

[vitorpamplona]

Yeah I think that is a good move. I updated the text on #1056 to match the revocation ideas from here.

[braydonf]

Cool, sounds good.

I'm convinced this will all work and would like to go through and document how in more detail. Various scenarios and attacks can be enumerated and how each is mitigated. This should also help to find any issues, if they remain.

Implementation seems fairly straight forward so far, I don't foresee any issues here. It'll still be useful to explore to uncover anything unexpected in both clients and relays, that can likely follow.

[kehiy]

some small changes. makes everything look better.