Why security matters when testing and validating microprocessors

Security teams continue to focus on supply chain incidents as attacks get more complex and varied. In fact, the Identity Theft Resource Center has found that supply chain attacks impacted 694 entities in 2020, which ultimately affected more than 42 million individuals.

To help combat these types of attacks, compute lifecycle assurance (CLA) has become a critical framework for analyzing and addressing security risks associated with the supply chains of compute hardware. It’s often broken out into four key stages – Build, Operate, Transfer, and Retire. For this article, we’ll explore the Build stage of a microprocessor, and more specifically the Test and Validation sub-stage.

Why does this matter for security analysts and professionals? Because the trust placed in the integrity of computing systems all starts in these early stages of the supply chain. Without a clear understanding of the threats faced during the Build stage of microprocessors – and the actions taken by vendors to mitigate them – teams cannot assert any level of confidence in the underlying security of their own systems.

Threat models play a pivotal role in the Test and Validation sub-stage because they offer a way to identify and illustrate potential attack vectors against a certain product, procedure, or methodology. For microprocessors and the Build stage, the model typically has five phases:

Security teams start with Assembly Complete as the first stage after all portions of the product have been successfully packaged into a single part. Parts coming out of assembly are extremely sensitive until the provisioning process gets completed. An inaccurate production count could support untracked loss or theft of such critical components. Threat actors could perform attacks on both valid and invalid parts. Although a part may not function fully for production usage, security pros could still consider it a candidate for reverse engineering or attempted exploitation of functional circuitry. Parts that are not fully provisioned also represent the highest security risk as many attack mitigations are not yet functional on the component. Until the team completes provisioning, the group should handle, track, and access these parts with the highest degree of scrutiny.

Class Testing typically represents a limited collection of tests before fully provisioning to verify the power-on capabilities of the parts. Falsification of a test may result in functional units being declared as failed or in parts with compromised security features being declared valid and ready for use. The consequences of such falsification could result in several potential outcomes, including lost revenue and compromise of proprietary information. Compromise of the integrity of the execution of the automated test equipment (ATE) could result in potential break-once-run-everywhere (BORE) style attacks against hardware products. Additionally, such equipment often has access to sensitive values that are stored in products, such as security fuses or plaintext cryptographic material. Collection and subsequent extraction of this information may result in later compromise (or emulation) of valid fielded products. Access to test procedures could also provide attackers with significant insight into what, and how, specific features or technologies are tested.

In the Fusing phase, electrical fuses inside each part are set, or “blown,” to set security critical values and enable or disable specific functionality. There are a variety of threat models used within fusing. Fuse values are used to control functionality and store critical data. Modification of such fuses, either pre-determined or arbitrary, can have a variety of problematic impacts. It’s especially true of any fuses that are not protected with any form of integrity protection. This problem may also exist on compromised ATE. Keeping encrypted data together with an unencrypted key represents an obvious security risk, a risk that’s further exacerbated if the data does not get integrity protected. Much of industry today has moved toward implementing unique-per-device keys for protection of sensitive data. Many products also have unique-per-device values that are used for identification and attestation purposes. Security teams may violate any assumption based upon the uniqueness of these values if multiple parts were provisioned using the same fuse file. As such, disclosure of Fuse Maps and unauthorized disclosure of Fuse processes are also major concerns.

This final step ensures a fully-functional product. As mentioned previously, theft of products, especially prior to completion of this phase, represents perhaps the most drastic of all security threats. Even if products are completely provisioned, theft reduces the cost impact to attackers and makes their job that much cheaper. In mitigating threats security teams want to make the cost of performing attacks targeting such threats as high as possible. Additionally, falsification of test and validation records could let the team discard a good product or ship a bad product. Theft of products do not directly result in security issues, but could result in greater likelihood of exposure of critical information or intellectual property, as well as the product being sold to a specific customer of interest to the attacker.

A malicious insider with access to products during the shipping phase can potentially inject trojan or counterfeit components into the supply chain. They might do this for several reasons, not all of which are malicious in nature. Regardless of the reason, it’s imperative that end customers receive only authentic and accurate components. Shipping records may also not seem significantly sensitive, but they can offer a lot of information to potential attackers. It could let them determine which customers will utilize which products, thereby helping them isolate attacks on specific products based upon their end target. And falsification of shipping records could allow a malicious insider to potentially record the shipment of more products than was performed, creating an excess they could sell on the side.

These are just some of the threats facing the Test and Validation stage for microprocessor lifecycles. Those interested in learning more learn about this topic, check out these resources:

Matt Areno, principal engineer, security architecture and engineering, Intel