Martin G. Dixon
Intel fellow and Vice President, Intel Security Architecture and Engineering Group
By Martin Dixon
Intel’s goal is to build the most secure products, from CPUs and XPUs to the software that enables our ongoing innovation to accomplish greater and more complex computing tasks. We are bold and ambitious in our pledge to security and invest in unparalleled people, processes and products to integrate security into the way we work and what we work on. It is our relentless pursuit of building the best solutions that has built trust with our customers and partners.
Since Forrester Research Inc. first coined the term in 2010, Zero Trust has become a hot topic in the networking security world. This security model is different from the trust and confidence our customers have in our products.
Zero Trust refers to a proactive and pervasive approach to network security designed to minimize uncertainty. It shifts the paradigm from trust based on physical connectivity or proximity to one that involves always authenticating every access. The Zero Trust model has enabled work from home without joining a virtual private network (VPN). Simply put, it means no one is trusted by default from inside or outside the network, and verification is required from everyone trying to gain access to network resources.
Changing the Game with Hardware
In hardware, many security paradigms are still based on physical connectivity. That is, once an access is on a hardware bus it is often assumed legitimate. Hardware designers are typically not taught to question messages. A bit or message that comes in is assumed to have come from the correct party. As attackers get more sophisticated in physical attacks, those assumptions need to be questioned just as the paradigm of authenticating once to the network has been questioned.
At the system level, Intel and others in the industry have contributed technology such as DMTF’s Security Protocol and Data Model (SPDM). SPDM allows the authentication and identification of hardware and the measurement of firmware. This model enables secure collaboration between elements in hardware similar to how TLS and HTTPS secure web-transactions. As SPDM is more widely adopted, components on the system can mutually authenticate and establish secure connections. Intel has also pushed for PCI-SIG and Compute Express Link to add Integrity and Data Encryption (IDE) that will, when implemented, help protect physical links to various accelerators such as GPUs.
However, I believe the Zero Trust concepts shouldn’t stop at the network or system. Rather they can be applied all the way down inside the silicon. We even refer to infrastructure on the chip as a network or “network on a chip.”
At Intel, we have technologies that allow for immutable identifiers inside our designs. Each transaction on our internal fabrics has a hardware-generated identifier. Additionally, as designs disaggregate into chiplets, mutual authentication is required between die within a package. Internally at Intel, we refer to a set of security principles that includes “Trust No One,” which is our way of relating to Zero Trust architecture.
I’ve listed the rest of our principles below. Hardware development has different characteristics to software, but there are a lot of commonalities for security principles. Some of the calculations change due to the latency and expense of semiconductor fabrication. Rebuilding software might take hours to days, but rebuilding a semiconductor takes weeks to months. This can tilt the scales against security mechanisms that want to lock-down debug and access.
- Fail safely and securely: Ensure that error conditions don't leave secrets around. The classic anti-pattern in hardware is the so-called cold-boot attack, where secrets are left in memory after a reboot.
- Complete mediation: Check every single access to confirm legitimacy. In hardware, this might mean making memory accesses go through appropriate memory management checks from the path from application to memory and back.
- Rule of least privilege: Minimize the privileges any hardware agent has. In hardware, it’s often appealing to give additional privileges to agents just in case. Usually, the stated justification is the cost of a mistake that causes a new fabrication. However, it is important to minimize privilege “creep.”
- Separation of duty: Make agents have their own purpose on the designs. Since hardware real-estate is expensive, it is often appealing to overload an agent with multiple duties. This complicates validating and reasoning about the security posture.
- Least common mechanism: Separate out security functions from others. It is a common design pattern to have a shared utility bus that transports sideband messages across designs given the expense of on-die wires. If that same bus carries user messages and secrets, it is an attack point.
- Secure the weakest link: Protect the design’s weakest part. In hardware it is almost always debug. Given the evolution of functional debug and structural testing in the industry, hardware debug features often want access to almost every single transistor on a design. That is at odds with security mechanisms that want no access to part or all of the design.
- Defense in depth: Build multiple walls. This can mean blocking access to a resource even if it seems like it should be open. For example, should a chip need to be debugged then production keys may be inaccessible.
- Simplicity: Invent simpler architectures. Simpler mechanisms are harder to come up with, but easier to implement, validate and secure. This is a universal truth for hardware and software.
- Psychological acceptability: Make security mechanisms easy to use. If the security architecture is too onerous, then it is tempting for hardware designers to give hardware blocks super-user-like powers.
In practice, we apply these principles when developing security technologies delivered by our products that improve foundational security, data and workload protection, and software reliability. As a result, our customers are provided robust technologies that improve their security posture and support a Zero Trust infrastructure.
The idea of foundational security is to bring up components in a known and safe configuration and have all the hooks necessary to keep them so. To boot safely, Intel has a host of architectural features, with the showcase items being the security engines found in both client and data platforms. The security engines ensure each part has its own unique identity that can't be forged. These engines provide services including approving debug, knowledge of privilege and mediation for deriving keys. The services are housed in a secure subsystem that has exactly one duty: security.
Once we've booted securely and have the system in a known good state, it's time to run user work. This is where Zero Trust can be applied to data and workload protection. Today, we have Intel® Software Guard Extensions (Intel® SGX), Intel® Virtualization Technology and other technologies designed to protect data and memory from uncertainty of the operating system and other applications.
Once the system is running in a trusted state and a layer of data and memory protection is in place, reality interferes. Most applications want to talk to the world. Software reliability is not strictly security, but bad actors want to break into systems through something that scales. That means software. This is where hardware-enabled tools like Intel® Control-Flow Enforcement Technology and Intel® Threat Detection Technology step in to improve the resilience of software in the face of malicious activity.
These are only some of the hardware-enabled innovations Intel has today to support our customers with a Zero Trust security strategy. We are committed to building the highest performing and most secure platforms. We’ll be sharing more architectural advancements later this year and at Intel Innovation.
Martin Dixon is an Intel fellow and vice president in the Intel Security Architecture and Engineering Group at Intel Corporation.