3 ms·
I build systems designed to distrust any single individual with cryptographic key material and SSSS needs a lot of careful handling and automation to accomplish
by lrvick 4y ago
I build systems designed to distrust any single individual with cryptographic key material and SSSS needs a lot of careful handling and automation to accomplish this.
Splitting the key safely is only part of the problem though, because you will then need a system that only -uses- the key in a way all parties consent to.
Threshold signing is a much easier alternative for many use cases but sometimes a cryptosystem requires just one key and SSSS is all we can do.
To avoid any single party accessing a complete SSSS split key you can:
1. Write an application that takes N public keys as input, and returns a newly generated key as SSSS shares encrypted to each respective public key as output.
2. Compile application deterministically as an immutable unikernel or firmware image targeting hardware that supports remote attestation (Nitro Enclave, Confidential VM, HSM, etc).
3. Publish source code such that all participants can access and review it, or confirm review was done by multiple parties they trust.
4. Have multiple parties trusted by all participants, or the participants themselves, build the application bundle and confirm they get the same hash
5. Any party deploys the bundle to a live remotely attestable system.
6. All parties use the remote attestation interface to confirm the target system is running the multi-party deterministically compiled application they expect.
7. All parties submit their public keys to the remote system.
8. The remote system generates new key, splits it, and returns SSSS shares to each party encrypted to their respective public key.
- generalizations 4y ago> This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the key. What you describe still trusts the distributor - you just found a way to make the distributor easy to trust. I'd be more interested in a mechanism that is mathematically correct, like some of the papers referenced elsewhere in this thread.
- lrvick 4y agoEven if you avoid trusting the distributor, the quorum of share holders still will end up having to reconstitute the shared key into the memory of a computer somewhere at some point to do cryptographic operations with it. There is no avoiding standing up computers all parties trust and if you are going to do that anyway then you might as well use them for key generation and distribution too.
- generalizations 4y agoWell, now you've just turned your locked box into a key distribution machine, and there's a big difference in the security profile of each.
- lrvick 4y agoWhat is the point of generating a cryptographic key that you can never safely use?
- generalizations 4y agoI mean that the security profile of a simple 'locked box' that only knows the keys when all parties agree to unlock it is a very different from the security profile of a 'key distribution machine' like you described. I mean, if we all agreed to perform the decryption, the secret's out anyway. But not before then.
- lrvick 4y agoDepends on use case I suppose. I can not think of many practical applications for one-time-use keys other than disaster recovery flows. The real world use cases I most commonly support are things like CAs, TLS keys, financial transaction signing keys, and sensitive document decryption keys. All of these require single keys to exist that needs to perform automated operations, and needs to be on systems that can be backed up, restored, upgraded, and maintained, while able to prove no single person can access or control the keys. The scheme I described can allow one key to be created, split, restored, used, and split again many times without full trust in any individual.