Protecting Data with Controller-Based Encryption, Part 1

Author: Kevin BurbankFIPS

We all know that data protection is critical, and with the growing adoption Controller Based-Encryption (CBE) for 8G Fibre Channel and 12G SAS/SATA controllers, I’ve heard from a lot of people who want to know more about the FIPS certification process for products that use CBE modules.

Over the course of this series, I’ll explain CBE and why it’s necessary, also, outline some of the key details you need to know in order to get FIPS certification for cryptographic modules.

Controller Based Encryption

CBE is a high-performance data encryption technology built into protocol controllers. Typical array controller designs include a protocol controller managing the SAN interface, another protocol controller managing the disk interface, and a CPU complex in between as shown here:

Controller Based Encryption

To implement encryption, we need a cryptographic module, key management clients, and connectivity to key server(s). Data encryption can be performed at several points within the system, including in the host computer, in the SAN infrastructure, or on each of the storage disks.

In an optimum scenario, the encryption solution should:

  • minimize complexity
  • ensure reliability
  • not impact performance
  • use a proven, secure architecture

To that end, the array controller is the ideal encryption location since the I/O controllers within the array controller are natural aggregation points for all data. Importantly, this location requires no additional CPU or system memory from the host to achieve line rate encryption.

Some FIPS 140 Background

FIPS certification dates back to 1995 when the National Institute of Standards and Technology (NIST) and the Communications Security Establishment Canada (CSEC) formed the Cryptographic Module Validation Program (CMVP) for validating cryptographic modules to the Federal Information Processing Standards 140 (FIPS 140).

Federal agencies are required to purchase FIPS 140-validated cryptographic products. Therefore, if your cryptographic products are not FIPS 140-validated, you are locked out of serving the federal space. What’s more, many commercial organizations have also adopted the FIPS 140 standard.

The latest revision of the standard is FIPS 140-2, though the next revision – FIPS140-3 – is currently in development.

The FIPS 140-2 Validation Process

FIPS 140-2 validation applies to a specific software and hardware configuration. It assures users that a given technology has passed rigorous testing and can be used to secure sensitive information.

Testing is performed by independent Cryptographic and Security Testing (CST) laboratories. The entire process can take 6 to 12 months or longer, and consists of three phases:

Phase 1: The Product Developer submits a product for testing.

Phase 2: The Laboratory analyzes the submission, including:

  • Product design and documentation review
  • Algorithm testing
  • Physical security testing (if applicable)
  • Source code review
  • Functional testingAfter completion, the Laboratory submits a validation test package to the Cryptographic Module Validation Program (CMVP) for review.Phase 3 (Validation & Certificate): The CMVP finalizes the validation process by posting a FIPS 140-2 certificate entry on the NIST website.

In my next post, I’ll explain the FIPS 140-2 validation levels and their requirements.

This entry was posted by Carol Whitmarsh on at and is filed under Encryption. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply

You must be logged in to post a comment.