nsecBunker: Your Nostr Keys Management Fortress

The Problem

Key delegation has been a hot topic in the Nostr community for ages now. Even though Nostr is a new protocol, things are moving so fast that it feels like it's been years since it was launched. If you think about it in terms of regular social media, it's easy to see why this feature is so important. It's like being able to give someone the keys to your house but still being the one who's in charge. A good example of this is how nsecBunker is helping run a shared Nostr account. But that's just one use case. There are a lot more possibilities, and we're going to discuss some of them in this post.

Legacy solutions

The centralized nature of many platforms simplifies the problem of key management. Social media platforms like Facebook Business Manager, Twitter Business, and LinkedIn Pages offer built-in tools for delegating roles to team members without divulging original login credentials. Third-party platforms like Hootsuite, Buffer, and Sprout Social further streamline this process, enabling management of multiple accounts, scheduling posts, and assigning roles, all without compromising the security of original credentials.

For more technical solutions there are services like Amazon Key Management Service (KMS). KMS helps generate, control, and manage cryptographic keys used for data encryption. With KMS, you can create Customer Master Keys (CMKs), define usage policies, and set up automatic yearly rotation. When data is encrypted, KMS generates a data key, encrypts it with the CMK, and provides you with both plaintext and encrypted versions of the data key. The plaintext key is used for data encryption, then discarded, leaving only the encrypted data key. To decrypt, the encrypted data key is sent back to KMS, which decrypts it into plaintext, given the necessary permissions. This system is employed by many businesses and media outlets to ensure secure access and compliance.

However, while these traditional systems are robust, they leave the end-user dependent on the service provider, who retains the ability to revoke access at their discretion. And this is precisely the problem Nostr is trying to fix.

The Nostr Way

The First Attempt

The first attempt that received serious attention in this direction was NIP-26. It introduced a new 'delegation' tag that enables events to be delegated and signed by other keypairs. This proposal is meant to abstract the use of 'root' keypairs when interacting with clients, with the idea that a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root public key, where the root keypair is stored in cold storage.

However, NIP-26 has been critiqued for its implications on key management. Arguably, the best explanation of the corresponding problems was layed out by in his "Why I don't like NIP-26 as a solution for key management" post here. Initially, NIP-26 was praised for its optional nature. However, as NIP-26 began to be seen as a universal solution for key management on Nostr, it started to raise concerns. The concept entailed users generating a secure, offline key to sign delegation tags for each Nostr app, potentially rotating them periodically. This approach would make these keys "faceless entities" only identifiable by their master key, significantly changing the user experience and expectations from NIP-26.

This shift in approach would effectively render NIP-26 mandatory for usability, turning it from an optional enhancement to a necessary implementation for clients. This would remove the flexibility of choice and potentially complicate the protocol. Furthermore, while NIP-26 could provide some solutions in the realm of key management, it's not seen as a comprehensive solution. It's suggested that a multitude of key management methods could be more effective, maintaining the optional nature and possibly presenting a more elegant solution. There's an argument that if a mandatory key delegation method is indeed necessary for Nostr, an alternative design might be more optimized and easier to implement than NIP-26.

The Promising Alternative

NIP-26, while a noteworthy attempt, seemed to diverge from the core philosophy of Nostr. This discrepancy highlighted the need for an alternative solution that would respect this foundational principle and avoid precipitating Nostr down a slippery slope of mandatory adherence.

This is where nsecBunker, introduced by , provides a compelling proposition. As the name suggests, nsecBunker enables users to establish and self-host their own bunker allowing them to manage Nostr keys. This Bunker can communicate with the user interface on your device, facilitating the creation of target keys, sharing them with corresponding Nostr users, and offering granular control over their interactions with the protocol.

Crucially, the implementation of nsecBunker does not necessitate significant changes in the builds of existing clients, preserving the opt-in nature of Nostr. Beyond adhering to Nostr's core principles, nsecBunker also holds potential to enhance user experiences and provide improved functionality, aspects I will elaborate on shortly.

How Does This Work?

elaborates on the core concept behind nsecBunker:

