Nitro enclaves are by far the best bet for companies and orgs, as long as not averse to AWS.
Discussion
Doesnβt https://nsec.app literally do that?
cc: nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy
Sort of, but the bigger issue is what happens if someone who knows the key leaves the company or org. Enclaves solve a bunch of management issues, like quasi-delegation, but they don't solve that core issue.
Or look at OpenBao
Thanks yeah, we did look at that, as well as closed-source stuff like Akeyless. It's all very cool stuff, but at end of the day either one or more human beings can know the secret, or no human being can ever. Sort of like an unavoidable binary there.
Or, smartcardsβ¦ Iβm thinking of working on something like that. 2FA for keys: a password and a physical token
Nice, cards are cool. Nosskey also has some neat stuff on the passkey/WebAuthn side. https://github.com/ocknamo/nosskey-sdk
It's that for businesses and corporate security in general it's tricky cause there is no higher level reset. For all this other stuff like Akeyless, it's still implicitly assumed there is some higher level reset if worse comes to worse.
You start your digital life in Nostr at the supreme court already, you lose you're out of appeals.
So were you able to come up with a solution for yourself on this core issue?
No, feels like running up against the laws of physics (and sociology).
Way I see it, if a human being privately lays eyes on an nsec then we have to assume that nsec is locked to that human being forever. They may or may not have copied it, taken a photo, written it into their Rainman photographic memory, whatever, but for security's sake we have to assume that itβs locked to them forever.
Going further, if a human being *could have* privately lain eyes on a nsec (i.e. they had some access and we can't prove that they didn't make use of that access) we have to assume that they did. And so on. All the general corporate security assumptions.
In most cases there is no real way for Nostr account to be a practical thing to use without a the possibility of a human being laying eyes on the nsec. (It can be a very impractical thing to use, like sharded up the ying-yang, but that's another story.) And a corporate nsec just doesn't work any more once it's been forever-locked to a human being who could leave the company on bad terms (or is just a jerk). It has to be burned.
My solution is to focus on Nostr use cases within companies, mainly as a way to bring frontline workers who don't have any digital identity within their company systems into the social fold. Because each company controls every relay in such an internal Nostr network then you always have whitelisting/blacklisting to fall back on if an nsec is exposed. So relay as the highest level, not nsec.
Basically just avoiding the problem. Though enclaves still very useful for that use case, your work on nitro is groundbreaking stuff.
> In most cases there is no real way for Nostr account to be a practical thing to use without a the possibility of a human being laying eyes on the nsec.
If nsec is generated inside an enclave and bunker url is returned then no human has seen it.
If some "policy" was provided when nsec was generated, like "require m-of-n multisig to change perms, rotate the bunker url, change this policy, etc", then a board of directors can control the nsec without seeing it, and if one of humans leaves they can change the policy and the bunker url.
Does this make any sense, or is there still a fundamental flaw here and we're just kicking the can?
> If nsec is generated inside an enclave and bunker url is returned then no human has seen it.
That's true, but if the electricity fails and the ram clears then when? Of course you can have the code do two things at once, generate the nsec and then encrypt it to the key of another enclave and send it there as a backup, but then you need that other enclave to exist at the time you push the image. (If you allow informing an enclave of new backup enclaves after the fact via vsock then now the power has leaked outside anyway, that vector is now open.)
>If some "policy" was provided when nsec was generated, like "require m-of-n multisig to change perms, rotate the bunker url, change this policy, etc", then a board of directors can control the nsec without seeing it, and if one of humans leaves they can change the policy and the bunker url.
Yup, but still what if the ram clears? Or AWS decides to stop your machine for some arcane reason? Meaning you'd still need a way to get the nsec out of there. And if you have to get it out eventually then feels to me like you may as well just start with it outside in the first place, shard it and upload the shards to multiple enclaves, etc. (very expensive). End of the day it does feel like kicking the can to be honest.
For an individual user it's fine, no problem with them knowing their own nsec and keeping it locally while signing from a nitro enclave for convenience. That's all great stuff. It's just that with an company account I can't see any way that isn't kicking the can. Who knows though, sometimes solutions come round and bonk you on the head.
Sent you DM.
Yup.
There goes your main argument against #communikeys π
Not really. The enclave dies, everything dies. If the enclave generates an nsec that is to never leave the enclave, then that nsec only lives as long as that physical machine lives, assuming you pay your monthly bills.
What it does help with is management of a key you accept will be know by someone at the company who may in future not be at the company. But you still have to accept that, so the core problem remains.
- You can have multiple enclaves with the same nsec. Generated and sent to them by another enclave (for example)
- You can play with conditional export of the nsec
- You can verify if an nsec was exported by someone
To me, those are #goodenough bulding blocks.
And again, solution is needed regardless.
If going for an "unknowable nsec" you can't have multiple enclaves with the same nsec generated by one of the enclaves in anything other than a airtight daisy chain.
Meaning if you start with enclaves A and B, you can have enclave A encrypt an nsec it self-generated to the key of enclave B, and then send it to enclave B (all under attestable code), then it exists in both and nowhere else. But they you're just moving the problem around, the same general point of failure just with a much lager bill. And you have all these encalves from day one, because you cannot update the code of enclave A to inform it of, say, enclave C.
The only workable way is if it's sent from outside in, but that's the core issue again.
Or you could use NA π