[yammosk]

Even just on a theoretical level I am not really sure the use case of this system. For most keys like ssl certs, this is just too impractical. For anything that has significant business value (like the iOS signing key), I don't think any business would give up all control of such a key to the whims of 3 out of 5 people.

[eamann]

It's to protect against the whims of a small set of people.

If one person holds the signing key to do something critical in your system, they're both a single point of failure and a huge security risk all in one. If you distribute that key to, say, 5 different people you've mitigated the single point of failure. But now you have 5 folks who can act potentially unilaterally.

Using a 3 of 5 TSS setup, you've still mitigated the single point of failure (any one or even two folks can go offline and you can still operate) while also protecting against unilateral action. It's a mathematically-enforced version of the "two-man rule." Similar to the way Cloudflare's Red October tool used to work by splitting things between parties: https://blog.cloudflare.com/red-october-cloudflares-open-sou...

[steventhedev]

The entire point of this is that the complexity is encapsulated on the signing side - not the verifier. So it's more that you would split the keys between systems you control - say the reverse proxy and the application server.

Or one that's checked into your version control (representing that it is your company's code that's running) and one that lives on the server (representing that it is a server your company controls).

Or to take your example - a key in the repo, a key from the dev, and a key from the build server.

[MattPalmer1086]

As opposed to the whim of one person?

[yammosk]

What secret is controlled by one person? That's just not how businesses manage secrets.

[MattPalmer1086]

You are not consistent here. When talking about only needing a single signing key you say that is not subject to the whim of one person. When discussing an N-out-of-M scheme, you think that it's just down to the whims of whoever is in that group. That's just not how business manages secrets!

[yammosk]

I just don't think that keys would be accessible by only one person in either scenario for any large business. The article suggests this 3/5 key needed system prevents issues but I don't think so in practical terms. My suspicion is it thinks there is only one person per key but I think in any business scenario a team would have access to all of them negating the benefits. I don't think that's inconsistent, perhaps just my misunderstanding of what this proposed.

[MattPalmer1086]

Ok, here's a scenario I have seen implemented before when dealing with HSMs and root CAs for a fairly serious PKI. You set up a 3 out of 5 share with each of the 5 keys stored on separate hardware tokens. The tokens are physically secured in safes, in tamper evident bags. To perform operations on the HSM, three out of the 5 tokens are required. The key custodians belong to different teams who can only open the safe for their token.

Now, you need to compromise at least 3 safes to do anything on the HSM. If a token is lost, stolen or damaged, there are still 2 others which can be used. Loss or theft of any two tokens does not compromise the HSM. Any unauthorised access to a token can be detected due to the tamper evident bag.

This gives you strong protection and assurance against any malicious insider or attacker. Having a single key (even if protected in a safe) is much weaker, and carries the risk of key loss (so you would have to have token backups, multiplying rather than dividing the risk).