Question: can nsec bunker custodian see your private keys? They store it to sign for you right? @PABLOF7z
Login to reply
Replies (52)
They're encrypted.
They are seen by the bunker, it’s encrypted at rest, but decrypted when it is used. Unless I misread the code or it changed recently 🐶🐾🫡
What is an Nsec bunker?
with the user's password right? cool.
if someone wants to 'export' their private keys, or transfer them to another custodian, i'm assuming that's possible, right? (how's the security process for that like?).
how is it decrypted? Who decrypts it?
A piece of software that holds and manages Nostr keys and signs events too.
Nsecbunker has the key so the service owner that runs nsecbunker has access to a decrypted version of your nsec. 🐶🐾🫡
Right, so technically the CPU sees the private key.
Oh, like the browser extensions that log you in?
Technically, the service owner has access to nsec. CPU, RAM, (if swapped also disk) sees the key. Unless it is a dedicated HSM or something like Enclave (AWS) there is no way around it 🐶🐾🫡
This can't be... I will wait for Pablo's response lol.
How else can you sign the note if you don’t have the key? 🐶🐾🤷♂️
Gonna get wallet of satoshi rugged
I'm not making any statements, I just want to understand how it works.
Hmm I wonder if a simple process trace would reveal the key when it's in flight then?
Right, I get that, but if you (service provider) is able to see everyone's decrypted key, do we not agree that could be an issue?
a tool to dump the process memory might 😉
strace 👀
I am not claiming that I know the code well en, so take my comments with a grain of salt. If signing is done at the client and key is never known to nsecbunker in its plain form, then only client has the access, if not, then server has the access. @PABLOF7z will be able to confirm one or the other way. 🐶🐾🫡
From the site: “Your nostr keys are stored encrypted with a passphrase you provide and must be decrypted by you before they can be used”
So is your passphrase salted? Is that saved somewhere? Or you have to enter each time to decrypt and sign?
Don’t trust, verify! 🐶🐾🫡
View quoted note →
So passphrase is only used at runtime and not stored in mem?
I don’t know but if the service has access to both (encrypted nsec and passphrase), then it is not hard to get a clear text nsec. It is clearly stored in mem since it’s in variable 🐶🐾🫡
Non custodial bunker in your browser is on its way, just fyi
Yes, it’s just not limited to the browser, i.e. you can put your key on any network attached device and have it sign remotely.
Confidential computing fixes this
You have to trust the bunker
But only the bunker (not every app you sign into)
You can also run your own nsecbunker
Isn’t this just an extension?
Nsec.app
nice domain!
How's it work? Is it up on Github or somewhere? I'm super curious.
Yup, it's true. Bunker has to be able to decrypt the key in order to sign with it. The user provides a password that is used to encrypt at rest but when the key is needed for signing the Bunker has to decrypt it (with the password you provide). The key is used and then re-encrypted.
This is why it's important that the code for something like Nsecbunker is open and (ideally) it would be verifiable that a bunker service is running the exact same code so you know they haven't done anything fishy.
Wdyt?
I’ll have a look tomorrow. Brain is mush at this point.
Ah ok. That would be a fairly straightforward improvement.
Also this one… probably abandoned though.
GitHub
GitHub - nostr-connect/nostrum: iOS & Android reference implementation of a Nostr Connect NIP-46 remote signer. Written with React Native Expo
iOS & Android reference implementation of a Nostr Connect NIP-46 remote signer. Written with React Native Expo - nostr-connect/nostrum
I think the major issue is that the service has access to both, the encrypted nsec and the key to decrypt it. Plus and service that is between the service and the client will have access to both, e.g., Cloudflare, TLS termination thingy. It’s just not a good approach to the storage of keys unless the organization hosts it in their own trusted infrastructure 🐶🐾🫡
i forget where i saw it implemented... maybe i even wrote an RPC recently that lets you do that unlock remotely so it never touches the disk...
oh, no, it was my former sponsor... let me see...
uses protobuf - you will see the proto and the generated pb.go code in there, that is an unlocker that stays off-disk
a second best option is using an environment variable, you can protect that behind root privileges
GitHub
indra/pkg/storage at 089a0df491fd76ac393875053625f9fd4fdbe140 · indra-labs/indra
Distributed Virtual Private Network Powered By Bitcoin Lightning - indra-labs/indra
This sounds super interesting. I’m not too familiar with go or gRPC but would love to understand the mechanics of this off disk unlock or remote signing.
AFK right now but I’ll have a look later and might send a few questions.
How else could a remote signer sign on your behalf if the key is encrypted?
So, trust your bunker provider or run your own bunker. To me, this is a pretty easy model to understand.
The bunker implementation can definitely be improved and become more paranoid but I think the trade-off for brand new users to get up and running super fast is worth it.
With certificates/"delegates" (nip-26) you can entrust the private key -- non-extractable -- to a hardware key store like Android Keystore, TPM, dunno what iShnitzels have.
Everything else is nincompoop shenanigans.
Wut? End-to-end encryption; why would Cloudflare or any MITM have it?
The nsec is encrypted at disk, user needs to talk to the bunker to provide pssphrase to decrypt it every time it reboots/forgets the nsec.
Ofc there’s a trust element which is why open sourcing it is fundamental and reproducible builds and even better running in a secure enclave are ideal.
Because Cloudflare sees your traffic in clear, because they terminate your TLS connection. So are the other services or equipment that does that
I think the point was that service that runs nsecbunker has access to the nsec as is, it doesn’t matter if it’s stored encrypted or not, it’s an easy fix to intercept the key if service wanted to.
Enclave or HSM with the proper and standard encryption key exchange and zero exposure of unencrypted nsec or the key is the only way I see it being trustworthy. 🐶🐾🫡
the communications with the bunker are over relays, it's no direct HTTPS connection 🤔
I do not have full visibility into the code at this time, but how does the key gets into the bunker, and how does the passphrase get to nsec bunker to decode the key. I am strictly talking about the initial setup. 🐶🐾🫡
over nostr, nip04 encrypted payloads
it doesn't expose any direct APIs because the whole point was to be able to run it behind a firewall without doing any holepunching tricks (other than left-side-of-the-curve "just use nostr" holepunching)
Ok, that makes sense. Thanks for clarifying this 🐶🐾🫂🫡
Reading up on all these replies, it seems like nsecbunker (and OAuth) must be run self-custodially via personal home server (ex: Umbrel).