In my previous column — Yay! Finally! A Way to Secure the Supply Chain! — we considered a cunning concept from the crafty chaps and chapesses at Lattice Semiconductor. As you may recall, the idea is to use the Lattice SupplyGuard service to pre-load MachXO3D or Mach-NX FPGAs with a lock program and associated cryptographic key, and it is these locked devices that are shipped to the contract manufacturer, whose security may be suspect and whose motives may be “misaligned,” shall we say.
FPGAs can be programmed using a range of mechanisms via a variety of ports, but the lock program shuts them all down. The only way for the contract manufacturer to reprogram one of these FPGAs is to use an encrypted image supplied by the designers of the system, which means the FPGA acts as its own hardware security module (HSM).
Apart from anything else, this means the contract manufacturer cannot overproduce systems using unprogrammed FPGAs because the encrypted image will work only with an FPGA containing the lock program, and such an FPGA is available only from Lattice (via the INTEGRITY Security Services (ISS)-based route discussed in my previous column).
The really clever part is that, in addition to containing the unlock key and the FPGA’s new configuration, this encrypted image also contains an updated version of the lock program along with its own cryptographic key. Furthermore, MachXO3D/NX FPGAs boast a dual-boot capability, which means that while the original lock program is running, after authenticating the new firmware, it loads that firmware into the other boot partition, reauthenticates it to ensure that all is as it should be, and then hands control over to the new program and wipes itself from the device. If anyone attempts to mount a cyberattack — such as cycling the power — while any of this is going on, the device will revert to its original locked program.
High-level depiction of a SupplyGuard-protected supply chain
(Image source: Max Maxfield)
The result is what the folks at Lattice call “Secure Ownership Transfer.” At each stage in the supply chain, the only people who can load a new image into the MachXO3D/NX FPGA — including the guys and gals at an OEM or a maintenance/repair facility — are those who have a suitable encrypted image containing an appropriate cryptographic key.
The Fall of Cyber Security and the Rise of Cyber-Resiliency
Let’s now assume that the system eventually arrives at the end user’s site, is installed into the network, and starts to perform its allotted tasks in life — and all is as it should be. The problem is that firmware patches and updates will need to be applied to various elements of the system over time, and nefarious forces in the form of hackers and rogue nation states will continuously attempt to break into the system and steal the family jewels, as it were.
Until recently, everyone’s focus has been on what is commonly referred to as cyber-security, the primary role of which is to keep bad actors out in the cold (i.e., on the other side of the firewall). Unfortunately, having great cyber-security can lead to a sense of false complacency along the lines of, “We are totally secure, you can’t get in, so sucks to you!” As a result, the heart of the system is left vulnerable and exposed if any dark forces do manage to breach the defenses.
Two classic examples spring to mind. The first involved the Danish shipping giant A.P. Moller-Maersk. Operating out of 564 offices in 130 countries, Maersk controls almost 20 percent of the world’s shipping capacity. As late as May 2017, if you had asked the IT folks at Maersk as to their ability to fend off cyber-attacks, they would have been extremely bullish as to their cyber-security capabilities. In June 2017, a finance executive in Maersk’s Ukraine operation asked his IT administrators to install an accounting package on a single computer. Sad to relate, this package was infected by a worm called NotPetya, which quickly wriggled its way through the company’s cyber-defenses. Within a matter of hours, Maersk’s worldwide operations were “dead in the water.” (I’m sorry, I couldn’t help myself.)
The second example involved a manufacturing facility owned by the Taiwan Semiconductor Manufacturing Company (TSMC). If you were to travel back through time to the beginning of 2018 and ask the TSMC IT folks at this facility as to their ability to fend off cyber-attacks, they would have smugly pointed out that their manufacturing plants were completely “air gapped” (physically isolated) from the internet and connected only to each other. It was, therefore, an unfortunate happenstance when a well-meaning operator ignored standard operating procedure and connected a new computer to the network before it had been officially sanitized by the IT department. It was even more unfortunate that this machine was infected by the WannaCry ransomware crypto-worm, which immediately went into full-on attack mode, quickly spreading throughout the plant and on to connected factories, eventually compromising more than 10,000 computers and fabrication machines across multiple sites.
Both of these companies boasted cyber-security of the highest caliber but — when their cyber-security failed — it ended up taking both companies weeks to recover and costing them each about $200M.
The problem in both cases was that, although these companies had awesome cyber-security, they had nothing in the way of cyber-resiliency when their cyber-security failed. “But what is cyber-resiliency?” I hear you cry. Well, cyber-resiliency refers to the ability of a system to continuously deliver an intended outcome despite adverse cyber-events such as cyber-attacks. This requires that systems are created in such a way that they are cyber-resilient from the ground (firmware level) up. If a system’s firmware can protect against cyber-attacks, detect cyber-attacks as they happen, and recover from those cyber-attacks while keeping the system functional, then this would be classed as a cyber-resilient system.
I can only imagine your surprise and delight to discover that this is where we close the circle and return to the same MachXO3D/NX FPGAs from Lattice that we used to protect our supply chain. In addition to offering low power, substantial programmable logic resources, and large numbers of input/outputs (I/Os), the flash-based configuration of MachXO3D/NX FPGAs provides “instant-on” capabilities that allow them to be the platform’s first-on, last-off devices. Furthermore, these devices also boast hardware security features that bring NIST-level security to embedded systems, including a NIST-certified Immutable Security Engine that — amongst many other things — enables pre-verified cryptographic functions such as ECDSA, ECIES, AES, SHA, HMAC, TRNG, Unique Secure ID, and public/private key generation.
As defined by NIST SP 800 193, platform firmware resiliency (PFR) involves protection, detection, and recovery. Protection includes protecting the platform’s firmware and critical data from corruption and ensuring the authenticity and integrity of any firmware updates. Detection includes cryptographically detecting corrupted platform firmware and critical data when the system is first powered on, while the system is running, and following any in-system updates. Recovery includes initiating a trusted recovery process and restoring any corrupted platform firmware and critical data to its previous value.
MachXO3D/NX devices fully address cyber-resiliency and PFR requirements by providing features such as their secure dual-boot capability, which means control will be passed to a new encrypted image only after it has been fully authenticated. These devices can also act as the system’s hardware root-of-trust (HRoT). Upon system power-up, the MachXO3D/NX first checks itself to make sure only authenticated firmware is running on it, after which it can check and verify the firmware associated with all of the other devices in the system, refusing to release those devices until it has verified the bona fides of any firmware associated with them.
MachXO3D/NX-based cyber-resiliency solution (Image source: Max Maxfield)
Once the system is up and running, the MachXO3D/NX will continue to maintain cyber-resiliency by protecting, detecting, and recovering itself from malicious attacks. Furthermore, the massively parallel processing capability of its programmable fabric gives the MachXO3D/NX the ability to monitor multiple communications busses and to protect, detect, and recover multiple other platform firmware elements at the same time.
As Eric Sivertson, VP of Security Business at Lattice is fond of saying, “Cyber-attacks are growing in venality, velocity, and veracity.” The bottom line is that all systems are in danger of being attacked and no system is 100% immune from attack. Although traditional cyber-security solutions can defeat many attacks, they become inconsequential once their defenses are breached and the systems they purport to protect are assaulted at their lowest firmware levels. Knowing that a system will be attacked (it’s not a case of if; it’s a case of when), the only option is to enhance existing cyber-security with cyber-resiliency that can protect against firmware attack, detect any ongoing firmware attacks as they happen in real-time, and overcome said attacks by restoring the system to a known-good state.
MachXO3D/NX FPGAs — in conjunction with the Lattice SupplyGuard service and the Lattice Sentry Solutions Stack software and services offering — can secure the supply chain, provide an HRoT, and make the entire system cyber-resilient. I’m extremely happy that designing cyber-secure and cyber-resilient systems isn’t my problem, but if it were, then you can bet your little cotton socks I’d be talking to the folks at Lattice.
