I was brought up by my parents to have a suite of core values, including the fact that it was wrong to tell porky pies and that it would be despicable beyond words to pilfer, pinch, or purloin anything from anyone. Shortly after I graduated from university, soon after I moved to commence my first job at International Computers Limited (ICL) in Manchester, England, I was burgled. The callous swine took the only thing I owned that was worth anything — a brand-new rubber-handled hammer that I’d purchased out of my first pay-packet.

Although this occurred close to four decades ago as I pen these words, I’m still seething with the injustice of it all. I wake up in the middle of the night thinking, “Some naughty person” (or words to that effect) “out there is wielding a rubber-handled hammer that should, by rights, be clasped in my own fair hand.”

With regard to the technologies, computers, and electronic systems I love so much, I hate the fact that black-hat hackers exist at all. It also really disgruntles me that nation states like China, Iraq, North Korea, and Russia do nefarious things including stealing our intellectual property (IP), rifling through our personal data, and attacking our infrastructure. Why can’t people and governments simply do the right thing and behave the right way?

The term “supply chain” refers to the system of organizations, people, activities, information, and resources involved in creating a product or service and supplying it to the end user. Today’s global supply chains are extremely distributed and highly complex, and there are many points in the chain where bad things can, and do, happen. For the purpose of these discussions, let’s consider only a simple supply chain as illustrated in Figure 1.

Simplistic depiction of a rudimentary supply chain (Image source: Max Maxfield)

The key point here relates to the firmware that is to be loaded into components like CPUs, MPUs, MCUs, GPUs, FPGAs, and/or the memory devices that serve them. Such firmware can potentially be compromised at any point in the supply chain. Of course, the designers of the system deliver their firmware IP in encrypted form, cryptographic keys are shared only with trusted players, and the cryptographic keys and encrypted firmware are injected into the target components using hardware security modules (HSMs). Unfortunately, when it comes to today’s dedicated Tier 1 hackers, the entire process leaks like a sieve.

As a result, systems delivered to the end users may contain cloned parts, counterfeit parts, or cheap-and-cheerful substitutions that degrade the reliability of the system, thereby impacting the reputation of the creators of the system. In some cases, the entire system may be a phony reproduction, thereby denying the original designers of that system their rightful remuneration. And — believe it or not — all of this is the good news, because the worst-case scenario is that the firmware contains malware designed to compromise your systems and either steal, corrupt, or ransom your data.

Should you feel I’m being a tad dramatic, may I refer you to Zombie Zero. In this case, a rogue nation state paired a contract manufacturer with a hacker organization. The original goal was to break into the enterprise resource planning (ERP) systems of Fortune 100 companies around the world. They achieved this goal beyond their wildest dreams. The contract manufacturer loaded compromised firmware into handheld barcode scanners that were distributed to the targeted companies. As soon as one of these scanners was installed on a wireless network inside a company’s firewall, it mounted a sophisticated attack against that company’s internal network. The end result was to exfiltrate every piece of scanned data (item type, source, destination address, and more) back to a botnet in China. The perpetrators subsequently used the compromised networks to deliver a second payload that extended their command-and-control capabilities to the targeted companies’ corporate servers in finance, thereby accessing detailed financial data on customers and shipments around the globe.

What is required is a hardware root-of-trust (HRoT) that we can actually trust. What we’re talking about here is a device that acts in a first-on, last-off role, controlling the powering up (and down) of the other devices, including verifying that any firmware they contain, or that is being loaded into them, is secure and remains uncompromised.

The bottom line is that we need at least one device — along with its associated firmware — that is guaranteed to be “good.” But where can one go to find such a beast? Well, you can only imagine my surprise and delight when I discovered that those clever chaps and chapesses at Lattice Semiconductor have come up with a solution that makes me want to perform my happy dance (you might want to run for the hills whilst I perform my warming-up exercises because this is not going to be a pretty sight).

High-level depiction of a SupplyGuard-protected supply chain
(Image source: Max Maxfield)

OK, this takes a little bit of effort to wrap your brain around but, once you’ve got the idea, it will bring a smile to your face and dimples to your cheeks. First, most of the existing process stays as-is with regard to any off-the-shelf MPUs, MCUs, GPUs, and FPGAs. What we are interested in here is Lattice’s MachXO3D and Mach-NX FPGAs being deployed in conjunction with the Lattice SupplyGuard service.

