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