At a high level, this model bears similarities to the traditional Amazon KMS approach, albeit with certain distinct nuances. For a deep dive into the technical intricacies of this model, I recommend checking out 's work-in-progress SECURITY-MODEL.md on GitHub.

To put it simply, nsecBunker is a daemon that facilitates remote event signing. It operates with two types of keys: user keys and nsecBunker keys. The bunker key interacts with the admin UI and only communicates with the pre-defined (admin) npub. Notably, this key doesn't store sensitive information or hold specific power -- it poses no threat to key material even if compromised.

The user key, on the other hand, is used for signing purposes. These keys are encrypted with a passphrase following the same approach as LND. This passphrase is mandatory every time nsecBunker is initiated, and losing it equates to losing access to the keys.

During setup, the administrator pre-approves a key (or a set of keys) for communication with the nsecBunker. The administrator(s) then create target keys to distribute to the intended users. These users can interact with the Nostr infrastructure without ever accessing the private keys of the account they're using. Let's walk through the process of setting up a Bunker.

Running nsecBunker

Paid Subscription

The easiest way to run nsecBunker is to purchase a paid subscription. The process is very easy and intuitive and, thanks to Lightning Network, it does not require you to share any sensitive data, such as IDs or bank card details. Scan a lightning invoice and get access to your own bunker in seconds:

Navigate to https://app.nsecbunker.com/ and press “Buy one here”:

Click “Next”

Paste your public key (or a few keys) you’d like to be in control of the target keys. The keys you’ll specify will be able to grant full or granular permission to target keys which, in turn, will be able to post on behalf of the admin account. The admin key will be able to, but have to be the same key that you’ll be signing as later on. This means that you will be able to create a target key to interact with Nostr and have it look like your account is the one that is logging in / posting / liking / etc., or a totally separate target key, which will be like a child account of yours, and won’t be linked to you for the outside world.

Specify how many users you’d like to be able to sign Nostr events with the Bunker you are creating. The number of end users directly affects the yearly fee rate.

Pay the lightning invoice

That’s it – your keys management fortress is ready to be utilized.

Here's a quick demo on setting up and using your nsecBunker by :

Alternatively, if you are confident in your tech skills, you can build your own nsecBunker. It’s an open source project, meaning that anyone can spin up their own version.

Docker setup

To quickly install nsecBunker via Docker run:

docker run -d --name nsecbunkerd pablof7z/nsecbunkerd start --admin <your-npub>

nsecBunker will give you a connection string like:

bunker://npub1tj2dmc4udvgafxxxxxxxrtgne8j8l6rgrnaykzc8sys9mzfcz@relay.nsecbunker.com

Visit https://app.nsecbunker.com/ to administrate your nsecBunker remotely. For details see the GitHub repository here.

Setting up your Connection

After procuring the string, navigate to https://app.nsecbunker.com/. Log in using your preferred NIP-07 browser extension. Ensure the Nostr account (nsec) you're using is the same one that is designated as the administrator. The bunker is designed in such a way that it will not reply or even recognize if anyone other than the administrator npub is trying to communicate with it.

Input the connection string into the required field and hit 'Login'.

As you can see, I left my connection string visible in the screenshot above. This is to showcase that it doesn't require protection and is simply a way of connecting to your bunker. The security model here relies on your npub being the only entity with an administrative account.

You'll land on the following screen:

Click the "Keys'' tab. If you see a "Loading" message under the "Keys" title, simply refresh the page, and you should see the "No keys created yet" message.

If after clicking the "Keys" tab button you do not see the "No keys created yet" message, that means there is some problem with the setup. It could be the mismatch of the pubs or the bunker could be offline.

You are now set to create and manage target keys (the npubs you will be able to share).

Creating a Key

Click on "Add Key". This will reveal a pop-up prompting for information necessary to create a new target access key.

The Key name is self-explanatory: it helps distinguish your target keys.

The need to fill up the Nsec field depends on how you plan to use nsecBunker. If you leave the 'Nsec' field empty, a new Nostr account will be created. This lets you manage how the target key owner interacts with Nostr. But if you already have an account and want to give someone else access, you can do that by entering the private key for that account into the bunker. It's a similar result, but uses an existing account instead of creating a new one.

