distributed secret key

[Kyle Hamilton]

There are two ways to handle multiple authorizations needed:
1) Secret data is shared across multiple locations/holders, or
2) Secret data is stored in a trusted system which itself requires multiple
authorizations.

You could perhaps put together multiple trusted systems, each of which has
a share of the secret data, and then have single authorizations for each of
those multiple systems.  But that that point, you're opening up a huge can
of logistical worms that you seriously need to examine through the lens of
a threat model evaluation, particularly against potentially rogue system
administrators and backup operators.

There is no possible way to have a distributed secret key without
distributing secret data across multiple entities/systems, though.  Whether
those entities are in the custody of those who possess the authority to use
them is unimportant, but if they are not then your threat model must
include attacks by those whose custody those entities/systems are actually
in. (Multiple encrypted containers/home directories for those shares might
work on the same system, but you still need to "send the secret data
around" to each of them.)

In any case, I am unaware of any existing system which meets your
requirement 3.  Admittedly, I haven't specifically searched for such.

-Kyle H

On Sun, May 24, 2020, 05:04 Erich Eckner <openssl at eckner.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> we're looking into setting up a CA with openssl, but we would like to
> distribute the secret key amongst multiple persons. We're aware of
> Shamir's secret sharing algorithm, but we'd like to know if there is some
> algorithm supported by openssl, that fulfills the following requirements
> (2 and 3 are not fulfilled by Shamir's algorithm):
>
> 1. Secret key shared amongst N persons, M<N shares sufficient for using
> the key.
>
> 2. No secret material (or parts thereof) needs to be sent around,
> preferably not even during creation of the key.
>
> 3. Secret key will not be assembled from the shares for the acutal
> operation. E.g. each share operates independently, and the intermediate
> result is sent around, after M keyparts operated on it, the signature is
> complete and can be used.
>
> If this is not supported by openssl, we're also open for suggestions of
> other (open source, free-to-use) software, that can achieve this and
> creates standard X.509 certificates (not sure if I termed that correctly).
>
> Thank you in advance!
>
> Regards,
> Erich
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7KRVMACgkQCu7JB1Xa
> e1rhyBAAvzJUrwcyRLpdme/mWsF/ftuA8nqv/ccw4be9Q1Y/S72MU/7UhKW2dBE0
> jp2tBV4zq5D3i37ElCy+Mco97cCQ+Ikg3pOtYaMYkK0hoybBlyX6onX0Y7jQhP2W
> N2v07HaN5RxtunxJgh7wUkWMy5arigKY9e645vJh5c8Ii5pwBb8QMwwMUJfb/1Hv
> 5yrF4x8la3lmqQSsAwkj0FFhAAmh+Xe/v4D+uoEzmTHY7vi9hGJsAAYNmJkwsIAb
> M/lK43wZRAXVbotFOVrud10wchBOSUtY0w6T5apmNJ/ArA61EbuFVtUUjjBYiv87
> oVxr+3pydjJLDW4WczcKLKQdNbhGPhmmz4DDHxvhLXSTrtFAPUm4Qb3VeM1AO0it
> Gs943eoBkUrga6813sBmulbtM3fnfDbJro0/ZqQnh4/vRKQUy6LvMj2W/M/8Fn1C
> M8um53J35/BAakZhOHaNvDrVty4bEJ0y1fNs7JNNpQfB+WjL8C04g2uExNJmAKgG
> 0dmZxDNGrPLKrltz+R39j0gbA4P1hnYkcgAYFcGho0z468IV5sgleHN3FhAp1qr5
> /TAuD2rwuPxT9wXf726n09iYJpq6jVhpBuF74mBNbyDdTzeeJtVq9mqngmhWqOCw
> KJcTXIhIem2wTA2yfhzf1PNK58hU55/lB36TnRryapp1rXLu1uU=
> =+60v
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200524/f98476df/attachment.html>