Requesting support for HSM Unseal method

[ats0stv]

Is your feature request related to a problem? Please describe.
Yes, this feature request is related to a problem. Currently, OpenBao does not support integration with Hardware Security Modules (HSM), a critical feature for enhancing security in sensitive environments. Many organizations, especially in sectors like finance and government, require HSM integration to meet compliance standards for cryptographic operations. This feature will enable OpenBao to automatically unseal using secure hardware, reduce operational complexity, and ensure that cryptographic keys are protected according to industry standards such as FIPS 140-2.

Describe the solution you'd like
I would like OpenBao to implement HSM integration to support automatic unsealing and enhanced security for encrypted data. This solution should include seamless setup and configuration for HSM devices that adhere to industry standards like FIPS 140-2. The integration should feature detailed documentation and command-line tools to facilitate easy and secure key management operations. Additionally, implementing the Seal Wrap feature will provide an additional layer of security, ensuring sensitive data is wrapped with an extra cryptographic barrier. This integration will make OpenBao a more robust tool for enterprises requiring high security standards.

Describe alternatives you've considered
As an alternative to integrating HSM support directly into OpenBao, we considered using software-based encryption keys with enhanced security measures. However in a private environment (non-cloud), the most securely viable is an HSM integration. Additionally, using HashiCorp Vault Enterprise was explored; however, it does not meet our cost constraints, making it less feasible for our project's budget. These alternatives, while potentially viable, do not fully meet the stringent compliance and security requirements that direct HSM integration would achieve.

Explain any additional use-cases
Adding HSM integration to OpenBao would also cater to use cases involving high-security applications, such as in government, healthcare, and banking sectors, where regulatory compliance demands hardware-level protection of encryption keys. I feel though an enterprise feature, this is a top priority item to implement as it will enable the adoption of OpenBao project in all environments.

Additional context
Integrating HSM with OpenBao aligns with industry best practices for security, particularly in sectors dealing with sensitive information. This feature would not only enhance the platform's attractiveness to prospective enterprise users but also leverage existing community expertise in HSM technologies to foster collaboration and innovation. By providing detailed documentation and examples, the adoption of this feature can be streamlined, encouraging widespread use and contributing to the robustness of OpenBao's security capabilities.

[cipherboy]

I think #16 is a duplicate of this.

It would be good to decide if we want to keep with the structure of go-kms-wrapping or if we'd like to simplify it in some way?

[jleni]

We would be able to contribute/participate and have experience in the area.

Maybe structuring around a more extensible architecture that allows for plugins would be very good.

[cipherboy]

@jleni Yes, a plugin architecture is what PKCS#11 bindings would effectively let you achieve.

The go-kms-wrapping project has already been forked into the OpenBao namespace, which has backend for various KMS systems but not for PKCS#11. What I've yet to think more about is if we want to keep that or go with a different approach. Right now the project is only used for auto-unseal...

IMO, if we wish to keep just auto-unseal (and not seal wrapping or managed keys), we could revisit our decision to use go-kms-wrapping and create a simpler library just for that one use case, migrating callers... And maybe seal wrapping and managed keys, were they to be added later, could take different, specialized approaches of their own.

The one thing I think I saw was that Azure KeyVault (their KMS offering) lacks PKCS#11 bindings of any sort (as does Transit), whereas most other KMS providers have PKCS#11 bindings... So maybe a Go pkcs#11 library would be nice, to eventually build Azure and Transit bindings without the need to put those SDKs in the main binary (like we do now)....

Some Saturday thoughts. :-)

But if you're willing, I might suggest spending some time looking at g-k-w and deciding what you think about keeping it versus replacing it. I'd take a careful look at the interfaces that exist presently, perhaps consider the ability to do key mobility/wrapping, and also at the extensibility of the protobuf files and make a determination there.

[DanGhita]

Hi @cipherboy,

Could you be more explicit about the changes that you have in mind concerning the go-kms-wrapping interface ? Which are, in your opinion, the main drawbacks of the current g-k-w?

Many thanks!

[cipherboy]

@DanGhita Hmmm... I think there's a few angles I can immediately articulate:

1. Being a not-particularly-modular Go library (and regardless, OpenBao wanting to include everything), the end result is that g-k-w pulls in a lot of dependencies (cloud SDKs) to achieve integrations with major cloud vendors' KMS solutions. These are large SDKs, AWS alone contributes many megabytes from past analysis, and the result is that it bloats the final binary size (see RFE: Split CLI, Agent, Proxy, and Server binaries #73 and Release: Stripped & Non-Stripped Builds #77 perhaps) much more than say, only PKCS#11 bindings would do.
2. The supported capabilities, right now, are very limited in our forked code. We apparently have Sign/Verify, symmetric encryption, and AEAD encryption and that's it. This leaves other primitives, e.g., used by Transit, off. I think some of this grew organically out of the OSS/Ent split of this package, but not having all ops available for all backends was seen as more of a modular choice and feature than not, even though most backends support all types of ops.
3. The interface style is... entertaining? :-) While better than v0, there are frequently non-obvious interface behaviors. E.g., look at AWS's SetConfig(...), which reads environment variables for many components. This makes it much harder to debug & understand both for us and users as there's a wider set of environmental (both literal envvar + config values) that impact results. This has lead to hacks like WithDisallowEnvVars as a configuration option.
4. Further, the interface lacks algorithm identifiers (if you look back up at Wrapper, Sign/Verify, &c). The interfaces does not expose it, and IIRC, this was because a given wrapper instance was meant to be more for a single key at a single provider, and thus choice of algorithm was in some sense, implicitly fixed (even though this disregards the realities of e.g., RSA PSS vs OAEP vs PKCS#1v1.5 vs KEM or EC DSA/DH). This makes things like, e.g., multi seal harder, or similarly, things like Managed Keys (in Enterprise, used by Transit and PKI for instance) harder. To me it seems like a parent context object of some sort, config driven, yes, with the ability to list keys and then have a derived instance helper per key that actually does operations, rather than having to pass config into a place that can globally create wrappers.
5. Choice of protobuf as a result structure is... eh? This ties all uses of go-kms-wrapping to a single output format struct, which makes changing g-k-w more fragile as you can't break backwards compatibility in any way, especially because it is a storage format. IMHO, having each project handle serialization of their actual storage format, converting it to common structures used for operations, rather than this global library handle that, would be good separation of concerns. This has made many efforts much, much harder. More precisely, I'd suggest that auto-unseal could use one mechanism (perhaps this, for backwards compatibility), seal wrapping could use its own, &c., and define just an encryption library rather than an encryption+serialization library.

My 2c., but I think, given we only use it for auto-unseal today, perhaps it is scoped nicely enough that we could restructure to avoid using g-k-w, and build our own multi-provider encryption library, even if it does import SDKs, with nicer interfaces and better separations of concerns.

Let me know if these thoughts are coherent this morning :-D

[IohannesArnold]

Hi @cipherboy, I would be interested at taking a crack at implementing PKCS#11 support for OpenBao, but I'm still new enough to programming and crypto in particular that I will probably need some guidance.

Just to be clear on the scope, the goal would be to implement more or less the Enterprise Vault design for pkcs11 unsealing, right? I've taken a look at those docs and at this pcks11 library by Google and can more or less get a vision of how I would use the latter to implement the former.

I actually haven't taken a look at the OpenBao code though, so if you could 1) confirm that the design goal and library I've chosen are more or less correct and 2) point me in the right direction in the OpenBao codebase where I would implement this functionality, then I'll get to work and see what I can do.

[cipherboy]

Hello @IohannesArnold! Great to hear. Give me a couple of weeks and I think I can put together two different proposals for how this can be implemented.

With no offense to anyone at Google, that library looks a little immature and progress seems to have stalled. I've used https://github.com/miekg/pkcs11 and I'd suggest starting with PKCS11v3 support so we can adopt PQC algorithms more easily.

The two approaches at a high level are the much simpler "add this library to go-kms-wrapping" and the more complex "replace go-kms-wrapping entirely with something more purpose built and direct". You should find g-k-w forked under the org's namespace as discussed above.

Let me know your thoughts!

[DanGhita]

Hi all,

IMHO, this topic could be summarized as following: how deep do we want to integrate a KMS into the Vault ? In other words, the current "go-kms-wrapping" is a very basic cryptographic interface (Encrypt/Decrypt). Instead of that, the idea would be to define a more powerful crypto API to be used internally by the Vault. And indeed, this new crypto interface (a kind of gkw V2) should (probably) be as close as possible to PKCS#11.
@cipherboy - do you agree with these thoughts ?

[cipherboy]

Yes, that's definitely a direction I see. Many of the issues with e.g., multi-unseal could be solved by making Vault only single-seal aware, but making a backend library handle the strategy of 2+ encryption backends. This breaks down only at the boundary between automation types (auto HSM/KMS vs manual Shamir's) and is otherwise much simpler. I've not put as much thought into it as I'd like, to be confident in the solution.

The issue with Google's PKCS#11 library is that it isn't very complete and is likely very specialized to their particular use case. We'd preferably want broader PKCS#11 support and more flexibility to do, e.g., symmetric encryption which AFAICT is missing completely.

My 2c.

(g-k-w v2 already exists and is iirc what we're using as of this release, so it'd be more like a v3 API, if we keep that library name at all).

[IohannesArnold]

I saw the other pkcs11 library and did note it looked more feature-complete; I just wasn't sure whether, in a security-focused application like this, using a third-party lib from what looks like an individual maintainer is too much of a risk. But if you think that it's okay to use, then I'll use miekg's lib.

I've taken a look at "go-kms-wrapping" and I think I could take a shot at adding a pkcs11 wrapper just like the others in the library. The other proposal of totally refactoring the seal design sounds beyond me though; this is a new codebase to me and I don't think I'd have the familiarity to do that.

[cipherboy]

Thanks @IohannesArnold! If you want to take a stab at it in g-k-w, it might be valuable to have anyways.

I've used that library in the past and I think it's used by several other security critical projects. The maintainer is usually fairly responsive and keeps making larger changes (adding pkcs#11 v3.0 support fairly recently).