It's not the Network! Ok, maybe it's the network...

Jason Rahm

Subscribe to Jason Rahm: eMailAlertsEmail Alerts
Get Jason Rahm: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Hardware Security Modules

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. 

The need for crypto offload

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. 

HSM diagram

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.

 The Fine Print

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 SafeNet or Thales solution, drop a comment below, ask a question in Q&A, or reach out to your sales team.

Resources

Configuring one of our partner netHSMs on BIG-IP is a more complex scenario than most deployments. The install guides for SafeNet and Thales are below in this list of resources.

Read the original blog entry...

More Stories By Jason Rahm

Experienced predominantly in the networking realm over the last dozen or so years, Jason is expanding his horizons towards systems management and even trying his hand at python.

Jason assists in the maintenance duties for http://devcentral.f5.com, contributes frequently in the forums, and writes weekly on some cool geekery in the F5 product lines. When not working, Jason enjoys spending time with his beautiful wife Michelle and his four children. He is active and volunteers network administration duties at his church and if there are any remaining minutes in the week, he enjoys Wii & XBOX, tennis, racquetball, softball, etc. He does not enjoy running, but does (scratch that, thinks about doing) it anyway to recover his youthful appearance.