The Passphrase is crucial for encrypting your keys and securing communications. Every time your bunker restarts you will need a passphrase to enter the admin panel. Treat it with the same caution you'd exercise with your private key - without it, access to your managed keys is lost.

With these steps completed, you can now share the public key with the owner of the target account.

Activating the Target Account

To start posting with a target key, users should visit https://coracle.social/ and click the "Advanced Login" button, followed by "Log in with Nsec Bunker".

Enter the npub or a token received from the Bunker administrator.

The standard account setup process applies here (in case of a new account), but stay in touch with the Bunker administrator, as they must approve all new interactions.

The nsecBunker Admin UI displays the authorization request for 30 seconds, implying the need for synchronous coordination with the person requesting permission.

While tokens do not require any authorization (more on this below), if you first log in to https://coracle.social/ with the npub , the administrator will receive an authorization request...

...and will be prompted to name this session.

Each subsequent interaction will also generate a request in the admin UI. You can either authorize interactions by event kind - Always allow - or bulk-authorize all future interactions - Always allow signing all kinds - (yet to be enabled).

The "Always allow" feature signifies that the administrator is required to authorize each event type just a single time. For instance, if a user wishes to post a note, which is kind 1 event, the administrator's authorization is needed only once for this specific event type. Subsequently, the user can post additional notes without requiring further permissions. Please be aware that as the tool progresses, the precision of access permissions will be further refined.

Introduction of Policies (see below) streamlines the system by allowing the issuance of an authorization token for the receiver, making administrators' lives much easier.

That's it. The target account owner can now interact with Nostr users without ever touching private keys. See the note below, which was posted by a co-author of , who does not have access to the Herald's private key:

For the video tutorial on setting up the nsecBunker check out this video by Pablo:

If you opt for the "Always allow all kinds" option, the setup process will only need to be performed once. Target account owners can then interact with other Nostr users without further assistance. However, if the managed account owner logs out of Coracle and logs back in, the setup process needs to be repeated for security reasons.

Tokens

Tokens allow you to issue permissions to users, which they apply to an npub of their choosing without requiring interactivity. Creating tokens is super simple:

Head over to the Keys tab;
Click on the Tokens button;

Click Add Token

Fill up required fields

Client name is required for your own reference
Policy lets you choose which rights you'd like to grant to the token holder
Set an expiry date if you'd like
Hit Create Token

Policies

The latest update to nsecBunker has introduced the "Policies" tab, a feature that enhances the authorization process and gives administrators more detailed control over permissions. This addition enables the creation of access tokens to distribute to account holders. Each token can be customized to permit certain event types, set an expiration date for the token holder's privileges, and even define the number of times user's interactions can be authorized.

To leverage this new feature, navigate to the "Policies" tab and select "New Policy":

Give your new policy a name and a short description...

The "Method" dropdown menu provides a way to refine the assigned permissions. While the default "Sign Event" option will suit most users, if you want to restrict the user to only engage with Direct Messages or the Highlighter, select the appropriate option. For instance, using the "Encrypt" method provides the user with permissions to send Direct Messages (DMs) and to generate Highlighter events, such as private notes. Conversely, the "Decrypt" option enables the user to access and read Direct Messages and other encrypted data that is specifically intended for the private key owner.
Within the "Permission" menu, you have the flexibility to either permit all actions or, as demonstrated in the above screenshot, restrict the user to only publishing long-form posts. This functionality could be beneficial, for instance, if you are delegating your blogging responsibilities and prefer the copywriter to not have access to other areas of your account.
The "Usage count" setting allows you to control the number of interactions the target account can perform.

Select "Add Policy" followed by "Save Policy". As illustrated below, your chosen settings will generate various types of access tokens, each with distinct rights and descriptions. The token at the top of the screenshot, for example, restricts the holder to only publishing long-form posts, while the token at the bottom grants the holder full access:

Navigate to the "Keys" tab and select the key to which you wish to assign rights, as outlined by the policy you created. Note that you'll need to unlock the key first by pressing the corresponding button and entering your nsecBunker passphrase. Click on "Tokens"