Let’s start with the MachXO3D/NX FPGAs. In addition to acting in a first on, last off role (supervising the powering-on/off and firmware loading of other components), these flash-based devices boast a host of hardware security features — like an immutable security engine and dual-boot capability — that bring NIST-level security to embedded systems, thereby allowing them to act as the system’s HRoT.

Where things get really clever is when we start to look at the Lattice SupplyGuard service, which provides customers with factory-locked devices that can be programmed only by using a configuration bitstream that has been developed, signed, and encrypted by the intended customer (the designers of the system, in this case).

Now, take a deep breath and we’ll walk through this step-by-step. Let’s start with the folks at INTEGRITY Security Services (ISS), whose mission in life is to deliver end-to-end, layered, embedded security solutions to protect intelligent devices and their supply chains. In this case, ISS oversees the loading of the initial lock program and any associated cryptographic keys into the MachXO3D/NX FPGAs, which are then shipped to the contract manufacturer. Meanwhile, the corresponding unlock key is shipped to the company that designed and owns the system.

As an aside, the guys and gals at ISS perform their magic in special datacenters and secure infrastructures with 24x7x365 operations monitoring, redundant power supplies (on-site generators), multiple internet providers, and industrial cooling and fire protection. As a result, in the event of an alien invasion, you’d be safer in an ISS data center than you would be in Fort Knox.

There are a variety of modalities by which MachXO3D/NX FPGAs can usually be programmed. The lock program disables them all. The only way the contract manufacturer can modify the contents of the FPGA is to present it with an encrypted firmware image (in the form of an encrypted bitstream in this case) that is provided by the designers of the system. Essentially, the FPGA is acting as its own HSM, but without anyone throwing cryptographic keys around like confetti.

This also means that it’s impossible for the contract manufacturer to clone the FPGA, because the encrypted bitstream can be loaded only into an FPGA containing the lock program, and those FPGAs are available only via ISS.

Now, this is where you really need to pay attention because the encrypted payload contains a number of items as follows:

• The unlock key that will unlock the lock program that resides in the FPGA and that will subsequently allow the new image to be loaded.
• The configuration bitstream that will define the FPGA’s function.
• A new lock program containing a new lock key.

Remember that MachXO3D/NX FPGAs have a dual-boot capability. This means that while one program is running (the original lock program in this case), a new program can be loaded into the other flash segment. The lock program that’s currently running authenticates the new program against its unlock key. Once the new program has been authenticated, it will be loaded into the other flash segment, after which it will be reauthenticated to ensure it was loaded correctly.

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. It’s only after the device has been reprogrammed and has authenticated itself that the original locking program transfers ownership to the new program in the other boot segment and wipes itself out.

Now, this is the really, really clever part because — in addition to the system designer’s IP — the new encrypted image also contains its own instantiation of the locking program, but this time containing the designers’ own cryptographic key. This means that this IP can be overwritten only by a new piece of encrypted IP that contains the corresponding unlock key, along with its own locking program and that program’s cryptographic key. In turn, this means that when the system leaves the contract manufacturer, it’s still locked, but this time with the designers’ own key, and — most importantly — at no stage did the designers have to share their IP or cryptographic keys with anyone else.

All of this sets the scene for what Lattice calls “Secure Ownership Transfer.” The initial IP provided by the designers may be a low-level test program. Once this has been successfully run, the designers may provide the contract manufacturer or the OEM with a second firmware image to be loaded into the device. In this case, the new IP can be loaded only into a device that contains the previous IP. And, once again, this new IP will contain its own locking program along with its own cryptographic key.

The same process can follow the system as it makes its way through the system. Later, if the product is sent to a maintenance and repair facility, for example, that facility may be provided with new IP firmware to be loaded into the device. Once again, this firmware can be loaded only into a device that already contains the unlock program with the appropriate cryptographic key. And, once again, this firmware will contain its own unlock program along with its own cryptographic key. And so it goes, all the way until the product is finally decommissioned.

Of course, we still have to worry about all of the other components in the system. We also have to be concerned about any in-system patches and updates that will invariably be loaded at the end-user’s facility. But we will leave these topics until my next column. In the meantime, you may want to watch the archived version of a virtual seminar on Cyber Resiliency Solutions and Supply Chain Protections for a Post-Pandemic World that took place on 9 March 2021 and that covers everything I’ve discussed here in excruciating detail. As always, I welcome your comments and questions.