5 ms·

I was just thinking about something like this problem. At $work, we use multi-signature signing to move cryptocurrency around, so that at least N of M officers

by derefr 3y ago

I was just thinking about something like this problem. At $work, we use multi-signature signing to move cryptocurrency around, so that at least N of M officers of the company need to sign, to prove that "the company" actually intends a movement of funds to happen. This ensures that no single officer can embezzle funds; and it also ensures that an attacker would have to do some kind of multi-target simultaneous coordinated rubber-hose attack (rather than just waiting to kidnap one of us when we go on vacation) to get access to the funds. I was trying to think of a way to extend that kind of security to the encryption of data — specifically the encryption of low-level root-account passwords (like an AWS account's root password). Shamir's Secret Sharing is the obvious first step... but you'd also then want two additional properties: 1. the decrypted secret should not be held even temporarily by any of the parties, but rather should be held by — and used "through" — a neutral system, so that the secret is reusable rather than needing to be burned the first time it's revealed 2. the neutral system — despite being likely owned by a third party! — should have no ability to exfiltrate the password into the hands of the third party. I think this can be workable in the specific case of wanting to use the root password as an HMAC, by doing SSS decryption inside a single-shot non-durable abstract machine with homomorphically-encrypted memory, wrapped in a network daemon: the network daemon spins up a copy of the abstract machine; receives each SSS key split from its owner, feeding each as it receives it directly into the abstract machine; the abstract machine, after receiving sufficient key splits, signals to the daemon that it is now "empowered" to sign; and the daemon can then use the abstract machine to HMAC arbitrary plaintexts sent to it, until it exits, and the abstract machine's state is lost. The real trick, though, would be making this work for HTTP Basic Auth over TLS, by delegating the generation of exactly one TLS frame — the one containing the Authorization header — to the abstract machine; where the network daemon would then act as an HTTP proxy, inserting this Authentication header into requests made through it. Having something like this could really improve security around the use of a lot of sensitive control-plane APIs! --- Of course, in a corporate context, you probably have a third party you can trust with the plaintext — e.g. an Enterprise Password Manager service — so you can relax property 2. In such a case, you don't need a fancy abstract machine; you can just ask said service to build a feature allowing secrets to be configured to require N-of-M confirmations by ACLed team-members to unlock them; and to build another feature for "opaque secrets" that are never revealed to anyone, but instead are injected into an HTTP Authorization Proxy that the Enterprise Password Manager service spin up themselves on their backend. But it's still fun to think about the case where your secret is so secret that you need to hide the plaintext from literally everyone but your co-conspiriators. :)

muixoozie 3y ago
If x officers died in a freak accident where there's not enough for N to sign, is there a way to recover?
- fbdab103 3y ago
  Seems no different than if all N parties with the key were lost. Is there a backup strategy in case the key people are all wiped out simultaneously? How does ICANN handle it? There was a recent story[0] about a crypto company where everyone "lost" the keys (I assume inside job). [0] https://news.ycombinator.com/item?id=37268750 https://news.ycombinator.com/item?id=37268750
- derefr 3y ago
  Yes, if you plan for it. There are several mitigation strategies for this. The simple approach, if you have enough people you fully trust, is to just have a larger number of participating signers / distributed key-splits than you need, such that you don't actually need a majority of the key-splits to be used, to achieve a signing quorum. (E.g., instead of 2-of-3 signing, you'd use 2-of-4 or 2-of-5 signing.) In this setup, usually there's a "core" of signers who are active participants in the system, where the required quorum size does constitute a majority of the "core" of signers; and then there are other "backup" signers, who aren't normally participants in signing as part of their job duties, but who can be called upon to act as additional signers in an emergency — usually just to participate in a "handover of power" (activation of new keys) for new signers (e.g. if the CIO and COO die, and you hire a new CIO and COO.) These signers should not be anyone who any of the "core" signers has power over — not any of their reports, not anyone they can fire, and not their own friends or family. (Personal acquaintances from outside the company do make good "backup" signers, though — an officer's personal accountant is a frequent choice.) Also, ideally, there should not be enough such "backup" signers that a single "active" signer could collude with the "backup" signers to embezzle funds. The signing configuration should still always imply the need for at least two "active" signers. (So 2-of-4 / 2-of-5 are actually bad configurations; a minimal ideal configuration would be more like 3-of-5 (with one backup signer), or 4-of-7 (with two backup signers); and you don't get both "not a majority" + "at least two active" together until 4-of-9 (2 backup) signing.) A more expensive version of this approach, but one which could be considered more secure and with less required trust, is to give the extra signing key splits needed to achieve a signing quorum to one or more law firms, under contract to only release those key-splits upon a legal notice of demand from all still-living members of the signing group. The law firm must then verify for itself that 1. enough people are dead that the signing quorum condition can indeed no longer be met without first activating one of the offline'd keys; and 2. exactly all remaining living members of the signing quorum really want the keys released (probably this would be done through in-person individual interviews and notarizations.) Also, to prevent this arrangement from acting as a https://en.wikipedia.org/wiki/Tontine https://en.wikipedia.org/wiki/Tontine (in the sense that it incentivizes murdering your co-officers), usually there would be a line in this contract stipulating that the keys won't be handed over while the still-living signers are under suspicion of directly or indirectly murdering the dead signers; and that the keys will only be handed over after a 60–90-day delay (which gives time for such a suspicion to arise, if relevant.) Another mitigation strategy, that works well in combination with either of the above, is for officers with signing keys to leave their password-locked hardware signing device (smart card, crypto wallet, etc.) with a trusted coworker whenever they're going somewhere potentially dangerous; and to leave the password to unlocking said signing device with the executor of their will, only to be released upon their death. In this setup, people who travel are temporarily unable to sign (the person they've entrusted their signing device to doesn't have its password, and so cannot sign for them); so travel scheduling + signing configuration must be planned together to ensure that a signing quorum is always possible to achieve.

