Utilizing Shamir's Secret Sharing Algorithm for Secure Key Vault Access

[ImanSharaf]

The current iteration of OWASP ASVS does not have a control or recommendation regarding the use of Shamir's Secret Sharing algorithm to manage access to key vaults. In sensitive scenarios, utilizing Shamir’s algorithm allows the distribution of access among multiple parties, ensuring no single individual can access the key vault.

Example Use Case:
Consider a financial institution that maintains a key vault for encrypting sensitive customer data. To avoid the risk associated with a single individual having access, the institution can employ Shamir's Secret Sharing algorithm to divide the access key into multiple shares. A predefined number of these shares are required to reconstruct the original key and access the vault, thereby distributing the responsibility and enhancing security.

[Sjord]

If this would become a requirement, the requirement should probably be "only allow access to a key vault with consent of at least two persons", instead of "use Shamir's Secret Sharing Algorithm".

I think this could be a useful security measure in some cases, which certain companies should consider, but I would not require it.

[elarlang]

Ping for @jmanico and @tghosth

[tghosth]

This feels too specific to be covered for ASVS. It might be relevant for something like a secret vault cheat sheet but I think it is too detailed for ASVS.

[elarlang]

@ImanSharaf - any arguments why it should be as separate requirement or some alternative solutions to mention/spotlight in other requirements?

[ImanSharaf]

@tghosth I believe Shamir's Secret Sharing can be too specific and we can have a more general thing such as "avoid the risk associated with a single individual having access to the key vault".

@elarlang I believe that works too.

[tghosth]

@ImanSharaf do you have a specific requirement that you think should be modified for this?

[ImanSharaf]

I want to say that we can modify 6.4.1 and add "avoid the risk associated with a single individual having access to the key vault" but it makes it an L3 requirement. Can we have a separate requirement for this?

[jmanico]

I want to say that we can modify 6.4.1 and add "avoid the risk associated with a single individual having access to the key vault" but it makes it an L3 requirement. Can we have a separate requirement for this?

Key management is really challenging. May I suggest that we focus on what to do, instead of what not to do? "Shamir's Secret Sharing" is just one method and there are many other ways to do really good scalable key management like https://code.cash.app/app-layer-encryption and similar.

There is also Blakley's secret sharing and many other sharing algorithms that are solid.

Also, Secret Sharing (SSS) Is not always needed. If you are in a scenario where you need to distribute trust among multiple parties and can't afford to have a single point of failure or a single trusted entity, SSS might be the better choice.

Sometimes, envelope encryption is just fine. If you are looking to manage encryption keys for data at rest and want the convenience of using cloud provider services with built-in auditing and compliance features, envelope encryption would be more suitable.

Also: Beyond SSS and envelope encryption, there are other key management strategies to consider, like hardware security modules (HSMs), cloud HSM, or multi-cloud key management systems, which provide hardware-backed key storage and cryptographic operations.

[tghosth]

Are we sure that there is a specific risk here?

As I see it, the risk which we are trying to prevent is that a single person with enough access to get to the secret vault directly steals a key.

Firstly, I don't think it should be possible to extract the keys from the vault anyway.

Secondly, generally the multi person operation is a one-time thing as the application needs to be able to access the secret vault on an ongoing basis. Someone with this level of internal access would probably be able to access the vault via the application anyway rendering the control less valuable.

As such, I am concerned that we are mandating a very specific requirement but I'm not sure that there is a specific risk we are addressing. It feels to me like the secret sharing mechanism would be useful in certain use cases but not as something that is universally mandated

[tghosth]

@ImanSharaf @jmanico what are your thoughts on my previous comment? Reproduced below:

Are we sure that there is a specific risk here?

As I see it, the risk which we are trying to prevent is that a single person with enough access to get to the secret vault directly steals a key.

Firstly, I don't think it should be possible to extract the keys from the vault anyway.

Secondly, generally the multi person operation is a one-time thing as the application needs to be able to access the secret vault on an ongoing basis. Someone with this level of internal access would probably be able to access the vault via the application anyway rendering the control less valuable.

As such, I am concerned that we are mandating a very specific requirement but I'm not sure that there is a specific risk we are addressing. It feels to me like the secret sharing mechanism would be useful in certain use cases but not as something that is universally mandated

[ImanSharaf]

We can close this.