You’ve now reached Part 4 of my four-part series on encryption. So now you’re an expert, right? Part 1 covered AES encryption, describing the difference between confidentiality and message authentication. Part 2 looked at data at rest (or storage data) and presented different issues for secure encryption. In Part 3, I discussed a complex security subsystem called MACsec for use on Ethernet systems. Now in Part 4, we’re going to dive into how Internet Protocol Security, or IPsec, can be accelerated by embedded IP cores, and then look at IP core support and qualification.

Compared with MACsec, which has a single detailed standard document, the IPSec specification is a rather bewildering suite of RFC standard documents with an array of options for encryption standards and connectivity. What I am considering is tunnel mode (IP Encapsulating Security Protocol RFC4303) using AES-GCM encryption and authentication (RFC4106).

Although IPsec shares much of the cryptographic functions with MACsec, there are some important differences. IPsec is termed an end-to-end solution using the Internet protocol, because intermediate routers have no means of decrypting and looking inside the packets. Also, unlike MACsec, the transmit channel in IPsec usually has multiple Secure Channels and will use different keys to communicate with different destinations.

At the start of a session, software establishes a mutual authentication with the far end equipment and negotiates what cryptographic keys will be used for the session’s duration. Once the connection is established, then encrypted messages pass through the network unaltered until they reach the destination. The entire IP packet is encrypted and authenticated by the originating equipment and a new IP header is added to route the packet to its destination. The system works in tunnel mode as a Layer 3 connection to create a virtual private network (VPN) for network-to-network communications.

Hardware accelerated IPsec in the form of an embedded core will be much faster than a software solution for encryption. A hardware solution may make sense in a server or gateway, which deals with IPsec connections from many clients. For maximum security, the encryption uses AES-GCM with 128-bit or 256-bit keys, which is supplemented by authenticating the entire packet.

Now let’s consider some different aspects of using embedded IP cores to provide secure systems. A common question relates to certification. NIST manages the Cryptographic Algorithm Validation Program (CVAP) under which licensed test labs check the responses of AES implementations to a lab generated set of test vectors. If they’re correct, the test lab will add the implementation details to the AES Validation List on the NIST website. There are test programs for all AES modes that have corresponding NIST standards (SP800-38A through SP800-38E). IP cores can also be validated under this program.

Algorithm validation under CAVP shouldn’t be confused with cryptographic module certification under FIPS140-2 or FIPS140-3, although use of a validated algorithm implementation is a requirement for FIPS140 certification. The difference is that FIPS140 is about the complete system and considers many aspects such as physical security (e.g., tamper resistant hardware) that aren’t related to the IP core. If you’re planning to submit a cryptographic module to FIPS certification, you’ll normally be guided through the process by the NIST approved test lab you select, and the IP core vendor will work with the test lab as required to provide any necessary product details and support algorithm validation.

This brings up the subject of support. The support that a vendor offers can be critical to success. If you’re one of the rare crypto experts, then maybe this isn’t so important. But for the rest of us, cryptography is a specialized skill that we don’t have time to acquire. I mentioned that choosing the wrong AES mode can leave the solution vulnerable, but there are lots of other decisions to be made and more complex cores that provide additional features. The implementation phase is typically where engineers need help from the core vendor, as the core often must be squeezed into an already tight FPGA design.

A well-designed core will give the designer the option to trade-off resource types. For example, there are crucial blocks in the crypto core called S-Boxes. These can be realized in either Block RAM or in the LUTs in the FPGA fabric. Having the option to mix-and-match lets designers squeeze the design into the available resources remaining in the device. Timing closure can be an issue for high-speed designs. Again, help from the core vendor can provide invaluable assistance. This might be by modifying the pipelining structures, or recommending applying different design attributes to critical nets.

Once the vendor and core are selected, there are further considerations. For example, can you get an evaluation of the core to see if it meets your requirements before you pay the license fee? Also, unlike just about any other IP you can license, some crypto core vendors will supply HDL source code. This lets the customer prove that the code has no virus or Trojan code incorporated, and that it can’t be forced into unauthorized states or operations.

Many vendors of secure equipment insist on conducting a security audit, and this is easier with source code compared to reviewing a netlist operation. Even if there are no resources for an immediate audit, there’s peace of mind to be gained from having the source code available for examination in the future should any questions arise. The audit results reassure end users that they can deploy equipment with the embedded IP core without concerns, and can be an important differentiator for the equipment vendor.

Source code also speeds up the design process and documentation. The design is enhanced because engineers can experiment with variables such as data-path width to provide a high throughput by implementing wider data paths. Alternatively, the core can be configured for minimum FPGA footprint by selecting a narrow data width. In contrast, these parameters are “hard coded” into a netlist prior to delivery, and the user has no options to alter the design.

Paul Dillien has worked with Algotronix Ltd. covering sales and marketing for the past six years. He previously worked in the FPGA industry, and is the author of The FPGA Market report. Paul is a Chartered Engineer and has worked in strategic and tactical marketing roles for leading U.S. and UK semiconductor companies and has specializations in competitive analysis and negotiation.