Can key metadata be stored more securely?

[paulhowardarm]

One of the pluggable components in the Parsec service is the KeyInfoManager, for which the only incarnation that exists today is the OnDiskKeyInfoManager, which stores key info mappings on the OS filesystem.

Confidentiality, availability and integrity of these mappings are important for a healthy Parsec deployment. Confidentiality is of particular importance in multi-tenant scenarios, where the key info does not only help us map high-level key names to back-end identities, but it also forms part of the access control subsystem to ensure that tenants cannot be given access to the "wrong" keys.

On-disk mappings are protected by OS filesystem permissions - this is part of the documented Parsec threat model.

An improved security posture could be obtained by storing these data outside of the OS. On a platform that supports secure enclaves or partitions, it may be possible to migrate key mappings into a secure storage service where they are not visible to the OS while at rest.

What would this look like? Would it depend on some underlying blob storage/retrieval primitives? And, if so, could those same primitives also form part of Parsec's API for direct client use as well? (Based on PSA Storage, for instance)?

[hug-dev]

I agree that the mappings make an essential part of Parsec and that ensuring that their security properties are respected is essential. Currently the protection is only based on operational mitigation 3:

Mappings should be put in a location that only the Parsec service and the trusted administrator can access.
The mappings are inside a folder for which the Parsec user should have exclusive access.

So relying on OS permissions as you said. Improved security is always better but this will only be "best-effort": we rely on the OS permissions so much on other parts of the threat model that improving this part only might not make it more secure. What I mean is that if we are not trusting OS permissions then so many of our operational mitigations become void: the authenticity of the Parsec service, the confidentiality of the config file, accesses to the logs, authentication through UID, etc...
If we decide to improve the security of those parts that are currently relying on OS permissions, we might have to go for an "all or nothing" change, where we review the entire threat model and decide to use a secure enclave for all of the parts relying on OS permissions.

Confidentiality is of particular importance in multi-tenant scenarios, where the key info does not only help us map high-level key names to back-end identities, but it also forms part of the access control subsystem to ensure that tenants cannot be given access to the "wrong" keys.

Note that "confidentiality" is not a security property of the "asset 7, key triple mappings". I think the information contained there: the key ID, its attributes could be leaked without big consequences but I agree that it should never be modified (integrity).

[paulhowardarm]

Good points. Agree confidentiality perhaps not so important as integrity for the mappings.

In terms of reliance on OS permissions for various subsystems - we should not let this inhibit our ambitions to improve things piecemeal. And, as it happens, sensitive aspects of config was going to be the subject of another question/issue I was planning to raise! Not sure about the all-or-nothing thing. I think specific threats can have specific mitigations, and recommending the use of enclave storage for certain things (such as the key mappings) would be one such mitigation. But there will always be a best-effort aspect to this, because some deployments might not be able to make use of enclave storage.

[ionut-arm]

What I mean is that if we are not trusting OS permissions then so many of our operational mitigations become void: the authenticity of the Parsec service, the confidentiality of the config file, accesses to the logs, authentication through UID, etc...

I think this is true for the setups in which we usually work which are just plain Linux distributions without any "software hardening" features. When I was setting up the TPM integration on a Dell Gateway I had to work quite hard to access various things even with "full control". Presumably stuff like AppArmor or SELinux could help create a more secure deployment where even if you elevate privileges and get access to one thing, you might not have access to another.

I think the information contained there: the key ID, its attributes could be leaked without big consequences but I agree that it should never be modified (integrity).

Without big consequences under our current threat model, but strengthening our threat model is a goal on its own. The reason it's ok now to say "confidentiality isn't important" is because we decided that's how it is, not necessarily that it can't/shouldn't be improved. The less assumptions we need to make, the better we can sleep at night 💤

One thing that seems particularly important for a storage like this is the authentication/authorization - how do we make sure only Parsec can access that data? I assume this is similar to the model for Trusted Services, though I don't know enough about it. An alternative would be to use some authentication value/password, though that would have to be stored on disk.... :) This exact issue tormented me a bit when we first wrote up the TPM integration, because there doesn't seem to be any way to enforce in hardware that only application X can access key Y. We need to rely on software executing in higher exception levels to check things for us