Benefits of FPGAs as implementation platforms for cryptosystems

About a year ago, we took a look on why hardware is more secure than software. Now it is time to focus a little deeper on the subject and discuss why Field Programmable Gate Arrays (FPGAs) are good platforms to implement critical cryptosystems and how they relate to competing solutions.

Isolation of critical cryptography and keys

The aspect that we touched already last year is that FPGAs (and other hardware-based solutions) allow full isolation of critical cryptographic computations and keys from the rest of the system that runs on potentially buggy software platforms.

With FPGA-based implementations of cryptography and key storage, the system can be designed so that the software system can never access cryptographic keys or other security-critical values. Even if the software gets compromised, the keys remain secure in the FPGA. As a consequence, the system remains protected, for example, against buffer over-read attacks (such as the famous Heartbleed bug) that allow the attacker to read over the intended readable region and expose security-critical information such as keys or passwords from the memory.

These kinds of secure software/hardware co-designs are nowadays easy to implement as FPGA vendors offer reprogrammable system-on-chip devices that combine FPGA resource with hard CPU cores (for instance, Intel® SoC FPGAs or Xilinx Zynq® Ultrascale+™ MPSoCs).

Algorithm agility

Algorithm agility is the feature that allows cryptographic algorithms to be updated in a system that is already deployed in the field. Algorithm agility is one of the key advantages of FPGAs and, in this respect, FPGAs compare to software: it is possible to update the algorithm support of an FPGA-based system because FPGAs are – as already their name says – programmable. This is an important differentiator of FPGA compared to Application Specific Integrated Circuit (ASIC) based security solutions such as Trusted Platform Modules (TPMs).

While the ability to update out-dated or even broken cryptosystems with new ones has always been important, it is without a doubt even more important today. Currently used public key cryptosystems – that is, Elliptic Curve Cryptography (ECC) and RSA – must be replaced (or at least complemented) with new ones in order to answer the threat of emerging quantum computers. This change is something that every system designer should take into account when using public key cryptography. But, unfortunately, the replacement algorithms or even their features such as key sizes are not fully known yet, so designing systems for them is still difficult, emphasising the need for algorithm agility.

Performance

Because implementations for FPGAs are designed on the register-transfer level, the designer has full ability to perform bit-level optimisations and utilise performance increasing design choices such as algorithm unrolling and pipelining. Consequently, carefully designed FPGA-based implementations are very efficient and can outperform software-based implementations by several factors. For instance, software-based implementations of AES-GCM, the work horse of Internet cryptography, typically start falling short after the required speed exceeds 10 Gbps, even on the most powerful processors with hardware-accelerated AES instructions (AES-NI). FPGAs, on the other hand, can easily handle encryption speeds of several tens of Gbps per encryption stream and even a medium-size FPGA can support hundreds of Gbps for parallel AES-GCM streams. The difference is even larger for many other cryptographic algorithms that lack hardware accelerated instructions in CPUs.

Counter-intuitively, FPGAs may sometimes match or even outperform ASIC-based cryptography implementations in practical settings. The reasons behind this are two-fold:

1. On one hand, FPGA-based implementations can be fully optimised for the features of the specific cryptosystem, as other cryptosystems can be supported via reprogramming, thanks to algorithm agility. On the other hand, ASIC-based implementations typically have to be designed generic enough to handle also cryptosystems that could be required rarely or possible in the future, simply because it is not possible to extend the algorithm support at a later stage. Consider, for example, a system that is designed to use Elliptic Curve Cryptography (ECC) on a modern high-performance elliptic curve Curve25519. An FPGA design can be optimized solely for this elliptic curve because the unlikely, yet possible, future requirement to support, for example, NIST P-256 curve can be covered by the ability to reprogram the FPGA. Then again, an ASIC implementation must be designed to have a generic support for both curves (and many more curves) which leads to a less efficient implementation.

2. The reprogrammability logic of FPGAs obviously brings overhead against ASIC-based implementations, where the required functionality is implemented directly on the silicon. However, the effects of this overhead are mitigated by the fact that FPGAs themselves are implemented with the most modern semiconductor processes which can be seldom used in customer ASIC projects for accessability or cost reasons. FPGAs also have hardened features such as multipliers and memory blocks that can be often utilized in cryptographic implementations to narrow the performance gap to ASIC implementations.

Security features of FPGAs

Modern FPGAs have built-in features that facilitate secure design. First of all, most FPGAs today offer a possibility to encrypt programming files that configure an FPGA to implement the particular designs. As a result, it is not possible (a) to reverse-engineer the design from a programming file or (b) to copy the design to another FPGA that does not have the decryption key for that encrypted programming file. Some FPGAs also support programming file authentication that additionally prevents any tampering of the programming file and, consequently, the design. Certain FPGA families also include built-in anti-tamper detectors that detect malicious-looking behavior such as attempts to open the FPGA package.

The non-volatile nature of (SRAM-based) FPGAs also makes the attacker’s task harder as the devices lose their states and configurations as soon as the power is switched off. On the other hand, this complicates generation and storage of device-specific values because the same programming file must typically be used across multiple devices. Xiphera has a patented solution to solve this problem.

All these security features add layers of protection and make FPGAs very good platforms to implement security-critical systems.