Select the policy you wish to assign to the key and, if desired, set an expiration time:

Click on "Create Token". A token, which takes the form of a Nostr public key, will be generated. You can now share this token with the intended user:

For a live demonstration of this feature, check out Pablo's video:

Use Cases

"The possibilities of nsec bunker are endless." -

The pace of development in the Nostr ecosystem is impressive. Just a day after the release of nsecBunker, integrated Bunker support into another one of his creations - the Highlighter.

You can find out more about this super efficient productivity tool in my earlier guide here: . As the Highlighter was recently redesigned, my guide needs some updates, but it's still a great resource to understand what Highlighter is and how it functions.

The revamped Highlighter is loaded with new features, such as Lists, Highlights, Private Notes, and of course, the nsecBunker login option. With this feature, you can log into the app without ever disclosing your private key to either the app or the NIP-07 extension provider.

The integration of Highlighter with nsecBunker paves the way to nostr applications that work seamlessly with browsers that don't have a NIP-07 extension, as is the case in most cases on mobile, massively lowering the adoption of Nostr among a general, less tech-savvy, audience.

To use this feature, click on "Sign in" instead of logging in with your browser extension...

...and enter the npub you got with the nsecBunker:

As the administrator approves your connection you get logged in. The process here is identical to the one I described for Coracle.

Take note, with the introduction of Policies, the Highlighter - fully integrated with nsecBunker - also supports the fine-tuning of corresponding permissions:

Highlighter showcases just one of many use cases of nsecBunker. Here are some more, but keep in mind that I'm only giving you a brief overview of the tool's potential:

Separate Accounts for Different Use Cases: nsecBunker enhances your security model by allowing you to retain your private key while using different Nostr clients.
Collective Social Media Account Management: nsecBunker can be used by journalist teams or companies to collectively run social media accounts, increasing user awareness of their products or services.
Child Control: Parents can utilize nsecBunker to set up accounts for their children, ensuring they adhere to family practices.
Burner Accounts: nsecBunker enables you to create specific accounts for specific use cases, all under your control.
Corporate Accounts: Businesses can generate keys for their employees, allotting rights specific to their positions.

However, the applications of nsecBunker are not limited to these. For example, one exciting possibility that emerged shortly after nsecBunker's release was the potential solution to creating private groups within the Nostr community. As astutely observed, the possibilities with nsecBunker are indeed endless. Have a look at his long form post here:

Supported clients

Here's a list of Nostr clients supporting nsecBunker (keep in mind that new clients are actively adding support of this tool, so the list may not always be extensive, feel free to leave comments if you see that some clients are missing):

Note that every client that offers you to login with a so-called "NIP-46" supports nsecBunker login.

Nostr = Everything × Freedom

Harnessing the unparalleled power of the most advanced currency humanity has ever seen, Nostr is an open and censorship-resistant protocol that promotes freedom of expression and allows you to stay anonymous. Its very foundation is rooted in open-source principles, making the collective knowledge and experience gathered through its development accessible to all. The protocol itself, along with most Nostr applications, are open-source. This allows anyone to contribute, adapt, or even build upon existing developments to create something uniquely their own. This is where the true power of censorship-resistant, open-source software resides - it's unstoppable.

Legacy systems, bound by their proprietary constraints, simply cannot compete with the collective intellectual power of what began as a cypherpunk movement and has now blossomed into a vibrant community of dedicated individuals. These individuals are committed to bettering the world, rather than merely filling their pockets with others' hard-earned money. Together, we are paving the way towards a future where freedom of speech and self-sovereignty are the norm, and the fruits of our labor contribute to societal progress. This collective effort fosters the creation of tools that empower us to build better, move faster, and grow stronger. More on this in my post here: .

We invite you to join this peaceful revolution. Participate in the growth of permissionless protocols, contribute to open-source software, and share your ideas to further enhance this vibrant ecosystem. Together, we are not just evolving technology - we are shaping a more open, inclusive, and equitable future.

Like what is building? Make sure to support him!

Pablo's Nostr account:
Pablo's site: https://pablof7z.com/