Store private keys to Nillion network

[eum602]

How could Nillion address storing sensible information such as private keys in a secure way?. In this use case a user wants to recover a lost private key prior saved to Nillion network.
Given such scenario I wonder:

• Is this a use case that fits Nillion features?
• How redundant is each piece of the blind split private key stored to Nillion?
• Does each node have all the split parts?; I mean, how is it guaranteed that the stored information will be always recoverable?
• who can access the split parts? Is information available to anyone having access to Nillion network?
• Is there a possibility that an attacker can obtain all pieces of blind information pertaining a particular private key stored to Nillion?
• How would network nodes collusion compromise the security of split parts for a given stored key?

Hope this questions help us to open a conversation regarding this use case.

[wwwehr]

Hey @eum602 I'm going to reply to each question in a different comment so that I can wait for some clarity from the team on some of them to provide the best answers!

[wwwehr]

Is this a use case that fits Nillion features?

Yes! Our storage technology is quantum secure and for a simple storage and retrieve workflow, we've got you covered.

[wwwehr]

who can access the split parts? Is information available to anyone having access to Nillion network?

Our current design utilizes a S3 compatible storage system and our network cluster participants for the PetNet (where your secrets are stored and compute operations happen) will initially be permissioned. Meaning that we will only connect to and work with partners that we talk to, audit, and explicitly trust.

Thus, on the technical front, we will require that these partners have a highly available and absolute secure handling of their storage implementation.

[wwwehr]

Is there a possibility that an attacker can obtain all pieces of blind information pertaining a particular private key stored to Nillion?

That possibly would require collusion and coordination of a large number of cluster participants of the PetNet to form a reconstruction attack. This is something we address at first by centralizing permission authority with us (Nillion) and establishing financial and reputation stakes; among other tactics. We are still working out all these kinds of details, but we understand how important this is to get right and aim to work out issues as early as possible.

[eum602]

So Nillion entity acts as a root of trust?, I mean any permission or removal of a node ultimately relies on Nillion Entity?

[wwwehr]

To start with in these early stages, this is our thinking as it will afford us all the best protection from attacks.

[wwwehr]

How would network nodes collusion compromise the security of split parts for a given stored key?

If enough, by percentage, of the network nodes colluded it would put all the data stored amongst them at risk of exposure. This is exactly why Nillion is decentralized so that you don't have to trust a single entity to "do the right thing all the time and never hire a nefarious black hat". We believe our strategies on how to address this very topic (ala permissioned PetNet) is an effective way to deter this kind of threat.

[eum602]

Based on the documenttion to retrieve a secret in Nillion; retrieving the blind split parts comprising a private requires a user-key (private key) and a node-key. How is this supposed to managed? How would these parameters be orchestrated between a natural person and nillion, Could you please elaborate with a recovery flow?

[wwwehr]

How is [the user/node key] supposed to managed?

We are working on an "in network" MFA solution for this, but for now we recommend treating these keys are having the same value and level of risk as the secrets being protected. If you can use HSM or other hardware security backed storage, that would be my recommendation. I use Amazon's parameter store for things like this (w/ their KMS) for storing secrets in dev/early projects.

[wwwehr]

How redundant is each piece of the blind split private key stored to Nillion?

Our current design utilizes a S3 compatible storage system. The operator of the network node will be responsible for providing reliable data retrieval and the guarantee is in the tokenomics reward system that we are in the process of completing. In other words, we aim to use monetary incentive or slashing mechanisms.

[wwwehr]

Does each node have all the split parts?; I mean, how is it guaranteed that the stored information will be always recoverable?

No. Each node contains only a subset of the parts and reconstruction cannot be completed without all the parts being present as expected on all of the cluster node participants. I am gleaning that you are thinking about "what happens if a node disappears forever from the cluster and is my data lost?" - our testnet and early functional network will not have this solved but we do have this on our roadmap for mainnet.

[eum602]

Thanks for replying; given a a subset of the parts is stored by just a subset of nodes in Nillion, I understand that the question: how redundant is such subset of the parts? is a work in progress item, isn't it?

[wwwehr]

we are discussing whether we want to have the network enforce redundancy, OR if we want that left to the operator. for example, maybe the node implementor is using replication on zfs, would they get benefit by mandating another technology that might be redundant or expensive - or impossible for resource limited hardware. anyways, I could imagine a variety of configurations of pros and cons. I'd be interested to hear if you have experience here and an opinion on how this should roll out.

[eum602]

For the sake of creating more decentralized solutions, having redundant parts of the same information would be aligned with such goal. Allowing a user to store a part but not making it redundant would not make sense for Nillion, since for the use case in the context of this conversation a user wants to avoid the non data availability problem. Given such scenario the question would be, whether the nodes storing such copies of a particular part is automatically determined by the Nillion Protocol or whether the node operator configures which nodes it connects with for such purpose.
Another point to bring would be how Nillion automatically detects there is at least one copy of a particular part of a secret.

[wwwehr]

@Davetbutler - FYI we're talking about data resiliency in the network. Our initial launch plan is to rely on network operators to provide high-availability re: the data storage. Erick's vote is that we would instill some responsibility in the network so that it has better guarantees on future availability. At it's core, we are simply advocating for "in network data resiliency" which maybe has to do with share distribution, node selection, and things like that so that it isn't (only) left to operator storage configuration.