by derefr 3y ago

muixoozie 3y ago

If x officers died in a freak accident where there's not enough for N to sign, is there a way to recover?

fbdab103 3y ago
Seems no different than if all N parties with the key were lost. Is there a backup strategy in case the key people are all wiped out simultaneously? How does ICANN handle it? There was a recent story[0] about a crypto company where everyone "lost" the keys (I assume inside job). [0] https://news.ycombinator.com/item?id=37268750 https://news.ycombinator.com/item?id=37268750
derefr 3y ago
Yes, if you plan for it. There are several mitigation strategies for this. The simple approach, if you have enough people you fully trust, is to just have a larger number of participating signers / distributed key-splits than you need, such that you don't actually need a majority of the key-splits to be used, to achieve a signing quorum. (E.g., instead of 2-of-3 signing, you'd use 2-of-4 or 2-of-5 signing.) In this setup, usually there's a "core" of signers who are active participants in the system, where the required quorum size does constitute a majority of the "core" of signers; and then there are other "backup" signers, who aren't normally participants in signing as part of their job duties, but who can be called upon to act as additional signers in an emergency — usually just to participate in a "handover of power" (activation of new keys) for new signers (e.g. if the CIO and COO die, and you hire a new CIO and COO.) These signers should not be anyone who any of the "core" signers has power over — not any of their reports, not anyone they can fire, and not their own friends or family. (Personal acquaintances from outside the company do make good "backup" signers, though — an officer's personal accountant is a frequent choice.) Also, ideally, there should not be enough such "backup" signers that a single "active" signer could collude with the "backup" signers to embezzle funds. The signing configuration should still always imply the need for at least two "active" signers. (So 2-of-4 / 2-of-5 are actually bad configurations; a minimal ideal configuration would be more like 3-of-5 (with one backup signer), or 4-of-7 (with two backup signers); and you don't get both "not a majority" + "at least two active" together until 4-of-9 (2 backup) signing.) A more expensive version of this approach, but one which could be considered more secure and with less required trust, is to give the extra signing key splits needed to achieve a signing quorum to one or more law firms, under contract to only release those key-splits upon a legal notice of demand from all still-living members of the signing group. The law firm must then verify for itself that 1. enough people are dead that the signing quorum condition can indeed no longer be met without first activating one of the offline'd keys; and 2. exactly all remaining living members of the signing quorum really want the keys released (probably this would be done through in-person individual interviews and notarizations.) Also, to prevent this arrangement from acting as a https://en.wikipedia.org/wiki/Tontine https://en.wikipedia.org/wiki/Tontine (in the sense that it incentivizes murdering your co-officers), usually there would be a line in this contract stipulating that the keys won't be handed over while the still-living signers are under suspicion of directly or indirectly murdering the dead signers; and that the keys will only be handed over after a 60–90-day delay (which gives time for such a suspicion to arise, if relevant.) Another mitigation strategy, that works well in combination with either of the above, is for officers with signing keys to leave their password-locked hardware signing device (smart card, crypto wallet, etc.) with a trusted coworker whenever they're going somewhere potentially dangerous; and to leave the password to unlocking said signing device with the executor of their will, only to be released upon their death. In this setup, people who travel are temporarily unable to sign (the person they've entrusted their signing device to doesn't have its password, and so cannot sign for them); so travel scheduling + signing configuration must be planned together to ensure that a signing quorum is always possible to achieve.