on 22-Feb-2016 15:00
In this final stretch of security month, what hopefully has been a helpful serving of security content concludes with a look at some of the technologies that support our integrated solutions. In this article, we’ll cover the hardware security modules (HSM.) An HSM is a crypto management device that generates and stores keys locally, protects that key material from leaving the device as well as enforces policy over key material usage, and secures cryptographic operations.
Back before I had the privilege to work for F5, my first exposure to HSM was working on a DoD contract. The web application infrastructure I was responsible for was subject to the FIPS requirements mandating key material be kept under hardware lock and, ahem, key. For years this was under the hood of your BIG-IP appliance (on select models ordered with FIPS cards,) and is still available in that configuration.
Locking away the keys in a custom hardware module in your BIG-IP is all well and good, and still applicable in many situations, but with the advent of hybrid and completely virtualized infrastructures, the need for network-based HSMs, or netHSMs (and now cloudHSMs for that matter,) arose. F5’s integration points with netHSM technologies were developed specifically for this need, allowing VE, vCMP, Viprion chassis, as well as any other BIG-IP appliance without FIPS hardware to be utilized with FIPS deployments.
In the fall, John covered some of the crypto offload options available to F5, FIPS compliant HSMs and otherwise in this Lightboard Lesson if you haven’t checked it out.
With a netHSM deployment, there are considerations on both the client and server side. For BIG-IP, a separate license is required to use a netHSM. On the netHSM, depending on the number of clients (i.e., BIG-IP devices) you use, you might need additional licenses from the netHSM vendor. Just like your infrastructure and application servers, redundancy and scale should be considerations as well, so understanding your SSL traffic needs is important.
The netHSM configurations require installation of the client software on BIG-IP, so that should be included not just as part of the initial deployment, but considered in future hotfix and upgrade plans as well, as the client software will not be carried forward and will need to be reinstalled. For vCMP and Viprion systems, please note that client software will need to be installed for each guest needing FIPS validation.
For further questions on the deployment scenarios and nuances with regard to either the Thales (née SafeNet) or nCipher (née Thales) solution, drop a comment below, ask a question in Q&A , or reach out to your sales team.
Configuring one of our partner netHSMs on BIG-IP is a more complex scenario than most deployments. The install guides for Thales (née SafeNet) and nCipher (née Thales) are below in this list of resources.
Do you, or anybody have any advice or pros and cons of Thales vs. Safenet? I know both are good but have a customer that is looking to decide between the two. Any advice on which should be used or certain environments, what should be the determining factor, etc... would be most helpful. Again, I know both are good products that F5 partners with but looking for scenarios on when to use one vs the other.
Bowlingbe, you can use both vendors Thales or SafeNet. Both are great company regarding HSM devices with different approach. Thales stores working keys on the file system called RFS (Remote File System). SafeNet stores encryption keys in a FIPS 140-2 Level 3 hsm device and keys never ever leave out from the HSM. Your question is all about customer needs. In SafeNet HSM for example Luna series, there are partitions to manage and store keys and also you need client license for every client that connect to the HSM device. You can check from google Safenet Luna 7 Network HSM. In Thales, there is new nShield XS series and every device comes with 3 client license by default. If you need more client license, you must purchase it. I strongly recommend to you thales devices for HSM which is great in my opinion. Hope these helps!
I am getting ready to use a netHSM but one question I have that I'm not finding any answers for is with regard to BIGIP upgrades. For example, if I set up an hsm installation, does that all get carried over to another boot partition when I upgrade to a new version of bigip with the configuration copy option to a new partition?
I had to create a /shared/safenet directory on the BigIP, how does an upgrade affect that?
Thanks in advance if anyone has any answer or guidance on how an upgrade would affect the external hsm settings.